<mark_weaver>civodul: okay. any more thoughts on how best to repopulate the missing build outputs on Hydra for core-updates? <mark_weaver>okay, I guess you're resistant to creating another jobset to force these builds, so I'll look into doing it the hard way <civodul>mark_weaver: not really, but i'm still unclear on this <civodul>i'm in "how can this possibly happen" mode <ng0>i must say danny is very busy writing packages <ng0>so manz new additions <ng0>many .. wrong layout <civodul>mark_weaver: seriously, i'd think many .drv file names have changed, and keep changing <mark_weaver>civodul: well, I guess that in typical cases, the old .drv file stays around long enough for the outputs to be built, and after that it usually doesn't matter. <mark_weaver>but losing our entire /gnu/store is a different case <civodul>yes, but for instance the (guix download) change i pushed triggered a change in all the .drv file names <civodul>so Hydra should notice that and use the new .drv files <mark_weaver>it seems to me that if an existing build exists from the same jobset and with the same output file names, the build is considered "cached" and left alone. <mark_weaver>I've often noticed that after fixing a download URL, I still need to manually ask hydra to download the new URL. <mark_weaver>presumably because it's still trying to use the old .drv file with the old URL <mark_weaver>civodul: the relevant code is 'checkBuild' in /usr/local/libexec/hydra/lib/Hydra/Helper/AddBuilds.pm <mark_weaver>I'll be very happy when I'll looking at scheme code here instead of perl <mark_weaver>anyway, yeah, if one output name matches with the previous build, it is entirely left alone. <civodul>oh yeah, those "already scheduled/built as build XXX" messages <mark_weaver>as an optimization, we should avoid updating drvpath if it's already set correctly <mark_weaver>heh, okay. well, how to update the 'drvpath' columns correctly, then? <civodul>wait, i guess i misunderstood what you meant <mark_weaver>the problem I'm trying to solve is that many builds that postgresql records as successes no longer have their outputs in /gnu/store <mark_weaver>the easy solution is to create a new jobset that builds core-updates, so it will create fresh builds for all jobs and make they're all built <civodul>that was a mixture of resistance and ignorance :-) <mark_weaver>no need to apologize. it's good to make sure the job is being done right, or close to right :) ***Digitteknohippie is now known as Digit
<nee`>How should I handle games that install their binaries to /games instead of /bin? ***tschwing_ is now known as tschwinge
***the_ktosiek is now known as ktosiek
<Sleep_Walker>can I somehow set GUIX_PACKAGE_PATH from system configuration? <rekado>Germany offers money for the development of free software <rekado>any project for civic tech, data literacy, data security, or software infrastructure are eligible <rekado>a creative applicant could probably make Guix fit into one of these categories <civodul>Sleep_Walker: you could arrange so that your system defines GUIX_PACKAGE_PATH in /etc/environment, would that help? <civodul>rekado: the English URL doesn't seem to work though <Sleep_Walker>civodul: I can alter /etc/environment from system configuration file? <civodul>Sleep_Walker: yes, grep for session-environment-service <civodul>unfortunately it's currently undocumented and inconvenient to use <civodul>but you can email bug-guix so we have an obligation to do something about it ;-) <rekado>BTW: I'm back in Berlin but before I can get back to reviewing patches I need to process a lot of email. If any of you think I should take a look at some patches sooner, please just send me a pointer. ***tschwing_ is now known as tschwinge
<civodul>there's a big Perl patch series by Danny that's pending, but nothing big apart from it, i think ***marxistvegan is now known as marxistvegan_
<ng0>is this a new web site? I only used hardened gentoo so far wit h PaX kernel etc.. <davexunit>civodul: what are the chances of linux-libre being reproducible? <ng0>ah, this is a new development <davexunit>and by different I mean "using a bunch of patches that aren't upstream" <ng0>isn't every hardened kernel in OS' which offer one customized? ***marxistvegan_ is now known as marxistvegan
<wingo>i guess we should be able to import packages from flatpak json files or something <ng0>what happened to the CCL and SBCL updates? from the messages I have it looks like it was forgotten in february. I'm sending out reminder emails on the forgotten threads, but my archive might be wrong about this one. <ng0>okay, maybe a bad time for questions. I'll just send an email on this one too <ng0>i'm not through, but I've only got 2600 messages to go through now, 3/4 done <ng0>i think i can mark my old gnunet threads as done when someone reviews the new one. <ng0>Leo is lfam here, right? <ng0>sneek: later tell lfam: do you know what the state of gparted is roel was working on, end of may? Otherwise I'll bump the thread. <wingo>civodul: lemme paste a json file somewhere... <wingo>somehow it's possible to build a flatpak from that json <ng0>sneek: later tell lfam: for reference, this is the threadname: May 28 [6/6] Roel Janssen, ... [PATCH] gnu: Add gparted. <wingo>$ flatpak install gnome org.gnome.Sdk 3.20 <wingo>$ flatpak-builder --ccache --repo=repo app com.igalia.Gobby.json <wingo>$ flatpak build-bundle repo Gobby.flatpak com.igalia.Gobby 0.4 <ng0>have i now added a second note or overwritten the first one? <wingo>we should be able to frob that into a package somehow <civodul>though maybe(?) there are more Guix packages than Flatpak apps? <wingo>apparently this "bundle" feature is somewhat new <civodul>i'm wondering about the cost/benefit tradeoff <wingo>i tried to package this version of gobby for guix in the past <davexunit>flatpak seems to be taking off more than guix, though <wingo>and failed, maybe i didn't have the right versions of the last 3 things <wingo>surely in this case the right thing to do is just for me to try again ;) <civodul>davexunit: sure, the cost/benefit tradeoff may be different a week from now <davexunit>flatpak is getting pushed by red hat and others <wingo>but maybe an importer could be useful for other folks, dunno <wingo>i literally lug around an old laptop with debian when i need to run this software ;) <civodul>at least it shouldn't be harder to package with Guix than with Flatpak <wingo>my guix machine is a lenovo x1 laptop <wingo>well, my desktop runs nixos and userspace guix, the laptop is guixsd <wingo>i'll do guixsd on the desktop when i get a new one ;) <myglc2>I've been using gnus/emacs/gmane to read/write guix mail lists but the future of gmane seems uncertain ... <myglc2>So... I was wondering how others read the guix mail lists via emacs w/o using gmane <ng0>you can download the mbox archives <ng0>or subscribe to the lists <wgreenhouse>but yes, I am considering downloading mbox archives of guix, emacs, etc. lists and importing into my maildirs <myglc2>wgreenhouse: yes I read that but over the weekend gmane search has not worked and right now the gmane server is down and I realize I am crippled w/o gmane, so I should have a backup stratedy <ng0>mbox to maildir should be as easy as nnml to maildir <myglc2>ng0: do you use any tools for mbox archives? <ng0>i fear to sort duplicates once more, which is why i did not do anything with old archives. <wgreenhouse>ng0: yeah, it's pretty easy, you can also use standalone "mb2md" tool, or procmail <ng0>i don't use mbox. i only needed nnml to maildir conversion so far <ng0>which i've done with perl <wgreenhouse>myglc2: whenever I have dealt with them before, I have used mb2md or procmail to blow them up into files in a maildir folder, and then used gnus nnmaildir+nnir-search-engine notmuch to view/search them <wgreenhouse>afaik there are currently more search options for one-file-per-message (like MH or maildir) than one-file-per-mailbox (mbox) <ng0>well notmuch can also use mbox i think <myglc2>ARG! and there go all my gnus marks. It would really be nice if mailman supported NNTP, I wonder why it doesn't <ng0>aren't the guix specific groups not synced to other servers not in the gmane.org domain? <wgreenhouse>ng0: I don't think so. some usenet servers carry the gnu.* hierarchy but it looks like guix is not part of that. <wgreenhouse>at least not from what I can see on eternal-september <myglc2>Does anyone know a reason why mailman doesn't support NNTP <wgreenhouse>myglc2: mailman doesn't even [directly] support smtp, AIUI. <wgreenhouse>also, the usual reason would be "nobody implemented it" <wgreenhouse>myglc2: btw, if you use gnus's scoring features and make a global score file, it should pick up on what you are interested in even if you subscribe to guix lists in a totally new way <myglc2>wgreenhouse: haven't adanced to scoring yet but I believe you. <ng0>with mailman 3 it might be possible to extend it, who knows. <rekado>interesting. I should try gnus again. I'd like to use it with mu, because the search is so fast, and with a local maildir. <myglc2>rekado: mu is not integrated with gnus in that it has it's own UI instead of using the gnux nnir search interface. <myglc2>An alternative is notmuch, which does support nnir and also uses xapian and maildir, so if you want gnus centric solution you might want to take a look at that. <myglc2>I have tried both and the performance is the same. <ng0>it's as if one person is running it. or at least the commits <rekado>myglc2: I've been using mu4e for some years. <ng0>what do you like with mu4e thatt notmuch didn't have? <ng0>i just switched to notmuch <rekado>with notmuch the database is precious. With "mu" on the other hand you can regenerate the database without losing anything. <rekado>myglc2: thanks for the pointer to nnir <ng0>mu4e and mu could be more to my liking.. I did not like Gnus because of the incredible flexibility. notmuch, i just run the tagging in my getmail script <ng0>my old Gnus configuration is also leaking into notmuch, so the fake MIME of inline patch default is not working, inline patches are difficult for me. is this easier to address with mu4e? <rekado>what is the problem with inline patches? <ng0>i can not safe them when the fake MIME of notmuch fails <rekado>I usually just run "git am" on the mail buffer <ng0>it's a specific problem for me <myglc2>rekado: Not sure it is a good pointer b/c the gnus/nnir search a big downgrade from mu4e <rekado>well, I find mu4e to be a little too restrictive. Search is great, but I often find that I could benefit from some of the many gnus features. <rekado>I suppose I could extend mu4e itself with Guile, but I don't really want to start yet another project when gnus exists. <ng0>i will try mu4e with a copy of my mail <ng0>notmuch emacs interface does what i need minus some liberties i had with Gnus, so maybe mu4e has some features which are better. <ng0>i don't want mail, i want what mail does not do, good organization <rekado>in my experience mu4e is somewhat less powerful than notmuch, but overall "nicer". <rekado>I haven't really found what I'm looking for. <rekado>mu4e's handling of threads is poor. <ng0>pybitmessage also fails at that point, no threaded view, but at least lists and addresses etc are separated. order is also hard. <rekado>no way to shrink or expand them. <ng0>that's what i like about nm <rekado>you can show related emails or just matching emails, but nothing in between, per-thread. <ng0>my thread catching was perfect with Gnus <ng0>not with the default, but what I configured <myglc2>rekado: if you implemented gnus nnir I/V for mu maybe you would have the best of both? <kyamashita>How can I access a package's version while inside its modify-phases procedure? <myglc2>wgreenhouse: the mb2md + nnmaildir+nnir-search-engine notmuch sounds good to me <kyamashita>I'm attempting to remove a "magic number" from red-eclipse's definition to make it easier to maintain. <davexunit>`(modify-phases %standard-phases (add-after 'unpack 'foo (lambda _ (display ,version) (newline)))) <davexunit>so the expression you generate has the version number baked in <davexunit>since the 'package' form does this automagically <ng0>the name of a package has a captitalized part, do i write it all small still? <ng0>does guix know about LE authority? I have a download which pulls from a server with LE cert <ng0>wget does not know about it, but does hydra/guix know? <ng0>guix download succeeded, is that test enough? <pongtong>did someone receive this from my build version on guix? <ng0>one thing i need to fix though: what socks library do i use? guix package -s socks gave me the torsocks one (not useful) and this ghc one <wgreenhouse>rekado: notmuch does interface with maildir flags for things that those cover (e.g. read/flagged/replied) <ng0>"description: This library provides a SOCKS proxy (version 5) implementation." this makes me assume i can use this for anything which needs a socks lib <wgreenhouse>rekado: since I'm using it as a search enhancement to gnus, though, I don't really touch notmuch's flags; my organization of maildirs is more foldery <ng0>eww. isn't there a socks library with a smaller size? <ng0>i disable it for now, socks is optional <sapientech>hi guys, installed guix.el through the git hacking tricks method. I am able to find the guix commands, but for each one, they end in a: No prompt found! error <davexunit>hmm, I get random corrupt archives when using 'guix publish --compress' <wgreenhouse>sapientech: does your guix profile directory appear in C-h v exec-path in emacs? <sapientech>wgreenhouse: yes it does, i am experimenting with geiser, guile load path, since that seems to be the problem <sapientech>i am adding my git branch to it, and it doesn't get the error, but now its stuck on: starting REPL... <sapientech>i think thats because its recompiling the newer ccache <ng0>is it somewhere documented why exactly we can't have for example xfs in addition to ext4 at the moment for GuixSD? <ng0>what's failing, what's needed? <sapientech>hmm, emacs is still frozen waiting for the guix REPL to start... <rekado>sapientech: I suggest to first run “make” in your git checkout <sapientech>rekado: i did run ./bootstrap, ./configure, and make check, make after that then? <sapientech>we might want to update the guix info manual. it does not mention calling make after make check <rekado>hmm, doesn’t “make check” depend on a full build? <mark_weaver>civodul: 4 consecutive test failures of shepherd on armhf, always in the respawn tests <civodul>i don't think i can fix it in due time, but OTOH it's not a blocker, esp. on non-GuixSD platforms <mark_weaver>I agree it's not a blocker, but elogind depends on shepherd, and several things depend on elogind <mark_weaver>not that it needs to be your job to fix it, of course :) <civodul>i'm afraid it's a problem with Guile's async signal delivery <civodul>mark_weaver: i think core-updates can be merged now; WDYT? <mark_weaver>redhill is causing a lot of aborted builds on armhf now, although I'm a bit puzzled looking at the logs. the load of redhill is successfully queried, but then we get lsh: Connect failed, (errno = 0) <civodul>so i guess i'll hit the merge button! ***GNUcifer is now known as cehteh