<nckx>If you use font-terminus: does bold work? Because it doesn't work for me in foot. Bold text is not. Very strange. ***caleb__ is now known as Kolev
<lechner>Hi, how can I add or replace a file in an upstream distribution for an inherited package definition, please? <lechner>just via patches? in one case, i am happy with an empty file, via touch <lechner>how about (snippet '(begin (touch-file "./README") #t)) <lilyp>lechner: call-with-output-file is your friend <jackhill>uh, oh, I'm getting into the texlive rabbit hole with my first package, #55644 <jackhill>but hopefully that means I'll be able to stop using the 3+ GiB package soon! <lechner>lilyp: thanks! do i have to use (call-with-output-file "README" (lambda () (newline))) with a 'builder'? <lilyp>lechner: builders are low-level, you don't need to think about them inside your snippet field <lilyp>just call-with-output-file as you would "normally" in scheme <lilyp>check display for writing string literals and format for formatted output <lilyp>(idk what you'd want to do to the README, but whatever) <lechner>i only need an empty file Makefile.am: error: required file './README' not found <lilyp>ahh, but where is ./ – is this in the root, in a subdirectory, elsewhere? <lechner>someone removed in an eager attempt to go from ./configure + m4 to autoreconf <lechner>root directory, and required by automake <lilyp>try calling (symlink "README.md" "README") <lechner>that would presumably go into (modify-phases %standard-phases (add-before 'configure <lechner>it's more complicated for me because the definition is inherited <lilyp>well, you could add it in a phase, but an origin snippet would also work, no? <lilyp>[use paste.debian.net for pasting code] <lilyp>yeah, just write your (snippet) into the (source (origin ...)) and you should be done <lilyp>don't forget to do (snippet #~(begin [your code])) though, because otherwise your code won't be staged <lilyp>yes, you need guile as compiler but also guile as interpreter for #! patching <lechner>lilyp: okay, thanks! that worked great, except both packages (one depends on the other) install scheme modules into the 2.2 site directory. that results in incompatible bytecode kind <lilyp>oh, right, you need to (substitute-keyword-arguments (package-arguments guile-wm) ((#:configure-flags flags) [your replacement flags])) <lechner>lilyp: thank you! you are very helpful <djeis>Is there an accepted strategy for packaging a library which does a dlopen at runtime to get one of its deps? <lechner>i'd like to know that too, please. what are the options? <djeis>Not a binary- presumably that could be solved, in the worse case, with a generated wrapper. But like, one .so which loads ones of its runtime dependencies lazily with a dlopen. <lechner>i am not sure how such modules are different from ELF executables in Guix, but i am new. i use libtool and libtldl on the .la/.so <djeis>In this particular case the transitive dependency comes from a driver, so the original intent was to load the version of the lib that came alongside a corresponding kernel module. <djeis>(and, in particular, the currently loaded and active kernel module) <nckx>Patch the dlopen call to use an absolute file name. <djeis>Right but then you get into weirdness where the package depends on one version of the lib but the sysadmin of the box has a different version's kernel mod loaded? <nckx>What cursed module is this? <djeis>Wouldn't be a good topic for here. <lechner>that's a kernel module in user space? <djeis>It's a kernel module and corresponding library for talking to it. <lechner>maybe use devices with ioctls instead? <djeis>API's neither documented nor stable. <nckx>This barely makes sense on a traditional distro, if that. <djeis>That's the whole reason the library exists. <nckx>You could load an older module, update the library and… then what? <djeis>Here, how 'bout this: it's a GPU driver. <lechner>why is there a dlopen call. doesn't the kernel load the module? <djeis>There's a userspace library that exposes functions for talking to the module. <djeis>The dlopen call is to load that userspace library. <djeis>That's undocumented internls. <djeis>Probably? Or ioctls, hard to say. Point is the kernel module doesn't expose a stable or even documented interface. <lechner>the issue is locating the userspace library in the store? <djeis>Yup- specifically the version corresponding to the currently loaded kernel module. <lechner>it sounds like the association with the library is greater <djeis>They're part of the space package, for whatever that's worth. <djeis>So like, I have a library called libdedisp. It needs to use this GPU, the only way to use the GPU is by way of a userspace library. It dlopens that userspace library, without care about library version numbers, because it wants whatever version is associated with the currently loaded GPU kernel module. <lechner>wouldn't the version matching resposibilty reside in the user-space module (which you call the library) <djeis>I didn't write the user-space module or the kernel module, and they seem to be written to be used in lock-step. <djeis>I don't actually know what would happen if I got the versions of those mismatched. <euandreh>Can I do a "guix pull" only for a single channel? <euandreh>Say I have channels "xyz" and "guix" in my channels.scm file <euandreh>How could I update only the "xyz" channel? <euandreh>If I duplicate the "xyz" channel into a dedicated file, guix pull complains of the file not having a channel called "guix" <lechner>Hi, how can an inherited package definition refer to the outputs, please? <euandreh>lechner: in the same way the original package definition refers to outputs <nckx>euandreh: If you specified a channel without ‘guix’, the resulting new guix command wouldn't contain guix — which is impossible and therefore forbidden. There doesn't seem to be an easy way of doing what you want, a --do-not-upgrade equivalent for channels. You could hard-code the (commit "…") for the guix channel in your channels.scm. <nckx>If you really want the --do-not-upgrade behaviour, keeping whatever commit is current without writing it down in a file, here's a terrible way to do so: <nckx>guix pull --commit=$(guix describe -f recutils | recsel -e "name = 'guix'" -P commit) <nckx>lechner: Missing ' before (list ? <euandreh>nckx: ACK, hard-coding the guix channel makes sense, I didn't consider that. I was hoping for a more ergonomic "guix pull -c xyz", that kept all channels as is without needing to do something else <nckx>Yeah, that doesn't seem to exist [yet]. <euandreh>nckx: actually, that solution only works for a file with 2 channels, "guix" and "xyz". If the file has "guix", "xyz" and "abc", both "xyz" and "abc" will get upgraded <nckx>Even my hack above works only for the ‘guix’ channel. <euandreh>yep, one would need a file with a pinned commit for each channel <nckx>That's why I phrased it as a broke man's --do-not-upgrade=, not as --upgrade-only=. <nckx>And really --do-not-upgrade=guix, fixed. <euandreh>in a way, I have to do the "git pull" part of the work, picking the correct commits, and then guix pull can go on to building the channels <euandreh>Is bug-guix a place for feature requests like this? <lechner>an alternative would be to allow the pull to complete but pin 'guix' to an earlier generation, no? <nckx>lechner: Yes, but we discussed that above. <euandreh>nckx: since you said both are fine, I prefer bug-guix because there the threads have a status of open, close, done, etc. <nckx>guix-patches was a joke :) <nckx>But, I'll still correct you: they are 100% the same bug tracker, there is no difference in power. The bug- vs -patches name is just for rough organisation. <nckx>euandreh: A polite thing to do would be to set the bug priority to ‘wishlist’. I don't know off-hand how to do so but the docs are out there if you search for debbugs priority, I'm sure. <euandreh>nckx: ack, I'll look for that. That's probably a X-Custom-Header thing <nckx>Yeah, or a control at debbugs dot gnu dot org command after the fact if your MUA makes that painful. <lechner>Hi, when the same version of a Guile module is in the store twice, but with a different commit (don't ask) which one does Guile pick? <vagrantc>lechner: it doesn't just pick modules from the store, it picks them from the operating profile, environment, etc. <nckx>Whichever store directory is either embedded into the Guile binary you're using (or transitively in one of its libraries), or is present in a variable like GUILE_LOAD_PATH, or is linked to a global location like /run/current-system/profile/lib. <euandreh>lechner: there will be only one version active, the other will be left for an eventual garbage collection <nckx>There is no ‘algorithm’, as in Guix never scans the store to compare names for whatever reason. <lechner>one is in the system profile; the other in userland <nckx>Just like there is no ‘dependency resolver’ in Guix. A points to B, or to C, but Guix never compares B to C to find the bestest at run time. <nckx>vagrantc said it more concisely. <nckx>So I'll pretend that I elaborated and clarified their answer. (Ha ha!) *vagrantc is happy to have multiple takes on things :) *nckx often wonders if my way of conceptualising & explaining things makes sense to anyone else, or is just rambling noise… <lechner>vagrantc: you often have deep, succinct insights! <lechner>it helps me learn; like your comment about co-installable but absolute paths. thank you! <nckx>euandreh: Thanks for that, I'll remember the term. <lechner>severity could also be called visibility <vagrantc>lechner: this question is basically an extension of the same "co-installable but absolute paths" issue <nckx>Now I'm curious. Why the ‘but’ contrast, vagrantc? <vagrantc>nckx: i need to leave some aura of mystery <nckx>We just wear funny hats and sing songs. <lechner>i had falsely claimed that guix prefers relative paths <lechner>i thought it went through the profile, but i see the error of my ways <vagrantc>guix is a big mess of symlinks and hard-coded paths :) <nckx>Which is vastly superior to other messes of symlinks and hard-coded paths because $reasons!!!! <nckx>…OK, maybe it is a religion. <vagrantc>well, rather than assuming everything is in a "standard" location, things are often hard-coded to the "right location for this particular instantiation" <lechner>well, i totally drank the kool-aid. all my systems are guix. i'm giong down with the ship! <vagrantc>you get some weird things like propegated inputs with python, and symlink farms to make PATH work reasonably ... but it still seems more elegant in many ways <oriansj>lechner: do the following: /usr/bin/env program and add: (service special-files-service-type `(("/usr/bin/env" ,(file-append (canonical-package coreutils) "/bin/env")))) to your config <vagrantc>i haven't even really used guix systems for more than ... updating things in guix for the most part <oriansj>the dark heresy needs not worship any gods <vagrantc>i swear, june will be the month of vagrantc working on reproducible builds in guix <nckx>oriansj: That should already be part of %base-services, for better or worse. <lechner>oriansj: will that send me back into the stone age? <nckx>lechner: Do you have /usr/bin/env on your system? <oriansj>lechner: it added the file /usr/bin/env to your guix system so that you can do the old unix solution to not having to know where things are installed <nckx>OK, I thought so. Then: nothing. <vagrantc>i thought that was added by default these days <nckx>Yeah, it is. I'm the knave responsible. <oriansj>so just use /usr/bin/env program_name at the top of your scripts and don't worry about where they are located. <nckx>Aside: I tried removing /bin/sh once and it did not end well. I suggest not trying. <nckx>I expected Guix to be all Guixy about it and not care but stuff started blowing up. <vagrantc>nckx: soon we'll have to add /usr/bin/sh :P <oriansj>well there is the disagreement over if one should (service special-files-service-type `(("/bin/sh" ,(file-append (canonical-package bash) "/bin/sh")))) or (service special-files-service-type `(("/bin/sh" ,(file-append (canonical-package dash) "/bin/sh")))) <nckx>I have never heard such disagreement. <nckx>We're a GNU distro, I very much doubt that bash is going anywhere to appease some vague and dying POSIX god of old. <nckx>Your notation made me think you meant Guix specifically. <lechner>wait, the D in dash doesn't stand for Debian? :) <nckx>Debian Almquist(sp?) shell. <nckx>Looked it up, gave myself a cookie. <nckx>lechner: Oh, did I ruin your joke? <vagrantc>yeah, i yearn for the good old days of /bin/ash <oriansj>lechner: wait until you here the one about a person who wrote a C compiler in assembly or a POSIX kernel in hex <nckx>oriansj: Stop corrupting the youth. <vagrantc>the youth were already corrupt, just like everyone else <oriansj>I shall bring #bootstrappable where I travel <nckx>Please continue bringing it to Guix. <vagrantc>well, we seem to be having a lot of fun today ... perhaps we should get back to coding and grumbling <nckx>This new bootstrap reduction is amazing. <nckx>Ah yes right grr everything sucks grr Rust. <vagrantc>yeah, the full-source bootstrap for guix is kind of the most amazing feat i've heard of in years <lechner>so how do i build with a particular Guile module, please? <oriansj>now we just need someone crazy and retired; with a lifetime of programming hacks to make smaller binaries, we could get M0 to fit in an MBR. <vagrantc>lechner: package the guile module, list it in inputs for whatever else you're building? <nckx>I have this particular cognitive dissonance about the Guix/bootstrappable bootstrap where it's both ‘this can't actually be as amazing and fundamental as I think, because that's herculean and literally everyone would be raving about it on-line’ and ‘…nope, that really is what it does, wow, why no CNN’. <lechner>i did but didn't change name or version <vagrantc>lechner: you have to build it from the same guix checkout/guix pull/guix time-machine ... <vagrantc>the name or version don't matter for the most part, it's what guix you use to build it <oriansj>nckx: it is kinda like curing third world diseases. The people who suffer really care and are greatful but outside of that no one really gives a shit. <nckx>Time to ask again: does anyone here use the Terminus font from Guix? Is it supposed to completely lack bold? <nckx>So I tried it in foot (where I spend most of my time and really care about pixels) and it was great, but… bold wasn't. <nckx>I'm guessing you wouldn't tolerate that and have the bold? <nckx>Are you saying that particular size has no bold? <nckx>That's hilarious. I didn't try other sizes (nor will I) but just my luck. <oriansj>also if you care about your eyes and pixels why 6x12? 8x14 is better <nckx>6x12 is fine on my X230 and my eyes are young and strong. <nckx>*X230T (it matters, sliightly smoller screen) <oriansj>nckx: hey, I am not 40 yet... I'm still young and hot... vroom vroom <nckx>I use 6x12 on the console too (a bitmap font I made as a teen because teens are bored a lot) and I like it. <nckx>oriansj: ‘I'm not 40 yet’ is indeed what all the young people say, well done. <nckx>No ‘fellow kids’ vibes whatsoever :) <oriansj>although my wife argues I was born 80 years old and just got worse with age <nckx>Oh dear. Our respective partners might find instant kinship on that particular subject. <nckx>Meanwhile, #bootstrappable is discussing whether /dev/null can't just be a normal file? I love that place. <nckx>oriansj: You had me at ‘deranged’ ♥ <oriansj>me too; everyone there is amazing and insightful <lechner>Hi, is it possible that i add a new (home-page) to an inherited package definition that was previously built, and guix package -f says "nothing to be done"? <nckx>Yep. Home pages and other metadata like descriptions and licences don't affect the package, and hence aren't included in the hash. <vagrantc>that reminds me that i haven't gotten it together to organize the "guix lint" party and/or hackathon <vagrantc>really want to do that before the release, which was planned for what? last September? November? January? <nckx>grep -ri 'this packages' && echo wait <nckx>…wow there are new ones. <vagrantc>admittedly, after fixing ~140 typos, it hurts a little to see more land sometimes ***taiju` is now known as taiju
<lechner>can i force a rebuild? i forgot the has and need the build log <nckx>You don't need to rebuild for that. guix build --log-file <nckx>If you built it locally it should not download a different log. <nckx>Anyway, you can force a rebuild with --check. <nckx>It's just wasteful in normal situations for this. <lechner>--check just rebuilds the official version. meanwhile, guix package -f guile-xcb-jep90.scm says nothing to be done (and shows no hash( <nckx>There is no ‘official version’ but I get what you mean. This is probably due to how Guix handles security updates, through a process called grafts. Try adding --no-grafts too. <nckx>Something's off here. Maybe I didn't get what you meant after all. What do you mean by ‘official version’? <nckx>I thought you meant substitute, from ci.guix.gnu.org *nckx pushes… and forgot the ‘this packages’ of all things. <nckx>And what do you mean by ‘it rebuilds the official version’? <nckx>What's ‘it’ *and* what's ‘the official version’? <lechner>Guile fan and Guix user jpe90 fixed it in their own repo <lechner>i would like to bring his code into Guix after experimenting <nckx>Sure, and that's what you've packaged in those 2 files. I'm with you so far. <nckx>Which command you are running to build them and what that command outputs to make you say an ‘official version’ is being built. <nckx>I ran guix build -f on both and wm failed as expected, and xcb is still building. <lechner>the xcb commit db7d5a3 belongs to mwitmer. that's what we ship currently <nckx>The xcb build looks frankly frozen. <nckx>And it's building guile-xcb commit dd9a6ac and guile-wm commit 91a29f2. <lechner>yes, but i have several builds of the former in my store. does yours ship (xcb event-loop) ? <lechner>but it's suppoed to go into 3.0, except -wm does not find it <nckx>I'll let you know when it finishes. But the file you pasted to <https://paste.debian.net/1242048> results in /gnu/store/spd4qvagh2fy4mjjizbv2q55scci4s78-guile-xcb-1.3-1.dd9a6ac. The others aren't relevant to it. <nckx>guile-wm-jep90 can't see guile-xcb-jep90 <lechner>okay, thanks! that looks good, locally too. why can -wm not find it, please? <nckx>They are in two different files, and your code for guile-wm-jep90 doesn't even mention guile-xcb-jep90. <nckx>Think of it this way: *how* can guile-wm-jep90 find guile-xcb-jep90? <lechner>/gnu/store/spd4qvagh2fy4mjjizbv2q55scci4s78-guile-xcb-1.3-1.dd9a6ac <nckx>Anyway, you need to paste guile-xcb-jep90 into the same file as guile-wm-jep90, *and* replace the original "guile-wm" input with your guile-xcb-jep90. <nckx>lechner: Yes, no jep90, but I don't understand what you mean by that. <nckx>What would the absence or presence of -jep90 change? I don't see it. <lechner>it did not find it because my guile-xcb did not refer to my version <lechner>i'm new to functional package management <nckx>Not because of the name. You could call xcb ‘guile-beefcake’, plug it into wm, and it would work. You could call it ‘guile-xcb’, *not* plug it into wm, and wm will never be able to see it. The name doesn't matter. <lechner>replacing all the occurrences in the parent definition is cumbersome. is there another way? <nckx>(assoc-ref inputs "foo") means ‘give me the input labelled foo’. You're already replacing said input with modify-inputs. So it will refer to your fork. <nckx>I didn't run it, of course. <lechner>nckx: thahks so much! i can't wait to try <nckx>I hope it works out of the box, and otherwise, well, you're much closer :) <nckx>Yes, good night! And good luck! <FlaminWalrus>Anyone have a reference home config with some Shepherd services in it? <nckx>lechner: You'll have to manually patch it with something like (add-after 'unpack 'patch-shebang (lambda* (#:key inputs #:allow-other-keys) (substitute* "guile-wm" (("/usr/bin/guile3") (search-input-file inputs "bin/guile"))))) <nckx>Why? Because the default patch-shebangs phase that magically runs for you can only replace shebangs that are in $PATH, and there is no package with a ‘guile3’ binary anywhere in Guix (guile@3 is still just ‘guile’). ***taiju_ is now known as taiju
<pashencija[m]>Could you please check `guix build gcc --target=aarch64-linux-gnu` on your machines? <nckx>pashencija[m]: As you probably expected, it failed with error: ‘__LIBGCC_DF_MAX__’ undeclared (first use in this function) <FlaminWalrus>pashencija[m]: Failed for me too. Sounds like for entirely different reasons; if you want a 120k line build log of which 2.3k match the regexp "error," lmk. <pashencija[m]><pashencija[m]> "I'm trying to build it on aarch6..." <- Yes, it works <pashencija[m]>Found out Raspberry cannot boot with fat16 partition. Gotta implement fat32 support in Image API. I guess it won't be hard <cbaines>pashencija[m], are you sure you want gcc specifically, rather than gcc-toolchain? <cbaines>also, gcc@11 has substitutes for aarch64-linux <jpoiret>in any case, as nckx would remind you, gcc == gcc-toolchain now <civodul>jpoiret: i forgot the conclusion about the string= wrong-type-arg error in (gnu packages linux) <jpoiret>yes, since i586-gnu is in %cuirass-supported-systems, build-aux/cuirass/evaluate.scm tried to ask for the cuirass job that builds all packages <jpoiret>but linux won't work since it's not a supported linux target (has no linux-architecture, hence the #f instead of string issue) <civodul>looking at (gnu ci), linux is not part of %core-packages though <civodul>yarl: not yet sorry, please be patient <jpoiret>yes but if i understand correctly, evaluate.scm tries to queue the 'all task <civodul>ah, but then linux-libre should be marked as "not supported" no? <jpoiret>no because it can't even produce the package def <jpoiret>make-linux-libre errors before producing the package record <civodul>reproduced with "./pre-inst-env guix build linux-libre -s i586-gnu -n" <jpoiret>yeah, because it tries to access platform-linux-architecture inside make-linux-libre <yarl>civodul ok ok alright. I would just like to highlight that I changed (or ("-h") ("--help")) to (or ("-h") ("--help") ()). I hope that's not a problem. <civodul>jpoiret: that's ok, it's called lazily (the input fields are thunked) <civodul>there's already a supported-systems field though hmm <jpoiret>the input field seems to be accessed in package-transitive-supported-systems <jpoiret>`(supported-package? linux-libre "i586-gnu")` reproduces the error again <civodul>we can fix this by checking whether platform-linux-architecture returns #f <jpoiret>i'm fiddling with open-bidirectional-pipe <jpoiret>since i've already touched the guile internals of open-pipe* and friends <Ashy>does anyone have an example config.scm that uses unattended-upgrade-service-type? <Ashy>i can't quite figure out how to specify schedule from the manual page <civodul>jpoiret: does it work if you do "guix build guix --with-patch=guile@3.0.8=./foo.patch"? <jpoiret>oh, should i just `guix shell -D guix --with-patch=guile@3.0.8=nn.patch`? <Ashy>ah i was just missing the import <jpoiret>i'll likely need a reconfigure though :( <civodul>ah yes, "guix shell -D guix" is a good idea if you need to hack interactively on Guix itself <jpoiret>otherwise it'll be still using the previous one with ./pie no? <jpoiret>damn, now that i'm thinking about it, piped-process isn't even thread-safe if we use it with bidirectional sockets :( <jpoiret>i'll patch some of them up and see how it fares <jpoiret>i don't think we'll need posix_spawn bindings though *civodul reconfigures berlin <civodul>yeah if we have something like piped-process in libguile, then we don't need posix_spawn <civodul>they're similar, seen from the application viewpoint <yarl>a quick look too if you have the time. I successfully compiled distcc using this. Its check phase creates zombies and assumes the init process reaps them. <jpoiret>yarl: won't runChild just execve the builder and be done with it? <jpoiret>i don't think it does from a cursory glance <jpoiret>you'd need to fork once again inside the PID namespace <yarl>startProcess forks. sorry, read to fast <yarl>jpoiret, let me explain, maybe more for me than for you: <jpoiret>i'll be afk for a bit but i'll read it later so dw if i don't reply right away <yarl>jpoiret ok. I didn't get what you told me above, sorry... <yarl>Yes there is a fork(clone) that sets up the namespaces in ... <yarl>Before my patch this runs childEntry that does sets up the environment then exec. <yarl>After my patch this runs reaperEntry that forks (via startProcess, I would rather use plain and simple fork, I would rather a daemon in C (a guile daemon is planned?), not C++, that's just me.) Parent is the reaper (pid 1), child sets up the environment then exec. <yarl>So when you hit childEntry (reaperEntry), you are already in the pid namespace, due to clone(). <yarl>guix-daemon <- guix-daemon (fork per connection) <- builder <- etc <yarl>guix-daemon <- guix-daemon (fork per connection) <- guix-daemon (reaper) <- builder <- etc <yarl>where guix-daemon (reaper) is pid 1 <yarl>I probably forgot to think of some things, like closing file descriptors. <yarl>And probably some other interesting things can be done, like giving up capabilities (for linux) <lilyp>IOW double fork to start a job? <yarl>lilyp that is not optimal... but it has the advantage of being clear and coherent. <yarl>Wait a minute, I'm not gonne propose this as is. <yarl>I'm just discovering the sources and trying things. ***taiju is now known as Guest6181
***taiju` is now known as taiju
<lechner>nckx: thanks! maybe one day i'll understand all the quoting, too <lilyp>for the record, modern sources should use #~ and #$ inside a package's arguments ***taiju_ is now known as taiju
<civodul>damnit i'm again locked out of berlin wtf <cbaines>civodul, I can SSH in, how far are you getting? <civodul>cbaines:ludo@berlin.guix.gnu.org: Permission denied (publickey). <civodul>could it be that i'm using too old an SSH key? <civodul>like an algorithm that's no longer supported <civodul>i find it hard to believe because the upgrade didn't upgrade openssh AFAIK <civodul>cbaines: any clues in /var/log/messages or /var/log/secure? <cbaines>just things like: Connection closed by authenticating user ludo [IP ADDRESS] port 57320 [preauth] <cbaines>civodul, do you get any more information about where it's failing if you use ssh -vvv ? <nalaginrut>The current guile-dbi is for guile2, how can I build it for guile3? <cbaines>nalaginrut, the package definition specifies guile-2.2 as a propagated-input, changing that to a guile 3 package looks to be the main change <nalaginrut>so it has to be released from the upstream, right? <tricon>nalaginrut: i am presently utilizing guile-dbi in a project. iirc, it doesn't build with a meager change from guile-2.2 to guile. i think it needs further repackaging. haven't had time to update it and submit a patch. <tricon>nalaginrut: you could copy the package definition and modify accordingly. <tricon>fwiw, i ended up just making a profile for guile-dbi to run against guile-2.2 and its deps. <nalaginrut>is it possible to make a local file and overload the guile-xyz.scm ? <civodul>cbaines: my authorized key in maintenance.git is an RSA one; could you check whether those are rejected? <cbaines>civodul, I think the key I'm using is an RSA one <tricon>nalaginrut: not certain of that, but you could copy the desired package def and change the package name and var: guile3-dbi, for example. <tricon>then: guile package -L ~/path/to/local/packages -i guile3-dbi <cbaines>civodul, could be something about key length, as I'm not sure the one I've got in maintenance.git works <cbaines>but I've got a longer one in my users ~/.ssh/authorized_keys <civodul>cbaines: {cbaines,ludo}.pub in maintenance.git have the same size though <cbaines>civodul, indeed, and I think that key doesn't work <nalaginrut>tricon: do I have to modify the system file? It's better if it can be specified as an option, or build with a local guix.scm file <cbaines>civodul, have you got a longer key I can add? <tricon>nalaginrut: no, don't modify the system file. <tricon>nalaginrut: -L lets you specify a custom path to additional package definitions. <tricon>nalaginrut: for example, mine is: guix package -L ~/dev/guix/packages <nalaginrut>one more question, can it be set to a default load path <cbaines>civodul, the key I'm using is 3072 bits <civodul>cbaines: how can you check that actually? <cbaines>I was using this command: ssh-keygen -l -f .ssh/id_rsa.pub <tricon>nalaginrut: the load path can be amended via the env var: GUIX_PACKAGE_PATH <nalaginrut>I copied an store the definition to a file guix.scm, and put it to the local path. It seems guix doesn't recognize it. So how can I specify a definition file? <tricon>nalaginrut: with -f, the file must end with a package definition. <civodul>cbaines: got it: check /etc/ssh/authorized_keys.d/ on berlin <cbaines>right... at least the issue is less mysterious now <civodul>the culprit would be 1f29ed4a812f86c45e2d9c37fd9f80f6d0418293 <civodul>commit 1f29ed4a812f86c45e2d9c37fd9f80f6d0418293 kinda makes sense <civodul>yet, that extension mechanism did work before <civodul>we've been using it in (sysadmin people) since 2017 <pashencija[m]><jpoiret> "if so, you'll want gcc-toolchain" <- It also fails to build <djeis>Didn't they disable rsa keys for ssh at some point? Or was that only some rsa keys? <lilyp>RSA keys are in a weird state ever since the openssl 8.3 update IIRC <djeis>yea, release 8.8 Potentially incompatible changes: This release disables RSA signatures using the SHA-1 hash algorithm by default. <djeis>Oh but... "OpenSSH has supported RFC8332 RSA/SHA-256/512 signatures since release 7.2 and existing ssh-rsa keys will automatically use the stronger algorithm where possible." <lilyp>does anyone know how to compile C++ code with our mingw packages? <jpoiret>pashencija[m]: yeah, i remembered later that gcc and gcc-toolchain are now the same on the command line <jpoiret>sneek, later tell yarl: Looks good! I totally missed the startProcess, that's what i was talking about <efraim>in other news, I now have keepassxc working with qutebrowser <nckx>If have both id_rsa and id_ed25519 and couldn't SSH into berlin. But if I simply remove id_rsa, I can. Strange order of preference SSH has. <civodul>nckx: the bug had nothing to do with RSA after all <nckx>As in somebody reconfigured just while I was deleting the RSA key? <nckx>Because my RSA key isn't authorised on berlin, it would be strange for it to ‘block’ ed25519 as it did. <nckx>Anyway, it was trash, now it's gone, I regret nothing. <nckx>I'm just saying what I observed. <nckx>The system was reconfigured at 16:49. It's quite possible it did slip perfectly between my two attempts :) Neat. <nckx>civodul: Thanks for the link. <jpoiret>civodul: any idea what i should be seeing with a successful `make cuirass-jobs`? <jpoiret>the replacement open-bidirectional-pipe i hacked up seems to be working well, no warnings/stuck processes for now <nckx>lechner: Here's a question. Which time zone do you use? <jpoiret>actually it just finished, although i only saw output for x86_64-linux <jpoiret>after some investigation, cuirass-jobs/jobs-xxxxx are all filled with jobs, so it seems it worked perfectly well, let me retry a couple times <jpoiret>(previously it always ended up hanging on my laptop) <nckx>> seems it worked perfectly well <nckx>yes that is very suspicious. <jpoiret>i must say i'm using a patched up guile with a different open-bidir-pipe though <jpoiret>ie 0 guile-side fork and fd shenanigans <civodul>jpoiret: "make cuirass-jobs" should create a 'cuirass-jobs' directory with a bunch of files in there <civodul>jackhill: thanks for the heads-up, i hadn't noticed <jpoiret>is there something i could do to put it through more tests? <pashencija[m]>Do I need to file a bug report about gcc not building for arm? <GNUverkty[m]>hi! is there any example of patching a hard coded INSTALL_DIR? <nckx>pashencija[m]: Yes please. But you said you got a different error than I did (IIRC)? <nckx>That was FlamingWalrus, but they didn't say what. <nckx>So you mean ‘should I file a bug report for GCC not cross-compiling for arm, even though I haven't cross compiled it myself’? <nckx>Erm, I guess, if you want. <nckx>I'll start anoter xbuild & furnish logs. <nckx>GNUverkty[m]: Something like (substitute* "Makefile" (("^(INSTALL_DIR = ).*" _ assign) (string-append assign #$output))) <pashencija[m]>If I want to add FAT32 partition support to Image api, should I file an issue first and then send patches? Or should I write and send patches without filing a bug? <nckx>GNUverkty[m]: …or (substitute* "Makefile" (("/usr/evil/no") #$output)) really, I guess, no need to overthink it that much. <nalaginrut>tricon: I just copied (define-public guile3-dbi ...), but it seems not work <nckx>pashencija[m]: For context, both ‘bugs’ and ‘patches’ end up in exactly the same place (both at debbugs.gnu.org and issues.guix.gnu.org) and share the same # namespace. The only miniscule difference is that sending something to -patches marks it as having a patch attached. <nckx>Filing 2 wouldn't make sense here. <pashencija[m]>nckx: The patch is not related to the problems We discussed here. It's just a new entry in gitignore <pashencija[m]>But I almost finished my fat32 patch. I still want to do more tests <vivien>I don’t have enough gigabytes on my /gnu/store partition to compile chromium :( <nckx>pashencija[m]: Hah. That is very much potential controversy to fit into a one-line patch. :) Fine by me, but are you really hacking on Guix on a Macintosh? <pashencija[m]>It would take more time to offload these to raspberry as its perfomance is much worse <jpoiret>are those your first mails? it might be stuck in moderation <nckx>No queued messages to bug-guix or guix-patches. <nckx>Might be queued elsewhere, let's wait for now. <sneek>yarl, jpoiret says: Looks good! I totally missed the startProcess, that's what i was talking about <pashencija[m]><jpoiret> "are those your first mails..." <- Not first. Sender is "p.shlyak@pantherx.org" <nckx>pashencija[m]: Where did you send it to? <peterpolidoro>hi, I am trying to trying to write a guix package for a pypi package and it is unable to find the tests. I tried replacing check with (invoke "python" "-m" "unittest" "discover") but it is still unable to find the tests. when I run "python -m unittest discover" in a python virtual environment rather than in guix then it finds and runs the tests as <nckx>pashencija[m]: OK. You probably wouldn't be the first to type guix-bug after typing guix-patches. There's nothing I can do for you for now. You're not being moderated, so if it ever arrives, it will be instantly approved. <nckx>peterpolidoro: And you're sure you're using the exact same sources (i.e., not guix building from PyPI and manually testing with a GitHub checkout, say)? <peterpolidoro>oh you are right I am doing that. I am building from pypi and testing with the github checkout. Maybe the tests are not being included in the pypi download? <pashencija[m]>OK. So either the message arrives or someone else submits a bug about GCC or I try it again tomorrow <nckx>peterpolidoro: It happens unfortunately frequently (and I feel like increasingly) that they are not ☹ <nckx>pashencija[m]: Sounds good. Sorry, I wish there was something more I could do. <nckx>We don't have access to the gnu.org mail servers proper. <nckx>peterpolidoro: Look at the output of ‘guix build --source <your package or -f scm>’, it's exactly what Guix will use. <nckx>If the tests are missing, you'll have to use git-fetch from the development repository. <peterpolidoro>oh I think you are right, thank you! I will change it from a pypi pull to a git-fetch and see if that fixes it <florhizome[m]>emacs–List–utils is failing to build, stopping my upgrade process. It’s somewhere as a dependency <KarlJoad>I don't think I've ever heard an answer about this. I have asked, but I probably missed the answer. Does it make sense to put system definitions in a channel? <nckx>KarlJoad: I think so. It's a workflow that might not be for everyone but it works great. <KarlJoad>Some of my personal packages are already in a channel. Moving the systems to the channel would just involve merging 2 git repos. <KarlJoad>Building my desktop before trying to reconfigure on another machine would be great, especially because I have to compile quite a few programs myself. <nckx>That's why I channelised all mine. My substitute server builds all my operating-systems automatically. It's great. <nckx>It's a bit more work than emacs system.scm && C-s && guix system reconfigure but it's a discipline you get used to. <florhizome[m]>> emacs–List–utils is failing to build, stopping my upgrade process. It’s somewhere as a dependency <florhizome[m]>It’s an indirect dependency of emacs–helpful. Could someone do it? <florhizome[m]>kiasoc5: I left the arguments path, it seems like there is some notion of cl in it because I got a warning… <attila_lendvai>what's the idiom to use if i want nested file-append's? #$(file-append curl (string-append "/bin/curl --foo=" nss-certs ...) *attila_lendvai seems to have found the proper nesting of unquote, file-append, and string-append <KarlJoad>nckx: I will have to get substitutes figured out, but the building itself should be easy enough to get my Cuirass server to do. <kiasoc5>florhizome[m]: i also got stuck with the upgrade, for me the only thing that was blocked by emacs-list-utils was emacs-helpful <kiasoc5>so i just removed emacs-helpful from my profile for now *nckx pushed the emacs-list-utils patch. <attila_lendvai>is this only me? i'm seeing: ntfs-3g[26473]: Could not load plugin /gnu/store/r1avamwgm5v39f4n717ip4cdn3rfvfjr-ntfs-3g-2021.8.22/lib/ntfs-3g/ntfs-plugin-8000001b.so (the file is not there). my toplevel issue is that ntfs partition is mounted read-only. <nckx>Thanks to Erik, whoever they are here (if at all). <nckx>attila_lendvai: Hmm! I'll try to reproduce it in a few minutes. <unmatched-paren>florhizome[m]: you mean (inputs (list pkg1 pkg2 ...)) or something different? <unmatched-paren>afaik (arguments (list #:foo #~bar #:baz #~quux)) is now encouraged too? *attila_lendvai gives up once again and reboots to print a file... <florhizome[m]>just some idea btw but I think it would be nice to … declutter arguments <florhizome[m]>there are so many things performed in this field that have very different purposes. <jackhill>florhizome[m]: I was just wondering that too why some things were done in top level fields and others were pushed down into arguments. <jackhill>I suspect there's some history here, but don't really know <nckx>Because they are different. <nckx>sneek: later ask attilla_lendvai: I don't use ntfs… Will it ‘work’ if I install it as a regular user? <jackhill>well, obviously :) but what's the significance of the difference? What should I be learning from it? <nckx>sneek: later ask attilla_lendvai: Also, isn't ntfs-3g, if not deprecated, the old way of doing things at this point? <akonai>Is there a way to add a package to the %load-path of a program-file gexp? Neither #:module-path nor actually setting the %load-path in the gexp seem to work <unmatched-paren>the list of arguments is spliced into the build system's procedure argument list <jackhill>unmatched-paren: a ha! the insight I was missing, thanks! <nckx>unmatched-paren spits the truth. <jackhill>maybe it's time for me to dive back into understanding build systems. The last time I looked, it all looked like fog to me, but I bet if I do it again, I'll be able to make out some feature :) Thanks unmatched-paren nckx and #guix! <nckx>Which keys are ‘valid’ at all is fully defined by the build system, pushing them into <package> record fields is very unnatural, although I completely understand why you suggested it. <florhizome[m]>I would really like to have make composing build systems more convenient for example. Instead of having it in arguments, it would make sense to me to move it into build–system <florhizome[m]>so you could either use a standard build system or use a procedure to compose one from existing ones… <nckx>Yeah, multi-build-system packages — while possible and cool — are a big step up in difficulty for new users. It would be nice to streamline that. <unmatched-paren>florhizome[m]: so something like (build-system foo-build-system #:foo bar #:baz quux)? seems doable <unmatched-paren>or perhaps (build-system (compose-build-systems foo-build-system bar-build-system) ...) <unmatched-paren>florhizome[m]: the only issue could be that stages from foo-build-system and bar-build-system would collide. it would probably require a complete rework of how guix builds work <florhizome[m]>Yeah this might more of a midterm/longterm thing, but better I mention it before 2.0 I guess <nckx>sneek: later tell attila_lendvai: Of course I can't reproduce it… That's with guix install ntfs-3g and a 1-GiB mkfs.ntfs'd image in /tmp. <civodul>it was fixed in less than 24h i think, but that's enough to be unlucky <nckx>guix news won't work here? <jpoiret>just sent my own patch for open-bidirectional-pipe, hope it can help <vagrantc>hrm. when adding new packages to guix ... i always want to do something crazy like ... alphabetically insert it ... only to realize there's no such habit in general and it seems things always get appended to the end? <nckx>civodul: I mean, I'll gladly write up a short message, I'm just not very optimistic that guix-announce@ or so will reach a meaningful number of users. It'll probably reach more ‘Linux blogs’ than users :) Unless you have a better idea. <nckx>vagrantc: No, that's great. Appending to the end is discouraged. <pashencija[m]>I didn't implement it because I want to say "I sent 100500 patches to guix" meaning one-liners with new file systems😅 <nckx>vagrantc: Even adding it to a random spot in the middle (not a fan) is better than appending. <nckx>Strictly ‘better’ in preventing merge pointless conflicts. <vagrantc>if you always append at the end, it maximizes changes for conflicts <vagrantc>gnu/packages/networking.scm seems to be without pattern <vagrantc>i guess i could pick one thing to put it before or after, and at least have two packages in some kind of order :) <nckx>vagrantc: Most, unfortunately, and nobody cares about ordering. I just add it before the first package that would come after it alphabetically. If that makes sense. <vagrantc>nckx: we seem to have basically arrived at the same conclusion <civodul>nckx: precisely, i don't have a good idea :-/ <florhizome[m]>sometimes packages consist of a couple repository’s cloned into each other <nckx>The only mechanism I can think of (and I'm not advocating for this) is making ‘guix’ check a URL each time it's run where we could put a flag to say users should pull. <lilyp>We need a "sort packages alphabetically" rule for guix style <nckx>Each time I advocate for sorting I get ignored (sure, fine) or hear people glancing at me over e-mail as a weirdo 😛 <vagrantc>florhizome[m]: maybe treat each source repository as a package, add them as inputs? *vagrantc cheers on nckx's urge to sort things! <lilyp>well, truth be told, sorting only applies to ~80% of our package files at most <jackhill>vagrantc, florhizome[m] that's what we seem to have done with nginx modules <lilyp>there's sometimes good reasons not to sort <lilyp>but that doesn't mean that breaking order for no reason is okay <nckx>OK, more people seem to agree than I thought over the years. <civodul>nckx: so you not only hear people over email, but you hear them glancing at you? :-) <nckx>I have special probl—er, powers. <civodul>lilyp: a "guix style" rule for that sounds like a good idea <pashencija[m]>Just let me know when I should stop putting shit on the fan with my macos emails🤪 <lilyp>Well, Tobias is not alone. I can smell them shouting. <pashencija[m]>So, theoretically, one can port and get libre guix on top of macos internals <lilyp>does that have the awful .DS_Store "feature"? <nckx>See. See! I called it. Here we go. Strap in. <nckx>The one-line patch with the 100-line discussion. <pashencija[m]>I just don't see any reason why one line in gitignore would hurt someone <nckx>Well, you wouldn't upstream your potato folder… <nckx>(Are they pictures? Videos? Recipes? Anyway.) <philip>For `guix system vm`, what is the best way to share, say, "/dev/sda"? Not a file system, but the device, so that the VM can mount the file system on it. <pashencija[m]>lilyp: I am not sure, but I supposed these files are created by finder (file manager) once someone opens the directory <philip>lilyp: The .DS_Store is for the default file browser, not the OS: it stores per-directory layout state and such. <nckx>FTR, I'm not against the patch at all. I don't have a clear answer to how far we should go to ‘support’/convenience use of proprietary software. <florhizome[m]>pashencija[m]: I have seen some efforts to make Linux and android oses run on ios, too <singpolyma>lilyp: what would be a reason sorting a file might not work? <lilyp>singpolyma: in java, poms are weird <lilyp>but there's also some small files like wine.scm, where it doesn't make thematic sense <singpolyma>lilyp: oh, if there's "subsections" in the file thematically I could see that <lilyp>meanwhile in all-your-crates-are-belong-to-rust.scm, sorting should apply <lilyp>I don't get it either, but long story short don't anger the beans. <attila_lendvai>nckx, AFAI followed the story, ntfs-3g is the *new* thing. and again, it seems to happen based on fs content (see debian bug)... hence i have abandoned the pursuit of a fix. <sneek>Welcome back attila_lendvai, you have 3 messages! <sneek>attila_lendvai, nckx says: I don't use ntfs… Will it ‘work’ if I install it as a regular user? <sneek>attila_lendvai, nckx says: Also, isn't ntfs-3g, if not deprecated, the old way of doing things at this point? <sneek>attila_lendvai, nckx says: Of course I can't reproduce it… That's with guix install ntfs-3g and a 1-GiB mkfs.ntfs'd image in /tmp. <lilyp>singpolyma: It'd probably be a Guile bug if at all <nckx>attila_lendvai: The ntfs3 ‘normal’ kernel driver is the new thing. The user-space (FUSE) ntfs-3g is the old thing. <nckx>The ‘3’ in both doesn't help the confusion. <attila_lendvai>nckx, then i'm behind. gnome's files app in guix HEAD mounts stuff using ntfs-3g. <lilyp>yeah, ntfs-3g has worked for ages <nckx>I'm sure ntfs-3g will work for years to come (and might support a bit more—for now). I didn't know you were going through GNOME. <singpolyma>lilyp: maybe. Bug somewhere if re-ordering defines breaks something <nckx>I thought you were manually ‘mount’ing in which case -t ntfs3 is a small change. <lilyp>thing is everything in guix is syntax so you can't really reorder things willy-nilly. <lilyp>particularly with inheritance, which isn't thunked <lilyp>pashencija[m]: I don't think you'll run the proprietary mac file manager on your pure GNU Darwin system, do you? <pashencija[m]>The idea is to develop arm guix in a VM writing code outside of VM. That's what I find convenient now, but it can be even better with that gitignore <lilyp>The gitignore still applies if you don't push it upstream, though <lilyp>plus, you probably want to globally ignore DS_Store if you're coding on a mac <lilyp>not sure what the mac equivalent to $XDG_CONFIG_HOME is, but there should be a way to "globally" gitignore .DS_Store on your machine <nckx>A Macintosh hidden file thing. <lilyp>unmatched-paren: a pointless file Apple keeps around to tell everyone you're a Mac user <nckx>Similar to .thumbs or whatever it's called in some DEs. <lilyp>Hidden files were a mistake. <unmatched-paren>".DS_Store is a file that stores custom attributes of its containing folder, such as folder view options, icon positions, and other visual information" <- yep, sounds pointless to me. typical smack. <pashencija[m]>lilyp: Wait, how else should I hide my potatoes from special services and shadow government? <cocomeat4[m]>unmatched-paren: aka stuff that should be in a system config dir and not in the dir itself <nckx>lilyp: Literally, or at least an accidental ‘feature’. <lilyp>put them through onion routing, that will tell them! <jonsger[m]>nckx "serious" question do you boykott NTP or why are your commit times always a few days in the past? <vagrantc>guix style hurts me with merging short lists onto a single line. think of the poor diffs. <lilyp>yeah, the formatter is still quite poor compared to emacs <nckx>jonsger[m]: exec faketime -m -f "@$(date --date='last Sunday UTC' +'%Y-%m-%d %H:%M:%S')" git "$@" <vagrantc>i think i met my grumbling quota for the day, back to working on things... <nckx>(The ‘last Friday’ thing was a cool new discovery at the time.) <nckx>vagrantc: I'll take over, I got you. <nckx>Someone say something nice about Rust. <lilyp>I can't wait for dxvk to be ported to rust. That'll make it easier to package :) <unmatched-paren>and uhh it's somehow had far fewer supply-chain attacks than it should have had by now <nckx>Hehe. I don't actually disagree about the language. ‘Rust the MoDeRn eCoSyStEm’ I meant. <unmatched-paren>ok, i'll just make something up... I love how Rust makes adding dependencies to your projects SOOO easy!!11!!11!1 <nckx>This is amusing me more than it is grumping. <lilyp>but in the end you still get called back in the black hole that's serde_json <lilyp>I just installed a package with npm and only got three copies of it. <unmatched-paren>and -cultists- people there had said that NPM was the best package manager <lilyp>Well, it's also the best vector for supply chain attacks <singpolyma>It's not my favourite but there are many worse ones <lilyp>which also explains why Rust has had so little until now <lilyp>the rest were all eliminated by the borrow checker <unmatched-paren>Hare is considering adding a borrow checker Maybe Possibly It Depends, so maybe that will give us a decent memory-safe systems language <lilyp>and because people outside of tech know that javascript is that scary thing that all web pages tell them to enable <singpolyma>lilyp: no one outside of tech has ever been told to enable JavaScript. They all have it enabled already <lilyp>And this... is to go... even further beyond! <unmatched-paren>because it was just too obvious to everyone that Mozilla, Apple, and Microsoft would never follow <singpolyma>Microsoft doesn't count anymore they just ship chrome. And Mozilla always folds <singpolyma>And honestly AAPL users are used to installing chrome. So it's just iOS users <singpolyma>unmatched-paren: they could just extend v8 to read the dart syntax <unmatched-paren>singpolyma: annoying as Apple is, their monopoly on iOS browsers may be saving the web :P as far as you can save such a failed experiment 