IRC channel logs

2020-03-06.log

back to list of logs

<jboy>nckx: I can continue my packaging adventure tomorrow
<nly>hi
<sneek>Welcome back nly, you have 2 messages.
<sneek>nly, str1ngs says: you probably want to use webkit_web_context_set_network_proxy_settings with the default context which you can get with webkit_web_context_get_default. see https://webkitgtk.org/reference/webkit2gtk/stable/WebKitWebContext.html. This will set the proxy for all GtkWebView's .
<sneek>nly, str1ngs says: try setting this in startup-hook for now.
<nly>thanks str1ngs
<nly>sneek later tell str1ngs thanks
<sneek>Okay.
<nly>sneek later tell str1ngs, i need this variable 'WEBKIT_NETWORK_PROXY_MODE': https://webkitgtk.org/reference/webkit2gtk/stable/WebKitWebContext.html#WebKitNetworkProxyMode
<sneek>Got it.
<drakonis>is it doable to append an arbitrary grub record?
<drakonis>append an arbitrary string to the grub cfg after grub records without having to rewrite the function that generates the grub cfg?
<atw`>what's the ettiquette around adding a python-… and a python2-… package? should it always be done, or should it be done under certain conditions?
<bandali>according to http://guix.gnu.org/manual/en/html_node/Python-Modules.html:
<bandali>> Some modules are compatible with only one version of Python, others with both. If the package Foo compiles only with Python 3, we name it python-foo; if it compiles only with Python 2, we name it python2-foo. If it is compatible with both versions, we create two packages with the corresponding names.
<bandali>> If a project already contains the word python, we drop this; for instance, the module python-dateutil is packaged under the names python-dateutil and python2-dateutil. If the project name starts with py (e.g. pytz), we keep it and prefix it as described above.
<Blackbeard`>hello everyone :)
<Blackbeard`>I am trying to add service qemu-binfmt-service-type to my config.scm
<Blackbeard`>as instructed here
<Blackbeard`> https://guix.gnu.org/manual/en/html_node/Submitting-Patches.html#Submitting-Patches
<Blackbeard`>ohh never mind, I made a typo
<jackhill>It appears to me that "spinners" (i.e. what's displayed while whating on things like gimp to open or the lock screen to determine I entered the wrong password) as not as smoothe as they used to be and flicker
<jackhill>spinners in gnome that is. Have others observed this?
<jackhill>I wonder if I have an older generation that doesn't have this problem
<Blackbeard>jackhill: what other examples do you have beyond gimp or krita?
<Blackbeard>Ah I think libreoffice has one too right?
<jackhill>Blackbeard: what I'm describing is not the gimp spinner per say, but the spinner in the gnome top bar while gimp is loading and displaying its splash screen
<jackhill>it is a difficult thing to screenshot
<lfam>What hardware are you using jackhill?
<drakonis>nckx: update rclone to 1.51 will ya
<drakonis>or anyone else.
<drakonis>should be just bumping it to 1.51
<jackhill>lfam: I am currently on a macbook 12,1, but I think I saw it at least once on my desktop at work today, which is a fairly new intel processor both with intel graphics
<jackhill>the macbook is a i5-5257U and the desktop a i7-8700
<Blackbeard>jackhill: ohh sorry I missunderstand. I can't help you then :/ I don't use Gnome
<navik>if I'm updating the bootloader configuration in `/etc/config.scm`; is there a way to only reconfigure the bootloader, or do I have to issue the full `guix system reconfigure`?
<navik>hm, half an hour ago, this config worked - but now my keyboard does not work whilst in GRUB upon reboot.
<navik>ah, mouse does not work either.
<navik>It's not exactly the behaviour one would expect, from changing the GRUB menu-entry device definition for another OS. Or perhaps GUIX got jealous and is proving a point.
<navik>anyway - it's very hard to incrementally improve system configuration if everything has to be reconfigured in tandem.
<navik>The GRUB issues might be due to my own copying configs back and forth between different boot-partitions. But the mouse issue is a bit strange, could be that it gotten disabled by me pressing some special buttons on keyboard. A lot of different potential errorsources.
<navik>I must be using the `guix` invocation in some strange way - I don't get it why it need downloading so much every time I issue it - is the updating so fervent?
<rekado>navik: reconfiguring the system should be pretty fast when not much has changed. It should not download anything when you haven’t changed any of the packages.
<navik>rekado: yep, that was my expectation; but now when I reverted to an older configuration, it did reconfigure so that I could scroll around in GRUB - it turns out I've installed linux-libre 5.1.2 yesterday, then 5.1.2 again today, followed by 5.0.10 two times, and then 5.0.9 one time. Now it's at 5.4.23
<navik>so, conclusion is; I don't know what I'm doing.
<navik>`guix pull; guix reconfigure system /etc/config.scm` did that, when I slightly changed the menu-entries in the bootloader config each time.
<navik>At least, both keyboard and mouse works again.
<rekado>wait, are you running this as different users?
<rekado>what user runs “guix pull”? And what user runs “guix system reconfigure”?
<navik>no, I hope not; I've been consequently doing a su - and then a guix pull and reconfigure
<navik>perhaps there's some magic going on that makes a `su -` not be enough?
<rekado>the only explanation I have is that you’re using different guixes
<navik>hm. Yes I do, since I reboot each time to check how the bootconfig worked
<navik>if I had chosen the same config to boot, I guess I wouldn't have had the same issues?
<navik>that actually makes sense, if the downloads are stored in the booted system version?
<navik>But for a newbie at this system, it's a bit confusing :)
<rekado>I don’t see how you would have gotten older kernels unless you either 1) selected an older kernel in the config or 2) used an older Guix.
<rekado>all downloaded items are stored in /gnu/store
<rekado>nothing is redownloaded.
<rekado>(until you free up space with “guix gc”)
<rekado>woo, 15T free space on ci.guix.gnu.org
<NieDzejkob>navik: Make sure you don't have `guix' in any profile. "type guix" should show ~/.config/guix/current/bin/guix
<efraim>Also if you don't run 'guix pull' between reconfigures then it will effectively only download/build the differences
<efraim>I only run 'guix pull' weekly and use that all week when reconfiguring
<DamienCassou>hi
***apteryx is now known as Guest3073
***apteryx_ is now known as apteryx
<DamienCassou>beyond efraim, is anyone sharing his/her Guix configuration(s)? It's good for learning
<rekado>DamienCassou: we share the configuration of the build farm in the maintenance repository
<rekado>DamienCassou: https://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/hydra
<DamienCassou>I'm more looking for desktop configurations for now. But thank you anyway, I will have a look
<DamienCassou>I keep getting this error today:
<DamienCassou>Throw to key `encoding-error' with args `("scm_to_stringn" "cannot convert wide string to output locale" 84 #f #f)'.
<DamienCassou>substitution of /gnu/store/zfi66vny0h10d180xajgm4pq2vnvmc2z-nss-certs-3.49.1 failed
<guix-vits>Hi Guix.
<nckx>sneek later tell drakonis Do it yourself: rclone@1.51's been available for a month. :-/ Pull once in a while, will ya.
<sneek>Okay.
<nckx>guix-vits: Good morning!
<nckx>rekado: Eh, ‘xargs -a file’, but in general cat's useless when you can ‘< file’. Thanks for finding a solution. Guix could sort gc candidates by size by default, although that oppositely affects people running it to free inodes (yes, they still exist).
<nckx>DamienCassou: nss-certs happens to double as an UTF-8 file name test suite, and can only be correctly unpacked & built if your daemon has the right locale available. This isn't on Guix System, right?
<DamienCassou>I'm still on Fedora (5 weeks left)
<nckx>Thought so.
<DamienCassou>it seems the --fallback option made it pass
<DamienCassou>bonjour civodul
<civodul>Hello Guix!
<sneek>Welcome back civodul, you have 2 messages.
<sneek>civodul, drakonis says: is there any particular reason the daemon rewrite proposal hasnt returned for gsoc 2020?
<sneek>civodul, nckx says: https://sv.gnu.org/people/viewgpg.php?user_id=15145 has expired.
<nckx>DamienCassou: You should make sure the profile from which your guix-daemon is taken is kept up to date. If it's your root profile it means making sure root's glibc-{utf8-,}locales packages are up to date.
<DamienCassou>`sudo guix pull`?
<nckx>DamienCassou: Foreign distributions are not my strong suit. Where does your guix-daemon.service get its daemon?
<DamienCassou>I envy you :-)
<DamienCassou>`ExecStart=/var/guix/profiles/per-user/root/current-guix/bin/guix-daemon --build-users-group=guixbuild`
<nckx>Then there's the fact that different distributions configure their sudo differently, so I'd use ‘sudo -i’ explicitly just to be safe. (Guix System defaults to ‘sudo -E’, others ‘sudo -i’, messy.)
<rekado>civodul: welcome back!
<nckx>DamienCassou: OK, ‘sudo -i guix pull’ on its own will update that profile and run a newer guix-daemon next time you start it.
<rekado>civodul: today there’s going to be a (hopefully) short outage as we move the server and storage array behind ci.guix.gnu.org to a different rack.
<nckx>& hopefully keep this problem from reoccurring.
<rekado>in the meantime I’ve prepared hydra-guix-129 to host the websites and serve the guix publish cache.
<nckx>DamienCassou: If you were planning on keeping your installation I'd say run this once a month or so.
<DamienCassou>nckx: my new computer will only contain Guix System if I can manage to install everything I need
<nckx>That's the trade-off. I hope so.
<bojan_petrovic>Hi, i tried to build python with armhf-linux-gnu, and got this error: https://paste.debian.net/1133689
<bojan_petrovic>Should I file a bug report?
<civodul>rekado: oh good, thanks for the update!
<civodul>so hydra-guix-129 will temporarily use the IP of ci.guix?
<civodul>bojan_petrovic: yes please; also include the output of "guix describe"
<nckx>bojan_petrovic: Weird. That means the value of libc is false :-/
<rekado>civodul: yes.
<rekado>I copied the certs and the cache, then updated the configuration to add the static web site services and to serve all that nginx stuff.
<rekado>I hope this will make a difference.
<civodul>cool, thanks for doing it
<nckx>civodul: Does %build-inputs contain more (implicit) inputs than the ‘inputs’ lambda* keyword?
<civodul>nckx: no, it's the same
<nckx>I don't understand why (assoc-ref %build-inputs "libc") in arguments works but (assoc-ref inputs "libc") later in a phase returns #f.
<nckx>Is one extra thunky
<nckx>bojan_petrovic: Go ahead & file a bug, I guess. Please include the command you used.
<civodul>nckx: weird, dunno
*janneke just built hello on the hurd
*guix-vits
<rekado>janneke: oh! Last time I played with Guix on the Hurd I noticed that the Guix-built tar segfaulted. Did you work around that?
<janneke>rekado: no, i didn't
<bojan_petrovic>thanks
<janneke>i built on efraim's recent wip-hurd-bootstrap branch and have some 20 odd patches ther
<DamienCassou>I'm trying to have /gnu/store be a bind mount to a directory in my home folder
<DamienCassou>Blackbeard: ^
<rekado>my TODO also says that “we should try to use Guile 2.0 instead of 2.2”
<rekado>janneke: neat.
<rekado>I’d love to set up a few Hurd build nodes on ci.guix.gnu.org
<janneke>rekado: i did find that make-4.3 does not work and reverted to 4.1 for the hurd for now
<janneke>rekado: oohhh, neat!
<janneke>i'll send a mail today to guix-devel; my branch lives at my gitlab wip-hurd-bootstrap
<rekado>I’m looking forward to seeing this merged. For me the biggest obstacle to hacking on the Hurd is a lack of Guix.
<janneke>the ugliest i did was to run `make dist' on gnumach and on the hurd and build from those tarballs
<rekado>I just can’t make myself work in a stateful environment.
<janneke>rekado: yes, me too!
<Gooberpatrol66>janneke: nice
<janneke>rekado: re guile-2.0; i have a patch set that reverts to guile-2.0 for hurd but am not using that right now
<janneke>if you think that's the way to go, i'll look at merging them too
<DamienCassou>Blackbeard: mounting a directory to /gnu/store seems to work
<DamienCassou>the daemon doesn't complain
<rekado>janneke: using Guile 2.0 was just a guess. I thought that maybe the miscompilation of tar was somehow related to using a different version of Guile compared to the other architectures.
<guix-vits>nckx: Funny, the ext4 has fixed number of inodes, probably because it's simpler than X. btrfs just ++inode's number, as "The inode number limit on 64bit system is 2⁶⁴, which is practically enough for the whole filesystem lifetime."
<nckx>:)
<slyfox>yeah, operation speeds on ext4/btrfs on those inodes differ quite a bit though
*kmicu is happy to see inodes issue is finally hitting guix 😺
<nckx>btrfs (and other treefses like bcachefs) just emulate inodes because, in glorious Unix fashion, an implementation details was made API. ‘How can we tell if this is the same file?’ ‘Oh, I know.’ Now we're stuck tracking the world's most unreliable tiny UUID for eternity.
<kmicu>slyfox: where ‘quite a bit’ is approximated in what numbers?
<janneke>rekado: ah, yes -- then let's wait going to 2.0 maybe until the need arises
<janneke>i found some powerpc discussion that suggested going guile-2.0; i tried many things to "get things going"
<kmicu>(the inode issue showing up means some ‘conservative’ folks start using Guix for real)
<rekado>oddly enough I haven’t hit any inodes problem on ci.guix.gnu.org
<rekado>the store there reached 37T at its worst
<nckx>kmicu: What do y'all *do* to hit inode limits with Guix? I'm at 3% IUse for /, total.
<nckx>(50G store, 400G ext4 /)
<kmicu>Turn off links optimisation, use ext* filesystem, garbage collect twice a year.
<nckx>Ah, the hard links.
<kmicu>Is deduplication enabled by default?
<nckx>On Guix System at least.
<nckx>kmicu: You need to manually disable it with --disable-deduplication.
<nckx>I wonder how many people do this because ‘it's sloow’, then run out of 'nodes. Hopefully, 0.
<kmicu>(It wasn’t on NixOS in the past (and maybe today too). #defaultsMatter (for ext4 users) 🤭)
<nckx>Yes.
<kmicu>(Still off https://nixos.org/nixos/manual/options.html#opt-nix.autoOptimiseStore Nix gotta go fast, like Intel’s out‑of‑order execution.)
<nckx>They should autoOptimise the 8 MiB HTML file I just downloaded to read that o_O
*kmicu *coughs* guix.html has 2.1MiB
<nckx>But think of the inode savings compared to html_node/.
<kmicu>For me that shows how much work folks put into those projects. Make those manuals 20MB or even 200MB—no complaints here only gratitude.
*civodul never hit an inode limit
*nckx never even came halfway close.
<guix-vits>ascii art: https://paste.debian.net/1133700
<nckx>jboy: Updating python-pygit2 to 1.1.0 fixes its build. Then… building gitless fails because it insists on python-pygit2 0.28.2 😒
<civodul>Cuirass on berlin leaks file descriptors these days, something must have gone wrong
*guix-vits not my ascii art, btw
<nckx>guix-vits: Random, also cute.
<efraim>I'll catch up on backlog later, but I found guile2.0 easier for powerpc, I think dftxbs3e made it work with guile2.2
<rekado>kmicu: we could probably make the manuals bigger by embedding base64-encoded images.
<alextee[m]>why does meson use python-2 in guix o.o
<alextee[m]>oh sorry was reading the package above it
<rekado>hmm, guix system reconfigure doesn’t terminate on hydra-guix-129
<NieDzejkob>how can you know?
<rekado>it’s stuck in the activation phase.
<rekado>i.e. it has built everything already.
<rekado>the problem seems to be the switch from Guile 2 to 3.
<rekado>there are warnings about incompatible modules that cannot be loaded
<rekado>ah, I think I found the culprit…
<rekado>when the new system is activated /etc is populated. This overrides /etc/hosts, which had an extra entry for ci.guix.gnu.org (because that server can only access ci.guix.gnu.org via the internal IP).
<rekado>since the connection to ci.guix.gnu.org times out eventually nothing happens until it does.
<rekado>so I’ll have to override the hosts-file field in the configuration and all should be good
<nckx>Tsk. State.
<zzappie>Hi Guix!
***janneke_ is now known as janneke
<mbakke>hello zzappie
<iyzsong>Hello :)
<mbakke>nckx: whoops, didn't see you were working on pygit2 as well
<nckx>mbakke: No prob.
<mbakke>rekado: why do the build server need to access ci.guix.gnu.org ?
<mbakke>hmm Cuirass seems unable to fetch new commits
<mbakke>from the log:
<mbakke>2020-03-06T13:34:40 Git error while fetching inputs of 'staging-staging': "target OID for the reference doesn't exist on the repository"
<jboy>nckx: oy vey.
<nckx>jboy: I got further (sorry, couldn't help myself, this package sounds ‘interesting’) and am now successfully failing to run tests.
<jboy>nckx: what did you do? patch gitless to accept a different version of pygit2?
<nckx>mbakke update pygit2 on master so I've forced gitless to accept it.
<nckx>Ayup.
<nckx>Don't know if that works yet.
<nckx>The WIP: https://paste.debian.net/plain/1133736
<nckx>…which is still running its tests 🤞
<jboy>The nix package just skips the tests: https://github.com/NixOS/nixpkgs/blob/7d31bbceaa12ad56779c3c55a9062fa7fb687c4a/pkgs/applications/version-management/gitless/default.nix#L20
<mbakke>jboy: but how do they notice incompatible versions of things? :-)
<nckx>jboy: Nix is a great example (so is Arch/AUR, Debian for copyrights, etc.) but they do some things I/we disapprove of 😉 As mbakke notes, the package may well totally fail with pygit2 1.1.0 (or for some other reason). It's good not to make users find that out at run time if possible.
<nckx>Tests pass and /gnu/store/638371gwxjfp7d3akiibdqys3dxyfbjy-gitless-0.8.8/bin/gl produces a help message \o/
<nckx>I presume you can handle it from here.
<jboy>whoa nice! thanks for the packaging lesson.
<nckx>jboy: My plej. I noticed that I pasted an older version above, here's what I actually ended up with (cleaned up some more, moved some things around, and now is a diff to version-control.scm): https://paste.debian.net/plain/1133748 . It still needs a description (at least a few lines, but don't write for length) and real-world testing of course.
<nckx>Thanks for working on it. 🙂
<nckx>I've inited, commited a file and viewed history, all with gl. I don't see the point but it was fun.
<nckx>mbakke: I'm trying to get carla to run. After fixing https://debbugs.gnu.org/cgi/bugreport.cgi?bug=39942 I get ‘ModuleNotFoundError: No module named 'PyQt5'’. The package does no wrapping AFAIC. How is it intended to be run?
<civodul>mbakke: isn't it a side effect of the FD leak?
<civodul>(the cuirass issue)
<mbakke>nckx: I wouldn't know, did not test it during review :-/
<mbakke>civodul: probably, seems fine now
<nckx>Eheh.
<nckx>alextee[m]: ☝ Question for you then.
<mbakke>mercurial fails on core-updates, and the latest version does not help even though it supposedly contains python 3.8 fixes
<alextee[m]>nckx: i think it needs some propagated inputs for python stuff
<nckx>I know. But why aren't they propagated or (better) wrapped?
<alextee[m]>that package is generally problematic for me too, i'm trying to build its release candidate but that doesnt work well either
<nckx>Okido.
<nckx>I'll give wrap-script a try.
<rekado>I’m going to shut off ci.guix.gnu.org soon.
<rekado>not sure if the replacement is going to work
<rekado>the firewall here is my biggest enemy.
<rekado>(it’s incredibly annoying to have this outside of our control)
<civodul>heh
<civodul>good luck, crossing fingers! :-)
<rekado>my apologies in advance for causing confusion and annoyance
<civodul>heh, no worries
<mbakke>rekado: the build servers should have (use-substitutes? #f), then they won't need access to ci.guix.gnu.org
<mbakke>also, good luck :-)
<nckx>🤞!
<rekado>mbakke: the build servers have (use-substitutes? #f), but in order to set up that replacement head I enabled substitutes on this one node.
<mbakke>rekado: oh, OK
<alextee[m]>hmm, add-after 'install starts in the "build" directory?
<alextee[m]>that's what (invoke "pwd") says
<alextee[m]>so in the package if i want to install something from the source dir i should do '../source/<filepath>'?
<alextee[m]>(trying to install a bash completion script from the sources in out "/etc/bash_completion.d/")
<nckx>alextee[m]: You can use (with-directory-excursion "../source"). Hard coding it like that doesn't feel great, but it's unlikely to change.
<nckx>alextee[m]: I'd first look into why the package's own ‘install’ target doesn't install it though.
<alextee[m]>nckx: it's my software, i did include it in my install script, but i dont know how to do it properly
<alextee[m]>it uses meson, and it needs a DESTDIR to install in out /etc/...
<rekado>hmm, looks like I made a mistake in setting up the websites…
<alextee[m]>but if I add a DESTDIR, then the prefix is added in the out dir like out /gnu/usr....
<rekado>oops.
<rekado>the servers have been moved, now we’re applying firmware upgrades.
<nckx>Yeah, DESTDIR is ‘usually not what you want’.
<NinjaTrappeur> https://guix.gnu.org/ 404 on my current connection
<janneke>oh, we're gone!
<NinjaTrappeur>Am I the only one experiencing the issue?
<rekado>NinjaTrappeur: yes, sorry
<nckx>alextee[m]: Does Meson have a concept of --sysconfdir?
<NinjaTrappeur>no prob :)
<rekado>NinjaTrappeur: I’m moving the server right now.
<rekado>should be back in ~1h
<rekado>(if all goes well)
<anadon>Good morning all
<nckx>o/
<alextee[m]>nckx: yes, i found it in the configurations
<NinjaTrappeur>ack
<alextee[m]>nice, so i pass out /etc to that
<anadon>nckx: The process tests when building appear to hang.
<nckx>anadon: What're we talking about?
<anadon> I made the changes that I think will fix building singularity images on more systems, but when trying to build to use those changes when following the build guide in the manual the testing hangs on the process test group.
<nckx>Ah. Hm. You're building on CentOS IIRC?
<anadon>Correct
<nckx>Just skip the test suite for now.
<anadon>Using linux 3.10.0-1062.12.1.el7.x86_64
<alextee[m]>nckx: should guix do this for meson-build-system automatically?
<alextee[m]>i mean passing --sysconfdir
<nckx>alextee[m]: That's what I would expect so I'm a bit sceptical about all this. But I don't know Meson better than you.
<alextee[m]>ah actually maybe it does, i was hardcoding /etc before :-) thanks for the tips
*alextee[m] tries again
<alextee[m]>whee it worked
<nckx>Huzzah.
<rekado>updates for the head node are complete
<rekado>just waiting for the storage array now
<jboy>nckx: I want to teach version control basics to non-technical students and gitless seems like the best option.
<nckx>Interesting. I didn't try anything fancy like rebasing or editing commits.
<rekado>rebooting …
<nckx>jboy: Can one use gl to contribute to existing git projects without anyone noticing (in a bad way)?
<nckx>That would counter any ‘but you're not learning a future skill’ argument.
<rekado>server’s up, storage as well, but no outside connectivity
<jboy>nckx: it's just git underneath, so I think yee
<janneke>hmm...trying to build a hurd-based bare-bones, stripped system with a new qemu-tiny still pulls in alsa, linux-kernel, texlive; having stripped the system; what am i missing?
<nckx>They seem unsure whether to market themselves as ‘we're just porcelain for git’ and ‘we're kinda a new VCS too’. Not that I blame them. Danger in both.
<janneke>linux-vm-loader...hmm
<janneke>hmm, still running expression->derivation-in-linux-vm, apparently
<nckx>alextee[m]: Take a look at 1ab58a3d90cc6b0d15b5557de4cc67fee6636cb3 for how to fix these things without resorting to propagation. And if possible test your packages in a pure environment before submitting them. You must have had python-pyqt installed locally.
<nckx>Although that wouldn't explain the /share/carla/carla failure. Anyway: testing is half the work.
<janneke>hmm, qemu-image runs that
<rekado>I think we’re all back up
<rekado>thanks for your patience!
*rekado sends announcement to the lists
<alextee[m]>nckx: i see, what does wrap-script do? just prepend the variable before calling the binary?
<nckx>alextee[m]: Exactly.
<rekado>alextee[m]: it modifies the script by adding a little Guile script to the top.
<nckx>rekado: That was extremely smooth. Thank you.
<alextee[m]>oh nice
<rekado>the Guile script sets the environment variables and then calls the script again but with the target interpreter.
<rekado>the target interpreter ignores the Guile stuff.
<alextee[m]>sounds pretty useful
<nckx>alextee[m]: https://paste.debian.net/plain/1133761
<nckx>alextee[m]: It is, and yet it was only used once in all of Guix. Now twice as much.
<rekado>this works because we can express Guile code in a way that is considered a comment for other scripting languages.
<rekado>nckx: I think I added another user recently
<rekado>so it’s probably up to a whopping three!
<nckx>‘wrap-program’ does the job acceptably so there's no urgent need to upgrade. However, I think it's just not known. Jakub reminded me of its existence y'day or I would have used wrap-program myself.
<rekado>wrap-program is the only option for binaries.
<nckx>wrap-script is aptly named.
<rekado>wrap-script has the advantage of avoiding the renamed target script (.foo-real)
<rekado>but it pulls in Guile at runtime, which may not be good.
<rekado>I think it’s neat and it was fun to implement.
***jonsger1 is now known as jonsger
<nckx>…the number of youngsters mailing savannah-hackers-public@ thinking it's some sAvAnnAh haxx1ng team…
<bavier>civodul: thanks for the patch review, and the suggestion for testing
<civodul>yw!
<nckx>apteryx: forgot to say: thanks for the btrfs update last night.
<rekado>I wonder if we could offer a snippet for the github crowd to show that their software builds with Guix
<rekado>e.g. with https://shields.io/
<rekado>civodul: we need to restart those SSH tunnels…
<dustyweb>hi hi
<dustyweb>oh, Guix in Debian is much closer than I thought: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=850644
<dustyweb>which I think would help with the "github crowd", too
<dustyweb>"look, you can use this on your existing dev environments, today"
<bavier>a shield would be neat, yes
<bavier>do people use shields for other distros?
<rekado>they use them for Conda.
<rekado>and Bioconda
<rekado>hmm, the GWL website is down and the gwl-web service won’t start.
<janneke>rekado: website is up!
<anadon>nckx: Seriously though, the process builtin test shouldn't be hanging.
<civodul>rekado: gasp, i forgot how i started those tunnels
*rekado reconfigures ci.guix.gnu.org after guix pull
<NieDzejkob>civodul: should've made them as services in the system config :P
<civodul>NieDzejkob: i know, i know :-)
<civodul>i thought it wasn't going to last ;-)
<rekado>broken promises… :(
<rekado>bleh, can’t fix the GWL website now
<rekado>will try again in a few hours
<Blackbeard>Hello everyone :)
<bavier>howdy Blackbeard
<anadon>`man` and `bash-completion` are missing after installing "man-pages" and "bash-completion". What am I missing here?
<Blackbeard>bavier: :D
<bandali>anadon, is your PATH correctly set up, or alternatively, are you sourcing the etc/profile file of your profile?
<anadon>bandali: I'm sourcing '~/.bashrc'
<anadon>at least for the bash-completion. For `man`, I'm trying to use `git --help`.
<Blackbeard>anadon: echo "$MANPATH"
<anadon>Blackbeard: empty
<bandali>anadon, does your bashrc or bash_profile in turn source $HOME/.guix-profile/etc/profile ?
<bandali>(this is done automatically on Guix System)
<Blackbeard>anadon: echo "$PATH"
<anadon>Yes
<bandali>but not on foreign distros
<anadon>Eeks. I need to clean this up.
<Blackbeard>MANPATH should not be empty
<mbakke>anadon: installing 'man-db' will populate MANPATH for the profile
<anadon>Blackbeard mbakke: https://paste.debian.net/1133789/
<mbakke>wowza :)
<Blackbeard>Can you paste your .bashrc and .bash_profiles too anadon ?
<anadon>One moment
<Blackbeard>Seems like some directories are called several times
<anadon> https://paste.debian.net/1133790/
<Blackbeard>anadon: are you on Debian or Guix system?
<anadon>Oh crap. It took the first file I listed, not the updated one. ONE SECOND
<anadon>OK. Had to revoke that token.
<anadon>Blackbeard: CentOS7
<Blackbeard>anadon: if you are on debian you need to add an ' export MANPATH='
<Blackbeard>But let me see if I can find the proper manpath
<Blackbeard>You should probably add infopath too
<Blackbeard>anadon: oh then you do need the export MANPATH
<anadon>With `man-db` installed, it seems to be working now.
<Blackbeard>Ah good then never mind :)
<mbakke>anadon: there is a useful starting point for setting up bash_profile here: https://guix.gnu.org/blog/2019/running-a-guix-xfce-desktop-on-centos-7/
<mbakke>note that without export MANPATH=/usr/share/man somewhere you won't be able to access the host manuals
<Blackbeard>Ahh good resource. It also has the xdg dirs
<anadon>Maybe eventually, but I have enough of a interface for now and I want to focus on getting the "-no-recovery" added for building singularity containers. https://paste.debian.net/1133791/
<anadon>That patch breaks a ton and I'm not sure why.
<nckx>anadon: I was born serious. I agree: the tests shouldn't hang, and a bug report would be much appreciated, but it's more important (to me) that you get a basic working Guix than that the full test suite passes.
<anadon>nckx: I'm starting to mind blank on this.
<anadon>I removed the compression lines so that those stayed the same. It looks like it skipped the pack tests so I'm attempting to rerun those tests via `make check pack`
<anadon>Without those compression changes, it behaves in a much more expected mannar.
<anadon>Found the testing section of the manual. Let me do things the right way here.
<nckx>anadon: Do the tests pass with a vanilla Guix?
<anadon>nckx: Mostly. Not entirely, but they seem to be unrelated to what I'm doing.
<anadon>How do I force the test suite to run the singularity test under tests/pack.scm? That level of granularity is not specified in https://guix.gnu.org/manual/en/guix.html#Running-the-Test-Suite
<nckx>anadon: Silly me perhaps, but I don't see the word ‘singularity’ in that file.
<nckx>I do see one in gnu/tests/singularity.scm, which you can run with ‘make … check-system TESTS="singularity"’.
<nckx>Otherwise you'll have to explain more 🙂
<civodul>rekado: i've restarted the tunnels to sergei/dmitri
<nckx>civodul, rekado: Is there anything I can do to make that tunnel go away? Short of having a static IP.
<nckx>You once mentioned that whitelisting domain names was possible so I don't understand the problem.
<civodul>not sure, it might be that IT at the MDC never got around to updating the white list
<anadon>nckx: It isn't well labelled. In `guix pack --list-formats` it makes note of it.
<nckx>Oh, squashfs, OK.
<anadon>It appears the singularity test is just broken from the start? No changes with or without changes.
<nckx>I don't think there is a way to run only one test in that file (unless civodul corrects me). You can replace ‘store’ with #f in the (unless …) before tests you want to skip, or comment out whole sexps with #; — both equally ugly work-arounds.
<nckx>anadon: I'll run it on a Guix System to rule out any CentOS Magic™.
<anadon>Please do. I keep running into Magic\TM
<anadon>How do you do the ^{TM}?
<NieDzejkob>Probably Compose Key
<nckx>anadon: I have a compose key. Which is (unironic) magic. Compose+T+M = ™. Compose+O+R = ®. You get the idea.
<nckx>Why it's so unloved & obscure I'll never understand.
<nckx>That stupid Fn/other key you never use? Make it a compose key. Thank me in a year.
<anadon>I need this in my life.
<nckx>XKB provides, my brother and/or sister.
<anadon>On the internet, no one knows you're a dog (^w^)
<janneke>nckx: hear, hear
<nckx>(You can then start customising your compositions, e.g. /+\ = λ, and fun ensues.)
<anadon>As I get into lisp, I'm going to need that one in particular a lot more.
<anadon>I hope to have my alternative file standard paper draft ready to send to the mailing list and the GWL mailing lists soon.
<nckx>Unfortunately Guix doesn't accept λs in patches (anymore — I tried), but you can use things like global-prettify-symbols-mode to fake it at home.
<anadon>Because fully transparent and secure distributed file support is great.
<nckx>ANYWAY:
<nckx>FAIL: tests/pack
<anadon>Wheeeee
<nckx>However, test-suite.log says that the squashfs one passed.
<anadon>Magic^{TM}
<nckx>Only self-contained-tarball fails. So your squashfs one failed, too?
<anadon>yes
<anadon>nckx: Could you check the following patch for me? https://paste.debian.net/1133806/
<nckx>self-contained-tarball fails because I disabled legacy 32-bit support in my kernel, so on a normal system all would pass. All is well.
<anadon>Why do tarballs depend on 32bit support?
<nckx>anadon: The bash that the test uses is a 34-bit Intel executable, probably to simplify things.
<nckx>Eh, 32, I haven't gone half-PDP on you.
<anadon>34-bit simplifies thing? Eh?
<nckx>Typo.
<anadon>Noe. Now it is cannon. Requires 34 bit support.
<nckx>anadon: Your average 64-bit kernel can run 32-bit software fine on x86_64, so this avoids having a different test with different hashes on both variants. I guess. That was just a guess. Or it's an oversight, because this won't fail on any ‘distro kernel’.
<nckx>Yah Guix gives your CPU 2 extra bits for speed another little known fact.
<nckx>anadon: I have to go eat now but will test your patch!
<anadon>Eat up!
<leoprikler>34-bit processors are pretty okay, but 69-bit processors will really revolutionize the industry! Why? Because it's 2*34+1.
<anadon>Why stop there? Just jump to 420-bit processors. We'll need the extra bit eventually for something someday. Maybe to have global addressable in the 41st millennium or some nonsense.
<leoprikler>420 bit processors would be so dope.
<anadon>Dope inside^{TM}
<anadon>As Snoop Dog plays in the background.
<leoprikler>Dope™ inside
<alextee[m]>we dont have gcovr ? :/
<NieDzejkob>alextee[m]: not with that attitude ;)
<alextee[m]>hehe, packaging time
<alextee[m]>it's on pypi, this should be a breeze
<mroh>the package "fd" installs "/etc/bash-completion.d/fd" instead of "/etc/bash_completion.d/fd" in gnu/packages/rust-apps.scm:190
<nckx>mroh: Care to send a patch? If you're new, it a good first one.
<mroh>nckx: ok
<nckx>Yay. We're here to help if you need any.
<NieDzejkob>oh, the difference is the - vs _
<nckx>anadon: The typomonster is also to blame for your test failure, I'm afraid (for you ego; might be good news for you). https://paste.debian.net/plain/1133813
<nckx>With this simple change it passes here: https://paste.debian.net/1133814/
<nckx>You should always check test-suite.log.
<nckx>Double-check, of course, if that was what you actually meant to write.
<rekado>this thing here: https://elephly.net/downies/guix-build-farm.jpg
<anadon>nckx: What ego? Also, if it was just a minor type, then great. I think I need to increase the font size on my system.
<anadon>*typo
<jonsger>rekado: amazing! thx you and the whole MDC
<rekado>the thing at the very top is the storage array, next three slots are switches (one mounted on the back of the rack), then comes the head node (known as berlin.guix.gnu.org), followed by a bunch of new servers.
<rekado>we’ve got some problems with three of the nodes; maybe they just need their memory reseated or DIMMs swapped.
<rekado>this always seems to be the case for big deliveries.
<rekado>the node at the very bottom has problems with the disk controller, so we’ll probably have to have the board replaced.
<nckx>rekado: ♥
<civodul>rekado: neat, and impressive!
<civodul>woow
<bavier>cool
<civodul>big thanks rekado & MDC :-)
<rekado>I’m just amazed that this trade worked. We started with discarded hardware and traded it for something new.
<civodul>well done!
<civodul>it's indeed really cool of them/you
<rekado>now I hope that we can make this all obsolete with IPFS and guix publish.
<civodul>ah yes, though this appears to take more time
<rekado>big thanks to my two colleagues Madalin and Dan who helped with the setup, the move, and all those details that I can never be bothered to care about.
<anadon>Once I have guix compiled and it appears to be working, is the the correct and safe thing to do to install it "sudo make install"?
<anadon>I'm having some troubling using the pre-inst-env script to fully test the change on my system and am looking to this as an alternative.
<anadon>What I keep seeing is 'guix pack: error: failed to connect to `/usr/local/var/guix/daemon-socket/socket': No such file or directory' despite running the one-liner in the manual which runs the daemon.
<nckx>anadon: The /usr/local means you didn't run configure with --localstatedir=/var
<Blackbeard>anadon: how did you run it?
<Blackbeard>Did you stop it?
<nckx>there's also --sysconfdir=/etc that needs to be set to find any /etc/guix/acl you might have, but I'm not sure if that's default.
<nckx>It's not an invocation error but a configuration one.
<Blackbeard>anadon: btw does CentOS use SELinux?
<nckx>Blackbeard: Yes.
<nckx>Surprisingly, none of the trouble so far was SELinux-related(!).
<Blackbeard>Ahh then it probably should be set to permissive
<Blackbeard>I haven't managed to make the guix daemon work with fedora
<Blackbeard>Using systemd and SELinux
<apteryx>rekado: pretty slick! Thanks to the MDC and to you :-)
<apteryx>nckx: haven't had time to troubleshoot it yet :-/. Perhaps tonight.
<nckx>Blackbeard: This is just a path issue tho'.
<anadon>nckx: Are you sure it is `--localstatedir-/var`?
<nckx>Did I type -? I meant =.
<anadon>No, I mistyped. It was (and is in terminal) =
<nckx>anadon: /var is 100% correct.
<anadon>guix pack: error: invalid argument: Extraneous argument after `--localstatedir'
<anadon>Coming from `./pre-inst-env guix pack --format=squashfs --localstatedir=/var bash-minimal rseqc`
<nckx>anadon: No, it's a configure option.
<nckx>./configure --sysconfdir=/etc --localstatedir=/var
<nckx>When you built Guix, you ran ./configure.
<nckx>You need to run it with these options and ‘make’ it again.
*jonsger still works heavily on his Guix + Nextcloud setup
<anadon>Nextcloud? As in Nextflow? When I looked into packaging them, it looked like a mess.
<nckx>anadon: As in https://nextcloud.com/
<anadon>nckx: I installed gcrypt stuff already. I'm not sure what this error means: https://paste.debian.net/1133818/
<nckx>a polished home file server (=cloud) solution.
<nckx>anadon: That's a very foreign-distro-looking-error that I can't help you with, sorry.
<nckx>s/file //
<nckx>Boo Telenet.
<anadon>Now no builds or substitutes can be installed in the pre-inst-env.
<bryanhonof>nckx: You talking about me? :P
<nckx>bryanhonof: Possibly!
<nckx>I didn't expect a response.
<NieDzejkob>anadon: run your pre-inst-env stuff in a `guix environment guix'
<nckx>anadon: After running ‘make’? And yes, this ☝
<bryanhonof>nckx: Haha, you from around Belgium (I am no fan either of telenet but I have little choise over the internet provider here)?
<nckx>Run configure, make, and (apparently this is necessary on some distroes) ./pre-inst-env in your ‘guix environment guix […]’.
<anadon>Everything dies on "no code for module (gcrypt hash)"
<nckx>bryanhonof: Yup. And it's true, there's not much of a choice.
<nckx>anadon: :-/
<anadon>This has quite the initiation period.
<nckx>This isn't directly related to the configure option but now I feel bad for breaking your working-somehow-kind-of system.
<anadon>Before guix makes it to prime time, a lot of these edges will probably need to be sanded down.
<NieDzejkob>anadon: could you paste the terminal output starting at `guix environment guix' up to ./pre-inst-env? I feel like there might be some subtle hint there
<nckx>anadon: Ah, did you run the daemon from the same guix environment? (You can ‘guix environment guix […] -- some --command to run --inside it’, you don't always have to spawn a shell.
<nckx>)
<jonsger>anadon: not yet as package or service (Nextcloud)
<NieDzejkob>oh, also `guix describe' maybe?
<anadon>Now guile is missing.
<anadon>What is even happening?
<anadon>Except that I can run it.
<nckx>anadon: Are you currently running a guix-daemon? Which one (exact ‘ps auxwww’ command line if possible). Also, like NieDzejkob said, giving us a good chunk of your terminal log up to this point might help.
<Blackbeard>anadon: did you run the command for linux daemon and stopped it?
<Blackbeard>Or kept it working on the background?
<anadon>Let me reset what I'm working with here.
<anadon>I need to roll back to a defined state.
<dftxbs3e>hey
<dftxbs3e>Blackbeard, so my configuration.. let me find a way to transfer
<bryanhonof>I am extremely sorry to throw my question right in the middle of another one but, I am looking into distro hopping again very soon and guixsd is on my list. Now I know it uses the linux-libre kernel and I have a pretty modern laptop (Thinkpad T495). Will this cause trouble for me or will I just have to build a few drivers myself? I am most worried about the Wi-Fi drivers since I belive the laptop included an intel one.
<dftxbs3e>efraim, janneke: yes I used guile2.2 for powerpc64-linux - https://gitlab.com/lle-bout/guix
<dftxbs3e>right now, guile-emacs seems to hang forever at 'Collecting OKURI-NASI entries', it printed until 70% and then it's been a day or two that it's stuck
<nckx>bryanhonof: I'm not optimistic. Even my ‘old’ x230t came with a non-libre Intel card. Which (Linux kernel) driver did you use with your previous distributions?
<dftxbs3e>Blackbeard, so I can't even see gdm, I see: 'New session c1 of user gdm.' then later 'Remove sessions c1.' then nothing
<lfam>bryanhonof: There are no free drivers for Intel wifi or any recent wifi chips
<lfam>As far as I know there is nobody working on this
<nckx>lfam: Oof.
<bryanhonof>nckx: To be very honest, I have no idea. At the moment I am running Arch with systemd-networkd and iwd. It just kinda worked out of the box t.b.h.
<lfam>I don't think there are any 802.11ac free drivers
<Blackbeard>dftxbs3e: what's your config.scm
<jonsger>dftxbs3e: btw congrats on powerpc64 bootstrap !
<dftxbs3e>lfam, there is free drivers for this: https://tehnoetic.com/adapters/tet-n450db - 450Mbps, that's well enough for me :-)
<dftxbs3e>In practice, I get 200Mbit/s up and down at home :-)
<dftxbs3e>In a librebooted X301
<lfam>dftxbs3e: I haven't been able to find anything faster than that card with free drivers
<dftxbs3e>jonsger, yay! I'm so happy!!
<Blackbeard>bryanhonof: I bought a TP-LINK TL-WN722N first generation to avoid all those problems
<bryanhonof>dftxbs3e: Yeah I have seen that one before, I am a little worried it won´t fit in the laptop tho.
<lfam>However, you can't swap the wifi chips in thinkpads without hacking the BIOS which is a maybe
<nckx>bryanhonof: There's probably a nicer way to do this, but what does ‘readlink /sys/class/net/w*/device/driver/module’ say?
<bryanhonof>nckx: ../../../../module/iwlwifi
<dftxbs3e>bryanhonof, Don't know about the bandwidth of USB but maybe you can find an M.2 USB adapter...? If a 450Mbps WiFi USB adapter doesnt exist
<nckx>Non-free ☹
<Blackbeard>I can even use it to do stuff with airmod-ng
<Blackbeard>And it is really cheap
<lfam>I think this wifi issue is probably the main reason that Guix users would choose a different kernel than linux-libre
<Blackbeard>lfam: yeah :(
<bryanhonof>dftxbs3e: I will look into that, I am not really sure.
*nckx agrees.
<dftxbs3e>I think it's fine people choose their own kernels, as long as the problem is not silenced through support of proprietary software by GNU Guix
<Blackbeard>Or video drivers. My laptop needs proprietary bits for changing screen brightness
<anadon>OK, got a clean environment. Things appear to make sense. What was it about running the new guix daemon in terminal?
<Blackbeard>dftxbs3e: there are GNU free softwace standards and guix respects them
<dftxbs3e>Blackbeard, I know, I hope modern PPC hurries to become laptop viable :-)
<anadon>nckx: ^^
<jonsger>there is an interesting project on the WLAN front called https://github.com/open-sdr/openwifi They had a booth at the FOSDEM
<dftxbs3e>Blackbeard, I think most people who don't have free hardware will either use GNU Guix on top of another distro or run it in a VM, or they'll be tempted to use it on baremetal and acquire free hardware :-)
<nckx>anadon: After stopping any running daemons, does ‘sudo ./pre-inst-env guix daemon--build-users-group=guixbuild’ work?
<dftxbs3e>What's interesting this time is that GNU Guix brings real value, it's not only an alternative.
<dftxbs3e>Despite being based on NixOS, I think there is technical justifications for preferring it over it
<dftxbs3e>s/based/greatly inspired/
<nckx>bryanhonof: Your card is also likely to require (non-free) firmware. I hope you can find a libre USB adapter that's not too bulky, or that somehow the whitelist on later Thinkpad models is less fascist than mine.
<bryanhonof>dftxbs3e: I honestly was thinking to get a used X200 from ebay for shits and giggles. Libreboot it install guix on it and call myself a free/libre supporter :P
<dftxbs3e>bryanhonof, honestly that doesnt cost much and feels really nice!
<Blackbeard>Yes it is wonderful :)
<bryanhonof>nckx: I will continue my research on that, thank you for the help (<- this counts for all of you)
<bryanhonof>And if I do not find a good way to run it baremetal on my system it will just stay installed next to pacman
<dftxbs3e>And it's environment-friendly :P (refurbished)
<bryanhonof>dftxbs3e: True, I have seen them floating around in my area for around €100-200 sometimes even less when a company goes bankrupt.
<bryanhonof>But back then I was still all about fancy technology and sadly alot of that technology is completely closed and proprietary
<dftxbs3e>bryanhonof, X200 with a SATA SSD is really sufficient.
<anadon>nckx: Yes. I had to background it -- that's expected, right?
<nckx>Yep! If it runs, that's good.
<jonsger>the problem of openwifi is that you need an FPGA the cheapest is around 800$
<nckx>Now, try running ./pre-inst-env guix [whatever you wanted to do]. Possibly inside a similar environment.
<dftxbs3e>I actually like being bound by my hardware on such a device so that I am constrained to be minimalist with my system configuration
<nckx>If it barfs, share the barf.
<dftxbs3e>I otherwise offload heavy tasks to my beefy Talos II
<dftxbs3e>Often, having limited resources pushes you to only use the better software
<nckx>bryanhonof: Hope to see you back here with good news.
<dftxbs3e>That trend where using bunch of memory for no reason is acceptable is pretty annoying
*nckx looks at guix pull.
<bryanhonof>nckx: You will, i recently became really interested in the concept of free/libre software. And guix looked really cool i.m.o. because of how everything tries to be based on guile.
<bryanhonof>dftxbs3e: You do not like having to buy extra RAM just to load your favorite web pages these days? :)
<dftxbs3e>GNU Guix has the potential to be the base for an actual lisp machine
<dftxbs3e>bryanhonof, haha, depends of the websites, you can still create memory efficient websites.
<dftxbs3e>There's good and bad ones.
<bryanhonof>Does it? Because how I understand lisp machines is that it would still need hardware to directly execute the lisp code, instead of translating it to assembly.
<dftxbs3e>bryanhonof, oh I didnt mean to go this far. You can have the interpreter be the root of trust
<bryanhonof>dftxbs3e: Aaah ok, yeah than I completely agree with you.
<dftxbs3e>You can enforce security by refusing to emit machine code for things that are not allowed to run in a context.
<dftxbs3e>Maybe hardware acceleration for tagged memory or something
<dftxbs3e>Like IBM i
<dftxbs3e>IBM i uses the JVM on ppc64, however
<bryanhonof>Or maybe an extention to the RISC-V architecture to support lisp instructions. That would be cool i.m.o.
<bryanhonof>Anyways, thank you guys again for the help but I'll be heading off!
<bryanhonof>Till next time.
<dftxbs3e>Blackbeard, http://dpaste.com/OWCR5ME
<dftxbs3e>Blackbeard, sorry: http://dpaste.com/0WCR5ME
<anadon>nckx: https://paste.debian.net/1133828/ It still throws. My guess is that SELinux is somehow messing with "Failed to read existing filesystem - will not overwrite - ABORTING!". This needs more verbose error reporting.
<anadon>Running from the command line directly with those arguments as "guixbuilder01" works just fine.
<nckx>anadon: You can disable SELinux with ‘setenforce 0’ if you're privileged.
<anadon>Thanks. I'm running our of thought trying all these new things.
<anadon>nckx: No change. No hint at what the actual underlying error is.
<nckx>anadon: You tried patching in "-no-recovery", [why] not "-noappend"?
<anadon>It looks like from the description of "-noappend" that each invocation would remove all previous files added.
<Blackbeard>dftxbs3e: can you login in a tty?
<dftxbs3e>Blackbeard, yes, that's how I use my machine right now
<Blackbeard>Did you try reconfigure?
<nckx>anadon: OK, makes sense… I didn't read the mksquashfs manual.
<dftxbs3e>Blackbeard, yes, I had many tries to fix that issue without success :-/
<dftxbs3e>Blackbeard, I think it's some leftover configuration that causes this
<dftxbs3e>in /var/lib or whatever
<anadon>nckx: Who made this code?
<Blackbeard>dftxbs3e: you don't get any errors?
<anadon>I don't know the mapping of usernames on here to git names. It says "Ludovic".
<nckx>anadon: git blame says civodul and (later) rekado. Makes sense.
<nckx>rekado might have more experience with old Red Hat systems.
<dftxbs3e>Blackbeard, /var/log/gdm/greeter.log has: http://dpaste.com/26WYMNZ
<anadon>I'll post in the Mailing List Monday.
<dftxbs3e>Blackbeard, can't find an up to date Xorg log
<nckx>anadon: Thanks.
<allana>Hi guix. Any Docker users here now? Docker (dockerd) has not been working for me for several weeks. Can anyone help me diagnose and hopefully fix the issue? Some relevant information in this paste: https://paste.debian.net/1133832/
<allana>I did not see anything in the mailing list
<allana>I would be surprised if I was the only person facing this issue. It went fomr working one day to not working another day with no config changes.
<allana>from working one day*
<allana>So I am curious to know specifically if it is working for anyone right now.
<dftxbs3e>is the system configuration for ci.guix.gnu.org published anywhere?
<nckx>dftxbs3e: maintenance (in the list of Guix repos @ Savannah).
<rekado>dftxbs3e: yes, it’s in the maintenance repository
<rekado> https://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/hydra
<dftxbs3e>nckx, rekado: awesome! so it runs hydra and not cuirass?
<nckx>dftxbs3e: No, that's just the old name 🙂
<dftxbs3e>nckx, aah ok. does it run well on latest GNU Guix as well?
<nckx>dftxbs3e: It should. I meant that the name is old, but the code is current.
<dftxbs3e>nckx, I got that. I was just wondering how often was the software from the ci machine actually updated.
<rekado>dftxbs3e: this is the exact configuration used on ci.guix.gnu.org right now. No changes.
<rekado>(I think I pushed all changes today)
<dftxbs3e>rekado, awesome :-)
<dftxbs3e>I want to run a powerpc64-linux specific cache
<rekado>dftxbs3e: whenever it needs to be updated. There’s no schedule.
<rekado>if you don’t mind we could also add a machine to ci.guix.gnu.org
<dftxbs3e>do you think it would be a good idea to cross build a whole cache for a platform?
<dftxbs3e>rekado, oh really!!
<dftxbs3e>mine? or yours
<rekado>yeah, ci.guix.gnu.org is distributed
<dftxbs3e>you have a powerpc64 machine from OSUOSL already
<dftxbs3e>it's probably running a powerpc64le-linux system right now though
<dftxbs3e>but if nested virtualization is enabled, you can run powerpc64 within
<dftxbs3e>or reinstall with Gentoo powerpc64-linux or something
<dftxbs3e>also I wonder, is there a way to run Sheperd on top of an existing distro?
<rekado>what’s OSUOSL? We have a powerpc64 machine? Where?
<dftxbs3e>rekado, Oregon State University Open Source Lab
<dftxbs3e>rekado, ask nckx ;-)
<rekado>oh
<nckx>dftxbs3e: It's le, and I'd like to keep it that way since consensus at FOSDEM was that it was slightly less likely to be well supported.
<nckx>rekado: It's a VM.
<rekado>ah
<dftxbs3e>nckx, well turns out powerpc64-linux was easier to get working :P
*rekado looks at the loop from the outside
<dftxbs3e>I'll get powerpc64le-linux working as well, shouldnt be too hard at this point
<Blackbeard>dftxbs3e: did you try renaming that log file or deleting it?
<Blackbeard>I would rename it first
<nckx>dftxbs3e: I know! And I thank you profusely. I hope I can get LE up & running too.
<nckx>What was the crucial difference?
<Blackbeard>Then reconfigure and then try again
<rekado>nckx: what do you think: should we buy some powerpc64 servers?
<dftxbs3e>nckx, I think you can start from my tree, it should be only about using those '--enable-128-long-double' something
<rekado>or would that be premature?
<dftxbs3e>nckx, in both bootstrap-tarballs and during commencement.scm and that should be it!
<nckx>rekado: I think we should start ‘the conversation’ now, yes. By the time we decide what to buy & how much & from whom we should have something to run on them. Even if it's not Guix System yet.
<nckx>I think we should buy some, yes.
*nckx has to go now.
<allana>ah-ha, shortly after posting a question here about docker I got it to work by loading the overlay kernel module using modprobe. Now I need to figure out how to have that kernel module loaded automatically. Can anyone help me do this a guix-y way? :-)
<dftxbs3e>nckx, IBM, Inspur, and RaptorCS sells IBM POWER9 systems but I think RaptorCS are the only ones really focusing on the libre-friendly part, so that gives you not many other choices. But thankfully, they're top notch :-)
<dftxbs3e>I encourage you to buy the mobo and the CPUs from RaptorCS and then buy the rest as usual, it'll be much cheaper
<dftxbs3e>Or otherwise, if you want to support RaptorCS financially, you can get one of their prebuilt systems.
<rekado>allana: sorry, I don’t know.
<jonsger>I can asists with buying POWER hardware and assembling, installing etc.
<rekado>I fear that a bigger problem than than buying the hardware will be hosting.
<dftxbs3e>Though they're not so much more expensive, I think you pay a little bit more still.
<rekado>this has always been a problem for us.
<jonsger>for the short time I could make a VM on my POWER machine and expose it via DynDNS to the build farm
<dftxbs3e>rekado, hmm.. well it's standard 2U
<rekado>with the armhf boards, hosting in a living room was fine
<rekado>not so much with rack servers :)
<dftxbs3e>rekado, they also have 4U workstation cases that can sit vertically, I have one of those at home, it goes on well in my apartment
<dftxbs3e>Think about getting a silent power supply and fans and you'll be good to go.
<dftxbs3e>IBM POWER9 CPUs actually don't heat up that much, or at least they do but they tolerate higher temperature than Intel. I was told they could go up to 120 C in normal conditions
<rekado>hosting in a proper data centre is, of course, an option, but it’s a big recurring cost.
<dftxbs3e>rekado, I can also make a VM, I have 256GB of RAM total with half of that free.
<dftxbs3e>(for now :P)
<dftxbs3e>I have 5Gbit/s down, 600Mbit/s up network link at home as well!
<jonsger>^ what?
<dftxbs3e>jonsger, in France we have a provider (free.fr) that offers 8Gbit/s down (theoretical), 600Mbit/s up (artificially throttled) Internet subscription for 40 euros per month
<dftxbs3e>I have a fiber SFP on the modem they shipped me
<rekado>I communicate with the internet via smoke signals.
<rekado>oak works best.
<dftxbs3e>:D
<rekado>but my guitars were made of maple.
<rekado>down to the last ukulele now
<dftxbs3e>jonsger, I'm near Paris, in French fiber zones (usually big cities), you should be able to get the same speeds.
<jonsger>dftxbs3e: I'm in Germany we don't have much fiber :(
<dftxbs3e>Blackbeard, ohh! well the log didnt exist but I found another one
<dftxbs3e>Blackbeard, named Xorg.0.log
<dftxbs3e>I remember looking there and finding nothing.. glad I have something now.
<nckx>allana: One more thing™ before I go: I wonder if commit 205c1e04e04b9a9338c7219ff82bd13f000fb8c8 is somehow involved in this, since you mention the word ‘module’…
<allana>nckx: Thanks, I was justa bout to try customizing initrd-modules of my operating-system
<dftxbs3e>Blackbeard, here's what it says: http://dpaste.com/08TDXK0
<dftxbs3e>Seems like Xorg itself renames the log file..
<Blackbeard>dftxbs3e: what happens if you try going back to a working generation?
<dftxbs3e>Blackbeard, I tried that too. Ran into similar errors as well.. it used to work just after install..
<Blackbeard>dftxbs3e: that's strange
<Blackbeard>So even working generations are failing to start? :/
<dftxbs3e>Blackbeard, Well. I remember trying them and it failing as well yes. Since then I ran guix gc so..
<dftxbs3e>Blackbeard, is there a way to generate a config with GNU GuixSD Graphical Installer from an installed copy of GNU Guix?
<Blackbeard>dftxbs3e: but why would you want one? You already have one and there are examples in the manual
<dftxbs3e>Blackbeard, just to make sure. I took an example from the terminal. Thanks.
<alextee[m]>ctrl+shift+alt+R works again! thanks whoever fixed it!
<dftxbs3e>Blackbeard, from the manual *
<leoprikler>alextee[m]: which commit?
<alextee[m]>guix (GNU Guix) bc8b2ffdac3f55414629ace5b1a0db32e9656c0a
<leoprikler>huh, wonder what fixed it