IRC channel logs


back to list of logs

<apteryx>hm, a page full of #54447 errors
<antipode>sneek: later tell amjoseph: it does: antioxidant. Even better, it doesn't use Cargo.lock either; it works like normal package definitions.
<sneek>Will do.
<psyclimb`>gnu guix!
<martin2020>is it possible to run AppImage on guix?
<martin2020>I downloaded one, but I get errors when I try to run it. Does anyone else have experience trying to run AppImages?
<lilyp>martin2020: you have to use patchelf to get the correct linker and libraries, but then it ought to work
<adanska>what is this "new package style" that i keep seeing in commits? eg. a08592b055e9b6d9baf704e2405ba9ae38215e62 with syncthing. is there a new reference guide re writing packages?
<adanska>or is it simply using gexps more?
<adanska>i feel like thats not the whole picture though.
<iyzsong>adanska: it's about using gexps for 'arguments', and remove labels for 'inputs'. 'guix style' can adjust that for old ones.
<xelxebar>martin2020: Yeah, it's a tad annoying. As lilyp mentioned, you need to put glibc and all its dynamic libs in a guix shell. Then use patchelf --set-interpreter to set the to the one in your shell.
<xelxebar>Then you can use LD_PRELOAD=$GUIX_ENVIRONMENT/lib the-executable to run the program.
<xelxebar>Need to identify all the dynlibs with ldd or similar and then figure out which packages offer the corresponding so files.
<xelxebar>guix locate probably helps these days. For packages not in the store, I typically use Debian's package search to get a hint on cases that aren't very clear:
<podiki>martin2020: see also (though note that the gcc:lib package isn't available, there is a workaround though)
<podiki>martin2020: instead use -e '(list (@@ (gnu packages commencement) gcc) "lib")'
<podiki>sneek: later tell martin2020 see ^ (or log) for using fhs container for appimages
<sneek>Got it.
<adanska>iyzsong: ahh.. okay, thank you. reading the `guix style` page has answered most of my questions. thanks :)
<spine-o-saurus>the hurd system is used for the kernel right?
<jpoiret>spine-o-saurus: can be used, although it's quite experimental
<jpoiret>usually Guix system uses the linux-libre kernel
<jpoiret>for example, there is no isolation of build processes on the Hurd yet
<attila_lendvai>if i add multiple sysctl-service-type to my services, then their sysctl entries will be merged, right?
<attila_lendvai>if this is true, then the manual recommends something unfortunate (to use modify-services as opposed to adding a new service) at
<iyzsong>attila_lendvai: only one instance of a service-type is allowed, other can extend it by 'extensions'. 'extensions' for the sysctl-service-type will be merged
<attila_lendvai>this is such a confusing part of guix! and i've written multiple services already. i think it's mostly due to the unfortunate naming of the abstractions... service vs. simple-service vs. shepherd's service abstraction, all intermingling in the same context.
<attila_lendvai>FTR, the solution is to add this as a service entry: (simple-service 'ipv6-config sysctl-service-type '(("net.ipv6..." . "...")))
<attila_lendvai>adding this seemingly very similar thing leads to an error: (service sysctl-service-type (sysctl-configuration (settings '(("net.ipv6...." . "...")))))
<andreas-e>Were the man pages for C moved? Commands like "man malloc" do not work any more. I have installed gcc-toolchain and not glibc into my profile.
<civodul>andreas-e: hallo! i believe it's in the 'man-pages' package
<civodul>"guix locate malloc.3.gz" confirms it
<andreas-e>Thanks, civodul! The package has last been touched ages ago, I am surprised I somehow lost it from my profile.
<jpoiret>attila_lendvai: simple-service creates a service *extending* the one you're giving it
<jpoiret>as opposed to (service ...) creating a new service of the type given
<jpoiret>maybe renaming `simple-service` to `simple-extension` could clarify that
<cbaines>remind me why guile makes so many readlink system calls?
<jpoiret>cbaines: guile itself or Guix?
<jpoiret>Guix does use quite a lot of them
<cbaines>I've heard of this issue, so I guess it's come up in relation to Guix, but I've noticed it specifically when looking at the build coordinator
<andreas-e>cbaines: Hello! How often is the branch substitute availability recomputed?
<civodul>cbaines: how 'bout i reconfigure bayfront?
<andreas-e>What do you think about adding the system for the packages at ? To save space, maybe the category could be dropped.
<andreas-e>(The background of my question is the i686 availability, which prevents new patches to be tested.)
<cbaines>andreas-e, should be every 30 minutes
<cbaines>civodul, that's fine with me
<andreas-e>Good! I wondered because yesterday the i686 availability hardly changed, but this must be due to only x86_64 packages being built. Thus my second question/suggestion :-)
<cbaines>andreas-e, milano-guix-1 was down until yesterday, and the coordinator was offline overnight, so things are a bit behind, hopefully it'll catch up soon though
<andreas-e>Right now the texlive packages are being built. The activity site turns into a fast-paced action film!
<andreas-e>Is there a way to get an idea of the backlog? Like the number in the gray box for cuirass?
<andreas-e>Or otherwise said: How much of the 22.6% missing to reach 100% substitute availability for i686 on master is due to build failures, and how much to scheduled builds?
<cbaines>andreas-e, you can ask the data service what's blocked
<cbaines>but I think for i686 it's just that the builds haven't happened yet
<cbaines>I've discovered the secret setrlimit procedure in Guile now, so I've increased the open file limit, which should help to avoid the coordinator breaking, and hopefully allow me to track down why there's so many files/ports open sometimes
<andreas-e>cbaines: Thanks!
<davidl>I have an issue where my guix package fails to build after pulling the channel but when I do guix build -f ./mypackage.scm. It throws an wrong type argument in position 1 expecting string - so hinting at a variable does not exist. What variables may be available during a guix build -f <mypkg> but not after the same file <mypkg> has been commited to the channel and guix pulled?
<attila_lendvai>jpoiret, i'd call it service-extension. or anything else that contains the concept/word 'extend', if this mechanism is called extension in the manual and the rest of the codebase.
<attila_lendvai>jpoiret, but i have a problem with the use of 'service' itself. i'd call guix services as components to avoid the confusion with stuff that runs as a process.
<jpoiret>attila_lendvai: I agree
<attila_lendvai>building guix on x86_64 fails, there's no substitute:
<qeqpep2>Hi, this produces operating-system with many duplicate services: (operating-system (inherit installation-os) (services (operating-system-services installation-os)))
<qeqpep2>A bug? How to completely override 'services' field of inherited os?
<attila_lendvai>wtf, mingw-w64-x86_64-11.0.1 as a dependency of gzip-1.12 on x86_64-linux? (this is why guix build fails)
<attila_lendvai>or is this some bootstrapping issue?
<jpoiret>attila_lendvai: how did you see that?
<jpoiret>through a guix build?
<attila_lendvai>jpoiret, my root issue is that guix is being built locally after a recent pull
<attila_lendvai>i may be misinterpreting the cuirass gui
<attila_lendvai>jpoiret, yes, i'm misinterpreting it. this is the right one i think, and it's still being built:
<attila_lendvai>is the former one a cross-compile for windows, thought? that'd be rather surprising to me.
<jpoiret>i think guix is in the set of packages that is checked for xcompilation
<andreas-e>attila_lendvai: Indeed this is the case. The derivation contains inputs such as gcc-cross-x86_64-w64-mingw32.
<attila_lendvai>isn't that a waste of build infrastructure? i mean, it's pretty hopess, no?
<jpoiret>attila_lendvai: why?
<jpoiret>I wouldn't bet on Guix working 100% but some parts might
<Altadil>Did a recent commit broke guix ? I juste did guix pull but can reconfigure the system anymore. Seems sheperd-mcron fails to build.
<andreas-e>Altadil: This sounds like a bug just was just repaired in the most recent commit. Can you try to pull once more?
<Altadil>andreas-e: still no luck. I am on 552d070, acording to guix describe
<ekaitz>hi! anyone here has thermald configured for personal use? It's like there's no way to add a configuration file to it
<andreas-e>Altadil: Sorry to hear this, then I do not know.
<Altadil>andreas-e: that’s fine, thanks for your help
<jpoiret>Altadil: maybe it's that very commit that broke it, you could try pulling from a commit earlier
<Altadil>jpoiret: going back to one commit before worked, thanks !
<janneke>to any emacs users here not using direnv+envrc.el i would say, consider taking advantage of the fact that we're still in the lazy summer/winter period like i did yesterday and have a look at <>
<janneke>(read to the end before starting to install/try things, because there's a small twist towards the end)
<cbaines>does the latest commit on the master (804074681c03af4f534aff40cc5496112d92416c) branch still need reverting?
<janneke>cbaines: i don't have that commit here?
<hako>I'm adding a fixup.
<hako>Sorry :(
<cbaines>janneke, ah, I'm misusing magit, it's 552d0703776c532f25498d5cb852c3c497cb9252
<jpoiret>hako: congratz by the way :)
<janneke>cbaines: check
<jpoiret>janneke: i've been writing my own elisp for this because i'm not satisfied by any of the existing solutions. but as you might have guessed, i'm not satisfied by my own code even
<janneke>jpoiret: hehe
<jpoiret>i dislike having to keep a state of which files are authorized to create an env automatically
<janneke>for now i'm _really_ happy with this solution, but i've only been using it for a day now
<janneke>also: <> ;)
<janneke>jpoiret: that's becoming ridiculous
<janneke>guix shell with its authorize thingy, and now direnv on top of that ...
<jpoiret>my own approach is having arbitrary .el being executed for files in a project, and adding helpers to simplify writing it instead
<janneke>.jpoiret.el or something :)
<jpoiret>that way you have better control over the set-up, compared to .dir-locals.el and buffer-env/direnv
<janneke>yeah, i'm not sure if i like the direnv "magic"; a manual guix shell also has its charm
<janneke>but setting the emacs environment per buffer in an easy way that really helps me
<hako>Hi Altadil, latest commit should work now, can you pull again?
<hako>jpoiret: Thank you! Though really feeling stressed now...
<Altadil>hako: pull and reconfigure completed. Everything seems fine. ^.^
<hako>That's great!
<MatoHota-Tmp>I cannot use ./configure during a package build and get a C compiler cannont create executable
<MatoHota-Tmp>Anybody got an idea of the problem source ?
<MatoHota-Tmp>I'm using a standard "gnu-build-system"
<mirai>MatoHota-Tmp: you don't have a ./configure file in the source then?
<MatoHota-Tmp>There is one
<mirai>configure or ?
<mirai>under a subdirectory?
<mirai>confirm this by downloading the source directly
<MatoHota-Tmp>in the log I can't see the error
<MatoHota-Tmp>sorry : I can see the error
<mirai>can you paste the build log
<MatoHota-Tmp>Nope - can't paste from my work
<MatoHota-Tmp>I try to copy part of it - I hope I won't make too many mistakes
<MatoHota-Tmp>configure: error: in '/tmp/guix-build-florist-22.1.drv-0/florist-22.1-20220106-1C034-src':
<MatoHota-Tmp>configure: error: C compiler cannont create executables
<ngz>Hmm, in what environment should I run ./etc/committers? I tried guix shell guix, to no avail.
<mirai>use a paste site (like
<MatoHota-Tmp>forbiden from my work
<MatoHota-Tmp>florist is a software written in Ada that I try to package
<MatoHota-Tmp>I had to package the compiler in a "gnat" package that install fine (I can even use it)
<mirai>MatoHota-Tmp: well, you'd have to wait for a fortune-teller to appear here since there's no clue as to what exactly is configure complaining about
<MatoHota-Tmp>ok, thanks
<mirai>ngz: within a guix checkout
<MatoHota-Tmp>I'll try to instrument the configure script
<ngz>mirai: Sure, but all I get is "no code for module (guix gexp)" (and no t-shirt).
<mirai>./pre-inst-env ?
<ngz>mirai: That's it! I didn't think of that because commiters.scm is a Shell script. Thanks.
<podiki>cbaines: is there something up with the us east mirror? last few weeks (i think) often on downloading substitutes it will just timeout, other times be usual quick
<ngz>mirai: BTW, I eventually understood your remark about `=' vs `prefix' in wrap-program, but I cannot answer as I don't use dblatex.
<mirai>ngz: :) I was planning on replying with a snippet after I squashed my local commits
<cbaines>podiki, I'm unsure, I don't have much visibility over how it's working. I can see some timeouts in the NGinx logs, so maybe it's having problems talking to bayfront sometimes
<cbaines>it would be nice to have some metrics for the reverse proxying
<ngz>mirai: Having a too large GUIX_TEXMF shouldn't hurt however, as long as the packages are not loaded (i.e., with \usepackage{...} or equivalent). So I assume `prefix' is a safe bet.
<podiki>cbaines: i haven't found any pattern, often it just doesn't respond for a while so i kill and restart guix build or whatever is trying to get the substitute
<podiki>usually that does the trick, very intermittent but happens often
<cbaines>podiki, if you'd like to investigate, I can give you access to the VM?
<civodul>andreas-e: hey! out of curiosity, what was the reason for removing hdf5@1.12?
<civodul>i'm asking because a colleague of mine is adding it to the guix-hpc channel :-)
<podiki>cbaines: thanks, but I don't think I would know where to start, my webhosting knowledge is pretty basic
<mirai>How can I lose the input labels when there are (origin …) objects among the inputs? <>
<apteryx>wow, 42974 seconds for building a linux kernel on aarch64, and still going:
<ngz>mirai: Use (search-input-file "") instead of relying on input's name?
<andreas-e>civodul: See
<andreas-e>It is outdated, and a specialist told me "Only HDF5 1.14.x (currently, 1.14.2) should be kept."
<andreas-e>And it had no dependents.
<mirai>ngz: so I simply put it as (inputs foo bar (origin …) baz …) ?
<civodul>andreas-e: ah thanks, i hadn't seen this thread
<civodul>in HPC outdated things may still be in use for a while :-)
<civodul>(that said, i'm all for periodic cleanups)
<ngz>mirai: You can also do as in texlive-xpinyin
<ngz>mirai: indeed.
<andreas-e>I wanted to try removing other versions as well, but there are tons of strange (in the sense of: having lots of patches and tweaks) packages depending on hdf5@1.8 and hdf5@1.10, so I will give up.
<andreas-e>civodul: So they are not essentially upwards compatible? In my algebraic world, most of the time one can just replace a library by a later release, sometimes with more or less trivial updates.
<andreas-e>I am not opposed to reverting the commit in case someone needs the package. But the version will be EOL this autumn.
<civodul>andreas-e: i don't know the details, it seems to be needed by simulation software colleagues are working on
<civodul>dunno, i guess we should be more cautious with this kind of packages maybe
<zamfofex>Hello, Guix! 👋 🎉 I noticed there has been some conversation about bringing Hurd substitutes to CI, but it seems it was building it for the incorrect system. Did y’all end up figuring out what was the issue?
<nikolar>Is there a Hurd guix??
<hako>Certificate for expired?
<nikolar>zamfofex: is there an installer or a VM image I can play with
<janneke>zamfofex: we're (slowly) trying to address that, severel steps were already taken...
<janneke>but yeah, atm there's still a problem with hurd substitutes
<janneke>sadly, because quite some packages do not build for the hurd yet, we still need hacks/workarounds
<zamfofex>I see. I really wish I could be able to help more actively somehow.
<janneke>hopefully that will become easier real soon
<indigo-oce>how do I show the available versions of a package?
<janneke>indigo-oce: guix show -- try: guix show guile
<indigo-oce>janneke "show: error: try:: package not found"
<civodul>hako: yeah, and, oops!
<civodul>nckx, cbaines, apteryx: how do we renew on bayfront these days?
<cbaines>do we know if it's the cert being out of date, or just NGinx serving an out of date cert?
<civodul>"certbot renew" doesn't know about it
<civodul>cbaines: the cert
<civodul>i restarted nginx recently for another expired certificate
<civodul>problem is gets special treatment because it the site was initially hosted on berlin
<cbaines>maybe try running /var/lib/certbot/renew-certificates civodul
<janneke>indigo-oce: the command is guix show, so you'll use :guix show <package>
<janneke>you may try:
<janneke>guix show guile
<civodul>ACTION tries
<civodul> is not there either
<indigo-oce>janneke Oh... I have no idea how I missed that... well the version I'm looking for isn't there...
<janneke>indigo-oce: you may alway try --with-version=PACKAGE=VERSION
<janneke>see: guix build --help-transform
<cbaines>civodul, I think the configuration handles, but not
<janneke>of course, YMMV
<cbaines>maybe this was never setup since the website was moved
<civodul>i think we're good now!
<civodul>cbaines: i did "certbot certonly -d"
<civodul>nckx, apteryx: sorry for the noise!
<civodul>why "renew" doesn't know about is a mystery to me
<civodul>we'll have to fix that
<apteryx>guix doesn't build on i686 on cuirass: [530/722] compiling... 46.8% of 361 filesbuilding of `/gnu/store/cgfsl0qcgk0vmirys7iji663nfvrfks7-guix-packages-base.drv' timed out after 3600 seconds of silence
<andreas-e>Concerning guile versions, is there a good reasons we have kept 2.2.4 without any dependents in addition to 2.2.7?
<apteryx>according to
<cbaines>civodul, I don't think is included in the certbot configuration, so it probably needs adding
<janneke>apteryx: i have some hacks for the hurd to split-up building of guix go-files
<janneke>(hurd is even more problematic)
<apteryx>also why is this showing 0 builds:
<janneke>ACTION looks
<apteryx>janneke: seems we could also just bump up the timeout for the packages derivation?
<apteryx>it's currently 1 hour
<janneke>i think there's a memory problem on the hurd
<apteryx>I think it's line 1283 in self.scm
<apteryx>not sure how to affect the max-silent-time of a computed-file derivation?
<cbaines>apteryx, I think max-silent-time is a bit of guix-daemon or store connection configuration, rather than being part of a derivation
<apteryx>right; then I'm not sure where to specify it for (guix self) derivations
<apteryx>what are properties for gexp->derivation?
<cbaines>so you can set the default in the guix-daemon config, or change it on a store connection
<cbaines>e.g. guix build changes it on the store connection if you pass --max-silent-time, e.g. guix build --max-silent-time=60 /gnu/store/cw6pgpr8yx23dgnkgbnzcran51fvl14i-guix-e318b62df.drv
<apteryx>perhaps we should change '(max-silent-time 3600)' in (sysadmin build-machines) on guix-maintenance?
<cbaines>apteryx, I'd maybe also step back a bit. I think the channel instance builds for i686-linux are broken because of memory issues, rather than a lack of time.
<apteryx>ah! so it had hung by the time it timed out?
<apteryx>there are some "out of memory!" messages
<apteryx>janneke: I guess your hurd fix will come in handy for i686 as well :-)
<janneke>right, that's what my hurd patches are for
<janneke>the "26 steps" is prolly somewhat over the top, but 5 steps wasn't enough and i didn't feel like manually making a 10-way split :)
<apteryx>ACTION merges the qt branch to master
<andreas-e>apteryx: Nice, good luck!
<mirai>any idea what's this license? <>
<ngz>mirai: it looks like expat
<nikolar>zamfofex: I haven't seen if you responded, sorry
<apteryx>it feels good to work with more nimble feature branches!
<andreas-e>mirai: I have not seen it before; probably the non-copyleft procedure will be a good fit.
<ngz>adreas-e: why non-copyleft and not fsf-free?
<andreas-e>ngz: I did not know about fsf-free. But according to the documentation: "license that does not fit any of the ones above". I think it does fit non-copyleft.
<janneke>ACTION is confused by git-send-email's --add-header feature
<janneke>this command:
<janneke> git send-email pets/*patch --smtp-pass='***' --add-header="X-Debbugs-Cc:,,"
<janneke>failed to cc maxim, and instead sent mail to cbaines, rekado, nckx, zimoun -- sorry guys...
<ngz>andreas-e: I admit this is confusing. `non-copyleft' is not a license per se.
<janneke>ACTION had never ever such surprises before with git send-email...
<janneke>aaand /me also included debugging code...
<andreas-e>ngz: Well, logically my impression is that non-copyleft applies to all non copyleft licenses without their own entry; then fsf-free would apply to all copyleft licenses without their own entry.
<civodul>apteryx: looks like the comment is now outdated:
<civodul>(great work, those Qt updates!)
<andreas-e>Not a very intuitive naming.
<janneke>apteryx: sent 32bit oom patches
<ngz>andreas-e: Indeed. I certainly have mixed both at some point. I don't think it is not a big mistake, but still..
<andreas-e>Turns out, I have added fsf-free myself more than 10 years ago... And civodul has added non-copyleft some time later.
<ngz>I don't think it is*
<civodul>janneke: the LGTM (minus debugging statements :-)) but i have reservations regarding (guix self)
<civodul>i think we should build in the same way on all platforms
<andreas-e>The texlive page seems to imply that the software is mostly copyleft.
<janneke>civodul: yeah, just saw them too and sent mail about that
<civodul>no worries
<janneke>civodul: aiui, apteryx's problems were with self.scm
<sneek>efraim: Greetings
<civodul>ok, i missed the beginning of the conversation
<janneke>you don't suggest we build 26-ways on every platform?
<civodul>maybe i shouldn't jump in :-)
<roptat>hi guix!
<efraim>sneek: botsnack
<janneke>'twas just an hour ago here, /me included links
<civodul>we could do the 26-chunk split on all platforms yes
<civodul>rather than just on 32-bit platforms
<civodul>a bit of a shame we have to do that at all :-/
<civodul>hey roptat! long time no see! :-)
<janneke>civodul: thanks for the quick feedback
<civodul>so in fact, it's not split in 26 pars
<civodul>(too hot in here)
<civodul>because self.scm already splits in two module closures
<civodul>but clearly that's too coarse
<efraim>can we read the headers and split them every X based on the number of other modules imported?
<civodul>i think what we should do is profile and fix the damn compiler :-)
<civodul>(which i did, but for very small gains)
<efraim>checking with wc -l it looks like tex.scm is closing in on crates-io.scm
<klementievd>hello everyone
<janneke>ACTION sent updated patches for 65456, but with one comment one line too far down, oh well
<andreas-e>janneke: Will this also fix the problem of "guix pull" requiring more than 1GB of memory?
<janneke>andreas-e: ah that could be, does that use guix/self.scm to compile? guess so...
<apteryx>ah, it's unfortunate, I just noticed the new qtbase refers to python 3.10, which inflates its size by 74 MiB
<lilyp>but… why?
<efraim>I might have to work on splitting up crates-io more ...
<mirai>is there some profiler for guile that could be used to find out what/where is it taking so much mem?
<apteryx>lilyp: captured as shebangs in python test runner scripts
<apteryx>eg /gnu/store/0bglkmf20a3l9ni2bbax368dxkfcg14l-qtbase-6.5.2/lib/qt6/libexec/
<apteryx>I'll add a disallowed-reference
<nikolar>Are there working guix hurd VM images or installer
<janneke>nikolar: have you tried the hurd image here?
<nikolar>Oh I somehow missed that completely and it doesn't show up when you serch
<janneke>np; yeah, seems to work still
<janneke>see also
<janneke>(or hurd blog posts on
<nckx>ACTION considers neither janneke nor civodul noise :-)
<nckx>janneke: That's weird though.
<nckx>Did someone add some auto-CC-teams hook?
<podiki>reviewing/pushing for a new submitter; question on commit message, should it just be updating to 1.9.5-0.<commit>? or is there a different way for updating version to commit not tag?
<podiki>nckx: mumi i think runs the teams script? or can be run separately to get the cc's, last I tried wasn't part of a hook though
<janneke>nckx: omg, yes; there's etc/git/gitconfig which has
<janneke>[headercmd] ... etc/teams.scm cc-members-header-cmd
<janneke>and running:
<janneke>etc/teams.scm cc-members-header-cmd pets/v2-0002-self-Build-gnu-packages-.go-in-26-steps.patch
<janneke>just yields all y'all addresses :-)
<janneke>so, it's by design, /me didn't f**k up :)
<nckx>I'm 'core', hence my suspicion.
<janneke>still sad that my manually-added cc to apteryx was stripped
<nckx>Yes, that should be considered a bug (not sure whose).
<janneke>oh well
<nckx>ACTION goes back to dining o/
<janneke>the cc on the cover-letter worked, no no problem :)
<janneke>ejoy nckx
<janneke>and thanxs for the headsup
<podiki>ACTION sees just such commit messages for updates to version-revision.commit
<apteryx>janneke: you manually added a X-Debbugs-CC header?
<apteryx>that's GNU Debbugs fault :-(
<apteryx>was reported and fixed in Debbugs
<janneke>apteryx: i did:
<janneke> git send-email pets/*patch --smtp-pass='***' --add-header="X-Debbugs-Cc:,,"
<apteryx>yes, and then etc/teams.scm would add its own X-Debbugs-CC, and then the GNU Debbugs instance discards all but the last one, IIRC.
<janneke>yeah that makes sense
<apteryx>you may have more luck with 'mumi send-email', which goes to lengths at merging the X-Debbugs-CC
<podiki>mumi send was pretty slick when I tried it, and think a few things were fixed since then too
<apteryx>ACTION still uses patman for the ease of recording the associated bug number and documenting changes between patch series
<janneke>apteryx: civodul just had a few comments on the split-build patches just here, LGTM on the patch (without debugging targets) and always do the 26-way split on the guix/self.scm patch
<janneke>so i'm inclined to push them, wdyt?
<GNUtoo>hi, I've a patchset that was sent in April this year and never reviewed:
<apteryx>janneke: I just wonder if instead of manually defining splits, we could have logic that automates a split? Perhaps future work
<janneke>apteryx: in the makefile, yeah that would be nice
<janneke>ACTION didn't even think of that
<apteryx>we could even use Guile in our Makefiles to do so ;-)
<apteryx>our GNU Make has support for it
<janneke>can we?
<janneke>we use automake...
<janneke>which generates posix-compliment makefiles, afaik
<apteryx>I think you can have canned recipes in a just fine
<janneke>yeah, but we need automake not to complain, and a fall-back for non-guile-enabled or non-gnu make?
<janneke>would be a cool feature tho
<janneke>anyway, /me goes to push the patches
<apteryx>it could be as simple as documenting that GNU Make with Guile support is required for building Guix
<apteryx>which would help its adoption in places such as Debian, where a bug report has been opened for some time without activity ;-)
<janneke>yes, that could work
<apteryx>ACTION is just thinking out loud
<janneke>ACTION will mention some of this when closing the bug
<janneke>it's kind-of silly anyway that we have .go build instructions in *and* in guix/self.scm
<janneke>couldn't make's guile somehove infoke guix/self.scm?
<apteryx>maybe! I'd rather the build system be self-contained too, but I haven't reviewed it all.
<efraim>janneke: based on my past experiences building guix on (32-bit) powerpc the forced garbage collection will help immensely on memory constrained systems
<janneke>efraim: let's hope these hacks work for some of these troubles
<janneke>having some movement in this area may already help
<janneke>jpoiret: headsup, i've rebased and reset hurd-team; and guix should build for the hurd on master!
<janneke>ACTION is trying that now
<vagrantc>guix pull failed on me ...
<vagrantc>ice-9/boot-9.scm:1685:16: In procedure raise-exception:
<vagrantc>error: license:arphic-1999: unbound variable
<vagrantc>oh, maybe it was not guix pull...
<vagrantc>ah, after running guix pull up to db02fcde386892b3a054d64403a4a5bfa1b7fce8 ... guix upgrade fails
<ngz>vagrantc: Hmmm isn't arphic-1999 exported from (guix licenses)?
<vagrantc>ngz: might be one of guile's inscrutibly wrong mismatched paren errors?
<vagrantc>also guix remove ... fails with the same issue
<janneke>hmm, fwiw /me just succeeded in pulling to db02fcde386892b3a054d64403a4a5bfa1b7fce8
<vagrantc>and doing ... things with it?
<mirai>civodul: I'm thinking on melding two G-expressions together to avoid this ugly patch-in-phase snippet for GCC-5, WDYT? <>
<janneke>vagrantc: just running `guix build --system=i586-gnu guix' for now...
<janneke>trying a home reconfigure...
<vagrantc>about the only working thing is "guix describe" for me
<vagrantc>guix gc --verify=contents,repair ?
<janneke>repairing unmatched parens in code ,that would be something
<vagrantc>no idea what is wrong ... maybe something is corrupted in the store ... was my thought
<janneke>ACTION is still building /gnu/store/gs4jbh0c8pd40x94x88mcalyi13b3lcl-guix-1.4.0-10.4dfdd82.drv
<civodul>mirai: i think i'm missing context, could you explain more? :-)
<mirai>civodul: the approach I'm taking with stdc++-docs is that patches are applied to the gcc sources directly in the gcc-5 and gcc-9 packages and autoreconf is only done in libstdc++-doc
<mirai>this works fine for gcc-9 but gcc-5 is fussy in that it requires an older automake version (that is not packaged)
<vagrantc>guix time-machine fails too
<civodul>mirai: the way i'd do it is by patching the generated rather than
<civodul>that way, no need to meddle with Autoconfmake
<mirai>so I can workaround it by putting a conditional phase in makelibstdc++-doc that fires only for gcc-5 OR I do a substitution on gcc-5 sources directly
<mirai>substitution as snippet in gcc-5 looks cleaner IMO
<civodul>all i'm saying is that we should substitute, not
<civodul>(similarly: configure, not
<mirai>civodul: the patches were upstreamed btw so this funky business _shouldn't_ be needed for > GCC 13.2.0
<mirai>The gcc-* packages are still auto<thing> free fyi, all they're getting is either a snippet or a patch to the sources field
<ngz>What would be this license? <> (l. 26) (I lean towards fsf-free)
<civodul>mirai: maybe i should look at your preliminary patch(es) when you think it's ready?
<mirai>sure, all that's left after the gcc business is rewording/squashing
<vagrantc>hrm. time to git bisect the results of guix pull ...
<apteryx>I wonder if #54447 could be caused by the anti-DDoS mechanism in place on berlin's network?
<apteryx>at least some of the cases (which I reported yesterday) seems to have to do with a broken connection
<efraim>I'm seeing the arphic-1999 errors also with guix time-machine
<civodul>is it hard to fix?
<civodul>apteryx: i don't think so; the anti-DoS thing must be on the edges of the network, when receiving incoming connectios
<apteryx>I see
<civodul>anyone working on the arphic-1999 unbound-variable issue?
<vagrantc>i was trying to bisect it ...
<vagrantc>got distracted by other things, like food
<civodul>food is important
<janneke>ACTION did a quick grep and didn't see anything obvious
<civodul>same here
<janneke>also still running guix home reconfigure and guix pull...
<janneke>and now...
<janneke>ACTION -> zZzz
<civodul>most likely the newly updated 'guix' package is broken too
<janneke>blame /me harder...
<civodul>well i don't know, we'll have to check
<civodul>that shouldn't prevent you from sleeping well in any case!
<janneke>thank you, night
<efraim>5898b2e8a3dbf7797e83b39a2783c5b543015725 its the 26 chunks that's the first broken commit, tested with time-machine
<civodul>came to the same conclusion
<efraim>I have some things I'd like to try, but I guess getting guix pull working again first and then trying them would be best
<civodul>i'm reverting and documenting the problem
<efraim>ok. I'll see about playing with it later
<civodul>details in
<civodul>whether the 'guix' package is also broken is another story
<civodul>maybe it's fine
<efraim>guix/self.scm is only used for guix-pull, so the guix package should be fine