IRC channel logs

2021-09-04.log

back to list of logs

<the_tubular>Is there any other "addons" than ublock-origin offered with guix ?
<the_tubular>I'd like to make fire moneky available if not
<leoprikler>if it's not packaged yet, you can be the one to do it :P
<raghavgururajan>leoprikler: Does v8 of gtk patchset look good to you?
<raghavgururajan> https://issues.guix.gnu.org/48554
<leoprikler>the comment is still weird English to me
<raghavgururajan>On the inputs?
<raghavgururajan>Oh that one
<raghavgururajan>Forgot.
<raghavgururajan>I will add that change.
<leoprikler>also on the gtk+ side (2 and 3), I'm not really a fan of how rust inverts inherit trees
<leoprikler>unless there's something broken with them, could you keep those two as-is and just add gtk4?
<raghavgururajan>The inheritance only touches synopsis, description and license.
<raghavgururajan>Btw, what is 'rust inverts inherit trees'?
<leoprikler>chotto matte
<raghavgururajan>what lol
<raghavgururajan>Anyway, I'll keep the gtk+ side as-is.
<leoprikler>yup, your inherit changes introduce wrong synopses and licenses
<raghavgururajan>Ah, okay.
<leoprikler>w.r.t. rust inverting inherit trees, it normally makes sense to inherit newer package versions from older ones
<leoprikler>but rust crates are special and do it the other way round, no idea why
<raghavgururajan>It seemed newer versions inheriting older versions odd to me. Older versions are likely to get removed/deprecated and we have to remove inherticance to newer versions. If vice-versa, just knock the older version out and newer version stays untouched.
<raghavgururajan>I think it only applies for non-toolchains
<leoprikler>well, suffice it to say, we won't say goodbye to gtk+2 for a long time
<leoprikler>btw. why no bin output?
<raghavgururajan>yeah.
<raghavgururajan>Separating bin causes cyclic dependencies between inputs.
<raghavgururajan>*outputs
<leoprikler>how so? could some additional things be moved to the bin output?
<raghavgururajan>I'll examine the output contents and get back to you.
<muradm>qt-build-system, does it provide qmake?
<raghavgururajan>muradm: No, it uses cmake. But you can replace build phase with custom one that could invoke qmake.
<muradm>yes, thanks, figured that now, building..
<leoprikler>you actually need to replace configure with qmake, but oh well :)
<milkey>what is the texinfo syntax for an inline quote that won't make `guix lint` mad?
<milkey>guix lint says "use @code or similar ornament instead of quotes" but there's no semantic tag for scare quotes :P
<muradm>milkey @sampl ?
<muradm>@samp to be correct
<milkey>close enough I guess
<muradm>if it looks like duck, sounds like a duck, why not call it duck? :D
<raghavgururajan>muradm: Correction, its configure phase (not build) as leoprikler mentioned.
<muradm>raghavgururajan, leoprikler: (thumbs up)
<roptat>mh what? "Undefined symbol #f"
<apteryx>is it supposed to be possible to switch to the gold or lld linkers for a package by simply adding them as native-inputs and configuring the package for it?
<apteryx>or is there something more involved to do w.r.t. to how the toolchain is setup?
<iskarian>apteryx, I think it should be that simple. See for example go@1.14, which just adds binutils-gold to native-inputs
<apteryx>right, I saw that too (the only example :-))
<apteryx>it didn't work for LLVM, but ldd did
<apteryx>it reduced memory usage by more than 4X for linking LLVM
<apteryx>lld*
<apteryx>but it seems a bit unstable (the build fails often, for no reason)
<apteryx>otherwise -DLLVM_PARALLEL_LINK_JOBS=2 will do it
<brendyn>Is it possible to refer to the tests? key in #:configure-flags?
<apteryx>I don't think so
<brendyn>I think I may have just done it: ((lambda* (#:key tests? #:allow-other-keys) (if tests? "-DBUILD_TESTING=ON" "-DBUILD_TESTING=OFF")))
<apteryx>but you could wrap the whole arguments in a (let ((your-shared-variable ...)) ...)
<brendyn>So I have #:configure-flags `("..." ,((lambda* (#:key tests? #:allow-other-keys) ... )))
<dhruvin>bricewge: To make sure sourcehut's builder's home directory exists before creating a gitconfig for it, I created a shepherd service that requires "user-processes". It worked without any issues. Let me know if that was the right thing to do.
<bricewge>dhruvin: Nice! That's what I would have done too.
<dhruvin>Update: sourcehut's build image for guix is ready, well almost. The only thing left to do is to provide right initrd modules. I believe default ones are okay. Let me know if there are any suggestions.
<dhruvin>PS: qemu is used to virtualize.
<dhruvin>I'll be back after lunch and share the details about it.
<attila_lendvai>is there a way to only fetch part of a github repo? can you please point me to an example? what i want is the equivalent of this in the git-reference: (url "https://github.com/trezor/trezor-firmware/python/"); i.e. only a subdirectory
<attila_lendvai>or anything i should grep for
<lilyp>attila: you can delete everything but the subdirectory using a snippet
*attila_lendvai greps for snippets
<dhruvin>Request for comments: Proposed build configuration format for sourcehut builder.
<dhruvin> https://paste.sr.ht/~dhruvin/fc058b96d14f2645f6b2f4751ab4dca1971413d7
<raghavgururajan>Rust gets on my nerve every freaking time.
<raghavgururajan>Seriously. Its been building for 3 days, for 1.2x.y to 1.3x.y It has to reach 1.5x.y
<raghavgururajan>Not sure if its my ignorance to understand rust or its bad design.
<bricewge>raghavgururajan: Who need fast compilation when you have a safe language?
<attila_lendvai>lilyp, thanks! i've found this instead, and testing it now: (add-after 'unpack 'enter-source (lambda _ (chdir "python") #t))
*raghavgururajan 's head spins
<lilyp>that works too, but remember that `guix build -S` still gives you the whole thing
<lilyp>whether or not you want that is up to you
<lilyp>raghavgururajan: it's rust's ignorance to understand concepts from the 80s :P
<lilyp>also it's companies piling huge ass codebases unto huge ass codebases
<raghavgururajan>I have to learn more regarding this mem-safe stuff.
<raghavgururajan>yeah that.
<lilyp>dhruvin: for the channels thing, do you think it'd make sense to map yaml onto scheme
<bricewge>dhruvin: I never used sourcehut's build, but I don't see how you will be able to add subsitutes server in the "repositories" dictionary as this is a different concept from channels
<bricewge>To have a usable substitue server you need a public-key and a url (see https://bordeaux.guix.gnu.org/ for exemple)
<attila_lendvai>lilyp, what i want, ideally, is to only include that directory, and preferrably without a subdir. i'm adding a snippet to delete everything else, and a chdir... but i really wished there was a better idiom for this. it comes up often.
<lilyp>do you have metrics on "often"?
<lilyp>bricewge, dhruvin: I think substitute servers could be enabled if repositories could be split into - channels: and - substitute_servers: somehow
<dhruvin>bricewge: sourcehut's repositories section is restricted to "string: string".
<attila_lendvai>lilyp, i'm new to guix, just getting into packaging stuff, and i've experienced twice.
<attila_lendvai>btw, isn't it preferred to use git repos as opposed to pypi references? or i shouldn't bother converting this package?
<lilyp>at this point it could just be that your personal pet project(s) which you're packaging are badly structured?
<dhruvin>For example: debian uses this format -> sr.ht: https://mirror.sr.ht/debian/sr.ht/ stretch main DEADBEEFCAFEF00D
<lilyp>dhruvin: given that restriction, what about - repositories: - channels: <paste channels.scm> - substitutes: <paste substitute acls or whatever>
<attila_lendvai>lilyp, it's e.g. trezor-firmware, that has a fw and a python side that must be more or less in sync, and they sit in the same git repo (which makes sense), and this repo is tagged python/v1.2 and firmware/v2.3 (not sure about this, but i've seen it before multiple times)
<lilyp>Okay, but let's say you have a given trezor-firmware package [firmware side] and then want to generate the corresponding python thingy, can't you just inherit the origin?
<lilyp>and then chdir python
<lilyp>it sounds like you would need one anyway and the other is optional
<attila_lendvai>lilyp, this fw is something that gets flashed on the device, not something that needs to be available on the host computer
<lilyp>ahh, I see
<attila_lendvai>git-download.scm doesn't yield itself for an easy patching to add this, at least not for a newcomer
*attila_lendvai is AFK for a few minutes
<dhruvin>lilyp: I'll have to read more about substitutes. After reading bricewge's comment, I think I have misunderstood it.
<bricewge>dhruvin: Maybe something like this https://paste.sr.ht/~bricewge/29f6667adc5e928dfe3172dc10f8bd0ca245d624
<dhruvin>Setting substitutes aside for now (my bad), are there any other suggestions?
<bricewge>But I don't really like it
<dhruvin>Yes, it's a bit of a hack.
<bricewge>For information`substitute-urls` is field from `guix-configuration` record
<dhruvin>I'll ask Drew about adding new fields to config and get back as soon as I get any response from sourcehut.
<dhruvin>Thanks, bricewge. Initially I believed it's something one could add in channels.scm. Turns out I was wrong. Reading it right now.
<bricewge>dhruvin: You could also ask on guix-devel
<bricewge>ATM I don't get how/where builds.sr.ht/manifest match on Guix concepts
<dhruvin>Fields in said manifest are just "nice to have" things. As a user of builds.sr.ht, you would have a manifest file of yours in your source code.
<dhruvin>There are only two fields "packages" (that maps to packages in build user's profile) and "repositories" (mapping to a list of channels)
<dhruvin>Everything else is common accross all images.
***[0x4A6F][m] is now known as [0x4A6F]
<bricewge>dhruvin: By manifest you mean sr.ht's manifest not Guix's, right?
<dhruvin>bricewge: Yeah, guix manifest, I should have written manifest.scm.
<bricewge>Ok, then you could use a `.guix-channel`https://guix.gnu.org/manual/devel/en/guix.html#Declaring-Channel-Dependencies to define non default channels you depend one
<dhruvin>Yes, that's what I'm working on right now.
<bricewge>AFAIK substitute server keys are host specific, so you would definitly need to specify it `manyfest.yml`
<dhruvin>The shepherd service I mentioned will have additional actions for adding channels and installing packages. For example, 'sudo herd add-repo sourcehut-builder "dug" "<dug channel>"'
<dhruvin>*add-channel (not add-repo)
<dhruvin>bricewge: I think I'm confusing you. Am I making sense?
<bricewge>No, I think I get it
<bricewge>But does it make sense to add channels in the `repositories` dictionary, as you can already specify them in `.guix-channel` and other OSes only expect a URL to get binaries from and a public key https://man.sr.ht/builds.sr.ht/compatibility.md#debian
<bricewge>This match closely to a substitute servers URL and their publick keys, isn't it?
<bricewge>s/publick/public/
<dhruvin>It does match closely to substitute servers.
<dhruvin>At the time of writing that paste, I thought repositories is where you get packages from (and/or definitions if they're source only).
<dhruvin>Also, nixos channels are specified in repositories field as well. That reinforced my view. Although, I haven't worked with nixos to really understand what they mean by channels.
<bricewge>Yes
<bricewge>NixOS' substitute servers are called binary caches IIRC https://nixos.wiki/wiki/Binary_Cache
<dhruvin>Then, nixos is indeed using repositories field to specify channels.
<dhruvin>(This doesn't mean we should too)
<bricewge>Yes, but it seems they can't specify a binary cache tho
<dhruvin>Yes, about the the substitute URLs. I read that I can add them to <operating-system> configuration.
<dhruvin>Is there any other way? Because this would require me to reconfigure to build system.
<dhruvin>*reconfigure the build machine
<dhruvin>*operating-system > services > modify-services (guix-service-type)
<bricewge>There is the `--substitute-urls` option for some subcommand
<nckx>Morning, Guix.
<bricewge>Hello nckx!
<nckx>o/
<xd1le>o/
***kimapr[m]1 is now known as Kimapr
<brendyn>apteryx_, actually it didnt work what i was doing
<bdju>for the target -> targets change that guix keeps warning me about, do I really just need to add an s or did something else change in the format? I remember the setuid change being rather hellish
<bdju>I'm mid-updating now or I'd just try it
<nckx>I expect you'll at least have to add (list …).
<nckx>But that's just that.
<lfam>Sigh, linux-libre changed their download URI schema
<lfam>The latest versions will be late or maybe we'll skip them, idk
<nckx>Did it really change? The original release wasn't properly deblobbed & they had to issue a fix.
<lambda`>When packaging If I have the choice between gtk2 and gtk3 which one should I choose? does the size difference in 'guix size' matter enough to choose gtk2?
<nckx>Don't ask me what it was but something snuck in that shouldn't have.
<lfam>Yeah, I get that
<lfam>They are created new versions of linux-libre for *all* previous releases in each affected series
<lfam>So there are new versions of every 4.4 release, for example
<nckx>lambda`: Guix tends to use the latest version of things without good reason. I've never heard ‘samba@4 is bigger than samba@3’ as a reason to keep the latter, so I'd go for gtk 3.
<lambda`>nckx: thanks!
<nckx>lfam: What else could they have done?
<lfam>I guess I expected it to be treated as a bug, and fixed in subsequent releases
<lfam>Like, nobody is trying to use 4.4.7 anymore, whether it's -gnu, -gnu1, -gnu2, etc
<nckx>Then I must misunderstand what they did/you mean; that's what I thought they did (issue a $gnu+1 for each non-FSDG release).
<nckx>It's not like distributing a known-bad 4.4.x ‘because it's old’ is acceptable.
<nckx>I'd expect them to pull it from distribution.
<lfam>Well, in Guix, we can't help with that. Our old package revisions are set in stone
<lfam>I don't know, I'm just annoyed. It's not a big deal
<nckx>Yeah, I must not understand the problem then, never mind.
<nckx>Sorry you have to deal with it.
<lfam>It turns a task that is rote into something more complicated
<dstolfa>lfam: oh dear... why did they do that
<nckx>s/known-bad/known-non-free/, which makes all the difference.
<nckx>It's not a bug you can keep distributing.
<lfam>I mean, it's kind of a self-inflicted wound IMO
<nckx>That's not a kind thing to say. Everyone makes mistakes.
<lfam>You're right, I'm sorry to everyone that is reading along
<lfam>I didn't mean to highlight a mistake but rather the sense of necessity of fixing old releases
<lfam>I don't even think this was a mistake but rather an old "I wonder..." being answered
<lfam>We all have to fix things as we can
<nckx>You wouldn't expect projects to keep distributing a release that was found to include copyright-infringing content (as happened to a Doom clone, I forget which one). They'd probably even nuke the git history. For Linux-Libre, this is morally equivalent.
<nckx>That doesn't mean it doesn't suck for you, and I really appreciate the effort you put into this package.
<lfam>I think that removing old Git history is beyond the pale in this case
<lfam>There's no copyright violation to speak of, in reality
<nckx>Right.
<nckx>Well
<lfam>If there was, there would be action taken by the copyright owners
<nckx>this is Linux-Libre
<nckx>you get my point.
<lfam>Yes
<nckx>:)
<dstolfa>lfam: sigh. sorry you have to deal with this mess :/
<lfam>They are planning to remove the old linux-libre releases, which will break old revisions of Guix
<dstolfa>perhaps softwareheritage can help here?
<lfam>So, any revision of Guix before approximately tomorrow will no longer be able to be built from source to deploy Guix System
<nckx>
<civodul>ah yes, this is terrible
<civodul>i saw the latest announcement, and didn't dare think this really meant that
<xd1le>well that sucks
<civodul>but do we still depend on those tarballs anyway?
<lfam>They are confirming it in the #gnu-linux-libre channel
<lfam>Yes, civodul
<civodul>i forgot where we are
<lfam>But, they are planning to rewrite their Git history too
<xd1le>oof
<dstolfa>lfam: i feel like this is pretty bad practice at this point...
<lfam>So, we wouldn't have access to old source code corresponding to origin hashes in our own Git history
<lfam>So for example, they will break the ability to build old Guix releases
<dstolfa>i understand why they are concerned about the non-free parts, but this is really bad engineering practice
<civodul>ah, so, it was right of mhw & co. to run the patching process on the vanilla kernel tree
<lfam>I agree, but they are going to delete the old patches as well
<nckx>It feels like vindication yes.
<lfam>I hope we can convince them to wait at least until we can download everything
<civodul>so there are several things we can do, and the easiest one is mirroring the useful tarballs
<lfam> https://linux-libre.fsfla.org/pub/linux-libre/releases/
<lfam>I don't have the storage on hand ATM
<lfam>We need the files named:
<lfam>deblob-5.13
<lfam> deblob-5.13.sign
<lfam>deblob-check
<dstolfa>it does seem like patching the vanilla kernel is a better approach in the future civodul
<lfam>deblob-check.sign
<lfam>For every release
<lfam>It's very urgent
<dstolfa>especially if they're just gonna rewrite git history every time they find anything
<nckx>dstolfa, civodul: I thought this is what Guix did?
*civodul has a pile of urgent things to work on
<civodul>nckx: yes
<nckx>I can no longer follow every turn in this saga, did that get reverted again?
<nckx>OK.
<civodul>i mean, we probably already have copies of everything
<civodul>but we need to double-check and gc-protect them
<lfam>I think that CI garbage collects them aggressively
*dstolfa clones linux-libre locally just in case
<lfam>Thank you dstolfa
<dstolfa>lfam: i found a number of git repos, which one is the right one?
<lfam>Actually I do have a spare terabyte
<lfam>Can anyone suggest a wget or curl script to download all those deblob* files?
<civodul>so, we could ask the .drv of each linux-libre package to the data service
<civodul>and then build all the source derivations on berlin
<civodul>we can have a shell script like you suggest lfam
<lfam>dstolfa: I would try this one: https://repo.or.cz/linux-libre.git
<nckx>lfam: I'm just downloading the whole thing with wget -m -np .
<lfam>Thanks nckx
<lfam>It might be really big / too much for their server if you don't limit it to the deblob scripts but it will still work
<nckx>The files are tiny; it's almost done; anyone can do this.
<lfam>Oh okay
<lfam>I misunderstood what was distributed there, I suppose
<nckx>Nah, I too was expecting tarballs in every subdir but that's not the case.
<maximed>does someone have some kind of bench mark for testing optimisations of the computation of derivations?
<lfam>nckx: I guess the full tarballs only exist in the latest releases
<maximed>I was thinking of running "time guix lint -c derivation"
<maximed>and "strace -c guix lint -c derivation"
<muradm>hello guix
<nckx>I wonder how SWH will handle rewritten git history (it should; that happens out there; I'm just curious).
<nckx>Hi muradm.
<dstolfa>lfam: i have a clone of the repo on 12 disks running ZFS, the only way that's getting lost is if i run out of space and it's not needed anymore, or if 3 disks die at the same time
<civodul>maximed: "guix build libreoffice --no-grafts -d"
<lfam>Thank you very much dstolfa
*nckx has a clone of the repo on like the SSD in their laptop which they can actually grab it when the house catches fire, checkmate.
<lfam>I'll send an email to guix-devel summarizing the situation and starting the discussion about what to do next
<nckx>Thanks flam.
<nckx>Also, lfam.
<civodul>cbaines: does the Data Service have an API that would allow us to map linux-libre revisions to their source (fixed-ouptut) derivation?
<lfam>I feel like flim flam
<dstolfa>nckx: can you give me the wget you used to get a copy? i'll run it too
<civodul>my data-service.scm client doesn't have it
<nckx>dstolfa: It was just ‘wget -m -np https://linux-libre.fsfla.org/pub/linux-libre/releases’
<nckx>It has hit tarball land now.
<nckx>Hm. Still, I should have the space.
<lfam>Yeah, it should only be the last few releases IIUC
<nckx>I'd rather have a coherent copy than realise I mirrored too little too late.
<lilyp>nckx: Given that SWH is content-addressed, wouldn't it just cache a version that's no longer referenced indefinitely*?
<lilyp>[*] Up to limits of memory
<dstolfa>nckx: running it
<civodul>lilyp: problem is that SWH archives "contents", not "containers" such as tarballs
<civodul>but we can have it archive the Git repo
<civodul>what's the URL again?
<lfam>I'd need to double check but I think it is <https://repo.or.cz/linux-libre.git>
<lfam>Or maybe <git://linux-libre.fsfla.org/releases.git>?
<lfam>Not sure
<civodul>tx
<lfam>Why not do both
<dstolfa>yeah, i'm doing both + doing the nckx wget
<nckx>I have a git clone saved as well.
<nckx>Lurkers included, I'm sure we have a good back-up by now ☺
<civodul>git://linux-libre.fsfla.org/releases.git is on SWH
<civodul>i made a request for the first one
<muradm>somethings under fire?
<lfam>It looks like <https://repo.or.cz/linux-libre.git> doesn't include the signatures, so it's not sufficient for Guix
<lfam>muradm: The source code we use to build linux-libre is going to be taken offline
<dstolfa>i feel like the fsfla site is being hit pretty hard with downloads lol
<civodul> https://archive.softwareheritage.org/browse/origin/directory/?origin_url=git://linux-libre.fsfla.org/releases.git
<dstolfa>sometimes it takes a few seconds for wget to respond
<lfam>Yeah dstolfa. My impression is that it's a regular server, and not a massive server farm
*civodul just noticed the "regular crawling" listing at https://archive.softwareheritage.org/
<nckx>Not here, despite me being quite a ways from LA.
<dstolfa>yeah it's zooming past for me too now
<lfam>I think the problem is probably storage / paging
<lfam>The lack of storage capacity on that server is why we don't build from linux-libre tarballs; the tarballs are deleted frequently to save space
<civodul> https://archive.softwareheritage.org/browse/origin/branches/?origin_url=https://guix.gnu.org/sources.json
*civodul also started wget on a machine with lotta storage + bandwidth
<maximed>civodul: I'll run "time ./pre-inst-env guix build -d axoloti-patcher-next@2.0.0 --no-grafts" instead because that takes longer, but thanks
<muradm>lfam: since when? or was it always like this?
<lfam>Always
<maximed>is there any particular reason for --no-grafts here?
<civodul>maximed: or "pigx", it's the package with the biggest graph
<dstolfa>alright, i'm preparing another backup in a datacenter. hopefully that'll be enough
<civodul>maximed: depends on what you want to benchmark, but if you want roughly package->derivation, then --no-grafts is what you need
<nckx>Before someone rings up fort Knox or that dodgy datacentre under a nuclear mountain thing, let's remember that tarballs regularly disappear because the author needed space, their $free Web host went tits-up, or they mistyped an rm without backups. Guix is ultimately the place to fix that if it's so important.
<nckx>The days before SWH were very dark indeed.
<lfam>Yeah it's true, but this is not "just some project". Most projects as foundational as the kernel do tend to get preserved both internally and externally. But linux-libre is kinda niche in general, while being crucial to Guix. So it's less likely that we'd find backups somewhere unless we made them ourselves
<nckx>I agree, and was going to add that but it was long enough already :)
<lfam>Tag team
<nckx>This is one of the not best packages for it to happen to, but it's a 'good' drill, no disrespect to the real pain it caused you.
<lfam>I definitely freaked out a bit. I thought I was merely going to have to adjust our tooling
<lfam>Which I am doing now
<lfam>muradm: Discussion from the early days of Guix: <https://bugs.gnu.org/14851>
<lfam>Haven't seen a bug number in the 10000s for quite some time
<dstolfa>this wget sure is taking a while...
<lilyp>btw. why do so many end-user packages propagate glib?
<lilyp>it used to be less, anecdotally speaking
<lfam>Not sure lilyp
<lfam>In what sense are you observing an increase in the number of packages propagating it?
<muradm>hmm.. me stupid since i can't use libre linux, was always thinking that it is just a set of patches maintained on top of vanilla kernel
<lfam>It is that
<muradm>but it seems they do it manually
<lilyp>lfam: I noticed that basically anything from the gnome metapackage propagates it somehow, which IIRC didn't use to be the case
<lfam>muradm: True, it's not just patches, but rather these scripts.
<lfam>muradm: They do it that way becaus otherwise the patch would contain the "nonfree" thing
<lilyp>I think at some point we decided to just "propagate anything pkg-config" and I'm not sure whether that's the correct move
<lfam>It's a bit of a parlor trick IMO but whatever
<lfam>lilyp: Right, I think the guideline was that anything listed in foo.pc "Requires" should be propagated, so a lot of things got propagated recently-ish
<lfam>Not sure about Requires.private
<lfam>lilyp: If it's a problem or if the situation can be improved, please start a discussion about it!
<muradm>hmm.. patch that would contain deletion of "nonfree" thing becomes "nonfree".. (face palm) :D
<lfam>Right
<lfam>The overall idea is to treat the nonfree parts like toxic waste: an elite team is designated to be able to handle it, and nobody else has to see it
<muradm>where do you know that vanilla-kernel -> some-magic -> libre-kernel is not compromized?..
<lfam>Who knows
<lfam>To be fair, Linux could be compromised in the same way
<muradm>ah, elite team... ok then.. :)
<lfam>And has been in the past
<lfam>Like the Linux release server was compromised
*dstolfa feels like this is so detached from reality that it would be funny if it wasn't sad
<lfam>It's not an easy problem to solve, if you share the values of their team. I'm not really sure how it could be improved given that starting point
<lfam>Personally I wish for a more pragmatic approach but there is some value in not giving in to pragmatism
<lfam>And I always say that "motivation is not fungible"
<lfam>People work on what they want to work on in the way they want to work on it. You can't really make volunteers do it differently
<muradm>it is always like that, invent a problem, which will require solution, that will spin more problems, what will require more solutions, so on.. :)
<lfam>That's one way of looking at it, but they also perceive problems that we do not, and that is why they decide to do it this way
<lfam>Like, to them, Linux is the problem because it includes parts that aren't freely licensed
<lfam>To me, that's no problem, because it's obvious that those things are not actually licensed in a problematic way. But to them, it's a big problem
<dstolfa>lfam: which parts of linux are not freely licensed (aside from firmware which is separated nowadays?)
<lfam>I think it's basically all the firmware and microcode
<muradm>to me licensing is a problem :) any way that is philosophy again :)
<lfam>But, it's not a problem *in practice*, as 30 years of Linux history demonstrates
<dstolfa>isn't firmware in a separate repository nowadays anyway?
<lfam>But it's the difference between "will I get sued" and "do I have source code"
<muradm>one should never say never.. )
<drakonis>dstolfa: it is indeed
<lfam>Maybe it's drivers that use nonfree firmware? I don't really know
<drakonis>is all firmware nonfree?
<dstolfa>no
<muradm>root cause is not laying with licensing/free/nonfree etc, it is beyond, these things are really just tiny subset of problem, thus one will always strugle to find workarounds for tiny subset of problem
<dstolfa>lfam: could i DM you?
<lfam>Sure
<maximed>drakonis: ath9k-htc-firmware is free, according to "guix show ath9k-htc-firmware"
<nckx>drakonis: No, firmware is just (cross-compiled) software. It's free (or not) because the author decides to make it so, not through any difference in nature.
<nckx>It's just very uncommon to do so ☹
<iskarian>morning Guix :)
<muradm>lfam: why not make a derivation that will be downloading vanilla kernel, downloading deblob script and applying it to vanial?
<muradm>then that derivation can be used as source for libre-linux?
<muradm>this way you don't keep vanilla kernel, you don't keep script
<lfam>That's exactly what we do muradm
<muradm>why then missing tarball of released libre-kernel tarball causes issue?
<muradm>if it is not used anyway
<iskarian>muradm, they also are going to remove/change the deblob scripts, as well as rewrite their git history
<iskarian>(just repeating what I read above :)
<dstolfa>lfam: i think my wget is about half way
<lfam>muradm: We started deblobbing ourselves after that bug report I sent you
<muradm>great then, why is https://repo.or.cz/linux-libre.git a problem? fgrep -r repo.or.cz/linux-libre <guix-src> gives no result
<dstolfa>muradm: AIUI, they are going to force push and rewrite history
***avoidr is now known as Guest7382
***avoidr_ is now known as avoidr
***Xenguy_ is now known as Xenguy
<lilyp>what was the emacs command to generate a pair of copypaste scissors again?
<bricewge>`message-mark-inserted-region`
<bricewge>I wished that command name would contain "scissors". It's not easy to remember it
<nckx>lilyp: If you're in message mode, the binding is C-c M-m.
<nckx>Only then tho'.
<lilyp>gotta alias it to M-x scissors
<nckx>My wget ‘almost done’ above was hilariously off the mark.
<nckx>It's still running.
<dstolfa>nckx: yeah... same
<nckx>With scissors.
<dstolfa>i'm on 4.4
<dstolfa>you?
<dstolfa>4.4.281 specifically
<nckx>It first fetches all indexes.html, then goes back to download the other files.
<nckx>4.4.123.
<nckx>Damn, you passed me.
*nckx → foods.
<dstolfa>i mean, i am running this on a 1000/1000 connection
*dstolfa is in 5.x land now
<nckx>Is in not-gigabit land.
<muradm>lfam: since i didn't get feedback yet on seatd-greetd-services thing, i'm going to prepare another update with these anyway now https://paste.rs/LVh .. :) one of things is to move seatd into gnu/packages/admin.scm as we discussed, currently no package seems to depend on it, so i suppose it is safe to move the package straight away, right?
<lfam>Yes, please send a revised patch series
<muradm>okay
<minikN>Hello, I'm trying to run blueman-applet from the console, but I get this error: https://pastebin.com/raw/Ab348hfQ (debian paste doesn't work for me atm). Any ideas?
<minikN>If I run the dbus command manually, it fails with "Autolaunch error: X11 initialization failed." (I'm on wayland using sway), if that helps
<bricewge>Why do we still have `xf86-video-intel` as a default xorg module?
<bricewge>Debian detracted it 5 years ago https://www.phoronix.com/scan.php?page=news_item&px=Ubuntu-Debian-Abandon-Intel-DDX
<muradm>lfam: another thing is seatd source can build libseat library and seatd daemon in two build commands, or both in one go, i could a) specify multiple outputs b) provide 2 separate packages, i'm for 2, personally. but this will duplicate version and hash twice, adding something function in gnu/packages/admin.scm like (define (make-seatd-source) ...) is fine? rather than copy pasting (source (origin between two packages
<muradm>ah never mind, i will inherit seatd
<lfam>muradm: Use your judgment about which is better
<bricewge>For a month or so I reverted the commit dropping linux 5.12 support as I thought it was the only working kernel for my computer.
<bricewge>But it turned out removing `xf86-video-intel` from `xorg-modules` "fixed" it. I can now use linux 5.13
<nckx>Probably because it didn't break anyone's set-up until now.
<bricewge>muradm: I wanted to review your patchset about seatd, but didn't find the time to do it yet
<nckx>I'm 100% certain it's not a positive choice to stick with the DDX driver.
<bricewge>muradm: Tho I wondered why your implementation try to replace elogind or don't depend on it while sead's README says “[seatd] will not displace systemd-logind anytime soon, [...]”
<bricewge>?
<bricewge>nckx: Do you know which of the other xorg modules should be dropped from default?
<muradm>bricewge: sway outsources seat management to libseat library, which provides minimal seat management interface. sway will not link with elogind/logind soon (wlroots to be correct).
<muradm>since users still depend on elogind/logind, they don't want to alienate them, libseat provides multiple backends, one for logind/elogind one for minimalist seatd replacement
<bricewge>nckx: Changing this default looks like it could break the config for some people
<muradm>who wishes to continue logind/elogind usage for their seat/session management, can continue to do so
<nckx><looks> Is that based on (wise) caution or some more specific concern?
<nckx>bricewge: ☝
<muradm>i'm quite minimalist, so i dropped elogind service on my host for instance, :)
*nckx eats Wayland® brand cat food so won't be changing anything in the Xorg recipe.
<bricewge>nckx: Nothing wise, only supserstitions
<bricewge>muradm: “(provision '(seatd elogind)” doesn't allow someone to use sead and logind services together
<nckx>I thinks it would be OK to update the configuration in good faith, it's hardly wanton to remove a driver that Debian(!) removed 5 years ago.
<bricewge>Ok, I'll send a patch remove that specific driver then and try to open a discussion for the other DDX
<muradm>bricewge: it is like elogind -> libseat -> wlroots/sway, or seatd -> libseat -> wlroots/sway
<muradm>that thing of (provision '(seatd elogind)) i explained before, check docker-service-type, it requires elogind, just because it needs cgroup file-system mounted
<muradm>which currently being mount by elogind only
<muradm>we should be spliting cgroup file-system mounting to separate service
<muradm>and depend elogind and docker-service on it
<nckx>bricewge: Excellent plan.
<nckx>Thanks for taking care of a forgotten corner.
<muradm>for now i put provision '(seatd elogind) which can then be refactored
<muradm>i didn't want to either touch or break docker-service-type for those who decide to use seatd in place of elogind
<muradm>once we make seatd in, i can then provide a fix for docker-service-type with refactored elogind/seatd and new cgroup-fs-service-type or a like
<muradm>touching everything at once not good i think
<bricewge>Yes of coursee
<bricewge>I think I confused seatd and libseatd
<muradm>bricewge, no issue :) i was same until sorted out things, now in todo https://paste.rs/LVh there will be two packages libseat and seatd, that would also help to people to make it clear
<bricewge>Thank you for the explanantion :)
<bricewge>I'll do my best to send a a review to the patchset
<nckx>“libglvnd is a vendor-neutral dispatch layer for arbitrating OpenGL API calls between multiple vendors […] and determines which vendor to dispatch each API call to at runtime.” Both ‘vendors’ here scan oddly (you're not sending RPCs to Nvidia's head office) and seem to be mere euphemisms for ‘proprietary driver’. Is that correct?
<muradm>bricewge, if you whish just wait, i'm preparing v6 now, then we can go over it
<muradm>i was using libglvnd when i was on arch, with my integrated intel and nvidia eGPU :)
<muradm>no RPCs, but OpenGL API yes :)
<muradm>vendors i suppose means openGL interface implementation vendor
<nckx>That was a bad joke :) I'm still catching up with stuff that happened over the summer so maybe this was discussed, but this package sends out hella nudge-nudge-wink-wink vibes.
<nckx>But I'm not a computer graphics person, maybe ‘vendors’ other than Mesa actually exist?
<muradm>me also, but as far as i understand, each graphics card "vendor" provides their implementations
<muradm>while some could be included in open source, some are not
<nckx>But are any of those free?
<nckx>Ah, some are?
<nckx>Great.
<muradm>it is not like opengl library is free and works for every case
<nckx>Sorry, I can't parse that.
<muradm>opengl is spec, which is to be implemented and provided by graphics card vendor, implementation does hardware thing normaly
<nckx>That I know. But the only free implementation I know of is Mesa.
<nckx>I don't (yet) see why it needs to be abstracted.
<lilyp>I think since mesa wants to use libglvnd, it's more low-level than that, think nouveau vs. whatever we use for AMD?
<nckx>I thought it was application <-> libglvnd <-> mesa <-> driver.
<nckx>Did I get that wrong?
<lilyp>though tbf I too think you're right on the wink wink nudge nudge thing
<muradm>mesa -> oss-driver-gl, mesa -> libglvnd -> closed-driver-gl
<nckx>Where the other scenario is application <-> libglvnd <-> proprietary garbaggio <-> driver I guess I don't know
<muradm>something like this
<muradm>when you have multiple graphics cards, mesa will go to libglvnd for oss-driver-gl also
<nckx>OSS is sound?
*nckx mas confused.
<muradm>i meen, open sourced driver
<nckx>Gotcha.
<dstolfa>nckx: how's your download chugging along
<nckx>4.14.
<nckx>29G.
<dstolfa>i'm at 36G on this machine... 2 more are downloading
<nckx>muradm: Thing is, why is Guix retargetting its Mesa on core-updates to use a backend specifically (and only?) to support non-free graphics drivers? That's my understanding.
<nckx>That sounds... not good? Bad, even?
<lfam>I'm at 109 GB here
<nckx>Stupid ocean.
<dstolfa>lfam: flash storage or just ocean? :D
<lfam>I'm in North America and it's spinning rust
*nckx has flash.
<dstolfa>ah, i'm downloading it on rust
<lfam>I think it's a matter of latency
<dstolfa>(no, not that rust)
<lfam>Network latency
<nckx>The faster rust.
<muradm>nckx, why libglvnd is retrograding? :) as far as i remember, issue was that mesa was loading opengl library from single place only
<muradm>assuming that you may have even good hardware like intel and amd graphics in the system at once
<muradm>mesa was not able to load their opengl libs at the same time
<muradm>there was conflics like one overwrites another etc. :)
<muradm>what libglvnd does, overwrites all of them, and puts it self into default location :)
<muradm>but knows how to lookup others, and dispatches calls
<muradm>was it changed for mesa in last 3-4 years i'm not aware
<muradm>Nix was also specially handling libglvnd
<muradm>for that reason
<muradm>of library resolution for mesa
<nckx>muradm: I don't know if it's retrograding. My very, very early understanding (which may well be wrong) was that Guix had an extra indirection library inserted into its default GL stack only and explicitly to support proprietary ('vendor', winkywink) libraries.
<muradm>if you just have libglvnd as a package, i suppose it would not be enough to just use it
<nckx>What Nix does here might not be relevant; they support non-free software.
<lilyp>I think the question is this: What does libglvnd enable you to do with only free software, that you can't already do with only free software sans libglvnd?
<nckx>There's not always a sharp line of what the right thing is for Guix, but ‘adding code & complexity that is only useful on non-free systems’ always crosses it.
<drakonis>lilyp: better foreign system support
<nckx>Not saying that's happening; literally can't say; hence questions.
<nckx>At least if that code is run/installed by default.
<lilyp>drakonis: as in "foreign blob support"?
<efraim>FWIW Debian uses libglvnd
<sneek>efraim, you have 1 message!
<sneek>efraim, iskarian says: Thanks for letting me know. If you're interested, this is regarding https://issues.guix.gnu.org/49921
<nckx>If this unbreaks things on FSDG-OK foreign systems that previously didn't work well with Guix, all is swell.
<efraim>sneek: botsnack
<sneek>:)
<nckx>For example, because Mesa's free libGL is all over the place on $random_distroes.
<nckx>But only if that's actually true and not a fig leaf. :)
<nckx>lilyp: Your message got lagged, but exactly.
<muradm>nckx: so me as user is not allowed to run non-free software if i install guix? :)
<nckx>I don't believe anyone is saying that.
<nckx>But Guix won't provide APIs that are useful only to non-free software.
<nckx>Well, that's probably not true in practice because one of our 20k packages probably does just that, but we won't *knowingly* put *effort* into complexifying Guix and maintaining more code just to enable that.
<muradm>does it mean that providing library that can load non-free library is providing api that support non-free software?
<nckx>Obiously not.
<nckx>If it is designed to only be able to load one specific non-free library, then yes.
<lilyp>muradm: *only* non-free software
<muradm>in the end of the day, guix it self is not providing api by including some library
<nckx>Correct.
<nckx>That is not the issue.
<muradm>just trying to understand, where does it writes that libglvnd is only for non-free software? :)
<lilyp>vnd stands work "vink vink nudge nudge"
<muradm>if i will want to develop my open sourced hardware and software card, until mesa does not inlude support for it, what can i do?
<lilyp>*stands for
<nckx>But if the graphics stack of Guix is now more prone to breakage because of libglvnd *and* it turns out that libglvnd provides no value to free software users at all, that means all Guix maintainers are wasting effort (core-updates debugging, etc.) maintaining a more complex stack just to support your non-free driver. That's not OK.
<nckx>muradm: Depends on why Mesa won't support it (and why are you then writing your own GL, which is presumably more work)? I'm less interested in hypotheticals that aren't than about the current state of things that are.
<the_tubular>Can a profile use more than 1 manifest file ?
<lilyp>the_tubular: yep, just pass them all via -m
<the_tubular>Nice :)
<lilyp>it will be merged into a big manifest tho, so you have little benefit
<lilyp>except that you can mix and match and version control I guess
<the_tubular>Yes mix and matching is what I want to do
<muradm>just checked core-updates-frozen/gnu/packages/gl.scm, libglvnd is not dependecy for anything as far as i see, so it is like in the path of "graphics stack"
<muradm>by that logic of course it can be dropped, as for me as user if i need it, i can include in my channel or whats so ever.. :)
<minikN>Hello, I was away for a while. I had the error starting blueman-applet, has there been a response?
<nckx>muradm: That's reassuring, thanks.
<nckx>As noted, still catching up, and waiting until code hits the fan to raise objections is not very fair either :)
<lfam>Hopefully we don't have an issue with linux-libre-headers-5.4.20, which is used to bootstrap Guix
<muradm>nckx: in my opinion as developer, it is nice to have library.. :) if i would decide to develop my own graphics card :)
<nckx> https://issues.guix.gnu.org/49339 mainly.
<nckx>muradm: Having or not having a library is not, at this point, an issue I'm concerned about.
<muradm>now i see :) yes, that will make users life easier to use n-word vendors i suppose :D
<muradm>if it is not the goal, then yes, it should be removed, and user will have to rebuild mesa if needs that
<muradm>which is the case currently anyway :)
<nckx>Right.
<nckx>Conversely, if current or future Mesa makes it almost impossible to build without glvnd support, even if it is purely to support malware, I'm not saying we have to spend excessive effort to undo that. It would just be… unfortunate.
<nckx>Guix maintainers would still be sponsoring non-free software, they'd just not have any choice.
<muradm>nckx: https://archlinux.org/news/mesa-with-libglvnd-support-is-now-in-testing/
<bricewge>minikN: Did you checked if you have correctly setup dbus?
<minikN>bricewge: No not really, however `ps ax | grep dbus` reveals several dbus processes, including `dbus-daemon`
<minikN>Actually wait
<muradm>nckx: https://bugs.freedesktop.org/show_bug.cgi?id=92877
<minikN>bricewge: This is my service setup: https://paste.debian.net/1210418/ base-system-packages is just my own definition of `(modify-services %desktop-services ...)` from another file
<nckx>muradm: Ta.
<minikN>bricewge: If there is special configuration dbus needs on Guix than I'm not aware of it. Please share. The snippet above is the only configuration regarding blueman for dbus I could find.
<bricewge>I'm not sure if your config is correct, as dbus-service seems to be wrapper (at first glance
<bricewge>I have found this in my config `(simple-service 'blueman-dbus dbus-root-service-type (list blueman))`
<dstolfa>lfam: my checkout is almost done. i can provide a download link through nginx if needed at some point
***Xenguy_ is now known as Xenguy
<bricewge>minikN: Yup, your `modify-services` is noop, you need to modify `dbus-root-service-type` in place of `dbus` with a `dbus-configuration` record
<minikN>Yeah you're right..
<bricewge>`modify-services` should at least warn the user in such case
<podiki[m]>nckx: catching up on messages here, re: libglvnd, we removed that change for the mesa update
<podiki[m]>it is just a version bump (and there is a patch for core-updates-frozen to go more up to date, mesa moving much faster than our core-updates process)
<minikN>bricewge: Can yuo tell me what the `dbus-configuration` object has to contain? Can't quite figure it out.
<podiki[m]>as per the discussion on those patch threads, probably using libglvnd with mesa will require some minimal changes to dependents that hardcode libgl library locations, and at least then current guix stuff should work the same
<podiki[m]>as for what that gains us in the non-free space, not sure
<podiki[m]>at least one application I think is with multiple graphics cards, where you need different libgl providers
<minikN>bricewge: I tried `(service dbus-root-service-type (dbus-configuration (services (list blueman))))` but I guess this is wrong, giving me: `guix system: error: more than one target service of type 'dbus'`
<bricewge>minikN:Yes you etheir need to modify the dbus-root-service-type or expand it (like the snippet I shared previously)
<podiki[m]>(mesa has also had libglvnd support for ~4 years, don't see why they would require it, but what do I know)
<minikN>bricewge: I tried your snippet: https://paste.debian.net/1210424/ unfortunately the error didn't change.
<minikN>bricewge: Sorry I restarted in case you said anything.
<bricewge>Can you share you whole OS with the specific error for that OS?
<minikN>bricewge: Sure, whole system is build from two manifests (2nd inherits from 1st): https://paste.debian.net/1210425/ and https://paste.debian.net/1210426/
<roptat>I'm having an issue pulling on armhf again, not enough memory :/
<roptat>guix-packages-base requires more than 2GB!
<roptat>and it doesn't swap at all
<civodul>bah :-/
<civodul>you're entirely sure it's guix-packages-base.drv eating this much?
<roptat>yep, I just stopped it and now my ram is at 6%
<roptat>(out of 2GB)
<roptat>when building, it was at 98% full, until it fails and stops doing anything
<civodul>terrible terrible :-/
<civodul>is it at --cores=1?
<roptat>ah no it's not
<civodul>how many cores?
<roptat>2
<civodul>ok
<civodul>and you're pulling a recent revision?
<roptat>yes, from yesterday I think
<civodul>built with Guile 3.0.7 and all
<civodul>ok
<minikN>bricewge: And the error starting `blueman-applet` is https://pastebin.com/raw/Ab348hfQ (I can't post that on debian paste for some reason)
<bricewge>I don't get, it did you to reconfigure your OS?
<bricewge>If so is there any file like “/etc/dbus-1/system-services/org.blueman.*”?
<minikN>After I added your snippet I cd'ed into the folder containing the scms and ran `sudo -E guix system reconfigure -L . ./geekcave.scm`. Contents of `/etc/dbus-1/system-services/`: https://paste.debian.net/1210428/
<bricewge>Ok, the OS configuration is correct since you have blueman files in /etc/dbus now
<bricewge>Try `sudo pkill -u messagebus -SIGHUP dbus-daemon` to reload it's config
<bricewge>Then I guess blueman should work (or after a reboot)
<minikN>bricewge: Doesn't work unfortunately. I also rebooted several times already. The error is still the same.
<bricewge>If not run blueman with strace and share its log
<bricewge>And what is the output of `env | grep -i DBUS` ?
<minikN>bricewge: `DBUS_FATAL_WARNINGS=0`
<bricewge>You are missing "DBUS_SESSION_BUS_ADDRESS"
<maximed>patch series for making 'search-patch' faster --> https://issues.guix.gnu.org/50384
<minikN>bricewge: Should this be set automatically or did I miss some configuration?
<bricewge>Your window manager should be srated with "dbus-launch " command to get the approriate environment variable
<minikN>bricewge: I'm using sway. I did not add any specific configuration apart from using sddm instead of gdm (because apparently it doesn't work with sway). The exec command in `/gnu/store/qsbdijqvq1wzf65xlflkcb2yj246s1nc-sway-1.5.1/share/wayland-sessions/sway.desktop` is just `Exec=sway`. I reckon this needs to be altered?
<civodul>maximed: sounds nice!
<bricewge>minikN: IDK, I'm not using thoses tools
<bricewge>Maybe just try `dbus-launch blueman-manager` at first
<maximed>civodul: I'm not sure if it actually improves things though
<minikN>bricewge: that actually worked.
<maximed>the syscall count is better, but the result from "time" isn't
<roptat>civodul, it's no better with -c
<roptat>-c1
<minikN>bricewge: Thanks for your help!
<bricewge>You're wecome :)
***sneek_ is now known as sneek