IRC channel logs


back to list of logs

<vagrantc>cbaines: subscribed, presumably needs to be moderated
<cbaines>vagrantc, yeah, I'm not quite sure who does that
<cbaines>anyway, good night o/
<vagrantc>hrm. would expect "guix pull --keep-going" to uh, keep going even if it fails to download a tarball or two
<vagrantc>i had assumed it was my proxy, but apparently is having issues:
<cbaines>vagrantc, the URL given has // at the beginning of the path, which I think is an issue
<cbaines>right, really leaving now o/
<vagrantc>it works when i download it a second time , though
<porcupirate>Well, now I know easyrpg player and liblcf need to be updated to 0.7.0 "sword"...
<porcupirate>I'll add easyrpg editor to the wiki wishlist
<jgart>Hi Guixers, wdyt?:
<jgart>I think gexp-inputs can be a useful function that can be part of the public interface. Why might this be a good/bad idea?
<jgart>I can send a patch for gexp-outputs if it makes sense to do so also
<porcupirate>Do I need special permissions to edit the wishlist on the wiki?
<jgart>the LibrePlanet one?
<jgart>I think you just need to register
<civodul>jgart: i'd rather not expose gexp internals
<civodul>there's lower-gexp if you really need something low-level
<jgart>ah ok
<jgart>I can close that then
<jgart>I can just email the following to without subject? `close 53330`
<jgart>Can I include other text in that email like github allows when you close an issue with a closing message?
<vagrantc>also works
<jgart>vagrantc, will the above work too?
<jgart>my above
<vagrantc>dunno, i always use -done :)
<vagrantc>and comment about why it's done
<jgart>NNN is the ticket number?
<nckx>jgart: Sending commands in the message body to NNN@debbugs would not work, it would just send a literal ‘close 53330’ reply. See <> for the available commands and the ‘control server’ address that accepts them.
<jgart>ah ok
<jgart>for clarifying
<nckx>Much arcane, very wizard.
<lispmacs[work]>hi, has somebody figured out the "sanity-check" python problem yet, which has affect numerous packages? I was particularly concerned about this package:
<lfam>I assume the package needs to add a dependency on 'reedsolo<=1.5.4,>=1.5.3'
<vagrantc>dunno if gnu's debbugs takes control pseudo-headers, e.g. "Control: close NNN" ... debian's does :)
*vagrantc hasn't used control@ for a long time
<nckx>I think it does, but (IMO) that's even mucher arcane and veryer wizard.
*vagrantc nods
<nckx>vagrantc: <hasn't> Are the headers preferred?
<vagrantc>nckx: i prefer them, as then i can address everything without having to remember to CC a different address
<vagrantc>e.g. i like to keep the action and the rationale all in one place
<ngz>TIL: gfortran is very _long_ to build =/
<porcupirate>Odd. I thought there was a nix importer...
<lfam>It was removed porcupirate. It no longer worked well --- even for a limited use case --- and all the simple packages had already been created for Guix
<lfam>Nobody stepped up to maintain it
<lfam>See Guix Git commit d95168321f4a9bf6857b598da0a183b45a868d54
<lfam>It was some of the oldest (if not the oldest) code in Guix
<nckx>lfam: Interesting, I didn't know that factoid :-) IIRC it was also unusual in requiring a locally running nix-daemon, rather than the ‘fetch and parse the nixpkg from GitHub’ that people expected from other importers.
<lfam>See this message nckx:
<lfam>So, it was definitively the oldest piece of Guix
<lfam>A bittersweet thing, to have outgrown it
<PotentialUser-5>is it possible to install guix without primary partitions count exceeded?
<Andrew>PotentialUser-5: The automatic installer (TUI) makes extended partitions
<PotentialUser-5>I don't understand, can you clarify?
<Andrew>PotentialUser-5: You want to install to a primary partition, or do you have all of them filled up?
<PotentialUser-5>I have 2 empty primary partitions and I want to try guix
<PotentialUser-5>I have bios mbr disk
<PotentialUser-5>selecting the partition gives me error
<PotentialUser-5>I am at Manual partitioning stage on the other computer
<Ribby>I just setup my gnu/guix interface design. Whew!
<lfam>The python-aiohttp fails to build since the version-1.4.0 merge
<lfam>It breaks ~280 packages
<Ribby>I like that xfce. It's lightweight, yet opts for stability of hardware operation. Might be as compatibility too.
<Ribby>Question: Will a wifi hardware work for the boot installation's download and build process? Or I am going too far in terms of compatibility.
<lfam>The aiohttp test failures... appear to be 47 occurences of an unhandled deprecation warning
<lfam>"E DeprecationWarning: The loop argument is deprecated since Python 3.8, and scheduled for removal in Python 3.10."
<Andrew>Probably not, if you need any nonfree drivers
<Ribby>Will any wifi hardware work at all? I know it's the "who's first, the chicken or the egg" loop, which is not any of them.
<Ribby>Yes, I'm talking about only using wifi, nothing else? Hahaha!
<lfam>Yes, some wifi hardware will work. But there are very few options
<Ribby>Those hardwares have connections with gnu...
<lfam>Say their name
<Ribby>I was figuring if a person relying on free internet service, needs to get on the boot installation's updates, what would be the options? I'm not going to blame for the situation in grasping straws.
<lfam>What hardware are you using?
<Ribby>Say who's name? I wouldn't even know until I research and test out stuff I guess.
<lfam>Basically, there are three wifi chips that will work on Guix.
<lfam>There are the ath9k chips
<lfam>There are the b43 chips
<lfam>And there are the chips supported experimentally by this project:
<lfam>I don't think there is anything else
<Ribby>Ok, I guess any chips associated with these brands have a chance.
<lfam>For example, ath9k is from Atheros. But there is only one chip from Atheros that works. None of the others work
<lfam>So, you have to choose carefully
<vagrantc>and not all the b43 chips work, even
<Ribby>Ok, that make senses.
<lfam>Probably, the best option is the chips supported by <>
<Ribby>It's a specialized product, I assume.
<lfam>They are sold in stores
<Ribby>The first in the list, bingo.
<Ribby>Or close enough.
<lfam>It might not work in the Guix installer, however. It requires an external kernel module that our installer doesn't include
<lfam>We should add the module to the installer for the future
<xelxebar>rekado_: Hey! Thanks for your pointers yesterday. I reproduced the missing Euler font error within a container. (FWIW, I'm already running on a guix system anyway, though).
<Ribby>The real question is if there is any wifi that could help download updates during a boot OS installation? Ethernet is obvious to go. Even a person relying on free internet service, ought to know how to use these cables for the boot updates.
<mroh>lfam: yes. rtl8821ce-linux-module also.
<lfam>I don't think there is any computer that comes with a supported wifi chip built-in
<xelxebar>rekado_: Still just a pebcak issue? If not, I'll file a report.
<Ribby>Of course, I am not sure if wifi can access private networks during the boot. Things could get very complicated. In fact, I am not sure how much use wifi would be compared to a direct ethernet connection. I suppose that maybe one cannot connect to the router or another client that allows download?
<lfam>So, on version-1.4.0, we updated python-tomli. This package has ~4800 dependents. But at least several hundred of them now fail to biuld
<rekado_>xelxebar: please file a bug report and Cc me. Thank you!
<Ribby>Is there a ethernet cable variant that can connect to another computer with internet access? I think such a device would be more useful than a wifi. It would be at least much faster than wifi. The only downside is that another computer would be preferably your owns!
<lfam>That's just a regular ethernet cable
<Ribby>So if a computer has more than one ethernet cable port, I could connect to the second port to access the network?
<vagrantc>you'd have to configure the computer to route the traffic somehow, but yes.
<vagrantc>there are also usb-ethernet adapters
<vagrantc>if you only have one ethernet port ...
<lfam>It's so frustrating that 240 packages are broken because python-black, a *code formatter*, fails to build
<Ribby>hmm... then my assumption on the requirement to carry around two computers for OS installation on free internet service is sound.\
<vagrantc>well, without making builds fail, many projects have a hard time following the coding guidelines ...
*vagrantc *coughs* guix lint
<Ribby>I'm sure there's a way to install another ethernet port, somehow.
<lfam>The linter is useful, but there's a good reason we don't allow it to break the build
<vagrantc>Ribby: there are also wireless routers with a single ethernet port
<vagrantc>lfam: i get that for sure
<nckx>What's the protocol for testing a graft?
<lfam>nckx: Testing which aspect of it?
<lfam>Like, did the references get rewritten?
<nckx>I'm grafting expat 2.4.3 over 2.4.1 and would prefer nothing asplodes due to ABI issues etc.
<Ribby>That usb-ethernet adapter would be useful for computers without a ethernet port.
<lfam>Ah, testing the deployment
<nckx>I guess.
<lfam>Check the soversions and make sure they are equivalent / compatible
<nckx>They are.
<lfam>Expat is a serious project so they will have handled that properly for a security update
<lfam>Beyond that, run some system tests, try upgrading your systems, etc
<nckx>lfam: soversion == SONAME?
<nckx>They matched.
<lfam>The thing that describes the ABI version
<nckx>It was just IIRC.
<lfam>Makes sense
<nckx>I have no idea when and where my system parses XML using expat.
<nckx>It's OK. I was just hoping for something more robust/codified.
<nckx>A checklist, if you will.
<lfam>You could check the dependency graph and see where the major part of the dependencies are introduced
<lfam>See if that program seems to be working
<lfam>It's a reason we try to avoid grafts, and try to limit their scope
<lfam>It's not possible to be sure
<lfam>But, I don't recall any issues with expat
<nckx>It just seems relatively easy to test an application and completely avoid all code paths that parse XML.
<nckx>All right.
<lfam>It's why I suggest figuring out where the 15k dependents are introduced. I assume there's a bottleneck in the tree
<lfam>It either uses XML or it doesn't
<Ribby>Plus, with usb-ethernet adapters, usb ports would be then essentially ethernet ports.
<nckx>That's certainly true.
<lfam>I think a lot of freedesktop stuff uses XML. Maybe it uses expat?
<lfam>Maybe check if the MIME database can still be built?
<lfam>Also, I always check that the references were replaced, "by hand". Like `guix gc --references foo` and compare the foo and bar derivations of the grafted and ungrafted derivations
<lfam>A simple sanity check
<lfam>I also check for packages that inherit from the replaced package. You have to make a judgement about what to do there
<lfam>I had hoped to avoid releasing with any grafts. Not sure why
<lfam>It just ratchets up the spooky bug factor
<Ribby>Otherwise, I guess you can unplug the public service's ethernet cable from their workstations. It sounds a bit unethical since you are using service without registered user authentication, but nevertheless, free direct internet service!
<nckx>lfam: Was the version-1.4 merge really the final rebuild?
<lfam>Well, it broke some things
<lfam>So there is still some work to do
<nckx>If not, and you're around and I'm not, sneak in an ungraft.
<lfam>I do think we can't afford any more world rebuilds though
<lfam>Like I said, we need to fix bugs. Not introduce them
<lfam>At least grafted bugs don't usually break builds ;)
<nckx>Grafting is fixing bugs.
<lfam>Yes, they fix some bugs with certainty, and maybe introduce some new ones. The circle of life on the bug tracker
<lfam>I'm working on this tedious Python-version requirement craziness
<lfam>God forbid we use the wrong version of the formatter
<Ribby>Another question to ask: Can I boot install guix without internet connection? If so, what would it look like? Is there (a showcase display of) a demonstration?
<nckx>Well, 8 of these bugs start with ‘CVE’, so they have excellent legal represantation and will make the flight regardless.
<lfam>Don't mind me. I am just CVEtching
<Ribby>About python, is it free software? Is it like the Windows that some come to fear?
<nckx>What initially worried me is ‘Link againgst libm for function "isnan"’ in the 2.4.2 changelog.
<lfam>Python is one of the greatest successes of free software Ribby
<vagrantc>Ribby: you'd have to get your packages or source code from somewhere, so you'd have to have pre-downloaded all the sources at least and build them
<nckx>Like, how could that break things in novel subtle ways.
<nckx>I guess we'll see.
<vagrantc>nckx: i have confidence in your ability to break things! :)
*vagrantc cheers
<nckx>‘guix pull: error: You found a bug’
<lfam>nckx: Is that one of the CVE fixes?
<nckx>lfam: No.
<nckx>Here's the log:
<lfam>Well, I would recommend trying to graft the full updtae. If that's no good, then we can probably find a CVE-only patchset to use
<nckx>If you are implying what I think you're implying, no way am I cherry-picking them.
<nckx>Good answer.
<lfam>I think they might offer a patch series
<lfam>I don't know, projects like expat often do
<lfam>Although I don't recognize the release manager for 2.4.3, so it may be different than in the past
<nckx>I'm completely unfamiliar with expat. I just noticed a security announcement in the mod queue.
<nckx>You are clearly more familiar than I am with expat upstream. It is unfortunate that you are tied up in more vital matters, and I am left to deal with trivia.
<lfam>I'm kind of tired of security updates
<lfam>They never end
<lfam>I want other people to try their hand at them
<lfam>What I was doing before was not sustainable for me
<Ribby>vagrantc: So the base OS files are on the servers and the boot install is just the core, bare bones, or installer? There is no OS without the server updates/upgrades then? I get that guix development is a ambitious feat. No doubt about it.
<lfam>If our security team is completely staffed by volunteers, it needs to have several of them.
<nckx>lfam: Just the volume or do you think your workflow was, in retrospect, flawed? What I'm doing here is certainly inefficient, but then I hardly ever graft things. I think it's been literal years.
<lfam>It was the unrelenting regularity... IMO, that's something that should be done by somebody that is paid, or by a team of volunteers spreading the work
<nckx>Even having to type ‘define-package…inherit…replacement’ is, honestly, a bit stupid. A waste of human time.
<lfam>Well, it's Scheme. I'm sure that somebody could write a script to handle it
<lfam>Anyways, to summarize, I burnt out on doing it as a volunteer.
<lfam>I would be ecstatic to be on-call for it if it was funded
<lfam>I would also join a team of volunteers. Already I still push security updates
<nckx>Somebody could. Nobody did. Doesn't bode well. I agree that dumping it all on one person at a time leaves nobody in the end.
<lfam>So, the only difference from before in terms of my work is that you can't count of me
<lfam>Which sucks, I know
<lfam>Can't count on me
<lfam>And, nobody ever asked me to handle it like I used to. It was fun for a while
<nckx>If that was your ambition or the pressure you felt, I'm glad you let go before you broke.
<lfam>It was mostly ambition
<lfam>I do think that being on-call for something like that would be a fun job
<lfam>Okay it's dinner time. See ya later
<vagrantc>the guix redphone
<nckx>‘The number you have dialled…’
<vagrantc>hrm, thought that was a general thing, but wikipedia focuses on the software
<nckx>I'd certainly expect people to get the reference.
<nckx>I'd never heard of the software.
<nckx>‘Red telephone’ will redirect you to the real one.
<nckx>(Despite the, yes, I know.)
<tribals>I'm trying to use host guix-daemon from within `guix shell --container`. I've first tried to share daemon socket only, this doesn't work - I can't install package. Then I've tried to share the whole /var/guix. It doesn't work either - still can't install package. But surprising thing is that after doing that I've noticed that passing whole /var/guix breaks my default profile on the host!
<jgart>lispmacs[work], if you want to bypass the sanity-check phase for now you can delete it until it gets fixed
<jgart>If it's blocking anything for you, that is
<lispmacs[work]>currently I'm just using time-machine to install into into a guix shell environment, when I need it
<lispmacs[work]>I tried using an inferior, but that created some propogated python conflicts with another package
<lispmacs[work]>mainly just don't want to see that python-esptool package bit-rot, since it is a very important tool for esp8266 programming
*v1dl00fyuq6f[m] uploaded an image: (214KiB) < >
<v1dl00fyuq6f[m]>Why is this not working? i am loosing my mindddd
*v1dl00fyuq6f[m] sent a scm code block:
*v1dl00fyuq6f[m] uploaded an image: (77KiB) < >
<v1dl00fyuq6f[m]>... at least i think that's posix ere
<v1dl00fyuq6f[m]>oh `sed -E`
<v1dl00fyuq6f[m]>thanks krey
***califax- is now known as califax
<v1dl00fyuq6f[m]>wow posix ere is so annoying
<v1dl00fyuq6f[m]>hmm is there a way to sanitize it? like if the `(substitute*` string was not matched to throw out error?
<v1dl00fyuq6f[m]>should be probably a default behavior now that i think about it
<lfam>When we want that property, we use a patch file
<lfam>Anyways, you also need to escape the parentheses in the string you want to match
<v1dl00fyuq6f[m]>> /home/kreyren/Repositories/guix/gnu/packages/bittorrent.scm:500:69: invalid character in escape sequence: #\)
<v1dl00fyuq6f[m]>ok what the hell
<lfam>Escape it twice
<lfam>Sorry, I should have mentioned that
<lfam>It's super annoying
<v1dl00fyuq6f[m]>just when i though that Posix ere can't be more annoying you found the way!
<v1dl00fyuq6f[m]>yay it works thankuuuu <3
<v1dl00fyuq6f[m]>what about the sanitization though?
*v1dl00fyuq6f[m] uploaded an image: (137KiB) < >
<v1dl00fyuq6f[m]>ehh it's not doing the `,` ?
<v1dl00fyuq6f[m]>and seems to fail when i (double) escape it?
<nckx>IIUC your arrow should be pointing from ‘"\" pyInfo’, one line lower, because that's where a ‘,’ is missing.
<v1dl00fyuq6f[m]>nckx: nope regexing the line highlighted
<v1dl00fyuq6f[m]>the line below seems identical, but it's checking for `python` executable not for `python3`
<nckx>‘your arrow should be pointing from’, not ‘to’.
<v1dl00fyuq6f[m]>s/the line below seems identical, but it's checking for `python` executable not for `python3`/the line below seems identical, but it's checking for `python` executable not for `python3`/
*v1dl00fyuq6f[m] sent a code block:
<v1dl00fyuq6f[m]> * ```... (full message at
<v1dl00fyuq6f[m]>nckx: what
<nckx>Ignore the Python code.
<nckx>It is not relevant to my answer.
<nckx>You forgot a ‘,’ in your second line.
<nckx>Yes :)
<v1dl00fyuq6f[m]>Is there sanitize it so that it fails if `substitute*` doesn't match anything in the file?
<lfam>Use a patch file
<v1dl00fyuq6f[m]>lfam: lame
<lfam>That is the answer, take it or leave it
<lfam>Well, there is another alternative.
<lfam>You could use substitute*, and then write a Scheme procedure that reads the file you've substituted and checked if it looks how you want
<v1dl00fyuq6f[m]>hmm dunno complaining on guix-bugs with reproduction of it seems as more efficient way as this is probably guix-wide issue that can happen
<lfam>But, patch files and substitute* have different puproses
<lfam>Patch files are familiar, we know what they are for
<lfam>But substitute* can match an arbitrary number of times
<lfam>It's a more flexible interface
<v1dl00fyuq6f[m]>but it still returns true even when it can't match anything
<v1dl00fyuq6f[m]>that to me seems insane
<lfam>Maybe it is. But you asked if there was a way to sanitize it, and I'm telling you that there is not
<v1dl00fyuq6f[m]>or if it has to be flexible then i would probably argue for an input argument
<lfam>It could be a change we should make
<v1dl00fyuq6f[m]>lfam: ah oke
<lfam>It's not just for patching dependencies
<lfam>It's for any textual changes
<v1dl00fyuq6f[m]>hm O.o
<Ribby>usb ethernet adapter cannot connect to another computer with net to get net? It seems that it is only useful for computers without ethernet ports. A special/unlikely scenario, since most hardware stays in the case intact instead of outside.
<Ribby>Bridging connection is a thing.
<vagrantc>Ribby: no, you can use them just like any other ethernet interface
<vagrantc>you can bridge the connection, or connect directly, etc.
<vagrantc>Ribby: i only brought it up because you mentioned a computer using two ethernet interfaces ... and you can easily add another with usb ethernet
<Ribby>It's rare to see computer with multiple ethernet ports. It can be configured though.
<Ribby>I thought of another way.
<nckx>lfam: System seems to have booted finely with <>. Updating my user packages will take all night, so good night, and thanks.
<lfam>You can tell it's an old Guix package because there's custom Scheme code in the source
<Ribby>Computer with wifi, with ethernet cable connected to its port and the port of another computer. Will this work in sharing internet connection?
<vagrantc>Ribby: yes
<Ribby>Yes! I'm trying to get things work with the least possible configurations. It's just a lazy, I mean, standard way of conventions. I'm not sure if its optimal in performance.
<Ribby>Okay, will the same scenario work if another computer (w/o wifi) goes under guix OS boot installation?
<nckx>lfam: Hah, I didn't even notice that, so afraid was I of changing anything more than strictly needed.
<lfam>It's fine, it's just funny
<lfam>You don't see those kinds of things in new packages :)
<nckx>I think it's okay though.
<nckx>lfam: python-dbusmock doesn't happen to be on the list of packages you were looking into? It's what just kaboomed my upgrade…
<v1dl00fyuq6f[m]>patch submitted ready for review
<v1dl00fyuq6f[m]>and for me to finally torrent terraria yayyy
<lfam>I hadn't noticed that one nckx
<lfam>I'm still focused on python-black / python-tomli. I'm hoping I can downgrade python-black without breaking all of mbakke's adjacent commits
<nckx>It's not immediately related to black, but it's got python- in the name, so thought I'd ask.
<apteryx>I've fixed python-black
<lfam>It's a frustrating situation
<lfam>Oh amazing!
<apteryx>and python-aiohttp
<apteryx>will push after a lint
<nckx>Now you're just showing off.
<nckx>Now do dbusmock.
<apteryx>that's broken too?
<nckx>Seems legit, sec.
<Ribby>By the way, I want to relay that usb ethernet adapter should work as a bridge by ethernet cable role.
<Ribby>Maybe even faster than wifi, but each computer will require one ethernet port.
*v1dl00fyuq6f[m] puts `` on a sign and dances with it like ppl in front of fast food trying to lure in customers on a chicken or whatever as everyone talks
*v1dl00fyuq6f[m] [ ... ]\ (^_^)
*nckx will just add --keep-going, which ought to be aliased to --bed-time, and → 😴💤
<Ribby>My only concern is if boot can read bridged connections at all.
<vagrantc>Ribby: there's nothing special about a bridged connection if you configure it correctly
<vagrantc>Ribby: what do you mean by "boot" ?
<Ribby>Like, if I was to boot install Guix with a bridged connection for updates/upgrades.
<Ribby>Does that make sense?
<vagrantc>Ribby: depending on your network connection, you might also be able to use an ethernet switch to plug in multiple computers to a single internet connection
<apteryx>lfam: I think python-black was too overcareful with tomli version
<Ribby>Probably more convenient.
<apteryx>it stillp passes its test suite after all, and tomli is just a toml parser
<vagrantc>Ribby: there's nothing special about a bridged connection, it's just networking.
<lfam>apteryx: I couldn't tell from the upstream bug report if they were too careful or if there was really some issue. I did notice that it's not enough to relax the requirements in There's a run-time check as well
<apteryx>oh, then my purported fix is not one
<lfam>It pops up when building packages higher in the graph, like python-isort
<Ribby>Then, my idea should work as that. Thanks.
<vagrantc>Ribby: you're asking very general questions about networking ... it might not be specific to #guix
<apteryx>probably just to run some useless lint on the source
<lfam>It's why I was thinking of downgrading python-black, apteryx. The older version we had doesn't seem to care as much
<vagrantc>Ribby: good luck working something out! :)
*v1dl00fyuq6f[m] created -- [PATCH] qbittorent: Bump 4.2.5 -> 4.4.0
<lfam>That's why I asked mbakke why he updated it. So I would know how to test it
<Ribby>It's just a mystery in the networking world of bootloaders...
<lfam>We might need to rollback some other upgrades, too. Who knows
<apteryx>merged on Nov 15, 2021
<lfam>Yeah, we could also try a patch
<lfam>The package really tries to prevent you from building from Git
<lfam>Overall it's a PITA
<apteryx>seems the last release is from Dec 5 2021
<apteryx>weird that it doesn't have the fix
<lfam>Here they hint at a release by February:
<lfam>But, that's a long time for some of these packages to be broken
<lfam>At least, I think of gqrx as an important package
<lfam>But I'm just being a nerd about that
<lfam>So, I can try the reversion with a test rebuild of all dependents, and I can try cherry-picking some patches
<lfam>I guess I'll try the patch first. That what would be easier to test IMO
<apteryx>the patch looks messy
<apteryx>I doubt it'll apply
<lfam>Which patch is that?
<apteryx>but I just ran black on a python file and it worked fine
<lfam>I mean, I think it *always* worked fine
<lfam>I need to find the runtime check
<lfam>Hm, apteryx, maybe I was wrong about the runtime check. I must have gotten confused about what I was attempting to do
<lfam>At least, vdirsyncer builds when you simply relax the requirement in black's I'm now building up to gqrx, which was my other broken package
*lfam fingers crossed
<apteryx>i've pushed that fix already by the way (for black)
<dumbdemic[m]>Is there a cli command to view the contents of a package scheme file in my channels ie the scheme file stumpwm when I install via `guix install stumpwm`? Or is this available on a website somewhere?
<dumbdemic[m]>* scheme file for stumpwm when
<Ribby>I wonder why vlc media player isn't available in the Os by default? Is it due to legal ramifications that may make a mess?
<v1dl00fyuq6f[m]><dumbdemic[m]> "Is there a cli command to view..." <- has a section for per-package documentation i am currently adding stumpwm
<v1dl00fyuq6f[m]>oh and to view the contents of package scheme file use `guix edit stumpwm`
<v1dl00fyuq6f[m]>optionally `guix show stumpwm`
<dumbdemic[m]>v1dl00fyuq6f[m]: Awesome ty
<v1dl00fyuq6f[m]>aaAAAAAA will anyone merge my hard work~ hmph
<v1dl00fyuq6f[m]>i am too lazy to change 2 lines of code and then wait 8 min for qbittorrent to build to be able to torrent terraria hmph
<v1dl00fyuq6f[m]>fine i will change the two lines hmph
<v1dl00fyuq6f[m]>took me 3 sec and it was painful hmph
<vagrantc>well, at least you're sharing the pain with each and every one of us :P
*vagrantc prepares to ramble
<v1dl00fyuq6f[m]>vagrantc: mhm <3
<jts>is anyone else unable to run guix system reconfigure because of ?
<vagrantc>jts: i think it was mentioned earlier, but not in much detail ... just amoung the big issues that need to be dealt with
<jts>I wasn't here at the time, unfortunately. Is there a work-around so I can eg change my kernel cmdline? Like should I pin the package or something?
<wigust>hi guix
<vagrantc>jts: i didn't hear anything mentioned, but you can always invoke an older guix instead
<jts>perfect, thanks
<vagrantc>recent updates have been a bit more intrusive than was expected ...
*vagrantc waves
<lilyp>does someone have experience with launching dbus inside a container'd guix shell?
<abrenon>hello guix
<lilyp>if it's another of these instant success, just add glib things...
<gyara>rust-clap-3.0.5 has different api with rust-clap-3.0.0beta5
<v1dl00fyuq6f[m]>gyara: how is that relevant to guix
<gyara>If I want to update clap to 3.0.5, does it means I need to check all packages deps on clap?
<v1dl00fyuq6f[m]>just `guix shell rust-clap@3.0.5` ?
<efraim>gyara: if it has a different API then it'd be best to check the packages that depend on it
<numerobis>Hi #guix! Is there a way to install the Monaco font on guix system?
<v1dl00fyuq6f[m]>what package in guix provides
<allana>Hi guix! Is there currently a way to incorporate per-user guix home into a system config?
<civodul>numerobis: "guix search monaco" turns up nothing, so maybe not yet?
<civodul>v1dl00fyuq6f[m]: hi! it's 'mesa'
<numerobis>civodul Thank you!
<civodul>allana: it's not possible currently, but would be nice
<allana>civodul: thanks
<abrenon>hi numerobis I don't see why not ? have you searched for the package ? are you trying to package it ? have you looked at other font definitions to draw inspiration ?
<abrenon>ah, sorry I missed civodul's search, well that leaves the two other suggestions : )
<mothacehe>hola guix!
<v1dl00fyuq6f[m]>civodul: danke sheen
<v1dl00fyuq6f[m]>howddya figured out that it's in mesa btw
<abrenon>¡ hola mothacehe !
<civodul>bon dia mothacehe! :-)
<mothacehe>hey abrenon & civodul :)
<civodul>v1dl00fyuq6f[m]: currently there's no way for figure it out, other than using "find /gnu/store -name libGL\*"
<abrenon>"bon dia" ? 🤔 esperanto ?
<numerobis>@abrenon: Thanks! For now I'm trying to use it, but at some point when I have spare time I may try to package it. On a different subject, is it "safe" to upgrade the system after not doing so for about a year, or should I expect certain things to break?
<abrenon>experience on other system would suggest pessimism, but I've recently seen a message on the mailing list from people amazed to see they could upgrade their system without a hassle after a very long time (was it one or two years ? it was long anyway)
<abrenon>in any case you need to update guix itself first, with guix pull, and if that works I see no reason why the following reconfigure should fail
<abrenon>you may perhaps have issues with the little amount of stateful stuff needed, I once had issues with GDM because of what was left in /var/lib
<abrenon>(but I think it was a left-over from an install of another distro because I had it on the first boot, it wasn't after an upgrade)
<abrenon>also, good news: packaging and using is essentially the same thing, there's a little overhead of cleanup and social interactions to get it accepted to the official repos, but the definition you'll need to try it is the package itself
<jpoiret>one thing you'll have to do is reboot right after `guix system reconfigure` to let the newer guix daemon start
<jpoiret>i'm not sure it restarts itself
<jpoiret>i might be wrong on that
<lilyp>it's wiser to restart it through herd (if necessary) and do your user profile before rebooting
<lilyp>user/system profile mismatches can cause some annoyances (missing localization, etc.)
<abrenon>oh, right I had that last time with an issue in some GTK lib because my user profile's app were lagging on the system
<numerobis>abrenon: Many thanks! Yes, I imagine some of the services definition might have changed, but hopefully not too much.:)
<numerobis>@jpoired Oh I didn't know rebooting was necessary, thanks!
<lilyp>btw. I'm halfway done with sufficiently containering my old system – AMA
<abrenon>lilyp: what was the scope of the project ? what was the initial need ? how do you define "sufficiently" ?
<attila_lendvai>lilyp, is that about running some apps in isolated containers on a normal Guix install?
<attila_lendvai>i'd be happy if my browser was in a container, and it could only access ~/Downloads/
<lilyp>abrenon: My work laptop broke. I need to access its files and services without polluting my personal machine.
<numerobis>lilyp: just to be sure, what do you mean by " do your user profile"?
<lilyp>attila_lendvai: somewhat. It's not as isolated – basically Epiphany would still have full write access to $HOME, but a different $HOME
<lilyp>numerobis: `guix package -u` or the manifest equivalent
<attila_lendvai>lilyp, i'm sure there'd be demand for a blog post, or a chapter in the manual/cookbook documenting this.
<abrenon>ah, interesting use case, yeah your experience would certainly improve the cookbook
<jpoiret>i've been thinking of factorizing operating-system and guix home and have capatibility for vm and containerized parts but that's obviously a big undertaking
<jpoiret>would be great though if you could simply spin up a part of someone's config in a container/vm effortlessly
<jpoiret>would make reproducers for complex bugs much more approachable
<civodul>there's this weird LaTeX error that still occurs for me:
<civodul>with texlive-latex-komascript
<civodul>does anyone have ideas?
<lilyp>civodul: you do have the standard letter class also available, right?
<jpoiret>hmmm, i'd love to help but i can't seem to properly use the modular latex packages
<jpoiret>anyone have a basic guide for which packages provide what (and what's the needed to start)?
<jpoiret>i'll need latex working sooner or later anyway
<abrenon>someone recently suggested to me to use tlmgr to find which packages provided what
<abrenon>but I never was able to understand its output enough to know which package was needed for kpathsea to stop complaining about something called cmr10, so I won't be of much help here
<jpoiret>rather, its trying to mkformat pdflatex.fmt, and fails because it cannot find latex.ltx
<civodul>lilyp: dunno, what package is that?
<jpoiret>i'm using "texlive-bin texlive-tex-ini-files texlive-latexconfig"
<civodul>-bin or -base?
<jpoiret>-bin. that might be the issue (i don't even have kpathsea then?)
<civodul>lilyp: oh that's texlive-latex-base, i have it
<lilyp>so you can correctly write normal letters, but no koma letters?
<civodul>dunno, fundamentally i don't care about koma, it's an indirect dependency of the thing i want to use
<rekado_>texlive-base is the package
<civodul>but yeah, it all seems to be like in Pierre's report above
<rekado_>don’t mess with texlive-bin, or texlive-latex-base
<rekado_>texlive-base includes texlive-bin and texlive-latex-base
<civodul>ah good
<civodul>i usually use texlive-base
<rekado_>the cmr10 thing … I fixed that on wip-texlive!
<civodul>should we hide texlive-bin and texlive-latex-base?
<rekado_>why is this still an issue…?
<civodul>cmr10? no
<rekado_>all font search weirdness should be fixed
<civodul>yes, that seems fine on version-1.4.0
<civodul>the issue for me is "Argument of \strip@prefix has an extra }."
<abrenon>yeah, sorry rekado_ I know you said that, I was just reporting my experience with tlmgr to suggest a lead to jpoiret
<civodul>coming from texlive-latex-komascript somehow
<rekado_>okay, I’ll take a look at this when I’m feeling better. I’m a daycare germ factory since about two weeks already…
<civodul>uh, that doesn't sound great, good luck with that!
<abrenon>: /
<abrenon>take care of yourself !
<jpoiret>seems like texlive-bin uses sed/uname/mkdir, so --pure doesn't work
<jpoiret>mktextfm in particular
<rekado_>jpoiret: that’s been patched
<rekado_>at least the sed call
<jpoiret>oh great! i imagine on the wip-texlive branch?
<jpoiret>or similarly named
<rekado_>commit a6499572b3cc564c197bc86d36a23ed7034944b8 and 871504e5bf9ae43d539955d4dc68f8a577ba2b1a
<rekado_>it’s on the master branch
<rekado_>wip-texlive went into version-1.4.0, and that went into master
<jpoiret>oh cool, i'll be guix pulling soon then
<jpoiret>just got "substitute: In procedure write_wait_fd: unimplemented"
<jpoiret>i thought i had seen a mail about that issue but notmuch doesn't find it, nor
<v1dl00fyuq6f[m]>How do i make dmenu_run to use `~/.local/bin` ?
<gnoo>add that to your PATH
<v1dl00fyuq6f[m]>gnoo: doesn't work
<gnoo>how did you add and did you export afterwards?
<v1dl00fyuq6f[m]>oh it doesn't work when called from S-D using xfce4 keybind
<gnoo>yeah, for that you need to export before the de is started
<gnoo>it's dependent upon the de, can you do 'startxfce4' on tty2?
<v1dl00fyuq6f[m]>n i start it from gdm
<lilyp>your .bash_profile or .zprofile should run before the WM then
<gnoo>there's probably a gdm specific way, i'm betting it requires using a .desktop file and i hate those
<gnoo>if you can use startxfce4 instead of using gdm, there's an easy solution
<v1dl00fyuq6f[m]>i use gdm x.x it's the default!
<gnoo>you can break away from the default
<v1dl00fyuq6f[m]>b-but i like GUI
<gnoo>just try it now, Ctrl+alt+f2, login with username, password then type startxfce4
<v1dl00fyuq6f[m]>i know i used it before but i prefer the GUI for DM
<v1dl00fyuq6f[m]>well for session management
<mothacehe>system tests appear to be broken by the 1.4.0 branch merge :(
<lilyp>v1dl00fyuq6f[m]: again, whatever you do in your login shell profile gets propagated to the session. This isn't SystemD, which somehow manages to bork that
<lilyp>but if it were, there'd be a solution to that as well
<v1dl00fyuq6f[m]>what's login shell in this context
<v1dl00fyuq6f[m]>*login shell profile
<v1dl00fyuq6f[m]>like ~/.bash_profile?
<rekado_>I think the tex fixes are broken again by the 1.4.0 merge
<rekado_>oh, never mind. Wrong branch. Phew!
<mbakke>any ideas why 'guix system vm' no longer display boot messages?
<mothacehe>mbakke: looks like "guix system vm gnu/system/examples/bare-bones.tmpl" displays boot messages
<mothacehe>on the gtk window
<lilyp>v1dl00fyuq6f[m]: yes, pardon my inclusive language
<v1dl00fyuq6f[m]><lilyp> "v1dl00fyuq6f: yes, pardon my..." <- so GDM sources the `~/.bash_profile` before session startup to make the variables available there?
<attila_lendvai>guix pull fails for me with "failed to start SSH session: Unable to exchange encryption keys", even though ssh works from the same account to the same server. is guix pull going through a different lib? i'm trying to use it with a ed25519 key.
<abrenon>v1dl00fyuq6f[m]: I'm not sure, I think it actually dependson the X session chosen from GDM
<abrenon>for instance, here I source it manually from a custom .xsession
<abrenon>to make sure my "global" environment variables are known to all my GUI programs
<lilyp>I think it only does so for xsessions, though
<v1dl00fyuq6f[m]>`~/.xsession` ?
<v1dl00fyuq6f[m]>will that work for xfce
<lilyp>If you launch GNOME normally in Guix (and I'm pretty sure it's the same for XFCE), your login profile is applied
<v1dl00fyuq6f[m]>and login profile == ~/.bash_profile right
<lilyp>probably maybe, in your case very likely
<v1dl00fyuq6f[m]>k trying
<abrenon>~/.bash_profile is one of the places where bash is going to look for its login profile
<abrenon>it could also be named .profile
<lilyp>we always have a bash_profile on guix though, so .profile is likely ignored
<abrenon>using XFCE4 with a .xsession here, pretty sure it's there for a reason, my .bash_profile wasn't sourced properly before I devised that setup
<abrenon>NB: with a .xsession (must be executable), GDM passes control and execs that, so the responsability to exec startxfce4 becomes the .xsession's
<abrenon>failing to do that yields setup where login "succedds" briefly but the screen flickers black for a mo and GDM's login screen returns right after
<attila_lendvai>FTR, libssh2 does not support that key type (as per
<v1dl00fyuq6f[m]>`~/.bash_profile` works, thanks lily-senpai~ <3
<abrenon>with XFCE4 or GNOME ?
<lilyp>attila_lendvai: I'm pretty sure Guix uses guile-libssh2, which you guessed it...
<v1dl00fyuq6f[m]>abrenon: xfce4
<attila_lendvai>lilyp, yep, libgit2 depends on libssh2. i guess i'm stuck with rsa keys.
<abrenon>wait what ? simply laying .bash_profile there was enough for it to be sourced ?
<v1dl00fyuq6f[m]>I am trying to develop a `manifest.scm` to build cargo-make:... (full message at
<abrenon>why wasn't it sourcing mine ?…
*abrenon is going to have to break everything again : (
<lilyp>abrenon: Guix System or foreign distro?
<abrenon>Guix System
<abrenon>was that fixed recently by chance ?
<abrenon>I remember taking a long time to investigate that one when I started
<lilyp>idk, it was sourcing it correctly for as long as I can remember
<lilyp>but I'm a GNOME sheep, so YMMV
<abrenon>I read all the manpages I could, to find that nothing said it would source .bash_profile implicitly meaning that I had to do it myself
<abrenon>I'll be right back after I've broken everything
<lilyp>That's your first mistake: You tried reading.
<v1dl00fyuq6f[m]>lilyp: ye reading bad
<lilyp>real hackers just mess up their bashrc until it breaks everything and declare emacs bankruptcy in the meantime
<attila_lendvai>lilyp, sadly, it's not enough to just generate an rsa key with ssh-keygen. it still doesn't work, even though ssh -v user@server logs in using the new rsa key
*v1dl00fyuq6f[m] just has a bashrc full of `. path/to/somewhere` that is sourcing clean-roomed files ~
<v1dl00fyuq6f[m]>modular design!
<v1dl00fyuq6f[m]>> <> I am trying to develop a `manifest.scm` to build cargo-make:... (full message at
<lilyp> :)
<v1dl00fyuq6f[m]>did that thing got retracted for ya on IRC
<v1dl00fyuq6f[m]>I am trying to develop a `manifest.scm` to build cargo-make:
*v1dl00fyuq6f[m] sent a scm code block:
<attila_lendvai>there's a new release of libssh2. any obstacles to updating it to 1.10.0?
<v1dl00fyuq6f[m]>with a development environment using:
*v1dl00fyuq6f[m] sent a code block:
<lilyp>attila_lendvai: look at `guix refresh -l'
<v1dl00fyuq6f[m]>dunno how to make it to not show the 2021 edition err when using the manifest.scm
<lilyp>if it says a number < 300, you're good
<abrenon>absolutely, I never said I was a "real hacker" nor wanted to be one
<abrenon>I'm not a hacker, and I do read
<attila_lendvai>lilyp, "Building the following 4305 packages would ensure 6302 dependent packages are rebuilt"... :)
<abrenon>especially when I empirically observe a behaviour that differs from my previous knowledge and expectations
<attila_lendvai>lilyp, that means not any time soon, right?
<lilyp>that means it goes to c-u, yes
<v1dl00fyuq6f[m]>aaaa this was supposed to be 20 sec adventure to schedule a fabrication and take a bath but that damned guix ain't building cargo-make grr
<abrenon>and I'll remain frustrated not to know why this is no longer necessary, because I don't touch things that work for no reason (yeah, like I said, I'm no hacker)
<abrenon>so anyway, thanks for notifying me that I could get rid of that unelegant fix
<lilyp>I couldn't tell you what went wrong back then either
<lilyp>FWIW we're facing similar issues with EXWM
*v1dl00fyuq6f[m] copypasted the instructions from Makefile.toml, scheduled fabrication and throws and here for ppl to say good work krey and press the merge button as he leaves to take a relaxing bath~
<abrenon>ohhh ? that's good to know, thanks for the pointer (it'll be useful when I have become a hacker and use emacs for everything like WM 😉)
<attila_lendvai>lilyp, what shall i do in such a situation? sending a patch to guix-patches is quite a hurdle only to increase a version number, and then potentially getting forgotten in the inflow to guix-patches... is that nevertheless the generally expected way in such a case?
<lilyp>attila_lendvai: just submit your patch as [PATCH core-updates], but remember to check whether core-updates already has it first
<attila_lendvai>lilyp, ok, will do the dance then. it doesn't have it, according to git show core-updates:gnu/packages/ssh.scm
<mbakke>mothacehe: oh indeed, my config had "console=ttyS0" in kernel-arguments, removing that made boot output appear on the graphic console ... I'm fairly certain console=ttyS0 did work previously on GTK, but can live with this quirk.
<abrenon>ohhh python-dbusmock isn't available and failed to build locally : (
<apteryx>there were some fixes yesterday that probably fixed it; have you tried 'guix pull'?
<abrenon>command "python" "-c" "import setuptools, tokenize;… failed with exit code 1 (shouldn't it be python3 ??)
<apteryx>builds fine here; with guix at 547625504c5560d66ac80405129ffb938f5200db
<abrenon>apteryx: I've pulled right before, I never reconfigure without pulling
<apteryx>sorry, guix at 1ebc9e88234812f6e6d00694ed7d27ac2ac4dc05
<apteryx>what is your guix revision?
<abrenon>pulled today at 14:48:35
<apteryx>what hash output by 'guix describe'?
<abrenon>the one I pasted above 5ed33b0d05902de921e972d41168910107c93515
<apteryx>ah, sorry, it's morning here ;-)
<abrenon>don't worry, it's nice enough of you to try and help me !
<abrenon>I'm trying to time-machine the build with the commit you've provided me with
<abrenon>(and good morning to you)
<apteryx>thanks! that commit should be good to build it... I'll reattempt a build with --check
<abrenon>what ? you say it works on your machine ? it fails just the same here
<apteryx>are you on x86_64?
<abrenon>guix time-machine --commit=1ebc9e88234812f6e6d00694ed7d27ac2ac4dc05 -- build python-dbusmock
<yewscion>Hey All, I've looked online and I've come up empty-handed for some info: I've recently been getting a guile error (`Throw to key `match-error'`) when I try to `guix pull` my personal repository. I can't figure out what has changed; If I disable authentication it works fine, but I'd rather not do that to work around the issue. What problems might
<yewscion>cause that error during `guix pull` ?
<abrenon>same error in the tests, when spawning some "python" "-c" command
<apteryx>I don't understand, it builds fine here, even on 5ed33b0d05902de921e972d41168910107c93515
<apteryx>running the test suite right now
<abrenon>what… ?! Oo
<abrenon>sorry the build itself passes, it's the tests that fail
<apteryx>OK, we'll see shortly if they fail here as well
<apteryx>nope, the test suite passed
<apteryx>perhaps a nondeterminist problem? does it sometimes succeed, sometimes fail?
<apteryx>please retry it a few times
<abrenon>haven't retried more than twice ^^
<abrenon>produced the same hash within /gnu/store
<abrenon>tests still fail
<wnklmnn>It's failing for me aswell
<dportnrj[m]>the same.
<abrenon>yeah ! I'm not hallucinating !
<abrenon>(thanks for the reports)
<wnklmnn>I see a couple "ERROR: timed out waiting for bus process to terminate" messages in the log.
<apteryx>I see them too, but they are not fatal for me
<zimoun>apteryx: failure with «ERROR: timed out waiting for bus process to terminate» on foreign distro. abrenon, is it the same error?
<apteryx>zimoun: see my message above yours (I get these too -- I think they are part of what the test exercises)
<abrenon>I have them but they do not seem fatal either because the tests continue
<zimoun>apteryx, are you running on foreign or Guix System?
<apteryx>guix system
<abrenon>they reach tests.test_systemd.TestSystemd
<abrenon>guix system here too
<apteryx>ah wait, those errors are caused by python-dbus waiting for finished processes to be reaped
<apteryx>but they aren't because there's no PID 1 init to handle the signals correctly, so they remain as zombies
<apteryx>still, not fatal for me here
<apteryx>but to fix those and make the test suite much faster we could launch them in a dumb init such as done for the mutter tests
<abrenon>must be 6 or 7 occurrences for me here, still none succeeded
<abrenon>it doesn't look very nondeterministic to me : )
<apteryx>looks like this here:
<jpoiret>it just built fine for me
<abrenon>the list of tests doesn't seem to be in the same order ?
<abrenon>there's TestNetworkManager in your logs, but not in mine
<abrenon>you also had TestPolkit
<zimoun>yeah, idem here. I have tried ’-M 1 -c 1’ and still error for me.
<abrenon>but most importantly, you passed TestSystemd (not skipped, you've got an 'ok') -> are you running systemd apteryx ?!
<zimoun>abrenon, I am running systemd and I have an error. :-)
<abrenon>darn : )
<abrenon>(also, what ? one can run systemd on guix ? as a user service spawned by herd ? what do you use it for ?)
<zimoun>abrenon, I am using Guix on foreign distro :-)
<abrenon>ok, makes sense, but apteryx said they were using guix system so I'm a bit surprised is all : )
<abrenon>but thanks for clearing that out
<zimoun>I think the package is doing a mock.
<apteryx>abrenon: no systemd
<zimoun>jpoiret, apteryx: are you using special flags for the daemon?
<jpoiret>nope, just additional substitutes servers
<jpoiret>but i did build it locally
<zimoun>it is really weird, isn’t it?
<apteryx>well I do use --max-jobs=4
<apteryx>and --log-compression none
<apteryx>but that's it
<m4t3>How far is #Hurd immunity on GUIX?
<abrenon>do you reckon it may be the number of jobs ?
*apteryx tries guix build python-dbusmock --max-jobs=1 --check
<abrenon>should I try to restart guix-daemon with a different set of options ?
<apteryx>but no, that shouldn't matter at all
<apteryx>max-jobs is the number of concurrent builds started; here we're looking at one build
<abrenon>fails here with --max-jobs=4 too
<zimoun>I am not able to build it with 923dcc3 from Jan. 14. But the susbstitute is available.
<apteryx>this is so strange
<lilyp>m4t3: currentlay, virtually all guix users are immune to running hurd as their main system
<lilyp>this won't remain that way for long; I'd imagine hurd adding support for 64bit arches or USB would be greatly beneficial to its adoption
<apteryx>abrenon, zimoun could you try './pre-inst-en guix refresh --update python-dbusmock && ./pre-inst-env guix build python-dbusmock' ?
<apteryx>in your guix source checkout
<zimoun>apteryx: yes, I will.
<abrenon>what does it do ? (also, yes)
<zimoun>note that it also fails with 7682145 from Dec. 23.
<apteryx>update python-dbusmock to 0.25 and try to build it again
<apteryx>what is the exact error again you get?
<abrenon>so I suppose it should be issued in a guix shell -D guix environment with source up-to-date and make returning successfully ?
<zimoun>the exact same one.
<apteryx>I'll try one more thing
<zimoun>apteryx: same error with 0.25.0
<apteryx>ok, thanks for checking
<abrenon>(still building guix…)
<apteryx>also, python-nose is kind of obsolete (unmaintained), but I'm guessing unrelated
<abrenon>exact same result
<abrenon>build works, tests fail on the same TestSystemd class
<apteryx>I'm readying a patch for you to test
<abrenon>so you have an idea what's going on ?
<zimoun>apteryx: for me, it builds fine with b603554ed0 (parent of core-update merge) at version 0.18.3 and starts to fail with 6dffced (core-updates merge) at version 0.24.1
<apteryx>abrenon, zimoun could you paste this definition in your sources:
<apteryx>and retry?
<apteryx>(overriding the current python-dbusmock package definition)
<zimoun>apteryx, missing the definition. :-)
<apteryx>"do not spam" thanks,
<abrenon>wow the tests don't look the same at all
<abrenon>and they pass
<zimoun>they pass too.
<abrenon>ok SIGCHLD, Reaped child… so you fix the zombies leaking problem ?
<abrenon>but how does that fix the systemd tests ?
<SeerLite[m]>Hi! Is there a way to modify-phases of an inherited package?
<apteryx>abrenon: so, the lack of zombie reaping somehow impacts the test
<apteryx>as it did for mutter
<apteryx>I'm not sure why it doesn't impact every host the same though.
<abrenon>that's really scary
<abrenon>but thanks for the amazingly fast patch
<apteryx>civodul: hello! if you read this, any idea what might be at play here?
<apteryx>abrenon: no problem! i happened to have that python-dbusmock experience still fresh
<abrenon>still, impressive ! : )
<zimoun>apteryx: what is the schedule for 1.4.0 because for x86_64, it seems okis but i686… ouch! a lot of reds.
<SeerLite[m]><SeerLite[m]> "Hi! Is there a way to modify-..." <- Nvm found some examples in the guix repo, can be done with substitute-keyword-arguments. bash-minimal is a good example
<apteryx>abrenon, zimoun I pushed the dbusmock fix to master in case you want to pull again
<abrenon>SeerLite[m]: sorry, I had missed your question ! good that you found useful examples
<zimoun>apteryx: thanks!
<abrenon>apteryx: ok, pulling to retry
<apteryx>zimoun: the failures on i686 appear transcient to me; probably just need a couple restarts
<apteryx>(stdin): Cannot allocate memory
<zimoun>hum, ok. Let see if build gcc@10 is enough. :-)
<apteryx>I've restarted gcc@7 and gcc@10
<apteryx>if you see other dubious failures please let us know!
<abrenon>guix updated, building my system again : )
<abrenon>it's compiling so many packages
<v1dl00fyuq6f[m]><abrenon> "it's compiling so many packages" <- not compiling.. probably downloading most of them bcs they are cached
<abrenon>v1dl00fyuq6f[m]: is that so ? then I thought I saw it build libmutter, gnome-shell and all
<abrenon>Load average: 0.95 2.76 2.57
<apteryx>python-dbusmock affected mutter at least
<abrenon>so that's logical
<apteryx>it touches 64 packages, mostly GNOME related
<v1dl00fyuq6f[m]>abrenon: oh it's probably building though if they are not substituted O.o
<ekaitz>hi guix!
<ekaitz>i got issues when reconfiguring
<v1dl00fyuq6f[m]>none ever says hi to me hmph
<abrenon>hi v1dl00fyuq6f[m] ! : )
<v1dl00fyuq6f[m]>ekaitz: provide output then
<v1dl00fyuq6f[m]>abrenon: grr don't say hi to me i hate it, i accept headpats though
<abrenon>: )
<ekaitz>one second, I lost the output by accident
<abrenon>ekaitz: trouble with python-dbusmock by any chance ? : )
<v1dl00fyuq6f[m]>ekaitz: or like do you know what the issue is?
<ekaitz>that was in the morning
<ekaitz>now it's folks
<v1dl00fyuq6f[m]>my printer is doing ... --- ... sound
<v1dl00fyuq6f[m]>poor thing
<ekaitz>-> build of /gnu/store/gcgcz9ndiqmxjbak6901knh6apcmrhpj-folks-0.15.3.drv failed
<apteryx>ekaitz: try adding python to native-inputs
<apteryx>meson doesn't propagate python anymore
<v1dl00fyuq6f[m]>ekaitz: `bzcat path/to/log/file`
<apteryx>since version-1.4.0 merge
<ekaitz>yeah python3 not found
<ekaitz>that's the error
<v1dl00fyuq6f[m]>So include it?
<ekaitz>should i include it in my system directly?
<v1dl00fyuq6f[m]>hard to say what is the issue though without log
***ChanServ sets mode: +b *!*@2001:470:69fc:105::1:6a20
***v1dl00fyuq6f[m] was kicked by ChanServ (User is banned from this channel)
***ChanServ sets mode: +o litharge
***litharge sets mode: -o litharge
<ekaitz>it's just when reconfiguring so it's a dependency i have
<ekaitz>is it a problem with folks package or with my config only?
<apteryx>with folks package; I'll push a fix in a minute
<ekaitz>thank you apteryx
<sneek>raghavgururajan: Greetings!!
<ekaitz>if the change is just what you mentioned with meson there must be more packages with the same issue, right?
<apteryx>many were already adjusted, but there may be some forgotten, yes
<ekaitz>thanks for your time
<apteryx>pushed with 1995920f68
<ekaitz>pulling right now
***ChanServ sets mode: +o antiharasserbot
***antiharasserbot sets mode: +b $r:@*
<ekaitz>apteryx: folks is working, thanks for being so fast
<efraim>merging the version-1.4.0 branch has me rebuilding from bootstrap binaries on powerpc and riscv64
<apteryx>version-1.4.0 was a world rebuild, so that's expected; was is not expected is that there's so little substitutes available for it
<efraim>there definately weren't any substitutes for powerpc or riscv64 :) AFAIK I'm running the only instance of each
<efraim>I wonder if we could drop sitecustomize from python-boot0
<apteryx>if python-boot0 is not used with extra python modules yes, otherwise no
<efraim>it looks like it's just used for glibc-intermediate
<efraim>i'll try removing it on core-updates and build to hello or mesa and see if it causes any problems
<apteryx>we could also try to use python-on-guile :-)
<apteryx>it seems to see constant development
<apteryx>nckx: moin!
<apteryx>according to, we're now among the top 10 package repositories (by package count)
<rekado>FYI: I had a sudden power outage (a power supply melted down and took my backup disks with it), which lead to the aarch64 nodes losing power.
<rekado>I started kreuzberg and pankow, but grunewald refuses to boot.
<apteryx>rekado: oof!
<ekaitz>apteryx: now gnome-boxes is not building, the error is meson related but not just that is missing python3
<apteryx>yeah, noticed that too. it's already fixed in master. apologies
<ekaitz>oh cool thanks!
<apteryx>is there any magic done for GUIX_LOCPATH in guix packs? Or is it something to handle manually? (I'm guessing the later)
<apteryx>I'm shipping a Python-based solution that relies on 'guix pack', and I'd like to ensure it won't suffer from locales issues.
<M326ads5ga[m]>that was rude hmph
***antiharasserbot sets mode: +b $r:@*
***M326ads5ga[m] was kicked by antiharasserbot (M326ads5ga[m])
<ekaitz>apteryx: gnome-control-center, too?
<civodul>apteryx: you need to ship glibc-locales (or similar) and to provide glibc so that GUIX_LOCPATH is set
<civodul>not ideal
<civodul>rather (@ (gnu packages commencement) glibc-final)
<civodul>to avoid duplication
<apteryx>civodul: OK, thanks for confirming
<ekaitz>something is weird here
<apteryx>civodul: and if my solution is to be used as a simple script, I need to wrap the script with these environment variables, right?
<apteryx>I basically add an entry to /usr/local/bin/my-script and have it used via invoking 'my-script' from PATH.
<apteryx>(upon extracting the guix pack tarball)
<civodul>apteryx: yes; or the script could source the profile's etc/profile file (i like the sound of this phrase)
<apteryx>ekaitz: got gnome-center-settings 41.2 to build; will push shortly
<ekaitz>yay thanks!
<apteryx>ekaitz: it's live!
<wnklmnn>gnome-music seems to be missing python aswell :)
<mbakke>efraim: removing sitecustomize from the bootstrap sounds like a good idea; probably you'll need to add (old-style) PYTHONPATH as a native-search-path
<nij->Hi! I'm confused with how guix home works in principle. I assume the point of it is to provide a "stateless" home, in the sense that the home-config file is used as a source of truth declaring the home.
<nij->However, most of the time we need to express the dotfiles in other langs, like bash. If I put all bash codes in the home-config file, I'd need to do lots of silly escaping.
<nckx>apteryx: …good moin to you too, as well, by the way! :)
<nckx>& good moin Guix.
<nij-> If I don't do that, then I must ask guix home to **READ** some other files. But this destroys the stateless feature in the meanwhile..
<nij->Am I thinking this correctly? And is there any secret pill that resolves my concern?
<abrenon>bye everyone, thanks again for the help !
<mfg>has someone tried packaging tree-sitter yet?
<apteryx>nckx: o/
<apteryx>would someone know if icedove is supposed to be able to open some email file from the CLI? I tried 'icedove -file path/to/myfile.txt' but it just throws: JavaScript error: resource:///modules/MessengerContentHandler.jsm, line 76: NS_ERROR_FAILURE:
<apteryx>if I instead open the email manually from the menu (File -> Open -> Saved Message...) it works
<apteryx>my aim is to easily view HTML messages
<nckx>So I want to personally apologise for giving v1dl00fyuq6f, banned here as M6piz7wk last December, a second chance and waiting too long whilst they happily headed down the same dark road that led them there. It was probably clear to many how inevitable that was long before it was clear to me. Sorry.
<nckx>Now they've been banned not just from #guix but from Libera, and the Guix ban is permanent.
<nckx>Resume your regularly scheduled hackings.
<sneek>notmaximed: wb :D
<notmaximed>sneek: botsnack!
<sneek>notmaximed, you have 1 message!
<sneek>notmaximed, podiki[m] says: thanks for earlier, both patches updated
<nckx>Them: you can't buy love.
<nckx>sneek: :)
<notmaximed>nij-: You could put your "guix home" configuration in a dedicated directory together will files included with 'local-file', and put all that under version control (e.g. git, regularily making tarball copies, ...).
*mbakke pushed a bunch of post-merge fixes, apparently Python patch upgrades includes setuptools, which is currently in disarray
<kennyballou>mbakke: is this why gnome-music and down are failing? I think the bottom was python-dbusmock(?)
<nij->notmaximed: That makes sense. And it's definitely more declarative than using gnu-stow.
<nij->If I do that, and if I change the content of say my bashrc source file. Would guix home be clever enough to detect the change and generate a new build?
<sneek>wb notmaximed!
<notmaximed>sneek: botsnack!
<notmaximed>nij-: Unless something has changed, it's more like guix (including "guix home" and "guix system") in general is too dumb to know that things don't have to be build again if no file was modified
<notmaximed>"guix shell" is as exception: if the manifest wasn't modified, it reuses an old build result (even if any 'local-file' it uses were modified)
<mbakke>kennyballou: the gnome-music failure seems unrelated looking at its log file ... I can't test myself atm as I'm still waiting for 5 Rust compilers to build
<notmaximed>Anyway, unless your 'local-file' things are millions of lines long or something, you probably don't have to worry about the time 'guix home' takes to intern the file
<mbakke>kennyballou: looking at some other commits, I think the problem is that its native-inputs lack 'python', as it is no longer propagated from Meson
<kennyballou>mbakke: okay, thanks. I'm barely digging into it, but is there a way to exclude it from the gnome service? I don't actually want it, and there's probably other gnome packages I don't need/want
<lfam>I just fixed gnome-music kennyballou and mbakke
<lfam>Er, just about!
<lfam>Just wait a minute or two
<nij->got it..
<lfam>It's a case where Python should be a regular input, as gnome-music does keep a reference to it
<lfam>Now the fix is deployed in our Git repo
<lfam>In fact, many of the recent similar fixes should use Python as a regular input
<kennyballou>lfam: woo, thanks, that was fast. What's the turn around for CI to have a substitute for it? Just curious
<lfam>Hard to predict. It could be 10 15 minutes, it could be several hours. It depends on factors
<lfam>But, it's a quick build
<kennyballou>lfam: cool, thanks.
<lfam>If you don't want to build on your machine, I recommend waiting until you see a completed evaluation of the relevant Guix Git commit:
<lfam>Building Guix itself will almost certainly take longer than building gnome-music, as far as your own machine is concerned
<porcupirate>Unknown command line option: CONFIG_SHELL=/gnu/store/vx6vfbmmazvfi7vp8xyjn2mcyylvw9gn-bash-minimal-5.1.8/bin/bash
<porcupirate>Is there a way to remove default configure options?
<apteryx>lfam: re Python as a regular input; are you sure? typically I see Python used in the shebang of custom Meson scripts.
<kennyballou>lfam: I figured it would be somewhere around there. I'm converting from nixos. I've always wanted to use guix instead but I wasnt't able to due to environment issues at the time.
<lfam>apteryx: If the built package keeps a reference to Python, then I think it's classified as a regular input
<lfam>Not every one of these packages does keep a reference, either. For example, Shotwell needs Python to build, but does not keep a reference to it
<lfam>Regarding gnome-music, the executable is wrapped with GUIX_PYTHONPATH, so it will be used at run-time. I believe that means we should categorize Python as a regular input
<lfam>(Several of these packages do that)
<nckx>porcupirate: No, you'll have to (replace 'configure …) and call the configure script yourself. If it doesn't accept CONFIG_SHELL it probably won't accept the majority of ‘standard’ (autotools) anyway.
<nckx>*arguments anyway.
<porcupirate>It doesn't even take --prefix :(
<mbakke>it would be neat to have --without-input and --add-input
<efraim>At some point it's too many flags
<civodul>--add-input (or --with-extra-input?) would be useful for instance when building autotools-based packages from Git instead of from tarball
<porcupirate>hmmm... what could --without-input break...
<porcupirate>And could it be used to modify build system inputs?
***daviid` is now known as daviid
<apteryx>lfam: agreed that if the package makes use of GUIX_PYTHONPATH, that's a clear sign python should be among its inputs
<apteryx>porcupirate: lacking a --without-input (which would be nice it seems), you can always replace an input by something dummy, such as 'hello'
<porcupirate>Which is what I already do.
<nckx>\o/ to hello being the null pointer/<none> of inputs.
<vagrantc>mbakke: were you actually able to build arm-trusted-firmware-imx8mq ? i thought support for it was basically dropped upstream
<vagrantc>mbakke: ah, without debugging symbols!
<porcupirate>I'm working on scummc-toolchain. It's frustrating that the maintainer clearly once used autotools to generate configure but broke it and removed all the autoconf files.
<lfam>What's the new bot in the channel?
<nckx>A friendly beast that means no harm and eats daffodils for tea.
<porcupirate>The maintainer didn't remove autoconf files. Such files were never added...
<porcupirate>Truly such is the crime of autoconf neglect...
<lilyp>why would you want source code in your source code repo?
<porcupirate>The worst parts are it doesn't take --prefix and it builds to a target-specific directory whose name depends on `hostname`.
<porcupirate>At least I can specify --buildroot
<f1refly>would it be easy to adapt this receipe for guix?
<lilyp>f1refly: no
<lfam>That package recipe looks straightforward, overall. I do wonder why it doesn't seem to have any dependencies, though. That's very unusual for Rust software
<civodul>yeah, it most likely bundles its dependencies
<civodul>via Git submodules i suppose
<lilyp>if helix is a crate or something, you could try recursive import
<lilyp>if not, you have to manually track down the dependencies used in cargo.toml
<jpoiret>it has a bunch of deps, looks like nixos does things differently
<jpoiret>doesn't look very funky though
<lfam>It's a case where adapting the Nix recipe might be hard, but simply importing the program via Guix could be trivial
<f1refly>how does recursive import work?
<lfam>I don't know, but it's what you want to use
<lilyp>f1refly: as a user, you just add --recursive to your `guix import' invocation
<lilyp>conceptually, it tries to use the same importer again and again for dependencies that are not known to guix yet
<f1refly>well, it builds, so thats nice
<vldn>sneek: botsnack :*
<vldn>is it possible to use the (map specification->package magic inside a package definition?
<vldn>that i don't have to include every input manually?
<vldn>(use-modules ....)
<mbakke>vagrantc: ...but that's as far as I got on the free firmware journey for the Cubox Pulse :(
<vagrantc>mbakke: i am fairly certain all imx8mq need some binary blobs for DDR training, unfortunately
<vagrantc>mbakke: maybe someday that will be replaced by something that works...
<porcupirate>Of course it's not detecting readline...
<porcupirate>What package makes libtermcap?
<dongcarl>I figured out that the mingw-w64 builds are failing because of the newly introduced `--enable-compressed-debug-sections=all` flag to the base binutils... However, I'm not sure why it's failing
<ytc>sometimes, while a guix update is working it suddenly pauses. and i have to cancel the process and re-run the command. do you have that problem either?
<SeerLite[m]>vldn: I guess you could but I'm not sure if it's good practice. I don't see any packages in the guix channel that do it like that
<SeerLite[m]>ytc: Does it happen when it's downloading substitutes? Like after downloading one it suddenly stops? That happened to me a few times when I first installed Guix but haven't had that problem since
<ytc>SeerLite[m]: no, it usually does that in the "make" process.
<porcupirate>sneek: botsnack
<ytc>it has just happened in at "make check" process so i decided to ask you guys.
<sneek>wb vldn
<vldn>@SeerLite i tried but it not worked =/  yep just wanted to do it for building new packages till i know what i need
<vldn>sneek: ty! botsnack
<porcupirate>How can I guarantee a phase fails? Shouldn't #f at the end of the phase work?
<jpoiret>no, this is being phased out i think
<SeerLite[m]>vldn: What did you try? You need to include (gnu packages) to get specification->package
<jpoiret>you can just do (please-error) or some other unbound thing
<nckx>porcupirate: Just write ‘fail’ where you want to fail.
<nckx>‘fail’ is very unlikely to be bound to anything.
<nckx>Or ‘punt’ or whatever you want.
<nckx>I usually use a naughtier word.
<SeerLite[m]>ytc: Any specific package you get this issue with or is it a common issue with all of them? It's never happened to me
<porcupirate>like "die" in perl?
<SeerLite[m]>porcupirate: (error) works
<nckx>porcupirate: That would be (error ["message"]). Writing ‘aaaargh’ or whatever just fails because it's not a bound variable name.
<SeerLite[m]>Alacritty build fails on master ;_;
<ytc>SeerLite[m]: mutter-41
<ytc>it halted again. i should wait for the substitutes i guess.
<SeerLite[m]>Hey so what's done when a (Rust) package requires a version of a dependency that's older than the one available in Guix? Just force it to use the newer version? Alacritty wants bitflags<1.3.0 but Guix has 1.3.2
<nckx>SeerLite[m]: What does ^version mean in Rust?
<SeerLite[m]>Uhh no idea
<nckx>That makes both of us.
<jpoiret>fwiw go has similar issues and in that case you can just try building with the newer version
<jpoiret>but nothing's guaranteed to work
<nckx>Whatever ^0.22.0 means, 0.23.1 doesn't match it.
<SeerLite[m]>The error says it tries for bitflags>=1.1.0, <1.3.0
<ngz>caret means you can take any other version as long as it keeps the left-most non-zero digit.
<ekaitz>apteryx: nautilus fails too
<jpoiret>eh, then you'll need the older version
<ekaitz>problems with meson-install
<nckx>ngz: Wow.
<nckx>Also, thanks.
<SeerLite[m]>jpoiret: Would I have to patch the cargo file?
<jpoiret>just install kitty™
<jpoiret>that was my number one con for alacritty heh
<jpoiret>you could try patching the cargo file
<nckx>a400a6422755897aa18e0768f0b47a577ad729f1 seems to be the cause.
<jpoiret>but you should look at the bitflags 1.3 changelog to see if there are any breaking changes
<SeerLite[m]>Good idea
<SeerLite[m]>ytc: It just finished building mutter, didn't have any issues. Maybe you just have to wait a bit? Or does it hang for a very long time?
<jpoiret>i only see bitflags = "1" though
<jpoiret>so 1.3 should work but it's just my naive understanding here
<ytc>SeerLite[m]: when i check the htop, it shows some processes of 'guixbuilder'. but they're using 0% cpu.
<ytc>speaking of guixbuilder, how can i see the build log?
<SeerLite[m]>You can try `guix build mutter` and it'll output the log as it builds
<SeerLite[m]>jpoiret: You're right, that's weird
<jpoiret>if it fails also you'll get a build log
<SeerLite[m]>Yeah the thing is it hangs so that doesn't happen
<SeerLite[m]>jpoiret: I missed a line in the logs, it isn't Alacritty that fails but a dependency
<SeerLite[m]>So it's rust-nix
<SeerLite[m]>That one asks for bitflags "1.1"
<SeerLite[m]>I don't understand why "1.1" would want specifically <1.3.0 though
<SeerLite[m]>Shouldn't it be <1.2?
<jpoiret>1.1 should be enough (somehow?)
<jpoiret>i think it might be one of its deps that itself requires bitflags with a diff version
<SeerLite[m]>I mean `guix build rust-nix` works
<SeerLite[m]>No idea, I'm confused
<SeerLite[m]>Here's the build logs for Alacritty:
<SeerLite[m]>Oh wait I get it
<SeerLite[m]>Alacritty asks for an older version of nix, which doesn't have the "1.1" patch
<SeerLite[m]>So to fix this what I have to do is patch Alacritty to use a newer nix
<porcupirate>Scummc is frustrating. Which is better: make a hidden package that installs everything to a tarball, then make a public package that extracts that tarball to the package's output, or make a package with an install phase that copies everything from a particular directory with a name that depends on the compiler version and target?
<porcupirate>I suppose another option is to build the tarball and extract it to target all in one phase...
<nckx>civodul: manual.css is the 👍
<nckx>Is the ⊕ supposed to be that (‘add’?) or is my Firefox misrendering?
<SeerLite[m]>Hm. Alacritty doesn't have rust-nix in its cargo-inputs. How is it finding it at all then?
<ngz>It comes from alacritty_terminal crate
<SeerLite[m]>Oh then that's the package I have to patch and not alacritty
<ngz>Maybe simply upgrading alacritty would solve the issue.
<ngz>I see 0.10 was released.
<ngz>and alacritty_terminal was bumped to 0.16rc4
<SeerLite[m]>Oh you're right, I missed that. I just saw "latest: 0.9.0" in the main github page
<SeerLite[m]>Those are release candidates though, is it fine to use them?
<ngz>A release candidate that builds is more interesting than a regular release that doesn't, IMO.
<SeerLite[m]>Yeah right, just thought it'd be better to patch the stable version instead. But it looks like Guix includes many packages that are RCs