IRC channel logs


back to list of logs

<davexunit>hello #guix!
<sneek>Welcome back davexunit, you have 1 message.
<sneek>davexunit, civodul says: yay for the F-Droid talk! :-)
*davexunit is back from vacation
<paroneayea>hey davexunit
<paroneayea>welcome back :)
<davexunit>paroneayea: hey!
<paroneayea>hi davexunit
<davexunit>paroneayea: how's it going?
<paroneayea>looking at the state monad in guix, which is making me wish I understood how monads work
<paroneayea>it's going okay :)
<paroneayea>davexunit: I'm hanging out in guix because I'm trying to figure out how deployment stuff will work for mediagoblin's premium hosting stuff. We'll probably use a debianoid rather than guix at this stage, but I'm really interested in the approaches guix takes
<paroneayea>how was your vacation?
<davexunit>paroneayea: my vacation was good. I went to Maine. I was supposed to stay until Tuesday but it's just going to rain so I came home.
<davexunit>paroneayea: I think an experimental guix mediagoblin deployment would be fun. :)
<paroneayea>would indeed be fun :)
<paroneayea>anyway, I'm heading to bed. Good night!
<DusXMT>If a package uses the GNU Build system, but it has the configure script in a non-standard directory, how do I specify in a package definition where it is?
<civodul>Hello Guix!
<DusXMT>Hi ludovic
<Svetlana>civodul, hi! it could be a nice idea to get hydra working. I'm compiling a disk image for around 3 days now.
<civodul>hey Svetlana
<civodul>Svetlana: it's actually working, AFAICS
<civodul>a bit slow, as usual, but "working"
<Svetlana>Ok, I'm trying again without the --no-substitutes switch to see what it says. It probably even works. Hm.
<civodul>yeah, let me know how that works
<DusXMT>civodul: Is it okay to change file permissions in a (snippet) in a package declaration? If yes, what module contains the chmod syscall?
<civodul>i just started 'guix package -u'
<civodul>DusXMT: yes it's OK, and 'chmod' is part of Guile's default module, so nothing to add
<DusXMT>civodul: Ah, thanks :)
<Svetlana>it keeps listing a lot of .o files at me but no more make's rubbish output
***mst_ is now known as mst
<DusXMT>Is there a way to create patches for guix packages which create files? I can create a patch, and if I import it with "$ patch < file.patch", it creates the file, but in guix, it says "can't find file to patch at input line n"
<civodul>DusXMT: by default Guix expects patches that can be applied with -p1 from within the source tree
<civodul>so perhaps that's the reason you're seeing this error
<leth>is there a reason you have to unmount /mnt at the end of the installation of guix?
<DusXMT>civodul: Is the use of (snippet) reasonable here: (it doesn't build yet, but I'm getting close)
<civodul>leth: to make sure everything is written to disk, and because the system doesn't unmount it otherwise (which may be an issue)
<civodul>DusXMT: that's an original approach (typically i would have replaced the 'configure phase), but i don't see anything wrong with that
<leth>civodul: that makes sense, but umounting it doesn't seem to work.
<civodul>leth: how?
<leth>it's used by unionfs
<civodul>oh, right!
<civodul>so you have to run 'deco stop cow-store', first
<leth>i guessed as much but that doesn't work.
<civodul>actually maybe just rebooting is enough
<civodul>how so?
<leth>yes a reboot should sync discs first.
<leth>unionfs still uses /mnt after i stoped cow-store.
<civodul>anyway, just run 'reboot', it should work fine no?
<leth>yes, i killed unionfs but that was not a good idea.
<leth>reboot "should" work.
<civodul>no, unionfs is used for the root file system, better not kill it ;-)
<leth>anyway deco stop cow-store should probably be in the installation deocumentation either that or just reboot instead of umount
<leth>or just sync
<civodul>right, i'll change that
<DusXMT>civodul: The program I'm trying to package for Guix fails the configure step as it can't determine where to put recovery files. It tests for /var/tmp, /var/preserve and /usr/tmp, using the first one which exists and is writable. I can make it assume the correct option, but I myself don't know which is
<DusXMT>So, where should temporary files, which should be preserved over reboots, be stored?
<DusXMT>In the GNU system
<DusXMT>because none of the directories exist in my guix installation
<civodul>DusXMT: actually these directories may exist in the system, just not in the build environment
<civodul>so you may have to patch nvi's build system to ignore the "problem"
<DusXMT>civodul: no, they don't even exist on my installation of the system
<civodul>well, they could exist ;-)
<civodul>but i'd rather use /tmp for that, no?
<leth>DusXMT: it's really confusing to call them temporary if they shouldn't be preserved since temporary is used in posix to denote a file that doesn't.
<DusXMT>civodul: /tmp gets erased after reboots, wouldn't make much sense putting crash recovery files there :)
<leth>if you're not making the files with mktmp or such a systemcall then don't call them temporary to avoid confusion over the term.
<DusXMT>okay, will avoid the term, seesh
<DusXMT>I think I'll just use /var/tmp, as that's what debian uses
<civodul>yeah, i don't know what the "standard" is
<civodul>Emacs and Vim (IIRC) keep backups alongside the original files
<leth>/var/tmp is recommended
<DusXMT>leth: thanks
<leth>though there is no guarantee that a file in /var/tmp is preserved over time. in fact it shouldn't be.
<leth>it "should" be preserved past a reboot though.
<DusXMT>Okay, it builds now and seems to work, I'll send it to the ML
<DusXMT>okay, sent. This was my first package definition, so I'm sorry if I did something wrong in it
<leth>after installing guix from an usbv it fails with 'failed to resolv partition label "root"' the partition is albled root, and the config is from the example on on the usb image. i've also tried using uuid which didn't work.
<civodul>leth: Svetlana reported that on their laptop the kernel would take more than 15 seconds to detect the USB drive, leading to the error above
<civodul>that's probably the same story here
<civodul>commit 5c3eb14 intends to fix that
<civodul>if that's an option for you, i'd suggest building a new installation image with that fix
<leth>why would you need to detect the usbdrive? also the problem exists if i boot without the usb drive plugged in.
<civodul>oh that's when booting on the installed system?
<civodul>after the error, does (find-partition-by-label "root") succeed at the REPL?
<civodul>also, is there a kernel message showing that the root partition was detected?
<leth>(find-partition-by-label "root") returns #f which i would guess means it doesn't work.
<leth>can i list the partitions somehow?
<civodul>yes, type: (disk-partitions)
<leth>empty list
<civodul>hehe, interesting
<civodul>so it may be that the initrd lacks some module for your hard disk
<civodul>do you know if anything special is needed?
<leth>that would be my first guess.
<leth>not sure, it's an old ssd.
<leth>running over sata.
<civodul>i think the default initrd has the sata modules already
<leth>i would be surprised if it didn't
<civodul>if you have another system available on that machine, could you try lsmod and see if there are modules obviously missing?
<leth>i guess i could boot up the usb drive and see how it detects the hd.
<civodul>oh right
<leth>will take a couple of minutes i'll highlite you when i'm done.
<davexunit>did you all see that we got some attention on hacker news?
***tschwing_ is now known as tschwinge
<leth>i'm guessing it needs pata/sata_via for my disks.
<leth>civodul: ok, it needs sata_via which i'm guessing isn't loaded in the guix system. does guix use /etc/modules(.conf) or can i set up the module in the config.scm?
<leth>think i found the documentation for modules, but i still don't understand how to use it.
<leth>should the filesystems that base-initrd takes just be an ampty list or does it have ot contain root, and in that case how do i refere to the root filesystem?
<leth>the base-initrd example in the documentation doesn't work.
<civodul>davexunit: cool!
<civodul>damn, that reddit thread was long ;-)
<civodul>leth: i think the manual has an example on how to specify additional kernel modules
<civodul>oh the example doesn't work
<civodul>hmm i think it should definitely work
<civodul>there are similar things done in gnu/system/vm.scm
<civodul>leth: gtg, but let me know if you find out!
<tadni>civodul: o/
<DusXMT>just out of curiosity, how long does it usually take for a new user of the mailing list to pass the spam dectection?
<tadni>DusXMT: Took me about an hour, initially.
<jxself>New users are probably moderated, and so it would depend on how quickly the list administrator were to go and clear the flag.
<jxself>Since clearing that flag in Mailman is a manual action.
<DusXMT>jxself: thanks
<jxself>Perhaps if you poke at civodul he can go do something. :)
<DusXMT>nah, he's probably working on something more important
<leth>civodul: now i got the initrd config to work, but unfortunatly it doesn't build. i'm ont entierly sure i got the modules right though.
<DusXMT>leth: Could you pastebin your error? (If you get `permission denied', that means the module is already in there)
*davexunit is packaging ruby
*jxself packages davexunit
<leth>trying to rebuild but i'll paste when done.
<davexunit>(define davexunit 'help-me)
<davexunit>ruby is being a pain
<ijp>sounds about right
<davexunit>got ruby to build finally, but tests fail
<davexunit>seems there are some rubygems issues to figure out.
<DusXMT>leth: could you try with something like --verbosity=9001? (doesn't have to be that high, but I don't know how much is the least for most details)
<DusXMT>As this error is rather vague
<leth>running at verbosity 9001
<davexunit>leth: what, 9000!?
<leth>it's over 9000!
<leth>note sure that helped really
<leth>unless there's some info higher than i can scroll up
<leth>i guess i could pipe the whole output.
<leth>ok, that helped.. i got module not found..
<leth>and for some reason i reboot the system, don't ask me why..
<leth>i guess it can't find the module.
<DusXMT>leth: are you using the fill file name?
<leth>if including .ko at the end is the full name then yes, otherwise no.
<DusXMT>Perhaps it also needs the subdirectory? Because it's basically just a cp command
<leth>hmm.. how would i know which path it should have?
<DusXMT>look around in /lib/modules on your working system? (eg. $ find /lib/modules -name thing.ko)
<leth>it doesn't have /lib/modules
<DusXMT>Hmm, strange. Then perhaps /
<leth>what is the base path of the cp command?
<DusXMT>I would thing lib/modules/version/kernel/; but I'm not 100% sure
<leth>seems likely i'll test it
<leth>that doesn't seem to be it
<leth>lovely that source code is in one line...
<DusXMT>the .drv file? That's because it's generated, i'd look at the definitions in guix/system of the Guix project folder
<DusXMT>actually, gnu/system/
<leth>it runs (find-files module-dir "^filename$") where filename is whatever i write in the cofig
<leth>i made a spelling mistake in the filename.. :)
<civodul>davexunit: ISTR someone had posted an initial version of Ruby
<davexunit>civodul: oh really? missed that.
*davexunit looks
<davexunit>found it
<davexunit>ah, pjotr did this.
<civodul>leth: could you paste the output of "bzcat `guix build --log-file /gnu/store/aayw08pspyw904z7fg3rjg3rjxkdfk8icizj-base-initrd.drv`"?
<civodul>and also the base-initrd call?
<davexunit>I've had a lot of problems trying to package ruby, going to move on to something more productive.
<civodul>yeah, that can be frustrating :-/
<leth>civodul: do you need it for something? i'm working on the problems i had and DustXMT has been very helpful
<leth>that seemed to have done the trick, let's se if everything is settled now
<civodul>leth: ah ok, no worries then :-)
<civodul>i was just hastily reading through my backlog
<leth>got it all working now thank you for the help civodul and DusXMT.
<DusXMT>leth: no probs
<leth>also the deocumentation might need to mention that using initrd needs modules srfi
<leth>-26 because it uses cut
<civodul>leth: good to know, and yes, will add srfi-26 to the doc
<DusXMT>Svetlana: # modprobe kvm; # might help
<leth>i run out of memory trying to install emacs, is there a required or recommended amount of ram for guix.
<DusXMT>leth: swap is definitely useful, I'm running on a system with 512M of ram, 4gigs of swap and I compiled most things on the machine
<tadni>leth: I've never tried guix on anything under 2gbs of ram, but swap is handy regardless.
<civodul>it's mostly the substituter that's memory-hungry currently
<civodul>but yeah, 2G should be OK
<leth>should i create a swapfile the regular way or is there some sort of configuration in guix to do it?
<leth>i guess i should've got a swap partition when i was partitioning the drive, but a file will do.
<DusXMT>leth: guix currently doesn't support swap
<DusXMT>so you have to manually activate it every time you boot, or somehow automate it
<tadni>DusXMT: Which is easy, but annoying.
<Svetlana>I just tried but it does not help
<Svetlana>could possibly try as root, hm :o
<DusXMT>Or you could also skip the image creation part and instead use $ guix system init install.scm /where/you/mount/a/usb/device/with/label/gnu-disk-image
<DusXMT>But you'll need to modify it to not overwrite the boot loader of your system
<DusXMT>anyways, I'm off to bed
<civodul>DusXMT: thanks for helping out, BTW :-)
<tadni>More minor kickback from using "GNU" as the distro name in #emacs. :^P
<DusXMT>civodul: No problem, anything to help out GNU and its users :)
<civodul>tadni: oh, what do people say?
<civodul>i guess i could also /join #emacs
<tadni>civodul: It's mainly one guy who has been persistent about it. But mainly " It's his PR problem, not mine."
<tadni>And similar sentiments.
<civodul>not sure what that means actually
<civodul>that "GNU" is a bad name for PR?
<tadni>From what I can tell, most people don't even know there is a GNU distro though stil -- even in directly GNU related means. #gnu, #fsf, #emacs, etc.
<civodul>yeah, well
<civodul>help needed :-)
<tadni>civodul: Because it's confusing that there is now a GNU project (the distro) just called GNU. They want a different name, I think.
<tadni>I think it's a non-issue personally.
<civodul>hmm, ok
<taylanub>I don't think bremner was being all that serious with his remarks, though I can't tell.
<tadni>Conversation has since moved on, in #emacs regardless. So it must not be a /huge/ deal anyways.
*tadni looks for's website sourcecode.
<taylanub><bremner> I have to say, this "GNU distro" think is pretty irritating, namewise
<taylanub><bremner> I can't wait for rms to tell them they have to call it GNU/GNU
*tadni wants to play around a little with the idea of a
*taylanub breaks #emacs law of no public logging
<tadni>taylanub: Heathen!
<taylanub>and then he said "GNU is super-mega-confusing as a distro name." all I could find in my logs. I don't think anyone's seriously bothered or so, just a pet-peeve/annoyance...
<taylanub>I'd say people will just get used to it.
<civodul>, why not
<mst>get that retro chic going in the naming
<mst>I suspect what will happen is people will use 'guix' to refer to the tool *and* the OS
<tadni>mst: Yeah, I've seen that already.
<mst>I don't really have a dog in this race, mind, that just seems like the inevitable consequence of not giving it its own name
<taylanub>wasn't that the initial plan?
<mst>and honestly I thought this was 'guix, the GNU linux distro (and also the name of the main system management tool)'
<mst>no idea. I was interested in nix-with-scheme, not politics
<taylanub>at least, the page had a misleading sentence in that direction; I see it's been changed: "GNU Guix is a purely functional package manager for the GNU system distribution."
<mst>hence why I've downgraded myself to observer status; it was made very clear that if I didn't want to buy into the full political side contributions wouldn't be welcome
<taylanub>it used to be "and a distribution thereof" or so, implying the distro is called the same name as the PM
<mst>but I'm getting good ideas from you guys, so I occasionally try to share a few ideas back :)
<taylanub>.oO( "GNU system distribution" sounds a little awkward )
<mst>also, GNUSD sounds like a transliteration of a sneeze that went really, really wrong
<leth>GNU is not complete until it has a lisp based window system imho
<leth>well i do run stumpwm but i'm not sure that would count.
<leth>what i want is a lisp replacement of Xorg i guess,
<leth>i want to replace everything with a lisp verison i guess.
<tadni>leth: Guile-wm has expressed interest of porting to wayland, as well as writing a graphic toolkit for Emacs.
<tadni>I don't see the point of rewriting xorg in lisp, for several reasons.
<leth>well not really a rewrite of xorg in lisp, just something that could replace it.
<leth>a graphic toolkit for emacs might be interesting.
<tadni>leth: Well, assuming that we had a wayland compositor in guile, which guile-wm might deliver at some point -- you practically are replacing xorg with "lisp" in the fact that wayland is just a protocol.
<leth>i wouldn't mind that.