IRC channel logs


back to list of logs

<ngz>Barring the change I made to use "guix environment guix --" before "make authenticate".
<nckx>ngz: But the script the hook calls (build-aux/git-authenticate.scm) was just changed.
<nckx>To no longer explicitly append ‘origin/’.
<ngz>I pasted the error I got from git (Magit actually). Process buffer has 3 lines: "Authenticating Git checkout..." then the error I pasted, then "error: cannot push references..."
<cbaines>I get "Git error: cannot locate remote-tracking branch 'keyring'" now, I guess I need to change something
<nckx>ngz: That's just make saying ‘the error that just happened killed me’, but it's not the actual error.
<nckx>It's possible that build-aux/git-authenticate.scm silently returned failure but that is not good and needs fixing.
<ngz>nckx: OK. I ran "git push" from the command line and got the same error as cbaines.
<nckx>cbaines: civodul said… something about an explicit ‘keyring’ branch? I can't remember where.
<cbaines>It was in an email
<nckx>Yeah, I thought it was something you participated in.
<cbaines>I was posting as I was hoping you'd have the solution nckx! :D
<nckx>TBH it didn't read like an ‘I'm going to push this thing now’ to me but I wasn't paying all the attention. Welp. I guess it's been pushed.
<nckx>cbaines: Er, no, I reverted that commit because it conflicts with my own changes.
<ngz>civodul wrote: "That also requires you to set things up appropriately".
<ngz>Without further ado.
<ngz>And now, the question is: what does that mean…
<nckx>ngz: There's already an upstream/keyring (or origin/keyring or whatever you've called it — that was the mess this was solving). I suggest you set up a local ‘keyring’ branch that tracks it and try again.
<nckx>git checkout --track ${origin}/keyring
<nckx>(Then switch back to master.)
<PotentialUser-83>Hello, using USB install on headless server the graphical installer doesn't appear on TTY1/VGA port
<PotentialUser-83>I see a ghost of it when I switch back and forth between TTYs.
<nckx>I think I have a better fix for this but there are 2 things higher on my TODO list.
<raghavgururajan>nckx: Do you know what "warning: SQLite database is busy" is about?
<raghavgururajan>Guix commands freeze with that.
<nckx>Hello PotentialUser-83. I don't think running the TUI installer over serial ports is supported, or at least tested.
<PotentialUser-83>Hello nckx I'm using an actual VGA monitor plugged into the VGA port.
<nckx>raghavgururajan: They don't freeze, they wait. This is a similar problem to the other one: over-contention of the database. You're waiting for a lock. So I know what it's about but I can't make it go away, sorry.
<nckx>My god I'm terrible at reading today. I'm sorry PotentialUser-83. I'm running back and forth between machines 🙂
<raghavgururajan>nckx: Thanks and no worries.
<ngz>nckx: Thanks! This seems to work. It builds the whole Guix again, tho.
<nckx>I'd just come from a serial console and that's enough to confuse my little brain. PotentialUser-83: What model graphics card do you have? I know AMD can be… problematic. I've never heard of the ‘ghost’ issue you describe before, though.
<nckx>PotentialUser-83: I think it's unlikely to be the fix but try booting with ‘nomodeset’ on GRUB's ‘linux …’ command line, if you know how to do that.
<nckx>It just might work.
<NieDzejkob>confused IRC with a shell? :P
<cbaines>yeah, and on that note I'll say goodnight :)
<PotentialUser-83>Thanks nckx: I'm using the built-in VGA on an Asrock server MB. It works fine on TTY2-4. I see the ghost when I switch to TTY1
<PotentialUser-83>So do I do the Grub thing on the root login on TTY2?
<NieDzejkob>PotentialUser-83: ideally you'd press e during boot and edit the kernel commandline in GRUB's interface
<NieDzejkob>I don't know whether you'll manage to modify the config from a booted installer
<nckx>PotentialUser-83: No, before even booting, when the GRUB menu (briefly) shows, you press ‘e’ and add ‘nomodeset’ at the very end of the (multi-line) ‘linux …’ line.
<nckx>Or, y'know, what NieDzejkob meantimes said.
<nckx>cbaines: Good night!
<PotentialUser-83>Cool, thanks. I'll try that.
*nckx strikes item #1 off the to-do list after 2 days \o/ Never have I been happier to see ‘error in finalisation thread: success’.
<ngz>Congratulations… I guess :)
<nckx>Moar substitutes for the data service.
<nckx>Thanks, I guess.
<ngz>You're welcome, I guess.
<nckx>I do!
<PotentialUser-83>YO nckx & NieDzejkob... nomodeset worked. Many thanks!
<bonz060>Is `guix deploy` only limited to systems that run GUIX? Can it run, say on foreign distros that use guix as a package manager?
<nckx>bonz060: It deploys entire operating-systems, so no.
<bonz060>nckx: Thanks for the clarification.
<nckx>bonz060: Since all Guix manages on foreign distributions are user profiles, SSH + guix package -m some-manifest.scm is probably enough.
<nckx>I just tried to use stdin as manifest, didn't work, would've been a neat one-liner otherwise.
<bonz060>nckx: I reckon you could something like ansible to run `guix package -m <manifest.scm>`. Btw, the manifest file contains all the packages for the guix system right?
<bonz060>I tried it once on some slow internet, and gave up. Ended up installing packages manually.
<nckx>It contains all packages for a profile, here a user profile, since there is no system profile on foreign distributions.
<nckx>It's just a list of packages.
<nckx>Well, it's a Scheme file that can do magic^Wanything, but it returns a list of packages.
<nckx>You mean you tried a manifest? Manifests do the (more robust) equivalent of ‘guix install $(< list.txt)’ so there's no speed difference at all. Can't speak for ansible, never touch the stuff.
<bonz060>nckx: the problem i had was that I had some packages that I never really needed from an older work station. When moving to a new machine, I realized I was downloading way too many things, moreso things I never really needed. So I opted to just cut down on things. At the time, I wrote a script to download things. I never really knew you could use the manifest.scm file like that.
<bonz060>nckx: Also, ansible is really convenient if you are managing a fleet of machines. Really convenient imho.
<nckx>bonz060: Hm, the example isn't really clear to me. I hope I didn't oversell manifests (‘just a list of packages’, remember). You still have to maintain that list like you'd manage the ‘implicit’ list of packages installed with ‘guix install’, and they still need to be downloaded from somewhere. You could throw ‘guix copy’ into the mix but that might get complicated.
<nckx>bonz060: To give you an idea of the largest ‘fleet’ I've ever managed: clusterssh worked marvellously 😉
*nckx → afkish.
<Kozo>Is anyone else getting "Git error: the SSL certificate is invalid" when doing guix pull? This is a fresh install of 1.1.0-5
<nckx>Nope, but I didn't start a 1.1.0 VM.
<nckx>Kozo: Untested idea: ‘guix pull --url=’.
<nckx>Seems to work.
<wdkrnls>Is there an autofs-service somewhere?
<Kozo>nckx: That worked. Thank you very much :-D
<Kozo>nckx: Oddly, the downloads say they are coming from https://~
<nckx>wdkrnls: Not that I know of. I have a package on another laptop I could update & submit but no service.
*nckx supresses ‘wow someone who actually uses autofs’
<raghavgururajan>Is there a way to disable dependency on systemd, when there is no build option to do so?
<raghavgururajan>I am trying to package sysprof.
<ArneBab>cbaines: is there a way to enable sudo? That way I could use addgroup directly.
<ArneBab>cbaines: context is users and groups in a container via environment
<bonz060>nckx: is clusterssh atomic? I guess I'm sold on Ansible because it's well marketted, plus everywhere I've worked in uses it, hence more familiar lolz.
<nckx>bonz060: Oh no no, it's literally a bunch of SSH windows you can type into at the same time 😃 It was a joke, except it wasn't, I use it.
*nckx → 😴
<nckx>raghavgururajan: Lucky for you I can't sleep. Unluckily(?) for you I've already packaged Sysprof but it doesn't work yet. I'm not that motivated to work on it right now, feel free to:
<nckx>raghavgururajan: Looks like gobject-introspection and pango can go; they have no effect on the end result.
<nckx>raghavgururajan: Neither does -Dhelp=true here.
<nckx>raghavgururajan: My typo: profile → profiler. Now we try to sleep again.
<raghavgururajan>nckx: Thank you!
***dingenskirchen1 is now known as dingenskirchen
<wdkrnls>nckx: I'm curious why you had the reaction about autofs?
<wdkrnls>err... the reaction of 'surprise'
<wdkrnls>maybe I could just use shepherd and mcron for all of that stuff?
<Nios34[m]>Hi. I used 'guix init /mnt/etc/config.scm /mnt' to install guix system.
<Nios34[m]>But guix said "error: opening file '/gnu/store/*.drv': No such file or directory", what should I do?
<roptat>Nios34[m], sorry I'm going to bed soon, but did you start cow-store?
<roptat>maybe check your installation media is not corrupted
<roptat>also, it would help if you could give some more details: what version of the guix installer is that, what architecture, what machine are you installing onto?
<Nios34[m]>roptat: x86_64 PC
<roptat>is that guix 1.1.0, or a custom installation image?
<Nios34[m]>roptat: 1.1.0
<roptat>I suppose you followed the manual installation steps in the manual, and didn't use the "graphical" installer?
<Nios34[m]>roptat: Yes. graphical installer also throws that error
<Nios34[m]>roptat: There are lots of drv files in /gnu/store, but that was missing.
<roptat>that's weird
<roptat>what is the name of that drv? (ignoring hash name)
<roptat>maybe run guix gc /gnu/store/hash-ghostript-9.27.drv then try again
<Nios34[m]>'error: extraneous arguments' returned
<roptat>sorry, guix gc -D /gnu/store/hash-ghostript-9.27.drv then try again
<Nios34[m]>Oh no
<Nios34[m]>I run it. And that package is OK now.
<Nios34[m]>But another package went wrong.
<Nios34[m]>Should I do it again?
<roptat>if that worked the first time, I guess you can try again... ^^
<Nios34[m]>I don't know how many times I will repeat it :-(
<dongcarl>I just want to express my utmost respect to Guix's maintainers. Functional distros are the future of computing, and Guix is at the forefront of what is possible. All hail Guix!
<roptat>thanks :)
<roptat>Nios34[m], agreed, you shouldn't have to do that
<Nios34[m]>Oh, I found the solution.
<roptat>"guix gc" with no argument maybe?
<Nios34[m]>I used 'guix gc --verify'.
<Nios34[m]>And everything is OK now
<Nios34[m]>:-) Thank you roptat
<roptat>cool :)
<Nios34[m]>Good night :-P
<roptat>it should have been my first reflex, but hey, I'm getting tired :D
<roptat>good night ^^
<Nios34[m]>dongcarl: All hail Guix!
<Nios34[m]>Hello. I have two graphics cards, each of them is connected to a monitor. But my guix system (Gnome) just found only one monitor.
<Nios34[m]>How to detect them and set up dual monitors?
<bdju>Nios34[m]: I probably won't know how to help, but I might as well ask you a few things. Did you use this setup on a previous distro and have it work? Are these AMD or Nvidia GPUs? What software have you tried to use to configure the monitors? Are you using X11 or Wayland?
<Nios34[m]>bdju: Intel built-in GPU & Nvidia GPU I don't where to find the Xorg
<Nios34[m]>- config file
<Nios34[m]>*don't know
<bdju>Nios34[m]: you may want to use the xrandr or arandr programs to try to configure your monitors
<bdju>Nios34[m]: on Guix System you would probably make Xorg-related changes in your /etc/config.scm rather than the traditional location.
<bdju>Nios34[m]: there is set-xorg-configuration which may be relevant, you could search it in the manual.
<bdju>also xorg-configuration
<Nios34[m]>xrandr only shows one monitor too :-(
<bdju>I wonder if you need something driver-related for the nvidia stuff, like bumblebee.
<bdju>I'm not seeing results for bumbleebee or optimus in the manual, though.
<Nios34[m]>I saw the nouveau works well (from Xorg log)
<bdju>Nios34[m]: is this switchable graphics in a laptop or an intel desktop with an nvidia gpu added?
<Nios34[m]>Nope. I'm not using laptop
<bdju>ah okay
<bdju>I'm not sure what to suggest. Hopefully someone more knowledgeable comes along and can help you.
<Nios34[m]>Hmmmmmmm, how to kill the Xserver? Maybe I can regenerate a config file.
<wdkrnls>I'm having trouble with Guix not recognizing installed Emacs packages.
<wdkrnls>One thing I noticed is that Guix on my other computer has two additional paths in the load path referring to my home directory.
<bdju>Nios34[m]: try to kill GDM with pkill or htop maybe
<wdkrnls>The Guix I'm looking at doesn't seem to have these.
<wdkrnls>Guix seems not to have set the load path.
***apteryx is now known as Guest29175
***apteryx_ is now known as apteryx
<icefox>If I want to use multiple wireless network cards in Guix System, how should I configure it?
<icefox>'(wpa_supplicant-service-type (wpa_supplicant-configuration' seems to be only available for one wireless network card.
***sneek_ is now known as sneek
<guix-vits>icefox: IDK, but why not use the Network Manager? It's using wpa-supplicant as "backend" afaik.
<bricewge>icefox: Did you try multiple instances of wpa_supplicant-service-type with a different interface field?
*guix-vits "Why not use the Network Manager? Aren't that 'bettet' than just wpa-supplicant?"
<bricewge>guix-vits: It depends on what you want; using NM here
<nckx>Good actual morning, Guix.
<guix-vits>bricewge: :)
<guix-vits>Hi nckx.
<nckx>cbaines: FYI, the GDS is sending a lot of /output/ requests my way which will always return 404. Just in case you rely on them for anything.
<cbaines>nckx, thanks, that's useful to know, probably means I've forgotten to add the code not to do that
<cbaines>From memory the /output/ related requests are for finding out what Cuirass builds there are for an output
<nckx>cbaines: ‘The build information can also be queried by output. For example,@samp{/output/kg9mirg6xbvzcp0a98v7326n1nvvwgsj-hello-2.10} will returnthe details of the output, along with the build if available.’
<nckx>I finally downloaded Cuirass 😉
<mroh>good morning guix!
<nckx>Hullo mroh.
<PurpleSym>Guix drops me into a (minimal) shell while booting, but there’s nothing in the logs after starting with an old generation. Anything I can do to debug this problem?
<rekado_>PurpleSym: this often means that Guix was unable to find the root file system.
<civodul>janneke_: i'm done reviewing the patch series!
<civodul>great work
<janneke_>civodul: thank you!
<civodul>janneke_: you can ping me today if things i wrote are unclear
<civodul>but it looks like those 8 patches can soon get in
<PurpleSym>rekado_: Nope, it’s mounted and I can actually continue the boot just fine by exiting this shell (^D).
<janneke_>mothacehe also did his review, after i get all comments done, we'll be pretty OK
<janneke_>civodul: one quick question about exporting <menu-entry> from gnu/bootloader.scm
***janneke_ is now known as janneke
<janneke>civodul: i've been using that in bootloader/grub.scm with 'match'
<janneke>(($ <menu-entry> label device mount-point linux arguments initrd #f ()) .. linux-bits)
<janneke>(($ <menu-entry> label device mount-point #f () #f kernel arguments modules) ...multiboot)
<janneke>guess i'll rewrite that using accessors?
***MSavoritias_ is now known as MSavoritias
***rekado_ is now known as rekado
<mbakke>nckx: do you remember why openconnect needs a specific version of GnuTLS? Ref a5ab71c73f595f690839f9027c507b50899776f4
<mbakke>I suppose it does a version check at build-time?
<civodul>janneke: yeah
<civodul>sometimes it's less convenient to use accessors, that's a tradeoff
<janneke>np, "it works" and yeah, it's pretty bad to use match this way and break encapsulation
<janneke>(eh, the rewrite now works)
<janneke>almost done rewriting activation and reordering etc-service
<nckx>mbakke: Yes.
<nckx>I'll add as a comment.
<nckx>mbakke: Unless you're merging something that will ungraft gnutls?
<mbakke>nckx: oh, a comment is great
<mbakke>I wanted to graft GnuTLS 3.6.14 to fix the TLS verification issue giovanni reported, as well as CVE-2020-13777, but the soname is different even though the ABI is compatible... 🙄
<mbakke>wait, the soname is different even between 3.6.12 and 3.6.13
<nckx>The thot sickens.
<mbakke>I suppose packages do not link the full ?
<mbakke>from a random sample, it seems they use
<nckx>mbakke: The only package I know off the top of my head requires gnutls & I would have noticed breaking is knot, and indeed it uses .30.
<nckx>Quite the risky assumption to generalise, but nothing seems to have blown up yet.
<civodul>nckx: do you know what the Python plugin of sudo buys us?
<nckx>Just that: users can write plug-ins in Python or C now. It buys ‘us’ as distro integrators nothing.
<nckx>civodul: Since it splits so nicely into a separate output I'm partial to keeping it as such.
*nckx assumes Mathieu tested said output, /me did not.
<civodul>nckx: oh i hadn't seen that Mathieu moved it to a separate output
<civodul>sounds good!
<nckx> - it's a bit of code but nothing terrible.
<janneke>civodul: i think i succeeded in slightly parameterizing etc-services for usage on the hurd
<civodul>janneke: cool
<janneke>(sudo and nsswitch do not compile, so we "couldn't" use generic etc)
<janneke>there were more reasons: remember the qemu-image cross-build bugs...
<janneke>that was kludged in hurd-etc-service
<janneke>timezone can't be "GNUeurope" anymore, though :-(
***dingenskirchen1 is now known as dingenskirchen
<mbakke>so I've spent way too long troubleshooting what I thought was a regression in a KDE package during an upgrade on 'staging', but it turns out we always had the same problem and it just popped up in a new consumer :-/
*civodul sympathizes
<civodul>janneke: oh, should i push those (gnu system vm) changes?
<janneke>civodul: that would be nice
<janneke>i verified yesterday that wip-hurd-vm does not depend on those...but still
<civodul>ok, i'll do that
<civodul>it did seem to help when targeting arm
<civodul>but perhaps it didn't expose all the issues you encountered
<janneke>yes, hurd is tricksier
<janneke>or arm more forgiving if you build an extra kernel for the wrong arch
*janneke does not remember the details
<janneke>we were pretty close
<janneke>civodul: crap: we need /etc/login for the hurd
<PotentialUser-79>Hi. I've just installed guix on virtualbox using the graphical interface. I'm scanning this page and cannot find out how to find this file on my system's configuration. In nixos it's configuration.nix and it's located always in /etc/nixos.
<janneke>oh, an motd
<cbaines>PotentialUser-79, Hmm, I think I remember there being a problem with this
<cbaines>PotentialUser-79, does /run/current-system/configuration.scm exist?
<PotentialUser-79>cbaines: yes. indeed, it's there :)
<cbaines>PotentialUser-79, great, I'm not sure you should edit that file, but copying and editing will be fine
*janneke adds them for the Hurd...we'll see
<NieDzejkob>you can either put it in /etc/config.scm or something like your dotfiles reo
<NieDzejkob>man, I'm too used to message editing
<PotentialUser-79>and then after editing it's `guix system reconfigure my-config.scm`?
<PotentialUser-79>also, how would do the same as `nixos-rebuild switch --upgrade` in guix?
<PotentialUser-79>sorry :) wrong window
<cbaines>PotentialUser-79, yeah, you've got the reconfigure command right
<cbaines>I don't know what nixos-rebuild does though, can you explain?
<civodul>it's sorta like "guix system reconfigure"
<civodul>IIRC "--upgrade" upgrades Nix (the interpreter)
<PotentialUser-79>its update nix channel of packages and then installs the new versions of them (all in one command). In guix i tried i see `guix system upgrade` and it gives me the warning to do `guix pull`. The pull took maybe 20 min but i suppose it updated the local package repo on my machine but still did not still the new versions, right?
<PotentialUser-79>cbaines: civodul btw, the config.scm is also in etc. It's called config.scm vs configuration.scm in /run/current-system
<cbaines>PotentialUser-79, I don't think there's a single command equivalent for Guix
<cbaines>guix pull updates Guix itself, and the package definitions available
<cbaines>guix system reconfigure will reconfigure the system
<cbaines>guix upgrade (or guix package -u) upgrades the packages in your profile
<cbaines>PotentialUser-79, either is fine, the naming of the system configuration doesn't really matter
<civodul>PotentialUser-79: the one in /run/current-system is different, see 'provenance-service-type' in
<PotentialUser-79>running `guix upgrade` i get warning: Consider running `guix pull` (even if i have ran it already)
<cbaines>PotentialUser-79, guix pull is per user, so that could be why
<PotentialUser-79>oh, i see, i ran those commands with sudo
<PotentialUser-79>I've found an article in reddit that with linux-libre 5.3.10 (gui i suppose) one is able to run guix os on virtualbox in fullscreen mode (somthing i cannot right now and it very annoying)
<PotentialUser-79>so, my question would be: i see in config.scm (service gnome-desktop-service-type). How would go about finding the other possible desktop services' names?
<PotentialUser-79>I found this quote id docs: This is a list of services that builds upon %base-services and adds or adjusts services for a typical “desktop” setup.
<PotentialUser-79>but i dont understand in which content i can evaluate this variable. I tried it in guile repl, but got errors
<PotentialUser-79>oh :) It appears linux-libre 5.3.10 (meaning 5.3.10 kernel version). Im running 5.4 already and the fullscreen in gnome does not work in virtualbox :/
<PotentialUser-79>Changing "Graphics controller" to "VBoxVGA" made the fullscreen work
<cbaines>PotentialUser-79, there's a services section in the manual:
<cbaines>guix system search ... also allows searching for services
<PotentialUser-79>ok, with fullscreen, i can start reading/learning. Thank you guys
<cbaines>Whoa, according to this page, I managed to build 97% of package outputs for x86_64-linux
<rekado>cbaines: can’t wait to switch to your build coordinator
<cbaines>I was expecting more things to fail to build, but maybe the actual percentage of build failures is 3% or less, which seems pretty good!
<rekado>many of the build nodes are idle which is a shame
<cbaines>I'm pretty sure some of the things I've built failed to build on the first attempt, but what I'm doing is just trying some more times if that happens
<cbaines>rekado, I'd be very happy to help you make use of this if you'd like, maybe I can do an initial pass at packaging it for Guix today
<janneke>hmm? "Git error: cannot locate remote-tracking branch 'keyring'"
<cbaines>rekado, do you have some specific uses in mind?
<cbaines>janneke, I had that as well, but creating a branch called keyring tracking the remote keyring branch helped
<cbaines>git checkout --track ${origin}/keyring
<janneke>cbaines: thank you
<janneke>that works :-)
<rekado>cbaines: specifically, I’d like to replace cuirass :)
<rekado>with cuirass I don’t know what machines build what, if they build anything at all, and it often seems like it’s busy with things other than building packages.
<cbaines>rekado, OK, have you maybe got 1 or 2 build machines to try it out on? They could probalby still be used by Cuirass at the same time.
<rekado>yes, we have enough build nodes to dedicate one or two
<civodul>i think it'd be good to plan ahead a bit what to do with cuirass, coordinator, offload
<civodul>maybe we're still in an exploration phase, but it'd be nice if it could converge eventually
<cbaines>I'm very up for more discussion about vision/direction
<civodul>cbaines: maybe experimenting with the coordinator on berlin like you discussed earlier is a good next step
<civodul>i don't know if it's because it's cloudy today but i feel overwhelmed and somewhat unhelpful
<cbaines>what's on your mind (other than clouds :) )?
<civodul>i was looking at the "guix environment" performance issue and it's muddy
<cbaines>I saw an email about propagated inputs and their effect on performance, is it that issue?
*janneke goes afk for a while
<civodul>cbaines: not really, it has to do with grafts
<civodul>or at least that's part of the problem
<cbaines>ah, right
<cbaines>Tracking something about grafts in the Guix Data Service is still at the back of my mind
<cbaines>The package replacement field would need recording, but maybe with that and the narinfo references information, there would be enough to work out what grafts would be made
<cbaines>I guess some of the information isn't quite right because grafts are just ignored
<cbaines>None of this helps with guix environment though :)
<civodul>ah yes, (gnu ci) adds replacements to the list of packages to build
<civodul>perhaps you could do something similar
<cbaines>Interesting, thanks :)
<nckx>jonsger: I just saw <>. Pity.
<nckx>Strange that I never got the mail.
<PotentialUser-79>i dont understand. I've added icecat to package list in my /etc/config.scm. Then did `guix system reconfigure /etc/config.scm` with and without sudo. After about an hour the process was finished, but there is not icecat in the path. Why?
<cbaines>PotentialUser-79, you might need to reload the profile environment variables, maybe try: source /run/current-system/etc/profile
<guix-vits>PotentialUser-79: did you'd used sudoedit? Close the $EDITOR, save isn't enough. Was once with me.
<nckx>rekado: Is there any kind of monitoring one the build nodes?
<NieDzejkob>PotentialUser-79: usually it's not recommended to install packages like icecat system-wide
<mroh>PotentialUser-79: it is a good practice to keep the packages of the system profile small. its more flexible (and faster) to add most packages to the user profiles.
<NieDzejkob>if you want to specify them in a configuration file, look up manifests
<PotentialUser-79>ok, thanks. mroh, so you normally guix users install packages as a user with `guix install package-name`?
<mroh>PotentialUser-79: yes, even as root
<mroh>PotentialUser-79: there are some exceptions like windowmanagers or packages that install system dbus services etc
<guix-vits>PotentialUser-79: an manifest for `guix package -m <file>`
<NieDzejkob>guix environment --container seems to die immediately when I add --expose=/bin to the arguments. How do I go about debugging this?
<civodul>NieDzejkob: oh it might be a bug because --container wants to add its own /bin, with /bin/sh
<civodul>to debug it you can strace it
<mbakke>nckx: the build nodes are monitored here (requires a client certificate)
<mbakke>it's pretty rudimentary though
<NieDzejkob>civodul: huh, yeah, strace -f ends with mkdir("/bin", 0777) = -1 EEXIST
<civodul>NieDzejkob: you could try modifying (guix scripts environment) such that it doesn't add its own /bin if the user specified one
<nckx>mbakke: Mmm, right, and I never got one set up.
<nckx>mbakke: So the build nodes have been up for >10 days. What was the average CPU usage over that time?
<nckx>(Roughly 🙂)
<nckx>I think it was 1.63%.
<nckx>Forgive (oh god forgive) the bashery:
<nckx>I honestly hope I made a type somewhere but I'll need convincing.
<nckx>Heh. *o.
<mbakke>nckx: seems not too far off:
<mbakke>so all nodes are represented on that graph, despite the description... as you can see only a handful are active at any given time, and only for a short period
<nckx>Holy —.
<nckx>No no no, I wanted to be wrong :-/
<mbakke>we clearly need to do something about cuirass :-) though right now, most of the jobs are stuck waiting on the DB lock
<mbakke>cuirass seems to have just given up on staging: :P
<nckx>1.63% of a week is less than 3 hours. That's how much work the build farm did this week.
<cbaines>mbakke, is that nice graph from Zabbix?
<mbakke>cbaines: yes
<cbaines>Cool :) Perhaps I should try it out
<mbakke>it's pretty decent :-) though creating such screens and graphs requires a lot of clicking around in the not-so-intuitive web interface
<pkill9_>hello guix
<mbakke>'evening pkill9_
<mroh>hello pkill9_
<nckx>I think Zabbix is currently the best-integrated monitor in Guix.
<nckx>Hi pkill9_.
<nckx>You need to create the DB by hand though.
<guix-vits>/o\ -- BY HAND!? (hi pkill9_)
<cbaines>If you have thoughts on Cuirass database stuff, I'm going to take another look at and if I can't find anything I've broken, I'll merge it within the next few days
<pkill9>can anyone see why freeorion fails to build?
<mbakke>cbaines: awesome :) I don't know much about Cuirass, but the main issue on Berlin now is the Guix DB lock actually
<mbakke>pkill9: "CMakeFiles/freeoriond.dir/build.make:313: *** target pattern contains no '%'. Stop."
<mbakke>maybe a parallel-build issue, or incompatibility with Make 4.3 (since core-updates was merged)
<cbaines>mbakke, yeah, I know the guix-daemon uses SQLite, but I don't really know more than that
<cbaines>I wonder if it's actually busy writing to the database, or something else slow is happening while the database lock is being held...
<cbaines>If the storage is faster on the "new" machine I hear about, that might help
<mbakke>cbaines: I think it's the latter, the system is mostly idle while dozens of builds are waiting for the lock
<mbakke>looking forward to trying reepca's patches from
<NieDzejkob>How can I reference a package for a different system with a gexp?
<NieDzejkob>(I want to put glibc for i686-linux at /lib)
<NieDzejkob>hmm, looks like I want to ungexp an expression that sets %current-system with with-parameters
<pkill9>i think gexps have an optional argument for #:system
<pkill9>also I think that's a package argument
<apteryx>I'm trying to debug something with GDB, and it won't break, even though I'm sure I'm at the right place (it's the only place where such output is printed). Ideas?
<NieDzejkob>apteryx: What optimisation level are you using for your program?
<NieDzejkob>(we're talking about a C program?)
<apteryx>the app spaws a couple threads, perhaps I need to activate some option??
<apteryx>yeah, GNU Anubis (C)
<apteryx>let me check for the optimization
<apteryx>it's using -O2
<NieDzejkob>hmm, the optimization might be screwing you over. Try -Og or -O0
<apteryx>rebuilding after ./configure ... CFLAGS='-O0 -g'
<apteryx>hmm, still won't break
<NieDzejkob>I'm not sure that's how you pass flags to configure
<NieDzejkob>try passing the CFLAGS to make too
<apteryx>it works, I saw the make lines with -O0 -g
<apteryx>instead of -O2
<NieDzejkob>hmm, OK
<NieDzejkob>idk, maybe paste your debugging session somewhere and I'll take a look
<apteryx>OK, first here's a patch that adds GNU Anubis
<apteryx>if you prefer I can mail it to guix-patches
<apteryx>NieDzejkob: OK, didn't want it, so here it is:
<apteryx>this is what my current debug session looks like
<apteryx>I'm trying to troubleshoot Anubis seemingly having issues with establishing the TLS tunnel with the SMTP server
<apteryx>it seems when Anubis is about te reply EHLO on the newly encrypted tunnel, the connection was already closed by the remote, and it prints 'Could not write to socket: Resource temporarily unavailable, try again.'
<apteryx>that'd be tunnel.c:658
<mbakke>uff, magit-blame on crates-io.scm seems to have sent emacs into an infinite loop
<apteryx>I usually use C-x v l g instead of magit-blame... dunno if that's faster (it's an Emacs built-in)
<apteryx>C-x v g pardon
<apteryx>then you have neat shortcuts like 'a' to access the ancestor commit of a given line
<mbakke>hm, will try it, once I have restarted
<mbakke>it has been spinning for a couple of minutes now, I guess it won't give up any time soon :P
<mbakke>RIP buffers
<apteryx>is this a regression? or was it always this slow?
<apteryx>I recently updated Magit.
<mbakke>I haven't updated yet, maybe the new version fares better
<apteryx>I just reproduced here... so I guess not
<apteryx>using magit-blame then 'm'
<apteryx>ah, it finally finished
<mbakke>it's pretty slow, but usually returns :P
<mbakke>apteryx: so the 'a' key "checks out" commit~ from where the cursor is?
<apteryx>no, I think it checkouts the commit that modified that line previously
<apteryx>'p' is commit~, IIUC
<apteryx>but I always get confused ;-)
<apteryx>ah, you seem to be correct
<apteryx>'a' would be commit~: Visit the annotation of the revision before the revision at line.
<civodul>/me does C-x v g as well
<apteryx>and 'p' doc says: Visit the annotation of the revision previous to this one.
<apteryx>I guess that explains my confusion ;-)
<apteryx>but 'a' is line-commit^, 'p' HEAD^, IIUC.
<mbakke>well, TIL, I have missed that functionality every once in a while :-)
<apteryx>any smtp server which does TLS that I could easily setup to debug my problems with GNU Anubis?
<apteryx>seems the remote doesn't like the TLS exchange, and closes the connection without saying much.
<mbakke>C-x v g is able to "time travel" the repository without touching the files, neat
<mbakke>I have a special "tardis" worktree for going back in time, to avoid touching all the files in my regular worktrees :P
<civodul>yeah C-x v g doesn't touch anything
<civodul>f jumps to the file at the given revision
<civodul>very handy!
<calher>Which program is this?
<calher>I had a dream about looking through someone's bookshelf and finding a calendar with both my ex's and my birthday marked on a calendar, right next to each other.
<calher>Wrong buffer, even.
<rekado>nckx: there’s only zabbix monitoring. But since nobody uses it, the notifications bot is disabled, and nobody really wants to configure zabbix to be more useful to us there’s effectively no monitoring.
<rekado>the MDC sysadmins (Madalin and I) get notifications when there are hardware errors, though, and we take care of clearing them and rebooting the machines when necessary.
<rekado>but I know that the nodes are pretty idle most of the time
<rekado>whenever I had to touch them for firmware upgrades I could pretty much always just go ahead because no builds were running
<rekado>it’s pretty frustrating
<rekado>good hardware bores itself to death
<rekado>nodes 101, 102, and 103 are new
<rekado>and a few others had memory errors so they were disconnected
<rekado>but overall a low load average sounds correct
<civodul>rekado: reepca has proposed patches that should reduce contention on the daemon database
<civodul>i hope that'll work as we hope!
<civodul>i agree it's terrible to have all this hardware underused
<civodul>we can also experiment with the coordinator on some of the nodes
<rekado>I’ll need some hand-holding to set up things. I can’t really follow the developments, so please just notify me when I should do something to set things up.
<bricewge>In a package definition, is there a way to only get the output hash or should get it from the out path?
<bricewge>When using git-fetch, how can I access the '.git' directory? I want to get the date of the last commit.
<mbakke>bricewge: the .git directory is stripped to save space
<mbakke>what do you mean by only getting the output hash?
<bricewge>I'm mean the hash part (...) of '/gnu/store/...-ipxe'
<pkill9>i'm guessing /gnu/store/<output hash>-package
<bricewge>pkill9: Yes
<mbakke>right, I don't think so
<bricewge>mbakke: I saw it was missing, is it possible to get the date of the last commit from the repo in origin
<cbaines>civodul, I was looking at those SQlite related changes earlier, but I wasn't aware there was interaction with the store database from Guile code?
<bricewge>I'm asking all of that to make IPXE reproducible
<mbakke>heh :-)
<mbakke>you'll have to hard code any metadata such as commit date in the package definition
<mbakke>I'd probably choose 1970-01-01 to make it obvious :P
<bricewge>mbakke: It need BUILD_TIMESTAMP to be an actual date because
<bricewge>That would be too easy ;)
<civodul>cbaines: it's used by 'guix offload' and by things like "guix pack --localstatedir" or "guix system disk-image"
<civodul>and of course the daemon reepca is working on
<cbaines>ah, right, I guess guix offload is applicable to berlin
<nckx>rekado: I was shocked by just how low. Poor lonely machines.
<mbakke>bricewge: oh, I see. Probably best to add a let binding close to the version with the commit date so that people remember to bump it
<nckx>bricewge: Git commits are more likely than not in chronological order, which would lead to unexpected results. You could create your own monotonically increasing timestamp.
<nckx>*not not? Not not.
<mbakke>bricewge: for the hash, you can subtract (getenv "NIX_STORE") from (assoc-ref outputs "out"), and cut off after 32 characters
<bricewge>nckx: Right, CommitDate should be in a chronological order unless manually specified, no?
<bricewge>WDYM by “monotonically increasing timestamp”?
<nckx>Treating your revision as seconds from the epoch or something. Something guaranteed to be ‘newer’.
<mbakke>the CommitDate from git log --format=fuller will generally be safe though
<bricewge>nckx: Hum, I see. But then someone that was previously using ipxe from say upstream, won't use our ipxe since it will always be older that them
<nckx>It's broken naive scripts of mine before because time zones are hard for people but sure.
<nckx>bricewge: I took your link to mean ‘these dates can influence behaviour and need to be accurate’, and in theory they can be bogus, but if they're good enough for you they're good enough for you.
<bricewge>mbakke: I'm thinking that even getting the git commitdate won't work if we add patch that 'substitute*' for example
<bricewge>Does that package has to be reproducible?
<bricewge>Or should I wait that upstream and Debian find a way to make it reproducible?
<bricewge>ATM I still need to fix 2 timestamp in an .iso for it to be reprducible.
<bricewge>But I have hard-coded "BUILD_ID_CMD" and "BUILD_ID_TIMESTAMP" which seems really dirty in the context of this package...
*civodul prepares to push automatic pager invocation for 'guix search'
<janneke>night-time greetings, Guix!
<civodul>i found the magic 'less' options to do the right thing
<nckx>Just out of curiosity I checked the guix repository and there's a commit that was commitDated before its parent in the last 150 commits. Don't rely on it. But it's fine as a hint.
<bricewge>nckx: Thanks, some committer had a lagging RTC?
<nckx>That's my guess.
*mbakke wonders if cuirass will ever succeed:
<nckx>bricewge: This is just me playing around of course. But it's happened 58 times in Guix, so it's not that far-fetched. I'm sure it's fine to break ties in a menu 🙂
<bricewge>nckx: Ok, but I don't know how to access the ',git' directory from inside a package derivation
<nckx>bricewge: Guix doesn't keep it.
<nckx>It also resets all timestamps.
<bricewge>I'll fallback on mbakke suggestion to use a 'let' and a comment to ask contributer to bump the timestamp each time they touch the
<civodul>hmm looks like sv.git doesn't quite answer
<civodul> is 502
<civodul>mbakke: this is worrying indeed
<cbaines>I wonder if the recent guix-master evaluation failures on are related to some state on that machine, as bayfront seems to be unaffected
<civodul>yes, it's almost certainly because of contention on the store database
<civodul>"database is locked"
<civodul>it's been happening a lot since recent reconfigures
<civodul>though i'm not sure exactly where that comes from
<mbakke>wow, civodul wasn't joking with cool-hacks-mode :-)
<janneke>yeah, "someone" keeps resetting master