IRC channel logs


back to list of logs

<PotentialUser-28>Thanks for answers, i
<pkill9>so they can't modify other program's files, and you don't have to specify each individual file/folder they can access, because whatever they create is dumped in their own space
<PotentialUser-28>I will give Guix a go (without musl)
<lfam>It might be nice to add some machinery in Guix for building the kernel with Clang, even if it wasn't built by default on the build farm
<lfam>I know that the kernel upstream is starting integrate some features from LLVM / Clang, and eventually it will include Rust
<bone-baboon>I just finished installing Guix using the 1.2.0 installer for a 32 bit system. When I run `guix pull` I am get this error "guix pull: error: Git error: the SSL certificate is invalid".
<raghavgururajan>sneek is swallowing my messages. Bad sneek.
<raghavgururajan>lle-bout[m]: Sneek decided to eat my message instead of delivering it you. We now have 'wip-gnome' on savannah. So plan is guix-patches --> wip-gnome --> master/staging/core-updates
<lle-bout[m]>raghavgururajan: works for me!
<lle-bout[m]>raghavgururajan: I had created it initially but then deleted because we wouldnt be working there anyway.
<raghavgururajan>I see.
<lle-bout[m]>pkill9: As for hardening, I am thinking of growing Qubes OS using GNU Guix, re-using the same software they provide but construct the whole system with GNU Guix instead.
<lle-bout[m]>This will be quite some work but I think that's entirely possible.
<lle-bout[m]>There should be no additional programming required besides Scheme to properly integrate it within GNU Guix.
<lle-bout[m]>Plus, Qubes OS is getting QEMU/KVM support also
<Aurora_v_kosmose>lle-bout[m]: This sounds interesting, what are you working on?
<lle-bout[m]>Aurora_v_kosmose: what do you mean?
<Aurora_v_kosmose>lle-bout[m]: I was asking if you were already working on that Qubes equivalent, and some more info on your idea/work if it was so.
<lle-bout[m]>Aurora_v_kosmose: Work hasnt begun, I said I was thinking about it, but the idea is pretty simple, right now Qubes OS is a set of packages on top of Fedora, we would just have to make that a set of GNU Guix packages instead, then write shepherd services, etc.
<lle-bout[m]>One disappointment with Qubes OS for many is that it doesnt appear to be designed to be used in any other form than the Qubes OS distribution, I actually think it may not be that hard to take it out and use it elsewhere.
<Aurora_v_kosmose>Would most of its relevant security features be portable though?
<lle-bout[m]>Aurora_v_kosmose: GNU Guix System is configured using Scheme, so there's no limitation in what you can do with it. What do you mean by portable? GNU Guix can compile and assemble the same software used by Qubes OS.
<lle-bout[m]>The finalized work will be a GNU Guix System configuration you can use (but also some packages upstreamed probably to make that shorter)
<Aurora_v_kosmose>lle-bout[m]: Stuff like the badUSB prevention and such.
<lle-bout[m]>Aurora_v_kosmose: The GNU Guix System configuration can contain any kernel parameters, etc. and services to mimic Qubes OS's boot process
<Aurora_v_kosmose>I see.
<Aurora_v_kosmose>That's somewhat promising, then.
<lle-bout[m]>There's no limitation in what you can do with GNU Guix, all in all I think GNU Guix is probably a better package manager to base Qubes OS on than Fedora and dnf. In that it provides much more clean tooling to assemble systems and maintain them in a rather minimal way.
<Aurora_v_kosmose>It's certainly a better idea considering the way RedHat is going anyway.
<Aurora_v_kosmose>Even without considering Guix's technical advantages.
<lle-bout[m]>GNU Guix needs more security auditing also, GNU Guile, GNU Shepherd and auditing of all services present in GNU Guix, that's plenty of probably (mostly) unexplored area w.r.t. finding vulnerabilities, and more people to do the day-to-day CVE patching process, I have hope this is coming together
<pkill9>cool lle-bout[m], you could use a guix system configuration for each domain!
<pkill9>instead of a separate distribution
<pkill9>or maybe not even require that? I haven't used qubes
<Aurora_v_kosmose>Essentially, a provisioned base Guix image and the already existent guix remote configuration management stuff that exists already.
<pkill9>that would be great
<Aurora_v_kosmose> or was this thing never merged into main?
<pkill9>a separate domain for banking and stuff, one for sensitive documents, and one for casual use
<Aurora_v_kosmose>oh nvm, it was. For some reason the info manual suggestions with counsel didn't pop up with the right section, but it's there alright
<pkill9>i hope it does lle-bout[m]
<pkill9>runtime security would go well with the security of being able to track the graph of all the software
<Frosku>I've installed xdg-desktop-portal and xdg-desktop-portal-gtk but Flatpak is still complaining: Failed to call portal: GDBus.Error:org.freedesktop.DBus.Error.UnknownMethod: No such interface ?org.freedesktop.portal.OpenURI? on object at path /org/freedesktop/portal/desktop -- any ideas?
<schmools>a beginner to guix so there might be a simple answer to this, but for some reason my guix install won't login with anything but the root account. my password wont get rejected it will just restart the login manager - happens in the terminal too so I don't think its a GDM thing...
<roptat>Frosku, majority of people here are sleeping now, so if you don't get an answer now, you can always ask on the mailing list, there might be more people who can answer:
<Frosku>Whats your shell set as in /etc/passwd? Sounds like a shell issue
<roptat>I've never used flatpak, so I have no idea
<Aurora_v_kosmose>There was also that issue a while back with something missing from the default system configuration.
<roptat>could be the shell crashing if you set something funny in .bashrc or something, don't know if it's very likely
<roptat>happened to me though ^
<Frosku>I had that issue when I set my shell wrong too
<schmools>I havent even been able to log into the nonroot account so I don't think I could have even changed anything in the .bashrc file
<Frosku>schmools: log into root then do
<Frosku>`su yourusername`
<roptat>right, doen't sound likely ^^
<Frosku>You should get an error or something
<schmools>shell is the same between root and my user in /etc/passwd but I might have a different shell set in /etc/passwd than I do for my user in my config.scm file
<schmools>frosku - I get "my home directory /.bashrc: permission denied"
<roptat>so, it's a .bashrc issue, I was right after all...
<Frosku>chown yourusername:users /home/yourusername/.bashrc
<roptat>though not what I imagined ^^'
<schmools>ran that command but still having the same issue
<roptat>what's the ownership and permissions on /home/yourusername{,/.bashrc}?
<schmools>yeah that was the issue I think
<Frosku>Did you create the file as root or something?
<schmools>don't think I did
<schmools>even if I run the chown command as a superuser, su myusername still says I don't have permission to access .bashrc
<schmools>kinda strange - I think this is almost a completely clean install...
<roptat>is there maybe a typo in the path it's trying to access?
<schmools>roptat - a typo in /etc/passwd ?
<roptat>yeah, maybe
<roptat>or maybe check access rights on /home
<roptat>should be accessible to anyone
<Frosku>schmools: (as root) mv /home/yourusername/.bashrc /home/yourusername/.bashrc.bak
<Frosku>Try logging in without .bashrc existing, then we can eliminate the idea that the issue is with the file
<Frosku>So just move it (as root) to .bashrc.1 or something
<Frosku>If login works we know the issue is with .bashrc
<Frosku>If not we know it's not
<schmools>nope same issue - I might also try to remove .bash_profile
<Frosku>Whats the error message?
<Frosku>If its still talking about .bashrc that suggests user home directory might be set wrong
<Frosku>in /etc/passwd
<Frosku>Which you can fix in /etc/config.scm
<schmools>yeah still talking about .bashrc
<Frosku>Check /etc/passwd
<schmools>(home-directory) is correct in config.scm tho
<schmools>home directory also looks correct in /etc/passwd
<Frosku>cat /home/username/.bashrc
<Frosku>And ls -l /home
<Frosku>What are permissions on home dir, and who owns it?
<guixy>hello guix
<sneek>Welcome back guixy, you have 1 message!
<sneek>guixy, nckx says: guix pull && guix install gpart .
<guixy>Frosku: on my system for every user, $HOME is owned by the user $USER, the group users, and permissions drwx------
<schmools>yeah - I think permissions seemed correct had to go to superuser to access /home/username
<guixy>Did you change the set of users in your config recently?
<schmools>no thats stayed the same
<guixy>ls -l /home
<guixy>Don't bother with any personal information.
<roptat>ls -ld /home too :)
<roptat>/home should be 755, owned by root, /home/username should be owned by username:users and 700
<Frosku>I have a fun question: has anyone ever seen gcc spit out 'unable to determine your cwd'?
<Frosku>I can't seem to compile perl
<roptat>it happens when you move the directory and replace it with something else for instance
<Frosku>But I'm not moving anything
<roptat>like cd /some/directory, then rm -rf /some/directory and from another terminal mkdir /some/directory
<guixy>On my system /home is drwxr-xr-x
<Frosku>Can't figure out your cwd! at /home/frosku/perl5/perlbrew/build/perl-5.32.1/perl-5.32.1/cpan/ExtUtils-MakeMaker/lib/ExtUtils/ line 237.
<roptat>you'd be in the right directory in te first terminal, but your cwd would be impossible to determine
<Frosku>But the only thing I'm running
<Frosku>in this case
<Frosku>is make
<guixy>drracket broke when it was updated to 8.0
<schmools>roptat - so my usernames home directory says "drwx------ 3 1000 users 4096
<schmools>and then the generic date stuff etc
<guixy>1000 should be the username.
<guixy>cut -d: -f1,3 /etc/passwd | grep 1000
<guixy>I think those are the fields we want...
<roptat>that seems to indicate your user does not have uid 1000
<schmools>should I try to force it to have uid 1000 in config.scm?
<guixy>That would probably be the best.
<lfam>I feel like I recently saw somebody asking how to set their UID to 1000 in config.scm
<lfam>I wonder if it's a new bug?
<guixy>uid field of user-account
<lfam>I've seen it when installing Guix System with a pre-existing /home partition
<schmools>yeah got it
<schmools>that seems to have worked
<schmools>thanks a ton
<guixy>So anyway, drracket broke with 8.0.
<guixy>It looks like there's a patch pending.
<guixy>I'm using time machine to try past versions of racket
<schmools>just for my reference somebody explain why having the uid wrong breaks things just so I kind of understand what I fixed?
<Frosku>Because permissions are set up so 1000 has access
<Frosku>But your user doesnt
<Frosku>So when you fix uid to 1000, the permissions are solved
<guixy>When the time-traveling drracket successfully launches, I'm getting font issues.
<schmools>got it, thanks
<Frosku>roptat: Any idea how I can fix that cwd issue when compiling perl?
<schmools>should the users group than be set up so that all new users get uid 1000 as well?
<guixy>schmools: no, all users should have a unique uid.
<guixy>If you want multiple users to access a file, set its group permissions.
<schmools>so is there some just a given set of uid's where permissions aren't broken then?
<schmools>because doesn
<Frosku>No, its just that the permissions are auto-set for uid 1000
<Frosku>So if you are not uid 1000
<Frosku>You dont have them
<guixy>They should be assigned incrementally for users starting at uid 1000
<schmools>ok - so for whatever reason the autoassigned uid just wan't in that range... is that behavior fixable?
<guixy>It's the reason I asked if you had changed the users. Had you been using your install for long?
<guixy>Is your /home a separate partition?
<echosa>roptat lfam - I figured out my weird "guix pull is stuck on a particular commit" issue! Inadvertently my fault. :-P Described here:
<echosa>tl;dr - I have two bash aliases
<echosa>alias guix-backup='guix package --export-channels > ~/.config/guix/channels.scm && guix package --export-manifest > ~/.config/guix/manifest.scm'
<echosa>alias guix-restore='guix pull -C ~/.config/guix/channels.scm && guix package -m ~/.config/guix/manifest.scm'
<echosa>Apparently, having those *.scm files in ~/.config/guix causes `guix pull` to load/use them by default. The commit my guix was "stuck" on was defined in the channels.scm file.
<echosa>I have moved those scm files somewhere else for storage and backup, and now guix seems to be working as expected again. :-)
<guixy>Is there a way to trace what fonts a program uses?
<schmools>sorry was away for a sec; no it's a fresh install guixy, the only thing I'd done was to add drivers for my wifi
<schmools>my home partition is separate though
<schmools>new machine - so I thought I'd try guix because I've wanted to give it a shot for a while and if I get too confused just jump back to debian and keep my home stuff at least the same
<guixy>schmools: See if you can reproduce the situation in a vm.
<guixy>If you can, it's a bug report.
<guixy>*submit* a bug report
<schmools>gotcha - I'll see if I can do that later
<guixy>Is home partition on an entirely separate drive? That could be something difficult to check on a VM.
<guixy>Frosku: Still having cwd issues with perl?
<guixy>Come on racket! Don't hang on the install phase...
<Frosku>guixy: Yeah
<guixy>Frosku: the issue is fixed in guix at gnu/packages/perl.scm +129
<guixy>It looks like it hard-codes /bin/pwd
<guixy>Frosku wouldn't have a problem if you had /bin/pwd. I think you can sed dist/PathTools/ -e "s/\/bin\/pwd/$(which pwd)/g" or something like that to fix it.
<guixy>Sorry, not too familiar with irc
<guixy>Missed the -i in the call to sed. Good idea to make a backup copy.
<guixy>And maybe change / to \/ in which pwd
<Frosku>guixy: How would I hard code /bin/pwd?
<Frosku>If thats the fix then its the fix
<guixy>perl hard-codes /bin/pwd.
<Frosku>Yeah, but I'm trying to use perlbrew (it's like nvm for perl) to manage multiple perl versions for testing
<Frosku>So I can't use the guix perl dist
<guixy>I know there's a way to make sure /bin/pwd is there... Let's see if I can find it in the manual...
***sneek_ is now known as sneek
<guixy>Adapt that in your config file for /bin/pwd
<Frosku>Any idea which package pwd is in?
<guixy>It's coreutils
<guixy>How long has racket been in the install phase?
<guixy>It's seriously frustrating.
<Frosku>Thanks guixy, that worked
<Frosku>Would have been nice if the error message just said `/bin/pwd: not found` or something lol
<guixy>Am I the only one running into font issues with drracket?
<guixy>the time machine drracket, since the current one doesn't work
<guixy>time machine to any commit b1248016e0492e1897f4d1127ccb07736c9bb6a5 or earlier
<guixy>Finally! hash 948ecc27dd33d6c9bd77e06c82b49e5a1139868b built and it doesn't have a font error.
***iyzsong-- is now known as iyzsong-w
<lfam>Ah, good to know echosa. I'm glad you figured it out!
<everstone>'guix describe' says 'error: failed to determine origin' and the version string is older than the newest guix in /gnu/store/. Why isn't it symlinking to the newest one?
<everstone>Also the date of everything in /gnu/store reads 1970-01-01
<lfam>everstone: The date thing is expected. The timestamps are all set to a particular date for reproducibility
<lfam>The `guix describe` thing, I think it appears after you've installed Guix for the first time, before the first `guix pull`. Does that describe your situation?
<everstone>Ahh, that makes sense.
<everstone>No, I have installed the system guix pulls ago
<lfam>`which guix` should be ~/.config/guix/current
<everstone>Oh! For me it's /run/current-system/profile/bin/guix. I'll rearrange my PATH to make sure that comes first
<lfam>Yes, that's the right solution
<lfam>On Guix System, this is usually handled automagically, but maybe you have some custom bashrc or similar?
<everstone>Yea, I just source the profile it tells me to in my rc
<everstone>Thank you!
<bdju>wow, maybe kick obasekiosa while they sort out their connection!
<bdju>does anyone have experience with getting the beep speaker working? I installed beep and got this error `beep: Error: Could not open any device`
<bdju>now that I think about it, not sure I've ever heard this machine beep. do laptops still have beep speakers? it's a T440p
<bdju>I was hoping to add a little beep to some scripts
<raghavgururajan>sneek, later tell civodul: Why IETF should keep XMPP as IM standard, instead of Matrix? (
<raghavgururajan>middle click paste, damn it
<raghavgururajan>sneek, later tell civodul: Please ignore that (middle-click paste happened). Were you able to look into the issue with glib-or-gtk build system not triggering bootstrap, in c-u?
<sneek>Will do.
<abralek>bdju: lsmod| grep pcspkr, try to run beep with --debug
<bdju>abralek: `pcspkr 16384 0`, beep debug output:
<bdju>maybe I just need to be in an additional group if it's a permission problem
<bdju>won't let my run with sudo `beep: Error: Running as root under sudo, which is not supported for security reasons.` `beep: Error: Set up permissions for the pcspkr evdev device file and run as non-root user instead.`
<bdju>I'm using %base-services rather than %desktop-services btw
<rhou[m]>I'm developing software in guix and was wondering where to put my package definition? In the same repository where my code is and use this repository as a channel or do I create a separate repo for my private channel?
<cbaines>rhou[m], is submitting it to guix an option?
<civodul>Hello Guix!
<sneek>civodul, you have 2 messages!
<sneek>civodul, raghavgururajan says: Why IETF should keep XMPP as IM standard, instead of Matrix? (
<sneek>civodul, raghavgururajan says: Please ignore that (middle-click paste happened). Were you able to look into the issue with glib-or-gtk build system not triggering bootstrap, in c-u?
<rhou[m]>cbaines: No it's not stuff that is interesting for the wider public
<cbaines>rhou[m], OK, I'm not quite sure then
<cbaines>morning civodul o/
<civodul>hey cbaines :-)
<civodul>raghavgururajan: i'm testing a fix for core-updates, together with a glibc upgrade
<abralek>bdju: I've just checked with a test user (tty member) in gnome. gnome-terminal beeps, but not the beep )
<cbaines>hmm, I just did guix system build on bayfront, and it finished, then tried reconfigure, and now it's building QEMU for some reason...
<civodul>maybe qemu 2.1 for grub's tests?
<cbaines>grub is listed as one of the derivations, so maybe
<civodul>yeah, and grub is not built when you run "guix system build"
*** sets mode: +o ChanServ
<civodul>looks like has pretty well absorbed the qt-build-system rebuilds
<civodul>like, there are kcachegrind substitutes even for i686
<civodul>not yet for aarch64
<jlicht>hey guix!
<civodul>howdy jlicht!
<abcdw>Hi guix o/
<yoctocell>hello abcdw!
<abcdw>I have a question regarding module naming. Why bash has its own module, while other shells are in shells.scm?
<abcdw>yoctocell: hi!)
<leoprikler>probably due to cycles
<leoprikler>many packages require bash in some form, but the shells in shells.scm may require one of those programs
<yoctocell>abcdw: Saw your patch for the Bash service, reviewing it now.
<leoprikler>e.g. a shell implemented in java requires java, which probably requires bash at some point
<abcdw>leoprikler: Thanks a lot for the explanation. I found guile quite good at handling cyclic dependencies, but still make a lot of sense.
<abcdw>yoctocell: Thank you!)
<civodul>mothacehe: it's so cool that we can push big rebuilds and have them handled in a timely fashion
<mothacehe>civodul: very appreciable indeed :)
<mothacehe>there are some new features
<mothacehe>I have created separate specifications for the images & system tests
<mothacehe>so that they don't "pollute" the master specification
<mothacehe>it's also easier to see quickly what's the status of those specifications
<mothacehe>for instance:
<mothacehe>I also added the "toggle" button you proposed earlier this week
<mothacehe>to switch from relative to absolute build view
<civodul>mothacehe: woow, nice! those features keep coming in :-)
<civodul>for system tests it's super useful
<mothacehe>the system tests situations seems bad btw
<mothacehe>I need to see if I can reproduce it locally
<civodul>yeah i'll give it a spin too
<civodul>pretty bad the the installation tests don't work
<mothacehe>yup :(
<civodul>mothacehe: BTW, could we have an emulated power9 (!) building the core subset?
<civodul>or could we use the OSUSL machine? (it doesn't run Guix System)
<mothacehe>where is this OSUSL machine?
<lle-bout[m]>mothacehe: Oregon USA
***rekado_ is now known as rekado
<mothacehe>lle-bout[m]: thanks, who has login access to that machine?
<civodul>mothacehe: lle-bout[m], marusich, nckx, and myself at least
<civodul>i suppose you can have an account there, nckx?
<civodul>thing is cuirass-worker would have to be started "by hand" or via a hand-crafted systemd unit
<mothacehe>yes, a small systemd unit could do the job I think
<mothacehe>a user unit even
***sneek_ is now known as sneek
<civodul>however, would it end up building all of the "guix-master" jobset, say?
<civodul>it would be nice to restrict it somehow
<civodul>perhaps we can tweak (gnu ci)?
<mothacehe>we can create a new specification building "core" only for the ppc arch
<civodul>right, that's probably easier
<lle-bout[m]>civodul, mothacehe : the machine OSUOSL provides has quite a slow disk but I could also provide a VM on my machine at home, where I have even PCIe Gen4 SSDs that go 5000MB/s w, and 7000MB/s r
<tissevert>Hi guix
<lle-bout[m]>tissevert: helloo!
<tissevert>: )
<lle-bout[m]>civodul: mothacehe : Vincent also has access AFAICT
<lle-bout[m]>Vincent Legoll
<bonz060_>cbaines: A little late to thank you, but anyways, thanks for pointing out that a conflict could be caused by the Python-roman package being at the bottom of a module... So I'm guessing that I have to keep in mind the order of commits when I push upstream right?
<cbaines>bonz060_, it's not about the order of commits, just when adding new packages, generally avoid adding them at the bottom of modules (unless you specifically want it to be there)
<leoprikler>some modules are also explicitly ordered alphabetically, so that's that
<lle-bout>rekado: hey! somehow I still can't use the patch-set feature, this is empty for example: - any ideas? Thank you!!
<sneek>lle-bout, you have 1 message!
<sneek>lle-bout, raghavgururajan says: It have sent patches to #47643. Could you specify the spots you were referring to regarding comments, via replies? I'll edit and resend that patch. Also, could you start a new branch 'wip-gnome' on savannah please? Thanks!
<bonz060_>chained: I see. Thanks for the tip!
<lle-bout>cbaines: hey! it seems your GPG key 3E89EEE7458E720D9754E0B25E28A33B0B84F577 has expired! Did you somehow extend it's expiration and forget to upload to Savannah? I also get that for BCA689B636553801C3C62150197A5888235FACAC owned by rekado!
<cbaines>lle-bout, hmm, I see it expiring soon (2021-05-17), but that's not yet. I'll extend the expiry date now though...
<lle-bout>cbaines: pub rsa4096 2010-11-07 [SC] [expired: 2019-05-18] - I see this
<lle-bout>did you upload a latest public key export to Savannah?
<lle-bout>Or anywhere else?
<lle-bout>Savannah is currently where I get the keyring from
<cbaines>lle-bout, possibly not, I'll update Savannah now
<lle-bout>okay! great! thanks!
<lle-bout>From here:
<cbaines>I've updated Savannah now
<lle-bout>cbaines: thank you! works now!
<rekado>I always extend my key and upload it to hkps://
<rekado>but I don’t always update my copy on Savannah.
<lle-bout>rekado: okay! Trying to refresh from there now.
<mothacehe>rekado: Fetching from on port 9418 is super slow on berlin, any idea why?
<mothacehe>~2 minutes to fetch one commit
<rekado>don’t know
<balance>Hello please help, how to prevent error "guix system: error: more than one target service of type 'udev'", after executing "sudo guix system reconfigure /etc/config.scm" seems that this mistake in next patr of config.scm "(services (append (list ...) %base-services %desktop-services))"
<balance>trying to install something like virtualbox, libre variant
<pkill9>what is that balance? there is already qemu plus it's frontends
<balance>"guix package -i qemu" and?
<civodul>mothacehe: "installed-os" works for me on master
<civodul>we should add MX entries to and deploy a web key directory (WKD) there
<mothacehe>civodul: looks like it failed while running Guix syscall tests on Berlin
<balance>pkill9: used part of config scm from this link in Ganeti section. Which frontends? sounds like something simple
<mothacehe>In guix/build/utils.scm:
<mothacehe> 735:19 2 (with-atomic-file-replacement "tests/syscalls.scm" #<pr?>)
<civodul>mothacehe: yes, i tried "guix build /gnu/store/r5xjkcxc1mkq18xk9ffmjbx6kw03rw6v-installed-os.drv" (drv from <>) and it fails similarly here
<civodul>it's not while running the syscall tests, but rather while patching it
<civodul>that's because it's starting off /gnu/store/giaqmfv73x1w1iggm3yicx91ck6nghvv-guix-current, which lacks the tests/ directory
<lle-bout>civodul: WKD yes!
<civodul>mothacehe: looks like current-guix-package is not getting set in (gnu ci)
<cbaines>this is an issue I'd like to look in to with respect to the system test derivations that the Guix Data Service stores, as I think they're similarly broken
<cbaines>I haven't got around to thinking about it yet though
<mothacehe>civodul: must be a regression in (gnu ci) indeed. current-guix-package seems to be set in "system-test-jobs"
<civodul>cbaines: does the Guix Data Service use (gnu ci) to compute them?
<civodul>raghavgururajan: commit 4863c4304e7d4d5945474e771d242878f8339d44 on core-updates should fix the bootstrap phase issue you mentioned
<cbaines>civodul, nope, it's going through (gnu tests), I didn't think using (gnu ci) was appropriate
<balance>pkill9: thank you, your advice helped. Have just Installed virt-manager :)
<civodul>cbaines: it's a matter of coupling and responsibilities: delegating to (gnu ci) allows to reduce coupling between Cuirass/Data Service on one hand and the system tests on the other hand
<civodul>*allows you to
<cbaines>all I know currently is there's something a bit off with some of the system test derivations that the Guix Data Service is recording, I haven't looked further in to what's going on yet, but I hope to at some point
<pkill9>I think that like openbsd, we should consider lack of documentation to be a bug
<ekaitz><pkill9> I think that like openbsd, we should consider lack of documentation to be a bug
<ekaitz>I agree with that
<ekaitz>for instance, I don't think the internals of Guix are pretty well explained
<ekaitz>in the documentation, I mean
<ekaitz>i wanted to make an effort on that and try to explain the internals but never got the time to dig :(
<cbaines>what internals are you interested in ekaitz ?
<ekaitz>there's code that isn't obvious to understand
<ekaitz>basically the guix service itself
<cbaines>ah, so the guix-daemon?
<ekaitz>the store is kind of black magic to me too
<cbaines>right, I don't think the next step there is to document it. The long standing ROADMAP item is to re-write it in Guile
<civodul>ekaitz: which parts of the manual did you read and find insufficient for this area?
<ekaitz>I think I've read the whole manual more than once, but that's one thing and other thing is to have the courage to touch the code
<ekaitz>cbaines: oh i didn't know about that, that sounds like a good idea
<ekaitz>basically nowadays i can deal with: packages, some scripts and build systems
<ekaitz>that's all the code I feel comfortable with
<civodul>the mythical rewrite
<ekaitz>the rest is *magic* to me
<civodul>but note that we've been closing some of these big long-standing issues in the past couple of years
<civodul>past year, even
<civodul>mothacehe: builds triggered by evaluations still go through the normal offload mechanism, right?
<civodul>kinda frustrating that the work being done for the latest core-updates eval doesn't show up at
<civodul>i'd happily spend some time staring at blue bars and meditating
<ekaitz>civodul: i'd like to take more time working on guix internals but it's kind of an scary task :)
<civodul>ekaitz: it really depends on what you mean by "internals"
<civodul>very little is "internal" actually
<civodul>most interfaces are public
<ekaitz>let's put it differently: not only adding packages
<civodul>some are not documented in the manual but they at least have docstrings and comments
<civodul>ekaitz: did you try playing with system config, services, etc.?
<civodul>that's another way to "get into it"
<lle-bout>Please help
<ekaitz>I'm running on guix on my only computer, so yeah!
<civodul>heh good :-)
<civodul>lle-bout: great that you put out a call for help with guidelines!
<civodul>though remember that recruiting is never easy
<PotentialUser-96>hi guys, need help with network issue, guix(1.1/1.2) will not connect to internet (while trying to install it), tried real-hardware, virtualbox, no luck, amy ideas?
<lle-bout>civodul: I understand, I hope some people will show up if we are more in numbers the task will be much much easier and less stressful, we also need a tool to collaborate on reviewing RSS feed entries with adding comments, tags etc. in an efficientand easy way.
<lle-bout>Because right now, everyone is bound to repeat reviewing work, we have no way of sharing which RSS feed entry we reviewed.
<lle-bout>I am afraid now I will have to be late again, I've been keeping up ever since I started my first security-related commit in GNU Guix but now it's kind of falling apart
<civodul>lle-bout: it's okay, don't consider that you or anyone has to keep up
<nckx>civodul: I deployed it, so I'm ‘debian’.
<nckx>And mothacehe ☝ since they asked.
<civodul>lle-bout: it's just not possible
<civodul>nckx: you mean you created an account for mothacehe?
<lle-bout>civodul: okay well :-/ - it's still disappointing we can't do it, I hope we can do it some day and everyone puts some time on it that it's a small not stressful task for every one
<nckx>civodul: No, just meant to ping them, but that was confusing.
<nckx>Do they want one?
<civodul>possibly, to run Cuirass worker
<civodul>lle-bout: it's a fact of life, you have to think of your own health and that of everyone you interact with, seriously
<civodul>it's just not possible to keep up
<civodul>instead, we must prioritize things, focus on addressing the most pressing issues
*nckx flies away.
<civodul>and take some time off occasionally too, otherwise we'll all get crazy :-)
<cbaines>I hope keeping up with updates and security updates will get better, but as you say, I think the thing to focus on is making that easier for volunteers to do the work
<civodul>i think lfam could speak about this better than i do when it comes to security issues
<lle-bout>civodul: I understand, I would like to prioritize, the lint color tool would really help that, also if we get a collaborative security tracker for GNU Guix we can probably also prioritize by severity
<lle-bout>I think it would be really great to prioritize by severity, it would really lower stress
<lle-bout>I feel powerless to create these tools, since I have no sysadmins rights on GNU Guix infra, and that I do not know GNU Guile's Scheme.
<civodul>reducing stress is also about ackowledging the fact that security vulnerabilities abound, IMO
<civodul>which is not to say that it's not to be taken seriously
<mothacehe>civodul: regarding build triggered by evaluations: yes they still go through the traditional offload mechanism
<mothacehe>and won't show up in /workers
<civodul>lle-bout: all system admin is under version control, no need to have an account on the actual machines
<mothacehe>63 minutes on core-updates, that's a long evaluation!
<civodul>mothacehe: this one is a full rebuild, so it's probably going to take longer
<civodul>lle-bout: but really, i don't think sysadmin is the bottleneck here since we don't have tools or services to deploy in the first place
<lle-bout>civodul: I understand, I'll take some time off now because it's stressful, also the GNOME upgrade now, I feel like we need help reviewing, there's already been people, I feel like I want to pause my contributions to GNU Guix now because I have plenty of other stuff to handle.
<lle-bout>civodul: We could deploy Debian security tracker software
<civodul>lle-bout: i don't know but yeah, i'd suggest not imposing too much stress on yourself, for sure
<lle-bout>I will come back soon, just need some pause
<mothacehe>civodul: you can cheat the web interface a little to get "live" build log of that evaluation though:
<lle-bout>I hope no one gives up or feels ignored when I am gone :-S - see you soon!
<civodul>mothacehe: yes, i do that sometimes :-)
<civodul>lle-bout: take care!
<lle-bout>thank you ludo for reading and reacting !
*rekado updates jupyter
<yoctocell>Currently the (guix upstream) module only supports fetching the source of a package if it is a tarball, would it be a good idea to add support for Git repos too?
<yoctocell>It would make it easier to create a generic-git-updater that Leo has mentioned:
<lubrito>Hi everybody! I'm an Outreachy applicant. I'm having a little problem with the ./configure step of the setup tools instructions for the Guix Data Service project. I've got this error message: "./configure: line 2365: syntax error near unexpected token `3.0'
<lubrito>./configure: line 2365: `GUILE_PKG(3.0 2.2)' ". I would appreciate if anyone could help me.
<lubrito>I'm running Guix on a Debian 11 (testing).
<rekado>lubrito: this sounds like the GUILE_PKG macro is not evaluated
<rekado>lubrito: are you running this inside of “guix environment guix”?
<lubrito>ops, no
<civodul>rekado: i nitp^W commented on
<lubrito>I'm following this instructions
<civodul>yoctocell: yes, it'd be useful to support Git repo updates
<civodul>0bd1498fc40820be35125cc0a62482d015b58e9b was a step in that direction
<rekado>lubrito: ah, you’re building the data service. Sorry.
<rekado>lubrito: you’ll need to have the development package for Guile, or build things inside of a Guix environment.
<yoctocell>civodul: Cool, I will look into implementing something like this. :)
<rekado>lubrito: I see that the instructions say to use direnv; the .envrc file should set up the Guix environmen for you.
<lubrito>rekado thanks, this helped a lot
<civodul>yoctocell: yay! i guess we need to somehow augment <upstream-source> so it can represent both tarballs and repos (with authentication, somehow)
<yoctocell>civodul: Hmm, I don't really know how we could authenticate git checkouts.
<raghavgururajan>civodul: Thanks!!
<raghavgururajan>Hello Guix!
<yoctocell>Some people sign the tags with pgp, but we would need to have the pgp key to actually verify it.
<civodul>yoctocell: "guix refresh" and supporting code already supports automatically fetching keys, so that's the easy part
<civodul>for Git, it would verify the signature on tags
<civodul>or, ideally, it would also support the "guix git authenticate" method, which is superior
<civodul>but it's also mostly unused outside of Guix, so that can come later :-)
<yoctocell>civodul: so "guix refresh" will already verify the tag signature?
<dmt>i installed quix in my debian 10, so the battery of the laptop died but im lucky an just bought another laptop (it was an old core 2 duo) im sure this is not due to guix so i'll try later
<dmt>the battery presented an error on boot but it was charging but chinesse and "brand new) (1 month old 6600mAh)
<dmt>and indeed the connector of the adapter need a soldadure, i sold the core 2 duo for 20 bucks and nget a i5 5300U with 256ssd for 100
<civodul>yoctocell: currently it only verifies signatures on tarballs, but it also takes care of download keys if needed, see
<civodul>it could do that for tags as well
<dmt>i'll read the the help, glad to use guix :)
<yoctocell>civodul: Ah, ok, thanks for clarifying
<yoctocell>civodul: Looking at 'guix-fetch' in (guix build git), it removes the .git directory which is where you would find the tags.
<yoctocell>Maybe it could keep .git/refs?
<civodul>yoctocell: in (guix upstream) you'd instead use update-cached-checkout from (guix git)
<yoctocell>civodul: Ok, thanks for the pointer
<Vongazi>How can i remove multiaple services from config.scm, because i tried but couldn't find the proper syntax
<roptat>Vongazi, what services do you want to remove?
<roptat>Vongazi, if you mean remove from %desktop-services or %base-services, there's an example in the manual:
<roptat>for multiple services, you can replace that example with something like this: (eq? (service-kind service) gdm-service-type)) becomes (member (service-kind service) (list a b c)) where a, b and c are the service types you want to remove
<Vongazi>roptat, yes thats how i removed gdm, but i also want to remove ntpd
<Vongazi>roptat, thanks
<tissevert>hmmm if I understand correctly, native-search-paths allows one to declare a variable containing a search path for say a programming language in the package declaring said language, but how is the variable actually brought to the user's environment ?
<tissevert>I can't see the variable I'm tracking in /etc/environment
<roptat>only if you have the package that defines the variable in the same profile as packages that would be added to that variable
<roptat>for instance, if you have only guile-cairo in your profile, you won't get GUILE_LOAD_PATH, unless you also have guile which is the package that defines it
<tissevert>seems reasonable, yeah
<tissevert>I don't have trouble figuring a missing variable, I'm merely wondering how PYTHONPATH magically entered my environment (because it's in my system-wide installed packages)
<roptat>well no, I don't think it's reasonable, but that's how guix works
<tissevert>but since guile-cairo doesn't *define* it, it's expected that the variable is missing, don't you think ?
<tissevert>well anyway
<tissevert>I had to write a bash script to edit my environment when entering a $GUIX_ENVIRONEMENT to test a ghc packages and now I had to do just the same giving numpy and pandas a test in python
<roptat>well, to me it'd make more sense that it's defined as long as the package contains lib/guile/3.0
<tissevert>and so I was wondering whether I should automate things, whether it was expected that language packages don't get added to the search paths in environment where you add them (temporarily)
<tissevert>or maybe I'm completely doing things backward and there is a super way to give a library package a test in a dedicated environment in an interpreter
<roptat>you'd install the package and its interpreter in the same environment
<tissevert>except when you install the interpreter in your system (or user) permanent environment, because you use that
<tissevert>and you give a library for that interpreter a try once but you don't want to mess your environment for good in case it's not that useful
<roptat>yeah, so I have guile in my system environment, and if I want to guix guile-cairo a try, I need to run "guix environment --ad-hoc guile guile-cairo" anyway
<roptat>because guix can only set variables when the package that defines it is part of the given profile
<roptat>it doesn't know that it's present in your system profile
<tissevert>of course !
<tissevert>I feel stupid now
<tissevert>I encountered exactly the issue you mention, and instead of figuring I could actually «reinstall» for my environment, I was reinventing the wheel generating my search paths by hand ^^
<tissevert>thank you !
<tissevert>you made my day
<tissevert>oh, magic ! now PYTHONPATH contains exactly what I had made it contain artificially in my previous attempt
<tissevert>: )
<tissevert>and now import numpy works !
<tissevert>I'm done spamming for today ^^' sorry about the verbose enthusiasm and thanks a gain a lot for your help
<Noisytoot>Why does recommend singular they rather than perse/per
<roptat>it's more common? never heard of perse/per before
<Noisytoot>It's also used for
<Noisytoot>This document uses the gender-neutral third-person pronouns “person” (which can be shortened to “perse”), “per”, “pers” and “perself.” These pronouns (aside from “perse”) were promoted, and perhaps invented, by Marge Piercy in Woman on the Edge of Time. They are used just like “she”, “her”, “hers” and “herself”, except that they apply regardless of gender. For example, “Person placed per new program under
<Noisytoot> the GNU GPL, to maintain freedom for all users of per work, and this way perse knows perse has done the right thing.” "
<vagrantc>Noisytoot: and notably more controversial
<Noisytoot>vagrantc, Is perse/per more controversial or they/them?
<vagrantc>one is actually part of the english language, and one is a recent invention by someone who has questionable authority on grammar or linguistics
<vagrantc>and one is in widespread use, and the other, to my knowledge, is not
<roptat>but who has authority on grammar or linguistics? :)
<vagrantc>i'd generally trust linguists, or if you must, grammaticians
<vagrantc>not that they're without fault
<Noisytoot>they/them is more ambiguous
<roptat>but language is ambiguous anyway
<vagrantc>Noisytoot: more ambiguous than something almost nobody has heard of?
<Noisytoot>Is the Guix manual translated into Lojban?
<Noisytoot>vagrantc, "perse", "person", "perself", "per", and "pers" are unambiguous, as they either do not have other meanings, or the other meanings make no sense in the same context
<vagrantc>Noisytoot: but they require actual incorporation into english, which seems to me a great source of potential confusion and ambiguity? "is that a typo? some technical jargon? is it a scheme function?"
<Noisytoot>You could explain at the beginning, like does
<vagrantc>and actually asking english to be precise is like asking the sky to change color
<vagrantc>Noisytoot: let's just agree to disagree here.
<Noisytoot>Why are node.js packages so small?
<roptat>you mean in guix or in general?
<Noisytoot>in general
<roptat>probably because of the culture of reuse, where the idea is that a small function that does a specific job is more reusable that a huge library of functions where you want only one of them
<Noisytoot>it makes packaging more difficult
<roptat>yeah, I know, tell that to JS devs though
<roptat>it does have some advantages though: it kinda limits circular dependencies sometimes
<roptat>in the sense that with a smaller package, hopefully you have less dependencies, so it's less likely you end up having a loop
<roptat>not so true with javascript, but I've seen some cases in java where circular dependency arise because too many different things are part of the same package
<Noisytoot>How do Java package managers manage that?
<roptat>they don't care
<guixy>hi guix
<Noisytoot>hi guixy
<roptat>when you specify a dependency, they just take whichever version was already compiled and available on maven central
<roptat>they don't recompile your dependencies, so as a java developer, you don't see the circularity
<roptat>and we create circular dependencies only because we want to keep only one version of the package, but if you had multiple versions, it would be more like a spiral of dependencies, where you go back one version on each round
<roptat>like A3 -> B3 -> A2 -> B2 -> A1 -> B1 -> no dependencies
<roptat>in that scenario if you depend on B3, since B3 depends on A, your tool would download A3 too, which doesn't make sense for our model
<roptat>in my understanding at least, maven will only use one version of the dependencies, and choose the latest version if there is a conflict in versions
<roptat>it makes it very difficult to reason about which version was actually used when building a given package
<roptat>for node, the tool actually cares about circular dependencies, but only for runtime dependencies
<Noisytoot>There's a package which depends on another package just to provide a function who's definition is: return path.charAt(0) === '/';
<roptat>I told you, it's another culture
<roptat>it sounds ridiculous, but if you implemented that yourself, you'd use == and that'd be wrong in some corner cases
<roptat>so there are some advantages
<leoprikler>using 1+ = com.github.some-user.add-one
<Noisytoot>What's the use of an add-one package?
<leoprikler>It provides a function, that adds one to a number (integer or floating point).
<leoprikler>You can use it to implement counters or something like that.
<Noisytoot>Does JavaScript already have a function to do that?
<leoprikler>now, currently things don't look too rosy with complex numbers, but we're hardly working on reviewing that pull request
<leoprikler>(yes, javascript has an increment operator)
<guixy>I want to set up a profile for all my fonts, but fontconfig doesn't search there. Is there a way to point fontconfig to search in the profile?
<Noisytoot>Maybe there should be 1 guix channel per package
<leoprikler>It is a known problem.
<leoprikler>1 channel per package?
<guixy>Thousands of different repositories with just a package.scm...
<roptat>yes, and then you just need to include the channels for the packages you need, guix won't have to work so hard when pulling :)
<roptat>guixy, I think we patched fontconfig in guix to look for ~/.guix-profile
<roptat>I think that was because it doesn't support an environment variable (or it would only allow for one directory)
<roptat>but there should be a configuration file you can change to let it look into another profile
<guixy>So what if I want all the fonts to be in the profile '~/.other-guix-profiles/fonts'?
<leoprikler>fontconfig hopefully still reads stuff from $XDG_CONFIG_DIR
<leoprikler>that's the file you have to edit :)
<roptat>guixy, according to, you can configure ~/.config/fontconfig/fonts.conf
<roptat>you'd add a <DIR PREFIX= DEFAULT" SALT="">" entry
<guixy>I've tried to configure ~/.config/fontconfig/fonts.conf. It looks like it forgets about all the system fonts.
<Noisytoot>Why are methods of fetching other than git-fetch and url-fetch not documented on
<roptat>maybe you want to start from the default config?
<roptat>Noisytoot, good catch, it's missing, you can write that documentation and send a patch to :)
<guixy><dir prefix="xdg"> adds a directory relative to XDG_DATA_HOME. The system fonts.cfg includes <dir prefix="xdg">fonts</dir>. So if I have the fonts in $XDG_DATA_HOME/fonts it should find those fonts without forgetting about the system fonts.
<guixy>I've tested it. It works for what I want, but I don't think it will work for fonts spread across multiple profiles.
<guixy>Thanks for the help.
<roptat>I think XDG_DATA_HOME can only refer to one directory
<roptat>namely, ~
<guixy> $XDG_DATA_HOME defines the base directory relative to which user specific data files should be stored. If $XDG_DATA_HOME is either not set or empty, a default equal to $HOME/.local/share should be used.
<guixy>Shouldn't XDG_DATA_DIRS work as well?
<roptat>I don't know, it looks like fontconfig doesn't read that
<guixy>hi lfam
<sss2>hi all
<guixy>Hello sss2
<sss2>how to tell in package script which version of gcc i want to use ?
<sss2>or maybe even clang
<lfam>Add the version you want to native-inputs of the package
<lfam>For example, add ("gcc" ,gcc-10)
<sss2>understood, thx
<lfam>Any Rust-ers know what I can do for this Rust / C build problem?
<sss2>and how to change cflags ? )
<sss2>i need more recent standard than default c++11
<terpri_>i was trying to test zathura which has a core package and separate plugin packages for rendering pdf/djvu/etc., but the core zathura package is looking in its own nonexistent plugins dir in the store (/gnu/store/.../lib/zathura) and hence not working at all. what should it be doing instead, looking in the corresponding directory in the relevant profile? or perhaps using a new environment variable since there's not
<terpri_>an obvious way to find its profile at runtime?
<roptat>you can add them to the #:make-flags or #:configure-flags
<roptat>terpri_, you need to install zathura and its plugin in the same profile, then guix will set the right environment variable for you
<roptat>you might need to load etc/profile from that profile in order to get the new variables in your environment (guix should warn you)
<terpri_>roptat, ah, thanks, that works, i was using new screen windows and forgot that those aren't login shells :) whoops
<guixy>Ok, this is weird. drracket has font problems when I launch it with ~/.local/share/fonts linked to the /share/fonts directory in my fonts profile. It doesn't have font problems without that link.
<roptat>did you regenerate fonts with fc-cache?
<guixy>fc-cache -f; drracket
<guixy>Definitely has font issues.
<guixy>rm ~/.local/share/fonts; drracket
<guixy>no font issues
<guixy> as a png
<guixy>I see it's broken.
<terpri_>i wish sourcing $GUIX_PROFILE/etc/profile were idempotent, since then i could source it in non-login shells. tricky to implement that with plain bourne shell, though
<guixy>Here's what I see by default, no link to my font profile in ~/.local/share/fonts
<terpri_>(i guess it wouldn't be *too* harmful, but path lists would end up with lots of redundant entries)
<guixy>Here's what I see with ~/.local/share/fonts linked to my font profile.
<terpri_>and guix did warn me as expected, i just didn't heed its advice :)
<guixy>Maybe I'm using redundant fonts?
<pkill9>terpri_: it looks in $ZATHURA_PLUGINS_PATH
<pkill9>which is added as a searhc path for zathura
<terpri_>pkill9, thanks, that's useful to know. i got it to work, i just forgot to source the profile settings so i guess it used a built-in fallback
<terpri_>now to test it -- i'm looking for a pdf reader that's a bit faster than evince for book scans (evince doesn't really seem to prerender upcoming pages even with 50GiB RAM available)
<rekado>the worst thing about updating jupyter packages is that they all need each other for running their individual test suites.
<leoprikler>from what I know about evince, it seems to keep ~3 pages of context alive
<civodul>rekado: all i can say is that i'm with you, i passively share the pain :-)
<leoprikler>rekado: w.r.t. improving python package quality, all you can do is to dance the bootstrap dance with all of them
<terpri_>leoprikler, yeah, that sounds about right. if there's a setting for that i can't find it (increasing the page cache size doesn't seem to help)
<leoprikler>perhaps make the single packages hidden and add a meta-package that depends on all of them and runs all the tests?
<lfam>Maybe we could use the --without-tests package transformation
<lfam>Like, have a package transformer (package-without-tests) that gets used somewhat automatically when we need it
<guixy>Speaking of jupyter, it would be nice to have a jupyter-notebook service.
<leoprikler>having such a transformer is meaningless when it's necessary
<leoprikler>--without-tests should always be optional or at least depend on whether or not you're running on a really flaky machine :)
<lfam>I mean, that's basically how the Python bootstrap dance works, by skipping tests
<lfam>This would just be an easier way to write the packages
<lfam>We've done this several times before, but it remains inaccessible to many contributors
<sss2> - how to properly define patches ?
<lfam>There are also some Python package graphs that just don't run the tests, and skipped the bootstrap dance entirely
<lfam>Like, we wrote the base of the package graph of certbot that way. Certbot has always worked fine
<guixy>python-hy keeps breaking because a dependency fails its tests.
<lfam>If we combine this work with a way to propagate #:disallowed-references up the package graph, it would be "safe" to programatically skip tests for this purpose
<lfam>At least, it would be an improvement to what we do now, which is pretty ad-hoc and under the radar
<lfam>If someone else submitted the certbot patches now, I might let them through or ask for revisions, based on my mood. They don't really meet our packaging standards
<terpri_>sss2, someone may have a complete answer, but you can take a look at how %patch-path is defined in gnu/packages.scm. it looks like you can set/add a directory to the GUIX_PACKAGE_PATH env var and use patch paths relative to that dir
<jeko>Hey Guixters!
<guixy>hi jeko
<terpri_>sss2, and it appears to look for patches relative to <channel-dir>/share/guile/site for channels but i'm not sure about that ('package-path-entries' appears to effectively add that dir to the load path, and hence patch search path, for channels, afaict)
<sss2>m.... sounds complicated
<terpri_>sss2, since kcollectd looks like it's set up to be used either in the channel or standalone, i think you could move the patches to <repo>/share/guile/site and search-patches should work as written with the channel, and with GUIX_PACKAGE_PATH=<repo>/share/guile/site set if you're building it as a standalone file
<terpri_>i haven't used search-patches outside of the main guix repo, though, so i could easily be wrong
<terpri_>(and yeah, it does look a bit complicated; i'd assume search-patches would use a directory layout similar to the guix repo's by default, and it looks nontrivial to customize the path...)
<terpri_>i'm also just skimming the definitions :) so my suggestions might be wrong
<civodul>terpri_: you can also use (local-file "./foo.patch") instead of 'search-patches'
***m6locks_ is now known as m6locks
<zzappie>Hey guix, how can I see what went wrong in bult-derivation?
<terpri_>civodul, ah, ty! that's much simpler :)
<sss2>terpri_, thx, i will try
<sss2>terpri_, thx, it works, now i need to find out how to properly pass cxxflags, looks like it ignores configure option and still forces gnu++11
<apteryx>is there a way to easily test a udev rule?
<apteryx>and am I supposed to reload the udev rules following a system reconfiguration with the new rule in place?
<civodul>apteryx: i think you have to reboot for the new udev rule to take effect (that sucks)
<civodul>see: sudo cat /proc/PID/environ |xargs -0 echo
<civodul>where PID is the eudev PID
<civodul>we could fix it by keeping rules in a fixed location, /etc/udev
<civodul>like everyone else is doing, basically
<apteryx>especially if it allows udevadm to pick the rules it seems it'd help indeed :-)
<apteryx>right now it only looks at eudev's store location
<civodul>but... is udevadm supposed to read the rules?
<civodul>i thought it'd just talk to the daemon
<apteryx>also if you add -n1 to your xargs command above (thanks!) it prints them on separate lines (I've learned this in #gnu today!)
<civodul>oh! didn't know that
<civodul>(still won't join that channel though :-))
<apteryx>I was experimenting with 'udevadm test /my/device'
<apteryx>as part of its output it seems to be actively checking if some rule file matches it
<apteryx>Would restarting the udev service refresh those environment variables it knows about?
<apteryx>(I tried earlier, that had the side effect of killing my graphical session, eh)
<civodul>apteryx: yes, it amounts to rebooting your machine
<civodul>see "guix system shepherd-graph"
<sss2>hmmmm, can't force CXXFLAGS for cmake-based project
<apteryx>civodul: apparently udev uses the inotify mecanism to keep track of changes to /etc/udev/rules.d and reloads the rules when they change
*apteryx sudo herd restart udev
<sss2> CXXFLAGS does not work, any ideas why ?
<apteryx>sss2: I think cmake is supposed to honor CXXFLAGS from the environment
<apteryx>you could try (setenv "CXXFLAGS" "your-value") before the configure phase (cmake) runs
<apteryx>see guix environment --ad-hoc cmake info-reader -- info '(cmake)CXXFLAGS' for the details
<Noisytoot>Another dependency of Sourcehut (node-once):
<Noisytoot>Could someone apply it?
<apteryx>sss2: I'm no expert though; you may want to consult in #cmake for better advice
<lfam>Noisytoot: Does it work? The removal of the configure phase and the comment "Fails due to tap being missing" needs to be explained a little more
<Noisytoot>lfam, It works
<Noisytoot>if configure was enabled, it would fail
<lfam>I recommend explaining things like this in a code comment
<lfam>I mean, you explained it partially, but not enough
<Noisytoot>Should I send a v2?
<lfam>Yeah, explaining the situation more fully
<lfam>You could even just send a followup email
<Noisytoot>Is "If configure existed, it due to tap being missing" good?
<Noisytoot>s/it due/it would fail due to/
<lfam>Imagine that you didn't know anything about this package
<lfam>Like me :)
<lfam>It looks like it's not done yet
<lfam>A build phase is removed due to a missing dependency. Does the package even build?
<Noisytoot>"If configure existed it would fail due to tap being missing, as we do not have tap packaged yet, tap is used for tests"
<sss2>apteryx, probably this cxxflags inherited from some other cmake script, and overriding manually set cxxflags ...
<lfam>Much better :) But, most packages can't build if you skip the configure phase
<lfam>So, it's still a bit mysterious
<lfam>You have to share your knowledge of the situation, so that reviewers can feel confident that the package is ready
<lfam>Maybe you could say "But the package still works as a dependency of 'foo', which is currently being packaged"
<Noisytoot>lfam, It does build without configure