IRC channel logs


back to list of logs

<oreloznog> /leave
<oreloznog> /auit
<oreloznog> /quit
<Apteryx>Hello! Any easy way to rebuild all of the emacs packages?
<buenouanq>guix package -u emacs*
<buenouanq>something like that
<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'
<atw>ah, thanks.
<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.e. ("git" "send-email")
<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
<Apteryx>I understand that, eh :)
<Apteryx>thanks for the pointer
<Apteryx>useful one!
<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' ?
<Sleep_Walker>jonsger[m]: guix package should be ready for use
<efraim>ng0_: I'll try that
<efraim>ng0_: looks like its --substitute-urls=url1,url2
<rekado_>efraim: quoted and without comma works for me.
<ng0_>without the " ?
<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 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>guix system guixify config.scm
<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
<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
<ng0>next time I'll do some comparison with a Debian,, and one of my Guix-following-Guix (im other words: no customization) systems and the files there.
***pkill9_ is now known as pkill9
<g_bor>Hello guix!
<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.
<g_bor>commit id is: 9102ce124
***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.
<g_bor>Hello guix!
<pkill9>anybody know of a downloadable ebook guide for guile/scheme
<pkill9>in .epub format
<pkill9>nvm i'll use something from here
<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?
<ajj_>lfam: yes
<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`>right, I'm just using en_US.utf8
<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
<mbakke>I'll try reverting this commit:
<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 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.
<bavier`>sounds like a bug report
<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?
<bavier`>in my experience, no
<lfam>Maybe I'll just rename the static libraries after installing them
<mbakke>Oh, apparently our version of Boost requires CMake 3.8!
<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_>with “-l” nothing new is built.
<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_>the output also differs
<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>now to time 'guix pull'
<efraim>after making berlin the only substitute server
<rekado_>hmm, this is really not normal
<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
<rekado_>I wonder where that comes from.
<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>Hello guix!
<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?
<kmicu>It looks that way pareidolia is no longer available.
<bavier`>pareidolia: there are blog posts tagged with "Talks" and "Research"
<bavier`>maybe what you're looking for
<bavier`>pareidolia: bottom of under "Posts by topic"
<bavier`>oh, "Papers" even
<pareidolia>Gotta love the wayback machine
<pareidolia>It seems every item was moved into a tiny blog entry
<pareidolia>I don't see how that is an improvement :-S
<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
<rekado_>didn’t even check if it exists.
<efraim>is it even current?
<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?
<efraim>Should probably be (which "sh")
<Steap>Not sure whether it's been posted but apparently, Nix is better than Guix at packaging crap^Wcode from NPM
<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>version numbers are never enough
<davexunit>as we well know ;)
<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