***vZS1_techrights is now known as vZS1_guix
***vZS1_guix is now known as vZS1
<vagrantc>so, i guess there are reasons why it's in /gnu/store/HASH-PACKAGE-VERSION <vagrantc>but it would be nice to have a symlink farm of PACKAGE-VERSION-HASH pointing to the things in /gnu/store <vagrantc>the tab completion works much better that way... <cbaines>I don't know much about filesystems, but the particular nature of the store might be interesting to play around with <cbaines>rather than having symlinks, couuld you instead have a (FUSE?) filesystem backed by the store database, which could use take advantage of that to potentially be faster <vagrantc>fair enough, guix just seemed so invested in symlinks it seemed a natural proposal :) <vagrantc>or actually, a tree structure i would like even better .../PACKAGE/VERSION/HASH <vagrantc>but not all store items follow that exact structure ... though i'm probably not really interested in browsing those either, so maybe it doesn't matter <cbaines>I think simple things are more dependable, like symlinks, but a filesystem for interacting with the store in the way you want would be cool I think <vagrantc>not anything i'm likely to implement, regardless, just floating the idea in the hopes that it takes root at some point :) <pkill9>i have an idea: chromium/icecat extension that tells you if you are looking at a piece of software and it's been packaged in guix, e.g. when you are looking at it's source URL, or on it's homepage <apteryx>hmm, my vm in gnome-boxes keeps loosing network access... I wonder why. <xelxebar>Anyone here successfully using xinit with a guix system? <xelxebar>Starting xinit fails and populates the Xorg.0.log with "systemd-logind: failed to get session: The name org.freedesktop.login1 was not provided by any .service files" <xelxebar>It looks like elogind provides the file share/dbus-1/system-services/org.freedesktop.login1.service <xelxebar>Not sure if related, but my "term-auto" service looks to be stopped. <xelxebar>Ugh. Nevermind... I forgot to install xterm :/ <xelxebar>Oh, and then there's the xorg-startx-command service... <xelxebar>Jesus. Simply setting set-xorg-configuration is causing reconfigure to download all kinds of stuff like wayland?? <raghavgururajan>After doing `guix time-machine --commit=f43287aff06082c83649a1d0c0184b9ac347c3c8 -- system reconfigure /etc/secondary.scm --allow-downgrades`, system was working fine. So I GC'd everything. <raghavgururajan>But now I cannot even do anything without building everything like gcc bash etc.. <raghavgururajan>This started appearing: substitute: guix substitute: warning: ACL for archive imports seems to be uninitialized, substitutes may be unavailable <raghavgururajan>At this point, I am unable to do `guix pull` or `guix system reconfigure`. <mroh>maybe you have a /etc/guix/acl.bak file that you can copy to /etc/guix/acl <raghavgururajan>For information, in current state, `guix describe` for user and root gives, 582cf9257cd1f9c969fbba5eb1c336ac8b975cde. Though current system generation is based on f43287aff06082c83649a1d0c0184b9ac347c3c8. <lfam>I'm here raghavgururajan <lfam>raghavgururajan: That warning means that your /etc/guix/acl file is not set up <lfam>I know the way that file is handled changed recently but I didn't pay attention to the discussion <raghavgururajan>lfam: I never had to manually deal with acl file. Would using time-machine for system reconfigure could have caused something to change? <xelxebar>raghavgururajan: Have you manually run `guix archive --authorize` before? <lfam>Since I don't know the details of what changed, I don't have a precise idea, but I'd guess that going back in time (--allow-downgrades) could have some unexpected effect if you went back to before the changes <lfam>On Guix System, you shouldn't need to do anything about that file xelxebar <lfam>What does that file contain on your system, raghavgururajan? <xelxebar>raghavgururajan: That command sets up your /etc/guix/acl file, but guix expects you to configure your substitute server auths via an operating-system config, so when you reconfigure, it clobbers /etc/guix/acl. As mroh mentioned, if you *did* manually add servers, then your old /etc/guix/acl gets moved to /etc/guix/acl.bak. <xelxebar>raghavgururajan: You really should set configure your sustitutes in your operating-system configuration. <raghavgururajan>xelxebar: I see. I guess due to changes mentioned by lfam, my acl could have changed due to --allow-downgrades <xelxebar>raghavgururajan: Search for "authorized-keys" in the manual. <raghavgururajan>> xelxebar: raghavgururajan: You really should set configure your sustitutes in your operating-system configuration. <xelxebar>Yeah, it should be. How many entries do you have in /etc/guix/acl? <xelxebar>Hrm, setting keyboard-layout in set-xorg-configuration isn't actually changing my layout. Does set-xorg-configuration only work with login managers? <lfam>Huh, I wonder what key that is. I'd guess it's your computer's own signing key <lfam>It's not the build farm's key <lfam>The 8D1 key is the build farm's <xelxebar>raghavgururajan: Yeah, you have the standard build farm as well as some other substitute server setup. <xelxebar>raghavgururajan: Not sure why the original one contains a weird key... <raghavgururajan>xelxebar: I think I may have done `guix archive --authorize` for bayfront <lfam>Yes, it's the bayfront key <xelxebar>raghavgururajan: How old is that commit that you time-machined to?? <lfam>It's a server that Guix owns, and it has a small build farm behind it <xelxebar>lfam: Thanks. I found bayfront.guix.gnu.org. Is it substituting for any particular class of packages? Just curious why it exists. <lfam>The short version of the story is that we wanted to use it to create the "new" build farm, but ended up with the build farm hosted at berlin.guix.gnu.org instead. Previously, Guix was hosted on a VM by the FSF, but we outgrew it <lfam>I mean, Guix something that can be "hosted". Our build farm was hosted at FSF <lfam>Guix isn't something that can be hosted <lfam>Now it gets used for a variety of things, but it's independent of berlin <xelxebar>lfam: Okay. So it's somewhat of a historical quirk. Thanks. <lfam>Yeah, basically. But, we'd want to own a powerful server that's independent of the build farm regardless <xelxebar>Oh, so it gets used for things other than substitute builds? <lfam>I'm not sure all the things it's used for, but the Guix infrastructure is controlled by the files in our maintenance.git repo: <lfam>So, you could poke around and figure it out :) <xelxebar>Oh cool. I love digging into these kinds of infrastracture details. Thanks for sharing! <lfam>I don't think many people find that repo, but it's no secret <xelxebar>Oh cool. There's a nice high-level TODO list too! Gives a good feel for where Guix may be headed. <lfam>It might be terribly out of date! <lfam>But it should be valuable either way <xelxebar>Yeah, several of these look DONE but are still marked TODO! <lfam>That's the problem with TODO lists :) <lfam>TODO: Update the TODO list <xelxebar>Also nice to see plain text accounting getting used in the wild ***iyzsong-- is now known as iyzsong-w
<xelxebar>On a different note, any idea why directly invoking xinit might not pick up the settings from set-xorg-configuration? <lfam>I wish I knew more about xinit in Guix. I use startx on Debian but I've never looked into how to use it with Guix <lfam>I know it used to be complicated but that work was done <lfam>This part is funny: "it successfully fails to start" *raghavgururajan is building linux-libre-5.4.74 on bayfront <lfam>Did it fail to build on berlin? ***chrislck_ is now known as chrislck
<xelxebar>mroh: Oh, nice. Starting to see the possibilities. Thanks <lfam>Once again, I get a substitute for 5.9 but not 5.4 <lfam>I wish I knew what was going wrong <raghavgururajan>@ build-succeeded /gnu/store/aaaphffrf5p1ds61s1yqm8yacgv056wr-linux-libre-5.4.74.drv - <bavier[m]1>Do we have pre-release install images for the upcoming 1.2.0 release somewhere? <apteryx>Mathieu worked on adding images built from latest continuously to the website <raghavgururajan>lfam: You are right. Something wrong with building of 5.4 series on berlin. On bayfront, 5.4.74 finished building successfully in about 20min. <lfam>Maybe a spurious failure of some 5.4-specific dependency is cached <lfam>I thinking of a spurious failure, like a timeout caused by high load <lfam>It would be different on different machines <lfam>I think it's something like that because I don't know why else it only effects 5.4 <lfam>I get a substitute for 5.9.3. I think that search engine is not working :/ <apteryx>ss2: I pushed samba v4.13.1; it now uses /var. <abcdw>I have a guix v1 as my primary channel, also have a channelX, which depends on guix v2 and doesn't work with guix v1. How can I define channel.scm with guix v1 and channelX? <xelxebar>Dang. Running guix from an nvme and with 24gb memory is a *whole* different experience. <wleslie>I'll likely have a working desktop next week; trying to imagine having more than 2 cores <vits-test>xelxebar: honestly, running Guix on aarch64 with only 4GB RAM, but on eMMC instead of HDD is also a *whole* diff.exp. <vits-test>tho i suppose with 24gb the builds will be no trouble any more. <xelxebar>ThinkPad E495: 256GB NVMe drive + 1TB SSD, 24GB RAM, AMD Ryzen 5 (8 cores). It's just that everything is immediate. <xelxebar>I'm used to running on a 10yo laptop where even a simple `guix show` takes a while. <xelxebar>vits-test: Yeah, solid state makes such a huge difference. Though it's also nice having a bunch of cores. <wleslie>my 8yo laptop says 0.628s real for `guix show binutils` <mothacehe>civodul: I didn't really dive into this issue yet! Were you able to reproduce it ? <wleslie>just realised that (make-libstdc++) contains nested quasiquotation <civodul>mothacehe: not really, but i think i have a better understanding of how it can happen <civodul>oops, command synopses from "guix help" were not i18n'd <vits-test>Hello Guix. Can package man-pages be included in %base-packages? It's only 3Mib. <xelxebar>wleslie: Yeah, guix show is fast if all the guile code is sitting in your inode cache. Running from a cold cache takes ~10 seconds for me. <xelxebar>Well, on the new thinkpad, it's instant either way. <abcdw>Is it possible to use in one profile guix v1 and channelX, which depends on guix v2? <xelxebar>Anyone here use a yubikey/smartcard on your guix system? <xelxebar>However, I vaguely remember encountering this on a different distro in the past. <xelxebar>Had to set up a udev rule to add the device to a "yubikey" group or something and add my user in it. <civodul>abcdw: you have one profile for Guix itself, ~/.config/guix/current, and one for the packages you installed, ~/.guix-profile <abcdw>Nope, I want to run guix time-machine -C channels.scm environment --ad-hoc package-from-guix-v1 package-from-channel-x-depending-on-guix-v2 <abcdw>civodul: something like that. *abcdw afk, will be back in 1-2 hours. <davidl>I broke my guix on a foreign distro by running guix pull from inside a container created with guix system container - is this a bug? <civodul>davidl: what do you mean by "broke"? <civodul>it seems unlikely that running "guix pull" in the container would break things outside <ngz>civodul: I answered yesterday to #43910 (#43911 is the same). I am waiting for an agreement (should I ?). <davidl>civodul: running the guix command outside the container doesn't work anymore and restarting the guix-daemon with systemctl restart guix-daemon fails etc. I actually couldn't even login to my user afterwards. Fortunately I had a recent snapshot of that VM so I just restored. <civodul>ngz: oh right, sorry; well maybe you can go ahead, it's been a while already <davidl>civodul: no program from /gnu/store outside the container would start. not sure if guix pull from inside the container operates on the the same /gnu/store or not. The container was created with guix system container simpleOS.scm --network and then started with sudo /gnu/store/xxxx-run-container <davidl>civodul: it happened twice by the way so probably reproducible. <civodul>davidl: can you copy/paste the commands and output so we see what you mean by "doesn't work anymore" etc.? <davidl>I can, but it is going to take a while before I get around to it. <civodul>also, if it's reproducible, you can even report steps to reproduce it to bug-guix <davidl>Ill get around to that faster :-) <ngz>civodul: Fair enough. I'll apply them. <g_bor[m]>civodul, rekado : zimoun told me that we should talk later about Outreachy intern selection <g_bor[m]>When do you think you would have time to discuss that? <g_bor[m]>The critical person there is definitely zimoun, as they were working together, but would like to ask for advice. <civodul>g_bor[m]: i'm happy to participate in the discussion though i probably won't have much to say <civodul>g_bor[m] was talking about Outreachy intern selection <zimoun>yesterday, I wrote an email and crap Emacs daemon crashed and I lost it. I will rewrite it. But time flies… <zimoun>my idea is to discuss and help to decide. Well share the decision process. <xelxebar>Hrm. I can't figure out how to use udev-rules-service, apparently. Don't see my rule in the directory $(herd rules udev). *zimoun says I have to pick one phone call. AFK, sorry. <xelxebar>Oh. Looks like udev needs to be restarted. <civodul>ngz: i think b107a19ffb6a6abb7bde3436f3fa359071bd1f5c has to be reverted: it causes too many rebuilds (via emacs-minimal) and it "broke" things somehow <civodul>no code for module (guix build glib-or-gtk-build-system) <civodul>builder for `/gnu/store/0pz2nnha8rsifh6qjsrylmsi29dklrvk-emacs-minimal-27.1.drv' failed with exit code 1 <ngz>civodul: guix refresh -l emacs reports 180 dependant packages. <ngz>905 packages, but note that most are Emacs packages <nckx>Also, breaking 905 fast-building packages (if that's what happened) is worse than rebuilding 905 fast-building packages... <ngz>That's not what I'm arguing about! <ngz>Anyway, I'll just shut up and revert. No worries. <Winux>I’m trying to package qtile for guix but it doesn’t show up in the sessions list <civodul>i don't know if we usually handle such emacs-minimal changes on 'master' <Fenlair>Hey everyone! I would like to package remmina (open source remote desktop tool, I believe from the same repo as freerdp?) Do you think that would be a good candidate for a first package? The dependancies look a bit daunting, but on the upside there is already a nix package of it. <civodul>hi Fenlair! as long as it uses a standard build system (Autotools, CMake, Meson, etc.), it should be fine <nckx>Winux: I'm assuming you mean GDM's session list and qtile is a wm (I'm assuming a lot). Does qtile provide a .desktop file in the expected place in the output? <civodul><nckx> Winux: I'm assuming you mean GDM's session list and qtile is a wm (I'm <civodul> assuming a lot). Does qtile provide a .desktop file in the expected <nckx>Fenlair: I don't see any dangers in the Nix expression. Go for it. <Fenlair>Ok, thanks civodul . It uses cmake :) *civodul could do a good job as a bot <nckx>Fenlair: Also, questions are always welcome here, even ‘this doesn't work <pastbin of you code>, halp’. <OriansJ>very stupid idea but: guix builds should be slower. Here is the idea: all builds should be done on a qemu virtual machine with as minimal specs as possible (per build) and get away from the bad idea that the package definition should be in the scope of the hash; which would allow one to build, document the final hash as well (to check the binary) in the package definition. <OriansJ>Thus making all builds host/cpu/etc agnostic <Fenlair>One thing that I try to wrap my head around. We use a module system on CentOS to get certain packages with certain dependancies loaded. But sometimes this goes boom, if you load two modules that use two different versions of, let's say Perl. How would that work on Guix, if I have Perl in the (install ...) list, it will not show up in my PATH and it wouldn't mess with anything else, but how does that package then know itself, which Perl <Winux>I looked up and it didn’t provide one. How can I put a desktop file inside my package definition? <OriansJ>Fenlair: the same way that having multiple versions of gcc using the correct version of binutils <OriansJ>we patch the paths to point to the correct version <nckx>Winux: Does qtile provide one anywhere in the sources? Don't just find -name .desktop; since it may be generated during the build. <nckx>Winux: If not, you need to create one from scratch such as done by toutenclic (random example). <nckx>(Is there a helper for that now? civodul?) <nckx>Fenlair: What's the (install ...) list? <Fenlair>nckx: in the package definition, there is (native-install ...) and (install ...) and I think (propagated-inputs ...), the last one being propagated to the PATH (if I understood that right). So propably if Perl is dynamically linked it would have to be in the last list? <Fenlair>oh it's always inputs not install, sorry about that. <civodul>nckx: i don't think there's a helper to create .desktop files <nckx>Fenlair: The ‘perl’ in your *inputs will be a "/gnu/store/<hash>-perl-<version>" string at build time. So ‘which perl’ will return /gnu/store/<hash>-perl-<version>/bin/perl. It's expected that your package embeds that absolute reference in all generated binaries/scripts. That usually Just Happens™, but if a the software does something like ‘execlp("perl" ...)’ at run time it should be patched to use absolute file names. <roptat>(guix build utils) has make-desktop-entry-file <nckx>Fenlair: That's a bit rambly, sorry, but it's a broad topic with many different answers. More specific questions can get more specific answers. <civodul>roptat: it's not documented in the manual ;-) <nckx>roptat: That's it. Thanks. <roptat>just like the whole of (guix build utils), no? *nckx was searching for ‘define.*desktop-file’... <zimoun>civodul, rekado, g_bor[m]: I am going to send you an email. And let discuss privately. <zimoun>roptat: do you have time to review the tiny patch that I sent you about the alias? <Fenlair>nckx: no worries, I'm already very thankful for that answer! Also OriansJ. The concepts haven't quite sunken in yet. What confuses me now is, that which perl would point to something in inputs. Isn't the difference between input and propagated-input, that in input the binary isn't put into the profile? And if it isn't in the profile, I would have expected it to not show up in the path/which. <zimoun>I am proposing to shift a bit the deadline <roptat>Yeah... 6th to 14th was already short, but here you're giving 4 days to record :/ <roptat>I don't think you really can create a presentation and record it in just 4 days <nckx>Fenlair: The ‘which perl’ I'm talking about is at *build* time, i.e. if your configure script or Makefile run ‘which perl’. perl is in $PATH in the isolated temporary build environment. However, if a user installs swaks (a Perl script) into their otherwise empty profile, the user running ‘which perl’ won't return anything because perl isn't propagated. How does swaks find its perl? It hard-codes the /gnu/store/.../bin/perl file name, so <nckx> perl never needs to be in $PATH after the build. <nckx>swaks' shebang is #!/gnu/store/8zvc5mvk0xm3ygrxsgpyy5ilxb5rzjry-perl-5.30.2/bin/perl. <nckx>and it's launched through a wrapper script that sets up $PERL5LIB. <nckx>Ideally it should ignore whatever $PATH and $PERL5LIB you have in your filthy environment. <Fenlair>if I do 'which perl' on the command-line, it has to be on the $PATH, no? <nckx>But installing *only* swaks won't put perl in your $PATH. And yet swaks will run fine. <roptat>zimoun, my fear is that if we extend the deadline, people who would have submitted on the 6th will submit on the 10th instead, and then will get only 4 days to prepare and record <roptat>because you know how deadlines work :) <Fenlair>oh I missed the big reply message you send! :/ (new to IRC :D) <nckx>I've never heard of CentOS modules so I can't make a direct comparison. <zimoun>roptat: yeah I know. :-) But 6th is this Friday. So it is short too. :-) <roptat>but it's only for a proposal, it doesn't require too much time <roptat>and then it gives you a week to prepare the talk <zimoun>yeah, ok. Do I tweak the patch or could you directly do it and push? <roptat>also, I think many people will be thinking "I'll get a reply on the 6th, so I'm not starting to work on this until then, in case they reject me" or something <roptat>we can always extend on the 7th if we haven't received anything yet <roptat>we'll have to be more vocal and ask people directly I guess :) <zimoun>and yeah, we have to ask directly. <vits-test>OriansJ: are U serious? My SBC struggles to make a Kernel in 2 hours, w/o VM. Subs. are scarse. <Fenlair>nckx: Thanks alot! That cleared up quite a bit for me :D The module stuff isn't from CentOS i think, just regular linux environment modules. <zimoun>mothacehe: we need a talk from you :-) <xelxebar>Hrm. Even getting the udev rule setup, I'm still unable to access the yubikey :/ <nckx>Hm, if I let the Makefile do its thing (running objcopy --strip-debug --strip-unneeded) it produces a 6.7M .so with 7.7M .so.debug. But I want Guix to handle it, so I patch it out, but Guix creates a 7.7M .so and 99M .so.debug. <nckx>I'm not even sure what my question is but: why? <nckx>I'd like to get the .so down to 6.7M at least. <nckx>Fenlair: C... clear? I'm always surprised but happy to hear that. (‘Regular Linux environment modules’ don't ring a bell either, I'm afraid.) <Fenlair>nckx: I'm not saying I understood all of it ;) But it's a lot less foggy now :D It's just a tool to help change environment variables dynamically. You can do 'module load gcc/8.3', which will setup your path to point to the right binary and then 'module switch gcc gcc/9.2' and it will change your path. I assume most of that is just not needed anymore with Guix. <zimoun>nckx: Sorry for the annoyance. It was to test if the alias really works. It does. :-) <nckx>Fenlair: Sounds like Debian's ‘alternatives’ system, which which I'm also not very familiar but have at least heard of. Does it change your $PATH (similar to guix environment) or the actual presence or location of symlinks (similar to guix install)? <nckx>But yes, Guix replaces such systems with its own. <Fenlair>nckx: It is quite flexible, if I remember right the module scripts are written in TCL, usually you just change the environment variables like $PATH. <abcdw>civodul: thank you, inferiors is a nice tool, but it's a little pitty, that channel doesn't bring his own dependencies with himself. <vits-test>./doc/guix.de.texi:2634 unknown command `sasmp' <nckx>vits-test: Should be samp, thanks. <abcdw>civodul: I found flake mechanism in nix pretty interesting. It is similar to channels, but from flake defenition flake.lock file generated, which contains not only this flake dependencies, but also transitive dependencies. It allows to have to separate nixpkgs versions at the same time for single environment without additional work. Probably it's not possible with guile, because it will result to name collision. <nckx>roptat: Can I just update the .po file or does this need to be handled by the TP? <nckx>Even if the answer is ‘the TP’ I'd rather push the quick fix to Guix.git to unbreak this. <roptat>nckx, it needs to go through the TP <roptat>can you fix it in guix and send thhe fix to the TP too? <nckx>I've already pushed the Guix fix (<- vits-test). How do I do the other? <nckx>I think I'll just look up who handles the DE translation and ask them, rather than set up what seems to be the git-send-email of translations just to delete a character. <civodul>abcdw: did you check "guix describe"? it's a way to "pin" Guix to a specific revision, which i think is one of the use cases of Nix flakes <civodul>but anyway, you're welcome to share your use cases on the ML so we can think about the limitations of existing tooling <roptat>nckx, yes, just ask the latest translator :) <roptat>sorry for the breakage, I excluded the russian translation for that reason, but somehow missed the issue in the German translation <roptat>civodul, do we have a 1.2 branch? When should I send the new strings to the TP? <civodul>roptat, zimoun: i thought i could talk about Git authentication but that'd be a completely new talk, so quite a bit of work <civodul>roptat: like i wrote, with the changes i pushed this morning + the partitioning i18n maav & i took care of, we should be fine <civodul>we should double-check that 0dc89c03684502c0702a7b9b3ae924d152d8f379 has the intended effect <nckx>That's Florian, correct? <roptat>nckx, yes according to the Last-Translator header <abcdw>Yep, I checked "guix describe", it works pretty well for locking, but I don't see a way to pull transient dependencies automatically. For example: channelA uses channelB and my code uses channelA, if I specify channelA in channels.scm guix pull or time-machine won't pull channelB as I understand. <civodul>however, you can only have one instance of a given channel in Guix <nckx>Thanks. I don't use Gettext. <civodul>abcdw: so you cannot have commit X and commit Y of the same channel <civodul>but i guess that's a reasonable limitation in practice <abcdw>civodul: oh, cool, I knew that I saw channels dependencies somewhere in the manual. Thank you for the link! <abcdw>civodul: Yep, probably it's a reasonable limitation. But what will happen in case there are few specifications of the same channel in dependency graph? <roptat>nckx, you don't need more than a text editor to see the header though :) <civodul>abcdw: duplicates are removed and the most specific one wins <civodul>so if there's one with (commit "xyz") and one with (branch "master"), the former wins <abcdw>civodul: got it, thank you for explanation) <civodul>zimoun: did you start working on NEWS & the release notes? <civodul>if not i can maybe take a look later today <zimoun>civodul: or talk about about Jupyter which is ready. :-) Or talk about guix-past and paper to code. Or about the experience in INRIA Bordeaux. Or a rough draft about the maybe FOSDEM talk. Or your opiniotated ROADMAP. <civodul>heh, you have no shortage of ideas :-) <civodul>roptat, zimoun: BTW you can send a reminder to info-guix, explicitly giving both guix-days@ and guix-devel@ as ways to submit a talk <zimoun>civodul: about NEWS, yes but nothing relevant. Please go ahead if you are in mood today. Then let send the result to guix-patches. And we can collectively process. <zimoun>and the reminder is in the pipe. I sent something to roptat this morning (instead of yesterday), time for processing. :-) *zimoun feels not scaling well... <ss2>Hey, folks, I'm trying it with my first package at the moment, but the sha checksum is failing at the moment, although it looks right: https://paste.rs/Bgx <ss2>It throughs an exception every time, and I got the hash from guix hash, as per the manuals. <nckx>ss2: Guix ‘base32’ hashes can start only with a 0 or 1. <nckx>‘guix download <URL>’ returns 10pcrpmb4n1mkgr21xd580nrbmh57q7s72cbs1zay847hc65vliy, not that. <ss2>I've been typing guix hash --format=base32, and it'd always reply with the other hash. <nckx>ss2: Seems like you've been using --format=base32. I get that hash if I do. <nckx>Guix's ‘base32’ != base32, but ‘nix-base32’, a historical left-over from Nix with different characters. <ss2>anyway, the package definition is far from complete. But thanks still. :) <ss2>It complains: guix package: error: cannot install non-package object: #<unspecified> <ss2>How do I look up these error messages? <nckx>ss2: Are you using guix build -f? That builds whatever value the file ‘returns’, so you need to end it on ‘cantata’. <nckx>I'm not aware of a list of common error message, but it's a cool idea. There are quite a few with a very specific Guixy solution. <g_bor[m]>roptat: do you have a link for the graph of maven somewhere? <efraim>I assume .class files are compiled and not source? <efraim>bummer. I'll see if I can work around it. the MARS mips emulator would be great to have <g_bor[m]>I hav found a link on the bootstrappable site. <roptat>more up-to-date than on bootstrappable <roptat>to be fair, this includes build-only dependencies, which maven people tend not to take into account <civodul>perhaps apt has a post-install hook for that? <bavier[m]1>civodul: there's a "refresh" action, right? I don't know if that would be appropriate. <vits-test>is `make check` hangs on test next to tests/guix-graph.sh? <leoprikler>You can restart gnome-shell, but that's a bit forced ;) <abcdw>Plan to talk about Nix and Guix on the stream. If someone wants to join, let me know, I'll share yt link. <roptat>just share it, people will know if they're interested (I am) <leoprikler>So we would need to signal install-changed on completion of `guix package` and `guix system reconfigure` <abcdw>roptat: would like to see your comments/additions btw <vits-test>leoprikler: honestly, i wonder why not ui/js/appDisplay.js. <civodul>apteryx: indeed, we could merge them <civodul>leoprikler: interesting, i was looking at 'apps-changed' in that file <civodul>so yeah, we "just" need to find how to signal 'installed-changed' <civodul>i was also looking at xdg-desktop-menu (from the 'xdg-utils' package), but it doesn't seem to do anything special <civodul>so maybe there's an inotify thingie somewhere *civodul has to go to an on-line meeting <leoprikler>vits-test: probably because grouping by language and then by scope makes more sense <roptat>abcdw, I don't have a youtube account <abcdw>I have irc on my second screen, you can write here if you want <vits-test>leoprikler: Not that i want to waste Ur time, but how the way? I want to see how "display" is working.. why guess in which lang they'd done it? To me it gives no sense currently. <apteryx>sneek: later tell civodul I've asked in #gnome, and apparently GNOME Shell is supposed to detect changed .desktop entries automatically. <leoprikler>vits-test: `tree` exists. There are subtle differences between how everything is nicely displayed and how stuff works under the hood as well <apteryx>The mechanism relies on inotify (on $HOME/.guix-profile/share/applications, in our case), so perhaps if the parent directory is switched via symlink it could fail detecting any change (just an idea) <leoprikler>If you're writing a typical web application frontend you don't care too much about the node in the backend, do you? <roptat>abcdw, I'm a bit ahead, but guix also supports the Hurd now :) <OriansJ>vits-test: I am very serious but for exactly the reasons you specified. I want to know for absolute certain after x hours of building that it will always succeed. <OriansJ>right now I do a guix pull and it might not even successfully complete and figuring out why is not exactly easy. <OriansJ>right now I managed to find a way to get /gnu/store/qm3l79ic89qpjjd8avqxd81425v4wvv5-gnutls-3.6.A.drv to both successfully complete and fail when being built from identical (minus the CPU cores) systems. <OriansJ>and I have no idea where to even start figuring out the reasons for that. <OriansJ>as they have identicial binaries at the start; both are 36GB of ram with matching SSDs; everything identicial as I can manage but somehow; 8 cores fails but 2 cores are successful. (doing a diff on hardware not possible) but the starting file systems are bit for bit identical; yet different results <apteryx>OriansJ: is it failing in the test suite? <apteryx>probably a race between concurrent processes <vits-test>OriansJ: IDK, but if it will be built in VM, will it run on our boxes in the end? Some progs compile good, but segfaults later (like it was with ntpd recently). Thanks. <OriansJ>apteryx: that was my guess too but doing guix build -c 2 didn't fix it either <apteryx>i'd bet if you ran it with #:parallel-tests? #f (or -c 1) it'd always succeed. <OriansJ>vits-test: well it is true; compiler optimizations can easily generate non-functional binaries but that is why we have generic targets like i586; which all later x86 processors can successfully run. <OriansJ>but then again my goal wasn't the fastest binaries possible but rather binaries that work successfully on as many systems as possible and can be built identicially on as many systems as that exist. <roptat>abcdw, a stable branch would mean you keep the old guix utilities too <OriansJ>roptat: that is what people get when they grab the latest guix binary now anyways. <roptat>hopefully we have a new release in a few days <OriansJ>until guix pull successfully completes; they are stuck with the oldest version we tar'd up. Which can't even accept manually downloaded substitutes <OriansJ>which is a problem as the stable binary can't successfully do guix pull on all systems. <OriansJ>and one can't download a substitute or build one which that old version accepts <apteryx>I can see that's not convenient, but it should technically work. <OriansJ>apteryx: because the nar file format changed between 1.1.0 and now <OriansJ>I am not certain when but if you install a guix 1.1.0 binary and do guix archive --import using the example nar in the documentation. It straight up complains that it isn't a valid nix file <OriansJ>and when one installs a frest 1.1.0 binary and trys to do guix archive --export to generate the binary; it produces something that by default it also considers corrupt; eg guix archive --export bash | guix archive -t (will fail) <apteryx>OriansJ: that seems an unrelated issue, I could reproduce it on a current Guix yesterday <OriansJ>now there might be a procedure to make that work (I just don't know what it is) <OriansJ>apteryx: yes but the point is if the nar files one can get from ci.guix.org are not valid to import and one can't build nar files that it'll consider valid and one is not able to build the file locally; one is stuck <maav>are we branching today? :) <maav>OriansJ: just a nitpick probably unrelated to this issue, it should be en_US.utf8 instead of UTF-8 ***samplet` is now known as samplet
<maav>but neither of those work <OriansJ>maav: it is the default contents of the systemd config file provided in the guix binary 1.1.0 tarball <OriansJ>and clearly it worked for a while but then it stopped and now it is a puzzle to figure out why <maav>i didn't checked that part, we should patch that... but the locale seems to not be installed at all, which is weird <maav>in foreign distros, afaik, the daemon comes from root's guix pull, isn't it? <apteryx>OriansJ: we don't see much there, could you paste the relevant gnutls failure or rerun the 'guix pull' with --verbosity=2 ? <OriansJ>maav: except the root's guix pull doesn't successfully complete <Fenlair>I started packaging remmina. guix package -f remmina.scm returns with 'guix package: error: cannot install non-package object: #<unspecified>'. My remmina.scm is -> https://pastebin.com/SR8ZxCYh. Any idea? :D <zimoun>maav: yep, I am favor to branch today. :-) <abcdw>roptat: You are welcome!) Thank you for joining and participating! <apteryx>sneek later tell civodul I've tried inotifywait on $HOME/.guix-profile and $HOME/.guix-profile/share/applications and it indeeds fails to report any change when the guix-profile symlink gets switched. <vits-test>Fenlair: add remmina at the end of the file in meantime. <vits-test>Fenlair: but modules should be added to load path, then all that. Simplest is like `guix package -L . -i remmina` <zimoun>snekk later tell civodul: do we branch v1.2 today? <zimoun>sneek later tell civodul: do we branch v1.2 today? <Fenlair>vits-test: Thanks, adding remmina to the end worked, now I get some real errors :P <vits-test>Fenlair: modules shouldn't evaluate to anything <vits-test>Fenlair: with remmina at the end, evaluation will happen every time someone or something loads this module. <Fenlair>vits-test: Ah remmina.scm is a module, so I should add it's directory to the module search path and make it install normally? <kozo[m]>Hello all, I'm working on making a guix iso for raspberry pi's. I installed guix binary and am looking at the disk image option. However, I need a config file to pass to it. Does the binary put a .scm file somewhere that I can use? <vits-test>Fenlair: better someone smarter will answer, but basically the process is described in manual. To package something for everyone, U better to work from our git tree. <vits-test>Fenlair: basically, if U drop remmina.scm to gnu/packages in git tree, U can `./pre-inst-env guix COMMAND remmina` <vits-test>Fenlair: (after `guix environment --pure guix`, then `./bootstrap && ./configure --localstatedir=/var && make -j`nproc`` in git tree, again) <maav>zimoun: cool, i'm working on some extra translations too, as i've already have the manual and guix upto master, hehehe <maav>i hope i can send a patch for the web soon... <Fenlair>vits-test: Thanks for the info! I will have to read the manual, since the last step went right over my head :D But it would be cool, if I could commit the package once it is running (and I feel a bit more confident in my Guix abilities :P) <vits-test>kozo[m]: I'm not sure if we have U-boot (bootloader) for Raspberry boards. <OriansJ>as debian's pastebin limits to 16KB posts <vits-test>kozo[m]: it's a config.scm (self.scm), but last time i check'd there was no u-boot for raspberries. <Fenlair>whup whup it's installing all the dependancies, cannot wait for the compilation errors :D <apteryx>OriansJ: on what arch are you building this? <apteryx>OriansJ: what does Guix describe says? <Fenlair>Hm, I managed to fix a few errors, but this one isn't very expressive :/ When building remmina I get the following log back: <Fenlair>In procedure scm_lreadr: /gnu/store/kh8c73a2pd2czb5jbsmshch0qcy2kvvh-remmina-1.4.8-guile-builder:1:9657: Unknown # object: #\< <dustyweb>samplet: are you Timothy Sample by any chance? <vits-test>; is comment, so closing paren is commented out <dustyweb>pinging you mainly because I have some question about the git-annex package... namely, I'm guessing the assistant was disabled for a Reason (TM) but I'm curious why <Fenlair>vits-test: hm I don't see that semicolon in my file or the pastebin :/ <samplet>As far as I remember, it was because we lacked dependencies. <OriansJ>I can provide the exact CPU details if you would like <samplet>There might have been a patch to enable it.... <dustyweb>samplet: well my spouse just started running guix on her machine (she did the install on her own! I just stood by and explained a few things) <dustyweb>we have everything she needs except the assistant, so I'm going to try to get that enabled I suppose <dustyweb>we went through enough of a long time where "this isn't a good time for me to upgrade my debian machine in case things break" and that accruing that we were like, "you know what, we need to break that cycle". And Guix is generally usable enough these days :) <vits-test>Fenlair: i pressed the "raw" button, and now see no that too. Maybe some emacs-w3m bug.. <samplet>dustyweb: Cool! I don’t see a patch, so maybe I’m mistaken. We have way more Haskell Web stuff since then, so hopefully it will be easy. <Fenlair>vits-test: Also I would hope there is a better error message in case of unbalanced parens :P <samplet>I’m actually in the process of getting the linter to warn about that, but it is an easy-to-make mistake when package Haskell libraries. <dustyweb>samplet: could you explain what that means, the versions from there...? <zimoun>dustyweb: git-annex-assistant was my initial goal when I hitted http://issues.guix.gnu.org/43843 then I was too exhausted to finish. ;-) Note that for reproducibility, the parallels build are truned off by default, so I can take a while when you build locally. <dustyweb>zimoun: did you find out anything about what was "needed" in the process? :) <zimoun>I do not remember. But as samplet said, the Haskell situation is not so bad now and the importer works more or less. <zimoun>Haskell LTS is a collection of Haskell packages that are known to work together. Well, it is an Haskell distribution somehow. <samplet>dustyweb: All of our Haskell packages have to work together. The Stackage people maintain a list of package versions that work for certain GHC releases. The “LTS 14.27” list matches our current GHC. <samplet>If we stick to their list, we can avoid “dependency hell”. <dustyweb>is haskell's packaging system not a fun time then? <samplet>It’s just that they pin dependencies frequently, and then expect that they all match perfectly. <samplet>(Rather than trying to keep long-term comparability.) <samplet>Finding a set of packages that all satisfy the constraints introduced by pinning is really hard. That’s why we leave it to the good folks at Stackage. <samplet>I have to go now, but feel free to ping/email me anytime about it. Especially if you want a patch review. ;) <apteryx>OriansJ: how did you install Guix on this system? Are you sure it's at commit d62c9b2671be55ae0305bebfda17b595f33797f2 (tag v1.1.0) ? <apteryx>if they're small enough, I think so. <apteryx>a reproducer (perhaps an operating-system to use with guix system vm?) is even better <bavier[m]1>in this case, the images would just be to show how the installer looks while rendered on my eeepc :) <bavier[m]1>unless there's a good way to limit the display size for a vm? I couldn't get that figured out in virt-manager. <lfam>In my experience, it works, but the bug tracker might drop them if they are too large, so take care to compress them appropriately <sneek>Welcome back civodul, you have 3 messages! <sneek>civodul, apteryx says: I've asked in #gnome, and apparently GNOME Shell is supposed to detect changed .desktop entries automatically. <sneek>civodul, apteryx says: I've tried inotifywait on $HOME/.guix-profile and $HOME/.guix-profile/share/applications and it indeeds fails to report any change when the guix-profile symlink gets switched. <sneek>civodul, zimoun says: do we branch v1.2 today? <civodul>zimoun: yup, i think we can branch today <civodul>i'll do that if nobody beats me at it <civodul>apteryx: neat! do you know where that inotify code is? <apteryx>I don't! We can have a look. Do you have an idea of how it could be fixed? It seems many applications making use of inotify could be broken the same way on Guix. <apteryx>perhaps abstracted in glib or something; I don't see any reference to inotify in the gnome-shell sources <apteryx>civodul: perhaps desktop_file_dir_changed in gio/gdesktopappinfo.c:234 <cbaines>civodul, going back to when I was talking about Guile+SQLite segfaulting, after lots of not getting anywhere, it's just occurred to me that it could be just like the PostgreSQL bindings, and be another GC race condition https://paste.debian.net/plain/1169833 <apteryx>its first monitor argument is a pointer to a GFileMonitor object, which implements the inotify stuff <zimoun>civodul: did you do something about NEWS today? <lfam>Fenlair: If the software doesn't have a test suite, you can add '#:tests? #f' in the arguments of the package definition <apteryx>civodul: interestingly there seems to be a polling based mechanism available (gpio/gpollfilemonitor.c), perhaps we can configure glib to use this instead of the gio/inotify/ginotifyfilemonitor.c for its GFileMonitor detection mechanism. <ss2>Is anyone around with some experience building qt packages with qmake? The package is having trouble finding the lrelease executable. <apteryx>civodul: it's actually GAppInfoMonitor that is responsible for monitoring the app info database for changes (gpio/gappinfo.c). <vits-test>ss2: why "QMAKE_LRELEASE=lrelease" not string-append with lrelease? <ss2>I'm just not getting it. <vits-test>ss2: the thing U commented out, with (string-append "QMAKE_LRELEASE=" lrelease), seem to be "righter" <vits-test>ss2: though there should be some #:configure-arguments or alike, rather than replace the 'configure phase <ss2>According to the source README, I'm supposed to do a qmake && make && make install. There's no configuring. But then my knowledge about qmake is limited. Especially how to string it into quile code. :) <Fenlair>In a package definition, in the arguments field I have a quasi-quoted list. If I want to reference to a package path in the configure options, do I have to unquote the package name? Something like this (arguments `(#:configure-flags (list (string-append "-DFREERDP_LIBRARY=" freerdp "/lib/libfreerdp2.so")))) <vits-test>ss2: in guix git tree: git grep qmake. Shows lots of invoke "qmake", seems U done right. <ss2>I've been reading around seeing how others have done it. <vits-test>ss2: seen gnu/packages/telephony.scm? it has lrelease <vits-test>ss2: maybe order should be `qmake that-file.pro VARS`? <ss2>yes, just tried that snippet. At least the error code changes from 3 to 2. <vits-test>let me guess.. QT.. was 3 become 2.. maybe it's a game? Like "U lose a life, continue playing? y/n" <ss2>not really. Mind you, Qt seems so complicated.. <ss2>Anyway, that was my fault. Shouldn't blindly copy code snippets :) <ss2>I think I'll give up for today. But I sucessfully compiled cantata, and am considering to contribute the scm, if anyone is interested. <vits-test>maybe (setenv "QT_INSTALL_BINS" (string-append qttools "/bin")), or smth? <nckx>Fenlair: Congratulations! <nckx>Fenlair: It's more complicated than that since you're on the build side, and you can't just pass a package over that boundary like you can pass a simple string like ,version or ,name. <nckx>Use (assoc-ref %build-inputs "freerdp"). <nckx>This all happens build-side. <nckx>Well, it's not illogical to want something as simple as quoting/unquoting instead of this, and IIRC that's exactly what the ‘gexp-based build system’ could provide, but it hasn't been merged. <ss2>vits-test: that didn't work either, but thanks for your help anyway, I'll have a look at it another day, and I didn't expect that it would be that problematic to compile it. <vits-test>ss2: Maybe lrelease is in another package, then. But another day is another day. <nckx>ss2: I haven't read the entire backlog. Any reason for not using the qt-build-system? <ss2>it doesn't work either, and fails with the same error message: the lrelease executable is not found. <ss2>I tried it with gnu, qt and cmake, they all fail. <nckx>ss2: https://paste.debian.net/plain/1169847 - Tries to install to /gnu/store/59dq1n4wj3maa3kcar6hspj2zd82as7q-qtbase-5.14.2/lib/qt5/plugins/platformthemes/libqt5ct.so, so you still need to do harder $prefix convincing, but it builds. <nckx>qt.qpa.plugin: Could not find the Qt platform plugin "wayland" in "" - might work fine on X11. <vits-test>nckx: why duplicate (string-append (assoc-ref inputs "qttools") "/bin/lrelease")? <nckx>Because tasty left-overs. <nckx>vits-test: I have to leave some exercise to the reader, or something 😉 <nckx>One could probably move them back into the 'configure phase with the same result but I think it fits, semantically. <nckx>vits-test: Fun fact: I haven't had any coffee today, because I'm out and now the shops are closed. <nckx>And by ‘fun’ I mean ‘horrible’. <lfam>I'd email you coffee if I could *raghavgururajan is triggered to have ☕ *nckx , panting, begins to wonder why everyone looks like a coffee cup and smells so good... <ss2>nckx: I owe you a cup of coffee for sure now. Thanks a lot! I'll have a closer look at the changes you made there. :) <nckx>ss2: In 2038, when we're allowed out of the house again and you ever make it to FOSDEM, I'll take you up on that, but that's what we're here for 🙂 <nckx>I ruthlessly deleted your out-commented update check disablement &c. that we probably want to keep. <civodul>cbaines: do you have a reproducer for the sqlite segfault? (and debugging symbols too :-)) <lfam>I guess there won't be any trouble having coffee at the Guix Days this year ;) <nckx>I won't be able to make it but hope you have a blast. <apteryx>OriansJ: OK, and you specifally want to *not* use the binary substitutes? <OriansJ>apteryx: well one can not provide a check for the guix build farm if one is using the binaries it builds for everything <apteryx>just checking, as it would have probably allowed you to 'guix pull' successfully. <OriansJ>looks like hydra.gnu.org.pub was replaced with ci.guix.gnu.org.pub but no problem (easy fix) <OriansJ>apteryx: only if one wants to be exact when providing the steps so that others can replicate your findings exactly <cbaines>civodul, no luck with SQLite debugging symbols, I've tried pretty much everything I can think of, but gdb still says there are no symbols available. I just sat down to write a reproducer though, I'm pretty confident it'll be easy to reproduce. <OriansJ>odd guix is downloading the binaries that were already built locally <OriansJ>does guix not actually check for locally built binaries when substitutes are authroized? <cbaines>OriansJ, do you mean locally build store items, rather than binaries? <cbaines>If these are indeed store items, I wonder if there's some issue with the daemon's database, either it's got out of sync with things actually in /gnu/store or it thinks some are invalid <OriansJ>cbaines: as in the binaries which were built by guix from source code in the process of guix pull and guix build <lfam>Considering your recent message about the signing key, I wonder if something is wrong on that end? <lfam>The hydra.gnu.org.pub key was removed in June 2019 <OriansJ>lfam: that is how long it has been since I've used binary substitutes <cbaines>I'm pretty sure there are some occurances of different derivations for the same packages in the graph, so having some "duplicate in name" binaries in different store items is probably a thing <lfam>To clarify the problem you are having: You successfully built a derivation (one of those .drv files), it still exists in /gnu/store, but Guix is downloading a substitute for it anyways? <OriansJ>lfam: it appears that way unless there are more than 1 version of /gnu/store/c8w9z48vvx2a3q3k44ch9yn00wk1qwhb-libxml2-2.9.10 and a few dozen other binaries <lfam>There can't be more than one "version" of a file of a given name <civodul>cbaines: i see that sqlite is built without "-g" :-/ <OriansJ>So why download if locally built with matching hash? <lfam>I don't know. It's definitely not supposed to do that <cbaines>civodul, I'm glad you understand it :) I did try adding a "debug" output, which did make some things happen <lfam>It sounds like a very serious bug <cbaines>I'm pretty sure fetching a store item that you seemingly have can also be explained by the item being invalid, or some issue with the database. So not necessarily a bug. <civodul>cbaines: you need to add "-g" to CFLAGS in there <lfam>I would be more suprised if it was a bug rather than a misunderstanding <cbaines>civodul, great, thanks. I think core-updates is the place to add "debug" as an output too <lfam>Mainly because it's a core behaviour of Guix that has been stable for years <civodul>cbaines: i feel less pressure for "debug" outputs now, especially for things that build quickly as is the case here <lfam>Even the word "substitute" is derived from this behaviour <OriansJ>lfam: ok; how did the item become invalid if built by guix on a system with ECC memory? <lfam>I would guess something happened to the database (found in /var/guix/db) or your computer's own signing key changed for some reason <civodul>"invalid" is to be understood as "not in the ValidPaths table of the database" <lfam>I don't know how that would happen. Thinking about it I realize that I don't even know how to effect that change <cbaines>civodul, you know more than me about this, although I think installing debug outputs is quite convinient (at least it seems like it should be) <OriansJ>lfam: could the signing key change when you do guix archive --authorize ? <OriansJ>or what if the local signing key wasn't in the acl? <lfam>I might even be misunderstanding how "authorization" works in the local context <maav>civodul: is the guix-artwork/website/.guix.scm being used to build the web page? or is there some other process do do that? <lfam>OriansJ: That command should add new keys, not invalidate old ones <OriansJ>lfam: but the default contents are empty <lfam>The contents of what are empty? <cbaines>civodul, while you're here, I've got a draft of a blog post on the Guix Data Service, but I'm not sure what to do with it next? <maav>i say that because it's using glibc-utf8-locales and they're missing the next locale for the web page, so i had to change it locally to generate it ^.^ <lfam>Right, you don't need to authorize yourself OriansJ. I am probably misunderstanding how "authorization" works in the local context <civodul>cbaines: i'm happy to give it a look if you want! <civodul>maybe you can commit it under drafts/ and give people a heads-up here <cbaines>civodul, like, just commit to guix-artwork and push? I think putting it in drafts first sounds better. <cbaines>If that's the next thing to do, I'll push it as a draft sometime this evening <lfam>I think that only "nars" are signed, and they are used to move things between computers <OriansJ>only when one runs guix archive --generate-key does it become populated with the local key <civodul>cbaines: yeah, you can put it in drafts so people can comment <apteryx>/run/current-system is not switched after a 'guix system reconfigure', correct? <lfam>Maybe you can check the database file itself, to see if these files are in the "ValidPaths" table <lfam>I think it is apteryx, hence the existence of /run/booted-system <apteryx>ah, I'm actually using 'sudo guix system switch-generation X', perhaps that doesn't do it <joshuaBPMan>Hey guix, odd question, when guix finally replaced the C++ build daemon with a guile one, would that "slow" down the building of packages a bit? Isn't C++ a wee bit slower than guile? <apteryx>C++ is about as fast as C, or as fast as you can get with a programming language. <lfam>It could have some effect, but I think that main source of slowness is in actual compilation, not guix-daemon activity <OriansJ>joshuaBPMan: well the build daemon isn't actually building anything but rather spawning the processes that do the build <lfam>Additionally, IO bandwidth and latency dominates in many cases <lfam>(Use tmpfs if you have the RAM) ***card.freenode.net sets mode: +o ChanServ
<zimoun>cbaines: cool for the coming soon blog post. :-) <zimoun>civodul: did you do something about NEWS today? <cbaines>zimoun, thanks, I'll let you know when I've pushed the draft, just in case you feel like proofreading it... <zimoun>cbaines: I will proofread with pleasure :-) <zimoun>and thank you for foss.events. Now the Guix Day is visible. :-) <apteryx>lfam: yes, reconfigure changes /run/current-system, but not switch-generation <apteryx>OriansJ: also note that there's an installation script for Guix available that would have probably helped avoiding the gotchas you seem to have run into <lispmacs[work]>I want to generate a channel specification file for the previous generation of my profile. Is there a way to do that? <OriansJ>looking at gnu/service/base.scm; specifically %default-authorized-guix-keys; it appears that only keys labeled '/share/guix/berlin.guix.gnu.org.pub' as the record authorized-keys appears not to be used to add additional keys anywhere. <OriansJ>apteryx: fair; however I like to understand what exactly is being done to the system so that I can learn/understand as I make mistakes (Which will be often) <civodul>zimoun: not yet... and it's getting late :-/ <OriansJ>If I just wanted a system that worked with binary blobs; Red Hat and Ubuntu have paid support. <OriansJ>It is the ability to build and understand what and why that interests me <OriansJ>One does not dedicate years of their life to writing programs in hex to bootstrap a C compiler from nothing; without being curious to understand how things work and why. <OriansJ>Just download binaries and be happy that it works; doesn't work for me. <civodul>OriansJ: i understand the frustration... but i must say this is not the tone we're used to here <OriansJ>civodul: forgive my tone and not actually frustrated today <OriansJ>just trying to figure why the behavior <dustyweb>yay, patch series for git-annex assistant sent to the list. <civodul>OriansJ: yup, understood, and people have been willing to help AFAICS :-) <civodul>(about which keys are authorized by default on Guix System & how to change that) <zimoun>dustyweb: yeah cool! I am a bit lost in the patch series <lfam>So, we are still trying to figure out why Guix is downloading substitutes for store items that already exist, right? <zimoun>civodul: late? Do you have a curfew? ;-) <zimoun>tomorrow, I will do a part of NEWS and send the result to guix-patches. <zimoun>dustyweb: that’s because I have not received (yet) all the series <apteryx>OriansJ: I'm aware of your (heroic) efforts in changing the bootstrapping landscape; I am very thankful for it! 