<Apteryx>Hello! Any easy way to rebuild all of the emacs packages? <Apteryx>this would rebuild those installed; I want to rebuild all of them. I had come up with a CLI way before, but I'm now thinking to use fold-packages in Guile directly <Apteryx>with some is-emacs-package? predicate (that already exists somewhere) <atw>How do people send patch series? I just sent one but I ended up manually sending an email for each patch. Surely there's a better way? <bavier>atw: 'git send-mail' generally works pretty well <atw>bavier: what package provides that? git's telling me that send-email is not a command <atw>also, is there a way to do send-email with magit? <bavier>atw: the git package's send-email output <bavier>'guix package -i git:send-email' <Apteryx>I usually just send all the patches as attachments in a single mail. <Apteryx>I haven't bothered setuping SMTP outside of emacs. <atw>I have a manifest like (map specification->package '(... "git:send-email")) but I'm getting "guix package: error: git:send-email: unknown package". Am I doing something wrong? <bavier>atw: as a specification, the output is a separate string <bavier>I think specification->package expects a pair in that case <atw>I couldn't make that work, but I found specification->package+output and that seems to do the trick. <Apteryx>this is my CLI way to build all the emacs packages: ./pre-inst-env guix build --fallback $(guix package -s "" | recsel -p name -e 'name ~ "^emacs-.*$"' | sed 's/name: //g'). There must be better ;) <atw>Apteryx: there's an example that's maybe similar to what you're doing in the manual, section 7.2 ("Running Guix Before It Is Installed") <atw>and re SMTP: me neither. I have a very emacs-centric workflow :P <mbakke>Apteryx: You might find `guix package -A ^emacs` helpful :) <jpt4>Has anyone been successful in running an X11 server without using the system configuration level %desktop-services? <jpt4>I.e. installing xorg-server, xinit, dbus, writing .xinitrc, etc? <efraim>Apteryx: 'guix build --fallback $(guix package -A emacs- | cut -f1)' should work <efraim>for guix on a foreign distro, how do I add multiple substitute urls? --substitute-urls='url1,url2' it doesn't seem to like <ng0_>isn't it --substitute-urls='url1 url2' ? <efraim>ng0_: looks like its --substitute-urls=url1,url2 <rekado_>efraim: quoted and without comma works for me. <ng0_>yeah, that's why I suggested it.. hm <efraim>this is on my aarch64 build slave, but i suspect I should run badblocks on the external hdd, but its 2TB over usb2 and could take days so i'm trying to avoid it <efraim>i checked the aarch64 build machine I got as fosdem, the PSU is dead, i'll try pulling one from another box I have soonish™ <CharlieBrown>Anybody got some really r/unixporn-worthy screenshots of GNOME on GuixSD? <rekado_>efraim: the *replacement* PSU is dead as well…? Or just the one that came with it? <ng0_>I'll soon write up an updated GuixSD on DigitalOcean short guide. I wanted to wait until I can sign up as community writer, but whatever.. I'll also try https://www.netcup.eu/ because they have better prices/specs for offloading builds etc <efraim>rekado_: the one that came with it <efraim>I was going to try the aarch64 servers on scaleway since theyre €3/month <ng0_>imo we could almost integrate the Debian->GuixSD process into Guix. There's a last step that's uncertain, but the rest is pretty straightforward <ng0>DigitalOcean also applies to 1984 with tiny changes and some other ISPs. For IN-Berlin I have the theoretic layout, in practice I never made a second attempt. <rekado_>ng0: what does “integrate the […] process” mean? <ng0>it's a few steps from full Debian to GuixSD. Those can be automated to some degree <rekado_>that I understand. But how and where? <ng0>where: I thought about writing a script as I've done it so many times that it gets annoying to repeat. But it could also be a subcommand or option in 'guix system'. <efraim>rm -rf /{bin,lib,etc,var,usr} and guix system init <rekado_>the problem with that is that a reboot won’t work any more. <ng0>my experience says otherwise.. but okay <rekado_>I always deleted bin and etc after system init, in the recovery REPL <rekado_>I’ve done this about 25 times for the build nodes of berlin.guixsd.org <efraim>I never knew how much etc to remove <ng0>that's probably the last remaining step I was talking about.. where I'm hacking around with move and copy <rekado_>it’s also an important step because GuixSD won’t boot if there are files that it tries to create on boot. <ng0>so far after the usual steps and a first 'reconfigure' that fails, I run: mv /etc /old-etc; mkdir /etc; cp /old-etc/{passwd,group,shadow,gshadow,mtab} /etc/; cp -r /old-etc/guix /etc/ and then reconfigure again ***pkill9_ is now known as pkill9
<g_bor>I've just run make check on a core-updates checkout, and I have four tests failing. <g_bor>Three in guix graph, with a message unbound variable ~S, and one in guix package, procedure string-take expects integer as second argument, and gets #f. ***kensington_ is now known as kensington
<g_bor>it seems, that the sqlite-autoconf tarball is missing. <g_bor>I'm trying to get to the bottom of this java-jeromq test failure, but this derivation is needed. <pkill9>anybody know of a downloadable ebook guide for guile/scheme <ajj_>Has anyone installed latex on GuixSD? I get an error complaining about locales when trying to compile a file. <mbakke>ajj_: I've used lualatex with GuixSD. <ajj_>I would really like to get latex work and I'm pretty much clueless on what I should do <bavier`>ajj_: I've used pdflatex for quite a while without issue <bavier`>but my tex files don't do anything very sophisticated <ajj_>bavier: What packages did you install? <lfam>ajj_: Sorry to jump in, but does your config.scm have a locales section? <lfam>And which locale does it use? :) <mbakke>I wonder why newer Ceph fails with `ld: cannot find -lBoost::thread`. <lfam>ajj_: It's hard to say without seeing the error message, but I'd guess that, by default, latex is trying to use the en_US.utf8 locale, or something like that. <lfam>It's possible that bavier` is using that locale, or is using pdflatex on another distro that handles locales differently <lfam>So, we should figure out how to make latex play with locales besides en_US <lfam>mbakke: Either our boost doesn't export that, or Ceph's build system didn't account for our unusual locations <bavier`>mbakke: that's a weird boost library name <bavier`>usually it'd be named something like "libboost_thread" <lfam>It looks like Perl conventions to me <bavier`>mbakke: I wonder if our boost package is missing some cmake config files? <mbakke>bavier`: I suspect actually CMake might need to be patched (it comes with a FindBoost.cmake). <mbakke>Ugh, apparently the backtick breaks riot.im tab completion :P <bavier`>mbakke: possibly, but I think target information is usually loaded from a <package>.cmake file <mbakke>Ah, ceph now uses a "BuildBoost.cmake". <mbakke>There are warnings like these during "configure": Target "ceph_test_cls_rgw_meta" links to target "Boost::regex" but the target was not found. <mbakke>So BuildBoost.cmake is only used when SYSTEM_BOOST is disabled. find_package(Boost ...) in CMakeLists.txt works, yet it's not set up correctly at link time. Ugh. <mbakke>It's been like this for almost a year, so I think it's Guix-specific. But will try to fix it :) <lfam>I'm looking at Google's Brotli compression implementation. Since 1.0.0, they install the static libraries with a 'static' suffix like libbrotlidec-static.a, which the application I'm packaging fails to find. It's looking for libbrotlidec.a, which was created by older versions of the Brotli build tools <lfam>Is this a common convention? <lfam>Maybe I'll just rename the static libraries after installing them <efraim>well now we actually want to update it in staging <efraim>we could downgrade boost, it also often seems to cause problems <lfam>I'd do it even before staging, since it will probably be hard enough as its own change <efraim>i tested my gccgo package again, this time gccgo -> go(-bootstrap-1.9) -> go-1.9 and it failed the same way as gccgo -> go-1.9 <efraim>so it looks like aarch64 really does need the gold linker <mbakke>Actually, the version of Ceph released yesterday requires boost 1.66. So now I'm packaging that and CMake 3.11.0-rc1. <lfam>Speaking of Go, I have a working package for Go 1.10, but the update will not be so simple because the go-build-system will need to change. I think I'll add it as a new package but keep go-1.9 the "default" Go for now. But I haven't had time to do this yet <lfam>Go 1.10 handles build artifact caching in a functional way (davexunit's 11th rule ;) ), but our build system isn't set up right, so none of the compiled objects are re-used :( <mbakke>Also, boost has ~1400 dependents, which is a bit much even for 'staging'. <lfam>Yes, it's quite a bit. But does it mean that our Boost is subtly broken now? <rekado_>I’m confused about the difference between “guix environment -l guix.scm” and “guix environment --ad-hoc a b c” <rekado_>but with ad-hoc a dependency is built from source. <mbakke>lfam: Not really, the current dependents seem to handle it fine. This problem is CMake specific. <rekado_>this is significant to me because “-l” yields an environment without the grafted glibc (so things crash) <rekado_>but with “ad-hoc” things seem to be fine. <mbakke>The version of Ceph in Guix also uses CMake, but didn't have a problem until it tried to use the "native" CMake Boost helpers. <lfam>Okay, I admit I don't understand. I trust your judgement :) <efraim>with 3 added lines the guix install script worked on scaleway <efraim>although the 0.14.0 release doesn't have berlin in the substitute-urls <efraim>after making berlin the only substitute server <rekado_>guix environment on different nodes gives me different behaviours <rekado_>all of them use the very same version of guix over nfs <rekado_>what’s odd is that “guix environment -l” appears to pull in an ungrafted glibc <efraim>i'm guessing that for armv7 'armv7*' should catch anything, but I don't have any armv7 boards easily accessable to test <mbakke>Of course CMake 3.11.0-rc1 fails to build :) <mbakke>Issue submitted upstream, will continue tomorrow. <mbakke>Maybe I'll just pull the FindBoost parts into our CMake package. <lfam>Assuming the currently running evaluation of the master branch goes well, I'll probably start an evaluation of the staging branch tomorrow. I'll also mention this on the mailing list <lfam>Let me know if I should wait :) <g_bor>I had test failures this morning building core-updates. 3 tests in graph and one in packages failed. <g_bor>Do you know anything about this? <lfam>g_bor: core-updates is not really expected to be buildable currently. Probably in a couple months we will start working on it again <lfam>For now, we are just collecting patches to update core packages there <vagrantc>ACTION takes greater interest in guix during cold weather <pareidolia>There used to be a page on the Guix site listing papers and presentations. Has it been removed? <bavier`>pareidolia: there are blog posts tagged with "Talks" and "Research" <bavier`>pareidolia: bottom of gnu.org/s/guix/blog under "Posts by topic" <pareidolia>It seems every item was moved into a tiny blog entry <rekado_>It just occurred to me that a core-updates-next branch was mentioned a couple of times in recent weeks. <rekado_>when I merged core-updates into master I did not do anything with core-updates-next <lfam>I had a local core-updates-next branch, but I've pushed most of it to the new core-updates branch <lfam>There is no central core-updates-branch <lfam>I mean, no central core-updates-next branch <lfam>I think it's best to keep those branches local, otherwise the workflow gets messy because we don't rebase on Savannah <rekado_>I just worried I may have forgotten something <lfam>It was mentioned but never acted upon ***xetver1 is now known as xetver
<bavier`>daemon download output with max-jobs>1 looks bad <efraim>it also looks bad when its downloading while building something else <bavier`>idk if that would be within scope for the proposed GSOC project? <efraim>i'd love a bar for each with [====> ] for each download, and under the bottom of build output <efraim>then again I'd also love multiple concurrent downloads of source, independant of max-jobs, although patching/tarring the source would have to take a job slot <lfam>Geez... these Hydra evaluations do take approximately forever, don't they? <lfam>Oh yeah, it should be, efraim <lfam>Steap: The Nix NPM packaging work is interesting and useful, but reflects some of the differences in values between our projects. Basically, they took the graph of NPM packages and picked a point below which they don't try to build from source, if I understand it correctly. <lfam>It's a very pragmatic decision because it's probably not possible to build all those packages from source <lfam>I mean, I think joeyh's praise of Nix is valid. If you want a distro that offers packages from NPM, Nix is an option, and Debian and Guix are not. <lfam>I remember when Nix presented their NPM work at Fosdem 2017, the room had lots of Guix people. We were all dying to know how they'd managed it :) <Steap>yeah I can see why it'd be a pain <davexunit>I refuse to believe that the only way to accomplish the goal is to give up and just package garbage <Steap>teh concerns about Debian seem kind of valid (not being able to package multiple versions of X sucks) <Steap>but saying "Guix is bad because they do not want to give up compiling", well.. <davexunit>maybe we just have to wait for everyone to get sick of node ;) <lfam>Maybe there are other ways to accomplish the goal, but they chose the way that worked for them with their resources and values. And I don't look down on them for it. <Steap>oh, that's not what I meant either :) <davexunit>I don't look down on them, but it's basically saying "actually this whole nix thing doesn't work very well" <lfam>I don't think joeyh is putting us down. The questions of how values affect tools affect the success of distributions is very interesting and not explored deeply <Steap>lfam: I think he fails to see that specifying exact dependencies (ie, libfoo == 1.2.3), is a terrible idea <lfam>Like, in my opinion, many of Debian's packaging policies are codified from learned experience of the packaging model they use <lfam>If the model changes, they can change some of their policies <Steap>we should be able to say "we need >= X.Y.Z, because the feature we need was introduced in X.Y.Z" <davexunit>is it libfoo 1.2.3 compiled with libbar or without it? etc. <lfam>In the world of Go, they don't even use version numbers <lfam>Luckily, Guix is flexible enough to permit all kinds of development models :O