<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>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>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.
<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>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.
<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 :)
<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
<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
*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.
<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
<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.
<nckx>Both Ahrefs and SemrushBot used to respect robots.txt.
<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?
<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?
<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.
<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 …
<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 <email@example.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>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 firstname.lastname@example.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.
<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?