<lfam>It was supposed to be frozen, so I'll revert them <efraim>looks like hartmut pushed some qt-wrapping patches <lfam>It would be nice if there was some way to communicate the status of the branch <efraim>we tried once using sneek but that didn't work out well <ngz>Can something be done in a git hook so commits after the freeze are bumped back to the committer? <lfam>In the past, development was a little more coordinated, so it wasn't a big issue. But the project has grown past that point, I think <civodul>lfam, efraim: i rebooted into my "staging" system and everything's fine <civodul>the childhurd works as well, as in i can log in and all <lfam>I'm going to do a merge and do `make check` again. If all goes well, I'll push tonight <lfam>The sky is the limit with git hooks, since they are just shell scripts <efraim>Also the connman issue got me on master also so it's not related to staging <lfam>Good! (I didn't know about a connman issue) <lfam>A git hook for "but the branch is frozen" could be interactive and make you type "Yes" or something <lfam>Or it could just block the push, and if you really wanted to push, you could disable it somehow <ngz>efraim: I see you enabled unstable features in rust-libloading-0.6. However, that prevents newer alacritty from building. Do you think the snippet can be removed? <lfam>I wonder, though, if you can have multiple hooks per "action", or if it would have to be combined with the signature checker <efraim>Probably? I'm not at my computer right now <efraim>It was probably to get the tests to pass <ngz>Sorry for asking that out of the blue :) <lfam>What is everyone's favorite system test? <plattfot>Hi, I've packaged up a guile package for guix. But having some issue with the load-path on some machines. Is anyone here good with autoconf and guile? <lfam>Hi! If nobody answers quickly, you will surely get an answer eventually <lfam>Either here on in #guile <plattfot>I haven't checked in #guile yet. Figured I'll try here first instead of double posting <lfam>This channel is busiest during the European and American daytimes, FYI <plattfot>yeah, I was afraid that might be the case. <lfam>You're more likely to get an answer if you show what you have so far, and describe the problems in more detail <plattfot>When I created the patch it worked fine on my machine (still does). But as the bug report shows some users are having issues with it not finding some of the code. And I can reproduce the issue on my laptop. <lfam>Is the GUILE_LOAD_PATH correctly set in the context of the running program? <plattfot>I'm suspecting it is not and that my machine is picking up some cache somewhere <plattfot>The change I made in 2.0.2 was that I moved the load path to the script <plattfot>When it is installed the code expands to (eval-when (load expand eval) <plattfot> (set! %load-path (cons "${prefix}/share/guile/site/3.0" %load-path)) <plattfot> (set! %load-compiled-path (cons "${exec_prefix}/lib/guile/3.0/site-ccache" %load-compiled-path))) <plattfot>I thought that guile might expand the ${prefix} and ${exec_prefix} to the right paths, as it was working on my machine. But I guess I was wrong <plattfot>I think I figured out my issue, see the #guile channel for more info. <apteryx>lfam: FWIW staging reconfigured alright on my system <lfam>That's for letting me know, apteryx! <zceejkr>Hello, I just installed GNU Guix with the graphical installer on my laptop. The partition table was a GRUB partition and a system partition. But now when I try to boot, I get told that no bootable device is found. I tried both Legacy and UEFI boot modes. Any ideas what to do? <atkka>zceejkr: if the installer finished successfully, reboot into your system's bios/uefi and point to your bootloader manually <stikonas[m]>I would first boot livecd and check situation with e.g. fdisk <zceejkr>atkka so I found a menu that allows me to enter costum boot path. Is it something like /dev/sda? <zceejkr>What I mean to ask is, what do boot paths look like <atkka>it will depend on the uefi/bios probably, on mine it says something like hd(0) gpt ... and some other stuff, I can select that then /boot/efi and grub64.efi or something along those lines <atkka>but I have to do that fairly often as lots of distors don't seem to populate my boot list automatically ***apteryx is now known as Guest91811
***apteryx_ is now known as apteryx
<PotentialUser-32>I am trying to load the v4l2loopback kernel module. I have installed the eponymous package but are struggling to get the module loaded. I tried adding (service kernel-module-loader-service-type '("v4l2loopback")) to my operating system service declaration but see no effect. I am on Guix SD (inside a qemu VM). Anybody can help me please? <mroh>PotentialUser-32: you could try `(kernel-loadable-modules (list v4l2loopback-linux-module))` instead of the service, but I guess qemu could complicate things, idk. <Zaladane>I'm looking over the manual and I can't find a section that outlines this bit, but is it possible during the graphical installation process to select no desktop environment/tiling window manager and have Guix just do something like a base install --- like you would if installing without selecting one of the available DE/TWM during an installation <cbaines>Zaladane, I can't remember for sure, but I believe so <cbaines>I've used the graphical installer for servers, so I'm pretty sure I'd remember if you had to add desktop stuff *rekado_ updates main laptop to “staging” <jonsger>raghavgururajan: libchewing fails to build for me in the testsuite <Zaladane>well it didn't yell at me for not selecting a DE/TWM so I guess we'll see if it works in a bit. <cbaines>ci.guix.gnu.org is telling me it has some nars which are ~18446744 terrabytes in size! <cbaines>I'm looking at this, as the Guix Data Service is breaking when trying to store the value, as the database field doesn't support values this large <htgoebel>I'm about to hand over my work on KDE Plasma and some KDE application. <htgoebel>Is it okay to push this to some WIP-branches at savannah? <efraim>I think it's OK. Are they pretty close to master? <htgoebel>efim: kwayland currently does not build on master (and on staging) <htgoebel>efaim: But in regard to the aptchset, they are close to master/staging <efraim>what was the test that fails? I wasn't able to reproduce it locally <efraim>sounds good, it's nice to be able to cherry-pick from those branches and make it work, rather than carefully fix many conflicts <htgoebel>anyhow both for the same test-case: PlasmaWindowModelTest <htgoebel>I was not able to reproduce either, I had different tests failing :-( <civodul>cbaines: ouch, what's the deal with this narinfo?! <cbaines>civodul, no idea, I'm guessing the information in the narinfo is somehow wrong <cbaines>I know of 3 like it, which seem to specify an incorrect size <civodul>sqlite> select * from validpaths where path = '/gnu/store/qhix6afvy2a6n7hlx4qgdns461p8kdnv-repeat-masker-4.1.1'; <civodul>43262123|/gnu/store/qhix6afvy2a6n7hlx4qgdns461p8kdnv-repeat-masker-4.1.1|sha256:33328e16d8d83dcf1a6e031598dbc517aff18e6c7ccd55f7894102bab55fcdb9|1611849907|/gnu/store/rr532q5fmwj1gafdgk6nhxg9khnbsw3z-repeat-masker-4.1.1.drv|-2097113072 <cbaines>is that from the guix-daemon database? <civodul>cbaines: could you email bug-guix@gnu.org and X-Debbugs-Cc: mothacehe? <civodul>i wonder if it could somehow be due to the new offloading mechanism <civodul>could you include other faulty store items as well? <civodul>the registration time here is "Thu Jan 28 17:05:07+0100 2021" <civodul>cbaines: it's a 32-bit signed integer wrapping issue <civodul>$ guix archive --export /gnu/store/qhix6afvy2a6n7hlx4qgdns461p8kdnv-repeat-masker-4.1.1|wc -c <cbaines>makes sense, I wonder where the value is being stored as a 32bit integer? <civodul>so i suspect the 32-bit thing is a recent regression <civodul>"select * from validpaths where narSize < 0" takes too long on berlin, can't do that as-is <cbaines>when I try and substitute one of the affected store items from ci.guix.gnu.org, I see: guix build: error: integer expected from stream <cbaines>it works from guix.cbaines.net, so I'm guessing that error is because of the NarSize being wrong <mhj[m]>Heyo, just a quick question. On the site https://hpc.guix.info/ , there used to be a way to search for packages instead of browsing through them. Now whenever I go to the 'browse' link on the site I posted, you can only browse. Is hpc.guix.info part of the official guix site or is it run independently? Just wondering, because searching for packages is so much easier than browsing through them haha <mothacehe>hey civodul, cbaines! re NarSize issue, I have noticed a strange behaviour yesterday, where downloading a substitute could take ages <civodul>apparently we can still export the store item (as in "guix archive --export"), even if narSize is wrong <civodul>so at first sight i don't think this could lead to slow/stale downloads <civodul>how are store items registered with the new offloading mechanism? <mothacehe>calling ensure-path with the build node added to the subtitute-urls <mothacehe>but I was able to reproduce the stale download issue by running "guix build --substitute-urls=worker the-problematic-drv" <mothacehe>and also "wget worker/nar/lzip/the-problematic-item: <mothacehe>sadly the problematic item has been GC'ed on the worker this morning <civodul>mothacehe: is there anything that prevents store items from being gc'd from the worker before the head node has fetched them? <civodul>mothacehe: BTW, re guile-git, we can't run the ssh test in the build environment because the build user's has /no-shell in /etc/passwd (so it can't log in) <mothacehe>oh i see, would removing "openssh" from the guix.scm inputs would be enough? ***jonsger1 is now known as jonsger
***apteryx_ is now known as apteryx
<civodul>mothacehe: should be fixed now! we'll see if CI goes green <mothacehe>looks like it's green, thanks for fixing that!! <marusich>dftxbs3e, I see that when using the powerpc64le-linux bootstrap binaries, glibc-final-with-bootstrap-bash (that is the variable name; it refers to a package with name "glibc-intermediate") fails to build because there is an "undefined reference to `__mulkf3'". Since this sounds related to https://gcc.gnu.org/wiki/Ieee128PowerPC I thought you might already know what to do to fix it? <apteryx>hello! Are these errors during offloading caused by network glitches? "Throw to key `guile-ssh-error' with args `("read_from_channel_port" "Error reading from the channel" #<unknown channel (freed) 7fdc35649560> #f)'." <marusich>I think the error occurs because the glibc source code, which is for the fairly recent version 2.31, refers to these new symbols which are missing in the relatively old bootstrap gcc, which is version 5.5.0. <lfam>Is anyone using a package that depends on ffmpeg on aarch64? I see that berlin fails to build a transitive dependency (libnotify) on aarch64 <lfam>I wonder if this can be reproduced on bare metal <cbaines>lfam, I've got an overdrive machine that you could access to build things on <lfam>That would be great cbaines! <lfam>Should I send you an SSH public key? <cbaines>lfam, I can use your key in the maintenance git repository, assuming that's OK? <cbaines>you'll need IPv6, I can get IPv4 stuff working if that's a problem <lfam>I just got a new ISP that doesn't support IPv6 <lfam>Shame but it is 1/3 of the price I paid before, and several times the speed <lfam>A couple years ago I actually told their door-to-door salespeople I wouldn't use them because of this issue. But now the money is more important <cbaines>lfam, no problem, try ssh lfam@217.155.61.229 -p 2223 <cbaines>I'm hoping that in the future, it'll be possible to have a Guix Build Coordinator instance that people can submit builds to, and those builds can take place on many machines <cbaines>that's effectively possible already, I'd just need to give people SSH access to the machine it runs on <lfam>That would be really useful <cbaines>lfam, you know about substituting derivations right? <cbaines>that should make it pretty easy to test arbitrary builds <lfam>What do you mean, cbaines? <lfam>Building the derivation instead of building a package? <raghavgururajan>jonsger: That's odd. It builds on my x200-t and also on bayfront. Is yours x86_64 as well? Btw, which patch-set version are you using? <cbaines>lfam, yeah, guix publish on ci.guix.gnu.org can now provide substitutes for derivations <cbaines>lfam, which means you can do things like guix build /gnu/store/pivmcs4vrr7pszvy84mxksdvhyn899cf-libnotify-0.7.7.drv even if that derivation doesn't exist on the overdrive machine <lfam>Speaking of publish, 'tests/publish.scm' fails on berlin (although not on my x86_64 laptop) <cbaines>although saying that, I just tried that exact command, and it didn't work... <cbaines>maybe that derivation is missing from ci.guix.gnu.org <lfam>That's the end of 'tests/publish.log'. It just stops without an error message <lfam>I wonder if it's due to networking restrictions on berlin <lfam>Would be nice to be sure :) <jonsger>raghavgururajan: I already pushed a patch fixing it. The "problem" is your x200, it doesn't build with many cores, thats when the testsuite failed <raghavgururajan>jonsger: Would you be interested in reviewing and pushing Telegram-CLI (#45954)? <efraim>lfam: sorry, I was out taking a walk <lfam>I have access to an overdrive now, thanks to cbaines <raghavgururajan>efraim: Just saw your email. Will try to shorten the patch and send a new one. <jonsger>raghavgururajan: I never used it, but can give it a try. Do you have a git branch of it? <raghavgururajan>jonsger: Thanks! I don't have branch for it, but the patch-set has only 3 patches and applies over current master. <raghavgururajan>jonsger: I can send you a diff file containing all the three patches, for testing. Few moments. <lfam>cbaines: Does the overdrive use solid state storage? Or rotational? <cbaines>jonsger, that's just because Patchwork doesn't understand a bunch of patches sent as attachments <cbaines>it might actually fail as well if the patches are applied properly, but I don't know <raghavgururajan>Applies on top of commit 041a9466ea23d6ae811491bcf529bf9487317b48 in master. <jonsger>got them with wget --content-disposition out of mumi :) <jonsger>never saw that (source (string-append (getenv "TEMP") "/source")) before, but if it works <raghavgururajan>efraim: I just realized that we have been using 'pre-releases' and not 'stable-releases' for liferea. The current pre-release is 1.13.5, whereas, current stable-release is 1.12.9. Should I downgrade from 1.13.4 to 1.12.9? <efraim>we try to only use the stable releases <efraim>although there are a number of exceptions <efraim>I think we can leave it as-is, and then upgrade to 1.14.x later unless there are problems ***zimoun` is now known as zimoun
<efraim>'guix lint liferea' suggests 1.12.9 is the latest version <civodul>marusich: hi! oops, i saw it, postponed, and forgot--apologies! <civodul>so i should upload these four files, right? <kozo[m]>Is there a service that would let me run a shell command on computer startup? <efraim>mcron doesn't have vixie-cron's @reboot option <efraim>a one-off shepherd-service should do it though <kozo[m]>Thank you efraim. I'm hoping there is a blog post somewhere that has an example. <efraim>i'll see if I can whip up something that should work <kozo[m]>I want to run wg-quick on a conf file from mullvad vpn <jmarsden>I am seeing an error building /gnu/store/*-disk-image.drv (on arm-aarch64). Is this a bug in my OS definition scm file, or something amiss with U-Boot? How could I troubleshoot this further? /gnu/store/8xvmri7z0prsz61cg4v22nmkaddid6bk-genimage.cfg:14: no sub-section title/index for 'config' <raghavgururajan>apteryx and/or lfam: I just noticed that you are working on core-updates and statging. Can you merge the commits by me+danny that were reversed in master on 2020-12-01? <efraim>config-file at the last line should be conf-file <kozo[m]>Wow, that is impressive for being "whipped up". Thank you sir <lfam>raghavgururajan: Which commits were those? I don't need commit IDs for every one, just one of them. Or at least a subject line <lfam>Git dates aren't very useful <lfam>Changing the subject, libnotify does build on aarch64 bare metal (overdrive with Cortex-A57) <raghavgururajan>lfam: From 6af3045f668efe3f1e6eda30e8f7d42148e238b7 to 0f78b5c1282b3cc60d912fc58d8176b5c6703c14 <lfam>Thanks again cbaines. Having access to the overdrive is really helpful <cbaines>on the subject of arm, I've been getting arm builds (armhf-linux and aarch64-linux) going again on guix.cbaines.net <cbaines>once that is up and running, I can hopefully get arm stuff going properly on the guix-patches Guix Build Coordinator instance :) <lfam>That would be really helpful. People said the lack of substitutes (at least for armhf) were a hindrance to their usage of Guix <lfam>raghavgururajan: I'm going to push the first three commits to core-updates. After that, the old commits don't apply to core-updates, and it's not trivial to work around. Can you send updated patches for those? <lfam>Specifically, I'm going to push what was 49d38b9a44d1045133e993f372394f9d3c626a72^..f6a00057f51e43bb136f326edf670a08d125919d <lfam>If you pass that "refspec" to `git log`, you can see which they are <lfam>And you can do `git checkout core-updates && git cherry-pick $commit` to see what I mean about them not applying <raghavgururajan>lfam: Sure, let me know which commits doesn't apply. I'll send you updated ones. <lfam>The commits 5b580c0a2873010a3ae02b11bdd46a736f52bc8c^..0f78b5c1282b3cc60d912fc58d8176b5c6703c14 are reversions. Those are the ones I didn't push <lfam>For example, gobject-introspection is already updated on core-updates, but I'm not sure if your other changes to that package still need to be made <lfam>I also tweaked the original commit messages, btw <raghavgururajan>lfam: Oh, I think gobject patch has to be pushed on master, because the patch was generated to accompany a change made to gobject in master. <lfam>`guix refresh -l gobject-introspection` shows that it has too many dependent packages to be changed on the master branch <lfam>Building the following 2346 packages would ensure 6037 dependent packages are rebuilt [...] <lfam>I'm not sure if anyone has a schedule in mind for core-updates yet <lfam>I would suggest we wait at least a month to begin. The build farm is improving rapidly, and it would save more time to wait and take advantage of more improvements <cbaines>more importantly, core-updates is pretty broken at the moment, neither Cuirass nor the Guix Data Service can process it successfully <cbaines>it would be useful to fix that, before adding any other changes <lfam>I don't know if it's "supposed" to be working right now. Traditionally it just collects random patches for a while, and then later on we fix it <lfam>It might be nice to change that workflow! But it's also nice to take contributions when they are available, and since upstreams don't really coordinate (even within GNU), one major update can break the branch for months while other upstreams adjust <cbaines>indeed, I'm still hopeful for lots of workflow improvements <lfam>The sky is really the limit!