<blake2b> apteryx: nice, I have to use VNC for remote desktop stuff occasionally so thats good news <dthompson>anyone know what would make export-path on a local store connection fail? <dthompson>after much hacking I've narrowed it down to a signing issue. <dthompson>blake2b: it's the same "corrupt archive" error I mentioned earlier. <dthompson>I just hacked the code to disable archive signing and the archive is able to be exported, but fails later because a signature is required. <blake2b>is this a system that was dormant that you're now bringing up to speed? <dthompson>this is on my laptop which should be relatively up to date, but perhaps the daemon that's running is not the version I think it is... <blake2b>do you have guix installed with guix? <blake2b>I know I had similar problems with a signing key issue some time ago and the issue ended up being that I had accidentally installed the package manage in my user profile <dthompson>yup. and I have a systemd service that starts the current guix for the root user. I'm updating that now. all this time I thought the issue was the remote connection so I haven't looked so closely at the local setup. <dthompson>once I find the root cause I hope I can see a way for guix to generate an error clearly explaining what is wrong <dthompson>because the error right now is extremely cryptic <blake2b>wait so you do have guix installed in your profile? <dthompson>in the root user's profile. I use that profile for running the daemon so I can 'guix pull' as root and get the latest then restart the daemon. <dthompson>a-ha! looks like it was the local daemon that was too old. <dthompson>quite old at this point. I don't remember how far back this issue started for me. <blake2b>oh wow yeah, thats about a year or so <dthompson>I've been in a loop where I'd try, fail, and then give up for months at a time <dthompson>I know I've tried various things each time but I don't remember what so I can't really say what the root cause was initially. <dthompson>sending 2gb of data to my server. it's been awhile lol <dthompson>a whole new world. gotta gc the old generations to get the space back after. <blake2b>I somehow borked my email a couple months ago, making it so that I can't use git-send-email, and have been wrestling with it on and off for evenings at a time, so I feel you <dthompson>blake2b: yeah sometimes there's some annoying issue that just drains your energy and you can't bear to work on it <elais[m]>When submitting a patch that includes updates to multiple patches all related to the one package I'm updating (in this case alacritty) do I need to send a separate patch for each package? <elais[m]>multiple packages all related to one package I want to update* <Cairn>Hey! If I'm aiming to package something with some dependencies which are already packaged as open patches, what should I do? <Cairn>Here's my assumption: I'll use the definitions of those open patches, for now, then I'll submit my patch and say that it depends on another patch being submitted. Does that sound alright? <elais[m]>looks like there's a few things that could move forward, apparently a patch series to update Alacritty is out there already? <elais[m]>It's just a couple months old and the thread is broken in multiple parts <pkill9>is it possible to track windows based on the binary that created them? <Cairn>pkill9: Seems like xwininfo doesn't give you what you're looking for <Cairn>But it gives the window ID, so you could use that with other X tools <Cairn>Only useful if you're using X of course <apteryx>dthompson: you could set build-locally? to #f <apteryx>to avoid sending 2 GiB to your server <apteryx>blake2b: glad there's at least a potential VNC user. I'm now trying to unlock XDMCP in our gdm. Seems it was buggy in 40.1. <apteryx>the accessibility buttons in GDM don't work; could someone confirm? <trevdev[m]><apteryx> "the accessibility buttons in GDM..." <- How may I help? <trevdev[m]>Any StumpWM peeps on? And/or CL? I'm trying to de-funk my understanding of how 3rd party libs should work. The whole stumpwm guix situation looks to be all derived from one source package and most easily installed on the root system much like stumpwm itself. I managed to write my own gexp to install my contrib module picks in my guix home env, but I'm having problems getting sbcl-slime-swank to work in either case <apteryx>trevdev[m]: if you have GDM as the login manager, on the login screen, there is a top right accessibility menus, with toggle such as High Contrast or such <trevdev[m]>I have a pretty bare gnome install, let's see what happens <trevdev[m]>apteryx: I toggled the toggles and they did not toggle <cnx>fellow guix, what emojus font do you use? <dgcampea>are mirror/fallback links possible for origin data types? I'd like to have a origin that tries to (git) fetch over http/ssh first and if that fails, a local path <polyex>ty guix ppl for making the best OS with the best tech (except need a FS like ZFS)!! <pkill9>polyex: it has btrfs which is similar is it not? <pkill9>also is the ZFS nonfree licensed? <examors>It's CDDL, so free, but not GPL-compatible <examors>btrfs is great though. I love the transparent compression. I have something like a 40% compression ratio on my /gnu/store <polyex>heard too many corruption stories about btrfs <examors>Hmm, ZFS is actually packaged in Guix so you should be able to use it if you want (maybe not on / though?) :D <fiesh>we've been using zfs on linux for many years on our production system (on /, Gentoo based), absolutely rock solid file system <fiesh>I guess if you only have one device, you can also go for btrfs and have a very similar feature set. but if you have more than 2 devices and want some form of redundancy other than mirroring, zfs is your only option for a good fs <polyex>fiesh can zfs work great for guix boxes? <fiesh>I have no experience with this at all, but I don't see why it wouldn't <dthompson>I've wondered what caused this issue for years, so big thanks to Evgeny for identifying the root cause! <sneek>dthompson, you have 1 message! <sneek>dthompson, nckx says: Why not use /root/.config/guix/current/bin/guix-daemon? You seem to have thought this through, but I don't see what further downgrading buys you — apart from bugs like this one :). It's roundly discouraged and might be made hard to impossible in future. <yuu[m]>examors: btrfs is good, but if when doing serious stuff i would prefer zfs for reliability <yuu[m]>when bcachefs is mainline, we can try that instead <acrow>Good to be back with the guixers... <tricon>acrow: "Wow, what a great audience!" <acrow>tricon: Yeah, it's a good crowd. <apteryx>make check TESTS=tests/guix-system.sh fails for me <apteryx>fiesh: "some form of redundancy other than mirroring" what kind of redundancy are we talking about? ***dsmith-work is now known as dsmith
<sneek>Welcome back dsmith, you have 1 message! <sneek>dsmith, dsmith-work says: Sent from #guile ***dsmith is now known as dsmith-work
<acrow>roptat[m]: Getting java-xalan-interp into guix has been in the works for a long time and been carefully reviewed after removing all the apache excesses. I don't want it to fall by the wayside. <acrow>roptat[m]: Getting java-xalan-interp into guix would also open doors to many other packages that depend upon a working xalan implementation. <acrow>roptat[m]: Please take a look. I think it's in good shape. ***Dynom_ is now known as Guest1706
<cehteh>anyone from the guixers at froscon? *acrow begins opening link in icecat. *acrow notices icecat disk accesses proceeding. *acrow eventually reads of missing pieces of hardware abstraction layer for the NVMe hardware. <Cairn>So it seems like `guix import go` isn't in great shame right now. It's fine to just manually package dependencies in the mean time, right? <acrow>Cairn: there are many ways to live. <nckx>dthompson: Oh. That's an unusual interpretation of <in the root user's profile>, but I'm just happy you're not running insanoguix. <pkill9>is there a way to cmadd to the guix home on-first-login or whatever stuff? basically, to write a .profile file in guile without changing the login shell to guile <nckx>acrow: I didn't notice the timestamps at first and hence didn't get your point. Wow. <demitasse[m]>pkill9: i tried your script for app images and i got an error msg <pkill9>you need to run it with guile as root <pkill9>looks like it's trying to run it with bash <acrow>nckx: Yeah, I took a little jab at how long it takes the default guix browser to start up. <pkill9>run "sudo guile app_images_script" <acrow>nckx: It's unfair though because I don't think I can fix it. I am just grateful that it's available in guix. <nckx>acrow: I can't find where it's the default. <acrow>nckx: Although I am also grateful for the availability of nyxt and flatpak! <acrow>nckx: I may have mispoken because I see I have no BROWSER set. But it is the default from within emacs. Which is where all the productive things happen. :) <acrow>nckx: Now that is something I ought track down and change. <nckx>Everyone knows that eww is the standard browser. <nckx>Interesting. That must be IceCat registering itself as default (or, only) through XDG (guess). <nckx>unmatched-paren: I'm going to save some time and skip straight to netcat. <nckx>"later renamed Nexus to avoid confusion between the software and the World Wide Web" <acrow>I wonder how XDG sets a default browser. I see no XDG_BROWSER -- but many other more abstract things... <nckx>The xdg-open man page is broken (if readable) here. <unmatched-paren>Oh, that reminds me. I need to send a patch to fix the moreutils man pages <nckx>Of course it ends in XML. <nckx>unmatched-paren: That exactly describes what man xdg-whatever shows here. <acrow>nckx: Opening new realms for me, xdg-open -- but it isn't installed -- albeit by snap and go-github-com-skratchdot-open-golang!? <unmatched-paren>and since you can't patch go packages in phases, you have to use propagation like that <acrow>That is another reason I like guix -- always finding out new(er|ish) stuff. *acrow modifies his config.scm and home-configuration.scm package listings. <acrow>There was a time when I believed %desktop-services betrayed me and so I went by my own devices and lo now I discover the xdg-utils. No wonder awesome and EXWM are comparative wonders for me. :) BTW, this also reminds me of how that MacOS does things.... I guess this is the future. :/ *acrow is humbled yet again. <nckx>Uh, I didn't mean to imply that it would fix all your problems, but I'm glad you've found love. <acrow>nckx: Always a pleasure working with you! <acrow>nckx: Perhaps too much coffee is really to blame. :) <pkill9>acrow: what do you mean is the future? <nckx>acrow: I'm a firm believer in there being no such thing as too much coffee. <acrow>pkill9: Well, for me, bc I didn't have xdg-utils installed on any of my systems. It seems this causes some setups to have more problems. <acrow>pkill9: I think I'd underestimated how commonly we now use environmental wrappers to start things. I always just relied on the shell. Even when employing rlwrap. :) <acrow>vagrantc: ah!, of course. That is why it has gone so long since identification. <nckx>Has this been fixed or discussed upstream? Bug report isn't clear. <vagrantc>or people are still using regular SSDs and spinning rust <vagrantc>put a little grease on the axle of my newly rebuilt bike trailer, it's fine <acrow>the flagrant rust spinning has increased the intrinsic angular momentum of the universe to the point that physicists now believe in dark matter. ;) <nckx>Just replace it with a solid state axle. Wheels were a mistake. Sleds are the future. <nckx>When I hear someone say ’spinning rust’ they immediately become this super-sleazy SSD salesman in my mind, trying to insult me into buying something. It's not a good look. <vagrantc>not well bootstrapped on arm platforms, though :/ <acrow>BTW, if NVMe confounds the abstraction layer I guess it is good that Optane has been cut loose.... Just trolling to see what people think... <nckx>I thought the point wasn't that you couldn't add the very same abstractions over NVMes, just that people chose not to because it was a good breakpoint to drop some ancient ones. <mbakke>implementing new abstractions takes work, but tends to pay off in the long run ... mostly people are just lazy and/or cowardly and opts for the least amount of friction <acrow>nckx: I'm not ignoring you -- I do not know but am also curious. What you say makes it seem much less of an issue, aligned with action we see, but others have tagged this as a high priority and that fits with what vagrantc says that imeans we cannot successfully bootstrap from NVMe hardware (the newest stuff). Just seems backwards to what I hear said... Hmmm. <acrow>mbakke: true, but we may want to introduce you to some better people. :) <vagrantc>there are some kinds of lazy that are better than the alternatives <vagrantc>take, for example, tricking, er, enticing someone to automate a task that you had been doing manually <nckx>acrow: I think you might have misunderstood me. I didn't mean to comment on the bug report with that last message. <nckx>I agree with the ‘important’ assessment (hence the silence of almost a year is odd, but whatever). Mes is one of those projects that will have to adapt and do some work. I certainly don't advocate for emulating the old syscalls in Mes, if that's how it came across. <nckx>Nor to imply that it wasn't a real issue. <nckx>I asked janneke in #bootstrappable if anything has changed since the last post to that bug report. <acrow>vagrantc: Have you had a chance to look at the latest goods? The multiple args problem was overcome with a little deeper digging. <acrow>vagrantc: That's what free software is all about, right? <vagrantc>acrow: not looking at things people are submitting? :) <acrow>nckx: np. All is well; I'm going to go grocery shopping bc I have to! <unmatched-paren>okay, naming opinions needed: what should be the actual name of the boolean field in <note> (for post-install notes) that suppresses the note if the package is being used via `guix shell` or `guix environment`? <apteryx>fiesh: you can use RAID10, RAID1 or RAID0 with Btrfs *apteryx is still getting "guix deploy: error: #<unspecified>: invalid G-expression input" on deploy :-( <apteryx>perhaps guix the package itself needs to be updated? <fiesh>apteryx: exactly, that's mirroring <davidl>a weird thing Ive noticed is that in the terminal when Guix outputs "expected hash" it changes the first digit, for example the package's (incorrectly) defined base32 value is set to something starting with "2...", it will show "0..", and for a "9.." it will show "1.." I have seen this multiple since defining 100+ node packages recently. <apteryx>so if you meant, RAID 5 or RAID 6, say that. <Cairn>Hey unmatched-paren. I'm using your aerc patchset as a starting point for a different package, since you've already packaged a lot of the dependencies I need. I'm curious about your `go-github-com-protonmail-go-crypto` packages. I get "warning: bad use of '_' syntactic keyword" when I try to use them. <lilyp>davidl: the first character can only be 0 or 1 due to the length of sha256 <davidl>lilyp: aha, thanks, that clarified that <rgl>is there a way to preseed (or make it execute commands) the live iso into an automatic installation? <Cairn>unmatched-paren: Any of the ones with that prefix. Also, I only see those prefixed once in the list, so I don't know what a different version would do for me. <Cairn>I guess I'm just trying to figure out where `(#:import-path _) "github.com/ProtonMail/go-crypto/brainpool")` works <Cairn>You only use that syntax to define the ones with that prefix. <Cairn>I was missing `#:use-module (guix utils)`. My bad. <lilyp>rgl: not that I'm aware, but as soon as you start ssh, you could just run your script over the network :) <rgl>lilyp, hummm that might work! what is the username/password? <rgl>by starting the live iso, it will just start ssh automatically and let you login as root without password? <lilyp>but you can run passwd beforehand <lilyp>not sure how ssh is configured tbh but everyone with physical access can open vt2-6 as root <rgl>I want to automate the installation somehow. there will be no user. <rgl>I send send keystrokes to the machine thou. <tricon>rgl: only thing i've used to do things like this is Packer, but that was for eventually generating a VM. <rgl>tricon, oh indeed, I want to first try with packer. do you already have/known a working example? :-) <rgl>or maybe, I should just cut a new iso that simply looks at the kernel command line and calls guix deploy? <rgl>I mean, it looks at the kernel command line for getting the url of the deployment specification. <tricon>rgl: i may have some ol' code somewhere. i'll look this weekend and let ya know if i find something. <rgl>tricon, cool. thx :-) <tricon>it'd be nice to have some way to preconf from an ISO via Guile. <Cairn>unmatched-paren, yeah, it looks like I've been using it. You just havent't updated any of the `go-github-com-protonmail-go-crypto` prefixed packages since version 1, so I didn't see any differing versions of those. <rgl>indeed, it would make bootstrapping a new system much easier. as-in, pxe install. <tricon>rgl: I have flirted with the idea of PXE-booting a tiny distro for hosting a VM, then pushing an OS (e.g. Guix) to it as a VM... <minikN_>Hello. I use chromium and everytime I pull and there is an update for it I needs to get compiled from source (I'm using substitutes). But it never works, it goes to 100% (which already takes several hours) but then just stops at 100%. It's been going for two days already. Can I do something about it ? Thanks! <rgl>tricon, I can use debian-live. but its somewhat lame not being able to use guix :D <tricon>rgl: it's just a thought, though. i don't have a working implementation of this outlined or anything. <unmatched-paren>minikN_: `guix weather ungoogled-chromium` says there's a substitute <Cairn>unmatched-paren: I will, thank you <rgl>tricon, as-in, boot debian live, install the guix tools, use them to install guix to the boot disk. but, not being able to use guix all the way, is somewhat odd. <Cairn>Oh, sorry, looks like the matrix bridge is lagging today. Taking me a bit to get messages. Thanks though unmatched-paren. <tricon>related, i'm dreaming of a "Guile Ansible". would be nice to have the power and expression of Guile the way Guix does through and through but for provisioning all infra. <rgl>you are flying high ;-) <rgl>you mean that already exists? :D <minikN_>unmatched-paren: It says "/home/db/.config/guix/current/bin/guix" <tricon>unmatched-paren: interesting! i shall investigate, thank you. <unmatched-paren>> This package provides the Guix Workflow Language (GWL), a scientific computing extension to the Guix package manager. It combines the specification of work units and their relationship to one another with the reproducible software deployment facilities of the functional package manager GNU Guix. A GWL workflow will always run in a reproducible environment that GNU Guix automatically prepares. The GWL extends your Guix installation with a <unmatched-paren>to get `guix workflow` you currently need to manually set GUIX_EXTENSIONS_PATH <lilyp>actually, guix workflow works from guix shell as well: guix shell guix gwl -- guix workflow have-fun.w <tricon>unmatched-paren: i'll have to start reading through the source. there may be some things i could borrow/piggy-back on here. i do recall seeing this some time ago. <hugonobrega[m]>hello guys. I haven't been able to update my guix system in ages (I guess a couple of weeks now) because of apparent network issues, but it's now been so long that I thought maybe someone had a better idea what could be going on. I've tried several different gnu substitute server urls but they all give the same result: some variation of "guix substitute: warning: while fetching <...> server is somewhat slow; <...> error: connect*: <unmatched-paren>hugonobrega[m]: that looks like a network issue, but recently dthompson experienced a problem where that was displayed but the issue was unrelated <hugonobrega[m]>unmatched-paren: it would be surprising if it were a network issue as it's been going on for so long now (and I have no other networking issues otherwise). got any leads for that dthompson issue that I can investigate? thanks! <fiesh>apteryx: I didn't say that because I didn't mean that, because zfs has raidz1, raidz2, raidz3 -- not raid5, raid6. <minikN_>unmatched-paren: I just did a pull again followed by a reconfigure.. it is downloading the substitute.. but then it's building it anyway... : building /gnu/store/nhrl66rn909j65jghx2cdqxv6bg75sf8-ungoogled-chromium-104.0.5112.101-1.drv... <fiesh>apteryx: and likewise does not call mirroring "raid" <dthompson>hugonobrega[m]: your issue looks different than mine. my error was related to archive signing not working properly. <dthompson>that was a local error. yours is a problem with remote substitute servers. <fiesh>apteryx: if you are curious about zfs, it's one of those few software packages (like postgres) that I only have good things to say about... and that's rare :-) -- so highly recommended <acrow>vagrantc: So, have I been too slow in delivering results from the trickery of the copyright tool? Sorry about that. <vagrantc>acrow: i was saying i was slow to review ***chexum_ is now known as chexum
<vagrantc>guix refresh --list-dependent directfb ... Building the following 41 packages would ensure 63 dependent packages are rebuilt: ... <vagrantc>is there a way to easily see all 64 packages? <vagrantc>a number of those dependent packages fail to build already ... so ... i guess i just ignore them? <vagrantc>think i have directfb building reproducibly <vagrantc>of course, half the time i can build it reproducibly locally, but the build farms are different enough to introduce more fun :) <vagrantc>gnome appears to indirectly be in the list ... <vagrantc>oh, gnome is just a trivial dependency package ... not ... like ... all of gnome <acrow>roptat[m]: If you commit java-xalan-interp, I will quickly be able to get you ditaa as a bonus package! :) ***LispyLights is now known as Aurora_v_kosmose
<apteryx>vagrantc: you can report the failing packages but yes, otherwise, you can ignore them <apteryx>(or try to fix them if you have some bandwidth) <vagrantc>trying to stay focused a bit ... but yeah <Cairn>Hey, I'm a little curious about packaging a go project with a "cmd" section <Cairn>What I've done is set the import-path to "github.com/boltdb/bolt/cmd/bolt" and unpack-path to "github.com/boltdb/bolt" which seems to succeed. <Cairn>The issue is that when I use that new package as an input to another, I get an issue akin to the sort of issue I would get if I just used "github.com/boltdb/bolt" as the import-path. I'll get a message like "no Go files in /tmp/guix-build-hydroxide-0.2.23.drv-0/src/github.com/boltdb/bolt" <Cairn>So it's succeeding when I build it on its own, but causing a project that depends on it to fail. <vagrantc>acrow: your linking to the top of the thread leads to a lot of history and reading that would lead someone with limited time to not follow-up on it <vagrantc>acrow: maybe post a summary and link to that instead? for 32947 <rekado_>Cairn: I’v been having similiar problems with Go packages <rekado_>I honestly don’t know how to package them correctly <Cairn>I'm so close: I've set up half a dozen deps, and yet I'm stuck on this last issue *vagrantc was just looking at how crazy it would be to package git-bug ... but implemented in Go and feel a little lost with where to start <Cairn>rekado_: Do you have any example packages I could take a look at which have a similar problem? <rekado_>not “cmd” in particular; just the fact that Go repositories contain multiple modules and in Guix we seem to create one package definition per module. <rekado_>one example is go-github-com-biogo-hts-fai, go-github-com-biogo-hts-csi, go-github-com-biogo-hts-cram, etc in (gnu packages bioinformatics) <Cairn>Ah. Well, I guess it's fine to make one general package like `go-github-com-biogo-hts`, since it'll provide all the submodules <Cairn>But I'm not sure if that's too general of a thing <rekado_>I tried and failed, which is why I ended up with all these sub-packages. <vagrantc>acrow: but from a quick read, it is hard to tell weather the licensing issues are resolved <Cairn>Yep rekado_. Like how unmatched-paren said earlier, they merged all their separate packages for `go-github-com-protonmail-go-crypto` into just a package titled that <Cairn>Anything after version 1, I believe. Although they recommend looking at v6 <vagrantc>acrow: it's not clear how to use the --exclusions argument ... <Cairn>Alright, alright, I got it. I misremembered the error; I wasn't getting a missing file issue when I just used "github.com/boltdb/bolt" as my input, but I was actually just getting a failed test issue. I used "#:tests? #f" and it succeeded. <vagrantc>acrow: debian/copyright-scanner -d $(pwd) --exclusions=debian/ ... In procedure car: Wrong type argument in position 1 (expecting pair): () <vagrantc>acrow: seems to run if i used --excludes=^debian/ ... no idea if it is working as expected <acrow>vagrantc: Where people have questioned what this Apache project has licensed we have made inquiries upstream. Those suspicions have been documented and you will see that those discussions have ended without any changes by the Apache project. As I see it we have done more than the due diligence needed to package a widely used free software library whose license continues to be maintained upstream. <vagrantc>acrow: making a clear, explicit summary and then pointing people to that will make it easier for someone to review <vagrantc>acrow: relaying all that in IRC doesn't help a lot, per se. :) <vagrantc>acrow: for more exciting news ... the file stemming/trimming is cool, bit it's leaving a leading / <acrow>vagrantc: What we have done on guix's behalf is carefully review the source to find and remove embedded dependencies and binaries that make the build easier. I don't think anyone would assert that what remains is inappropriately licensed. I still trust that the upstream is a reliable free software provider. <acrow>vagrantc: I can get rid of the leading backslant -- that actually happened as part of a fix and I ought to have nailed it down better. <vagrantc>acrow: but asking someone to review, and then pointing them to the whole thread, instead of a summary of the rest would help <vagrantc>acrow: at least, in my opinion it would help <vagrantc>acrow: continuing to debate on irc about it perhaps less :) <acrow>vagrantc: Well I had been considering changing my nick from acrow to relentless-nag. <vagrantc>acrow: i can't get the patch for 32947 to apply on master ... seems like it wasn't formatted correctly <vagrantc>acrow: er, it's not even clear which patch to try to apply <vagrantc>acrow: nope, i can't figure out what patches are old copies, what patches are current copies, and what patches you actually want applied from that bug report <vagrantc>acrow: so maybe reposting all the patches you want wioth [PATCH vN] in the subject ... maybe with a summary of the current status ... would really help make it possible to review ... 