***jonsger1 is now known as jonsger
<civodul>cbaines: re finding the commit that introduced a regression, sure, sounds good <civodul>the CPATH vs. C_INCLUDE_PATH is a long (and sad) story <mjw>civodul, can I read the story somewhere? <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 <mjw>ah, cool issues.guix.gnu.org works again <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>mjw: IIRC, the problem is that Guix ends up putting libc at the beginning of the search path <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>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>i'll read about your adventures tomorrow :-) <mjw>No! Wait, what it "the guix way" to pull the manual, update, build and submit an issue? <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. ***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
<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>But I'm too clueless about Scheme and GNU Guix <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>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? <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 <oriansj>dftxbs3e: and does mescc-tools build without issue? <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>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>oriansj, do you want to give a hand on this? <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 <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 <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>to build it it would be guix build -e '(@@ (gnu packages commencement) libstdc++-boot0)' <efraim>i assume it works also for environment <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]>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]>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? <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 <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! <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>for Outreachy i guess we have to wait for GNU to be accepted as an org, right? <civodul>but for Outreachy, we must do better than last time <civodul>i guess we were too late and did not communicate enough <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. <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? <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]>I don't know how to express it really properly, but I will try my best. <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>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>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]>I will collect the proposals we had, and send a mail to guix-devel *g_bor[m] going to the dentist <nixo_>Who's coming to FOSDEM 2020? I still need to book my flight <civodul>nixo_: make sure to come to the Guix Days, too :-) <civodul>janneke: i just realized that Gash doesn't provide /bin/sh, how come?! :-) <nckx>The ZFS licence is incompatible with the GPL. <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 ? <efraim>binary substitutes, it would need to be built on the machine which was going to use it <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>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>compare to bluetoothctl command line, which should work <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 <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 <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 <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>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>And there's a status icon, but still "No bluetooth found" ***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. <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. <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? <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 <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>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>python build is much more complete than ruby.. <roptat>probably nobody worked too hard on this <nckx>Parra: It's more a feature request than a bug, but somewhere in between. <roptat>or maybe there's a separate package for ruby-tk? <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>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>it is not packaged as standalone library <Parra>it is packaged by means of other packages <Parra>after I finish this I will try to submit a package <PurpleSym>Does `guix environment --with-graft` not alter dependencies of manifests (via -m)? <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>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 <wingo>the r-b summit location & venue looked amazing <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 <jonsger>jmercouris: why are you don't using "guix environment guile-lib"? <nixo_>gnunet is failing to build 0.11.8 (broken tests, can't find some .conf gile) ***ng0_ is now known as ng0
<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>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: 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>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>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: I've usually ignored it in the past, I just hope most other people do too. <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 <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 <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]>i dont have ffmpeg in config.scm but i installed it for my user <nixo_>if you want to compile things, you need to be in an environment <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>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>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>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>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. <brettgilio>We will raise him in the spirit of the GNU. Haha <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. <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 :) <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? <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>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]>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 <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 ***jonsger1 is now known as jonsger
<bavier>any good way to debug svg icons not showing up in a gtk+ application? <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>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>I'm wondering now if this is a gresource issue <leoprikler>I don't think app icons are usually packaged in the gresource <bavier>I see "data/log-shade.svg" in it's gresource.xml <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 <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>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>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? <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? <nckx>dftxbs3e: ‘ensure’: I don't see another (even theoretical) way. For ‘ensure, but, like, not super’: substitute servers sign substitutes. <nckx>leoprikler: It's not elegant but ‘guix environment foo -- true && guix build --no-substitutes foo’ does kind of that. <nckx>As in it doesn't build gcc from source, if that's what you mean. <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>any idea how much data that would be? <nckx>johnjay: From what? Guix System installer? Guix binary installer on another distribution? <nckx>‘Few gigs at least in any case.’ <johnjay>there's no progress indicator which was alarming to me <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>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 <dftxbs3e>I mean, something that arbitrary organizations can run <nckx>dftxbs3e: We define ‘ensure’ super differently then. <nckx>johnjay: What's the last …? <nckx>‘Don' trust nobody but myself with binaries’, very roughly. <johnjay>i hope i can change my keyboard later <johnjay>i picked the wrong one in the installer <nckx>Also no distributed votes that are interesting signals but easy to game. <nckx>johnjay: You can edit your /etc/whatevertheinstallercallsyoursystem.scm & add/edit the (keyboard-layout …) field, the reconfigure. It'll just be a bit painful. <nckx>dftxbs3e: Sure, it's not black & white. <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 <nckx>Seems like overkill to install the entire distro, but welcome! <dftxbs3e>I feel like I'm missing something by not using Emacs <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>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? <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. <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