<nckx>Some (transitive) dependency of zrythm-next keeps a dependency on coreutils. Not surprising to be honest, it's not seen as a problem because ‘you'll have it anyway’. But I agree for packs it makes little sense.
<alextee[m]>i guess the only solution is to manually clean these?
<alextee[m]>i want to make omni-installers but i can't ship 200 mb worth of crap :-)
<alextee[m]>well, crap = useful stuff that's just not needed at runtime
<nckx>It's the quick & dirty solution. The right solution is finding out who's depending on coreutils & why.
<nckx>There's a system shepherd that runs your system services, and you can run your own instance of the shepherd to do the same for ‘user services’, like, ehm, your emacs daemon (silly example but that's the only thing I use it for).
<nckx>The user shepherd isn't handled by Guix at all, it's something you configure to start when you log in, and that's desktop/whatever-dependent.
<ryanprior>lcatcat: you can roll-back your package update with `guix packge --roll-back`
<marusich>lle-bout, OK. I totally rabbit-holed a different thing, and now I'm exhausted, so I don't think I'll have time to work on this today, but tomorrow I'll try to find some time to pick apart that commit into a few individual patches we can submit to guix-devel for review.
<lle-bout>marusich, I'm sorry I didnt do that directly, I'm very unfamiliar with GNU Guix contribution guidelines for now
<marusich>That's OK. Which parts do you think are necessary for building functional bootstrap binaries?
<marusich>e.g. the part that adds powerpc64-linux as a supported platform, is probably not necessary for that
<marusich>but, to vet the bootstrap binaries you gotta build something, and to build something, you gotta make it a supported platform, i guess
<marusich>point is, I would like to limit the first set of changes to those we believe are sufficient to build bootstrap binaries. Ideally they would be reproducible binaries, and they will work when we follow up with more changes to enable building packages from tem.
<marusich>e.g. the parts where you added the bootstrap binaries and their hashes, are not strictly necessary for building functional bootstrap binaries
<marusich>I intend to put those into a separate patch series, if possible.
<marusich>They like to split changes out to their smallest conceptual purpose, generally.
<marusich>going afk now - talk to you more tomorrow!
<lle-bout>sneek later tell marusich I was curious what you were rabbit-holing - and to respond - AFAICT the only patch needed on current master to *build* the bootstrap binaries is the one adding: ((string=? system "powerpc64-linux") "/lib/ld64.so.1") - otherwise, to use the bootstrap binaries, glibc and binutils-final changes are required.
<janneke>hmm, there's a build substitute, but no log file
<janneke>bah, --no-substitutes does not carry over to the offload server
<xelxebar>Asked this yesterday but went to bed and my logs may have cycled out the answer:
<xelxebar>When building with --check --rounds=2 and there's a discrepancy between rounds, sometimes I get two outputs in the store foo and foo-check
<xelxebar>The failure message is something like "Outputs differ between /gnu/store/..-foo and /gnu/store/..-foo-check"
<xelxebar>However, most of the time, the message just ends "output differs"
<xelxebar>What am I missing that's causing different outputs and error messages, and how do I get the *-check one back?
<terpri>i fixed it! now to remember how to get this git commit into guix
<mbakke>xelxebar: it's a bit confusing, --rounds only take effect with normal build commands, while --check only works when you already have the item in your store (and --rounds does not apply to --check)
<mbakke>xelxebar: in in all cases, you need --no-grafts to prevent testing the grafting process
<mbakke>as well as --keep-failed to actually save the result
<terpri>i'm quarantined at home nursing a seriously ill roommate, who would be in hospital in any civilized nation, so i wasn't at the protest itself. otherwise i'd have been teargassed or worse
<terpri>friend in SF was gassed, cops are using chemical weapons, flashbang grenades, rubber bullets, beanbags, possibly real bullets against peaceful protesters
<mbakke>terpri: excuse my ignorance, the riots are protesting police brutality, right? and the police answers with deadly force?
<terpri>mbakke, yes, the protests were sparked by the murder of george floyd in minneapolis, minnesota. he was handcuffed and facedown on the pavement, and a police officer, derek chauvin, kneeled on top of him until floyd died, while floyd was begging to breathe and begging not to be killed
<terpri>(there are other recent incidents of police brutality/murder, but that's the straw that broke the camel's back)
<terpri>people organize peaceful protests, and police come with teargas and mace and other weaponry and attack whole crowds of protesters
<terpri>not certain if there's been more "deadly force" just yet, but probably so, they are using "less lethal" weapons constantly on thousands of people
<terpri>the protests were initially confined to minneapolis but have grown explosively across the entire country, coast to coast
<terpri>and our militarized police forces are brutalizing peaceful protesters in almost every major city
<terpri>rioting is escalating (as the police continue to incite them) and there are cities with entire blocks on fire
<terpri>i imagine Democracy Now! (https://www.youtube.com/user/democracynow , obviously recommending newpipe etc. rather than youtube's proprietary JS) would be a good non-corporate news source for non-americans who want to keep tabs on the situation
<mbakke>local media reports that the president blames the riots on "radical left wing groups" which does not sound like he is interested in a diplomatic resolution :-/
<nckx>(Note for non-USians: ‘incitement’ is American for ’shooting at people’. This is not some yelling riot cop on a front page.)
<Hugal31>Is there a way to know why guix doesn't look for a substitute? I have a substitue server and a client that authorized this server, and it worked for installing the curl binary, but now when I want to install iotop, it want to build the iotop derivation along with a big number of dependencies, although the derivation is built on the substitute serve
<guixer>Hej guix! I'd like to configure my user services properly with shepherd. But I don't get why it behaves like it does.. I have set #respawn? #t but if I kill a service process with pkill, the service does not rerun its command. Instead herd status actually tells me that the service is still running. Any hints?
<TBC_x>How do you chroot into guix system from another distro?
<guixer>mbakke: some services use make-forkexec-contructor and some the system-constructor. I used & to put some of the commands in the background, that might be the issue.. I'll have a look into removing thos and check out #:pid-file :). thanks
<mbakke>guixer: there is also fork+exec-command, but I'm not familiar enough with the shepherd to give good recommendations
<guixer>mbakke: make-forkexec-constructor builds on fork+exec-command. what are you using to control user services?
<TZander>absolutely. The CI website is frustrating for me to use, the dependencies would be nice to show (and their status).
<TZander>can I search for queued, but not yet build, packages? If so, how?
<TZander>For instance, I'm wondering what happened to the aarch64-linux build of 'master', package flowee.
<cbaines>I guess this search sounds like it does what you want: spec:guix-master status:scheduled system:aarch64-linux ^flowee
<cbaines>Although I get back builds that don't have that status, so I'm not sure if it's right...
<cbaines>data.guix.gnu.org has some information from ci.guix.gnu.org. The advantage of using the Guix Data Service is that it knows how derivations relate to each other, and what derivations relate to which revisions
<TZander>ah, indeed. Weird that a normal search doesn't include "scheduled" status. I'd consider that one of the main reasons to use the website...
<cbaines>The disadvantage is that you don't know it the data is up to date, and I think it's been stuck updating recently, so it's not up to date
<butterypancake>what's the state of using npm and/or yarn on guix? I'd like to package signal-desktop but if npm and/or yarn isn't there, it won't be fun... From my perspective it looks like they aren't there...
<cbaines>butterypancake, I looked at this recently as well for Grafana, I think there's quite a bit more work needed
<cbaines>There has been some work on importers, but I think more is needed
<nckx>Hm, seems that our node package is now broken.
<cbaines>Hopefully with some progress there, we can get some of the common required packages in to Guix
<nckx>But it's not like everyone checks that page weekly.
<butterypancake>so for packaging, how free does a program need to be? Is open source good enough? Texas Instruments releases a bunch of opensource code but they don't really care a lot about licencing to the point that I'm not quite sure what the license on tilib even is
<TZander>so maybe the rule is relevant for guile, not so much for most compiled stuff...
<TZander>If I have a c/c++ library, and one uses Qt (as a simple example) there isn't anything I can do to make anyone trying to compile that NOT also require Qt. Since it needs those headers and it needs to have the .so's to link.
<cbaines>If you're talking about things like libraries, then they should be handled differently, and it's quite normal to propagate dependencies
<TZander>yeah, I would suggest propagation to be the standard for all libraries. Maybe not for apps (where there are no .so files installed)
<cbaines>So, taking krita and qtbase as an example, does krita directly stuff provided by qtbase?
<cbaines>If it doesn't, then there's an argument to removing that input, and doing something else
<TZander>krita has C++ code that includes headers from various KDE libs, and those inherit from (and thus include) header files from qtbase. At link time and at runtime they use the dynamic libraries from qtbase
<cbaines>I've just tried building krita without qtbase, and I got an error which suggests the karchive package should propagate qtbase
<cbaines>there could be others, I just looked at one error
<butterypancake>in the synopsis for tilib, should I put something like "You'll likely want to install the MSPDebug package to use this" and also put a thing in the MSPDebug package saying "If you are using X probe you'll want to install the tilib package"? Do we put suggestions in the synopsis?
<cbaines>TZander, feel free to send patches if/when you notice issues like this, it should be as easy as just moving the input from the inputs list to the propagated-inputs list, with the justification that it's required at runtime to use the package
<TZander>cbaines: maybe best to start with a comment and an awareness that propagated inputs are just fine in all libraries.
<TZander>It would help immensely if this is accepted to avoid having to have a justification. The justification is: its a library. This is how libraries work.
<cbaines>I'm not sure that argument generally applies though, the other inputs to karchive are zlib, xz and bzip2, and I'm not sure all of those are required to be pushed in to the profile where you're using karchive
<cbaines>just because it's important that some inputs are propagated, doesn't mean it's best to propagate all inputs
<guix-vits>butterypancake: We do put suggestions in descriptions: for example in `hackrf`
<mbakke>cbaines: great summary of the situation, I got rather triggered by the notion of propagating everything all the time :P
<cbaines>thanks, I think looking at specific examples helps
<butterypancake>tilib is needs for mspdebug iff your using a ti probe. so tilib would be an optional dependency if at all. But I think some other programs use tilib so I'm thinking they should just be two seperate packages?
<apteryx>TZander: keeping a profile as clean as possible is nice for the functional model. It helps avoiding unexpected interactions between the applications that share it.
<TZander>apteryx: yeah, for binaries and modules like guix that makes sense. As explained before by others. No doubt.
<mbakke>if you want a custom build of libfoo, let's say with -march=native, it would be difficult to use it in a profile if other packages needlessly propagate the vanilla libfoo
<TZander>when it comes to libraries (and indeed, bzip2 is a gray area because the package has both) I don't see it.
<nckx>TZander: That would make it impossible to combine two packages that link against 2 different builds of libfoo into the same profile.
<TZander>OK, how is this. All libraries always propagate their dependencies. (like kio propoagates karchive, and someone propagates qtbase) and applications (like krita) then have to have MUCH less inputs. Apps don't propagate anything. Nothing ends in the profile.
<nckx>How does that address any of the objections?
<mbakke>IMO propagating-by-default makes things less maintainable, because you can't be sure whether removing an input of Kio will dependent packages (that may or may not use it directly, you don't know)
<apteryx>yes, you shouldn't have to specify transitive dependencies of librairies of a package using said libraries. If you do, there's a problem with those libraries.
<apteryx>is there an issue # about this KDE libraries problem?
<TZander>I think this addresses the issues: All _libraries_ always propagate their dependencies, which are libraries too. (like kio propoagates karchive, and someone propagates qtbase) and applications (like krita) then have to have MUCH less inputs. Apps don't propagate anything. Nothing ends in the profile.
<TZander>apteryx: it would be unproductive to file a bug stating "we have 80+ copies of the qtbase input in the kde.scm file". I can file it with the proposed solution if people think the suggestion makes sense.
<mbakke>TZander: it does not address the issue where krita _directly_ depends on libfoo, which happens to be propagated by libbar, and removing libfoo from libbar would break krita
<nckx>nixfreak: We'll see; it might not do as much as you expect 🙂 (or it might work fine for your use case).
<nixfreak>I need to install antora which has dependencies in node using npm
<TZander>mbakke: If you write a cmake parser to find all the **direct** dependencies of an app, you can add that libfoo to the inputs of krita.
<TZander>otherwise I'm thinking you are searching for problems in order to avoid having to face that there is a massive duplication of effort that has piled up in the packages of guix
<mbakke>TZander: surely isolated to the KDE packages
<apteryx>the golden rule has so far been to propagate only when it is required. Without digging in, and knowing that KDE is C++ based, I can only guess taht the problem with KDE libraries is that *some* (constrast this with *all*) packages should have been propagated but haven't. I'm not a KDE person, but it seems unnecessary to unilaterally recommend that libraries always propagate their dependencies.
<nckx>TZander: I find your attitude quite inappropriate. You refuse to listen to the many objections to your (flawed) proposal then top it off with an accusation that others are making up objections in bad faith. Do with that information what you will but it just might explain why you haven't convinced anyone.
<nckx>Perhaps a calm and considered mail would be more effective.
<efraim>sefault in ly when I try to use it at boot
<mbakke>also, I'd appreciate if you grep the sources yourself instead of having me do it :-)
<TZander>What do you mean inkscape doesn't depend on them? Is the packaging wrong?
<TZander>you lost me... Why are these examples of what 'guix edit' shows not examples of how the number of inputs would be lower if libraries propagate libraries they depend on?
<mbakke>TZander: inkscape does '#include FT_FREETYPE_H' and 'png_create_write_struct(PNG_LIBPNG_VER_STRING', why should it not have freetype and libpng as inputs?
<TZander>because that is how c/c++ library dependencies wokr...
<apteryx>Are you arguing that every libs on Earth should appear under /lib and packages would find them automagically by side-effects without explicitly specifying them? That is starting to sounds a lot like what most distros do. Guix does it differently though, and I think it's a good thing.
<TZander>no, its not how distros work, its how dynamic libraries work
<TZander>do an 'ldd /usr/lib/libfreetype.so' and notice the output has libpng in there.
<mbakke>TZander: that does not mean that every user of libfreetype needs libpng.so available
<mbakke>TZander: well, in the case of libfreetype.so specifically, you are right, and which is why libfreetype propagates libpng
<mbakke>it does not logically follow that inkscape should not have libpng as an input
<nckx>mbakke: TZander misread your ‘does’ as ‘doesn't’, which explains much (but not all) of what followed.
<apteryx>nckx: very interestingly, the middle click paste issue came back to haunt me (until the next reboot, I guess).
<TZander>"that does not mean that every user of libfreetype needs libpng.so available" <-- this is demonstrably wrong, 100% of the applications linking against libfreetype need libpng in the container in order to compile.
<nckx>😃 (Not laughing at you, but at the sheer *tenacity* of this thing.)
<apteryx>nckx: yes, I thought for a while my mouse had a hardware issue, but it doesn't, and it affects any mouse.
<nckx>I'm tempted to think it is a hardware issue, just not on that side of the connection.
<nckx>Mainly to preserve my belief in a deterministic universe, but still.
<nckx>Or you have some weird forgotten Xorg.conf you're not telling us about.
<apteryx>TZander: the only reason freetype propagates libpng is to not break pkg-config when it's used in build systems. The comments says: "These are all in the Requires.private field of freetype2.pc.", when referring to libpng and zlib.
<lle-bout>hey, there's no lightdm service, how are we intended to use lightdm in GNU Guix? Or one just needs to contribute a service?
<nckx>lle-bout: It's currently in flux, so I'm not sure, but it is being worked on.
<lle-bout>nckx, okay, GDM has been too RAM hungry for me
<nckx>So probably still in ‘how do we DTRT’-limbo.
<apteryx>TZander: if you 'info "(guix) package Reference"', you'll find the common uses of a propagated inputs detailed in the documentation of that field.
<apteryx>quote: For example this [propagating an input] is necessary when a C/C++ library needs headers of another library to compile, or when a pkg-config file refers to another one via its ‘Requires’ field.
<lle-bout>nckx, I used sddm previously for Wayland with Sway and XWayland, but it seems SDDM runs in Xorg so there's both running in the background, so I removed SDDM entirely and started Sway from the command line directly.
<apteryx>haha, ok. Hm, I'd rather get rid of the old inskcape, as inkscape 1.0 is (supposedly) much faster when invoked to transform images at the command line.
<mbakke>apteryx: you'll have to wait for the next staging cycle in any case, by pushing to master at least users can start enjoying the new version :-)
<mbakke>apteryx: as a bonus, your friendly local staging herder will probably take care of getting rid of the old version when it is time
<butterypancake>how do I clear the cache for a package? It's having trouble unzipping a zip it downloaded so I want it to redownload the zip. The GC options don't seem to mention being able to specify a package. I see the option to remove the zip directly, but I'd like to clear everything related to this package
<butterypancake>also if anyone has experienced zip problems recently, I'd like to hear of those because I'm prety sure my downloaded zip is fine :/
<nckx>butterypancake: Whoah there, X-Y-Z problem I think 🙂 You can force a re-download of the zip file by changing the hash by one character, but that will just redownload the zip. What's the actual error?
<mbakke>i.e. does it have all the files directly at the "top level", instead of inside a subdirectory?
<butterypancake>so it says command "unzip" "/gnu/store/xxxxx-MSPDebugStack_OS_Package_3_15_0_1.zip" failed with status 127
<nckx>😃 Sorry. butterypancake: It's because unpacking happens during the *package* build, not the *source* build, and so the source would somehow have to influence the package inputs (ehh, probably nasty) or we'd have to add ‘unzip’ as a default input and where will that end.
<nckx>…in one extra input, that's rig—I mean madness!
<butterypancake>Now it's saying no makefile found? I'm so confused by this package. I create a guix environment and goto the folder and run make and see that it's supposed to complain that I don't have boost, not that the makefile doesn't exist...
<nckx>butterypancake: It *is* a zipbomp (Makefile is in the root directory, not nicely in MSPDebugfoo-x.y.z). Use url-fetch/zipbomb instead of url-fetch.
<nckx>If you don't, Guix playfully decides to chdir into the first directory it finds.
<butterypancake>oh, I get it. a zipbomb is when you make the zip wrong and ruin my entire day
<nckx>butterypancake: No, it's part of the source field. (patches (search-patches "foo.patch")), put foo.patch in gnu/packages/patches, add the patch file to gnu/local.mk (under dist_patch_DATA) — alphabetically of course.
<butterypancake>so I put 'command -v shepherd && shepherd' into my .profile so I could have user level services. The problem is that if I login twice, now I have two shepherds both running all my services and my services don't really like that. Also if I don't login, my services don't run (not a big deal really but systemd is nicer in this regard). Is there a solution for this?
<butterypancake>oh dear, I think the patch is supposed to be applied one directory higher. Ugh. How do patches work?
<rndd>hi! i'm trying to pull guix from my local copy (url "file:///home/myuser/..."). but there is the error "guix pull: error: Git error: object not found - no match for id (5c133ca561acfc1a1b9fe6dfc03d2bd12784242c)"