<brendyn>Anyone know how to run guix on OpenStack? <starikot>Hi, is this the channel for The Guix System Distribution? <starikot>Is this a new distribution developed by GNU? <starikot>I've read that Richard Stallman used/uses Trisquel GNU/Linux so I always thought that was GNU's own distribution. <mark_weaver>well, it depends on what you mean by "developed by GNU". It is perhaps more accurate to say that Guix is a GNU project. <mark_weaver>and GuixSD is one of the free distros listed by the FSF. <mark_weaver>Trisquel is more mature, since it is based on Ubuntu. GuixSD is newer. <starikot>There are some things that are confusing to me, so sorry if my questions seem stupid. <mark_weaver>it seems to me that these questions are mostly meaningless, and depend on one's definitions. <starikot>GNU was launched by Richard Stallman (rms) in 1983, as an operating system which would be put together by people working together for the freedom of all software users to control their computing. rms remains the Chief GNUisance today. <starikot>How can it be an operating system when the kernel (Linux) wasn't even made back then? <mark_weaver>there are videos and papers about Guix in the Help section <starikot>I wanted to try Trisquel when I heard about it, but I saw that it is very outdated. <ng0>savannah and mail list web interface server in *.gnu.org is down at the moment? <ng0>so i wanted to say, I saw the comments voicing concern and 'no' against the suckless.scm move just today <ng0>iÄm okay with this, and the new st update can be applied (it's in suckless.scm), and i'll update only the copyrights patch, as this adds back one copyright which was left when dwm.scm -> suckless.scm happened <ng0>can we discuss it here then? I see the point in gnome.scm to some degree, but not in suckless.scm <ng0>suckless as i understand it is a group and their close relatives which share the goal to produce small codebase software <ng0>having stagit in version-control.scm makes more sense than putting it into suckless.scm <ng0>it's hard to choose the right module when we have no set order on that. I agree that dmenu does not belong into wm.scm, but in wm.scm is already another menu application <ng0>would it be easier to define what goes where instead of just moving everything around every n months, and only move around after discussions on the general scheme of locations? <ng0>why are people in favor of suckless.scm? <janneke`>as more packages include their guix.scm to build it, this issue will resolve itself <mark_weaver>I don't have a strong opinion one way or the other about having suckless.scm, however I think we should avoid moving packages from one module to another unless there is a good reason to do so, because every time we move a package, we will break people's OS configs and/or profile manifests. <ng0>i agree with that point <ng0>i think we should include an additional item in the manual about moving modules. when you do it, you should respect copyrights. even if we do not split up suckless.scm, i'll have to add back some coyprights i found which were lost when dwm.scm because suckless.scm <efraim>I mostly try to keep to joining single files together, like c-ares in adns.scm since its similar to adns <efraim>And I was thinking about shells.scm for a while. Next is moving mc and some others into a file-manager.scm or something similar <efraim>I have vifm ready to submit, and I have to figure out what to do with ranger <janneke>where is the linux kernel configuration config-x.y.z file stored? <efraim>linux-libre-$(version)-$(arch).conf <janneke>ACTION was wondering if a_out was enabled: no, and whether he should enable it or bite the elf bullet <rekado>it is very rare in Guix to have the same (package) variable names in different modules. <rekado>in manifests and OS configurations users could import all package modules without any problems, no? <rekado>in that case they wouldn't be affected by us moving around variables. ***starikot_ is now known as starikot
<efraim>they would still need to change the modules imported <rekado>efraim: why? If we had a "super module" that simply re-exported all other modules? <efraim>ah, i missed the part where they could just import all the package modules <bavier>rekado: it was suggested at one point to encourage users to use the 'specification->package' in os configurations <kocio_>hello, I try to make a new package recipe, which requires substitution configure with running ./bootstrap.sh - what the code should look like? <kocio_>This code doesn't work - I made it following some other recipes: (arguments #:phases (modify-phases %standard-phases (replace 'configure' (lambda* (zero? (system* "./bootstrap.sh")))))) <kocio_>I'm not a programmer, let alone Guile programmer... <davexunit>kocio_: you probably don't want to replace the configure phase. <davexunit>usually when I see a ./bootstrap.sh script, it is something that generates the configure script <bavier>(add-before 'configure 'bootstrap ...) <efraim>so it would come after the 'unpack phase <davexunit>sometimes people write bootstrap scripts that also run configure <davexunit>because the configure script hasn't been patched yet <davexunit>kocio_: for now, try replacing "replace 'configure" with "add-after 'unpack 'bootstrap" <kocio_>what should be exact code snippet? like this?: (add-after 'unpack 'bootstrap (system* "./bootstrap.sh")) <efraim>(lambda _ (zero? (system* "./bootstrap.sh"))) <davexunit>kocio_: you need a procedure as the third argument <davexunit>'lambda' is the syntax for creating procedures <davexunit>(lambda _ ...) means "a procedure that accepts any number of arguments", effectively ignoring all of the arguments passed to it. <bavier>I think I figured out the kodi build failure <bavier>I think the fix is as easy as replacing "ffmpeg" with "ffmpeg-2.8" in the inputs <bavier>but during debugging I also upgraded to 16.1 <bavier>build is still going, but has already passed the problem point <davexunit>my partner just uses netflix and thinks we're going to get arrested for downloading a movie so my HTPC has fallen into disrepair <ng0>why was the font removed from st inputs? <bavier>davexunit: yeah, 3rd alpha out so far <bavier>the alpha release notes mention ffmpeg-3.1 support <bavier>but idk what their release schedule is like, and when they'll get to the stable release <mark_weaver>using an old ffmpeg makes me nervous, because it surely has published security flaws <mark_weaver>but using an 'alpha' version doesn't sound too good either. <bavier>the only other packages that still need ffmpeg-2.8 are blender and vlc <mark_weaver>I'm not too worried about blender, but vlc is a problem <mark_weaver>people will likely be using vlc on videos on files from potentially malicious sources <bavier>I'll check if that works with ffmpeg-3.1 <mark_weaver>wgreenhouse: I would expect it to work, because grub is the relevant component and we're using a new grub (2.02~beta3), but I cannot confirm. <mark_weaver>I've seen some newcomers report problems with that because they forgot to create the required partition, and grub complained. I pointed them to the problem and didn't hear back one way or the other. <mark_weaver>if you try, please let us know how it went, one way or the other <wgreenhouse>mark_weaver: thanks; will test and report. aiui grub would have to know to copy relevant bits of itself to the UEFI system partition; wasn't sure if there was a guix system configuration syntax for that <mark_weaver>grub-install seems to try to do exactly that, and even reports failure if the system partition doesn't exist (leading to new users asking questions here about it), so I take that as a good sign. <mark_weaver>afaik, there's nothing special to do in the GuixSD OS config for this. <mark_weaver>but I don't have any UEFI systems myself, so I'm making educated guesses here <wgreenhouse>ah, okay, so grub-install itself includes the logic for noticing we're on a uefi system <mark_weaver>grub-install is run as the last non-trivial step of "guix system init" <wgreenhouse>mark_weaver: that's cool! I guess part of my brain is still wired for lilo <bavier>can someone summarize the "package metadata" thread on the ML? <bavier>I was going to reply at some point, and then it blew up <mark_weaver>it would be better to just skim the messages, I think. that's a pot better left unstirred <bavier>ok, read up now. I see what you mean <jlicht>still one of the most civil escalating ML thread I've read ;-) <lfam>Did anybody receive my message to guix-devel about the aircrack-ng patch? It seems to have made it to the guix-devel archives, but I got a message back about SPF problems. So I'd like to know if *anyone* got it :) <sneek>Welcome back lfam, you have 1 message. <sneek>lfam, jlicht says: thanks for reacting so quickly to the jq fix :) <lfam>sneek: later tell jlicht: Those are very important patches. Thank you for sending it! Keep paying attention :) <rekado>idea: run the daemon as a regular user and shell out to setuid helper that spawns the chroot. <rekado>functionally, there’s little difference to what we do now, but psychologically admins would no longer need to fear a root daemon. <myglc2>rekado: remember the discussion a few days ago about gnus/notmuch/mailmain/gmane? <catern>rekado: ugh... that would be worse than having a daemon...