IRC channel logs


back to list of logs

<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>well, maybe some kind of memory corruption :-(
<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 looks
<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.
<mark_weaver>hence the first calls into iconv there
<civodul>mark_weaver: backtrace:
<civodul>it's not really pleasant to have this get-string-n in the middle of binary I/O
<mark_weaver>civodul: what kind of port is it?
<mark_weaver>ah, a CBIP. hmm.
<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.
<mark_weaver>yes, the Guile/GDB stuff is insanely great! :)
<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>it does call it
<civodul>line 359
<mark_weaver>oh, nvm :)
<civodul>maybe it's doing other silly things though
*civodul needs to sleep
<civodul>end of the hackathon for me :-)
<mark_weaver>okay, good night!
<civodul>too bad i didn't manage to finish that refactoring for build systems
<civodul>sometime this week, hopefully
<mark_weaver>a good beginning, no doubt :)
<civodul>we'll see
<civodul>good night/day!
<mark_weaver>well, that pti->encoding_mode value is indeed very bogus. it *does* look like memory corruption to me.
<mark_weaver>(and not just that field)
<davexunit>I think this was a successful hackathon. :)
<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>I'm glad the hackathon went well :)
<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! :)
<paroneayea>bavier: :)
<mark_weaver>sneek: later tell civodul: regarding it's definitely memory corruption. almost all of the fields are clearly invalid.
<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>Got it.
*mark_weaver goes afk for a while...
<mark_weaver>bavier: is your clock set right? says that your patch was pushed negative 5 minutes ago :)
<bavier>mark_weaver: :P
<bavier>actually, it is 5 or 6 minutes fast
<bavier>I haven't used this system in a while
<mark_weaver>not important, just never saw that before :)
<bavier>me neither, heh
<Steap>putain il est 2H
<civodul>Hello Guix!
<sneek>Welcome back civodul, you have 2 messages.
<sneek>civodul, mark_weaver says: regarding it's definitely memory corruption. almost all of the fields are clearly invalid.
<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 | | things to package: | thanks to everyone who joined the hackathon!'
<civodul>mark_weaver: seems to be a nice fix
<phant0mas>good morning guix
<mongrol>I have found a workaround for the buggy qemu graphic console
<mongrol>qemu -vga std
<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?
<civodul>no idea
<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>it's been a month, i think
<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
<civodul>there are pros and cons
<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)"
<civodul>things like that
*leth waves to starchild
<starchild>what are the specific pros though?
*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
<civodul>also which is a minor annoyance
<nkar>how's dmd?
<civodul>it does the job
<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>dmd lacks the stuff to correctly solve the bug DusXMT was referring to:
<civodul>DusXMT: what problem did you have with X?
<civodul>'slim-service' works for me
<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>DusXMT: ooh, i see
<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
<civodul>something like that
<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
<civodul>"bootx" is the script you use?
<DusXMT>That's how I named it, yes
<DusXMT>It's not official or anything
*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
<davexunit>phant0mas: avr-gcc and friends?
<davexunit>that would be great.
<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
<phant0mas>the pc is too hot to touch right now :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
<mark_weaver>yeah, that makes sense to me.
<davexunit>not sure what that name would be, though.
<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?
<davexunit>flash-tools works for me
<Ulrar>nkar: Cool ! :)
<phant0mas>davexunit: flash-tools it is then
<civodul>would Gnash go in that module? :-)
<civodul>otherwise could be "rom-tools"
<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...
<civodul>it takes some getting used to
<davexunit>I'm going to push the pypi importer once I get home from work. :)
<cmhobbs>is there a packaging guide?
<cmhobbs>i still need to read all the docs
<cmhobbs>the gnu distribution bit in the docs is quite confusing
<cmhobbs>granted, i skimmed it
<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>nkar, on it! thanks
<cmhobbs>is the purpose of the bootable system to roll yet another libre gnu/linux distribution?
<cmhobbs>sorry for the stupid questions :/
<nkar>no need to be sorry
<davexunit>cmhobbs: yes.
<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?
<nkar>it's already used
<cmhobbs>is it a guix flavored kernel or is it linux-libre?
<davexunit>yeah we use linux-libre
<jxself>If you want to install GNU stuff on an existing distro then GNU SRC (Source Release Collection) might be better.
<paroneayea>hey cmhobbs :)
<paroneayea>fancy seeing you here
<jxself>Everybody loves Guix. :)
<civodul>cmhobbs: to install Guix on a running GNU/Linux system, see
<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
<civodul>davexunit: yes, that could work
<cmhobbs>paroneayea, o/
<cmhobbs>civodul, davexunit, i'm using guix right now on xubuntu and trisquel
<davexunit>cmhobbs: yay!
<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
<cmhobbs>but i need to get up to speed
<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>tadni: 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
<davexunit>yeah, that can wait.
<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.
<davexunit>to see what's lacking
<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.
<cmhobbs>i dig it
<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>just the package manager
<cmhobbs>i like the purely functional aspec
<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.
<davexunit>so I can reproduce them at any time.
<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.
<cmhobbs>wow, awesome
<cmhobbs>i need to learn me some guile :/
<tadni>cmhobbs: You can do a lot with Guix, without even knowing how to program.
<davexunit>tadni: agreed re: guile-wm
<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>tadni, my job is programming :D
<cmhobbs>i'd just like to help with the project
<cmhobbs>going to lunch
<cmhobbs>back in a bit
<tadni>cmhobbs: o/
<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>davexunit: Neat!
<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>we'll see.
<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
<davexunit>ya know, so C-t C-t sends C-t
<tadni>davexunit: What's multiple layered keybindings called? Like doing "C-' g n" to create a new group?
<davexunit>I dunno, actually.
<davexunit>been wondering that myself
<davexunit>I need to implement a system like that for Sly
<paroneayea>"key sequence" is what emacs calls them
<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>paroneayea: ... weird.
<paroneayea>weird indeed
<tadni>Yup, just checked the logs.
<tadni>Okay, going to nap. Peace peeps. o/
<alezost>tadni: someone was working on feh package during hackathon: I don't know if he still wants to finish it. At least you can use his intermediate results.
<cmhobbs>i have returned \\o/
<cmhobbs>ha, thanks
<cmhobbs>is packaging a good place to start working on guix?
<cmhobbs>or should i try to jump into learning the codebase first?
<davexunit>packaging, definitely.
<cmhobbs>cool. i'll start looking into that. i'm reading the slides mentioned earlier today
***starchy is now known as starchild
<mark_weaver>hi civodul!
<civodul>hello, mark_weaver!
<mark_weaver>I applied the bash update (from bash-cve-bis) to master, since it's all built on x86.
<civodul>perfect, thanks!
<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)
<DusXMT>Any feasable alternatives?
<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>quidam. :)
<jxself>Who survived the 68 mile hike by the way.
<mark_weaver>that's good!
<mark_weaver>quidam == Rubén Rodríguez ?
<jxself>quidam on IRC.
<starchild>jxself: what's that about a hike?
<jxself>He went on a 68-mile hike with some friends over the span of 4 or 5 days.
<jxself>Trisquel's BDFL.
*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.
<jxself>But quidam is still BFDL.
<jxself>er BDFL
<starchild>this is betty btw:
<jxself>GitHub? EEk.
*jxself faints
<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.
<starchild>I would need to learn packaging
<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?
<davexunit>starchild: also, I just added this to the wishlist, looks straight-forward to package:
<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
<mark_weaver>ah, okay
<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)
<cmhobbs>what are the hurdles to packaging?
<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.
<tadni>cmhobbs: In what regard?
<cmhobbs>tadni, just common roadblocks
<cmhobbs>what makes a difficult or easy package/
<jxself>The amount of work involved?
<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?
<cmhobbs>dependency chain, maybe?
<tadni>cmhobbs: That's a big part of it.
<cmhobbs>i know the question was vague
<cmhobbs>just getting my feet wet here :D
<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.
<tadni>Namely Clisp and Stumpwm.
<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.
<mark_weaver>s/a home-rolled/and home-rolled/
<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>ah, okay, thanks
<civodul>sorry, i look grumpy now ;-)
<mark_weaver>no worries, I sometimes ask questions on IRC when I should do my own research first :)
<civodul>heh :-)
<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>the error is:
<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
<DusXMT>mthl: pastebin, my friend
<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>hi! BTW :-)
<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 or
<mark_weaver> is nice to use for scheme snippets
<mthl>It compiles with that command
<mthl>but it failed!
<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>mthl`: Really, anything remotely lisp related -- is typically a good choice.
<tadni>Besides, I don't think they have clj support yet?
<DusXMT>tadni: fits that description afaik
<tadni>DusXMT: For anything remotely lisp related, support wise?
<mark_weaver> does block tor users, I know that from personal experience (I route my web traffic through tor)
<tadni>Isn't it non-free?
<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
<civodul>good night/day!
<mthl`>thanks to civodul i use paredit but it's not enough
<mthl``>thanks for your help, i'm going to bed, bye!