<catern>isn't there a program which patches Guix packages to be usable without the /gnu absolute path, by using $ORIGIN? <lfam>CharlieBrown: Did you pick the right audio output from the drop-down menu? <lfam>It works for me on Debian but I usually have to pick the right thing <CharlieBrown>lfam: Which drop down menu? I went into the settings and only one option was available in each (ALSA). <lfam>CharlieBrown: On the main screen there is a drop-down menu with an icon of a speaker next to it <lfam>It's the same as Preferences > Devices > Playback Device ***pksadiq_ is now known as pksadiq
***pksadiq_ is now known as pksadiq
<efraim>i'm copying the ntp service as a basis for the openntpd service, I assume I should borrow heavily from others that provide a 'service-type' and not just a 'service' <civodul>every "service" is actually a service-type <brendyn>My Evince is failing to remember what page I was on last time I opened a pdf. Does anyone else find that? <civodul>brendyn: does it warn about a missing GSettings thing? <civodul>settings are saved via "GSettings" AIUI <civodul>mb[m]1: i was going to generate that glibc tarball, but that's the name of the branch again? <civodul>release/2.26/master seems to be something different (?) <civodul>at least 'git describe' doesn't report what you'd expect <civodul>bah, i get a different hash for the tarball <efraim>to delete a system profile I just remove it from /var/guix/profiles ? <g_bor>Just a quick question: I have a package inherited from a package having a debug output, and it seems, that I have a .gnu_debuglink records installation directory reproducibility problem further down the inheritance hierarchy. <g_bor>I'd like to know if adding outputs out to this package would help, or should I add a strip .gnu-debuglink phase? <g_bor>(basically do we have a .gnu-debuglink if we don't have debug output?) <m-o>efraim: yes, you may also want to guix gc after that. <civodul>i didn't understand your first sentence though <civodul>are you saying you found a package that's not reproducible? <mb[m]1>civodul: different hash, really? Did you copy the command exactly as written, including the trailing slash after --prefix? <g_bor>No, that's not it, the package is reproducible. <g_bor>We are trying a slightly different approach in the diverse double compilation project, that causes otherways harmless problems to appear as non-reproducibility. <g_bor>In the usual setting recording the installation directory is not a problem, because we always install the package in the same place. However when we want to compare the double compiled results, then we have a problem with the recorded installation directory. <g_bor>For example libtool la files have a reference to the installation directory. <civodul>git archive --prefix=$(git describe)/ HEAD | xz -9 > $(git describe).tar.xz <mb[m]1>civodul: I had used a slightly different command than the documented one, see email. <mb[m]1>I'll push the updated hash shortly. <civodul>efraim: regarding commit 4f3e02f198719c98a46aa3060fbd9bececa20f87, which fixed t1lib CVEs, do you think you could split the big patch into several ones? <civodul>currently its file name is just a couple of bytes away from tar's maximum file name length limit <efraim>Sure, I can take a look at it when I get home <efraim>civodul: we can actually just cut t1lib out, nothing depends on it <civodul>efraim: right, but maybe that's a bit radical <bavier>civodul: nice writeup on cluster installation! <ng0>hi! I have some open font patches for at least 1.5 months and more (oldest is august), with no comments and one as I understand it good to go. Can someone review and/or push in the next days? That would be most appreciated <lfam>ng0: The nototools patches? <lfam>I'll handle them now if you can give the subjects of the emails or some hyperlinks <lfam>ng0: I'll handle them now if you can give the subjects of the emails or some hyperlinks <ng0>the nototools aswell I meant. <ng0>they are prefixed with [font] <ng0>in the bgtracker i mean <ng0>and 28594 is nototools <bavier>anyone else see failures of tests/guix-system.sh on current master? <ng0>ACTION makes a note that the next gnunet bot should give links to guix patches when someone mentions #123567number in the buffer <ng0>also Geomyidae is working, in case anyone feels like gophering over a new review :) <ng0>ACTION shouldn't try to bundle services and patches anymore <ng0>another thing that is good to go is the i3lock-color + i3lock-fancy. I'll apply the tiny correction I mentioned in the last email and send the new version. <ng0>As I understand it Xfburn only needs description edits applied and it's good to go aswell. I'll work on this tomorrow <ng0>2018 will be the year of debbugs on Guix. Or at least I hope I can finish testing the package. I don't want to let it become 14 months old because of no test suite and only manual work. <lfam>ng0: Regarding the nototools patches, why are they only Python 2? Do they not work with Python 3? <lfam>It's okay if the answer is "I don't know". I'll try it myself in that case <ng0>I knew once upon a time <ng0>so far my guess is: maybe because of one of the dependencies. <ng0>I wasn't really prepared for this question anymore :) <lfam>Okay, I'm just going to ignore it :) <lfam>I'm also going to move a couple of the libraries to fontutils.scm, so that python.scm doesn't grow too much <ng0>ahaha.. damn I intended to append the rebased patches to the comments I made <ng0>I only pushed it to my server. hm. still not my best day <ng0>ufolib is python2 only <ng0>and I drew the conclusion back then *I think* that this implies thta we should do the same for the whole graph <ng0>I think I'll send a correction commit for fira-sans. My description and synopsis was bad <CharlieBrown>I try to explain to my family members that Guix and GPG are reliably secure, but they just blindly insist that the government has everything compromised and alters everything all the time wihout anybody knowing. <lfam>ng0: I already pushed it <ng0>I know, htat's how I noticed it <bavier>CharlieBrown: e.g. guix uses an EDSL for packages, which allows for more powerful package manipulation that what Nix gets with its special-purpose language <janneke>CharlieBrown: that depends on your perspective, some like Nix better. What's your take? <ng0>is X.X.Xx, for example 1.2.3a more established for minor patch releases where a fourth separator is not allowed for various reasons? <ng0>more than X.X.X-X (1.2.3-1) <lfam>ng0: I've noticed the latter tends be used by distro when revision their packages <lfam>I mean, when revising their packages <lfam>I think it doesn't really matter as long as the versions are ordered correctly when sorted alphanumerically <ng0>Gentoo has hard checks on "-" if you don't use the versionator eclass or any other eclass providing the tools to rewrite it to their liking. <ng0>so 7.56.1-2 is a no-go on Gentoo for example <lfam>I noticed it in the latest gnurl. I don't think it really matters for us <ng0>I know it doesn't matter for us <civodul>CharlieBrown: there was a branch that dustyweb started, though it may have gathered dust (ah ha!) <ng0>I guess as long as no one other than Gentoo informally complains, I stick to what I used recently. The ebuild I wrote a long time ago is miles behind what I have. <civodul>would be great to have a MediaGoblin service <ng0>lfam: thanks for your work :) <roptat>hi, I'm having some trouble building a package... <roptat>I get this: *** error: gettext infrastructure mismatch: using a Makefile.in.in from gettext version 0.18 but the autoconf macros are from gettext version 0.19 <roptat>I'm not sure if it's an issue with the package or guix... <lfam>roptat: The name of the package? <roptat>I'm running its autogen.sh first <civodul>roptat: you may need to run 'gettextize' during the bootstrap phase <roptat>replacing ./autogen.sh with autoreconf -fiv worked <civodul>yeah, people often feel the need to write their own autogen.sh <lfam>civodul: What is the purpose of listing the patch files in gnu/local.mk? <civodul>kmicu: that's the bright horizon :-) <civodul>lfam: it's boring, but it's so that "make dist" can add them to the tarball <lfam>The node patch from earlier today didn't get registered there <lfam>I can push a followup commit now <civodul>yes i've made this change locally too <lfam>I tested a `guix pull`, which worked, so I felt confused about the purpose of patch list <lfam>of the patch list, I mean <civodul>yeah it's really just for "make dist" <civodul>which sounds a bit anachronistic in a way <lfam>ACTION tests the latest QEMU bug fix patches <bavier>I personally like the hardcoded lists of files in automake <bavier>sure you might forget to list a file here and there, but you save yourself the (more embarrassing) possibility of unintentionally distributing a file that gets caught up in a wildcard <civodul>bavier: true, that's also something i appreciate <civodul>though in practice that info is mostly redundant with what Git already knows <civodul>ACTION pushes certbot and other patches by wingo <bavier>civodul: dist_patch_DATA = $(shell git ls-files gnu/packages/patches) ? <bavier>well, no, you'd need to substitute it or something so that users don't need git installed <bavier>anyhow, there are more important things to work on