<civodul>RISCi_ATOM: you should use 'slim-service' to get an X session up and running <civodul>then the default will start WindowMaker, but you can change that with ~/.xsession <mark_weaver>civodul: is it possible that one thread was reading from the port while another thread changed it's encoding? <mark_weaver>it could also happen if one thread was writing while another changed the encoding. <civodul>no, there's only one thread, doing a get-string-n on a port <mark_weaver>that assertion is in scm_i_port_iconv_descriptors, which is only called from two places. <mark_weaver>it's called from get_iconv_codepoint (ports.c) and display_string_using_iconv (print.c). both of those are static procedures that are themselves only called from one place each, and only if (pti->encoding_mode != SCM_PORT_ENCODING_MODE_UTF8). and the only other value in that enum is SCM_PORT_ENCODING_MODE_ICONV. <mark_weaver>civodul: did the assertion failure happen within a call to get-string-n ? <civodul>actually i didn't check the backtrace <civodul>but the one-line patch in the paste above reproduces it <mark_weaver>can you find out what is the value of pti->encoding_mode when the assertion fails? <mark_weaver>and also a backtrace. I'd like to know whether the field has been overwritten with garbage or if it's legitimately set to SCM_PORT_ENCODING_MODE_UTF8 <mark_weaver>although SCM_PORT_ENCODING_MODE_UTF8 is 0, so that might be corruption too. <mark_weaver>it would actually be good to see the entire pti structure, to see if it looks sane. <mark_weaver>civodul: in all of serialization.scm, that seems to be the only place where textual I/O is done instead of binary I/O. <civodul>it's not really pleasant to have this get-string-n in the middle of binary I/O <civodul>(this Guile support in GDB is wonderful :-)) <mark_weaver>makes me wonder if scm_new_port_table_entry is not getting called for this kind of port. <davexunit>I really need to learn to use GDB and how guile integrates with it <civodul>it's supposed to work out-of-the-box <mark_weaver>civodul: bah, I think the problem is that 'make_cbip' doesn't call 'scm_new_port_table_entry'. <mark_weaver>when I added the pti stuff, I assumed that all ports would be initialized by 'scm_new_port_table_entry'. <civodul>maybe it's doing other silly things though <civodul>too bad i didn't manage to finish that refactoring for build systems <mark_weaver>well, that pti->encoding_mode value is indeed very bogus. it *does* look like memory corruption to me. <mark_weaver>such a nice backtrace, with all the SCM values shown properly :) <paroneayea>I wish I could have participated... I had an urgent deadline <paroneayea>on the upside, my understanding of guile continues to grow! maybe soon I'll be useful to guix. <bavier>paroneayea: we'd certainly like the help! :) <mark_weaver>sneek: later tell civodul: encoding_mode = (unknown: 2349617152) (should be 0 or 1), iconv_descriptors = 0x1067f0000000002 (not a valid heap address), setvbuf = 0x4189800000000000 (pointer to C function, can't be right), alist = 1174427952046145536 (that's a SCM value, should be an alist obviously) *mark_weaver goes afk for a while... <bavier>actually, it is 5 or 6 minutes fast <bavier>I haven't used this system in a while <sneek>Welcome back civodul, you have 2 messages. <sneek>civodul, mark_weaver says: encoding_mode = (unknown: 2349617152) (should be 0 or 1), iconv_descriptors = 0x1067f0000000002 (not a valid heap address), setvbuf = 0x4189800000000000 (pointer to C function, can't be right), alist = 1174427952046145536 (that's a SCM value, should be an alist obviously) ***civodul changes topic to 'GNU Guix | http://gnu.org/s/guix/ | things to package: http://libreplanet.org/wiki/Group:Guix/Wishlist | thanks to everyone who joined the hackathon!'
<mongrol>I have found a workaround for the buggy qemu graphic console <mongrol>how do I tell guix to download packages again if my store gets wiped? <mongrol>basically my install barfed on grub-bios-setup and I wiped the rootfs <nkar>has someone recently tried to package ghc? can't guix accept a binary dependency as done in nixpkgs? <civodul>nkar: technically it can implement the same approach as Nixpkgs <civodul>just as described in "Bootstrapping", but for Haskell instead of C <nkar>I forgot, do they patch the binary to allow that? <nkar>unrelated question: does anyone use standalone guix daily? <civodul>nkar: i saw your questions and then got disconnected and unable to reconnect <civodul>so yes, i use the standalone system daily <civodul>obviously there are rough edges, but it works for my use cases <starchild>any specific reason that in the package names the hashes are at the beginning rather than the end? <civodul>starchild: it's inherited from Nix, and there are no specific reasons <starchild>is there any faq somewhere that discusses the pros and cons? <civodul>not that i know of, maybe there should be one <civodul>but the basic argument is that one rarely has to type in those file names <civodul>instead one would run, say "find $(guix build foo)" *starchild waves back to leth <nkar>starchild: that's probably the most popular question <civodul>starchild: if you have a store file name printed on screen, you can just remember the first 3 letters say, and type "ls /gnu/store/abc<TAB>" <civodul>whereas if you typed /gnu/store/bash-<TAB>, you'd still have to choose between several variants <starchild>true, but it also gives me an imediate idea how many bashes I have <nkar>starchild: in practice, you don't use the store directly, so it doesn't matter <civodul>starchild: now you know the arguments in favor of each :-) <civodul>i think many people, me included, make the same remark when discovering the thing <civodul>but eventually, you tend to forget ;-) <nkar>civodul: re daily usage: great! could you elaborate on the glitches? <DusXMT>nkar: I also use GNU as my main operating system <DusXMT>Currently, my only complaint is that my network card gets detected late, but I guess that could be fixed by simply putting the driver into initrd <civodul>yeah, i don't have this particular problem ;-), but i have issues with sound <civodul>that's annoying but acceptable for me, because i know how to work around it <DusXMT>I even have X installed, but I had to hack up a couple of scripts to set up the environment and start it properly, which require root access, so my solution isn't that secure - but it gets the jopb done (there is no xinit afaik) <civodul>DusXMT: what problem did you have with X? <civodul>and i have ~/.xsession to launch Ratpoison <DusXMT>civodul: No real problem, it's just that I'm used to starting X with xinit (startx) instead of having it start autimaically, in case I _don't_ want to use X <DusXMT>The script runs as root, starts X, and then calls another script as my user that starts WindowMaker. <civodul>it would be good to have a startx program somewhere <civodul>or we could change the 'xorg-server' service to be off by default <civodul>so you would run "sudo deco start xorg-server" when you want X <DusXMT>civodul: or even better, for it to not be intrusive, let it be configurable wether so start the X server by default via a key to the service in the os definition <DusXMT>So those who like it the old way will not be affected <civodul>DusXMT: exactly, sounds like a good idea <DusXMT>That means bootx might go on retirement then *phant0mas started working on an AVR toolchain package <Ulrar>Would be great to get ghc working, it's not the first time I see that question here <phant0mas>I remember there are a lot of avr funs in here so I thought it would be nice having it :-) <davexunit>phant0mas: I should really say this on the list but since you're here... could you perhaps make an (gnu packages avr) module for this stuff to live in instead of creating a new module per package? <phant0mas>I was actually thinking of asking the same thing, I will send the patch after the building is finished :P <mark_weaver>I also agree, but at least one of the packages he added for the avr stuff is not avr-specific, so we'll have to be selective. <mark_weaver>I recall that when I added the 'flashrom' package, needed to flash libreboot (or coreboot), it used a library phant0mas had already packaged for the avr stuff. <davexunit>maybe the module name can be more generally named. <davexunit>tools for flashing firmwares on various chips <nkar>Ulrar: I'll try to use the "bootstrapping" method civodul suggested. I've tried to do it differently but haven't succeeded. <phant0mas>maybe something like flash-tools ? And we will add in there flashrom, avr-dude and anything similar? <civodul>though ROMs that are flashed are not really ROMs... <davexunit>not sure how to best avoid the confusion with gnash <davexunit>civodul: thanks for the help with autotools. I find it all so hard to grok, and then I see how little code it takes to accomplish a task... <davexunit>I'm going to push the pypi importer once I get home from work. :) <cmhobbs>the gnu distribution bit in the docs is quite confusing <cmhobbs>but it might help to have an entry point for installing guix on already running gnu/linux systems <nkar>cmhobbs: "package without a scheme" on the home page <cmhobbs>is the purpose of the bootable system to roll yet another libre gnu/linux distribution? <nkar>yes, that's the purpose. though, guix has more "tasty" features compared to ordinary distros <cmhobbs>is the plan to use the Linux kernel? <cmhobbs>is it a guix flavored kernel or is it linux-libre? <jxself>If you want to install GNU stuff on an existing distro then GNU SRC (Source Release Collection) might be better. <davexunit>cmhobbs: I personally use guix on a debian system from my git checkout via the pre-inst-env script. <phant0mas>davexunit: civodul; maybe flashing-tools? There will be no confusion with that <cmhobbs>civodul, davexunit, i'm using guix right now on xubuntu and trisquel <civodul>cmhobbs: cool, thanks for trying it out! <cmhobbs>i'm just stoked for a libre package manager. i've been reading up on it, i'd like to help with code/packags <davexunit>packaging software is a good first step for contributing. if you can find a missing piece of software that has a sane build process, you're golden. *tadni still needs to do Feh, since someone was kind enough to already do scrot. <tadni>I think openbox should be mostly ready to go too, but I'm not as motivated to package that -- seeing I don't use it. *tadni will probably try to do feh, by the weekend. <tadni>Really, wicd or some other network manager, it the only thing I still /need/ for my day to day computing. <tadni>I can skim by on guile-wm for the most part or ratpoision, stumpwm is by no means essential for me. <paroneayea>cmhobbs: are you running it as a userspace package manager? <cmhobbs>paroneayea, currently yes. got it running this weekend on my systems during the hackathon <cmhobbs>i'll try to start using it exclusively <paroneayea>I'm thinking of setting it up on my debian machine <paroneayea>aside from the guix os version in a vm, would be nice to have a way to install more up to date libraries for just my user <tadni>cmhobbs: The distro, or the package manager on a host OS? <cmhobbs>i don't know about the guix os for primary use <cmhobbs>i'm not sure most of the stuff i use would be on there <cmhobbs>i'll let it mature a bit before then <tadni>cmhobbs: Kay, I was going to warn you there are a few gotchas for GNU distro alpha right now. <tadni>The big one, being lack of being able to connect to wifi. <davexunit>we certainly would appreciate you building VMs or trying the installation on spare hardware. <cmhobbs>davexunit, i can run it in VMs for sure <cmhobbs>but i won't run it as my main OS until things are stable <tadni>cmhobbs: Are you going to use qemu? <cmhobbs>i guess the big question i have is: why make yet another distro? <tadni>If so, you need a special command, that opens a virtual boot menu. <davexunit>I imagine a lot of people have that question. :) <cmhobbs>tadni, not sure. i generally just toss things into virtualbox. anything heavier, i use xen or kvm <cmhobbs>davexunit, yeah, i'm not being critical, i'm just trying to understand what niche guix (as a distro) would be trying to fill <tadni>cmhobbs: Unify the GNU project, into an actual OS. Offer a set of utils other distros dont, etc. <davexunit>cmhobbs: you may have noticed that we do thing quite differently than other distros. <davexunit>the whole "purely functional package management" thing <cmhobbs>well, i haven't noticed anything about a distro with it <cmhobbs>i also like the per-user installations <cmhobbs>and the multiple build user accounts are interesting <davexunit>well having a package manager is good, but it's kind of weird to have a package manager like guix on top of another distro. <tadni>The GNU Distro, is the only thing really tying me to Scheme over CL at this point, tbh -- and that is due to all the cool things happening here. <davexunit>guix can do things that a lot distros struggle with like reproducible systems configuration <davexunit>in guix, you can write some Scheme code that describes exactly how a machine should be configured. <davexunit>and install on physical hardware, or maybe make a bunch of VMs in a cluster or something. <davexunit>there are a ton of tools out there that try to tackle the problem of reproducible systems, but none (besides nix of course) tackle it from the systems level <tadni>cmhobbs: Another really cool thing, and it's due to the fact that there is an "OS EDSL" is that one can very easily set up "spins" of GNU. You can have a very minimal install image and a directory with a bunch of scm files that automatically grab a certain enviroment. Say a gnome.scm, kde.scm, webserver.scm, etc. <tadni>It's a lot more flexible, than other distros, besides again maybe NixOS. <davexunit>when guix is more mature, I hope to be able to maintain a git repo that stores the OS definitions of all my machines. <tadni>davexunit: Yeah, that'd be neat. <tadni>Once we get wireless networking working, I plan on working on "emaculate.scm" more and uploading it somewhere. <tadni>Guile-wm needs a bit more love though, I'm probably going to side with ratpoison for the time being. Tiling did not work as intended. <tadni>cmhobbs: You can do a lot with Guix, without even knowing how to program. <tadni>davexunit: The big glaring ones for me, is the input/key handling and the lack of modeline -- but there are some other things here and there. It's sad to see mwitmer hasn't really done much this year on it. <cmhobbs>i'd just like to help with the project <tadni>And with my experience level, I can't do much to anything with guile-wm to help it out ... :^/ <davexunit>tadni: yeah he must be busy. I'll probably have another patch or two to send him when I try guile-wm next. <tadni>I mean, given a years time ... if Guile-wm has progressed really, I'd love to help, but hopefully it's in a comparable state to stumpwm by then. <davexunit>probably won't get there unless mark witmer hacks on it more. <davexunit>I got stumped trying to figure out how enable an escape sequence <tadni>davexunit: What's multiple layered keybindings called? Like doing "C-' g n" to create a new group? <davexunit>I need to implement a system like that for Sly <tadni>/me is still trying to visualize what a "graphics toolkit" for emacs would look like, as-per guile-wm's wishlist. <tadni>Maybe just simple gui widgets like found in gtk. <tadni>Did my last message come through, about the graphics toolkit query? Erc doesn't display it. <tadni>It just kinda disappered when I pressed enter... <paroneayea>yes, though it said /me and then inserted two newlines after it <tadni>Okay, going to nap. Peace peeps. o/ <cmhobbs>is packaging a good place to start working on guix? <cmhobbs>or should i try to jump into learning the codebase first? <cmhobbs>cool. i'll start looking into that. i'm reading the slides mentioned earlier today ***starchy is now known as starchild
<mark_weaver>I applied the bash update (from bash-cve-bis) to master, since it's all built on x86. <mark_weaver>it seems I need a way to upgrade all except for a couple of packages that are currently broken (icecat and conkeror) <mark_weaver>(though I guess really I should stop using those browsers entirely until we apply security updates to them) <mark_weaver>the best solution is to find out how to patch them up and get them working again. <DusXMT>(Of course there's w3m, and it can even display pictures on xterm and fb, but many, many sites are broken in it, mainly due to the lack of formatting and js, but quite frankly, what more would one expect from a text browser like w3m?) <mark_weaver>(conkeror is built on xulrunner from our icecat, so we'll get conkeror for free once icecat is fixed) <mark_weaver>since icecat is just based on firefox, probably we just need to find the security patches applied to that version of firefox since icecat was made from it, and apply them. <mark_weaver>I looked on their mailing list, and there is a new icecat maintainer, currently working on newer versions. <DusXMT>I think Debian's iceweasel is currently at version 24 i n stable, so maybe we could look at their patches? Perhaps? <mark_weaver>I really think this problem should be fixed within icecat itself. <mark_weaver>i.e. the icecat project should be providing security fixes somehow, even if they simply adapt the patches from firefox or iceweasel or whatever they find most convenient. <jxself>The new icecat person is the trisquel person. <jxself>Who survived the 68 mile hike by the way. <jxself>He went on a 68-mile hike with some friends over the span of 4 or 5 days. *starchild asks betty to translate 68 miles to kilometers *civodul thoughts Trisquel's team was larger <jxself>I'm not sure how up to date it is. <davexunit>starchild: I would say "package it!" but it's Ruby and that's complicated. <davexunit>the development dependencies mention rspec with we don't have yet. <davexunit>I feel like every ruby project I encounter uses its own build system. <DusXMT>starchild: then try it. You can try packaging dosbox, for example, a free PC emulator (which can be used for messing with real-mode assembly programming). I've already done it but haven't posted it (yet), it was relatively easy but I had a build failiure I had to fix. I think trying to package it is a good first step <mark_weaver>DusXMT: out of curiosity, does dosbox have advantages over qemu? <DusXMT>mark_weaver: I think it's both lighter and faster, when it comes to emulating dos, as the operating system is implemented, not emulated <DusXMT>s/operating system/program loader and file system/ <starchild>alright. reading the documentation now. thanks for the suggestions. <DusXMT>(The real reason why I haven't posted it is because the build system doesn't detect one of the optional dependencies. The fix should be trivial, but I just haven't gotten around to it) <tadni> civodul: One of the core problems of all Free Software Distributions which I've seen, is in that the number of people working on them are soooooo small. This is one of the things I'm hoping the "GNU brand" will help with -- even if that means canabalizing some smaller Free Software Distros. <cmhobbs>what makes a difficult or easy package/ <tadni>cmhobbs: Well, I'm guessing you are saying compared to other distros? <cmhobbs>tadni, no, i just meant packaging something new, what's constitutes an easy thing to roll a package for and a difficult thing? <tadni>cmhobbs: That's a big part of it. <DusXMT>cmhobbs: Easy package: Buils out of the box with the standard build procedures, difficult: Doesn't / neeeds patching <tadni>Something like GNOME will take a lot longer than what I'm using to get rolling. <DusXMT>not always patching actually, but working around the build system to get it to work <tadni>DusXMT: That's true too, if a package follows a traditional build system and/or not need a patch in some form or another. <DusXMT>And then there's programs that fail to build becausethe APIs of libraries have changed, then the program needs patching <DusXMT>For example, abiword relied on the fact that libjpeg defiled boolean as an int. Since as of version 9 (iirc) it changed to an enum, and since Abiword is in c++ and c++ has stricter casting rules than C, it didn't build because of it (but again, the fix was trivial) <DusXMT>And it also relied on the fact that libpng's data structures were publically accessible, which is no longer the case with modern libpng so that also needed fixing - again, trivial stuff, but still, it needs patching <DusXMT>And then there's packages that you just write the definition for, it finds all its dependencies and builds flawlessly, that's what I'd call an `easy package' <mark_weaver>civodul: I saw that you implemented a fix for downloading via https using the SERVER NAME extension, but even with the latest 'master', I still can't download magit-1.2.0.tar.gz *DusXMT should stop jabbering and actually get back to packaging, gpc is waiting for him <mark_weaver>it says: "warning: TLS 'SERVER NAME' extension not supported" <mark_weaver>and then proceed the fail the same way it did before <mark_weaver>this is on a standalone Guix system. however, the guix-daemon is a bit old. maybe that's the problem? <mark_weaver>cmhobbs: the most common packaging problems are related to the fact that on a guix system, everything is somewhere in /gnu/store/* and not in the usual places. in practice, packages based on the autotools usually work fairly well, but other build systems like cmake, python, ruby, a home-rolled ones are often more work. <civodul>mark_weaver: please reply to the bug address :-) <civodul>mark_weaver: if it says "extension not supported", that means the set-session-server-name! procedure isn't defined, so it's not the latest GnuTLS <mark_weaver>no worries, I sometimes ask questions on IRC when I should do my own research first :) <mthl>Hi Guix! Hey I tried to define a package called gmrun and i get an error, perhaps can someone help me to understand what is my mistake. <mthl>$./pre-inst-env guix build gmrun <mthl>;;; note: source file /home/mthl/src/guix/guix/config.scm <mthl>;;; newer than compiled /home/mthl/.cache/guile/ccache/2.0-LE-8-2.0/home/mthl/src/guix/guix/config.scm.go <mthl>;;; Failed to autoload make-session in (gnutls): <mthl>;;; ERROR: missing interface for module (gnutls) <mthl>;;; Failed to autoload connection-end/client in (gnutls): <mthl>;;; ERROR: missing interface for module (gnutls) <mthl>;;; Failed to autoload make-session in (gnutls): <mthl>;;; ERROR: missing interface for module (gnutls) <mthl>;;; note: source file /home/mthl/src/guix/gnu/packages/xorg.scm <mthl>;;; newer than compiled /home/mthl/.cache/guile/ccache/2.0-LE-8-2.0/home/mthl/src/guix/gnu/packages/xorg.scm.go <mthl>;;; note: source file /home/mthl/src/guix/gnu/packages/kde.scm <mthl>;;; newer than compiled /home/mthl/.cache/guile/ccache/2.0-LE-8-2.0/home/mthl/src/guix/gnu/packages/kde.scm.go <mthl>;;; note: source file /home/mthl/src/guix/gnu/packages/scheme.scm <mthl>;;; newer than compiled /home/mthl/.cache/guile/ccache/2.0-LE-8-2.0/home/mthl/src/guix/gnu/packages/scheme.scm.go <mthl>guix build: error: gmrun: unknown package <civodul>mthl: can you try ./pre-inst-env guile -c '(use-modules (gnu packages gmrun))' ? <civodul>assuming that's the right module name <civodul>and yeah, pastebin is better for things like that <mthl>i will use it for the next time <DusXMT>maybe not exactly pastebin (it has ads on and blocks tor users), but perhaps paste.debian.org or dpaste.de <mthl>It compiles with that command <DusXMT>Time to examine the error and fix what is wrong <tadni>DusXMT: Is a pastebin, not just the general name for such a program -- which one such implementation of such, happens to have that name and is non-free/has adds? <tadni>Besides, I don't think they have clj support yet? <tadni>DusXMT: For anything remotely lisp related, support wise? <mark_weaver>pastebin.com does block tor users, I know that from personal experience (I route my web traffic through tor) <DusXMT>I think it is, but I haven't checked. Librejs claims non-free JS, but that it does even on pages like libreplanet or on some pages of the free software directory <civodul>mthl`: does guile -c ... report an error? <DusXMT>tadni: just to avoid a misunderstanding, my answer was referring to `Is a pastebin which happens to have that name and is non-free/has adds?' <mthl`>i have made syntactic errors that i'm trying to fix <DusXMT>mthl`: In Vi, if you press % above a parenthesy, it will jump to the one that opens/closes the region enclosed by it, I find that useful for lisp/scheme (emacs probably has something similar) <DusXMT>That's very useful for debugging scheme/lisp files for syntax <mthl`>thanks to civodul i use paredit but it's not enough <mthl``>thanks for your help, i'm going to bed, bye!