IRC channel logs

2020-06-04.log

back to list of logs

<sirmacik>yup :/
<marusich>mbakke, nckx, so we have a VM when we need it, from OSUOSL, but no actualy hardware at this time, right? For some reason I thought we had a machine, but I guess I was mistaken.
<nckx>Not ‘Guix’, no.
<marusich>I mean, I know lle-bout / dftxbs3e has a machine. They're helping quite a lot with the porting, and they've set me up with access to test stuff if I need to. I'm getting a POWER9 machine of my own soon, too.
<marusich>OK, that's good to know.
<dftxbs3e>nckx, marusich: we have a VM from OSUOSL I encouraged nckx to get, that's all
<dftxbs3e>The rest is personal hardware
<dftxbs3e>The VM from OSUOSL has a little endian operating system on it
<dftxbs3e>And I'm not sure nested virtualization is enabled
<dftxbs3e>OTOH my VM is big endian and has nested virtualization enabled, so you can make a little endian VM nested inside it if you want to
<raghavgururajan>cbaines: You around?
<marusich>I'm sure that will be useful when we get to little endian stuff
<cbaines>raghavgururajan, yeah, I was wonderinng earlier if you'd managed to access bayfront
<dftxbs3e>marusich, it certainly will to extend the official cuirass instance with powerpc64le-linux
<dftxbs3e>Cuirass will use any system specified for offloading, correct?
<marusich>I'm not sure; I haven't set up Cuirass before but am eager to try
***dingenskirchen1 is now known as dingenskirchen
<raghavgururajan>sneek, later tell cbaines: I still get the same error while accessing bayfront.
<sneek>Will do.
<lle-bout>marusich, things are still building!
<lle-bout>grub had failing tests because qemu on ppc64 in nested virutalization doesnt support some feature
<lle-bout>fw_cfg it's called
<lle-bout>hmm seems like cuirass doesnt support ipv6 listen
<lle-bout>marusich, so I ran cuirass without a VM, just manually through the command line in a screen window
<lle-bout>marusich, cd /root/cuirass-data && cuirass -D cuirass.sqlite --web -p 80 --listen=localhost -I 5 --threads=56
<lle-bout>Cuirass is not really documented and I'm not the best at reading GNU Guile's Scheme - can't figure out how to actually run evaluations, I defined a specfile already, now what?
<lle-bout>well I found that the git repo had a documentation in latex, so I compiled Cuirass manually to see it, couldnt find it otherwise, probably because I use GNU Guix *on top* of Gentoo
<lle-bout>well it didnt help so much.. will try fiddling with examples again
<lle-bout>I can add specifications but they do not evaluate! And when I use --one-shot it adds an evaluation but that one has zero builds and stays that way forever
<lle-bout>It's unclear how you actually make Cuirass work. I wish to build all packages from a set of specified GNU Guix git+branch continuously
<lle-bout>* for a specific platform
<mroh>good morning guix!
<marusich>good morning
<icefox>export GUIX_BUILD_OPTIONS="--no-substitutes -c 2 -L /foo/bar"
<icefox>sorry, paste error
<icefox>ice-9/boot-9.scm:1669:16: In procedure raise-exception:
<icefox>Unrecognized keyword: #:use-substitutes?
<icefox>I am using emacs-guix. When I use it to install a package, I get this error. Does emacs-guix need some additional configuration?
<civodul>Hello Guix!
<janneke>hello civodul!
<civodul>hey janneke!
***apteryx_ is now known as apteryx
<marusich>Amazing. I finally re-built /gnu/store/pygln3lr6qbxcps3kmn3w4bc0d0nlpd3-gcc-stripped-tarball-5.5.0.drv after doing a "guix gc" of as much as possible, including gcc-final, and it *still* built exactly the same bits that it did before, on my machine, last time.
<marusich>cool that it's reproducible on my machine, not cool that it's different for every individual who has built it on their own machines.
<marusich>(This is for https://debbugs.gnu.org/cgi/bugreport.cgi?bug=41669 )
<marusich>civodul, janneke do you know if any of the prior bootstrap binaries were actually reproducible? In the sense that, two identical versions were built on two different machines without sharing any build artifacts (e.g., via substitutes).
<marusich>I am wondering if getting the powerpc64-linux bootstrap binaries 100% reproducible is a requirement for adding them.
<mroh>icefox: this is a known bug, see https://gitlab.com/emacs-guix/emacs-guix/-/issues/18
<marusich>I searched guix-devel but found no explicit mention of such reproducibility
<janneke>marusich: the binaries that i created were always reproducible, but i created gcc only for hurd; i was not involved in a gcc bootstrap binary for x86 (those were pretty old)
<marusich>When you say "reproducible," do you mean somebody or yourself built them from scratch on another machine, or do you mean that you were able to build them multiple times, bit-for-bit reproducibly, on the same machine (re-using the same compiler to build them the second time)
<marusich>?
<marusich>Because my binaries are also bit-for-bit reproducible right now. If I build it a second time, on my machine.
<janneke>(we need better terms, or /me needs to formulate better)
<marusich>But two other people building it on their own machines have produced 2 different results.
<marusich>it's pretty weird
<janneke>marusich: the binaries were re-created by someone else, on another machine, and were the same
<marusich>But do you know if that preson actually rebuilt their entire toolchain?
<marusich>Or is it possible they ended up using substitutes that you also used, to build the toolchain that built the binaries?
<janneke>but...no indeed
<civodul>marusich: janneke is talking about the "reduced binary seeds" that have been in use for x86 for a couple of years
<janneke>so, it /could/ be that for hurd, the other person and myself both injected some non-reproducible input
<civodul>whereas you're looking at the big binaries
<marusich>Ah, OK. yes, i'm talking about the big binries.
<janneke>civodul: well, yes -- those were verified by mweaver
<civodul>yes
<janneke>but...we also verified the hurd bootstrap binaries, recently -- right?
<civodul>but i'm not sure about the "big" binaries
<civodul>janneke: oh right
<civodul>so that should be similar
<civodul>hmm
<janneke>but...i don't think anyone did a --no-substitutes build!
<janneke>that could have been a mistake
<civodul>marusich: in the bug report, you mention 4 people getting different results
<marusich>4 people, 3 on the list and me
<marusich>I misspoke earlier in this chat
<civodul>marusich: could you retrieve some of the nars and diff them?
<marusich>the number of people is 4
<civodul>ok
<marusich>I do have the build outputs
<marusich>I am running diffoscope but it's huge output, like 250 MB of output
<marusich>i am trying to pare it down. At the moment, there seems like a lof of stuff like this...
<civodul>you can start with "diff -r --no-dereference"
<civodul>and then diffoscope files selectively
<marusich> https://paste.debian.net/1150058/
<marusich>ok, that's good to know. I will see if I can make sense of it.
<marusich>I am also rather surprised that after I GC'd the output of gcc-final - along with everything else I could GC - and then rebuilt everything (which took like a day), I *still* got identical output.
<marusich>(built with --no-substitutes)
<marusich>(identical output means, identical to what i built previously, not identical to the other people's output)
<marusich>Anyway it's super late here, and the build just finishe.d I'll investigate more tomorrow.
<marusich>It is a mystery. I hope we can figure it out, because it'd be really great to verify that multiple people can cross-compile the same powerpc64-linux binaries.
<civodul>so it looks like a different offset and ordering of the C++ symbols
<marusich>meanwhile, lle-bout is courageously compiling cuirass and other things with the binaries we did built, on a branch in a non-official repo
<civodul>weird
<marusich>yeah
<marusich>seems consistent, in the thousands of lines I glanced at
<marusich>no idea what would cause it, though
<civodul>bah
<civodul>would be nice to see if this affects other architectures
<marusich>i still find it hard to believe that the binaries are reproducible *on my machine* but differ only on *another person's machine*
<marusich>that is so weird
<civodul>that happens with things that are due to kernel differences (like recording uname(2) output), or things that depend on file system ordering (unsorted readdir calls)
<civodul>and probably other things as well, but that's what comes to mind
<marusich>hmmm, well we probably are using different kernels, since we made no attempt to coordinate those things.
<marusich>those are some potential factors to test for, i guess.
<civodul>so $(wildcard *.o) in a makefile for instance
<civodul>i think the latest make reverted to unsorted glob pattern expansion, no?
<marusich>These are all good ideas. It isn't clear where it's coming from, so I'll have to dig deeper. For now I'm going to go zzz
<marusich>Have a nice day!
<civodul>actually it's the opposite (fortunately): https://git.savannah.gnu.org/cgit/make.git/tree/NEWS#n110
<bdju>anyone know how to change font priority on guix? I'm trying to get my emoji to all show up in color
<janneke>phew!
*janneke still always sees boxes when nckx emoji's
<bdju>it apparently is a big mess to do with fallback fonts
<bdju>because most fonts will be missing the emoji symbols so then a fallback has to supply them, and there's an order of priority... it's a bit of a headache
<bdju>I had color emoji working at least partially in the past without trying
<janneke>ascii emoji's work great! :-D
<PurpleSym>Is guile’s statprof module a reliable way for profiling guix?
<civodul>PurpleSym: yes
<PurpleSym>Ok. I figured out that `guix environment --ad-hoc` can be slow for some packages (like r-learnr), but not for others (guix).
<bdju>is there a way to search the whole guix manual at once to quickly find something without knowing what section to go under? I'm always struggling to find stuff...
<civodul>PurpleSym: ah, that's interesting; could you send the details to bug-guix?
<civodul>in that case it's often more useful to look at the package graph than to use statprof
<PurpleSym>civodul: Alright, will take a look at the graph as well. I’m preparing a bug report right now.
<civodul>"guix graph r-learnr | xdot -" shows that it pulls in all the Haskell stuff (for Pandoc), plus texlive, Ruby, etc.
<civodul>it's crowded
<PurpleSym>Yep, lots of propagated inputs seem to be the problem.
<PurpleSym>bdju: There is a single-page version: https://guix.gnu.org/manual/en/guix.html
<bdju>PurpleSym: ha, I guess that sorta works. I was expecting tips for viewing it locally in info or emacs, though. (I do usually view the web version just because I don't know the info binds well, though)
<bdju>huh. not that many results for fontconfig and none of it covers setting rules or changing font priority. maybe the manual lacks what I need
<efraim>I was always curious but happy to find out the 4/5 identical binaries were also identical when built from aarch64
<bdju>is there a skeleton fontconfig/fonts.conf file somewhere that I can copy to my ~/.config/fontconfig dir to edit?
<bdju>well, I should say I found something but it has a scary message telling me not to edit it
<jonsger>efraim: nice that you took the time to test it :)
<lprndn>hello guix@
<terpri_>nckx, boeg: quick update on tor packaging. they fork a firefox-esr version only a little newer than icecat's, so probably no big issues with rust etc. dependencies. looking into their custom build system (rbm?) to see if their are major incompatibilities with the guix way of doing things, but i think if we feed it pre-downloaded git repos there won't be huge blockers to packaging
<terpri_>i might be able to use help with debugging build issues or general testing during the next few weeks, still too early to say
<civodul>oh, looking at Tor Browser?
<terpri_>civodul, yes
<terpri_>nckx and i discussed it in...the past day or so
<civodul>terpri_: cool, it'd be nice to have it
<terpri_>civodul, then have it we shall :)
<civodul>yup :-)
<civodul>janneke: the substitutions in "hurd/paths.h" are only needed for startup, when /hurd doesn't exist, right?
<civodul>i wonder if it's a problem to have _HURD_{PROC,AUTH} modified
<civodul>like when you upgrade and want to use the latest Hurd servers
<janneke>civodul: i think: yes
<janneke>so, proc,auth won't be used before activation?
*janneke has a go with that
<civodul>what i mean is that hurd/paths.h is captured by libc, the Hurd itself, etc.
<civodul>so we'd need to see how libc uses _HURD_{PROC,AUTH}
<civodul>but you wouldn't want it to be stuck on an older Hurd if you've reconfigured to a newer one
<janneke>changing hurd without rebooting, eh?
<janneke>someone needs to write a blog post, sometime end of march next year
<terpri_>all quiet on the eastern front so i'm going to try to get that flatpak bugfix posted today
<terpri_>(three-line change, thank goodness)
<terpri_>btw, is anyone looking into AppImage support for guix? it's...not very guix-compatible compared to flatpak
<terpri_>(might have asked already, as i was rambling about appimage's...questionable design decisions here a few days ago)
<janneke>civodul: i've dropped new hardcoding patch out + "/hurd/" for proc,auth; so only for /hurd/startup; that works fine
<civodul>ok!
<civodul>terpri_: as in "guix pack -f appimage"?
<terpri_>civodul, the reverse, running distributed appimages under guix
<terpri_>appimages do odd things like self-extracting and automounting embedded fuse filesystems that expect to run on FHS gnu/linux (bc "common libraries" and so on are not included)
<terpri_>might be quickest to set up an fhs container (with debootstrap or something)
<terpri_>this is (for me personally) a proprietary app that needs gpu access, otherwise qemu/virt-manager would be the obvious answer
<terpri_>i suppose i could finally figure out how to set up pcie passthrough the right way, but that's always been tricky ime
<terpri_>(getting this running will likely result in a giant library of gamedev tools being ported to godot, under a free license, having lots of conversations about it with client who is basically sympathetic but uneducated about free software)
<terpri_>like a proprietary toolkit under development for almost ten years being liberated
<civodul>terpri_: ah no, i haven't looked into making that work (and i'm not interested TBH ;-))
<civodul>but i like the clever hacks that AppImage builds on
<civodul>"guix pack -f appimage" could be a fun ride
<terpri_>guix-generated appimages are probably just fine, it's the existing appimages (many free software programs) built with appimage's tools that are nigh-impossible to run on guix
<terpri_>zulip, for a free example: https://zulipchat.com/apps/linux (recommended as an example by ryanprior)
<terpri_>of course it'd be ideal if all the flatpaks and appimages floating around were simply repackaged independently for guix, but that's a fair amount of work
<terpri_>prusaslicer (tool related to the free software/free hardware prusa 3d printers) is another example of a fairly important free program, which is distributed as an appimage
<terpri_>(at least for that one i'll get paid to package directly for guix, as i've persuaded the client it's "work-related" for prototyping purposes :))
*kmicu celebrates yet another inodes‑are‑full issue on the ML 🎉
<allana>Hi guix. I'm having a build fail with "'linux/errno.h' file not found", does anyone know what input I should have so that the build can find errno.h?
<civodul>allana: did you install "gcc-toolchain" and set up env vars as indicated?
<allana>civodul: no, and I am fiddling with that now. Thank you.
<civodul>yw :-)
<jonsger>terpri_: oh nice that you get payed for :)
<nckx>Mornin' all.
<lprndn>nckx: hey!
<Kozo>Good Morning
<davidl>can you have recursive channel dependencies as in channel A depends on channel B which depends on channel A?
***stefanc_diff_ is now known as stefanc_diff
***jr0_ is now known as jr0
***deesix_ is now known as deesix
***sneek_ is now known as sneek
***cyrozap is now known as Guest35309
<Kozo>Does Guix come with some sort of firewall? I have setup guix publish but the port I've set it to is not open on the server
<jonsger>janneke: does 58bde8719857ecdea15e75bf57b0d1ba1eebe1e4 intenionally remove grep from the inputs of the hurd package?
*janneke looks
<nckx>Kozo: No. Did you read the manual entry for guix-publish-configuration? It defaults to ‘localhost’ unless you explicitly listen on 0.0.0.0.
<nckx>And I can confirm the latter works.
<janneke>jonsger: hmm, "it works" (TM) without grep; but i had the idea that grep was needed for MAKEDEV, and thus removed...
<janneke>but now i'm confused: MAKEDEV is only removed later, and also: it does not use grep
<jonsger>janneke: so only missing in the commit log :P
<janneke>the only mention of grep i can seem to find is a commented-out "egrep" in rc.sh
<janneke>jonsger: it looks like that...unless; mkfsimage.sh is using grep, but that's not being substituted at all;
<janneke>jonsger: yes, update commit message, or leave grep and substitute mkfsimage.sh -- thanks!
<Kozo>nckx: I did but I guess not close enough. Strangely, nstat is reporting that it's listening at 0:0:0:0:*. Thanks for the answer
<nckx>I'm not familiar with nstat but that's weird. 0:0:0:0 notation is weird too.
***familia___ is now known as familia
<Kozo>nckx: Sorry, that should read at netstat, not nstat
<Kozo>as*
<Kozo>nckx: It did not like a custom port in the 8000 range. Setting it back to 80 seems to work fine with 0.0.0.0 set explicitly. Thanks again for your help =]
<nckx>Kozo: Hm, any port should work, I run it on 3000 and 33333. But if 80 works for you, all the better.
<Kozo>nckx: That is a problem for future me ;)
*nckx double-checks whether we've grown a firewall by default… nope.
<NieDzejkob>oh ffs, IceCat is telling the websites I visit I'm in UTC+0 again
<terpri_>jonsger, well, "paid" ;) something like $100/year/"project", other workers need the money more, so they get more, for now
<terpri_>helps keep me stocked up on soylent and juul pods though, and hopefully will be more in the future
<allana>Anyone have experience with using flatpak with guix? I see that it is included in guix packages. I am able to run it, search flathub and install packages under my user account. but so far, I have not been able to run anything. I suppose that I need to configure something. Any tips?
<terpri_>allana, do you get an error message when running things?
<allana>Yes, but I am uneasy about talking about running anything nonfree. Not sure if I will get crucified :-). For example I tried to run firefox
<allana>But firefox is not the goal here, I want to be able to run any arbitrary flatpak software
<terpri_>allana, can you paste the error somewhere? i just fixed a bug in flatpak (not submitted yet), maybe it's the same issue
<nckx>NieDzejkob: That's expected if privacy.resistFingerprinting is on. If it's not, yeah, bug.
<allana>terpri_: ok, one moment :-)
<NieDzejkob>nckx: so it's a bug, but more edgecase-y
<allana>terpri_: "bwrap: execvp xdg-dbus-proxy: No such file or directory"
<terpri_>yep, that's it
<nckx>allana: You won't be crucified, just politely asked to stop 🙂 And Firefox is free.
<terpri_>i have patch, let me see if i can find where git stashed it
<terpri_>a patch*
<nckx>NieDzejkob: As in only certain JS ‘API’s return it? What do you mean?
<NieDzejkob>I recently created another firefox profile. For some reason IceCat decided it should be the default. I switched it back, but this particular session was first launched with a profile that has resistFingerprint enabled, as is the default
<nckx>Ah.
<NieDzejkob>Could the code be written in such a way that it doesn't entirely work with multiple profiles?
<nckx>I use multiple profiles but always start an explicit ‘--ProfileManager’. So I can't speak for how good its notion of ‘default’ is.
<NieDzejkob>perhaps the profile creation wizard has some checkbox I should've unchecked
<terpri_>allana, this patch should fix it: https://paste.debian.net/1150141
<terpri_>going to try to file a proper bug report for it today
<allana>terpri_: thanks!
<roptat>hi guix!
<roptat>there seems to be an issue with the armhf build farm: https://ci.guix.gnu.org/log/jn0r0cwh681p2zmlbfnfh7ymaysylmv3-guix-extra
<allana>terpri_: Is that patch expected to be in guix?
*janneke spams #41541
<civodul>roptat: looks fishy
<roptat>it's been failing in that way for a few days it seems
<civodul>$ file -L "/gnu/store/aw08wv3j9pq1pqgwqbhmpkyn7q90nv4c-guile-ssh-0.12.0/lib/libguile-ssh".so
<civodul>/gnu/store/aw08wv3j9pq1pqgwqbhmpkyn7q90nv4c-guile-ssh-0.12.0/lib/libguile-ssh.so: ELF 32-bit LSB pie executable ARM, EABI5 version 1 (SYSV), dynamically linked, not stripped
***wingo_ is now known as wingo
<roptat>which sounds correct (though the message doesn't say ".so")
<roptat>but is it present on every armhf node?
<roptat>how does offloading work if one of the offloading servers is currently down? does the build fail, or does guix schedule it on another offload server?
<terpri_>sneek, later tell allana: the patch should be in guix master very soon, simply haven't gotten around to submitting it properly yet
<sneek>Will do.
<terpri_>24/7 roommate nursing (USA #1! /s), protest logistics, $work, daily life, living under night curfew with my schedule...it's a lot, but fortunately i'm a decent juggler
<guix-vits>terpri_: Is there any way to apply such patch without a local repo?
<terpri_>guix-vits, you can create a package that inherits from flatpak and adds the change, if you know how to do that
<terpri_>guix-vits, example: https://paste.debian.net/1150153/ customized zsh package that installs the info manual (unlike standard guix zsh), installable with guix package -f
<terpri_>you could probably copy the flatpak package definition into a new file, rename it "my-flatpak", and patch it manually, guix will warn you if you forgot to import some module or whatever
<terpri_>(the error should suggest specific modules to import)
<terpri_>what i do personally, is have a guix git checkout, with a personal "current" branch for customizations, and then use channels to use that checkout like so:
<terpri_> https://paste.debian.net/1150156/
<terpri_>which will override the default "guix" channel
<terpri_>of course, then you have to keep it in sync with master yourself, so perhaps more effort overall than making a customized flatpak package to use for a few days
<terpri_>(channel defs go in ~/.config/guix/channels.scm)
<guix-vits>terpri_: Thanks.
<rekado>I tried to reduce closure size of packages using pandoc, but only managed to drop about 1G.
<terpri_>"only" :)
<rekado>I tried but failed to let GHC link pandoc statically (i.e. static linking of Haskell stuff only).
<rekado>I don’t know why it doesn’t work, but that would be the correct solution in the case of pandoc.
<rekado>we simply don’t care about all the Haskell libraries.
<rekado>instead of 3GB we should just have a single tool weighing in at a few megabytes.
<civodul>roptat: i've restarted that guix-extra.drv and it succeeded this time
<roptat>cool
<civodul>i wonder if guile-ssh could have been gc'd in the meantime or somethign
<roptat>do you know what happened?
<civodul>no
<bavier>hi guix!
<civodul>hi bavier!
<bavier>\o
<ryanprior>rekado big agree, static installs are often preferable, hope you can get it working
<rekado>I’ll push my updates to the haskell-build-system to a branch and ask for review first
<rekado>I tried building ghc-pandoc with “-fstatic” with and without my changes and it wouldn’t work in any case
<rekado>the linker tries to find the wrong libraries somehow
<rekado>not sure what’s going on there
<rekado>but in the meantime we could at least shave off 1GB by separating the shared objects from the static archives.
<apteryx>which package provides the fnctl manpage?
<apteryx>the man-pages package doesn't have it
<apteryx>seems it should
<janneke>apteryx: try fcntl
<apteryx>haha! I need glasses
<apteryx>thanks, janneke!
<janneke>apteryx: me got bitten by that before, ioctl, prctl, f..tl
<apteryx>hehe
<raghavgururajan>Hello Guix!
<raghavgururajan>Are relocatable packages useful in Guix System?
<ryanprior>Is there any official style/content guide for Guix package descriptions? If not, would that be a welcome contribution?
<apteryx>raghavgururajan: I think the main use case is to use a Guix package without guix installed (say, because you don't have admin privilege on a machine and can't have the daemon installed).
<raghavgururajan>I have an build-option for a package, to either enable or disable relocatable support. Would enabling be of any use/advantage to the user?
<raghavgururajan>apteryx: Ah, gotcha! So, relocatable might come in handy.
<apteryx>ah, we're talking different things
<raghavgururajan>Oh.
<apteryx>Guix itself has support for rewriting the location of the store at runtime
<apteryx>you are talking about some library/tool used by the application itself
<apteryx>IIUC
<raghavgururajan>option('relocatable', description: 'Whether to enable application bundle relocation support',
<apteryx>guix pack --relocatable
<raghavgururajan>So no need to enable it during build?
<apteryx>raghavgururajan: I would disable such support, as in the store it's better when everything refers explicitly to things
<civodul>raghavgururajan: a relocatable build option in the package's build system is probably useless for Guix
<apteryx>and where we want stuff to be relocatable we can use the mechanism provided by 'guix pack'
<civodul>yeah
<raghavgururajan>civodul, apteryx: Cool!
<mbakke>cuirass-web is crashing on many requests to ci.guix.gnu.org according to the log
<mbakke>it looks like someone is scraping old evaluations and log outputs, which probably contributes to the problem
<ryanprior>With regard to a style/content guide for Guix package definitions, here's my current question: if a service provides a no-fee tier and I want to mention that in the package definition, is it appropriate to use the common-language "free tier" or is there another preferred term?
<raghavgururajan>What is the value for --target/--system to build for armhf machines?
<ryanprior>I imagine that a guide could provide lots of answers to things like that and help us write consistent, useful package descriptions. Thus far I've been inferring style by reading other package descriptions, which leaves a lot unsaid.
<raghavgururajan>In other words, if I want to build for armhf machine, what should be the value for `--target=` in `./pre-inst-env guix build --target=`?
<nckx>raghavgururajan: They're not the same. --target=arm-linux-gnueabihf, --system=armhf-linux, I think.
<raghavgururajan>nckx: Thanks!
<civodul>mbakke: that someone could well be... the almighty cbaines!
<civodul>cbaines has been working on the "Guix Disturbance Service", which has this side effect
<civodul>just sayin'
<mbakke>does not look like it, the requests come from a couple of different sources with different user-agents, like "Mozilla/5.0 (compatible; AhrefsBot/6.1; +http://ahrefs.com/robot/)" or "Mozilla/5.0 (compatible; SemrushBot/6~bl; +http://www.semrush.com/bot.html)"
<mbakke>perhaps we should install a robots.txt
<mbakke>in the off chance that these are actually well-behaved :P
<civodul>oh yes, i remember having lots of requests from ahrefs.com on hydra.gnu.org
<civodul>we eventually added iptables rules IIRC
<nckx>Both Ahrefs and SemrushBot used to respect robots.txt.
<bonz060>Hi. Is it possible to run `npm` within the trivial build system? I want to repackage some javascript files from which the repo's don't have a `build` directory; And I'd need npm to transpile the js file.
<rekado>bonz060: you have no internet access in the build container.
<mbakke>welp, https.access.log is 52G, no wonder my grep takes forever
<bonz060>rekado: I don't think about that. I guess my best bet would be to download the file from a cdn and hash that file. Is it possible to do a download for separate files within the same package definition?
<rekado>bonz060: yes, via native-inputs
<civodul>mbakke: oops!
<civodul>we need some log rotation
<bonz060>:rekado thanks!
<mbakke>AhrefsBot has connected via 46 different IP addresses over the last 100k log entries, though all seems to be a single /23 network
<civodul>mbakke: i forget how we did that, but maybe the guix-sysadmin archives have something about it
<civodul>or perhaps it was actually through nginx
<civodul>ah yes, see hydra/nginx/hydra.gnu.org.conf
<civodul>before we get rid of that file ;-)
<ryanprior>bonz060: you could in theory use npm to download files into a package-input, but I don't know if npm produces a byte for byte reproducible node_modules folder even with a lock file. (Not saying it doesn't, I haven't tried it and don't know.)
<ryanprior>You have to have hashes for all your package inputs. If you can make npm produce a node_modules folder with a reliable hash, you could use that as a package input to your build.
<rndd>hi everyone! sometimes i find "^L" symbol in sources? does it have any meaning?
<rekado>rndd: yes, it’s a page break
<rekado>some people use elaborately styled separators for that
<rekado>using ^L we say that this is a new section, let the editor style this any way the user prefers
<rekado>(it’s semantic markup, if you will)
<rndd>rekado: it's special for emacs?
<nckx>rndd: No.
<rndd>where i can read about it?
<nckx>rndd: https://en.wikipedia.org/wiki/Page_break ?
<nckx>‘Semantic use’ is relevant here.
<rndd>oh, ok
<rndd>got it
<terpri_>you can use C-x ] (forward) and C-x [ (back) to jump between pages in emacs
<terpri_>i've only seen it used for section breaks in lisp dialects, though surely some other languages use it too
<terpri_>(and plain text i guess)
<rndd>terpri_: how i can make my page break in text?
<nckx>rndd: I read ‘is it special for emacs’ as ‘is it emacs-specific’. I might have misread ‘does emacs treat is specially’. Yes, but not visually, and I've never used the (to me obscure) navigation bindings.
<terpri_>rndd, C-q C-l
<rekado>there is a package for Emacs to render ^L as a horizontal line
<rekado>emacs-page-break-lines in Guix
<terpri_>yes, https://www.emacswiki.org/emacs/PageBreaks lists some packages to treat it specially, page-break-lines is one of them
<rndd>ok, thanks
<ArneBab>I’ve been unable to guix pull for two months now — recently started upgrading directly from a git clone. Do you have a hint how I can fix that?
<ArneBab>$ LANG=C guix pull
<ArneBab>https://git.savannah.gnu.org/git/guix.git 790ada9 … /gnu/store/kmzfd8avp1qskknh4z62birwvdja9ixy-module-import-compiled.drv... 4% … failed with exit code 1
<rekado>why wait for two months!
<rekado>does it provide more output than that?
<rekado>hmm, I’m very puzzled by differences in reported file sizes
<rekado>I took the Qemu VM image on the Guix website, unpacked it, and converted to RAW with qemu-img
<rekado>du -sh *.raw says it’s 2.9G
<rekado>but ls -lah *.raw says it’s 30G
<rekado>df -h tells me I only have 13G free space, so I don’t even have enough space for a 30G file
<rekado>aws s3 cp tells me it’s 30G as well
<cbaines>raghavgururajan, are you around to investigate why you can't SSH in to bayfront?
<sneek>Welcome back cbaines, you have 1 message!
<sneek>cbaines, raghavgururajan says: I still get the same error while accessing bayfront.
<rekado>something about sparse files, maybe?
<marusich>hello guix
<bavier>hi marusich
<marusich>how goes it?
<davidl>I am receiving a package conflict error upon installing jupyter that doesn't make sense as I don't have any of the packages installed that guix mentions being in conflict: https://paste.debian.net/1150220/
<marusich>davidl, perhaps they were both propagated-inputs of some dependent package
<davidl>marusich: is there any way to search for which package that might be?
<davidl>I mean the output mentions "propagated from..."
<davidl>marusich: and in the paste I show that trying to uninstall the packages which are mentioned as "propagated from" doesn't work - saying the package is not in profile.
<davidl>which -a jupyter also mentions that I have jupyter in ~/.guix-profile/bin
<ArneBab>rekado: because I had no mind to fix any problems outside the most pressing ones …
<ArneBab> http://paste.debian.net/1150225/
<marusich>davidl, if you run "guix edit jupyter" etc. you can see the package definitions.
<marusich>Looks like as the error says, both jupyter declares both python-ipywidgets and python-qtconsole in its propragated-inputs. And both of these declare a python-ipython in its propagated-inputs. However, they are different: python-ipywidgets pinned the python-prompt-toolkit dependency to version 2, in commit 32ba87c14fd5e5b54d95211cd9a159d568ce7c67.
<marusich>That commit is from May 26th, so it could be that this is an unintneded consequence of the change.
<marusich>Could you email bug-guix@ and email the author, Edouard Klein <edk@beaver-labs.com>, to ask about it? I don't really know what the right thing to do here is, and I have to focus on something else.
<davidl>marusich: thanks for the analysis
<marusich>maybe Edouard will know what the right thing to do is. Also, is it causing you a problem?
<marusich>Or do things seem to work?
<davidl>things don't really work right now
<davidl>I am trying to setup a manifest for a reproducible dev-environment that uses jupyter and a bunch of other packages.
<marusich>OK. If it's breaking jupyter somehow, then it's all the more reason to open a bug report and ask Edouard about it.
<marusich>I'm not sure what the right ettiquette for opening a bug report and CCing somebody is, though. If you email bug-guix@ and also put Edouard in CC, they might accidentaly reply to bug-guix@ by hitting "reply to all", which would create a new bug report.
<marusich>So I guess, unless somebody knows better, it would be safest to just email bug-guix@gnu.org first to open the bug report, and then separately email Edouard to ask them to look into it.
<marusich>Oh hey. I see that you can't even install jupyter now. I tried "guix package -i jupyter -p /tmp/myprofile" and it just failed. I skimmed your paste, so I didn't notice that. That's definitely not great :(
<PurpleSym>davidl: In the meantime you can update/install the package with `--allow-collisions`, but it may not work.
<davidl>marusich, PurpleSym: ok Ill look into that either tonight or tomorrow.
<marusich>PurpleSym, when I tried that, it successfully installed jupyter, yes.
<marusich>davidl, apparently *this* is the right way to CC somebody when making a new bug report: https://debbugs.gnu.org/Reporting.html
<marusich> X-Debbugs-CC: someone@example.com
<marusich>Totally unrelated...I wish there were a project like Yunohost but for Guix
<davidl>marusich: I wish that too!
<marusich>It's a shame that projects like Yunohost end up being so distro-specific
<marusich>But I guess it's how things go once a project has decided upon a base system to use.
<rekado>ArneBab: can you show us /var/log/guix/drvs/km/zfd8avp1qskknh4z62birwvdja9ixy-module-import-compiled.drv.bz2 ?
<jonsger>rekado: those qemu images are dynamically growing up to a certain size so I guess it's a matter which size the tool reports
<rekado>jonsger: I’m not using the image, thoug.
<rekado>*though
<rekado>it’s just an inert data file
<davidl>marusich: yes that is a shame... I know that someone with a nick "snape" in here had some pretty decent config.scm with nginx and email and stuff that would be a start for such a project.
<davidl>I think the configs were named like hermione.scm etc. but I can't find their git anymore.
<ArneBab>rekado: http://paste.debian.net/1150248/
<ArneBab>… and I have an idea where that came from
<ArneBab>the git checkout is done with my env, right?
<ArneBab>what happens if I have autocrlf = input or autocrlf = true?
<ArneBab>in ~/.gitconfig [core]
<ArneBab>(need that for my work setup)
<davidl>marusich: found it! this serves as a really great config example for various hosting stuff: https://git.lassieur.org/cgit/emacs.git/tree/guix/hermione.scm
<ArneBab>In procedure scm_lreadr: /gnu/store/wm525iw4xg4hij16lncmhrrxalq98idw-module-import/guix/store.scm:1480:1: illegal character in escape sequence: #\return
<ArneBab>that looks like \n received \r
<ArneBab>rekado: looks plausible? ^
<ArneBab>yepp: switching to unix line-endings in emacs and using M-x diff-buffer-with-file gives:
<ArneBab>-;;; GNU Guix --- Functional package management for GNU^M
<ArneBab>
<ArneBab>+;;; GNU Guix --- Functional package management for GNU
<ArneBab>
<ArneBab>how can I fix that?
<earl83>hello
<earl83>So my understanding is that guix uses hashes to verify a package when you install it. Is that just it? What if my connection was edited to install a fake package despite the hash being shown as correct?
<cbaines>earl83, I don't quite follow, but the hash of the downloaded data is computed, and that's checked against the expected signed hash
<terpri_>earl83, it's not clear to me what failure mode you're imagining
<terpri_>yes, exactly, it's checked against the hash in the package definition
<earl83>Lets say I decided to install package foo. And both the package and the expected hash were modified by a third party entitity. Is there any other factor to verify it wasn't tampered with during transition? Like distros like debian use gpg to verify a deb file.
<cbaines>earl83, there's a cryptographic signature for the hash (it covers portions of the narinfo file) which prevents this
<terpri_>well if the "expected hash" were modified, that means someone managed to get a bad hash into the guix repo
<earl83>cbaines, where can I read more about this cryptographic signature for the hash?
<bavier>earl83: the "Substitutes" section of the manual touches on this
<bavier>the substitutes are signed and the signature is verified locally after download
<bavier>so the attacker would somehow need to have access to the substitute server's signing key
<earl83>It's a relief that the precompiled binaries are signed by a key along with verifying the 256/512 hash.
<earl83>So if I wanted to use a guix package with a package that's available in my distros native package manager, that's possible, correct?
<NieDzejkob>what exactly do you have in mind? that's a pretty general question, so the answer is "it depends" ;)
<earl83>I want to use webkitgtk from guix rather than compile it from source because it's absolute hell to compile.
<earl83>Actually, nevermind. Turns out that surf is in the repos as well. I don't have to mix packages from my native manager with guix after all :D
<earl83>But lets say I wanted to compile surf git and use it with the guix webkitgtk. Is that possible?
<glat-agent643>Hello. I am selling cheap GNU/Linux licenses. $89 today!
<earl83>What kind of licenses?
<glat-agent643>earl83: a license for single computer
<earl83>I've never heard of needing a license for GNU/Linux like this is windows.
***ChanServ sets mode: +o rekado
***glat-agent643 was kicked by rekado (Kicked by rekado)
<glat-agent643>Hello. I am selling cheap GNU/Linux licenses. $89 today!
<NieDzejkob>rekado:
***glat-agent643 was kicked by rekado (Kicked by rekado)
<glat-agent643>Hello. I am selling cheap GNU/Linux licenses. $89 today!
<mbakke>...
<earl83>Is stuff like guile-git and guile-gcrypt required if I'm just doing the binary install of guix?
<mbakke>earl83: it's pretty easy to define custom packages inheriting from an existing guix package, here is an example: https://paste.debian.net/1150281/
<mbakke>earl83: they are required, but included in the binary IIRC
***rekado sets mode: +b $r:glat-agent*
<earl83>Wait. If I have surf installed through guix and also a custom surf package, won't there be a name conflict?
<kabo>Hi, are there any plans for a arm64 usb installer image?
<kabo>would be cool to get guix running on my pinebook pro
<dlowe>I got it running but it's pretty bare bones atm
<kabo>huh, ok
<kabo>I recall hearing that linux 5.7 was where support for the chip was going to get mainlined
<kabo>not exactly sure what that means
<kabo>is guix already on linux 5.7?
<dlowe>searching for "guix on pinebook pro" will give you a blog entry about installing it and it works
<dlowe>but I didn't get a gui running or anything
<dlowe>I think if I were going to do it right I would cross-compile on my desktop machine
<earl83>mbakke, let me ask you, I know you mentioned making a custom package, but what If I wanted a non guix software like surf that I compiled myself to use webkitgtk from guix. Is that possible?
<kabo>hmm, looks a bit involved right now
<kabo>I'll have to look into this a bit later, when I have more time on my hands
<mbakke>earl83: in that case you'd just to 'guix environment surf' and you should be able to compile it locally
<kabo>LOL
<earl83>Can't I just make the distro think webkit is installed in my guix directory rather than in /bin or /usr/bin?
<mbakke>earl83: 'guix environment surf' will drop you into a shell with all dependencies of surf available, including webkitgtk
<mbakke>earl83: you can use --pure or --container to ensure that no dependencies from your foreign system are used
<mbakke>i.e. git clone <surf>; cd surf; guix environment surf -- make should compile it even if you have not installed any dependencies locally or on your foreign distro
<earl83>and what happens to the surf binary? Where does it get put?
<mbakke>probably ./surf, dunno :-)
<earl83>I don't know if it would be in my path if I used guix environment surf
<mbakke>earl83: guix environment surf only makes the build dependencies available, not surf itself
<mbakke>I'm trying to answer your question on how to compile it manually :P
<earl83>I don't think your answer was what I was seeking
<mbakke>oh
<earl83>Dependencies won't be a problem
<earl83>But I want surf to know that webkit and all dependnecies are in the guix directory rather than the usual /bin or /usr/bin or /usr/local/bin
<mbakke>earl83: yes, that will happen if you compile it in a 'guix environment surf'
<earl83>after I run guix environment surf, I can move the binary to any other directory after that?
<mbakke>sure
<earl83>awesome. I think you answered what I was looking for.
<mbakke>:-)
<mbakke>guix is pretty magic
<earl83>Thanks man
<mbakke>earl83: note that if you do that, and later run 'guix gc', some of the dependencies might get garbage-collected
<earl83>what happens when it gets garbage collected?
<mbakke>the binary will be unable to find the runtime dependencies
<earl83>So guix gc is something I shouldn't do?
<mbakke>you can use 'guix environment --root=$HOME/.surf-root surf' to prevent the depencies from getting garbage collected
<mbakke>by default, only packages installed into a guix profile are protected from GC
<mbakke>but you can add as many "roots" as you want
<earl83>Fascination
<earl83>I wonder if suckless likes guix. Probably not because it's not C89.
<guy>Hello, I made an install usb using 1.1.0-4 and when I guix pull I am getting the error "glibc-bootstrap-system-2.2.5.path: patch not found"
<guy>nevermind, it was reported today on guix issues. My search was to detailed.