IRC channel logs

2019-12-10.log

back to list of logs

***jonsger1 is now known as jonsger
<civodul>cbaines: re finding the commit that introduced a regression, sure, sounds good
<civodul>hey mjw!
<civodul>the CPATH vs. C_INCLUDE_PATH is a long (and sad) story
<civodul>gcc.scm mentions <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70129>
<mjw>civodul, can I read the story somewhere?
*civodul looks
<mjw>civodul, right, I see that gcc bugzilla, but if I set C_INCLUDE_PATH instead of CPATH everything works and I cannot replicate any issue
<mjw>and with CPATH set the guix gcc is basically unusable
*mjw loves -Werror for everything
<civodul>mjw: https://issues.guix.gnu.org/issue/30756 has the details
<mjw>ah, cool issues.guix.gnu.org works again
<civodul>yeah i had to kick it, not great!
<Blackbeard[m]>Guix is sq great (:
<Blackbeard[m]>I enjoy using it so much
<mjw>civodul, that is a long bug, but I still don't understand the issue. Is it cmake specific? (/me obviously uses autotools)
<mjw>What is the solution for those who want the system headers really being recognized as system headers?
<mjw>Without that building almost anything causes spurious warnings and makes all my nice -Werror projects very sad.
*civodul nods
<civodul>mjw: IIRC, the problem is that Guix ends up putting libc at the beginning of the search path
<civodul>and actually puts it twice
<civodul>that, in turn, breaks #include_next
<civodul>something like that
<civodul>so the fix would be to arrange for libc to appear at the bottom of the search path, like Mark H Weaver wrote there
<mjw>hmmm, so why am I not seeing that issue if I simply use export C_INCLUDE_PATH=$CPATH; unset CPATH ?
<civodul>well, from what i understand right now
<civodul>mjw: good question; could it be that PureOS headers from /usr are picked up?
<mjw>I mean, I could use that as a workaround for now in my personal profile, but I am sure I would trip over it every time I setup guix from fresh
<civodul>i'd recommend testing in "guix environment -C", to avoid interferences
<mjw>ah, that was indeed my next learning thing... what are these environment things :)
<civodul>heh :-)
<civodul>it's just about creating a profile "on the fly"
<civodul>"guix environment --ad-hoc gcc-toolchain coreutils -C" spawns a shell in a container
*mjw has to admit it took him a day to figure out what goes where. If you happily follow the guide put everything you think you need in your .bashrc you get very puzzling results.
<civodul>and in that container, there's nothing but the toolchain and coreutils
<mjw>apparently it is common knowledge that you have to put all this special goo into your .profile file instead... :}
<civodul>mjw: i guess we'd happily take your newcomer's feedback to see what needs to be improved/fixed!
<civodul>ah yes, .bashrc vs. .profile is a common "mistake"
*civodul -> zZz
<civodul>i'll read about your adventures tomorrow :-)
<civodul>good night!
<mjw>No! Wait, what it "the guix way" to pull the manual, update, build and submit an issue?
<mjw>Specifically, I would want to submit a change for https://guix.gnu.org/manual/en/html_node/Application-Setup.html where how would I get and update that?
<nckx>Blackbeard[m]: 🙂 Digit: same, but ‘pity [Guix] doesnt want to get hijacked by bedrock’ sounds like slang for *something* (probably illegal), and it doesn't sound good.
<mjw>OK, maybe getting some sleep first would be a good idea.
<nckx>sneek later tell mjw: Nooo, don't go… OK, too late. You'd git clone https://git.savannah.gnu.org/cgit/guix.git, then edit doc/guix.texi and commit your change, then git send-email it to guix-patches at gnu.org.
<sneek>Will do.
***ChanServ sets mode: +o nckx
***nckx changes topic to 'GNU Guix | 1.0.1 is out! get it at https://guix.gnu.org | videos: https://guix.gnu.org/blog/tags/talks/ | bugs & patches: https://issues.guix.gnu.org | paste: https://paste.debian.net | Guix in high-performance computing: https://hpc.guix.info | This channel's logged: http://logs.guix.gnu.org'
***ChanServ sets mode: -o nckx
<Blackbeard[m]>nckx: I don't know what is that about :/
<dftxbs3e>hey how would you delete a configure flag when inheriting a package?
<efraim>using alist-delete. best bet is to git grep for ((#:configure-flags
<dftxbs3e>I ended up using 'delete'
<dftxbs3e>But I'm too clueless about Scheme and GNU Guix
<dftxbs3e>Seriously I give up on this.
<dftxbs3e>And I cannot spin up the appropriate debugging environments because GNU Guix is not fully bootstrapped..
<oriansj>dftxbs3e: no distro is fully bootstrapped
<dftxbs3e>I mean, I can't use guix environment -C
<dftxbs3e>because the required packages don't build, it's what I'm trying to fix..
<oriansj>dftxbs3e: does the guix binary not run with the required permissions?
<dftxbs3e>the guix binary is fine
<dftxbs3e>GNU Hello doesnt build
<dftxbs3e>on POWER9
<oriansj>but it builds fine when you do guix build hello ?
<dftxbs3e>The current problem is that libstdc++ basename and others definitions conflict with glibc's ones
<dftxbs3e>oriansj, no it doesnt build at all
<oriansj>dftxbs3e: and does mescc-tools build without issue?
<dftxbs3e>mescc is not used on POWER9
<oriansj>dftxbs3e: but it is the most trivial to build package
<dftxbs3e>Then it probably builds, I'm giving it a try right now
<dftxbs3e>ugh no it wont build I think, it depends on non-bootstrap gcc, correct?
<dftxbs3e>no it doesnt build, it fails on the same error as GNU Hello
<oriansj>dftxbs3e: no it is actually at a level below the bootstrap gcc (as it is used to bootstrap gcc), so it should be leveraging the bootstrap gcc
<oriansj>in theory any working C compiler will work
<oriansj>as it depends on ZERO libc functions and only leverages a handful of kernel syscalls
<dftxbs3e>oriansj, it tries to build another gcc from the bootstrap gcc if you try to 'guix build mescc-tools'
<dftxbs3e>and that's what fails
<dftxbs3e>even if mescc-tools doesnt need it, it's how it's defined in GNU Guix
<oriansj>dftxbs3e: well it defaults to (build-system gnu-build-system)
<dftxbs3e>that might be why
<dftxbs3e>oriansj, do you want to give a hand on this?
<dftxbs3e>There's two issues that overlap
<dftxbs3e>The bootstrap gcc-7 can't build gcc-7's libstdc++ because it doesnt support some C++ features that this version of libstdc++ needs
<dftxbs3e>So the current workaround is to use gcc-4.9.4's libstdc++
<dftxbs3e>But the long double format between gcc-4.9.4 and gcc-7 has changed for POWER9 LE
<dftxbs3e>in gcc-6.2 exactly
<dftxbs3e>so objects can't be linked together....
<efraim>does libstdc++-boot0 build with gcc-6?
<dftxbs3e>efraim, it inherits the same problem somehow, I tried it already, let me try again.. I changed few things since
<dftxbs3e>nope, doesmt work
<dftxbs3e>doesnt *
<str1ngs>hmmf I have a package that I want to copy to my publish server. though I've export and imported it. it still want to build the packaeg on the publish server. the guix describe hashes are the same. and the package file hash is the same. how do I figure out why it wants to build the package? and not use the imported path?
<dftxbs3e>efraim, oriansj: is it possible to create an environment container for a private package?
<efraim>you want the -e flag
<efraim>to build it it would be guix build -e '(@@ (gnu packages commencement) libstdc++-boot0)'
<efraim>i assume it works also for environment
<dftxbs3e>cool ! thanks
<dftxbs3e>efraim, one issue I met is that intermediate inputs that get built don't have the 'environment-variables' file in their kept build directory
<dftxbs3e>I wonder if that's going to solve it, one is running now
<dftxbs3e>and by the way, it doesnt work with environment
<dftxbs3e>because it wont create the environment for something that fails to build
<dftxbs3e>well that didnt work, it still didnt create the environment-variables file...
<dftxbs3e>wonderful, I still can't reproduce the exact environment to start hacking in it ....... I'm done here I think.
<alextee[m]>help, i borkedmy system
<alextee[m]>it loads in grub rescue mode and it'slooking for i386-pc/normal.mod
<alextee[m]>but im using EFI so i can only find x86_64 in my boot directory
<g_bor[m]>hello guix!
<g_bor[m]>GSoC 2020 has just been announced.
<g_bor[m]>We also know by now that Outreachy initial applications for the next round are starting on January 22.
<g_bor[m]>For GSoC the student application period start on March 16.
<nixo_>alextee: do you have a distro on an USB?
<nomad1>hi
<pat_h>Hello, is there any Guix equivalent to Nix's 'nix-serve' (docs here: https://nixos.org/nix/manual/#sec-sharing-packages)? I know there is 'offload' for Guix, but I am looking for something that is closer to setting up one machine to pull substitutes/binaries from another guix machine on the same network.
<pat_h>That link may get recognized improperly, here it is again: Hello, is there any Guix equivalent to Nix's 'nix-serve' (docs here: https://nixos.org/nix/manual/#sec-sharing-packages)? I know there is 'offload' for Guix, but I am looking for something that is closer to setting up one machine to pull substitutes/binaries from another guix machine on the
<pat_h>same network.
<pat_h>Sorry I'm new to IRC :/, here is the link: https://nixos.org/nix/manual/#sec-sharing-packages
<g_bor[m]>pat_h: you might be looking for guix publish
<pat_h>g_bor[m]: Ah, yes that looks like exactly what I wanted, not sure how I missed that. Thanks so much!
<civodul>Hello Guix!
<zig>o/
<g_bor[m]>hello guix!
<janneke>hello g_bor[m]!
<g_bor[m]>civodul: GSoC 2020 is now announced. Also Outreachy initial applications start on January 22nd.
<g_bor[m]>Do you think we should promote these opportunities?
<g_bor[m]>I believe in the last round we were a bit late to the party.
<civodul>hi g_bor[m]!
<g_bor[m]>janneke: howdy
<civodul>sure!
<civodul>for Outreachy i guess we have to wait for GNU to be accepted as an org, right?
<civodul>er, for GSoC
<civodul>but for Outreachy, we must do better than last time
<civodul>i guess we were too late and did not communicate enough
<civodul>WDYT?
<g_bor[m]>civodul: I believe we can announce our intention to participate, and showcase the project ideas, so that potential applicants know what to expect, and post an update when the participation becomes official.
<g_bor[m]>Does that make sense?
<civodul>g_bor[m]: yes, it makes sense to me
<civodul>would you like to spearhead that again, and if so, what help do you need?
<g_bor[m]>Actually the approach taken by the two organizers are now completely the opposite of one another. Outreachy expects the students first, with barely any infromation about the perspective projects, while for GSoC they expect the project ideas first, and later come the students, with all the project possibilities at hand.
<g_bor[m]>civodul: yes, I will prepare a blogpost about our intention to participate. Do we have any other forums we should promote this?
<g_bor[m]>Also, we are handling everything for Outreachy, but I believe I should contact the GNU GSoC group regarding GSoC.
<civodul>g_bor[m]: in the case of GSoC, i guess we cannot promote anything until we have a list of projects + mentors, right?
<g_bor[m]>civodul: I also believe so.
<civodul>in the case of Outreachy, it seems weird to say "we're participating" if we're not putting some projects on display, but maybe that's how it's supposed to work?
<g_bor[m]>civodul: I think that this system is very new, and there are some communication curlpits. The main thing is that by the time the projects are announced the initial application period is already closed. We should communicate something like 'if you think a project will fit you, then you should fill in the initial application form. If it turns out that there is no appropriate project, then you don't need to go further with
<g_bor[m]>that...'
<g_bor[m]>I don't know how to express it really properly, but I will try my best.
<civodul>ok, sounds good
<civodul>we need to make sure to provide links to the right bits of info (eligibility, deadlines, etc.)
<g_bor[m]>One thing I will need assistance with is to determine what earlier proposals are actually completed by now.
<civodul>completed in what sense?
<civodul>i guess you could share the plan on guix-devel anyhow, and take it as an opportunity to ask for help
<g_bor[m]>I mean we developed it already, independent of an internship.
<civodul>ah
<civodul>the Data Service i18n was not implemented, for one
<civodul>then there was a proposal by roptat IIRC, what was it again?
<g_bor[m]>it was netlink support.
<g_bor[m]>That is also on my list.
<g_bor[m]>And also installer i18n
<g_bor[m]>no, sorry, installer accessibility
<g_bor[m]>I believe that was your proposal.
<g_bor[m]>I will be back soon.
<g_bor[m]>I will collect the proposals we had, and send a mail to guix-devel
*g_bor[m] going to the dentist
<civodul>alright, thanks g_bor[m]!
<civodul>and take care of your teeth ;-)
<nixo_>Who's coming to FOSDEM 2020? I still need to book my flight
*civodul is going!
<civodul>nixo_: make sure to come to the Guix Days, too :-)
<civodul> https://libreplanet.org/wiki/Group:Guix/FOSDEM2020
<nixo_>civodul: Cool! Sure ^^
<civodul>yay!
<alextee[m]>nixo_: yes thanks! i reinstalled guix
<alextee[m]>all my stuff is back :)
<nixo_>alextee: great!
<civodul>janneke: i just realized that Gash doesn't provide /bin/sh, how come?! :-)
<nomad1>does Guix Systems support ZFS ?
<civodul>nope
<nomad1>ouch
<nckx>The ZFS licence is incompatible with the GPL.
<nckx>nixo_: I'm coming 🙂
<nixo_>nomad1: but we have btrfs, that according to the name should be better ;)
*nckx just built their first Guix bcachefs kernel but still needs to boot into it. Such future!
<leoprikler>talking about that, can we get "quick rebooting" features such as kexec into guix/shepherd?
<efraim>I thought for ZFS we could include it but c[11:02:50] <nomad1> efraim:subtitues ?
<nixo_>namad1: pre-compiled cache?
<efraim>binary substitutes, it would need to be built on the machine which was going to use it
<nixo_> https://guix.gnu.org/manual/en/html_node/Substitutes.html
<leoprikler>are non-substitutable packages really something mainline guix should distribute?
<efraim>it's free software. the issue is license compatibility
<nckx>efraim: Yes, that's an option. The GPL covers redistribution but not use, ‘users’ can combine whatever they want.
<efraim>nothing prevents someone from building ffmpeg with openssl, but if they made such a package they'd be unallowed to redistribute it
<leoprikler>is ffmpeg + openssl generally not redistributable, or is it rather a specific flavour of openssl that is not?
<efraim>IIRC its a combo of the gpl2 + openssl license
<kirisime>Hello guix, what can I do to find out why bluetooth doesn't show up in GNOME settings panel?
<leoprikler>you mean the option does not exist or it does not have meaningful values?
<kirisime>leoprikler: "No bluetooth found"
<kirisime>I have the bluetooth service added and it shows up in herd status, it's set to auto-enable and rfkill lists the devices as unblocked, and my user is in the lp group.
<leoprikler>you can try debugging gnome-settings-daemon, but it's probably missing bluez or something like that
<leoprikler>(as an input)
<leoprikler>compare to bluetoothctl command line, which should work
<kirisime>Now, where do I get bluetoothctl...
<leoprikler>bluez package
<kirisime>My root profile has something called "bluetooth" in its PATH but when run it just says "unknown device type .bluetooth-real"
<lurch>leoprikler, ffmpeg is available, and there's libressl which is openssl in better
<leoprikler>but it's not used by ffmpeg, is it?
<ng0>if you believe libressl is openssl in better than you have to think beyond libressl presentations.
<ng0>the licensing stays the same
<efraim>leoprikler: it's not, it was just an example
<efraim>lurch: ^
<lurch>ng0, so you think there is no improvement from openssl to libressl?
<ng0>different goals + the usual NIH from openbsd + more funding insecurity
<ng0>i didn't write "no improvements"
<kirisime>Looks like I need firmware, thanks anyhow leoprikler
<ng0>i guess you were as generalizing as i was, discussing libressl details isn't that important to me. some ports I don't get (guilty of working on some myself, but just out of curiosity), like a portable openbsd nc which is now packaged for guix
<leoprikler>bluetoothctl tells you that?
<kirisime>It's a broadcom module from a decade ago. Since the wireless needed firmware as well I think it's a safe bet even without checking the model number against some list of unsupported devices.
<leoprikler>fair enough
<leoprikler>just warning you ahead: even if you get it to work, GNOME will probably not show it (but bluetoothctl will)
<kirisime>Bluetoothctl lists a MAC address for it, though.
<kirisime>I'm not sure how this works.
<leoprikler>can you connect something?
<leoprikler>(or before connecting pair it first)
<kirisime>Well, it did connect.
<kirisime>GNOME even gave me a popup window...
<kirisime>And there's a status icon, but still "No bluetooth found"
<leoprikler>again, that's probably on gnome-settings-daemon
***sirmacik_ is now known as sirmacik
<kirisime>I'm on a guix version from more than a month ago, is there a chance that it'll work in a newer one?
<kirisime>I know colord (and night light) were fixed in a version newer than this.
<leoprikler>Currently not AFAIK, but it may get fixed sometime™
<leoprikler>might be worth a bug report (i don't know if one exists yet)
<kirisime>I tried sending a file to my phone and got this error: "the name org.bluez.obex was not provided by any .service files"
<kirisime>How does GUIX handle these mysterious .service files? I get a lot of little errors about them.
<kirisime>The org.bluez.obex.service is in the output of the bluez package but not in my or the system profiles.
<nckx>sneek: later tell kirisime: Can't speak from experience, but (guix)Desktop Services in the manual explains one way to use these files with Guix.
<sneek>Will do.
<jyscao>When I do "info guix", the info page shows up for me in Spanish not English. Any idea on what the cause is? My system locale is set as "LANG=en_US.UTF-8" if that's relevant.
<nixo_>Hi again, this problem [https://debbugs.gnu.org/db/33/33105.html] just verified for me (manually chmodding the folder worked). I'm in the lp group
<nckx>On my print server it's drwxrwx--T 1 root lp 0 Dec 10 12:07 /var/spool/cups/tmp/
<nckx>Does that mean I manually chmod'd it long ago? Strange.
<nckx>Exact same perms on my laptop so I doubt it.
<nckx>kirisime: Did that work?
<nckx>jyscao: What does ‘info -w guix’ print?
<nckx>All previous complaints about ‘info’ were that it *doesn't* respect locales, so this is odd.
<Parra>does Guix bundle with X11? I may have found another bug in Ruby
<Parra>ruby builds without tk because it cannot find x11, is this behavior desired?
<roptat>jyscao, are you on a foreign distribution? what package does info come from?
<jyscao>roptat: I'm using Fedora 29
<roptat>mh... that's what I'm using too, and I get the English manual, even with my fr locale (which is expected, info doesn't support i18n)
<roptat>the other languages are supposed to be separate info files (there's guix.info for the English version, guix.fr.info fro the French version, guix.de.info for German, etc)
<roptat>so "info guix" should open guix.info, but I remember a discussion where it appeared that older versions of info / other implementations simply dropped the file names at the first dot (to support guix.info.gz for instance) instead of at the last dot
<roptat>which means that guix.es.info is mapped to the info manual for guix, as well as guix.info, guix.fr.info etc
<roptat>but you should have a recent enough info reader...
<jyscao>roptat, great thanks, info guix.info gave me the english
<roptat>cool :)
<nckx>Parra: Guix shouldn't bundle anything 😉 There isn't really such a thing as ‘X11’, you should find out which library (I mean, it could be libX11 but that's often not enough) Ruby tests for, and make sure it's an input.
<Parra>I mean, Ruby isn't building tk which is a graphic UI library, because it depends on libx11 and it isn't present, this is a bug? because python and Ruby both use tk
<Parra>this is how it's working right now on the current ruby package in guix master
<Parra>so ruby build is incomplete, all gems depending on tk wont work
<leoprikler>python does have a tk output, though
<leoprikler>so perhaps we would have to do the same for ruby?
<Parra>roptat: and yes, ruby does not include x11 as input, neither tk
<Parra>let me.check python
<roptat>mh? did I say anything?
<Parra>python does
<Parra>python build is much more complete than ruby..
<roptat>probably nobody worked too hard on this
<Parra>I understand
<nckx>Parra: It's more a feature request than a bug, but somewhere in between.
<Parra>I can submit another bug
<roptat>or maybe there's a separate package for ruby-tk?
<nckx>Parra: Did you mean me?
<Parra>yes, sorry haha
<Parra>it's just adding proper inputs so ruby can be built completely
<Parra>as it will trigger a huge build, and since it isn't dyn linked (as the bug I submitted recently) I'm just inheriting from it and solving this by myself
<Parra>but it would be good if it is patched on master soon
<nckx>Parra: You can try adding the required inputs yourself, then look at ‘guix size ruby’ before & after to see whether it should be separated into an output/package.
<Parra>I don't understand what you mean by separated into an output package
<nckx>*output or package, then.
<nckx>If it adds more than a few % in size and can be cleanly separated from the main ruby package, we could for example add a ruby:tk output as is done for python.
<Parra>also ruby needs ncurses
<Parra>and python too
<nckx>Define ‘needs’.
<Parra>you go to the git repo in github, and it explicitly says the dependencies the runtime needs to build properly
<Parra>that means "needs" to me in this context
<Parra>otherwise the runtime is not complete
<Parra>and some packages wont work on it
<nckx>Lots of projects list all possible dependencies. But if it rules out building dependent packages they should be added. Guix doesn't tend to be minimalist in such cases, the opposite even.
<Parra>libyaml is also needed
<Parra>is it available in guix?
<Parra>how can I check that
<leoprikler>guix search yaml
<Parra>ty
<Parra>it is not packaged as standalone library
<Parra>it is packaged by means of other packages
<nckx>Parra: Yes it is?
<Parra>perl-yaml-libyaml
<Parra>python2-pyyaml
<nckx>web.scm, libyaml.
<nckx>2 versions even 🙂
<Parra>oh yes, sorry
<Parra>thanks
<Parra>after I finish this I will try to submit a package
<Parra>a patch*
<nckx>Thanks.
<PurpleSym>Does `guix environment --with-graft` not alter dependencies of manifests (via -m)?
<civodul>PurpleSym: it should alter them
<PurpleSym>civodul: Hm, that is strange. It works with `guix envirenment --with-graft=foo=bar --ad-hoc some-package`. Let me double check, maybe I’m missing something.
*jonsger hopes he can make it for the Guix days and FOSEM :)
<civodul>jonsger: would be nice!
<civodul>we met one of your colleagues at the R-B Summit BTW (Bernard) :-)
<jonsger>problem is I have oral examinations somewhere in January or February and I only know the date two weeks before
<jmercouris>hi guys, are guile questions tolerated int his channel? I'm trying to compile guile-lib
<jonsger>civodul: oh he was there. Nice :)
<jmercouris>OK, I'm going to assume it is OK then :-D
<wingo>the r-b summit location & venue looked amazing
<jmercouris>here is what happens: http://dpaste.com/2Q7GXRH
<jonsger>jmercouris: there is also a #guile chat on freenode
<jmercouris>I've put the output of ./configure and make on there, it happens when trying to compile any library
<jmercouris>no matter what happens I always get: ice-9/boot-9.scm:752:25: In procedure dispatch-exception: no code for module (unit-test)
<jmercouris>I have no idea where to begin with debugging this, so any guidance would be greatly appreciated
<jmercouris>jonsger: thank you, I'll post there too
<jonsger>jmercouris: why are you don't using "guix environment guile-lib"?
<jmercouris>jonsger: I'm on macOS
<nixo_>gnunet is failing to build 0.11.8 (broken tests, can't find some .conf gile)
<nixo_>*file
***ng0_ is now known as ng0
<snape>Hi, http://logs.guix.gnu.org/guix returns 504
<nixo_>Hi :( emacs is not finding ess. I see that I still have the folder ~/.guix-profile/share/emacs/site-lisp/guix.d with ess and ledger inside
<rekado>log viewer is back
<rekado>nixo_: I guess ESS (and all other packages that happen to provide Emacs modes) needs to be adjusted to comply with the changes to the Emacs environment variable settings.
<rekado>nixo_: could you please submit a bug report?
<nixo_>rekado: yes, I'm replying to an old patch I sent where I upgraded ess to 18.10.2
<nixo_>It was ugly, but maybe now that we are fixing it we can take the time to upgrade
<bavier>nixo_: gnunet just built alright for me at commit 92a0c3e
<dustyweb>civodul: str1ngs: definitely wasn't me but that looks very interesting
<nixo_>bavier: I'm on ba7fed8ec4. I'll try again, else I'll need to bisect
<str1ngs>dustyweb: what looks instresting?
<dustyweb> https://radicle.xyz/
<bavier>nixo_: that'd be great, thanks
<str1ngs>dustyweb: oh yes, I was thinking of swithing one of my project to it. to see how the workflow is
<str1ngs>dustyweb: I think civodul was looking for a guix package for radicle which I havnt found the time for yet :(
<nckx>‘inside the Linux kernel’ → ‘inside the kernel Linux’?
<nckx>Help me with my gnuspeak.
<bdju>First one, but remove "kernel" because it is the kernel is what I'd think.
<bdju>Although the first one as-is has the benefit of being unambiguous.
<bdju>Similar to saying "6AM" even if you use 24 hour time normally because "6 o'clock" is more ambiguous than "18 o'clock" among mixed company.
<nckx>I think ‘just Linux’ is the worst of both worlds TBH.
<nckx>bdju: Heh. No religious wars about that… I hope?
<nckx>Hm, grep -r 'kernel Linux' * | wc -l → 95, grep -r 'Linux kernel' * | wc -l → 556. I'm a bit surprised.
<nckx>Welp, since it's an existing package I'll stick to the status quo ‘Linux kernel’ just jumped out at me. Thanks for answering, bdju!
<jonsger>"Linux kernel" feels more natural to me :)
<nixo_>nckx: instead "Linux the kernel" will match "Stallman"
<bavier>nckx: I would have expected to see more occurences of the first
<bdju>Well, if Linux to you is just the kernel, calling it "Linux" seems to make sense. It just has the risk of meaning different things to different people then.
<nckx>jonsger: Sure, but that's a different discussion.
<nckx>bavier: Same.
<nckx>bdju: In an FSF-perfect world they'd prolly be fine with that.
<nckx>…and Wikipedia wouldn't be a hive of extremist ‘Linux’ propaganda, I see they've been butchering the Guix page again. Sigh.
<nixo_>bavier: yep, my revision failed again. Trying with yours, and then I hope "git bisect run guix time-machine --commit=$(cat .git/HEAD) -- build gnunet" will do everything for me
<bavier>it'd be nice to remove the plethora of references to Nix on that page
<bavier>just read through https://distrowatch.com/weekly.php?issue=20190624#guixsd, kinda curious what all these issues the person ran into are
<bavier>some are not limitations, I suppose, like DE applications list refresh
<bavier>but they mentioned applications "disappearing from their path" after using 'guix install ...'
<bavier>"the manual page simply refers us to the Info page" so I have no access to documentation at all :P
<ng0>i would just ignore distrowatch
<ng0>ah, i didn't know there were also stories/tests on dw
<nixo_>bavier: I had he's same problem with 'guix package -u', where the problem probably is he is using "the wrong guix", the same applies for the 'guix install icecat' missing
<bavier>nixo_: oh, the 'hash' issue, right
<bavier>but they'd "reappear" later, after starting a new shell presumably
<bavier>ng0: and anonymous reviews
<bavier>ng0: I've usually ignored it in the past, I just hope most other people do too.
<bavier>I want to like it, I guess
<smithras>it sounds like he just tried 'guix --help' without realizing that there was a 'guix package --help'
<nixo_>half of his problems can be explained by the hash thing. the icon problem is different and as I'm not using a DE I don't know if it can be fixed easily. The slowness, I don't know, as I'm used to it (and I think it became faster in the last year, and this review is 6 months old)
<nixo_>bavier: ok your commit worked (and it took 55 minutes for my computer to build it...). I hope the git bisect will catch it fast
<bavier>nixo_: I hope it's not too many steps
<nixo_>git said it's ~4
<alextee[m]>how do you force a newly installed package to go in /run/current-system?
<alextee[m]>i just installed ffmpeg but there's no libavcodec in current-system
<alextee[m]>i can see it in the ffmpeg's store though
<nixo_>alextee: I think packages under current-system are those inside your 'config' .scm operating-system -> package field
<nixo_>alextee: Do you want it installed by root for all users, or you need it in your user profile?
<alextee[m]>nixo_: er, either is fine
<alextee[m]>i dont have ffmpeg in config.scm but i installed it for my user
<alextee[m]>it doesn't get found when i run meson though
<nixo_>if you want to compile things, you need to be in an environment
<alextee[m]>really? i never had to do this before
<nixo_>the command is "guix environment --ad-hoc ffmpeg meson ...."
<alextee[m]>doesnt the current profile have everything installed?
<alextee[m]>but maybe it's more "correct" to be in an environment
<nixo_>I think not all environment variables are set when you just install it in the profile
<valignatev>Hey! Couple days ago I had a problem with guix failing to find locales. The weirdest thing was that guix-daemon didn't have any problems with locals while user's guix couldn't find them and warned me with "failed to install locales" every time. roptat was kind enough to explain to me how guix and guix-daemon relate and how locales work with guix: e
<valignatev>.g. their relation to glibc and user profiles. It really got me to the right direction and I've solved my problem finally, yay!
<valignatev>The problem was that I'm using fish shell really, and GUIX_LOCPATH wasn't set as a global environment variable, it was set as a universal shell variable, and they are a different things in fish. Basically, "universal shell variables" don't get exported to the child processes. In order to make them so, one have to "set -Ux GUIX_LOCPATH $HOME/whateve
<valignatev>r" instead of just "set -U"
<valignatev>It all snapped when I was digging deep and opened "guix" executable in the text editor which is just a little scheme script that reads GUIX_LOCPATH and adds to a guile load paths. Then I've tried (getenv "GUIX_LOCPATH") in the giule repl which returned #f, I've tried (getenv "PATH") which returned correct PATH, and I figured out the something _fish
<valignatev>y_ is going on.
<valignatev>roptat: So yeah, thanks one more time, your explanation was really helpful. I've also found out that fish package definition in guix itself is installed in such a way that it reads /etc/profile and potentially obtains GUIX_PROFILE and GUIX_LOCPATH from there, so I'll try to replace my Arch fish with the fish from Guix and see how it goes. But even
<valignatev>now it works well
<valignatev>keywords for future log searches: fish shell GUIX_LOCPATH environment GUIX_PROFILE locale
<dftxbs3e>hello, did the 'environment-variables' file for failed builds disappear in core-updates?
<brettgilio>Hey, all. How is the day going?
<brettgilio>Just wanted to let you all know, I might be away for a few days. My wife and I are expecting our first child to be born any hour/day now.
<valignatev>brettgilio: Whoa my congratulations!
<brettgilio>valignatev: thank you! :)
<brettgilio>We will raise him in the spirit of the GNU. Haha
<dftxbs3e>:-) -- Congratulations as well!
<valignatev>GNU/child
<lurch_>what you're refeferencing to as child is in fact Brett/Child, congrats dude
<nckx>brettgilio: Oh! Congratulations!
<bavier>brettgilio: awesome, congrats and good luck!
<brettgilio>Thanks all. On my way to the hospital now. They sent us home yesterday, so hopefully today is the real deal.
<lurch_>already decided on a name?
<str1ngs>(map give-cigars (all-users))
<nixo_>valignatev: It's not GNU/child. Is GNU+child
<roptat>bavier: we already read that article, and we suppose they tried to run multiple guix install in parallel, one being much slower than the other
<roptat>That issue shouldn't happen anymore, since we are now locking profiles when operating on them
<bavier>roptat: ok, good to know it's generated discussion before
<roptat> This one was kinl of obvious to fix :)
<brettgilio_>@lurch_ Matteo
<lispmacs>hi, I installed guix on another x86-64 machine, using the 1.0.1 installation image. First thing I did is try to run guix pull, but am getting error "The SSL certificate is invalid".
<roptat>lispmacs: have you checked your clock? And set SSL_*, as per the manual?
<lispmacs>roptat: no and no
<roptat>Then you should :)
<roptat>Oh, is that a guix system, or a foreign distro?
<lispmacs>roptat: hmm, time appears to be off by 1.5 years into the past
<roptat>Ok, then you should fix that, because your computer thinks the certificate is not yet valid :)
<lispmacs>roptat: now, whose dumb idea was that
<lispmacs>ssl certificates should be backwards compatible with broken computer clocks
<roptat>Btw, don't set SSL_* on the guix system, it's done for you
<lispmacs>next thing you'll tell me is that I can't use expired certs either
<lispmacs>err, well, I guess I could on this computer
<alextee[m]>does guix have any sort of binary packages you can make?
<alextee[m]>er, or even source packages as separate files
<alextee[m]>or is it just the package declaration?
<alextee[m]>like on arch, you have a PKGBUILD and you can produce binary packages pkg.tar.xz
<roptat>You can declare a package in a separate file, or even create your own channel
<alextee[m]>that's still just a declaration though
<bavier>alextee[m]: are you thinking 'guix archive' or 'guix pack'?
<alextee[m]>it has to fetch the sources for example, or maybe you can specify a local file and zip/tar that all together or something
<roptat>Right, we do everything by declaration
<roptat>You can specify the working directory as the source
<alextee[m]>bavier: aaahhh right, yeah, that's what im looking for
<alextee[m]>thanks!
<alextee[m]>guix archive
***jonsger1 is now known as jonsger
<brettgilio_>Wife is getting admitted for labor. Wish us luck!
<bavier>brettgilio_: w00t!
<janneke>brettgilio_: you will do fine!
<bavier>any good way to debug svg icons not showing up in a gtk+ application?
<leoprikler>bavier: which icons exactly?
<bavier>leoprikler: I'm working on a package for the midori browser. In the "About" dialog, the logo is shown as just an "X"
<bavier>not super important for sure, but makes me wonder whether other icons are missing
<leoprikler>the midori logo, I assume?
<bavier>leoprikler: right
<leoprikler>I think, this is because Guix does not add app logos to hicolor as other distros would.
<leoprikler>Do you run this from an environment or from the guix build directory directly?
<bavier>from the store directly
<bavier>I'm wondering now if this is a gresource issue
<leoprikler>I don't think app icons are usually packaged in the gresource
<bavier>leoprikler: midori seems to :)
<bavier>I see "data/log-shade.svg" in it's gresource.xml
<leoprikler>is log-shade.svg the file in question?
<bavier>well, actually, it might be the .ico file.
<bavier>ui/about.ui has '<property name="logo-icon-name">midori</property>'
<bavier>I'm mostly guessing though, I don't have much experience with gtk
<leoprikler>would you be willing to share your temporary package definition?
<leoprikler>otherwise just point me at the git commit you're trying to package and I'll try reasoning about the source
<bavier>leoprikler: for sure: https://notabug.org/bavier/guix-bavier/src/wip-midori/bavier/packages/web-browsers.scm
<johnjay>has anybody successfully installed the latest guix 64 into the latest virtualbox (6.0.14)?
<johnjay>i tried it with option Linux 64 (Other) and it immediately freezes
<leoprikler>as far as the crash is concerned, I would report that behaviour to upstream, but leave configuration to the user for now
<mbakke>johnjay: do you mean virtualbox freezes, or the Guix installer?
<johnjay>the latter
<johnjay>i think i got it to work now. i restarted it and hit 'Enter' on the boot menu it shows
<leoprikler>bavier: interesting, I don't think I can reproduce your behaviour
<bavier>leoprikler: hmmm, ok. which DE are you running?
<bavier>I'm in ratpoison
<leoprikler>I'm running GNOME.
<leoprikler>3.32 for the sake of completeness
<bavier>ok, I'll try on my own on GNOME. If it works there, I think we can punt on the issue.
<johnjay>substitute is guix speak for binary packages right?
<nckx>More or less.
<johnjay>ok. i spent an hour trying to get guile emacs to compile
<johnjay>so i figured it would be faster to just install guix and then a substitute
<dftxbs3e>also, I have a question, the only way to ensure a substitute corresponds to the package definition is to build it correct?
<leoprikler>dftxbs3e: guix build --no-substitutes followed by guix challenge
<dftxbs3e>leoprikler, but that builds the entire thing correct?
<dftxbs3e>how did GNU Guix intend to store substitute on IPFS? Are they signed by the CI release key?
<leoprikler>yes, sadly
<nckx>dftxbs3e: ‘ensure’: I don't see another (even theoretical) way. For ‘ensure, but, like, not super’: substitute servers sign substitutes.
<leoprikler>I'm not aware of a lightweight --no-substitutes
<leoprikler>It would be interesting though.
<nckx>leoprikler: It's not elegant but ‘guix environment foo -- true && guix build --no-substitutes foo’ does kind of that.
<leoprikler>it does?
<nckx>As in it doesn't build gcc from source, if that's what you mean.
<leoprikler>that's a huge improvement though
<nckx>If you mean ‘I want to know that this foo corresponds to foo.tgz but I don't want to build it’, I don't see how that's possible without building it + repro builds.
<bavier>'guix build --no-substitutes=foo foo' might be nice
<bavier>i.e. "use substitutes, but not for foo"
<johnjay>oh... it's downloading packages.
<johnjay>any idea how much data that would be?
<nckx>johnjay: From what? Guix System installer? Guix binary installer on another distribution?
<johnjay>the former
<nckx>‘Few gigs at least in any case.’
<nckx>Oh. Few more gigs then.
<johnjay>ok
<johnjay>there's no progress indicator which was alarming to me
<johnjay>it's downloading gcc-5.5 now
<johnjay>which is also somewhat disquieting since it's like what, version 8 now?
<nckx>As long as the file doesn't end in tar.something that's good.
<leoprikler>guix uses earlier gcc versions in bootstrapping
<leoprikler>not sure if gcc-5.5 is the first one, but if it is: everything is normal, nothing to see
<nckx>johnjay: 7, but things can depend on earlier GCCs, even when not building from source.
<dftxbs3e>maybe there should be an easy to install system to cooperatively compare hashes from built artifacts
<johnjay>Downloading from https://ci.guix.gnu.org/nar/gzip/STUFF...gcc-5.5.0...
<dftxbs3e>I mean, something that arbitrary organizations can run
<nckx>dftxbs3e: We define ‘ensure’ super differently then.
<nckx>johnjay: What's the last …?
<johnjay>literally it is ...
<nckx>OK, that is good.
<dftxbs3e>nckx, what's your definition?
<nckx>‘Don' trust nobody but myself with binaries’, very roughly.
<dftxbs3e>yes of course
<johnjay>i hope i can change my keyboard later
<johnjay>i picked the wrong one in the installer
<dftxbs3e>I didnt follow up to the previous stuff
<nckx>Also no distributed votes that are interesting signals but easy to game.
<dftxbs3e>I would say it improves the situation
<bavier>guix-on-the-blockchain
<bavier>*sarcasm*
<nckx>johnjay: You can edit your /etc/whatevertheinstallercallsyoursystem.scm & add/edit the (keyboard-layout …) field, the reconfigure. It'll just be a bit painful.
<leoprikler>Proof of compilation errors.
<nckx>dftxbs3e: Sure, it's not black & white.
<johnjay>i can edit that? ok cool
<dftxbs3e>there could be a list of servers that publish hashes, and GNU Guix would hardcode a list of all these servers, and every time you get a package, if the hashes don't correspond to what everyone (or 90%) got, you get a want-to-continue warning
<nckx>johnjay: The installer is the first *and last* GUI helper, unless you count emacs 🙂
<nckx>After that it's all editing all day.
<johnjay>well emacs is the whole reason i'm doing this
<johnjay>so i'm fortunate then
<nckx>Seems like overkill to install the entire distro, but welcome!
<leoprikler>Guix as an Emacs bootloader :)
<dftxbs3e>I feel like I'm missing something by not using Emacs
<dftxbs3e>Is Emacs an OS by now?
<johnjay>well i tried downloading the source from git://git.hcoop.net/git/bpt/emacs.git and it compiled with errors
<leoprikler>You can have it as your init, but it still lacks threads.
<johnjay>so this is in fact the fastest way
<johnjay>actually having threads in emacs is one of my motivations
<dftxbs3e>leoprikler, Emacs lacks threads? in what way?
<johnjay>i heard guile has posix threads so i wanted to look into it
<dftxbs3e>leoprikler, also, does Emacs benefit from GNU Guix development tooling that other editors do not have?
<dftxbs3e>For Scheme etc.
<johnjay>dftxbs3e: steve yegge has a post about js2-mode where he talks about how many thousands of lines of javascript he can process before it annoys the user blocking
<leoprikler>dftxbs3e: Up to and excluding 27, there are no threads at all in Emacs. In 27, there is some thread support, but not POSIX threads afaik.
<johnjay>yes
<leoprikler>I would really prefer an Emacs on top of GNU Guile, but the road there has a lot of bumps.
<johnjay>leoprikler: my first bump i ran into... getting it to compile without errors
<johnjay>T_T