IRC channel logs

2021-03-10.log

back to list of logs

<nckx>Regexes are too useful to drop, but that second behaviour sounds good. It's just tweaking the order after all, it won't fail to find things the user expected.
<lle-bout>nckx: I never said to drop regex just to clarify
<nckx>Oh, you mean rename the packages, I see. That's seems overkill too though.
<lle-bout>non-technical users can't be expected to know regex
<lle-bout>so definitely shouldnt get in the way
<kcurtet>lle-bout: I think regex its fine. I just need to escape special chars
<lle-bout>Second option sounds amazing
<nckx>lle-bout: Getting in the way is too strong but your second (amazing? OK :) option would improve ordering without breaking things, which sounds perfect.
<nckx>kcurtet: A few. You can change the hard-coded path to ld*.so using patchelf, or on Guix System you can create a symlink in /lib automatically. You can also patchelf each library location individually, or you can install all required libraries into a profile (e.g., using ‘guix install’) and add $HOME/.guix-profile/lib to LD_LIBRARY_PATH, or a few other similar hacks.
<kcurtet>Nice!
<nckx>There are multiple ways to do it, all of them a bit dirty, but the fact remains that Guix/Nix don't cater to seamlessly running third-party binaries. It's just not a priority.
<nckx>Be prepared to have to learn a bit to get them to work ☺
<kcurtet>I see. maybe i can clone the package recipe for node 10 and upgrade it to 15
<lle-bout>We maintain a non-trivial downstream patch to qemu to build info manuals, it doesnt apply on qemu 5.2.0, would be nice if it got merged
<nckx>kcurtet: That would be the Right Way!
<nckx>I'd be amiss if I didn't point out that it's probably not trivial (we'd have node 14/15 already if it were), so plan accordingly.
<nckx>Oh, it seems there is/was a wip-node-14 branch.
<nckx>I don't know what the status is.
<apteryx>lle-bout: it got mostly merged already
<kcurtet>Its because i have a library @hapi/hapi it dosen't support node 10
<kcurtet>O nice
<apteryx>lle-bout: lfam made a patch to update 5.2.0 that gets rid of it
<apteryx>(while preserving the info manual, I believe)
<pkill9>can i change the user's home directory in a guix container, without simply changing $HOME (it seems that programs use the 'real' home folder vs $HOME environment variable)?
<kcurtet>My ouput of ldd https://dpaste.org/vZrm i need just 2 libs?
<pkill9>well -u changes the user and home directory, so it is definitely possible
<pkill9>just seems to be hardcoded i guess
<nckx>pkill9: $HOME is the ‘real’ home directory, so how would they know? If it's a subdirectory of the original $HOME, maybe they're using $XDG_...?
<lle-bout>apteryx: it says it drops the patch and doesnt build an info manual but no big deal I think, we should submit such patches upstream first I think
<pkill9>nckx: maybe from the passwd file? idk
<lle-bout>apteryx: didnt see the patch to update qemu from lfam so thanks
<lfam>It's on the patch tracker
<nckx>pkill9: Old school.
*nckx tried to get into a container to see what's virtualised and what's not (like /etc/passwd) but kernel says no :-/
<kcurtet>ls
<pkill9>maybe it's getting the HOME var before it's been changed by guix
<pkill9>specifically when i run fish
<lle-bout>lfam: issues.guix.gnu.org search's a bit bad heh, so had to go with <https://yhetil.org/guix> to find <https://yhetil.org/guix/YDnFzUxSfPQVxmht@jasmine.lan/#t>
<pkill9>it puts me in my 'real' home dir, rather than the new $HOME var
<pkill9>also mesa shader cache keeps getting put in the 'real' home directory inside the container
<pkill9>so I'm wondering where they're getting them from
<lle-bout>lfam: trying to patch CVE-2021-20263
<nckx>pkill9: Here, ‘HOME=/tmp fish’ respects it and ‘HOME= fish’ prints ‘Please set the XDG_DATA_HOME or HOME environment variable before starting fish.’ So... maybe, although I don't actually know fish at all.
<nckx>pkill9: So ‘cd’ in fish doesn't change to whatever $HOME is set to in fish? Or...?
<kcurtet>Any guix command to copy a recipe? or i need to go to the repo
<lle-bout>lfam: apparently the security bug is only in a feature added in 5.2 so we're safe
<pkill9>nckx: I mean when you start it it starts in the real home dir, but typing 'cd' it goes to new one
<lle-bout>lfam: but for your patch, I think you should actually patch it
<lfam>You mean apply it?
<leoprikler>doesn't any shell start in the PWD of the previous one?
<lle-bout>lfam: yes
<lfam>I'd like to do it soon
<nckx>kcurtet: ‘guix edit PACKAGE’ will open the file in your $EDITOR, and you can save/copy it elsewhere, but actually saving it to the same file won't work.
<kcurtet>nckx: thx
<nckx>pkill9: fish doesn't chdir on start, it just keeps the current pwd, so maybe that's expected here.
<nckx>(Again, unable to try in a container, but that's what happens without one. cd /blah && fish → fish in /blah → cd → fish in /home/nckx)
<apteryx>lle-bout: the original info patch was submitted upstream here
<apteryx>this was the version working on what became 5.2 (ninja build system)
<pkill9>after removing --no-cwd it seems to stay in previous directory now, maybe --no-cwd puts you in real home dir
<nckx>Unless guix env -C chdirs, I think fish is acting normally. Less sure about mesa. Might be related.
<lle-bout>apteryx: alright!
<apteryx>lle-bout: there was an email exchange that followed and their way to build the doc was revised (not sure this landed in 5.2)
*lfam tries and fails to make a simple-service of sysctl-service-type
<lfam>Not so simple after all
<pkill9>ah yea
<apteryx>which should make it trivial to build an info manual (hopefully it should be as simple as a configure flag)
<nckx>pkill9: It does no such thing, but maybe that's where your starting guix env...
<nckx>Or something in the way you start it is doing so.
<pkill9>nckx: if i run `guix environment -C --no-cwd --ad-hoc fish` it puts me in my homedir
<apteryx>lfam: perhaps the changes didn't make it to 5.2? In which case the patch published https://patchew.org/QEMU/20200925024143.26492-1-maxim.cournoyer@gmail.com/ could be used in the meantime
<nckx>Errr, correction pkill9, it does so on once machine and not on another.
<nckx>What the.
<pkill9>(if i run that while in /tmp directory)
*nckx stares at screen.
<pkill9>nckx: if you use the -u option to change the user, which also automatically changes the homedir, it changes directory
<pkill9>maybe guix is getting the real homedir from real /etc/passwd, and then changing to it, idk
<nckx>OK, if I remove the 500+ line bashrc on the ancient box acting weird it works as expected, quelle surprise.
<nckx>pkill9: You are very correct.
<pkill9>aha yes
<nckx>(mkdir-p home-dir) (setenv "HOME" home-dir) (chdir (if map-cwd? (override-user-dir user home cwd) home-dir))
<nckx>and, last for dramatic effect: (home-dir (password-entry-directory passwd)).
<pkill9>well that solves that mystery
<i1l>sneek: seen pipeware?
<sneek>Not as far as I can remember.
<i1l>damn, sneek! thou also not an part of "we".
<i1l>what bugs me, is that nothing better than alsamixer was found by me. new protos are, but where are the "things"?
<lle-bout>nckx: upstream git release key 'E1F036B1FEE7221FC778ECEFB0B5E88696AFE6CB' does not have non-sha1 self-signature, so what do we do?
<pkill9>why can i not access this in guix repl or guile :( (@@ (guix scripts environment) launch-environment)
<lle-bout>e.g. guix refresh can't verify releases
<i1l>pkill9: guess: it is an macro (launch-environment) maybe?
<lfam>lle-bout: I think we just ignore it. One could ask the upstream to upgrade their PGP or whatever they should do
<pkill9>i1l: it's in define*
<nckx>lle-bout: I don't have a better (non)solution than to disable that line in your gpg.conf. It's just not tenable to keep working around the rest of the world.
<lle-bout>nckx: just did so hopefully temporarily, thanks
<nckx>I guess it happens to work for me because I never use ‘guix refresh’.
<nckx>And don't let friends use SHA-1.
***sturm is now known as sturm11
<nckx>But meh, sucks.
<nckx>Wish I had a better answer lle-bout.
<lle-bout>nckx: we should tell upstream to change
<lle-bout>not sure who to send an email to though..
<lle-bout>updating git to 2.30.2 on master, that OK? it doesnt have <300 dependents
<lle-bout>(it has security fixes)
<nckx>If you have the energy to do so, please do! :) I'm too de{ple,fea}ted atm.
<nckx>Er, the mail.
<nckx>How many dependents does it have?
<lle-bout>nckx: 119 IIRC - but it surprised me it is so low
<nckx>Mine says 191.
<lle-bout>191 maybe
<nckx>‘doesnt have <300’ → typo then?
<lle-bout>yes sorry
<nckx>No problem. I've always updated git on master too. Go ahead.
<nckx>(It's always possible that some change would cause that number to skyrocket, so thanks for paying attention.)
***sturm11 is now known as sturm1
<i1l>pkill9: do not be greedy. show the errors.
<pkill9>it just says error: launch-environment: unbound variable
<nckx>I don't follow Guile dev closely but I think that @@ is no longer something you can count on working in 3.0.
<pkill9>oh, why's that?
<nckx>Either it only sometimes does or it always doesn't, I'm not sure.
<nckx>Er, declarative modules something something.
<i1l>bingo.
<nckx>Being incompatible with the @@ hack so it had to go.
<i1l>i mean, i used this thing in config.
<i1l>aren't it was seen in Guix packages sometimes?
<nixo>Hi guix, it's super late so I'm going to sleep, but I just tryied to upgrade guix and got a failing graft
<nixo>pstoedit-3.75: replacement length differs from the original length "vlix7fclb7ifjgmxgpwr1pvraff89w7b-imagemagick-6.9.11-48" "mf0y39m4n8j9g189pyv7idc69k0dgr3w-imagemagick-6.9.12-2"
<pkill9>so there's no alternative to @@?
<nckx>nixo: The version has to be exactly the same length, because a graft is a filthy naive string replacement in binaries.
<nckx>So you have to lie, basically.
<nckx>Drop the 8 or the - or whatever offends you least.
<i1l>pkill9: copy-paste needed things to an separate module.. then maintain synchronisarion with upstream. that what all serious dudes do!
<i1l>flatguile.scm
<nckx>lle-bout: Thank you for fixing all the CVEs.
<kcurtet>
<kcurtet>> Im building a service for emacs --daemon but im not sure witch
<kcurtet> command tu use for #:start () `make-forkexec-constructor' seems to
<kcurtet> kill the process and restart but not sure if its the #:stop
<kcurtet> command (make-kill-destructor)
<nixo>nckx: but that is already on master
<nckx>Guix 1.2.1 CVE-free edition.
<nckx>nixo: Oooh dear.
<nckx>Thanks for reporting it.
<nixo>However, with --no-grafts it did work so I'm fine, but maybe it should be fixed
<nckx>It definitely should, thanks. What command was that? guix pull?
*nckx was also about to go to bed...
<nckx>lle-bout: Could you take care of that first? ☝
<i1l>wait. Guix has no pre-defined service for Emacs?
<i1l>just grepped the Manual.
<nixo>nckx: I'm runnign 'guix package -m manifest.scm'
<nixo>running*
<nckx>i1l: Those who run emacs as a service do so as their own user. Shepherd user services aren't (...yet?) handled by Guix.
<lle-bout>nckx: uhm problem with imagemagick?
<nckx>Yes. Mind if I revert 82e887ba48c2ba91b17aa9b6b17501e3e0ef4aef?
<i1l>nckx: bbut.. i saw Emacs service in Nix.
<nckx>lle-bout: (I have only to press return.)
<lle-bout>nckx: will trim version
<lle-bout>now
<nckx>OK!
<nckx>Thanks
<nckx>*!
<i1l>kcurtet: you do like this: https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/services/ssh.scm#n190 ?
<nixo>thank you, good night!
<nckx>Good night nixo.
<nckx>i1l: Yes, and it's ‘Whether to enable a user service for the Emacs daemon’ :)
<nckx>Guix System only configures system services for now.
<i1l>nckx: was systemd not ised due to reproducibility, btw?
<nckx>You *could* (probably?) run emacs as your user that way, but it ain't right.
<nckx>i1l: I don't think so, simply that the Shepherd (previously: dmd) already existed and is written in Guile Scheme.
<nckx>Synergy & all that. That systemd is explicitly Linux-only (no Hurd support) might have been a factor even then, but I don't know about that.
<nckx>Maybe we just got lucky.
<lle-bout>i1l: the GNU Guile Scheme extensibility feature is the main argument to me.
*nckx not anti-systemd, no shoot.
<lle-bout>Actually using systemd would've probably saved us lots of hassle, but GNU Guile Scheme extensibility is also really good and important in GNU Guix. Opens so much possibilities.
<lle-bout>GNU Guix is 'GNU', so if there's the opportunity to use GNU software I think it is preferred.
<i1l>did anyone used lsh ever, btw?
<nckx>Probably.
<lle-bout>i1l: not that one though, I should try
<i1l>lle-bout: not sure if It alive..
<lle-bout>but to be honest here, I try openssh more w.r.t. security considering lsh's much less popular and gets less auditing.
<lle-bout>I trust *
<nckx>i1l: Believe it or not, there was no openssh-service when I started using Guix in 2015, only lsh. So very many people have used it. Well, as many as used Guix.
*nckx → finally 😴♥
<nckx>o/
<lle-bout>nckx: good night!
<i1l>+1
<bone-baboon>I would like to look at some package modules. Where are they located on a Guix system?
<lle-bout>bone-baboon: guix edit <pkg>
<lle-bout>You wont be able to edit source files this way but you can inspect them. To edit, clone a local copy then use ./pre-inst-env guix edit <pkg> - see manual for usage of pre-inst-env etc.
<bone-baboon>lle-bout: Thanks
<bone-baboon>Section 10.1 Using the Configuration System of the Guix manual mentions unambiguous package reference like `(list bind "utils")`. It mentions a downside of this approach is that you need to know what modules defines a package. What is a good way to find out what module defines a package?
<pkill9>how much memory/CPU does a guix container use?
<pkill9>is there much overhead?
<lle-bout>pkill9: it's a Linux container so not much no, but do calculate it more precisely.
<lle-bout>bone-baboon: "guix show <pkg>" will tell about the filename the package is defined in (ending in .scm), GNU Guix uses file name without extension as module name AFAICT.
***qyliss- is now known as qyliss
<Gooberpatrol66>Is it possible to generate a Btrfs RAID configuration from config.scm?
<bone-baboon>lle-bout: Thanks
<morgansmith>hey in commit c05ceaf2b650d090cf39a048193505cb4e6bd257 a comment near the top of tests/lint.scm (line 64) should have been deleted but was not. It's a super quick and easy thing so I'm hoping complaining here will fix it.
<bone-baboon>`guix show git` has a location field. If I search for a module using it's location `locate gnu/packages/version-control.scm` there are many files that match the search that have different hashes. If I want to read the module which one should I be looking at?
<morgansmith>bone-baboon: try `guix edit git`?
<apteryx>dongcarl: I narrowed the issue to dbus-c++; for some reason attempting to use this from Guix to build static libraries would result in the previously reported errors. I think we may be missing patches to our dbus-c++ package, compared to debian and others.
<bone-baboon>morgansmith: Thanks
<bone-baboon>I am using Emacs and ansi-term. When I run `guix edit git` it opens `nano` in the Emacs ansi-term buffer. Is there a configuration variable I can set so that it just opens the file in a regular Emacs buffer?
<morgansmith>so if you run `M-x server-start` then you run the emacs daemon. This is nice because now you can send things to that daemon and it will pop up in your emacs. Then you can set you $EDITOR var to emacsclient. emacsclient is the executable you use to interact with the daemon
<morgansmith>alternativly, you could decide to not use guix edit. the location you found is relative to the root of the git repository (Only true if the package your looking at is not from a 3rd party channel). I'm not sure where that reposity is located on your local disk, but you could obtain a new copy from here: https://git.savannah.gnu.org/git/guix.git
<bone-baboon>morgansmith: Thanks
<bone-baboon>What is the signifigance of the "gnu/packages/version-control.scm" file that `guix edit git` opens compared to the other "gnu/packages/version-control.scm" files that are located with `locate gnu/packages/version-control.scm`?
<lle-bout>bone-baboon: the other copies could be cached versions that GNU Guix kept
<bone-baboon>lle-bout: Thanks
<lle-bout>mbakke: See: https://issues.guix.gnu.org/issue/47033 - xdg-utils wrapping in ungoogled-chromium
<morgansmith>so how do I actually use data.guix.gnu.org? I want to show someone that emacs-flymake-shellcheck is bust by sending them a link. Can I use data.guix.gnu.org for this purpose? And if so, how?
<lle-bout>morgansmith: bust as in..?
<lle-bout>morgansmith: if you are talking about failed builds, then you use ci.guix.gnu.org rather
<morgansmith>guix build emacs-flymake-shellcheck == *sad noise*
<morgansmith>ah
<morgansmith>oh. yes ci.guix.gnu.org is wonderful and is exactly what I wanted. Thank you very much!! :D
<raghavgururajan>> apteryx‎: sorry, I've forgotten once more; what exactly do I need to do to have icons available in a pure environment?
<raghavgururajan>For gtk, --ad-hoc hicolor-icon-theme and adwaita-icon-theme, with or without dconf.
<apteryx>raghavgururajan: I've tried that in a pure environment but jami would still lack some icons
<apteryx>gtk+ is included in the profile, so XDG_DATA_DIRS is defined
***iyzsong-- is now known as iyzsong-w
***iyzsong-- is now known as iyzsong-w
<raghavgururajan>apteryx: Hmm.
<hapster>hello guix o/
<hapster>is anyone here using EMMS and MPD successfully? I could use some help setting it up or an example configuration :)
***ppsym is now known as PurpleSym
<mothacehe>hey guix!
<Whyvn>I am trying to build my first package. From the looks of it, it should be a very simple package to implement. But I am having issues. It is a python package and only needs to run python3 setup.py install. I am getting an error on the build phase. From looking the manual python-build-system says it does python setup.py build and then python setup.py install. My question is, how can I skipp the build phase and go directly to the install
<Whyvn>phase? I tried modify-phases %standard-phases (delete 'build) but that didnt work. this is the package declaration I have so far http://paste.debian.net/1188632/ I am sure I am missing something obvious...
<lle-bout>hello mothacehe! :-D
<lle-bout>mothacehe: I have something to discuss with you!
***apteryx is now known as Guest97284
***apteryx_ is now known as apteryx
<lle-bout>Whyvn: hey, what's the error you are getting?
<mothacehe>hey lle-bout!
<mothacehe>tell me :)
<Whyvn>lle-bout: http://paste.debian.net/1188633/
<lle-bout>mothacehe: I would like to suggest you remove paging on evaluation pages in Cuirass and add ability to sort by the build icon so we can easily see new build failures in individual evaluations
<lle-bout>Whyvn: so you used a GNU Guix hash as commit, that's wrong
<lle-bout>Whyvn: also try: guix import pypi -r cryptop
<Whyvn>lle-bout: thanks that seems to make it a little easier. how do you add licenses that are not in guix licenses?
<lle-bout>Whyvn: what license are you referring to?
<Whyvn>i am getting error: license:bsd-3: unbound variable hint: Did you forget a `use-modules' form?
<Whyvn>
<Whyvn>i tried gnu packages form, but thats wrong.
<brendyyn>Is Mathieu in here?
<lle-bout>Whyvn: Add: ((guix licenses) #:prefix license)
<lle-bout>brendyyn: mothacehe?
<mothacehe>lle-bout: isn't the filter per failing builds sufficient?
<mothacehe>brendyyn: that would be me
<lle-bout>Whyvn: ((guix licenses) #:prefix license:) rather
<brendyyn>mothacehe: simple-cuirass-service test uses the code you removed and breaks the build for me
<mothacehe>brendyyn: oops, let me fix it.
<brendyyn>thanks
<lle-bout>mothacehe: well when I make a change I want to check if I made GNU Guix more broken than it was, going to fix already-failing builds is another quest
<brendyyn>lle-bout: license: with a colon
<lle-bout>brendyyn: yes I corrected a bit later as well
<gagbo>Hello, I have a small issue when trying to run a simple "guix pull", I fail building the "guix-system-tests" derivation, with a "simple-cuirass-configuration->specs unbond variable" error. Has anyone encountered this ?
<Whyvn>lle-bout: apologies for the needing of step by step guidence, but I am getting this error now error: cannot install non-package object: #<unspecified>
<mothacehe>brendyyn: it should be fixed
<brendyyn>mothacehe: thanks
<mothacehe>gagbo: it should be fixed if you run "guix pull" again.
<lle-bout>Whyvn: your manifest must return the package object
<mothacehe>lle-bout: I see, that would be a filter on "new-failures"
<gagbo>mothacehe: seems good, sorry for the noise ! (had weird timing on that one, I thought I did something wrong on my desktop install)
<lle-bout>mothacehe: yes! :-) Also fixed builds would be great too!
<mothacehe>lle-bout: I'll see what I can do
<lle-bout>mothacehe: thank you! And what about paging on evaluations, what do you think? I think the paging is useless and making navigation troublesome there.
<mothacehe>yeah I agree it's painful, maybe the Boostrap library has a better suited object for that
<Whyvn>lle-bout: is there a place in the manual that will expand upon that, I do no know what that means. From what I gathered from the package guides is using guix package --install-from-file=, would I have to append a --manifest field? Or would another entry go into the package.scm file?
<Whyvn>do not know**
<lle-bout>Whyvn: the (package ..) object needs to be last in the file, or a variable that references one
<lle-bout>Whyvn: in Scheme, values are returned when they are present last in a function or file here
<lle-bout>Whyvn: unspecified here means you have nothing last, you must be using only (define-* ..) expressions
<lle-bout>mothacehe: superb! thanks!!
<Whyvn>lle-bout: ok that makes a little more sense. yes there are two (define-public <names>)
***iyzsong- is now known as iyzsong
<mbakke>lle-bout: do you think it's feasible to add absolute references to xdg-utils in ungoogled-chromium instead of wrapping with PATH?
<lle-bout>mbakke: I tried, there's many places, also xdg-utils has many executables, xdg-open, xdg-email, xdg-mime, ..
<lle-bout>mbakke: the solution I proposed is easiest and most maintainable
<mbakke>lle-bout: OK, LGTM :)
<lle-bout>mbakke: considering the prefix, the wrapper has no downsides
<lle-bout>mbakke: alright! do you push it?
<mbakke>lle-bout: rumor has it that you can push now? :)
<mbakke>it's been so long I'm not sure I remember how..
<lle-bout>mbakke: yes I can but you reviewed :-P
<lle-bout>I can push it, will do shortly if you don't
<mbakke>lle-bout: that's great, I'm not really setup for pushing atm :)
<Whyvn>lle-bout: if python-requests is in the package repo, what would be the reason for getting and unbound variable? `(("python-requests" ,python-requests) is defined in propagated-inputs, shouldnt it be automatically pulled?
<raghavgururajan>Hello Guix!
<lle-bout>Whyvn: missing use-modules
<lle-bout>raghavgururajan: Hello! :-D
<Whyvn>lle-bout: oh yeah..
*mbakke has been trying to add a "debug" variant of ungoogled-chromium for investigating a crash on some sites, but it's tricky because the debug code is not properly "ungoogled"
<raghavgururajan>leoprikler: Examples needed more work. So I disabled it for time-being. Working on it now.
<lle-bout>mbakke: ahh... so sad..
<raghavgururajan>efraim efraim_ efraim1 : Thanks for merging #47016. Would you be able to merger related #47017 as well?
<jlicht>hey guix!
<Whyvn>lle-bout: holy hell, it worked. Thanks a lot lle-bout! its a simple package, but i am happy to have one made. I appreciate the patience and help.
<brendyyn>Whyvn: congrats
***amfl_ is now known as amfl
<Whyvn>brendyyn: thanks, it was a small victory i needed. I thought I was going to get filtered by the guix package system. I would eventually like to help contribute to more packages and documentation, but I first have to understand it myself.
<efraim>raghavgururajan: 47017 fails to build for me
<efraim> https://paste.debian.net/1188645/
<raghavgururajan>I disabled that tests.
<raghavgururajan>Lemme check.
<brendyyn>Whyvn: what do you mean by filtered?
<jlicht>Whyvn: perseverance and being patient with oneself go a long way in learning new things, congrats :)
<Whyvn>brendyyn: I woudldnt be cut out to help with creating packages with guile/scheme/guix as it would be too complex, but of course with enough time there comes understanding. I have just been bashing my head against the keyboard the past few days trying to get at least 1 package together.
<raghavgururajan>efraim: The build finishes on my end.
<raghavgururajan>successfully built /gnu/store/z4b9sha76jz1zm7kmppg841rvx7mx4xh-gajim-1.3.1.drv
<raghavgururajan>/gnu/store/h0hca6q6q9pxgj7hksd34mdmpyks4ay5-gajim-1.3.1
<efraim>raghavgururajan: I'm building on a tmpfs using stock linux-libre 5.10.19, also fails with --cores=1
<raghavgururajan>efraim: With `./pre-inst-env guix describe` = f4018716bbbf87f54fe9c9429edb51e222ef2aaa, I get "successfully built /gnu/store/zqnp5z4a1n9xmqqrdvzid8qblj7fk827-gajim-1.3.1.drv"
<efraim>I last tried on f4fd7bda51f26c3ae00c4c8681c344074739df5c, also failed before that commit
<raghavgururajan>efraim: Can you try with the below?
<raghavgururajan> https://jabber.hot-chilli.net/jabberupload/share_v2.php/9c61ef9d-e546-4354-ab8b-bd715777336d/0001-gnu-gajim-Update-to-1.3.1.patch
<efraim>raghavgururajan: that worked, not removing the old failing test. should the old linked issue remain?
<efraim>hmm, looks like a different failure, following the link
<raghavgururajan>No, the old issue is resolved in new release. But the two fails with new issue, ModuleNotFoundError: No module named 'gajim.gui.emoji_data', which is related to https://dev.gajim.org/gajim/gajim/-/issues/10478.
<raghavgururajan>So the new issue link applies for both the tests.
<raghavgururajan>Both tests now fail with same error.
<efraim>hmm, adding add-installed-pythonpath didn't help
<raghavgururajan>I'll update the issue in upstream.
<efraim>thanks
<raghavgururajan>efraim: Updated => https://dev.gajim.org/gajim/gajim/-/issues/10478
<lle-bout>so many CVEs to patch
<lle-bout>I became a CVE-smashing robot
<efraim>lle-bout: if we were able to rebase some of the ppc64le patches onto master would powerpc64le work? or are there other things in core-updates (besides gcc-8) that it needs
<efraim>and by some of the patches I mean the ones in the wip-ppc64le branch starting from where it adds the bootstrap binaries
<brendyyn>Anyone else getting bizarre http headder erros downloading substitutes lately?
<lle-bout>efraim: if someone could do that then it would be awesome, you told earlier it would be difficult, gcc-8 is only required for glibc >=2.32, otherwise some patches were taken from core-updates like gnutls, but you'll see
<lle-bout>brendyyn: yes, see: https://issues.guix.gnu.org/46967
<efraim>it looks like gcc-4.7/libstdc++, findutils-boot0 and glibc are the only tough ones. I think the rest that aren't specific to core-updates can probably be straight cherry-picked to master
<lle-bout>efraim: alright! that really sounds good!
<civodul>hey!
<lle-bout>hello :-)
<civodul>sneek: later tell mothacehe the (guix channels) changes apparently broke Cuirass: https://ci.guix.gnu.org/eval/149790/log/raw
<sneek>Will do.
<brown121407>Has anyone managed to setup a LSP for C++ in Emacs on Guix? ccls fails to recognize even basic stuff, like cin/cout. Here are more details about my problems: https://lists.gnu.org/archive/html/help-guix/2020-11/msg00115.html
<raghavgururajan>leoprikler: I have CCd you on #47042, with regards to enabling examples for QtSolutions.
<jx96>Is anyone trying to compile rust-cargo-c 0.7.3+cargo-0.51?
<raghavgururajan>Folks! With this patch (https://paste.debian.net/plain/1188666), how to make copy-build-system to install files as `/bin/foofile` instead of `/bin/foodir/foofile`?
<raghavgururajan>(The foofiles are selected via #:include)
<Formbi>hi
<Formbi>I'm trying to package PyPy2
<Formbi>but I'm getting «unable to execute 'cc': No such file or directory» when it tries to build the CFFI stuff
<lle-bout>Formbi: (setenv "CC" "gcc")
<Formbi>which is quite strange, cause I don't really see 'cc' anywhere in the source
<Formbi>lle-bout: I passed --cc=gcc to the rpython
<Formbi>I did «export CC=gcc» in guix environment and it doesn't work either
<PurpleSym>Formbi: PyPy2 as in the JIT Python interpreter?
<lle-bout>was thinking about something the other day, doesnt time-machine command mean every package that will ever violate FSDG will continue to be available on GNU Guix
<wleslie>cffi pulls its C compiler from distutils
<Rovanion>lle-bout: Isn't that always the case with a versioned package repo, sort of? It's just easier to use now.
<Formbi>wleslie: but it uses the bundled distutild
<Formbi>distutils*
<Formbi>PurpleSym: yes
<lle-bout>Rovanion: Yes it is but I don't think any other FSDG distro has such capability.
<PurpleSym>Formbi: Have a look at the existing pypy3 package. There’s a substitute* for lib-python/3/distutils/unixccompiler.py
<PurpleSym>Maybe you can even inherit from that package and just adjust the things that are different for Python 2.
<Formbi>I did
<wleslie>how are you testing the build?
<Formbi>guix build
<wleslie>also: there's an existing pypy3 package? how do you even build pypy3 without pypy2? I guess "very slowly"
<Formbi>yeah
<Formbi>also I did guix build -K and guix environment --pure from the build directory
<leoprikler>raghavgururajan: you have to set a slash at the end of one of "examples" or "bin" (i.e. "examples/" or "bin/"), but I'm not sure which
<leoprikler>note that you shouldn't install the examples though (see my mail), it's just in case you want to learn more about copy-build-system
<apteryx>raghavgururajan: about that icon issue; I've built the application from a 'guix environment', not relying on the gtk-or-glib-build-system phases; perhaps something from it is required?
<raghavgururajan>apteryx: In those phases, for gtk, the executables get wrapped with gtk modules. IIUC, icons are not included in modules. So probably unrelated.
<raghavgururajan>But you might be missing module(s) that loads icon(s).
<apteryx>right, it just wraps them with the environment variables such as XDG_DATA_DIRS, but that's set in my 'guix environment'
<raghavgururajan>I mean executables get wrapped with .so files under /lib/gtk/modules.
<raghavgururajan>leoprikler: The compiled examples might be useful right? like an reference implementation or something?
<leoprikler>no
<raghavgururajan>Okay then. I'll just focus on [1] instead of [2].
<leoprikler>for icons, schemas etc. to work such packages need an envrionment with --ad-hoc glib
<leoprikler>(which just causes XDG_DATA_DIRS to be set accordingly)
<raghavgururajan>For [1], I get "no library QtSolutions_LockedFile found" while linking. Even when I mention "-l../../qtlockedfile/libQtSolutions_LockedFile.so", I get "no such file or directory".
<raghavgururajan>leoprikler, ^
<apteryx>leoprikler: ah, funny, I knew that, but I thought gtk+ was propagating glib. It isn't.
<leoprikler>raghavgururajan: -L../../qtlockedfile -lQtSolutions_LockedFile.
<raghavgururajan>leoprikler: Tried that too.
<raghavgururajan>Same error.
<leoprikler>oh, of course, because it's in the lib subfolder 😋️
<apteryx>lle-bout: in theory yes. In practice, I'd expect the lack of substitutes, and the original sources disappearing to cause problems (although Software Heritage intends to change that, but it doesn't cover everything yet).
<raghavgururajan>leoprikler: LoL, I did not notice the missing /lib. But I tried with /lib.
<raghavgururajan>WTF. it builds without /lib.
*raghavgururajan looks up
<leoprikler>"I tried with /lib, WTF it builds?"
<raghavgururajan>On wait never mind. Spoke too soon.
<apteryx>leoprikler: sadly, adding glib is not enough in this case; I guess the wrapping of .so and other dirs in the glib-or-gtk build system really does something helpful
<leoprikler>oh, sure, but it does not add XDG_DATA_DIRS
***janneke_ is now known as janneke
<leoprikler>wait what it does?
<leoprikler>indeed, it does
<leoprikler>ahhh, but for schemas, you still need glib, because they're not in the data folder or the input
<raghavgururajan>leoprikler: With "LIBS += -L../../qtlockedfile/lib -lQtSolutions_LockedFile", I get "ld: cannot find -lQtSolutions_LockedFile".
<leoprikler>perhaps ordering?
<leoprikler>nah
<civodul>avalenn, apteryx: i'm looking at "guix import go", we should be all set!
<leoprikler>this looks like a job for `guix build -K`
<raghavgururajan>> leoprikler‎: "I tried with /lib, WTF it builds?"
<raghavgururajan>It build for you?
<civodul>avalenn, apteryx: i'll add an entry in etc/news.scm so people can discover it
<leoprikler>no, that's just me quoting you out of context
<avalenn>Thank you
<raghavgururajan>💣️🔪️💉️
<efraim>lle-bout: I got waylaid by some household stuff, I got libstdc++ adjusted, next bit is gcc itself
<raghavgururajan>-K looks good. I mean patched correctly.
<efraim>of course after I finish it has to be tested on powerpc64le
<apteryx>civodul: cool, I'll keep polishing extra bits I have locally when I have a chance and submit for review later
<apteryx>civodul: thanks for reviewing it
<apteryx>raghavgururajan: the idea that some modules required to load icons is missing sounds like plausible; here's one of the messages from the client: DEBUG: 08:44:15.457: Could not load icon: Unrecognized image file format
<apteryx>so probably need to extend GIO_EXTRA_MODULES the way glib-or-gtk-build-system does
<raghavgururajan>apteryx: gdk-pixbuf or gdk-pixbuf+svg?
<apteryx>interesting, there's no $GUIX_ENVIRONMENT/lib/gio/modules in that profile
<apteryx>it's a shame this hackery is not transparently handled by search paths
<raghavgururajan>leoprikler: I have built with -K. What are we looking for?
<raghavgururajan>I see LIBS += -L../../qtlockedfile/lib -lQtSolutions_LockedFile -L$$QTSINGLEAPPLICATION_LIBDIR -l$$QTSINGLEAPPLICATION_LIBNAME
<leoprikler>first of all, source the environment variabls
<leoprikler>*variables
<leoprikler>now you can run make inside the build directory and check which modifications actually lead to a good result
<apteryx>civodul: it's not currently possible to express a search path such that it selects the parent directory if it contains some child directory/file, correct?
<apteryx>raghavgururajan: it's strange, inspecting what the glib-or-gtk build system does, and looking at the glib and gtk+ packages search paths, the only difference seem to be that the build system sets GTK_PATH rather than GUIX_GTK3_PATH.
<apteryx>s/sets/wraps with/
<raghavgururajan>I see.
<apteryx>another interesting point is that the jami package doesn't even make use of glib-or-gtk-build-system (it uses cmake-build-system), yet when installed to my user profile along with adwaita I do get icons.
*apteryx is confused
<zimoun>hi!
<apteryx>zimoun: hello!
<efraim>lle-bout: got gcc adjusted, both patches pushed to wip-ppc64le
<efraim>looks like findutils is core-updates specific
<roptat>so it's not clear to me, shall we start merging c-u soon, or do we wait for the next release?
<roptat>also for next release, I can send a message to all our translators via weblate, to inform them of our plans, string freeze and release dates, etc
<roptat>and we'll have to compromise on readability of commits related to locales I think, because weblate updates po files from the pot, even when there is no change to the translation itself
<roptat>meaning there are many changes in po files that are just "let's update the comment that gives the line number of this string"
<roptat>especially in the manual, since any modification will change line numbers of every string after it
<efraim>my understanding is core-updates after the next release
<efraim>we'd like it, but there ends up being a lot that goes into fixing everything
<zimoun>roptat: my understanding is merge core-updates after the next release.
<roptat>ok, thanks :)
<roptat>so we plan the release for april 18?
<zimoun>IIUC, merginf c-u requires more than 6 weeks
<zimoun>I think it is a good date, initial commit anniversary.
<roptat>zimoun, since you were complaining about readability of po commits, is it ok to push current po files, even though some update only comments / untranslated strings?
<roptat>I don't think we have a choice anyway, but if you oppose, we can try and think about something, like I did with how we normalize po files now
<leoprikler>apteryx: along with adwaita is the key here
<leoprikler>if you install missing icons, they do get seen by XDG_DATA_DIRS, since that has ~/.guix-profile by default IIUC
<zimoun>well, the best (pragmatic) seems to push the current po files and think about something as incremental improvement for next.
<emacsen>I'm looking for an article... maybe someone else has read it... It basically shows how you can go from a configuration language, or a data language like JSON and you realize quickly you've made a lisp
<emacsen>it's driving me mad that I can't find it again!
<apteryx>leoprikler: I do have adwaita-icon-theme in the environment manifest
<apteryx>even when not using --pure the icons cannot be loaded
<leoprikler>and if you add glib + adwaita-icon-theme?
<apteryx>glib is also in it
<leoprikler>interesting
<leoprikler>perhaps hicolor is missing?
<apteryx>hehe, also there
<apteryx>it seems to find the icons, but fail to load them
<leoprikler>IOW the icons are "broken"?
<leoprikler>i.e. the files themselves?
<apteryx>this kind of call fails: GdkPixbuf* icon = gdk_pixbuf_new_from_resource("/net/jami/JamiGnome/jami-symbol-blue", &error);
<leoprikler>hmm, are the gresources installed or are they linked into the application?
<leoprikler>a similar failure occurs in mumble (it is unable to load sounds)
<leoprikler>I suspect grafting
<apteryx>it returns NULL and I get this message (from the client-gnome code of Jami): g_debug("Could not load icon: %s", error->message); which gets printed as DEBUG: 09:40:34.180: Could not load icon: Unrecognized image file format
<apteryx>and to be clear, I'm building the application in 'dev mode' outside of a Guix package definition for now; so perhaps that's at play but I at least extend XDG_DATA_DIRS to its local install/share directory
<leoprikler>IOW grafting should also not affect it?
<leoprikler><file alias="jami-symbol-blue">jami.svg</file> <- it could also be that svg support is missing?
<roptat>does strace show it finds jami.svg?
<apteryx>leoprikler: right, the application itself cannot be grafted
<raghavgururajan>leoprikler: Regarding indentation, it appears so.
<apteryx>roptat: so the icon is installed locally (dev tree): ./install/client-gnome/share/icons/hicolor/scalable/apps/jami.svg
<roptat>oh wait, is that a Qt application?
<apteryx>and in the environment I'm doing XDG_DATA_DIRS=install/client-gnome/share:$XDG_DATA_DIRS command-to-run-jami
<roptat>ah no, "gnome", so must be gtk
<apteryx>nope, that's still the GNOME client (gtk+)
<roptat>I had issues with Qt and svg icons in the past
<apteryx>let me see with strace
<roptat>but that's not it then
<leoprikler>the icon itself maybe installed, but not under the name it's searched for
<roptat>Qt was missing its QtSvg plugin (or whatever it's called), and I had to wrap the program
<leoprikler>that's only in the resource
<apteryx>ah, it must be that the gtk-font-cache is not build with those icons since the application is *not* in a package form
<apteryx>not built*
<apteryx>leoprikler: the icon is registered in client-gnome/pixmaps/pixmaps.gresource.xml, using: <file alias="jami-symbol-blue">jami.svg</file>
<efraim>lle-bout: you can't update mongodb, the license changed
<leoprikler>yes, and that resource gets linked into the application itself
<efraim> https://github.com/mongodb/mongo/blob/master/LICENSE-Community.txt
<leoprikler>so, wait, if I were to use --latest and somehow got a working package, it might no longer be under the version I assume it has?
<leoprikler>scary
<zimoun>apteryx: do we agree that we can remove python2 packages if there are broken and without any dependant?
<apteryx>zimoun: yes
<civodul>apteryx: right, search paths only add matching files/directories
<apteryx>OK
<civodul>so for XDG_DATA_DIRS, it's share/, which is admittedly pretty broad but IMO a "problem" with XDG
<zimoun>apteryx: ok, so I am doing the list
<apteryx>civodul: right; every package must have a share due to installing the license file
<civodul>yeah
<apteryx>but that doesn't seem to cause a problem so far
<civodul>right
<civodul>apteryx: re "guix import go", do you know where i can find examples of packages that can be imported?
<civodul>apart from the one in the manual
<civodul>looks like the go-version->git-ref call in definitions is bogus
<avalenn>cidovul: pkg.go.dev
<civodul>avalenn: thanks!
<avalenn>what sort of bug
<civodul>avalenn: https://proxy.golang.org/pkg.go.dev/@latest is 410
<civodul>avalenn: we do, say, (go-version->git-ref version) == (go-version->git-ref "2.4.0") == "2.4.0", but the Git tag is "v2.4.0"
<avalenn>je me suis mal exprimé
<avalenn>you can find packages in pkg.go.dev, but an example of package would be golang.org/x/sys
<apteryx>civodul: oh, I have a fix for that in my tree
<apteryx>but my tree is in a messy state... let me try to extract that bit
<avalenn>you're right, "v" should be added if it does not exists
<apteryx>civodul avalenn here is where it does it: https://paste.debian.net/1188709/
<avalenn> https://paste.debian.net/1188710/
<avalenn>mine is not tested at all
<apteryx>go version should include the v, so I think my fix is more correct
<avalenn>my version adds it in go-version->git-ref, yours add-it after
<apteryx>right, I'm just being picky that strictly, a go-version must be formed with the v prefix, so it makes sense that the regexp matches it
<civodul>apteryx: oh good
<civodul>i'll take that and then leave it up to y'all for further improvements
<civodul>:-)
<apteryx>I have another little one for the license field unless it's been applied already
<apteryx>this reads better: https://paste.debian.net/1188711/
<apteryx>ah, but license extraction is to be applied later anyway, it #f right now, right? nevermind then
<avalenn>I cannot remember why I made the "v" optional in the go-version regexp
<avalenn>I just know I had "some" reason
<apteryx>it's possible that non-module Go packages use non v prefixed versions; I'm not sure if the generated go.mod from the proxy server would normalize it but probably not, so that may be why
<civodul>i fixed the license field
<civodul>apteryx: shouldn't the two arms of the 'if' be swapped?
<civodul>as in: (if (and plain-version? v-prefixed?) '(go-version->git-ref version) '(string-append "v" version))
<civodul>otherwise it has no effect
<apteryx>works for me (TM)
<apteryx>let me look at it again
<apteryx>so plain-version? basically means it's a tag such as v1.2.0
<apteryx>it's fun, it's because the code is quoted
<apteryx>the version you see is not the version passed as argument :-P
<apteryx>the version in the quote is the guix record bound version variable, whichis stripped of any 'v' prefix
<apteryx>the version provided as argument has the prefix. Confusing, eh?
<avalenn>I think my patch makes the think more understandable
<avalenn>always make the output of go-version->git-ref output the "v" prefix
<avalenn>and just strip the "v" for the version field of the package
<avalenn>as the regexp matches with or without "v", go-version->git-ref is idempotent and works with the stripped version as input too
<Noisytoot>I have noticed a spelling mistake in guix/licenses.scm, in a comment on line 239
<Noisytoot>";; "LOST PROFITS" becoms "LOSS OF GOODWILL" and a section is added between 6.2" should be ";; "LOST PROFITS" becomes "LOSS OF GOODWILL" and a section is added between 6.2"
<apteryx>avalenn: what is version is "v2.3.4"? It'll become "vv2.3.4", no?
<Noisytoot>(it's "becomes", not "becoms")
<apteryx>avalenn: I don't have the full code context, just looking at the diff
<avalenn> https://paste.debian.net/1188716/
<apteryx>(go-version->git-ref "v2.3.4") -> "vv2.3.4"
<civodul>apteryx: ooh, got it
<apteryx>avalenn: also we could normalize the string so that it always outputs a v prefixed one, but that ends up getting used as the git refspec so we shouldn't alter it in my opinion
<apteryx>as you said, there may be a good reason why the v is made optional in that regexp, and I'm sure some Go package indeed would use a tag such as "1.0.0" rather than "v1.0.0" if they predate the Go module system or don't care about it
<apteryx>s/would/could/*
<avalenn>apteryx: you're right, I missed something
<avalenn>bad reading of my own code
<apteryx>no worries
<lfam>I'm trying to make a simple-service of sysctl-service-type, to set up some default sysctl settings on Guix System
<lfam>This is the code I have right now: https://paste.debian.net/1188721/
<pkill9>i thought there is already a sysctl service
<lfam>But, it crashes like this: https://paste.debian.net/1188722/
<lfam>Yeah pkill9, I'm trying to use it :)
<pkill9>ohhh
<lfam>Does anyone have any advice?
<lfam>I tried copying the pattern used by the other "default settings" simple services, which are the console-font-service and the static-networking-service
<lfam>I tried just using (service sysctl-service-type ...) in %base-services, but this prevents users from setting more sysctl settings in their config.scm. In that case, it fails like "guix system: error: service 'sysctl' provided more than once"
<lfam>Although, it seems to me this should work. It does work for special-files-service-type
<safinaskar>all links at https://guix.gnu.org/en/download/latest/ show "bad gateway"
<lfam>I've been trying to figure this out for hours
<Artemix>Hey there! during setup on my laptop, due to having a shitty router the dhcp address resolution is very slow, and the eth link establishment of 5s timeouts before. Is there a way to avoid that?
<safinaskar>your download server don't work!
<roptat>oh no, is berlin on fire?
<safinaskar>ci.guix.gnu.org
<lfam>It is indeed offline
<Artemix>if that was being hosted at OVH strasbourg, the datacenter was destroyed in a fire today
<Artemix>sooo
<lfam>It's not
<lfam>That's pretty crazy though
<roptat>thankfully, berlin is in Berlin
<roptat>but I thought it was berlin answering directly on ci.guix, so it's not offline, is it?
<lfam>The server is online
<lfam>I see that the main admin is logged in
<roptat>alright :)
<civodul>avalenn, katco, apteryx: pushed! \o/
<avalenn>\o/ I must use it now
<katco>civodul: i assume you're talking about the go importer?
<lfam>Yup!
<katco>woo! awesome work all! it's going to be fantastic having that :D
<apteryx>civodul: yay! thanks to katco and avalenn for their work on it, and for you for reviewing it!
<katco>yes, big thanks to all involved. especially avalenn for carrying it over the finish line.
<katco>i don't usually do `pull`s in the middle of the week, but today i make an exception :)
<avalenn>I am focusing now to try to package some software I need that have big dependency chains.
<avalenn>And I am already hitting some limits which can quickly become painful with recursive import.
<avalenn>This importer is really a work in progress but the first step is here now. We just have to improve it.
<katco>+1
<pkill9>is unionfs safe enough to rely on?
<pkill9>like it's not going to break?
<avalenn>cidovul: you added the hash generation from git. Thanks a lot.
<avalenn>I can now drop my dirty patch which tried to do it.
<civodul>avalenn: yw!
<civodul>anyone knows how to invoke the Postgres CLI to fiddle with the Cuirass database?
<jonsger>yes
<jonsger>civodul: sudo -u cuirass -s /bin/sh -c 'psql cuirass -h /var/run/postgresql'
<apteryx>avalenn: in my tree I was trying to unlock pinned version imports to deal with recursive dependencies of self
<apteryx>for example golang-protobuf's bootstrap is reminiscent of rust's
<rekado>is it expected that cuirass is down?
<rekado>lfam: just saw your mail
<lfam>No
<rekado>so, nobody is restarting it right now
<rekado>okay, I’ll do it
<lfam>I saw that mothacehe was logged in so I figured they knew, but I sent htat email anyways
<rekado>I just started the cuirass services
<lfam>Thanks
<lfam>This isn't your problem, but I notice that the list of specifications in the web interface is no longer correct
<rekado>yeah, it’s very short
<civodul>jonsger: thanks!
<rekado>and … hmm
<rekado>just generally odd
<rekado>why are all the values in the “channels” column “guix”?
<rekado>I need to go now
<lfam>Alright
<civodul>jonsger: my instance is broken: https://guix.bordeaux.inria.fr/eval/10277/log/raw
<lfam>mothacehe replied to the email
<civodul>i think it has to do with the new evaluation process
<civodul>i'll have to upgrade prolly
<civodul>bumpy!
<raghavgururajan>lfam: Would you be able to review and merge #46584?
<daviwil>Hey folks! Quick question - is there any way to get the shell output when running a script using `invoke` in a package definition? My `(invoke "sh" "script.sh")` is failing with a nonzero exit code and I can't see any script output to figure out why
<apteryx>rekado: could be due to me pushing a commit triggering 2700 builds 30 minutes ago; I had checked the number for gtk+@3 but didn't for gtk+@2; decided to let it slip rather than revert.
<apteryx>that was on staging
<roptat>daviwil, invoke does send the output of the script to the console though
<roptat>if the error code is "127", that's no such file or directory, which would explain why there's no output
<daviwil>roptat: Yes! That's the code. Thanks, I'm probably using the wrong script path
<daviwil>Could it also be that `sh` itself isn't being resolved?
<daviwil>I see some packages `(invoke "sh")` without adding `bash-minimal` to `native-inputs`
<roptat>I doubt it, unless you're doing something very crazy with the package definition
<roptat>bash is an implicit input
<daviwil>That's what I suspected
<daviwil>Ok, `sh blah.sh` returns error code 127 so it's definitely a bad script path
<apteryx>is someone else using the staging branch?
<apteryx>I though a profile defined with a manifest incluing gdb and some :debug output should define GDB_DEBUG_FILE_DIRECTORY, but that doesn't seem to happen (anymore?)
<apteryx>the variable is defined as a native-search-path on gdb on staging
<apteryx>meh, it doesn't work
*apteryx puzzled
***jx97 is now known as jx96
***qyliss_ is now known as qyliss
<euandreh>is it my env, or the latest commit on guix can't be authenticated?
<euandreh>guix pull: error: could not authenticate commit 15092548804b6c50ea276d098f76a79bd0042398
<leoprikler>same here for local git checkout
<euandreh>since the commit was pushed to Guix upstream repo, I assume this might be a new committer missing its fingerprint in the 'keyring' branch
<leoprikler>Typically we set up keyring and authentications first, though.
<leoprikler>but "key 51A0 982A 58B6 4622 4648 3308 5EEB 3986 CB2F 65ED is missing"
<leoprikler>so perhaps you're right
<nckx>("9ADE 9ECF 2B19 C180 9C99 5CEA A1F4 CFCC 5283 6BAC" (name "taylanub"))
<nckx>[commit made] using RSA key 51A0982A58B64622464833085EEB3986CB2F65ED
<nckx>euandreh: A very old committer.
<euandreh>makes sense, maybe from before authentication was setup
<leoprikler>It is signed, but the wrong key?
<roptat>there's a key for taylanub in the keyring branch, but it's not the same fingerprint
<euandreh>hmm, I didn't check
<roptat>what should we do in this case?
<euandreh>maybe contact taylanub to update the keyring, and move the commit to a different branch so that the channel doesn't stay broken
<leoprikler>fwiw, it seems their key was updated on savannah
<lfam>I can't stick around but I saw the logs
<lfam>I removed taylan from the Savannah project
<lfam>This is a case where I suggest rewriting the history of the branch
<lfam>Once things are fixed, another Savannah admin can re-add them to the group
<euandreh>the commits to be rewritten are just one FTR
<lfam>Right
<cbaines>I think savannah is configured not to allow force pushes, so the only way to remove the commit might be to delete the master branch, and re-create it without the commit
<lfam>Yes
<efraim>I thought the master branch was protected also
<lfam>I was actually going to remove them from the project anyways, due to a long time without any participation
<cbaines>I'm not sure what the implications of that are, I wonder what would end up being sent to guix-commits
<lfam>It will send an email that the branch is deleted. No big deal
<lfam>We do it all the time for other branches
<lfam>And if we break it... it's already broken
<lfam>Alright I have to go
<euandreh>ack, ty lfam for the guidance
<Noisytoot>I just ran "guix pull", and I got this error: "guix pull: error: could not authenticate commit 15092548804b6c50ea276d098f76a79bd0042398: key 51A0 982A 58B6 4622 4648 3308 5EEB 3986 CB2F 65ED is missing"
<Noisytoot>How can I fix it?
<euandreh>Noisytoot: its really broken now, still working on fix
<euandreh>see https://logs.guix.gnu.org/guix/2021-03-10.log#205043
<Noisytoot>Maybe "guix pull --commit=60174c9c8c307be43450af38ce7c4e268278e07c" will work (it's the commit before), but it's slightly older
*Noisytoot tries it
*nckx got disconnected at this ideal time, reads backlog.
<Noisytoot>guix pull --commit=60174c9c8c307be43450af38ce7c4e268278e07c is working so far
<nckx>Noisytoot: ‘So far’? It should just work.
<nckx>guix pull: error: could not authenticate commit 999a1cba5416bb2099e21d4fc55624d8ef2c7fa1: key CA4F 8CF4 37D7 478F DA05 5FD4 4213 7701 1A37 8446 is missing
<nckx>Grrr.
<nckx>(Yes, git log --format=oneline {origin/,}keyring | head -n1 → 3da8e4a6587d05145d1cad94ef6183d34bac7555 Add keys for lbraun.)
<zimoun`>nckx, 999a1cba54 works for me, I guee. But 1509254880 not.
<zimoun`>*guess
<nckx>zimoun`: 1509254880 is expected.
<nckx>I'm not going to bother debugging 999a1cba54 now.
<nckx>I've asked #savannah about deleting the remote master branch.
<nckx>I can't.
***nckx changes topic to 'GNU Guix | ⚠️ you need to run guix pull --allow-downgrades exactly once | get Guix at https://guix.gnu.org | videos: https://guix.gnu.org/blog/tags/talks/ | bugs & patches: https://issues.guix.gnu.org | paste: https://paste.gnome.org/ | Guix in high-performance computing: https://hpc.guix.info | This channel's logged: https://logs.guix.gnu.org'
<nckx>OK, people. Things should be back to normal. You need to run guix pull --allow-downgrades as the topic says. Do not make a habit of this.
<zimoun`>nckx: I am not sure 999a1cba54 is broken. rm -fr ~/.cache/guix && guix pull --commit=999a1cba54 -p /tmp/trash works for me. But 1509254880 is definitively broken. As reported before.
<lle-bout>nckx: what happened
<roptat>nckx, that would be for people who ran guix pull during the breakage only, right?
<euandreh>roptat: yep
<nckx>roptat: Indeed.
<euandreh>lle-bout: see https://logs.guix.gnu.org/guix/2021-03-10.log#205043
<nckx>roptat: To add more to the topic I need to cut something :)
<roptat>ah
<nckx>It shouldn't stay up for long.
<euandreh>nckx: I'm already used to adding --allow-downgrades, due do doing git push -f frequently on a personal channel XD
<nckx>euandreh: Ssh, I use it every time, but I Know What I'm Doing (I Do Not).
<lle-bout>nckx: okay thank you
<lle-bout>nckx: maybe we should have more granular --allow-downgrades
<Noisytoot>guix pull works!
<nckx>lle-bout: --allow-downgrades=<commit> ? Right now it is a needlessly racy thing.
<euandreh>Noisytoot: 🎉
<lle-bout>nckx: yes also per-channel
<nckx>Noisytoot: Only with --allow-downgrades, I hope?
<nckx>Otherwise we have another more serious fun bug.
<Noisytoot>nckx: Without --allow-downgrades
<nckx>Oh.
<nckx>Right.
<nckx>Duh.
<nckx>I had already pulled the bad commit, you sane people hadn't.
***nckx changes topic to 'GNU Guix | get Guix at https://guix.gnu.org | videos: https://guix.gnu.org/blog/tags/talks/ | bugs & patches: https://issues.guix.gnu.org | paste: https://paste.gnome.org/ | Guix in high-performance computing: https://hpc.guix.info | This channel's logged: https://logs.guix.gnu.org'
<lle-bout>awesome news on the go importer!
<euandreh>is it merged?
<lle-bout>euandreh: yes!
<euandreh>woot!
<euandreh>I'll try "guix import go -r terraform" later today!
*lle-bout runs M-x cve-squashing-robot-mode
<Noisytoot>lle-bout: What does that do?
<lle-bout>Noisytoot: error out Emacs for now :-P
<lle-bout>It's just I've been doing very repetitive task of patching CVEs in GNU Guix since last few days and I'm again back at it.
<lle-bout>Not so boring to me after all.
<lle-bout>I have issues determining if that feature in lib3mf is DRM or not: <https://github.com/3MFConsortium/spec_securecontent/blob/master/3MF%20Secure%20Content.md>
<roptat>no idea what 3mf is, so it's hard to say
<lle-bout>roptat: apparently it's a 3D model standard and lib3mf is the reference impl, it's used by openscad
<roptat>encryption by itself is not DRM
<lle-bout>I am updating lib3mf to fix security issues and it seems they added support for this "Secure Content Extension" in the more recent version
<lle-bout>roptat: it isnt but the name of the standard kind of.. smelled like it.
<roptat>yeah
<roptat>it really depends what it does
<lle-bout>"Ensuring end-to-end encryption from producer to device for privacy sensitive information (like medical patient data)"
<roptat>if it's just encryption, then it's fine, if it's encryption + so weird permission model, then it's maybe not fine
<lle-bout>"Obeying Governmental regulations for production data (like ITAR or GDPR)"
<lle-bout>"Digital Asset Security applications in Industry 4.0 environments"
<lle-bout>"Secure Archiving of Print Data in untrusted environments (like Cloud Storage) without the risk of content leakage."
<lle-bout>Very buzz-word
<roptat>what does that even mean? ^^'
<roptat>probably, apart from point 3, it sounds legitimate (I don't understand point 3)
<lle-bout>It looks very bullshit indeed, if one wants content protection then just share like 7z archives with AES encryption, don't know
<nckx>bullshit = content leakage, to be fair.
*nckx just rolls eyes at the buzzwords.
<Noisytoot>Or tar + gpg
<lle-bout>Noisytoot: yes but maybe less user-friendly
<roptat>well, it's xml + gpg :)
<dongcarl>mbakke: Do you remember what prompted you to write qtbase-moc-ignore-gcc-macro.patch? Did you post an issue?
<lle-bout>roptat: It looks like a public/private encryption scheme like you can create 3D files encrypted for certain public keys
<roptat>lle-bout, that's what it looks like to me too
<roptat>I think it's fine
<lle-bout>Can't find DRM inside the spec at least
<lle-bout>roptat: yes I think too, let's update it.
<Noisytoot>Why did Guix decide to use IPFS instead of GNUnet for distribution of substitutes?
<rekado>Noisytoot: Guix didn’t decide that.
<lle-bout>Noisytoot: GNU Guix didnt decide much, it's whoever implements something first at this point. Also GNUnet isnt as mature of a software and big of a network I think.
<rekado>Noisytoot: we wanted to use GNUnet before we became aware of IPFS, but the Guile bindings for GNUnet (a GSoC project IIRC) didn’t progress enough to be useful, and GNUnet took a *very* long time to be unbroken between releases.
<rekado>GNUnet didn’t make a new release but requested that older releases not be used.
<rekado>not very encouraging; and then IPFS came along: it actually worked, and the developers actively engaged with us to get things going.
<rekado>that doesn’t mean there won’t even be substitute distribution over GNUnet.
<lle-bout>both can co-exist IMO
<rekado>the next step for that to happen would be to update the Guile bindings for GNUnet.
<rekado>there’s a clone of the bindings here: https://git.gnunet.org/gnunet-guile2.git/log/
<rekado>the commit history does not look very encouraging
<rekado>I find it odd that the original commit history was squashed. Here’s the original project repository: https://git.savannah.gnu.org/cgit/guix/gnunet.git/
<rekado>(it seems rude to me to squash other people’s commits.)
<rekado>uhm, when I view this page in icecat it’s full of github icons: https://ie.wikipedia.org/wiki/Lewis_Carroll
<rekado>it looks fine in ungoogled-chromium
<lle-bout>rekado: what do you mean github icons
<nckx>It looks fine in IceCat 78.3.0esr.
<nckx>lle-bout: http://issues.guix.gnu.org/42174
<nckx>Literal octocats or whatever it's called.
<rekado>yes, exactly that
<rekado>but I only see this on https://ie.wikipedia.org, not anywhere else
<lle-bout>o_O
<lle-bout>Why do these font issues happen in IceCat specially?
<lle-bout>What did they do so wrong there?
<lle-bout>I wonder why we package docker/engine instead of moby/moby
<cbaines>the docker packaging was done before the moby arrived I believe
<lle-bout>I can't say for sure that every known security issue is fixed there
<lle-bout>moby/moby has newer versions that docker/engine doesnt have
<Noisytoot>rekado: I have the same issue with IceCat
<Noisytoot>(whatever page I view)
<Noisytoot>rekado: I see it everywhere
<Noisytoot>rekado: I fixed it by copying the necessary fonts to ~/.local/share/fonts, and then running fc-cache -rv, but that is non-optimal
<lle-bout>I don't have that issue and never had to copy fonts around
*lle-bout installs their fonts using system configuration
*Noisytoot runs a foreign distro, and can't do that
<Noisytoot>What are all of the "cosmit" and "TODO++" commits on https://git.gnunet.org/gnunet-guile2.git/log/?
<nckx>Noisytoot: I guessed cosm(etic comm)it.
<nckx>And TODO++ = add to TODO.
<nckx>It makes me grateful for GNU/Guix's format at least.
<Noisytoot> https://xkcd.com/1296/
<mbakke>dongcarl: there is some information in the linked bug report, any package invoking 'moc' at build time failed (qgpgme and a couple others)
<nckx>Noisytoot: https://paste.debian.net/plain/1188770
<nckx>I'm very proud of XXX2.
<Noisytoot>What repo is that?
<nckx>A random Linux experiment.
***sturm1 is now known as sturm
***sturm is now known as Guest4039
<dongcarl>mbakke: Interesting. It just fixed a long-standing problem for me, so thanks!
<mbakke>dongcarl: cool, you're welcome :-)
<lle-bout>I just learned about "git add -i" partial file staging, awesome!
***Guest4039 is now known as sturm__
<lle-bout>I call for testing of the just updated containerd and docker paackages
<pkill9>TIL of bindfs, mount --bind as user