<katco>ok, well, if i do a build on the pinebook pro without `--without-grafts` it tries to build again, so it's difficult to see the derivation <lfam>It tries to build when you use --no-grafts and --derivations? <katco>`guix package -i emacs --no-grafts` on the pinebook pro is downloading things and looks like it will work <lfam>I do recommend grafting for installed packages but it's up to you <katco>lfam: no, it tries to build when i do `guix build gdk-pixbuf --derivations` <katco>lfam: if i graft to install the package, that's how i get into this whole mess. it won't work =/ <lfam>When grafts exist, then it's necessary to either build or substitute the ungrafted dependency graph before --derivations will complete <lfam>I was curious if the exact same derivation that built on CI fails to build on your PBP <lfam>You could even do `guix build /gnu/store/...-gdk-pixbuf-NNN.drv` <lfam>It will just build that derivation without doing other package-y stuff like grafting <lfam>Well, unless the derivation is for a graft, of course <katco>i suspect that will succeed because that's not the problem right? it's the grafts that make it fail? <lfam>I'm trying to get the log of the failure :) <lfam>If it fails on your machine but builds on CI, we want to fix it <katco>oh you should have said so! i'll paste it, one sec <lfam>I'm sort of blundering my way through debugging this. Sorry that it's so inefficient <katco>not at all! i'll never be upset at someone who is taking their own time to help with a problem. tyvm <katco>hmmm hold on, i don't want to waste your time. `guix package -u` just succeeded on the pine after installing emacs without grafts... <katco>i'm going to do a pull on the x86_64 to see if that makes the build work... <lfam>Alright, fingers crossed! <katco>ok, no. same error. grabbing log. <katco>so on the pine, `guix package -i emacs --no-grafts` and then `guix package -u` worked <katco>`guix package -i emacs` was failing <lfam>Is there any more output at the end, that includes the .drv filename? <lfam>I do think that '"ninja" "-j" "64"' is ambitious for the PBP <katco>yes, sorry, that was the literal log file: `builder for `/gnu/store/y85rf18vbjg0040mhrgg3vi6z023a3v5-gdk-pixbuf-2.40.0.drv' failed with exit code 1` <lfam>It may be running out of memory or something like that <katco>this is running on the x86_64 <katco>this is the output of `guix build gdk-pixbuf -saarch64-linux --derivations` on x86_64 <lfam>I'm building the derivation now on CI <lfam>It's weird, it actually crashed the Guix process <katco>i agree j64 is a bit much for a pinebook pro ;p <lfam>Yeah, I'm logged in over SSH and just ran `guix build /gnu/store/y85rf18vbjg0040mhrgg3vi6z023a3v5-gdk-pixbuf-2.40.0.drv` <lfam>Hm, I tried again and it's running now. Building the source tarball first <lfam>It's offloading an Overdrive 1000 (4 x Cortex-A57 cores) <katco>i found myself considering investing in an aarch64-linux build farm today :) <katco>sbc aarch64 computers are pretty handy. and i have a pine phone here i'd like to get guix on as well. <lfam>We are in the process of improving our collection of aarch64. Finalizing purchase plans now, and also applying for some hosted resources from ARM <lfam>Our current collection is not even close to being enough <lfam>The current situation is really tough, since so many SBCs really can't handle compiling an entire operating system <lfam>Alright, the derivation built successfully on the overdrive. It should be available as a substitute in the coming minutes <lfam>We've noticed a large number of weird build failures while trying to emulate aarch64 on recent AMD chips (the build farm is AMD). <katco>ahh! that's the root-cause i've been hoping for <katco>ok, so... unfortunately offloading to a threadripper may be counterproductive <lfam>Since we only have the Overdrives, we are dedicating about half the farm to emulated aarch64 builds. It's incredibly slow and, with these weird failures, not as useful as we'd hoped <lfam>Finally, there is some solid workstation and server class aarch64 hardware available at retail now, so it's time for us to dive in <lfam>I'm hoping it helps grow our ARM userbase, by improving the experience <lfam>And really, we don't want to boil the oceans. Build once and substitutes :) <katco>well this has been extremely helpful, thank you lfam. you've probably helped me understand why other packages aren't building because of offloading <lfam>Sorry I didn't mention it earlier. It's something that's only in the back of my head, since I don't currently use ARM myself <lfam>I keep forgetting that miscompilation is a real problem for us currently :/ <lfam>I can't stop windowshopping ARM SBCs! <katco>yeah, my x86_64 laptop wouldn't power on this morning, so i dusted off this pinebook to try and help my daughter with remote learning, and yikes! <lfam>There are some great devices that really sip power <katco>i've all kinds of uses for them. but i want guix! <lfam>I also struggle with the problem of always wanting the forthcoming generation! <katco>i'll probably go with whatever pine64 comes out with next. love that company. <lfam>Yeah, they are doing awesome work. It's really inspiring to see movement on hardware from a free software perspective <katco>but i need to get back to my daughter. she needs help with schoolwork (and some company from mum). thanks for all your help! <terpri_>katco, have you seen the mnt reform laptop? <terpri_>seems like the kind of device guix hackers would be into, though i don't know offhand if the gpu works with linux-libre <terpri_>(you can in theory replace the SoC because it's on a standard sodimm module :D but there aren't alternative options yet afaik) ***circ-user-5Htxo is now known as unimog
<stikonas>if not, pinebook pro might be the better option <terpri_>ah, not quite blobless: "Almost [blob-free boot] (DDR4 controller needs non-ARM blob)" good enough for me, could maybe be reverse-engineered, but not RYF-level <terpri_>pinebooks are too big for me :( maybe'll they'll make more of the 11.6" pinebooks sometime <lfam>lispmacs[work]: We removed it because it depended on Qt 4, which was removed <lfam>It would be great to have it back, if it can work with a version of Qt that is still supported <lfam>Maybe qucs could be added there <jackhill>do we do any cross-building on the build farm? I know we spend some effort trying to make the build systems support cross-buildingβ¦ <contrapunctus>Tried cp'ing the Guix System image to a USB flash drive. Laptop detects the drive, offers it in the boot device menu, but selecting it for boot just takes me back to the startup screen ("press ESC for boot menu"). This laptop boots a Debian USB flash drive just fine. π€ ***iyzsong-- is now known as iyzsong-w
<contrapunctus>donotshake[m]: thanks for the response. "In almost no situation will simply copying the iso/img to the drive work." Oh, why's this? <donotshake[m]>Heres a quick explination on dd. It setups up the partitions and everything <donotshake[m]>there's software like Yumi that use grub, which is a bootloader that has the ability to directly boot iso. For now I would keep it simple and dd, which will make sure the usb is setup properly. <contrapunctus>donotshake[m]: oh lol - sounds like you missed this bit "Also tried dd as suggested in the manual, no difference." π cool, waiting for the Devuan ISO to download. <donotshake[m]>Sorry, I did miss that. Could be a legacy / uefi boot situation. <civodul>hi koleesch! i use Emacs EXWM, not sure if that counts <contrapunctus>donotshake[m]: Aha, I tried a different flash drive and the Guix installer is finally running \o/ <contrapunctus>...oh wut. I selected English Dvorak, but the Hostname dialogue is still using QWERTY π€ <leoprikler>afaik you have to specify your layout in several places, one of them being GDM <donotshake[m]>You probably have to get through the installation, then when the system reconfigure happens you'll be set. Or drop to console and try loadkeys dvorak <koleesch>civoduk:i will try it. I just install guix in boxes in my fedora to test for production on my mac book air. <contrapunctus>Oh. It seems the installer doesn't yet support LVM logical volumes π€ <sturm>hi folks, I'm seeing "guix package: error: corrupt input while restoring archive from socket" when running `guix install`. Is that normal, or is it likely to be something at my end (bad hard drive, bad network etc) <leoprikler>sounds similar to a bug, that should recently have been fixed <sturm>thanks leoprikler, i'll try a guix pull and see how I go <civodul>sturm: hey! the daemon is running and fine? anything in its log? <sturm>civodul: hi! seems to be running ok as it in installing things ok generally well - just seems to intermittently fail when I give it my full manifest.scm to install. It may be a coincidence, but it seems to fail on a rust package <sturm>I've just put on a stir-fry so I'll pop back in with more info in an hour or two :) ***aidalgol_ is now known as aidalgol
<civodul>there were a couple of interesting issues <mothacehe>is it ok to patch doc/build.scm on 1.2.0 branch to fix manual generation? <civodul>mothacehe: sure; what's the problem there, something with guile-lib? <mothacehe>civodul: yes, doc/build.scm from 1.2.0 uses a modified guile-lib. When building the docs from a recent Guix, the 1.2.0 doc/build.scm inherits from the recent Guile-lib, causing a build failure. <civodul>mothacehe: right; we discussed it a couple of times with lfam and apteryx <civodul>for version-1.2.0 maybe we just need to copy the 0.2.7 package definition? <mothacehe>maybe we should generate the doc in an inferior to avoid this kind of issues <civodul>mothacehe: we could, but maybe it's inconvenient, dunno <civodul>mothacehe: BTW, not sure if you saw my message yesterday, i wondered what you thought of working towards the Scheme daemon? <jeko_>$ /gnu/store/dxrwz82s34zi33n9h9cpn8sqw5pv4qyz-run-vm.sh <jeko_>Could not access KVM kernel module: Permission denied <jeko_>qemu-system-x86_64: failed to initialize kvm: Permission denied <jeko_>kvm:x:984:guixbuilder01,guixbuilder02,guixbuilder03,guixbuilder04,guixbuilder05,guixbuilder06,guixbuilder07,guixbuilder08,guixbuilder09,guixbuilder10 <jeko_>guixbuild:x:30000:guixbuilder01,guixbuilder02,guixbuilder03,guixbuilder04,guixbuilder05,guixbuilder06,guixbuilder07,guixbuilder08,guixbuilder09,guixbuilder10 <jeko_>do I have to add my regular user to the groups kvm and guixbuild? <jeko_>well I tried to add myself to kvm, not much better <mothacehe>civodul: to anwser your message of yesterday, I think that the Cuirass remote building mechanism should be made part of the Scheme daemon rewrite. <civodul>mothacehe: more specifically, do you see yourself working on the Scheme daemon sometime in the coming months? :-) <civodul>i'm asking because that seems in line with part of your work on Cuirass <civodul>and because you're one of the few people who'd be a perfect fit for the job <civodul>if that could fit into your general plan, that'd be great <civodul>(but maybe it doesn't fit, and that's fine too) <mothacehe>hehe, yes that would be a logical follow-up, but it would require NLNet to keep sponsoring me I guess. <civodul>if there's a new grant application period coming soon, and if you'd like to discuss what to put in there, we can do that <mothacehe>Yes there's a new submission period ending June 1st, I could submit that idea. <mothacehe>I also thought about p2p/ipfs substitutes + substitutes mirrors but some people may already be working on that stuff <civodul>what would be interesting is to keep an eye on extra features, such as non-root execution, or direct use as a library <mothacehe>do we have some draft plan for the Scheme daemon rewrite somewhere? maybe on old gsoc proposals? <civodul>GSoC proposals + mailing list discussions involving reepca (Caleb) <civodul>and there's a wip-guile-daemon branch, too! *mothacehe fixed manual generation <lle-bout>civodul: hello! what do you think about getting an NLNet grant for community organizing in GNU Guix? I heard NLNet is becoming more keen to that. <lle-bout>The people who want to do that need to show up, I know someone also who does it very well, Maxime, a friend <lle-bout>He's already working on some NLNet project doing it right now actually, but that will come to an end at some point <civodul>lle-bout: hi! what does "community organizing" mean? <lle-bout>civodul: something similar to LibreMiami meetups <lle-bout>I wouldnt know how to explain it with words necessarily <efraim>I would image also something like our online guix meetup last novemberish <lle-bout>Basically every time we had a meetup, including LibreMiami meetup ones, I felt like it was such a great learning experience for everyone, information flows through and all much better <lle-bout>But I also think there's more to meetups in community organizing <sturm>civodul: regarding the earlier "guix package: error: corrupt input while restoring archive from socket", haven't hit it again yet after a `guix pull`, `guix gc -d 1m` and `sudo guix system reconfigure`. Nothing interesting in guix-daemon.log, but here's the install output: https://paste.debian.net/hidden/e38206fc/ <lle-bout>I feel like to make GNU Guix development (or even just packaging) more accessible and inclusive, community organizing is a must <efraim>I also attended a C++ meetup about using conan as a dependency manager for c++. <nefix>Good morning! Is it possible to add nix packages to a operating-system definition? <lle-bout>I don't know if any Outreachy or other initiatives actually paid off in terms of actual people feeling included and staying around now and the future in the GNU Guix project, maybe more regular GNU Guix meetups would help making it a pleasing experience and have people not give up early because nobody would be here to help or else, in some way, doing community organizing would be also that probably <davidl>nefix: I don't think so, there is however a guix import nix <pkg> command, that could help you in defining your nix packages as guix packages which you could then use. <davidl>lle-bout: are there any measurements with numbers for people using and staying around with Guix? Say number of substitute downloads etc. <davidl>since mailing list archives and manual are pretty good resources for help these days, less ppl may show up in here for example. <lle-bout>davidl: I don't know I have no visibility there, probably some statistics could be made on package popularity (by the way that would be a great way to focus our efforts on what people actually use), but then there's also the political question of whether it is OK to do such statistics or not <davidl>lle-bout: I think nginx should be able to collect some data, which then could be anonymized and fed into maybe piwik/motomo for some good statistics. <lle-bout>I think Matomo is not strictly necessary also not very fit for the use case, it's some PHP thing and that part is far from being packaged in GNU Guix I feel, probably some custom counters page in ci.guix.gnu.org would do the job <davidl>lle-bout: ok. Matomo should be good at supporting both nginx logs and anonymization so thats why I thought be useful, but you probably know better. <lle-bout>davidl: I don't know better I just felt that Matomo was too intrusive <davidl>lle-bout: well its not really minimalist if thats a consideration. <lle-bout>davidl: that also, but I felt even though it's Free Software and put forward as privacy-respecting, I think the actual implementation still tracks stuff in undesirable ways, I wouldnt feel great if it was used <davidl>lle-bout: yeah something like that popcon page would be nice to have for Guix. As the page says, there's 24hours in between anonymizations - I suppose that could be a debate. <davidl>However, from installing Debian many times, I remember it's easy to opt out of that. <davidl>so basically, you may not get much data that way. <lle-bout>davidl: yes, so consent is important but also may make statistics less useful <davidl>lle-bout: I think knowing how many downloads of substitutes you have in total (losing who requested them) could be a useful measure of overall use, and I believe you could still get data pinpointed to which package is being requested. <lle-bout>davidl: agree but do we still need to get people's consent for that? <davidl>lle-bout: no, so that's a bonus. Keeping track of how many times you serve substitutes is your info. <lle-bout>davidl: for me that's all we would need but I don't know if we must still get consent for this <davidl>lle-bout: I don't see why, or in what way someone could even argu being opposed to it. <lle-bout>I feel like this kind of aggregate statistic is truely anonymous <civodul>lle-bout, efraim: i'm all for more meetings (on-line or not), indeed <civodul>Guix Days so far were rather targeting insiders <civodul>but having meetings explicitly reaching out to newcomers, like the LibreMiami meetups i suppose, would be great <lle-bout>civodul: happy to learn that makes sense to you too! <civodul>we "just" need a few volunteers for each meeting; we have machines with BBB ready to go <apteryx>civodul, lle-bout, efraim with the new rendez-vous point feature of jami (video conference), it's something we could setup easily for our needs, and not depend on 3rd party infrastructure (or javascript :-)) <zzappie>apteryx: jami is a great project but It newer worked for me and my friends. Did you have positive experience with it? <civodul>i admit i haven't yet given Jami a try, but it sounds like you have a good point <apteryx>heck, perhaps savannah could host such instances itself and have the savannah usernames registered through the new JAMS server (a way to manage users in a centralized way, such as via LDAP), although I'm not familiar with JAMS at this point. <lle-bout>Having to *install* Jami might be a barrier for some newcomers, but also Jami has had connectivity issues due to it's P2P nature, nonetheless I acknowledge it's been getting better and better and it becomes a more dependable tool I believe <zzappie>don't know but we use jami as paper post for fun. Messages usually delevered in a week. And sometimes lost :) <apteryx>zzappie: mobile device or desktop? I've had most issues with the dht proxy, when using F-Droid builds for example. <lle-bout>The wonderful thing about BBB remains that it's mostly a zero-setup click-to-join solution <roptat>lol, I received whose subject starts with [spam] ^^ <apteryx>zzappie, lle-bout jami-qt-20210326.1.cfba013 just landed on master; I invite you to try it and report any issues you may have <roptat>and that was not my antispam adding this, I don't have one :) <roptat>lle-bout, have you seen my patch for jetty? <apteryx>lle-bout: only when I noticed about them :-) thanks for the notice <jlicht>how do folks apply (huge) patch series on when you reach v{2,3,4}? <lle-bout>roptat: yes! handling CURL security patch rebasing now, also need to eat.. the rebase is non-trivial.. with high probability of mistake, I don't like those especially when security-sensitive <jlicht>s/on/ to the guix source checkout/ <lle-bout>roptat: please do seek review from other people also <koleesch>where is the configuration from guix save after i installed it? <jlicht>lle-bout: Thanks again for the offload-offer, but I should have a faster machine available in 2 weeks :) <civodul>apteryx: i think you should lower your expectations regarding Savannah :-) <civodul>i mean, it's likely running PHP from 5 years ago, so... <lle-bout>jlicht: it's a difficult one, I don't have a solution, I believe some people bake scripts for that, but rekado_ pushed something to Mumi for it, don't remember exactly how it works though! *lle-bout feels the same way about expecting GNU infra to evolve <roptat>koleesch, if you're lucky you'll find a file in /run/current-system/configuration.scm. You can't edit it from there, but you can copy it to /etc/config.scm for instance <apteryx>civodul: why? I mean, if we want something to happen, we have to volunteer and do it ourselves, of course ;-) <apteryx>also, bandali now has their feet both in savannah and jami, so it seems a good ally there :-) <civodul>apteryx: i agree; but there's a huge technical debt on Savannah, gnu.org (do you know what "CVS" is? :-)), fencepost, etc., which i think is in large part due to the "missing stair" <civodul>others on this channel know the behind-the-scenes stories better than i do <apteryx>civodul: perhaps we could prepare a Guix System config with all the services needed; then we'd have something to propose ;-) <civodul>anyhow, we could very much deploy this on our infra, esp. if there's a Guix service :-) <civodul>apteryx: i agree, though that's ignoring the social side of it: people working on Savannah do not use Guix System currently <civodul>so it's feasible, but it's a loooong-term effort (at best) <apteryx>right; it'd take time and patience (and we'd need to get involved) <jlicht>lle-bout: wait, is that change already deployed online? <vldn>hi :) i added a plugin for purple to my package list but pidgin can't find it? <apteryx>jlicht: in Gnus, C-u N | git am (you need Emacs to be in the right working directory before, e.g., M-x cd) <apteryx>where N is the number of mails to with patches to apply <jlicht>apteryx: notmuch seems to have something similar. Thanks for the pointer! ***pocketroid_ is now known as pocketroid
<crazazy>hey guys question. I was looking at the nix service for nix and more importantly the nix-configuration datatype <crazazy>and i found the `build-sandbox-items` option, but I can't find out what it does <crazazy>with no explanation what "build-sandbox-items" is <crazazy>nor is the config option specified anywhere in the nix manual <crazazy>nor is it a visible option when do `nix show-config` in the terminal <raghavgururajan>lle-bout: librsvg fails. Wasn't due to our update though. But it is a blocker for everything. <crazazy>and so since its define here, can anyone here maybe explain why "build-sandbox-paths" is in the nix-configuration datatype <crazazy>s/build-sandbox-paths/build-sandbox-items/ <cantillion>Do I need to go through specific steps to add non us locales into my guix-profile? I'm getting this kind of warning and I would like to fix it: "bash: warning: setlocale: LC_ALL: cannot change locale (de_DE.utf8)" <lle-bout>raghavgururajan: yep well :-S - lots of things on my plate now, between Zimoun drama, other IRL drama, CVE queue filling up, ..., will look at librsvg ASAP <jlicht>mothacehe: \o/. Any chance there could still be a (tiny) addendum on how to configure things without the web interface? <raghavgururajan>civodul: Any chance "Unbound variable: %outputs" for librsvg, related to your patches? <lle-bout>If I don't have people helping I feel like I will be burning out following the CVE feed if I have other things to do in parallel, if I follow the CVE feed I must not do anything else, be full time on it also not much other things other than contributing to GNU Guix *raghavgururajan didn't get any of the emails on the GNOME 40 thread at guix-devel <lle-bout>civodul: can you kick/ban jehelset at least temporarily? <lle-bout>seems /ignore on ERC did the trick for me *raghavgururajan says *Keep calm and XMPP* ;-) <lle-bout>is there a way to add tags to bugs during sending emails to bug-guix@gnu.org instead of after? <lle-bout>having to wait for the bug id after sending email just to set security tag is painful <lle-bout>raghavgururajan: for me all possible generated substitutes were built on your branch <lle-bout>raghavgururajan: can I try rebasing on latest core-updates? maybe that includes more fixes? <lle-bout>raghavgururajan: I've rebased locally, no conflits, waiting for your confirmation to push <iyzsong>raghavgururajan: hello, i'd like join the GNOME 40 party. and next day I'll look into packaging gi-docgen and gtk4. <lle-bout>raghavgururajan: are you a committer yet or not ? <lle-bout>If so, then we can move wip-gnome-40 to savannah for iyzsong to contribute more easily, otherwise we can maybe arrange for access <iyzsong>raghavgururajan: no need, I'll go sleep soon.. yeah looking forward it <lle-bout>cbaines: hello! iyzsong would like to contribute on the GNOME 40 upgrade, iyzsong you could share your public SSH key early so cbaines has time to add it until you come back <iyzsong>I'm still not sure about if i need push to cbaines's repository, maybe we can talk about it next days, thanks.. <lle-bout>iyzsong: okay! probably you can push directly to core-updates and we can pull it on our branch <iyzsong>sure, i think gtk4 can go master directly, after that I'll look into collaborate with you. <lle-bout>raghavgururajan: I am re-running builds on it now <Noisytoot>Is the Guix blog available as Guix channel news? <Noisytoot>"To sum up, yes, you could use your channel as a blog. But beware, this is not quite what your users might expect. " <leoprikler>The blog may expand on a few news entries, but I doubt it's a superset either. <lle-bout`>apteryx: hey! do you think jami-qt is better than jami-gtk? <apteryx>I will push a hot fix soon, disabling LIBWRAP <apteryx>it's unrelated to jami-gnome vs jami-qt <lle-bout`>apteryx: scrolling seems a bit floppy in the account page in jami-qt with touchpad not sure why <lle-bout`>I linked my phone, really love how Jami does that <lle-bout`>apteryx: also if you right click on the id of some contact the menu wont disappear if you click elsewhere in jami-qt, is the client mature or still new..? <lle-bout`>mothacehe: thanks a lot for adding a link to the wiki on the help page! ***lle-bout` is now known as lle-bout
<lle-bout>I like Jami but due to the absence of (public) group chat support, I never had people to talk to with it heh <apteryx>lle-bout: the group chat is almost ready (it's called swarm internally) <lle-bout>It's been long time coming I feel like Jami concentrates lots of technical expertise that has yet to benefit actual people in high numbers <lle-bout>apteryx: I think I'll use jami-gnome instead, it seems the UI/UX is more stable for me there <lle-bout>apteryx: this is my id: 1910bcfdf376bfeb95f95049a8252c302376b948 <maddo>lle-bout: as someone who wants to help with gnome40 but nearly no knowledge of guile, is there something I can help with? <lle-bout>maddo: I don't know GNU Guile much either, I think yes you could help with testing once more stuff works! <apteryx>lle-bout: gimme a couple minutes, and I'll call you <lle-bout>apteryx: oops don't think I can handle calls now but some text messages at least! <lle-bout>maddo: did you do GNU Guix packaging before? <maddo>I understand that gnome requires systemd to have basic functionality up and running, so I'm not sure how it translates on guix <maddo>lle-bout: nope, did some nix packaging tho and am an emacs user <lle-bout>maddo: I don't know yet how it affects GNU Guix, we will see when we reach the part where we run GNOME and fix remaining runtime bugs <lle-bout>maddo: we are upgrading stuff like glib, pango, cairo, gstreamer, gtk, etc. now, for now, no relation to systemd <apteryx>lle-bout: ah, sure :-) when I think jami I always think video for some reason <lle-bout>maddo: alright well I believe the best way probably is to wait until we have more stuff working then do testing <leoprikler>most of the systemd dependency should also be covered with elogind <lle-bout>maddo: however I encourage to get more familiar with GNU Guix packaging in general, it will be useful either way! <apteryx>pkill9: I'm happy to help with your problem if you can share more details <maddo>lle-bout: will do, I plan to switch my main desktop to guix (which will require some reading to be perfectly honest as to while I understand guix doesn't want to support nonfree software, it is however required to run my own pc). <maddo>still for systemd, my understanding is that it became the default session manager since 3.34 <civodul>could even be turned into a cookbook entry since it's probably a fairly common use case <mothacehe>yeah you're right, I'll see what I can do :) <lle-bout>civodul: would be awesome if --with-patch supported URLs also, for security work trying out patches quickly it's very useful! :-D <pkill9>i think all of the commandline flags that point to external data need to be able to access both local files and remote URLs <lle-bout>pkill9: great way is probably making all commands "pipepeable" somehow <pkill9>i made a mailing list post about that <lle-bout>pkill9: I saw didnt know it was you though :-D Thanks! <pkill9>i don't think you'd want to pipe things like patches <pkill9>i suppose you could give '-' as a URI so it would <lispmacs[work]>hi, I wanted to get qucs back into my profile, which was removed from Guix. I can do it with guix install and time-machine, but I prefer to use manifest files. Is there a way I could do that using channels and a manifest file? Or would I need to create a separate profile for it? <lle-bout>you can basically reference an older version of GNU Guix using inferiors *lle-bout reconfigures their system <lle-bout>I realize some times I spend considerable amount of time writing commit messages that could be automatically generated. <leoprikler>you can always add some snippets to etc/snippets :) <lispmacs[work]>hi, I'm trying to use the Inferiors example from setion 5.8 in the manual. However, my manifest file currently is of the form (specifications->manifest '("package1", "package2", ... , "package100")) whereas example uses packages->manifest instead. Could somebody tell me the easiest way to integrate my inferior package in this case? <apteryx>the wrapper scripts make debugging with GDB a bit of a pain <Frosku>Hey all, I've managed to get Guix up and running. Can someone help me to get a tor service running on startup? Right now it runs but only manually in terminal. <Frosku>cbaines: Thanks, so I can just add (tor-service-type) to the list if I'm happy with default settings? <cbaines>Frosku, it'll probably be (service tor-service-type) but yes, that should do it <Frosku>So I added that, but it's saying <Frosku>Service tor could not be started. <Frosku>herd: failed to start service tor <cbaines>hmm, I think there might be logs in syslog, so /var/log/messages maybe? <cbaines>I'm not sure how to debug that though <jlicht>could it perhaps be the issue that raid5atemyhomework ran into? With the networking service being 'up', but stuff actually not working yet? <Frosku>jlicht: I tried restarting the service manually and no dice (and I know network services are running) <Frosku>The perplexing part is that `sudo tor` works <Frosku>Apr 2 19:29:22 localhost shepherd[1]: Service tor could not be started. <lle-bout>leoprikler: I'll try, dont know much elisp <apteryx>should --with-source apply recursively? E.g., guix build B --with-source=A=some-source.tar, where B depends on A, should rebuild B using the modified A? Currently it says a warning that the transformation has no effect and returns B unmodified <civodul>apteryx: someone worked on a patch to make it recursive but that eventually stalled <Vongazi>Hello i am trying to build GNU IceCat, but it is taking a very long time, because it compiled 5 different versions of llvm and rust 1.19, rust 1.20, and now it is compiling rust 1.21, i don't understand why i need to build different versions of the same package just for IceCat to build? <lfam>Vongazi: It sounds like you have chosen not to use binary substitutes for Guix, but to instead build everything from source. Is that correct? <Vongazi>yes, the only binaries i installed were when doing guix system init, and guix pull <lfam>So, you want to build every package from source? <Telc[m]>on upgrading emacs to 27.2 I got """.guix-profile/share/emacs/27.1/lisp': No such file or directory""" <apteryx>Telc[m]: known issue. There's a versioned entry en EMACSLOADPATH that won't get refreshed until you re-login. <apteryx>There are patches from leoprikler that addresses it <Vongazi>i thought it would not take a long time, because i was running gentoo and compiling firefox takes around an hour, but now icecat has been building for 5 hours <lfam>Vongazi: The more detailed answer is that IceCat depends on Rust. In Guix, Rust is bootstrapped by building a couple dozen versions of Rust. Each version is built using the previous version of Rust <lfam>I would expect it to take a few days, if not a week <apteryx>16 hours on a Ryzen 3900X on master / 8 hours on core-updates <lfam>Unfortunately, the Rust project chose not to make Rust "bootstrappable" in any other way. I guess that Gentoo doesn't bootstrap Rust but instead use a binary blob <lfam>Or, their version of Firefox is too old to depend on Rust. I don't know <lfam>apteryx: Nice, did we improve the bootstrap chain on core-updates? <apteryx>yes, it starts at 1.29 intead of 1.19, and the tests of intermediary rust packages are disabled <lfam>I'm impressed the 3900X can do the entire Rust bootstrap in 16 hours with only 105 watts <Vongazi>lfam i just don't understand why i need to build 5 different llvm, and 3 rust versions <lfam>Vongazi: Actually, you'll need to build a couple dozen Rust versions <lfam>This is how they are bootstrapped from source code <lfam>Later versions of Rust can only be built with a binary of the previous Rust <lfam>If you don't to build all this, I recommend enabling binary substitutes <lfam>Most languages make it possible to build the compiler from source code without any blobs, but Rust doesn't do that <lfam>I have to go AFK for a bit <Vongazi>lfam oooh thanks, it is going to take a long time to compile a lot rust versions, i going to enable the substitutes <civodul>lfam: good news, the on-line manual is up-to-date, thanks to mothacehe! <Telc[m]>is there an equivalent to "guix weather" that only reports on the packages I have installed from /gnu? <jlicht>Telc[m]: you can feed "guix weather" your manifest file <lfam>The main files are 'guix.texi', which documents Guix, and 'contributing.texi', which more about how to join us :) <jonsger>We reach this goal this for x86 <- one "this" too much <atuin>what package do i need to get the stddef.h from gcc-lib? <jonsger>atuin: gcc is a hidden package, so you can not install it via CLI but maybe its included in gcc-toolchain <atuin>I have a profile (who knows when it was built) that contains it :) <atuin>n6injxy1xbg3dg54nbq2k2higw2wa5wa-profile/lib/gcc/x86_64-unknown-linux-gnu/10.2.0/include/stddef.h <atuin>I'm trying to setup clangd lsp on emacs for guile source code but seems i'm not going too far :D <jonsger>thanks for your application, seems to be a nice program and we are in society of pretty prominent projects ^^ ***Thunderbi is now known as nckx
***sneek_ is now known as sneek
<lle-bout>raghavgururajan: still building the rebased branch, at rust 1.38 now <apteryx>civodul: nice finding about that qt-build-system closure size <apteryx>that probably explains in part why my jami-qt guix pack weighs 2.7 GiB <lfam>Hey apteryx, are you still available to do the release for April 18? <apteryx>lfam: I am, yes! Although I should get in touch with civodul about the required offload machines access. <lfam>apteryx: Yes, we'll start to coordinate the details soon. I'll think I'll take over coordination from zimoun <lfam>Got anything particular in mind, lle-bout? <lfam>It's important to take a break when the work is no longer fun <lle-bout>they sent me long emails I still have to reply but it's really long I will do it peacefully later <lfam>We can talk about it more in private or later <apteryx>lle-bout: better keep the private things private :-) <lle-bout>lfam: I pinged libupnp guys, it seems they didnt fix it yet <lfam>Some of them are not very "release-y", but we will decide what to do <lle-bout>lfam: I don't find the UI/UX very nice to check for blockers, probably debbugs is better at it <lfam>Yeah, I am looking at the debbugs page <civodul>apteryx: oh, great that you're volunteering to do the release! <lfam>I think that things like "Fresh install of 1.2.0 can't guix pull" are the most important bugs to check on, and to make sure they don't happen again <apteryx>civodul: Yes, I'd like to, if that's not too much of a ball and chain :-) <lfam>There was a bug about the missing init scripts in the release tarball, and that was fixed. That's what I mean by "release-y" :) <apteryx>as I'll probably need a couple tips along the way <cbaines>civodul, I'm back testing threaded TLS connections, I now can reproducibly crash Guile... guile: ports.c:2900: scm_i_write_bytes: Assertion `written == count' failed. <lfam>I'd like to test the generation of the release tarballs and the installer next week, and I'll test installing Guix System on x86_64 <lfam>It would be nice to test installing on an ARM system <lfam>I don't have any hardware so I can't do that <lle-bout>can't build much there but I can install <civodul>cbaines: ah, that's getting interesting! <lle-bout>It's the router from my ISP, they added a feature to create VMs on it somehow, and it runs on arm <apteryx>I'm having an issue with Docker still; it won't build opensuse tumbleweed images to to some update missing from runc IIUC (they have some kind of syscall whitelist, and it needs to be updated for new syscalls used by the glibc in tumbleweed) <lfam>That will be great lle-bout. I forgot, but we should also test installing in a VM <lfam>That's amazing lle-bout. American ISPs do not offer hardware like that <civodul>cbaines: would be nice to see if it's a GnuTLS "session record port" that's hitting the assertion <apteryx>it's been resolved by updating containerd.io/bionic 1.4.4-1 on Ubuntu, I guess I should look at updating our containerd package <vagrantc>i have a few armhf and aarch64 systems i could run tests on <lle-bout>vagrantc: also somehow offloading doesnt work on aarch64/arm with Debian Bullseye <lfam>Next week we'll build some pre-release "artifacts" and make them available for testing <apteryx>lfam: I only have a TS 7970 board laying on my desk. Not sure if that could work (it's an old i.MX 6 based board) <vagrantc>lle-bout: i suspect there might be problems with the libssh dependencies <lfam>apteryx: Yeah, I think that would be useful to test armhf <vagrantc>lle-bout: it's a hunch more than anything <lle-bout>vagrantc: okayy, well not sure how to debugs, errors have not been very helpful and I don't know if I can *attach* a GNU Guile debugger somehow <vagrantc>lle-bout: but i haven't tested more than very basic features ... e.g. guix pull, guix build, etc. <lfam>I didn't know this manufacturer, apteryx. Thanks for pointing it out <apteryx>we use them a lot at work, I think because their boards are fully documented and there's no NDA <lfam>NXP is the best chip maker, in that regard <lle-bout>vagrantc: I see, well, is that something you are going to be able to fix post-freeze? <lfam>Sadly NXP's fabs were both severely damaged in February <apteryx>vagrantc: they cater to the 'industrial' market, so it's probably not that impressive hardware side. That i.MX 6 has a quad core and 2 GiB of RAM IIRC. <lfam>They lost power for over a week due to cold weather in Texas <lfam>And thus the equipment froze, and then thawed <vagrantc>lle-bout: when i have more than a hunch to work with, i'll have a better idea :) <lfam>Basically total destruction for a semiconductor fab <vagrantc>lle-bout: depends on the severity and the intrusiveness <apteryx>lle-bout: would you happen to know if updating containerd to the 1.4 series is doable? we're currently using 1.3.10 <vagrantc>lle-bout: i also don't have a firm handle on all the moving parts involved in offloading ... i set it up a few times a year or two ago <lle-bout>apteryx: I don't know much about docker, I did the security update last time but <lle-bout>If we have the go importer now at least we have help <cbaines>civodul, I've managed to muddle through using GDB to suggest that it is, write bytes is called with a gnutls-session-port <lle-bout>lfam: seems you didnt signoff my commit you pushed but fine <apteryx>lle-bout: yeah, it's great until a go package relies on go modules <lfam>The info is still available in `git show --format=full` <lfam>sign-off is just to make it easier to see <apteryx>it's more to do with the go build system <apteryx>we should make a GOPROXY build union ala Gentoo <lle-bout>apteryx: so you want to upgrade docker for this release? <lle-bout>but since this is a frontend bug, I do not know if we ship that <lle-bout>it seems we do, as "front-end" output in zabbix-server <apteryx>lle-bout: I'm checking if I can get away with just containerd/runc <apteryx>it's not clear from this report what needs to be updated, but from experience it seems to resolve around having a recent containerd package (not sure if that includes runc on debian, I'm guessing so) <apteryx>another bit that may be required to update could be libseccomp <apteryx>actually I had already tried recent versions of containerd and runc, and it was not enough on Guix System the last time I tried (I still have the branch) *apteryx checks libseccomp <apteryx>I see containerd depends on libseccomp <lle-bout>IIRC containerd, docker etc. is behind by several so.. <lle-bout>Also I think maybe we should ship Podman instead, maybe it's easier to package even <lle-bout>oops it seems 'TESTS="zabbix" make check-system' fails on master <lle-bout>apteryx: as you said earlier, I think it's containerd/docker that would include the rules, not libseccomp <apteryx>perhaps debian has backported that commit <lle-bout>so it seems running system tests is broken on master