<vagrantc>cbaines: subscribed, presumably needs to be moderated <cbaines>vagrantc, yeah, I'm not quite sure who does that <vagrantc>hrm. would expect "guix pull --keep-going" to uh, keep going even if it fails to download a tarball or two <cbaines>vagrantc, the URL given has // at the beginning of the path, which I think is an issue <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"... <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>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>I can just email the following to 53330@debbugs.gnu.org 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? <jgart>vagrantc, will the above work too? <nckx>jgart: Sending commands in the message body to NNN@debbugs would not work, it would just send a literal ‘close 53330’ reply. See <https://debbugs.gnu.org/server-control.html> for the available commands and the ‘control server’ address that accepts them. <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. <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 =/ <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>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 <Andrew>PotentialUser-5: You want to install to a primary partition, or do you have all of them filled up? <Ribby>I just setup my gnu/guix interface design. Whew! <lfam>The python-aiohttp fails to build since the version-1.4.0 merge <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... <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>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 <Ribby>It's a specialized product, I assume. <Ribby>The first in the list, bingo. <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. <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 <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 <lfam>Check the soversions and make sure they are equivalent / compatible <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? <lfam>The thing that describes the ABI version <nckx>It was just libexpat.so.1 IIRC. <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. <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. <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>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. <vagrantc>nckx: i have confidence in your ability to break things! :) <nckx>‘guix pull: error: You found a bug’ <lfam>nckx: Is that one of the CVE fixes? <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. <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>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>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>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 <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 ***califax- is now known as califax
<v1dl00fyuq6f[m]>hmm is there a way to sanitize it? like if the `(substitute*` string was not matched to throw out error? <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: #\) <lfam>Sorry, I should have mentioned that <v1dl00fyuq6f[m]>just when i though that Posix ere can't be more annoying you found the way! <nckx>IIUC your arrow should be pointing from ‘"\" pyInfo’, one line lower, because that's where a ‘,’ is missing. <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`/ <nckx>It is not relevant to my answer. <nckx>You forgot a ‘,’ in your second line. <v1dl00fyuq6f[m]>Is there sanitize it so that it fails if `substitute*` doesn't match anything in the file? <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 <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 <lfam>It's not just for patching dependencies <lfam>It's for any textual changes <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. <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? <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… <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. <lfam>It's a frustrating situation <nckx>Now you're just showing off. <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 `https://issues.guix.gnu.org/53334` 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 <Ribby>Like, if I was to boot install Guix with a bridged connection for updates/upgrades. <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 <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 setup.py: 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! :) <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 <lfam>Yeah, we could also try a patch <lfam>The package really tries to prevent you from building from Git <apteryx>seems the last release is from Dec 5 2021 <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>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 setup.py. I'm now building up to gqrx, which was my other broken package <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? <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..." <- guix.miraheze.org 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]>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 <vagrantc>well, at least you're sharing the pain with each and every one of us :P *vagrantc prepares to ramble <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? <vagrantc>jts: i didn't hear anything mentioned, but you can always invoke an older guix instead <vagrantc>recent updates have been a bit more intrusive than was expected ... <lilyp>does someone have experience with launching dbus inside a container'd guix shell? <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 <gyara>If I want to update clap to 3.0.5, does it means I need to check all packages deps on clap? <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? <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>allana: it's not possible currently, but would be nice <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 : ) <civodul>v1dl00fyuq6f[m]: currently there's no way for figure it out, other than using "find /gnu/store -name libGL\*" <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 <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 <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 <jpoiret>i'm using "texlive-bin texlive-tex-ini-files texlive-latexconfig" <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 <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 <rekado_>the cmr10 thing … I fixed that on wip-texlive! <civodul>should we hide texlive-bin and texlive-latex-base? <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! <jpoiret>seems like texlive-bin uses sed/uname/mkdir, so --pure doesn't work <jpoiret>oh great! i imagine on the wip-texlive branch? <rekado_>commit a6499572b3cc564c197bc86d36a23ed7034944b8 and 871504e5bf9ae43d539955d4dc68f8a577ba2b1a <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 logs.guix.gnu.org <gnoo>how did you add and did you export afterwards? <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? <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 <gnoo>you can break away from the default <gnoo>just try it now, Ctrl+alt+f2, login with username, password then type startxfce4 <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 <rekado_>I think the tex fixes are broken again by the 1.4.0 merge <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 <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 <lilyp>If you launch GNOME normally in Guix (and I'm pretty sure it's the same for XFCE), your login profile is applied <lilyp>probably maybe, in your case very likely <abrenon>~/.bash_profile is one of the places where bash is going to look for its login 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 <lilyp>attila_lendvai: I'm pretty sure Guix uses guile-libssh2, which you guessed it... <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 ? *abrenon is going to have to break everything again : ( <lilyp>abrenon: Guix System or foreign distro? <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. <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 ~ <attila_lendvai>there's a new release of libssh2. any obstacles to updating it to 1.10.0? <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 <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 <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 <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 <abrenon>5ed33b0d05902de921e972d41168910107c93515 <apteryx>sorry, guix at 1ebc9e88234812f6e6d00694ed7d27ac2ac4dc05 <apteryx>what hash output by 'guix describe'? <abrenon>the one I pasted above 5ed33b0d05902de921e972d41168910107c93515 <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 <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 <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 <abrenon>same error in the tests, when spawning some "python" "-c" command <apteryx>I don't understand, it builds fine here, even on 5ed33b0d05902de921e972d41168910107c93515 <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>/gnu/store/zaj5cr6lx5zkcxrjdjdiqi969sz6m3hf-python-dbusmock-0.24.1 <apteryx>perhaps a nondeterminist problem? does it sometimes succeed, sometimes fail? <abrenon>produced the same hash within /gnu/store <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? <abrenon>they reach tests.test_systemd.TestSystemd <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>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 : ) <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 <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>(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 : ) <zimoun>I think the package is doing a mock. <zimoun>jpoiret, apteryx: are you using special flags for the daemon? <jpoiret>nope, just additional substitutes servers <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 <zimoun>I am not able to build it with 923dcc3 from Jan. 14. But the susbstitute is available. <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' ? <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 ? <apteryx>also, python-nose is kind of obsolete (unmaintained), but I'm guessing unrelated <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>(overriding the current python-dbusmock package definition) <zimoun>apteryx, missing the definition. :-) <apteryx>"do not spam" thanks, paste.debian.net <abrenon>wow the tests don't look the same at all <abrenon>/gnu/store/136yrcg7zwbmgd91abmsw3xaimlj3sp9-python-dbusmock-0.25.0 <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>I'm not sure why it doesn't impact every host the same though. <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 <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 <apteryx>zimoun: the failures on i686 appear transcient to me; probably just need a couple restarts <zimoun>hum, ok. Let see if build gcc@10 is enough. :-) <apteryx>if you see other dubious failures please let us know! <abrenon>guix updated, building my system again : ) <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 <apteryx>python-dbusmock affected mutter at least <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>one second, I lost the output by accident <abrenon>ekaitz: trouble with python-dbusmock by any chance ? : ) <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 <ekaitz>should i include it in my system directly? ***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 <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 ***ChanServ sets mode: +o antiharasserbot
***antiharasserbot sets mode: +b $r:@*:asozial.org
<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 <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. <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 <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. ***antiharasserbot sets mode: +b $r:@*:ggc-project.de
***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>rather (@ (gnu packages commencement) glibc-final) <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 <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! :) <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>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, you have 1 message! <sneek>notmaximed, podiki[m] says: thanks for earlier, both patches updated <nckx>Them: you can't buy love. <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? <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>Just wait a minute or two <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>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 <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. <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 ***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' <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 <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... <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`. <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 <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 <lfam>It's a case where adapting the Nix recipe might be hard, but simply importing the program via Guix could be trivial <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 <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? <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... <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. <ytc>it has just happened in at "make check" process so i decided to ask you guys. <vldn>@SeerLite i tried but it not worked =/ yep just wanted to do it for building new packages till i know what i need <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 <nckx>porcupirate: That would be (error ["message"]). Writing ‘aaaargh’ or whatever just fails because it's not a bound variable name. <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? <jpoiret>fwiw go has similar issues and in that case you can just try building with the newer version <nckx>Whatever ^0.22.0 means, 0.23.1 doesn't match it. <ngz>caret means you can take any other version as long as it keeps the left-most non-zero digit. <jpoiret>eh, then you'll need the older version <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]>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>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 <jpoiret>if it fails also you'll get a build log <SeerLite[m]>jpoiret: I missed a line in the logs, it isn't Alacritty that fails but a dependency <SeerLite[m]>I don't understand why "1.1" would want specifically <1.3.0 though <jpoiret>i think it might be one of its deps that itself requires bitflags with a diff version <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. <ngz>s/interesting/useful <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 
