<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. <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 <nckx>I think I have a better fix for this but there are 2 things higher on my TODO list. <nckx>Hello PotentialUser-83. I don't think running the TUI installer over serial ports is supported, or at least tested. <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 🙂 <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. <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 <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 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. <ngz>You're welcome, I guess. <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. <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 😉 <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. <wdkrnls>Is there an autofs-service somewhere? <Kozo>nckx: That worked. Thank you very much :-D <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? <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>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: https://paste.debian.net/plain/1150493 <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. ***dingenskirchen1 is now known as dingenskirchen
<wdkrnls>nckx: I'm curious why you had the reaction about autofs? <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? <roptat>is that guix 1.1.0, or a custom installation image? <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>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 <roptat>sorry, guix gc -D /gnu/store/hash-ghostript-9.27.drv then try 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>Nios34[m], agreed, you shouldn't have to do that <roptat>"guix gc" with no argument maybe? <roptat>it should have been my first reflex, but hey, I'm getting tired :D <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 <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>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? <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. <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 😉 <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>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>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>almost done rewriting activation and reordering etc-service <nckx>mbakke: Unless you're merging something that will ungraft gnutls? <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 <mbakke>I suppose packages do not link the full libgnutls.so.30.26.2 ? <mbakke>from a random sample, it seems they use libgnutls.so.30 <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 <janneke>civodul: i think i succeeded in slightly parameterizing etc-services for usage on the hurd <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>janneke: oh, should i push those (gnu system vm) changes? <janneke>i verified yesterday that wip-hurd-vm does not depend on those...but still <civodul>it did seem to help when targeting arm <civodul>but perhaps it didn't expose all the issues you encountered <janneke>or arm more forgiving if you build an extra kernel for the wrong arch *janneke does not remember the details <janneke>civodul: crap: we need /etc/login for the hurd <cbaines>PotentialUser-79, Hmm, I think I remember there being a problem with this <cbaines>PotentialUser-79, does /run/current-system/configuration.scm exist? <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 <PotentialUser-79>also, how would do the same as `nixos-rebuild switch --upgrade` in guix? <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 <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>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 :/ <cbaines>guix system search ... also allows searching for services <rekado>cbaines: can’t wait to switch ci.guix.gnu.org 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 <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>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 <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 <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 <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>I honestly hope I made a type somewhere but I'll need convincing. <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>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 <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>it's pretty decent :-) though creating such screens and graphs requires a lot of clicking around in the not-so-intuitive web interface <nckx>I think Zabbix is currently the best-integrated monitor in Guix. <nckx>You need to create the DB by hand though. <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 <NieDzejkob>How can I reference a package for a different system with a gexp? <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? <apteryx>the app spaws a couple threads, perhaps I need to activate some option?? <NieDzejkob>hmm, the optimization might be screwing you over. Try -Og or -O0 <apteryx>rebuilding after ./configure ... CFLAGS='-O0 -g' <NieDzejkob>I'm not sure that's how you pass flags to configure <apteryx>it works, I saw the make lines with -O0 -g <NieDzejkob>idk, maybe paste your debugging session somewhere and I'll take a look <apteryx>if you prefer I can mail it to guix-patches <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.' <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>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 <apteryx>is this a regression? or was it always this slow? <mbakke>I haven't updated yet, maybe the new version fares better <apteryx>I just reproduced here... so I guess not <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>'a' would be commit~: Visit the annotation of the revision before the revision at line. <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>f jumps to the file at the given revision <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. <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>good hardware bores itself to death <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 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>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>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 <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. <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' <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>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>yes, it's almost certainly because of contention on the store database <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 
