IRC channel logs


back to list of logs

<lfam>The loss of the domain for ~13 years is really crazy, though.
<lfam>Truly astounding
<rekado>ACTION —> zzzZ
<marusich>civodul, do we have any tests which verify the behavior of 'guix system reconfigure'? It looks like the system tests don't check behavior across reboots. Since the vm is started with -no-reboot, we just start up the vm, check stuff, and that's it.
<marusich>To add tests for roll-back and switch-generation, I could verify without rebooting that e.g. symlinks got updated and that the new grub.cfg is still a gc root, but I'm wondering if it would make sense to reboot and verify that /run/{current-system,booted-system} point to "the expected place", and that the symlinks in /var/guix/profiles/ are "still correct"
<civodul>marusich: tests/services.scm has unit tests for some of it, but there's not complete test yet
<civodul>i guess we could write a system test for that
<civodul>so yes, you could check symlink targets, and ideally you could also reboot and check again
<marusich>qemu-command/writable-image in (gnu tests install) hard-codes "-no-reboot" into the command that runs QEMU. To facilitate checking something after a reboot, I'd need to use a different command to start QEMU, wouldn't I?
<dvc>lfam: What's the status of kicad? did you look at the v3 patch series that foradis sent?
<lfam>dvc: Ah yes, I did look at it but then I forgot about it. I'll look at v3 once I finish with this libtiff update. I'll do it tonight
<lfam>Thanks for the reminder!
<lfam>dvc: Any experience with CVS?
<dvc>i'm fixing the openocd patches and will push those...
<dvc>only git :)
<lfam>Alright, then I'll get to kicad soon enough :)
<dvc>the one and only version control!
<lfam>I don't think CVS is about version control. I think it's actually a privacy tool. Put your data in the CVS repo and then nobody will ever be able to read it
<civodul>lfam: when i have to deal with CVS i mostly use "VC" in Emacs
<civodul>are you trying to retrieve the diff of a commit?
<lfam>I finally got the patches extracted. It turns out that CVS gives different revision identifiers based on how you invoke `cvs log`
<civodul>right, it has no notion of commit/changeset
<civodul>that's the funny part about it
<lfam>So, you have to do `cvs log file` rather than `cvs log`
<lfam>Otherwise you get bogus identifiers
<lfam>And it includes a "commitid" in the log, but apparently none of the tools can make use of it...
<civodul>yes, it was added as a hack afterwards to simplify conversion :-)
<lfam>So many bugs have been fixed since the last release, it might be reasonable to build from the repo
<lfam>Gosh. One of these two bugs is a duplicate that I already fixed
<dvc>xD I learnt that the hard way too. Always check the latest source first, and check if there is a development branch... Too much time wasted...
<dvc>so nice to be doing something "constructive" again vs all the pseudo class work
<civodul>dvc: don't fail your exams ;-)
<lfam>Now I test the kicad patches
<civodul>marusich: after spending time staring at your patches and fiddling with them, i ended up sending you an updated patch
<civodul>i've reversed the roles ;-)
<marusich>Haha OK :)
<marusich>You're fast
<civodul>not that fast, i think it took me 1h30 to wrap my head around it
<civodul>tricky stuff!
<marusich>I'll take a look
<dvc>*dvc is going going to bed
<lfam>sneek: later tell dvc: Good morning! ;)
<sneek>Got it.
<zacts>hi guix
<rekado>oof, just reviewed patches that were later marked as obsolete :(
<rekado>Hi Guix!
<sneek>Welcome back efraim, you have 1 message.
<sneek>efraim, ng0 says: I think I found some parts in psyclpc which cause it not to be reproducible. I will test this today and if lynX happens to be online today, it'll be fixed today or within the next days, otherwise I will already include it in guix as a patch phase before it goes into upstream
<efraim>sneek: botsnack
<efraim>I'm preparing to give some loving to samba.scm, and by loving I mean a beating with the anti-bundling stick
<rekado>efraim: woo!
<efraim>Anything to not have to hack on the daemon :)
<efraim>First target is the bundles waf
<rekado>hmm, I got three mailer-daemon delay notifications just now for emails to openmailbox and ng0’s domain.
<Apteryx>How was the party?
<Digit>anyone know if anyone bedrock hijacked a guixsd yet? n did it work? and same question, for adding guixsd as a bedrock strata to an existing bedrock system.
<efraim>did we make autoconf 1.15 the minimum?
<jmd>Does anyone know what package(s) I need to install to get emacs' po-mode ?
<amz3>Digit: what is a bedrock starta?
<amz3>Digit: or bedrock system?
<alezost>sneek: later tell jmd re "what package I need to install to get emacs' po-mode": in theory you need to install 'gettext', but it doesn't work currently (fixed in core-updates), see <>
<sneek>Will do.
<efraim>it works!
<efraim>now I have to find that throw-away comment again
<efraim>and build out to hello
<efraim>currently compiling gcc-boot0 on aarch64
<efraim>from man 2 clone: "For example, on aarch64, child_stack must be a multiple of 16."
<ng0>why is openssl not deterministic? that's one of the dependencies of psyclpc. we have applied some reproducibility fixes at our end, but because openssl is not deterministic I can not use guix to check if this fixed it completely
<ng0>are there other ways to find out?
<rekado>you can build it twice and compare the result
<ng0>i thought it has to be more than twice? that was what I was aiming at.
<ng0>building twice with --fallback --no-grafts: seems fixed now at our end
<jmd>diffoscope might help
<sneek>Welcome back jmd, you have 1 message.
<sneek>jmd, alezost says: re "what package I need to install to get emacs' po-mode": in theory you need to install 'gettext', but it doesn't work currently (fixed in core-updates), see <>
<paroneayea>things that are fun to think about but I'll probably never get around to:
<paroneayea> package the CADR lisp machine emulator and associated software for guix and get it runnable :)
<paroneayea>it's free software, and our history!
<lfam>Any Gajim users here? Can you tell us if we need to do anything about this bug?
<lfam>"OTR leaks cleartext when using XHTML"
<lfam>Is our package vulnerable to that?
<lfam>mark_weaver: I noticed you've fixed Gajim bugs in the past
<rekado>I don’t think we have OTR in gajim
<rekado>ACTION checks
<rekado>I think OTR is provided by a plugin
<rekado>“What's the status of python-otr and gajim-otr on GitHub or the gajim-plugin repository?”
<rekado>“It's dead.”
<rekado>“I do not recommend using this software, as it's completely unaudited and written by non-cryptographers. I would not be surprised if it provides absolutely no security in any sense.”
<lfam>It *seems* like a plugin based on the bug report but I don't know much about our Gajim package or Gajim in general
<lfam>Building it now to see what it creates
<rekado>I use Gajim and OTR is not available
<rekado>I can see it only in the plugin browser
<rekado>(but I’m not yet using the latest version)
<lfam>So, plugins are something that we don't ship?
<rekado>correct. Plugins have their own dependencies.
<lfam>Okay, good news for us, I guess
<rekado>the only plugin we have is the plugin installer.
<lfam>This is funny, there's a directory in gajim called "dcraven"
<lfam>In the package, that is.
<lfam>Do we share a contributor? :)
<lfam>It looks like core-updates is pretty close to being ready. There are a handful of python packages left to fix. I assume we'd like to fix ardour. We should fix wget on armhf and mips64el. What else?
<lfam>I know already that the latest borg release's test suite depends on a newer pytest. I think I'll package it just for use in borg.
<lfam>The failure of the Go bootstrap on mips64el seems pretty fixable, considering that it fails with a Scheme error:
<rekado>I just fixed and updated python-joblib
<lfam>Nice :)
<lfam>rekado: Do you think I should start a new core-updates-3 evaluation?
<rekado>are things not being evaluated again?
<rekado>ACTION is not so happy about some commits that look like they didn’t get reviewed enough :-/
<lfam>rekado: It's looked to me like core-updates is being evaluated manually
<rekado>oh, I’m sorry I misunderstood.
<rekado>I see that we already have a core-updates-3 jobset
<rekado>the last I knew of was core-updates-2, so I wondered why you want to create a new jobset.
<rekado>just starting a new evaluation of core-updates-3 should be fine.
<lfam>Right, I think we kept creating new ones to work around that Hydra bug. We've made a bunch of changes since the last core-updates-3 evaluation and I'd like to see the results
<lfam>Okay, I'll do that
<lfam>rekado: It's never to late to revisit existing commits :)
<lfam>I've asked Hydra to start another evaluation of core-updates-3
<efraim>why does make-boot0 have a separate debug output?
<ng0>why should I call a software in a comment which is really shareware non-free? does the difference in a comment matter?
<ng0>license is labeled shareware, I did not come up with that
<ng0>either way people will have no access to it here
<ng0>there's a discussion going on at tor-devel/tbb-devel which makes me assume that if it turns out to get to a decission, we will not be able to build a torbrowser, if we'd ever include it, at all at some point in the future. at least I think statically linking could be a problem
<lfam>ng0: link?
<lfam>Or are those IRC channels?
<rekado>ng0: re “shareware”, I just think “non-free” is clearer in our context.
<ng0>thanks for your review, I realized I had some unpublished changes.
<ng0>I will try to get the next version of patches out once psyced fnctions with the psyclpc with the pcre again and there are new release tarballs including all of this
<ng0>I'll include the move from now existing psyc.scm to messaging.scm there, makes no sense to do it now
<rekado>ng0: your comment on torbrowser is quite vague. Could you elaborate?
<rekado>static linking is not impossible with Guix
***kragniz is now known as kragspooks
<janneke>to be able to use --rounds=2 with build, i must either remove the package or change it if it's already built?
<efraim>you can also try with --check
<Digit>amz3 sry, forgot to include link that would have explained that question i asked right before falling alseep.
<Digit>anyone know if anyone bedrock hijacked a guixsd yet? n did it work? and same question, for adding guixsd as a bedrock strata to an existing bedrock system.
<janneke>efraim: thanks!
<civodul>Hello Guix!
***kragspooks is now known as dootniz
<lfam>Hello civodul!
<efraim>i need to look at commencement.scm more but looking at LFS I shouldn't need a libstdc++-boot0
<ng0>rekado: it's not? I understood guix so far that it implies dynamic linking by design
<civodul>Guix doesn't know what "linking" is, so no problem
<ng0>it's maybe one of these aspects I should read the paper for
<ng0>could one theoretically mix static + dynamic in our system?
<ng0>and to make it a bit more interesting: different libcs?
<ng0>I assume yes so far, but it's not applied
<ng0>libcs i mean, linking, that the question I can't solve myself
<ng0>i think I need to break this mess up again:
<civodul>bah debbugs.el is still broken
<civodul>if anyone has a workaround, i'm interested
<ng0>sorry, had a little interruption. so: 1) could we use static and dynamic linking in the system at the same time without issues (or switch to static if we figure, hey we want smaller binaries etc with uclibc-ng or musl for example) and 2) is the toolchain only at bootstrap level bound to one system and above that we are free to use whatever we could but for consistency (and because not every libc is packaged
<ng0>yet) we stick to one implementation, but more are possible without bouncing into walls like other systems do?
<efraim>Having spent the past two weeks in commencement and make-bootstrap it looks like it should be as "simple" as switching the GCC inputs
<efraim>Er, s/GCC/libc
<efraim>And this is why I shouldn't write and commit patches late at night
<ng0>I imagine we could at some point have a libc option where you could globally choose musl/glibc/uclibc-ng .. or am I still stuck too much in the middle road between guix and gentoo? would this work, selection a libc globally?
<civodul>efraim: fiddling with commencement.scm is quite time consuming, notably because it takes a lot of rebuild to find out whether you made a mistake
<civodul>just to say that i sympathize with you ;-)
<Apteryx>I'm seeing "collision encountered", caused by .../share/mime/globs. Can I do anything to fix that?
<Apteryx>The package appears to be "shared-mime-info-1.6"
<Apteryx>By the way, is there a command to list the software installed globally? I know how to use "guix package -I", but this lists only the extra software installed in my personal profile.
<lfam>Apteryx: Do you understand the issue behind the collisions? If so, I'm not sure how to fix them. We have to approach it on a case-by-case basis
<lfam>Regarding global packages, I'm not sure if we have a canonical way to list them. They are specified in /run/current-system/profile/manifest
<Apteryx>lfam: No, I don't understand the issue behind collisions. My guess is that two different packages needed a different versions of a binary/dependency, and that those two versions are clashing to appear in my PATH? Maybe I should complete my reading of the fine manual.
<lfam>Apteryx: Basically, multiple packages contain a path like 'share/mime/foo', so when those packages are symlinked into '~/.guix-profile', those paths "collide"
<lfam>Only one of the packages' 'share/mime/foo' will exist in your profile
<Apteryx>lfam: I see. Can guix tell me which packages are causing that?
<lfam>Sometimes it's harmless, sometimes not
<lfam>Yes, the packages are named in the collision warning messages that you saw
<Apteryx>Oh right!
<Apteryx>So it seems that "xdg-mime-database" is colliding with "shared-mime-info"
<Apteryx>Thanks for making me look closer at the collision messages :)
<Apteryx>Now, I need to resolve which package I recently installed which would have pulled those dependencies.
<ng0>sometimes you don't have to. some collisions are okay
<lfam>Once you've investigated a little bit, please send in a bug report if you think these collisions will some a problem
<lfam>What a strange typo!
<Apteryx>But will I see those messages everytime I install something new?
<lfam>Yes, as long as the collisions are still present. Your profile is rebuilt each time you install, remove, or upgrade a package
<lfam>The messages are annoying but they serve as an incentive to do something about them ;)
<Apteryx>OK. Thanks for the explanation.
<rekado>ng0: re alternatives to glibc: I don’t think we’ll ever have enough capacity to build the world for as many times as there are libc implementations. It’s also not really our goal to do this.
<rekado>ng0: we could apply patches to make software work with other libcs, so that users can swap out the libc with the input rewriting framework we already have.
<ng0>for the first reply, I think it's doable, but not right now.
<rekado>but the primary focus is on building the GNU system and this isn’t helped much in adding more libcs.
<ng0>there are just glibc, musl, and uclibc-ng you need to pay attention to
<ng0>2 are covered
<ng0>and uclibc-ng is almost 1:1 to glibc in build compatrablity
<ng0>with vanilla uclibc-ng it's closer to 1:1
<rekado>“almost” :)
<rekado>well then you could build the new libc and preload it with LD_PRELOAD or similar.
<ng0>technically 1:1, but I am only exposed to the hardened variant of it.
<ng0>where you'll run naturally into problems
<rekado>if it’s really a drop-in replacement there’s little value in rebuilding the world to offer variants for all packages that sit on uclibc-ng.
<rekado>ACTION —> zzZ
<ng0>it's not a drop in replacement
<ng0>I spare you a long list of things, uclibc-ng made a list of comparison themselves
<lfam>What does `guix package -u . --keep-going` do if something fails? Does it merely keep building, or does it also do a profile transaction at the end?