<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>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)
<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!'
<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)
<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?
<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: 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.
<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)
<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?
<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.
<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.