IRC channel logs
2022-11-21.log
back to list of logs
<AwesomeAdam54321>a12l: There's `guix build --source <package>` to get the source code, but it's not part of `guix shell` <a12l>AwesomeAdam54321: Thanks! Have I understood it correctly that the workflow for developing a patch for an existing package is to first runt `guix shell -D <package>` to get an development environment for the package; and then run `guix build --source <package>` to get the source downloaded into the store; after that you need to copy the source tarball into the directory where you're to work on the software? <a12l>And after unpacking the source tarball you cd into the source dir you create a git repo; commit all files to the repo; and then actually begin writing or deleting code. After that you the changes you've made to .patch files with git diff and then apply them to in your config <a12l>AwesomeAdam54321: Good to know! <kori>is there anything special about /etc/config.scm being in /etc/config.scm? is anything gonna look for it there? I mean, you gotta specify the path when you reconfigure anyway... <mirai>kori: it doesn't need to be located there <lechner>kori / with 'guix deploy', which I find far more comfortable, it is most certainly is a user directory <kori>lechner: yeah, I'm moving towards using guix deploy instead <kori>i'm still learning the ropes of guix... <kori>i'm gonna end up with something similar <AwesomeAdam54321>a12l: Not really, it's because the build phases are run in a reproducible build environment set up by the guix-daemon <kori>where can I read about the convention to prefix things with % (i.e. %base-packages) <AwesomeAdam54321>johny-cantwell: It seems the (guix ...) namespace isn't in the load path <johny-cantwell>I was unable to install guix with apt-src so I just did "apt-get isntall guix" then "guix pull" <johny-cantwell>oh, I left out full filepatch in my earlier message, it was actually in /gnu/store/(hash-here)-guix-system-source/gnu/system/images/pinebook-pro.scm <johny-cantwell>Also, it appears the pinebook image from the website lacks uboot <AwesomeAdam54321>How do I use a newer gcc/gcc-toolchain in a package definition for cmake-build-system? <apteryx>johny-cantwell: the doc suggests the bootloader u-boot-pinebook-pro-rk3399-bootloader should have been used <johny-cantwell>Does anyone know how I can get ability to build for arm on my intel cpu debian laptop? To solve the issue of "no code for module (guix platforms arm) ? <apteryx>johny-cantwell: look for qemu-binfmt in the manual, to regitser the right ARM device <AwesomeAdam54321>johny-cantwell: The Pinebook image can be built yourself and you can compare it to the image there <johny-cantwell>one more question, whole disk encryption on guix possible with luiks? <johny-cantwell>and yes, I verified again. the pinebook raw image does not boot, it lacks u-boot <johny-cantwell>so maybe the pinebook .scm file does not actually work and has not been tested? <rekado>gcc-toolchain 12.2.0 finally built on aarch64 <rekado>we should increase the timeout hints <rekado>ACTION moves on to the next missing build <sneek>Welcome back mothacehe, you have 4 messages! <sneek>mothacehe, nckx says: I've updated & restart cuirass-r-w on both POWER nodes. I'll init your password tomorrow. <sneek>mothacehe, nckx says: …which is Monday :) <sneek>mothacehe, nckx says: For symmetry, I've added you (with same password) to guix-ppc64le.sjd.se and verified that you're able to sudo. <sneek>mothacehe, nckx says: I've added the public key on berlin. <mothacehe>thanks nckx! for some reason I have a "Permission denied (publickey)" on 10.0.0.13 (assumed to be guix-ppc64le.sjd.se) <cbaines>I haven't checked yet, just pulling now :) <omlet[m]>Its good ideal make the blog about guix in portuguese and spanish? <omlet[m]>My objetive os use the plume or other fediverse alternative for first <omlet[m]>AwesomeAdam54321: But yes, nonfree is only the small tutorials <omlet[m]>But i think not is necessary speak about this <rekado>on aarch64 vim keeps failing one of its tests <rekado>Test_searchpair_timeout_with_skip <rekado>Expected range 0.001 - 0.01, but got 0.018705 <rekado>it’s always just a tad above the expected range <AwesomeAdam54321>I guess so, since tests should test functionality, not whether it times out or not <cbaines>rekado, it seems to have built on bordeaux, can you see an obvious difference in the logs? <cbaines>looking at the recent builds for vim, none seem to have that failure <rekado>I’ve attempted to build it three times on kreuzberg, and this one test keeps timing out <cbaines>what's the exact derivation you're building rekado, I'll try and reproduce? <rekado> /gnu/store/w63rj256inmn81zhsa4vfyfkmq3gp3js-vim-9.0.0820.drv <cbaines>rekado, both of those builds have now succeeded <PotentialUser-27>Hello everybody, I'm quite new here and also with guix. Currently I'm playing with GuixSD and needed to install libpthread-stubs as a dependency with a precompiled binary. I tried guix install libpthreads-stubs but libtree an the binary shows that libpthread.so.0 is not picked up. I found the lib on my disk but not as a link in .guix-profile. Can <civodul>PotentialUser-27: hi! you need to tell the loader where to look for libpthreads-stubs.so <civodul>this is usually done by setting LD_LIBRARY_PATH <civodul>as in LD_LIBRARY_PATH=$HOME/.guix-profile/lib <civodul>however, be careful with this: it will lead all binaries to pick .so files from there <PotentialUser-27>Isn't the leoader configured to look into that profile by default on GuixSD? <civodul>that will likely prevent binaries from the host distro (assuming you're using Guix on another distro) from running <civodul>if it's a precompiled binary, it's likely using the loader of the host distro <PotentialUser-27>I'm currentlky running GuixSD in a VM to see if I'll might switch to GuixSD <civodul>now, you may want to try "guix shell --container --emulate-fhs" for this use case <civodul>well then yes, you still need LD_LIBRARY_PATH, or "guix shell --emulate-fhs" for this precompiled binary <PotentialUser-27>Hmm, seems that I have to read some more through the docs. But thanks for pointing me to that info! <rekado>cbaines: /proc/loadavg says: 16.46 11.77 8.46 20/997 24882 <cbaines>that doesn't seem that high, is it building other things? <cbaines>lechner, I wouldn't look at the patchwork checks, I should probably stop creating them. Instead look at qa.guix.gnu.org/patches <lechner>cbaines / Wow, thanks! You are a powerhouse. (Btw, there are no colors in text browsers like EWW.) <cbaines>lechner, haha, this has been years in the making! <cbaines>lechner, I'll look at switching the patches page back to using CSS for the issue statuses, at that point, it should be easier to add in some symbols that make sense in EWW or similar browsers <rekado>cbaines: it built fine this time <rekado>it may be a good idea to relax the test or disable it. Not great that it can fail under expected loads. <rekado>same with the gcc 12.2 timeouts. We should increase the timeout hints for aarch64. <cbaines>rekado, sure, at least we're more sure it's load related now <lechner>cbaines / i can also take a look maybe. Does the site link to a repo? <cbaines>lechner, I should have probably asked before I jumped ahead and did it, but I've added some symbols now, and that seems to work for me in links <cbaines>there's probably plenty more issues to fix/improve though! <cbaines>civodul, I was looking to push the qa-frontpage repository to Savannah, so that I'm not the only one who can push to it. I've forgotten how to create new repositories though? <civodul>cbaines: you have to make a "support request" on Savannah <cbaines>civodul, thanks, I'll try and figure it out... :) <civodul>fun: i can't log in on Savannah, i get silently rejected or something <civodul>no error message, but then i'm just not logged in <civodul>(i was going to search for a past request so you could see) <cbaines>civodul, I seem to be logged in, I've also found some previous requests <cbaines>this isn't (insert billion dollar tech company) :D <abrenon>have you signed for some "hardcore commitment" though ? <lechner>cbaines / the symbols look great. thank you! <mothacehe>civodul: hey! i saw your changes to Cuirass, thanks! I plan to deploy a new version today on all workers, anything more to add? <civodul>mothacehe: hi! i think i initially wanted to look at something else but i forgot why <civodul>maybe something about inspecting build queues? <civodul>i thought i had something more concrete in mind <civodul>for the Berliners among us in particular <mothacehe>i created an images-version-1.4.0 specification on Cuirass <efraim>looks like we're missing a linux-libre-arm64-generic-5.15 kernel. I'll see if it's my OS config and what I can get done with my pinebookpro, but it's getting disheartening <klm_>On the latest guix (d7ba488d3505ba6), I'm getting a compile error for `guix build dxvk`. Bug, or am I doing something wrong? <omlet[m]><civodul> "omlet: the blog posts are https:..." <- Make the personal blog about guix <civodul>mothacehe: yeah, an RC would allow us to test the whole process <civodul>it's more tedious, but closer to what we'll do <ennoausberlin>When I comment issues on issues.guix.gnu.org it is not listed afterwards . Is this normal behaviour and will someone read it it anyway? I want to communicate that racket 8.7 is not built for aarch64 due to missing csh. The racket maintainers told me it is supported on aarch64 <cbaines>ennoausberlin, are you using the comment box, or sending an email? <cbaines>hmm, sending an email might be more reliable. I'm not sure how the comment box works, or if it's enabled. <rekado>when an issue is archived on the debbugs side I don’t think the comment box works <ennoausberlin>rekado: But it is not visible. I will send an email later this day <mothacehe>the cuirass database has a very large number of pending builds (268013) which makes all queries super slow. <rekado>ennoausberlin: bunch of errors in the logs for mumi.mailer <mirai>Is the subject prefix value read by machine or is it just for readers convenience? (talking about using 'git send-email' to guix-patches) <mirai>I'd like to send a "draft" patch <mirai>would a subject prefix 'PATCH wip' or 'WIP' be ok? <civodul>mothacehe: ah! would be good to see why they're not being queued <civodul>mirai: "PATCH WIP" i guess, but please make it clear in your message what's missing or what you'd like people to help you on <mothacehe>civodul: i think that they we not queued because their workers were hanging due to server going offline, but it should now be fixed <mothacehe>however that's a very large number of builds for very few workers <mothacehe>kreuzberg deploy fails due to git-minimal build timeouting on aarch64 <mothacehe>and reconfiguration fails due to guile-gnutls build error <mothacehe>nckx: i installed cuirass-1.1.0-13.1341725 on guixp9 <rekado>I’m currently building guile-gnutls with “--cores=1” to see if it fixes things <civodul>mothacehe: maybe we can delete old builds and keep recent ones? <rekado>tls13-resume-x509 still fails :( <cbaines>haha, so the comment at the bottom of emacs-xyz.scm seems to be working, I'm not seeing new packages added at the bottom <cbaines>but instead, they're being added just above the last package :D <cbaines>so maybe we need a comment there that says "not here either..." <rekado>the build log is /var/log/guix/drvs/5s/1lrwxd17hp97lxh9if6qni39qma5z1-gnutls-3.7.7.drv.gz <apteryx>sneek: later tell mirai also, preferably sent WIP patches to guix-devel, not guix-patches, to avoid crowding the queue with non-reviewable work <apteryx>(or rather, work not ready for a final review) <cbaines>apteryx, we already have plenty of blocked stuff on guix-patches, so I'm not sure that matters <cbaines>my main preference is that patches for things other than guix.git go to guix-devel <cbaines>(e.g. guix-artwork or guix-maintenance patches to guix-devel) <apteryx>cbaines: yes, items blocked for a long time (moreinfo) are a problem also <apteryx>ACTION personally wastes time going through non-actionable items on the patches tracker <cbaines>apteryx, that is a problem, but we need to come up with approaches for that anyway <cbaines>I've been using the moreinfo tag to mark things that aren't ready to be merged <cbaines>I'm not sure we'll ever be able to stop going through non-actionable items, but hopefully we can get to a point where only one person does it, then everyone else can skip on to other hopefully actionable things <apteryx>I guess we could have a policy for items waiting too long on feedback: close if the changes are too great to pursue, else the changes can be made by the reviewer <apteryx>cbaines: about ready to be reviewed items, do you think qa.guix.gnu.org could apply some user tag (with user "guix") to debbugs? such as "ready-to-review" or similar <cbaines>apteryx, potentially. I think we're getting close enough to having actionable information (e.g. these changes causes this package to fail to build, introduce this lint warning, ...) that we could be sending emails to issues <apteryx>I typically gnu-debbugs in Emacs to view items; it'd be nice to have something exposed there <cbaines>so yeah, maybe along with that there could be some tags relating to what state the changes are in <yarl>gnucode: I saw the other day you had some problems to produce latex with org-mode? I do that. Do you still have problems? <yarl>Try to tell sneek to tell you but he was sleepy. <cbaines>jgart[m], if it's still open when I do my next round of patch review, I'll take a look <jgart[m]>no probs, I just happened to come across it <jgart[m]>and I mentored disseminated dissent on that patch a bit <jgart[m]>he's was a new contributor and guix user at that time <apteryx>this should return the list of all element user-tagged in guix-patches, if I understand correctly: (debbugs-gnu '("tagged") '("guix-patches") nil t) <apteryx>I get only two items returned though, which is suspicious <yarl>I wonder if it is possible to package or write a system configuration that runs a php application that needs to be in a read-write directory? <mirai>Exactly which address should I use for multiple patches? The 'Multiple Patches' section mentions 'guix-patches@gnu.org' but the commands are all for 'guix-patches@debbugs.gnu.org' ? <sneek>Welcome back mirai, you have 1 message! <sneek>mirai, apteryx says: also, preferably sent WIP patches to guix-devel, not guix-patches, to avoid crowding the queue with non-reviewable work <mirai>and involves invoking '$(etc/teams.scm cc-members ...)', which wasn't required for the single-patch case? <mirai>apteryx: does guix-devel also use debbugs? Do I need to do some special dance with git format-patch/send-email before sending? <lechner>mirai / i think they want you to use git send-mail <apteryx>mirai: guix-devel doesn't use debbugs no <apteryx>mirai: how man commits do you have? you could simply attach them to the email as attachments (after producing them with 'git format-patch') <mirai>apteryx: It's 1 but it has a "cover mail" <mirai>so for guix-devel I can just straight away do git send-email? <apteryx>can an operating system declaration in a .scm file accept arguments from the command line? 'guix deploy my-os.scm some-arg' <apteryx>it's declarative, with bits declared from the command line ;-) <mirai>how do I invoke programs that are usually installed to /sbin/ ? <lechner>mirai / from the shell or from another program (for packaging)? <mirai>lechner: thing is, guix has no /sbin <lechner>mirai / it has a thousand. they are on your PATH <mirai>and rasdaemon is not only installed but also enabled as a service <lechner>mirai / you probably have to install it in your profile, too. <apteryx>lechner: right, I meant s/deploy/system reconfigure/, apologies for the confusion <mirai>lechner: right, doing it as root did the trick <mirai>though I get an interesting error <mirai>bash: /root/.guix-profile/sbin/ras-mc-ctl: /usr/bin/perl: bad interpreter: No such file or directory <apteryx>has anyone gotten a yubikey nano working in ungoogled-chromium? <apteryx>mirai: the executable would need their perl shebang to be patch as part of its packaging <lechner>mirai / you may wish to try something like (string-append package-name "/sbin/ras-mc-ctl") in your config <lechner>mirai / the Perl thing looks like a packaging error <mirai>lechner: from the 'root' user perspective, its not enough to have '(rasdaemon-service-type)' under 'services' in the 'operating-system' declaration? Do I also need to add 'rasdaemon' to 'packages'? <lechner>mirai / that will make it available to everyone. you could also do 'guix pull' as root followed by 'guix install rasdaemon' i think\ <lechner>mirai / the 'packages' approach is probably better <lechner>mirai / but a truly declarative approach should not require a root user at all (except for halt and reboot) <civodul>nckx: did you have any success with libreoffice on i686? <rekado>civodul: looks like kreuzberg’s disk is also about to fail <rekado>just opened an RMA claim for grunewald’s disk <rekado>smart reports are on ci.guix.gnu.org in /root <PotentialUser-30>I trty to compile and got: Run-time dependency qt5 (modules: Core, Gui, Qml, Quick) found: NO (tried pkgconfig and config-tool and Program moc-qt5 moc found: NO <civodul>rekado: i deployed the new /etc/guix/machines.scm on berlin <rekado>PotentialUser-30: think of /gnu/store as a garbled cache. You still need to have a pointer into that cache to make sense of it. <rekado>so when you compile you need to be in an environment that exposes items in /gnu/store to the tools in your environment <rekado>(via environment variables, usually) <rekado>is this a Guix package or a “manual” compilation? <rekado>a Guix package definition should fully describe the environment in which compilation happens <rekado>it is — by design — unimpressed by whatever you may have installed on your system <apteryx>PotentialUser-30: there's no qtcore, it's called qtbase <unmatched-paren>PotentialUser-30: i think you need to add (inputs (modify-inputs (package-inputs gst-plugins-good) (prepend qtbase-5))) <PotentialUser-30>OK. Already tried (gnu packages qt) - that made no difference. But i'll try plus the code above... <unmatched-paren>#:use-module (gnu packages qt) will not change your package definition... <unmatched-paren>PotentialUser-30: your inputs are basically the dependencies of the program <unmatched-paren>the difference between native-inputs and inputs is that when you cross-compile, the inputs are built for the target arch, and the native-inputs are built for the host arch <PotentialUser-30>OK. This one looks good: Program moc found: YES (/gnu/store/w4rzq607irbr3xn90n8vq0hy3snnkrnc-qtbase-5.15.5/bin/moc <unmatched-paren>so you need to make sure anything used at runtime is an input, since it'll be used on the target arch <PotentialUser-30>But how about that? Could not find: Qml Qt5Qml in /gnu/store/w4rzq607irbr3xn90n8vq0hy3snnkrnc-qtbase-5.15.5/lib AND Run-time dependency qt5 (modules: Core, Gui, Qml, Quick) found: NO <unmatched-paren>and anything used at build-time is a native-input, as it needs to be able to run on the arch that the program is being built on, not the one it's being built for <unmatched-paren>PotentialUser-30: there are a bunch of other qt packages you'll need to add to that (prepend ...) <PotentialUser-30>Perhaps the same game. I think i should do little research myself now first... <PotentialUser-30>Looks much better now - but Run-time dependency qt5 (modules: X11Extras) found: NO but not sure if really needed. I'll try first... <unmatched-paren>PotentialUser-30: ohh, there's no -6 variant, so it's just qtx11extras <PotentialUser-30>OK. Looks really good now - only wayland missing but i do not want that! So thanks again a lot for today!! :-) You are very kind guys !! <unmatched-paren>PotentialUser-30: i think if it has an optional wayland dependency you should probably add qtwayland-5 <lechner>Hi, in the system config, is there way to declare network being up as a prerequisite for an NFS file-system? <mirai>What does the 'REVISION' parameter stand for in "git send-email -1 -a --base=auto -v REVISION --to=ISSUE_NUMBER@debbugs.gnu.org" (from 22.6.2 Sending a Patch Series) <mirai>lechner: I'm also interested in knowing this, though I am using network-manager <lechner>mirai / i am also on network-manager, but in the process of switching to connman <unmatched-paren>lechner: for connman you need to (1) add the service-type (2) run ``sudo connmanctl'' to run the console <unmatched-paren>(3) do ``agent on'' (4) run ``enable wifi'' (5) figure out what your network interface is with ``ip link show'' <lechner>unmatched-paren / i haven't tried yet. i am currently reading up on all the changes i am about to make <lechner>unmatched-paren / do i need to run connmanctl or will it auto-connect eth0 when mii is detected? <unmatched-paren>(6) do ``scan wifi'' in connmanctl (7) do ``services'' to display networks <unmatched-paren>lechner: oh, for ethernet i'm pretty sure you don't even need connman or wpa-supplicant... <unmatched-paren>anyway, the big wifi_* thing next to the network is the network code, so do ``connect wifi_*'' <unmatched-paren>then it'll ask you for your password, and it'll be permenantly added to auto-connectable networks <unmatched-paren>so to add a new network just do ``agent on'', then ``services'', then ``connect SERVICE'' <mirai>the manpage / git send-email --help has no mention on what this '-v' flag does btw <mirai>hmmm... I did a git commit --amend <mirai>'-v' vanishes from format-patch <mirai>do you also experience the same issue? <mirai>that <> is just placeholder for email <mirai>I don't have any '-1' file in cwd <mirai>at least I have an editor now <mirai>though reporting this to 'git' looks like an obtuse process <apteryx>hmm, guix has been updating the linux git checkout for 96 minutes (attempting to do kernel bisect tests using git-checkout) <efraim>follow-up to my comment earlier, looks like my qemu-binfmt-service-type might've been causing me trouble <apteryx>civodul: seems guile-git/libgit2 is showing their limits on such a massive repository as the linux kernel :-) ^ <apteryx>is there an equivalent of --with-source= for an origin? git-checkout is too wasteful/expensive <PotentialUser-30>unmatched-paren: Should we do an additional nheko-qt or expand the old nheko with the "new" (in case it really works as intended) Perhaps its to much bloat for some people... <PotentialUser-30>Yes. Thats why i asked. But the maintainer missed the -Dgst-plugins-good:qt5=enabled so there is no video call in nheko... <efraim>does anyone use the qemu-binfmt-service on aarch64? <unmatched-paren>PotentialUser-30: make sure to split "Add gst-plugins-good-qt" and "nheko: Support video calling" into two different commits <PotentialUser-30>Ää sorry i was unprecise: We only have to modify the gst-plugins-good with the -Dgst-plugins-good:qt5=enabled and we have nothing to do with nheka as i understand... <unmatched-paren>PotentialUser-30: problem is that we probably don't want gst-plugins-good to depend on qt by default <apteryx>it probably already does but that's going to have to be cleaned up at some point <apteryx>gtk4 wants a bunch of gst-plugins-* IIRC <apteryx>they're "optional" but most distros include them so that would make our own gtk version crippled compared to what's expected <unmatched-paren>PotentialUser-30: we modify the nheko package to depend on -qt instead of non -qt <apteryx>it's been a while I looked at it, so you're welcome to have a look for a fresher idea <apteryx>this is just because we weren't concerned being careful before gtk4 appear. it doesn't have to. some dependencies can have their qt support split into another package, but there were a bunch of them <apteryx>but funnily, from past investigation currently gtk4 in debian also pulled qt, unless they fixed that <Fare>Can I somehow use my beefy i686 as a build farm for my aarch64 devices? <Fare>weird: it looks like I managed to get my yubikey working for all purposes... except using google on chrome! <sarahjones>What do I need to do to get pinebook pro image from guis website to boot? I have a clear emmc chip and have it disabled. I know the issue is lack of u-boot. Does the image from website not contain u-boot? <sarahjones>former image used to work from guix website. newest one from earlier today is not booting anymore. I also have two pinebook pros I attempted on, in which it was booting yesterday from sd card <apteryx>podiki[m]: thanks to the hint about yubikey/udev rules. I was able to make it work with libfido2 following your instructions! <podiki>apteryx: glad it worked! I have to update my config to libfido2 as well (and hello from emacs, my matrix server is feeling unwell at the moment) <podiki>apteryx: regarding the doc update (which overall looks good to me), did you find plugdev necessary? I have it in the udev rules but not my user for some reason <omlet[m]>After, tutorial about the guix in portuguese <lechner>sneek: later tell unmatched-paren: Hi, does gvfs require elogind? I saw you have MTP. Do you also have user mounts in your setup? Thanks! <sneek>unmatched-paren, you have 1 message! <sneek>unmatched-paren, lechner says: Hi, does gvfs require elogind? I saw you have MTP. Do you also have user mounts in your setup? Thanks! <apteryx>podiki: ah! I didn't test without it on my user. I guess if it works for you without it, it must be unncessary. <podiki>apteryx: I didn't try your chrome test though, I can when I'm back at that computer <podiki>and is pcsc service then only needed for the gpg key device functions, not for u2f? <podiki>I'll have to try with libfido2 and no plugdev spec in udev rules (not sure where I got that, if my user isn't in that group anyway...) <lechner>Hi, do we track prerequisites between services? I see guix deploy: error: failed to deploy lechner-desktop: service 'guix-publish' requires 'avahi-daemon', which is not provided by any service <unmatched-paren>which provides a shepherd service that provides the service symbol 'avahi-daemon <apteryx>there's a patch adding libxpresent supposed to fix it <apteryx>haven't had the chance to test it yet <apteryx>there's both a bug and a patch, I think <apteryx>make sure you close both if you get to apply/test it <civodul>i was thinking i'd wait and pull & retry later :-) <civodul>ACTION occasionally puts an "end-user" hat on <apteryx>podiki: haven't dabbled with gpg yet, but I'd guess it's only needed for that, yes <lechner>unmatched-paren / I did not add wpa-supplicant-service-type, but now see guix deploy: error: failed to deploy lechner-desktop: service 'networking' requires 'wpa-supplicant', which is not provided by any servic <apteryx>would someone have a suggestion to bisect linux kernels? I've define some glue in my config file that should be able to use the local checkout, but so far my experiment poiting to the source via git-checkout results in 3 GiB of RAM used and seemingly never-ending processing. <Fare>If I modify a checkout of guix and/or my channel extension to it, how do I test a package change without making a commit? <nckx>civodul: Not yet. It took so long to build I couldn't test it then :-( It should be sitting on the server by now, or its failure log is. <civodul>just to clone the thing with guile-git? <apteryx>linux kernel with bot torvalds and stable remotes fetched <nckx>panosalevro: Should work, bug reports welcome. <apteryx>civodul: I let it run like 2 hours then got fed up with it and C-c'd <civodul>apteryx: sounds like something's not right <nckx>civodul: No, I will actually test, I just haven't yet. Any changes? <civodul>apteryx: i'm not surprised it takes times (it's a full clone), but 3G of RAM means something's wrong <civodul>or it's a serious limitation of libgit2 <apteryx>civodul: can you think of a way to use the equivalent of --with-source in place of an origin? <panosalevro>nckx: i have tried 3 different guix images on ventoy and none of them work. im only using it because my BIOS doesnt seem to detect my usb unless i use ventoy. ive spent quite a few hours trying to install guix today with no luck. ive managed to install guix before without problems so im not sure whats going on <apteryx>If it could just copy the whole checkout to my store, that's probably going to be faster <Fare>reka: uh? should my channel have its own copy of pre-inst-env, or should I build guix's ? <rekado>Fare: for your channel use GUIX_PACKAGE_PATH or use “guix build -L /path/to/your/channel/modules” <nckx>panosalevro: Oh no. Can you give more details than 'no[ne of them] work'? <apteryx>nobody uses a veneable nvidia 8800 GTS with their Guix System? <a12l>How do I apply a patch on a package that's only intended for myself? <nckx>The only Ventoy-relevant improvement since 1.3 was, I believe, a longer time-out for buggy USB controllers. <panosalevro>nckx: ok, so it throws a bunch of ACPI BIOS errors "Failure creating named object", then "#### INIT NOT FOUND ####" and finally "/ventoy/busybox/sh: can't access tty: job control turned off". that's immediately after grub <apteryx>ACTION has rebuilt mutter twice today, wonders why <nckx>panosalevro: No good ones (note that I'm currently without computer, so I can't even grep gud). What's the sha256 of the Guix 1.3 iso on the device? <apteryx>podiki: for the pscd stuff, we could add another subsection catering to the gpg use case <apteryx>if what's needed is clear in your mind :-) I'd be interested to try that out too <podiki>apteryx: I think I only needed pcsc service, I didn't need the udev rules before some months ago (no idea what changed) <podiki>for both gpg card and as u2f/fido device <nckx>If 'INIT NOT FOUND' is legitimate, it never even makes it to booting Guix. That is not a Guix error. <a12l>What's the difference between `guix pull` and `guix upgrade`? Can't find a distinction in the manual <podiki>apteryx: recently got a yubikey or similar? I use it as my gpg device for pass words, encryption, all that <panosalevro>nckx: interesting, i downloaded the image from guix website <panosalevro>nckx: also, ventoy worked when installing artix just fine <podiki>a12l: pull just updates guix and package definitnions, upgrade upgrades your user packages to the new versions from a guix pull <a12l>podiki: Aha, thanks! So similar to apt's `apt update` and `apt upgrade`? <podiki>a12l: been many a year since I apt-ed anything, but I think so? <nckx>panosalevro: That is expected. Artix wasn't corrupted. 😉 <a12l>This line made me think that it both updated the package descriptions, and installed them <a12l>"To update that distribution, along with the Guix tools, you must run guix pull: the command downloads the latest Guix source code and package descriptions, and deploys it." <podiki>apteryx: I'll confirm the plugdev question on my computer later and respond on the patch you submitted. and it's a great idea, it is a FAQ I think <nckx>Just download the ISO again and check the sha256 before booting. <nckx>It should match the one I linked to above. <podiki>a12l: perhaps something to improve then; but guix is also things like guix shell, temporary using packages, etc.; I often pull but only upgrade rarely <a12l>podiki: Wait, why do you upgrade rarely? <panosalevro>nckx: you're right, ill check the sha256 in my next attempts. but ive downloaded the image so many times and guix's server is so slow the speed caps at 200kbps/s <panosalevro>nckx: btw the 1.2.0 also has ACPI BIOS errors but results in a kernel panic <a12l>Can you use an `operating-system` declaration with Guix Home? I'm trying to add a substitution server, but I can only find documentation for how to add it to an `operating-system` declaration. <nckx>panosalevro: Then the 'errors' probably aren't a problem. They happen on most systems. <nckx>I have no idea if Ventoy supports 1.2. Not worth debugging IMO, since we know 1.3 should work. (And 1.2 is even more ancient.) <lechner>when committing to master/staging/core-updates, it sometimes seems that the thresholds should not be fixed package counts but rather be weighted by how likely people are to actually use those dependent packages, and also by the burden incurred at the local level (such as likely compilation time, relatively speaking). the substitute servers might also benefit from such a change. <apteryx>texinfodocs documentation target applied to the kernel o/ <a12l>Why do I get the message "guix upgrade: warning: nothing to do" when running `guix upgrade`, if `guix pull` don't actually upgrade packages? <nckx>Missing argument to 'guix upgrade'? <panosalevro>nckx: ok 1.3.0 it is then. is there a torrent i can use to download its image? <nckx>It could print a hint that it expects a regexp and that '.' matches all packages, a12l. <nckx>panosalevro: Try tobias dot gr / guix-system-install-1.3.0.x86_64-linux.iso <podiki>a12l: well I keep an eye on what is updated and will do a full upgrade (I use multiple profiles) and a system reconfigure, it just is not every day like I have in my past <a12l>nckx: Should I run `guix upgrade .` if I want to upgrade all my installed packages? If yes, I still get the same message <apteryx>nckx: I don't think '.' is required for 'guix upgrade' at least I've never used it. <a12l>I get "guix upgrade: warning: nothing to do" both when I run `guix upgrade` and `guix upgrade .` <nckx>Does your user *have* packages installed? <nckx>If you have no packages there's nothing to do. <podiki>try a guix package --list-installed to find out <a12l>nckx podiki: Only `glibc-locales` is listed <nckx>apteryx: No idea. Hence '?'. Good if so! <nckx>If it's up to date there's nothing to do. <a12l>But I've a list of around 15--20 packages in my `guix home` config. <nckx>'guix home' is something else. <nckx>It has its own command, I dunno what it is. <nckx>panosalevro: Works here. <nckx>Just my copy of the ISO. <a12l>From what I understand I should run `reconfigure` when I want to apply a configuration change from my configuration file, but from what I know updating packages are done outside of that. <podiki>sorry, also not a guix home user, so I don't know the details for packages in that sytem <nckx>It's like 'guix system reconfigure'. Both mean 'build me a new system (using the current guix version) described by this configuration, and switch to it.' <a12l>nckx: It seems that you're right. Packages are being updated <podiki>so in this case that would include packages installed in that configuration (just like guix system), to get to a12l's question for upgrading guix home packages I think <nckx>While 'guix upgrade' sort of emulates an old skool PM, but only in your user profile (well, by default.) <podiki>yup, so guix system configuration and guix home configuration manage services but can include pages to install <nckx>ACTION is always sometimes right. <podiki>and as nckx says, you can also install packages to other profiles (like for development environments or for keeping things separate for organizational or other purposes) <podiki>better always sometimes right or sometimes always right? <a12l>I'll try to submit patches to the docs that clarifies this when I've more time. The docs didn't make it clear to me at least. <nckx>panosalevro: Did you delete the spaces and replace the dot? I just don't want spiders fetching a 700M file. <a12l>Now I understand why you don't run `guix upgrade` so often :) <podiki>patches/questions/suggestions from new users on these areas always welcome! if you don't have the full patch process figured out, you can submit what you were confused about at least <nckx>podiki: Always definitely confused now. <panosalevro>nckx: it's okay, i found an image with a good signature. lets see <podiki>a12l: depends what you use, most of what I have now is pretty stable, so I tend to upgrade quickly for things like new browser versions (security) <podiki>ACTION here not here for a while <nckx>panosalevro: You should at the very least get a *different* error, but it should really just work. <nckx>The only known bug is that short-ish time-out I mentioned above, which I think I increased on master. <nckx>And the ISO on the USB definitely matches that checksum now? <nckx>I'm repeating myself, sorry, but this means Guix never even gets a chance to boot. The GRUB you mentioned, is it Ventoy's or Guix's? <panosalevro>nckx: checksum is different again but the signature was good? i dont get it <nckx>Did you verify the signature of the ISO *on the USB*? <nckx>I frogot to add: after un- and remounting it? If the device is bad, you might just be reading the good cached data in RAM, not what was written. <nckx>The fact that you keep getting bad csums implies a broken device. <nckx>panosalevro: Check the signature? Same way you did it before copying the ISO. But with the file on the USB drive. If that wasn't the question I dudn't understand. <nckx>ACTION thumbs getting tired :) <panosalevro>nckx: now i understand what you mean. i checked the signature on my hard drive and the signature was good. now that i tried on the usb, it returns a bad signature <nckx>Ah, you probably meant GRUB. Guix's GRUB has a big honking Guix logo on it. <Fare>is the Guix logo some devil's horns? <nckx>panosalevro: Yeah, damaged bits will change the hash (and a signature signs the hash). <panosalevro>nckx: it's definitely the same file and it returns a bad signature on the usb stick. now lets try with a brand new usb stick <nckx>Oh noes, it still says GuixSD. <nckx>No. It's just a domain hack. My initials are TGR. <panosalevro>nckx: i've used a .ca domain for similar purposes (i love domain hacks) <sarahjones>anyone successfully get guix working on pinebook pro? Image from website does not boot, I think it is failing to include u-boot. <Fare>the best domain hack was dot@dotat.at <nckx>panosalevro: I got the 'idea' from Sacha Chua. 'Wait a minute', I thought, big-brainedly, and checked a registrar. I couldn't believe it was free. <nckx>I meant 'available'. But it's cheap. <panosalevro>nckx: (i realized what you meant after i sent that msg) <panosalevro>nckx: checksum is good on the new usb stick! crossing fingers... <nckx>Please just boot please just boot. <nckx>I don't remember if that was part of the joke^Wconspiracy, or if I was just in a hurry to post it. It's old. <panosalevro>nckx: checksum is all good. but i just get kernel panic :/ <pkill9>wow nckx you are onto something, perhaps Guix wasn't bestowed upon us by Prometheus after all, but Baphomet, in an attempt to restore the balance between proprietary and free software <nckx>OK, but that's (I know it doesn't feel like it) progress. It's booting Guix's kernel. It didn't before. What's the stated reason for the panic? <nckx>pkill9: I'm glad someone finally takes it seriously. <nckx>panosalevro: I have to go be social and shit. Sorry. Good luck 😕 <panosalevro>nckx: "GC Warning: pthread_getattr_np or pthread_attr_getstack failed for main thread", "GC Warning: Couldn't read /proc/stat" ... "Warning: compilation of /ventoy/init failed" then kernel panic <panosalevro>nckx: no problem, thanks a bunch! where should i file a bug for this? <Fare>When does guix transitively rebuild from source vs graft new libraries on existing binaries? How do you control the difference? <panosalevro>is bug-guile AT gnu . org the correct address to file bugs? or does guix use something else? <pkill9>I wonder how many more KDE libraries need to be added in order to add the KDE desktop environment <pkill9>since guix already has a bunch of KDE software, and I noticed plasma bigscreen just got added <a12l>How do I apply a patch on a package that I've installed using `guix home`? The patch is only intended for myself. <apteryx>civodul: guix now at 2.5g processing linux git tree after 30 minutes <sarahjones>I recommend removing pinebook image from website due to it not being tested and not working <sarahjones>so I guess guix users have to stick with the backdoored intel and amd cpus lol <apteryx>sarahjones: did you report a bug about it? <Fare>sarahjones, you think the ARMs aren't backdoored yet? <sarahjones>I'm going to see if I can build it myself with u-boot. <sarahjones>the thing with ARM, are there any known backdoors or reason to believe they are unsafe? at least intel and amd is known <sarahjones>I'm still new to pinebooks so this is a learning curve for me. and most documentation is chaotic or incomplete or lacking. <sarahjones>or very hard to find, trying to learn about how to compile and install u-boot to sd card now <sarahjones>I must say though, guix does seem promising, if I can ever get it to work. I cringe at the thought of trusting binaries, and so all about eliminating exposure to binaries as much as possible <sarahjones>and compiling things from source code is usually a large pain or impossible. I suspect most people if any don't even test if common packages actually can be built. even apt-src on Debian is a nightmare to get things to work. guix looks to make building from source easy 