IRC channel logs
2023-07-16.log
back to list of logs
<nckx>Rovanion: Should be fixed, by the way. <Guest54>cow-store, service unknown. Ist IT only available in os Install Image? <Guest54>Can i build that top be available for arm? <nckx>All it does is ensure that you won't run out of space on / . If you can do so some other way, or if / isn't in RAM, you don't need it. <nckx>(I don't remember if it's only for /gnu or also /tmp etc., but that's the gist.) <nckx>For example, in my SystemRescueCD earlier, I had to mount -o remount,size=8G /something/something/cowspace after enabling swap. Same effect. <Guest28>I aws Guest54 but on my phone. Yea I basically want to boot Guix from USB and install the system directly with BTRFS. <nckx>So many guests, so little tea. <nckx>ACTION AFK. Good luck though. <Rovanion>gimp-resynthesizer is written using Python 2. Python 2 was removed from package gimp in 8d71e5b2a5b5f5e6ca49e10a65384c298437b401. Development to move resynthesizer to Python 3 is done in coordination with the move to Gimp 3/2.99. Anyone happen to have a recipie for Gimp 3 lying around? <Guest28>Ah I remember. My issue is probably that the installed Guix version is always some version behind the version that created the image. <viaken>How do I tell guix to build the Foo package in bar.scm? I want to do more packaging, but I can't figure out the workflow. <viaken>If I'm reading this right, I'd do something like `guix build -L path/to/dir/containing/bar Foo`? <HiltonChain[m]><mirai> "Hilton Chain: "Honor tests? flag..." <- Thanks, I like this commit message as well. <raghavgururajan>sneek, later ask lilyp: Apart from webkitgtk, could you tell me 3 packages that needs upgrade? I'll try to work on that parallely. Apologies for being idle, the new job's been hectic. <lilyp>I'm not sure what of it doesn't require webkitgtk, but everything that goes into the gnome metapackage helps <sneek>Welcome back lilyp, you have 1 message! <sneek>lilyp, raghavgururajan says: Apart from webkitgtk, could you tell me 3 packages that needs upgrade? I'll try to work on that parallely. Apologies for being idle, the new job's been hectic. <jpoiret>viaken: if it's not in the guix checkout but in your own channel, yes, although you should use -L path/to/your/channel i think <Irvise_>nckx: hi! I sent the email regarding GCC-Ada/GNAT to the guix-devel ML. However, some time has passed and I have still not received it and it does not show in the archives. Maybe my email is being blocked (not the first time this has happened). Could you take a look? The email also had a few links, but they are from well-known websites plus my personal one... <tao[m]1>If we're moving to the matrix.org homeserver, isn't it possible to auto-migrate? I think Matrix allows you to tombstone and auto-point to the new location <ChocolettePalett>By the way, what if hypotetically I make a package and, for example, define its name to be "helloworld", but the package itself is defined as, for example, "hiuniverse", i.e. its name doesn't match its definition. Does it count as a bug? [sarcasm]How much bounty do I get for it?[/sarcasm] <nckx>Good morning. What has appservice done. <lilyp>if it's a big difference, then yeah, maybe, if it's stuff like "hi-tool" vs. "hi", I'm not so sure <nckx>ChocolettePalett: Naming is hard. Depends on the exact difference. <nckx>tao[m]1: AFAIK you can't (as) easily forward folks like you can do on IRC? <ChocolettePalett>I've tried to install the "make" package, but it's called "gnu-make" in the sources. <ChocolettePalett>It could be okay I guess _but_ both "guix search" and the package searching website made me think that its name is "make" <nckx>Irvise_: You were indeed stuck in moderation. It won't happen again. <nckx>Irvise_, pjals: What exactly happened? All I see is a mass quit of Matrix users, which, whilst annoying, is hardly a new thing. Was this time different? <nckx>raghavgururajan: Just about to leave, but I'll PM you later if that's all right. <patched[m]><nckx> "Good morning. What has appservi..." <- Kicked 120 accounts for inactivity <Irvise_>nckx: thanks. Regarding appservice, I have seen about 150 status messages of appservice kicking users who were idle for too long. <ChocolettePalett>Oh, it seems that I got confused about how guix package and guix home handle package installation, so a package name not matching its identifier isn't a bug actually... Knowledge has a beginning but no end indeed. <HiltonChain[m]>ChocolettePalette: (gnu packages) provides some procedures to find packages by the name filed. <HiltonChain[m]>Actually "guix package --install" uses the specification->package+output procedure defined in it. <jpoiret>janneke: the hanging pipe tests for guile should be fixed in latest master <jpoiret>i don't think we should be using 3.0.9 on Hurd since it's bound to cause problems <ChocolettePalett>It's a very useful feature, but it adds so much green to my config to the extent of not suiting my GNU/Emacs theme; also I've read that specifying names can help catching typos in "compile time" <jpoiret>yes, using symbols should be preferred :) <janneke>nice but...you want to specialize guile for the hurd? <jpoiret>i would rather avoid it :) but we'll run into some very troublesome problems if we don't <jpoiret>or convince guile maintainers to make a new release, but that's probably not the right time for it <janneke>how about just skipping those tests for now, and... <janneke>...adding hurd patches to guile on hurd-team <janneke>somewhere at the top, and wait for a good moment to merge hurd-team <jpoiret>ie. patch conditionally if the target is hurd <jpoiret>adding a phase that does the patching for us <jpoiret>i'll see if I can squash all the changes related to system* <janneke>i fear that introducing guile/hurd would be very painful <janneke>better to have this ugly patch hack, probably <jpoiret>ah, even easier, Ludo already added a patch for this earlier, but it doesn't contain all the fixes i think <jpoiret>just have to overwrite that one with one containing all of them <jpoiret>just need to cross-build a hurd image again, then i'll test this out <janneke>nice, apart from the guile rebuild ;) <jpoiret>arf, since it changes configure.ac we might need to use autoconf and friends <nckx>tao[m]1: Nope, not possible. We'll have to wait & see what EMS is planning for the :libera.chat rooms. Maybe they'll tombstone them, maybe they'll do something better. Possibly they'll do something worse. <nckx>ACTION passes 'round the rum. <nckx>‘guix build: error: executing SQLite query: database disk image is malformed’ Here we go again. Must be a bcachefs bug. But it's weird, I never get dmesg errors and fsck is happy. <jpoiret>I see Kent Overstreet is trying to get bcachefs merged! <jpoiret>I wanted to try it out when it's finally in the upstream tree but it seems it'll have to wait for a bit more testing :) <pjals>finally!! i've failed twice trying to patch linux-libre for bcachefs in guix <michel><nckx> "tao: Nope, not possible. We'..." <- Just noticed, thanks for whoever updated the topic on libera.chat <nckx>pjals: Where'd you get stuck? I've had a linux-libre-bcachefs almost-ready to submit for an embarrasingly long time, but (1) bcachefs keeps looking like it will be merged soon™ (2) I wouldn't actually use said package myself. <pjals>well, specifically, i was making a patch-any-linux-for-bcachefs-ifier, not just a linux-libre-bcachefs since i have 2 machines and one of them require a... let's say non-standard version of linux <nckx>michel: I've been taking care of that mess but it hasn't been easy. <pjals>and it's kinda hard to make a patch work for two differently-structured variants of linux <nckx>I see. I went the other way & ran the make-linux-libre on Kent's tree, which is indeed much easier. <nckx>But in practice I run a mongrel abomination that I maintain in git, with many—many—other patches, not through Guix, so there's less motivation to upstream a totally different package. <Irvise_>nckx: sorry to bother you again. But my email shows up in the archive but I have not received it in my inbox (I am subscribed to the ML, so I should receive a copy). Did you receive my email in your inbox once it was allowed? <nckx>You're not bothering, that's what I'm for. <nckx>And yes, you should, but I don't think this is something we can debug. <Irvise_>As long as other people got it, I am happy then :) Thanks ^^ <nckx>Irvise_: Did you receive a complete-looking rest of list traffic since you subscribed? <nckx>Or maybe your mail client is being just a bit too clever in deduplicating messages. <Irvise_>nckx: I have been receiving all (or at least most) of the ML yes :) <Irvise_>Could be, but that has not happen with other MLs such as NetBSD's <Guest28>If I install Guix via usb. I need to mount my root partition to /mnt and my vfat with esp flag partition to /mnt/boot/efi? <nckx>Irvise_: Let's chalk this one up to Internet gremlins eating your copy, but if it keeps happening don't hesitate to ping me. <Guest28>and afterwards I would need to place rpi4 uefi stuff to the root of the first partition? Since it does only boot to grub shell <nckx>That I can't say, since this sounds like something Pi-specific. <pjals>Guest28: Yup, and then you need to do herd start cow-store /mnt in /mnt. <pjals>It's probably one or the other but I'm too lazy to remember which one <pjals>And then, finally, copy your config or dotfiles to /mnt and do the guix system init! ;^) <Guest28>There is no cow-store, since I cant use an installation image <nckx>As long as you can enlarge whatever this live medium uses to back /, and have enough RAM & swap to back it, you'll be fine. <pjals>\<off-topic\> Why is Cat Disruptor 6000 in the Matrix room? <Guest28>because I now have my Guix installed with btrfs as the fs on my rpi 4, but it doesn't boot like it should. I am always in grub shell <nckx>pjals: That was there when I bought it, I swear. <pjals>ACTION goes through the membership events <nckx>I evilly conspired with matrix.org to hostilely take over the Matrix room, I don't know if this still counts as an original or a copy. <nckx>But the Disruptor was in the old one. I assume the original admin added it. I think it's cute, but if consensus is that it's annoying, we could boot it. <Guest28>do i need gpt or msdos partition table or doesn't it matter? I currently have msdos with 1 partition to be esp and 2 partition to be set as boot <nckx>Why do you have msdos? It is, at the very best, unconventional. <jpoiret>it's the name Grub gives it for some reason, maybe some other tools as well <jpoiret>right, I even learned there's still something called the MBR in GPT disks 🙄 <nckx>Anyway, ESP really implies GPT. That a lot of firmware might happen to boot from an msdos ‘ESP’ is nice, but not reliable. <nckx>jpoiret: The PMBR \o/ Which you can set to ‘bootable’ in parted just to completely confuse newbies. <jpoiret>not reliable, but mandatory per the EFI spec though <nckx>Have you seen what firmware vendors do to specs? It's not pretty. <nckx>But my ‘why’ above still stands. Unless you have a good reason to stick with msdos/mbr (buggy firmware? :), use GPT. <pjals>You should just put the EFI System GID and maybe the ESP flag and maybe even the label "EFI SYSTEM" on the vfat partition and it should all work <pjals>The label is probably not part of the standard, but it may help with quirky systems. :^) <nckx>I don't actually use parted myself, but the ‘esp’ ‘flag’ should be what you want. I quote ‘flag’ because it's not really a flag like it was in the msdos times, that's just the (IMO odd) way that parted exposes some GPT type UUIDs. <Guest28>it is just strange, if I use guix system image, there is a dir called EFI in the 1 partition, with guix system init it generates a lot more stuff and has a complete different structure <nckx>That means the first partition is the ESP. You should get a directory called EFI (or efi) on your new ESP (so /mnt/boot/efi/EFI) too. <Guest28>this grub efi arm chainlider pi 64 thing is hard to understand <pjals>Pretty sure that configuration is meant for use with SD cards in the RPI <Guest28>yeah, I install on sd card but boot from usb stick to have a btrfs system and not ext4 <Guest28>Someone using a Talos 2? I wonder how good they perform. Does GNU Guix work on POWER well? <oriansj>Guest28: well there is no PowerPC system image yet, only guix binaries which run on the Linux distro of your choice. <nckx>‘Get Guix System to work on powerpc64le-linux’ still needs to be done. <jpoiret>civodul: our guile-2.0 package did do the native-input trick you were talking about, but none of the ones inheriting from it. Also you probably need to run ./configure for it to work? <goober>I have an issue with ld within guix shell not finding the libs I feel it's supposed to: <goober>I do guix shell gcc-toolchain and from there I type 'ld -lrt --verbose' and it only seems to be searching some random binutils derivation <civodul>jpoiret: hey! guile-2.0 has "this-package" in 'native-inputs', so those that inherit from it have it too (and it resolves to the right package) <jpoiret>and manually adding the newer guile did end up working <civodul>however i was referring to other packages, like guix: guix could have (native-inputs (list this-package ...)) and i suspect that would speed things up <jpoiret>configure would say that guile-2.2 was found instead of 3.0 <jpoiret>yes, i'll be trying for guix as well! <civodul>oh you're right, it's not in (package-native-inputs guile-3.0) <jpoiret>wdyt of getting guile-3.0 to build using autotools in general? <civodul>look: (parameterize ((%current-target-system "i586-pc-gnu")) (package-native-inputs guile-3.0)) <civodul>long-term that's a good idea, short-term it's best avoided <civodul>because that'll unavoidably create bootstrapping issues <goober>even though $LIBRARY_PATH/librt.so.1 exists <jpoiret>civodul: we have automake and autoconf in commencement now <jpoiret>we can throw out manual generation for guile-final <civodul>well sure, but i'd say one thing at a time :-) <civodul>we have them already in 'master', no? <jpoiret>esp. adding the race-free posix_spawn_file_actions_addclosefrom_np <jpoiret>and I'm not parametrizing the whole guile package over %current-target-system <jpoiret>it's needed to get native building working on the hurd <civodul>can't we live with guile-hurd-posix-spawn.patch for now? <civodul>(apologies if i missed some earlier discussion!) <jpoiret>no, i don't think it's enough, the open-input-pipe tests are failing <jpoiret>janneke disabled them but i think it's going to bite us back if we don't fix it for good <goober>zamfofex, thanks that did the trick <jpoiret>civodul: probably that doesn't work once you try to modify the native-inputs <jpoiret>guile-3.0 doesn't add anything new but I did, that's probably where this-package goes wrong <civodul>jpoiret: re posix_spawn, so maybe we can augment glibc-hurd-posix-spawn.patch to match what we have in Guile 'main'? <civodul>i agree we'd rather get open-pipe* working :-) <civodul>re this-package, i'm not sure i follow what you write here :-) <jpoiret>well, currently there's no (native-inputs ...) field for guile-3.0, but I added one because I wanted autoconf and automake, so that might be the difference here <civodul>i'm confident you can avoid autoconf/automake <jpoiret>and regarding the patch, that's what I'm doing <jpoiret>well, we added a new configure check for posix_spawn_file_actions_addclosefrom_np in the patch series <jpoiret>right, I could remove that indirection from the patch <civodul>or you could patch the "for ac_func in" line in 'configure' to add it <civodul>the game is to find a one-liner that lets you do your thing without regenerating configure & co. <formbi>is it possible to delete phases from the pyproject-build-system? <jpoiret>i'll just remove the check "# define HAVE_ADDCLOSEFROM 1" <jpoiret>formbi: yes, you can use (modify-phases ... (delete 'phase)) <formbi>I'm trying to package python-copier (now I have this: http://ix.io/4AJL ) and it crashes on the check phase even though it shoulddn'e be used <janneke>ACTION tries to catch-up on the guile hurd'les ... phew! <Guest28>civodul: Did the guile-fiber solution work in the Github issue? <civodul>Guest28: in the interim, you could configure your device to use shepherd built against an older guile-fibers <Guest28>civodul: I don't need to the latest revision. Will update if it got fixed. <Guest28>I asked since I would have tested it on the pi as well <formbi>did I do something wrong with the phases or is it some kind of a bug? <zamfofex>formbi: It fails on the “check” phase of a dependency to me. <formbi>I often seem to forget to look properly xD <jpoiret>civodul: should `guix/build/po.scm` be compiled? <jpoiret>it's only used while building guix, right? <civodul>jpoiret: it doesn't *have* to be compiled, but it's also used by build-aux/convert-xref.scm, itself used when running "make" in Guix <jpoiret>yes, I'm making it build for $(build) and not $(host). <jpoiret>also, GUILE_LOAD_COMPILED_PATH is explicitely unset when building, for cross-compilation of the package this definitely should not be the case, but could we remove this from the makefile altogether? the warning above suggests that some people ran into issues without it <Rovanion>My time travel seems to be foiled by a failure to build a non-guix channel. How do I select only for the guix channel no be included? <jpoiret>we don't have a `--no-channel--file` option yet unfortunately <jpoiret>you can probably temporarily move your channels.scm file somewhere else <Rovanion>Attempted with a --channels=x.scm where x.scm contains only %default-channels. <Rovanion>Anyone knows where I get hold of atk-bridge? `guix time-machine --commit=faefd4d1db6ba84931e8201171555b004d0fc65c --channels=$HOME/.config/guix/default-channels.scm -- environment --ad-hoc gimp gimp-resynthesizer atk -- gimp` is what I'm trying. <Rovanion>Gtk-Message: 19:17:56.336: Failed to load module "atk-bridge" <jpoiret>probably you somehow need the girepository search path to pick it up <jpoiret>what if you add gobject-introspection to that shell line? <jpoiret>ah, that's an environment command, not shell! I don't remember the right flags, but can you specify --ad-hoc only once? <jpoiret>I thought it would've been one for each <jpoiret>is GI_TYPELIB_PATH set to somewhere that contains Atk-xxx.gir? <Rovanion>Not exactly. Inside the Guix shell it points to a /gnu/store item with Atk-1.0.typelib. <Rovanion>Nah! God damn! That was just a red herring. It was Gimp that checked if there was already _any_ instance of Gimp running, and then terminating on its own. <Rovanion>The Gtk message is just expected behaviour. <podiki[m]>how do I showed closed issues in guix-patches on debbugs? <podiki[m]>showing suppressed bugs should show closed but it does not :( <podiki[m]>the answer is to do (setq debbugs-gnu-suppress-closed nil) even though it sounded like if you show suppressed bugs it shouldn't hide closed anyway <lissobone>Is it just me or something's wrong with Kdenlive? <lissobone>At first it worked... incorrectly. The effects (and compositions) window was snow white. Now it just segfaults. <podiki[m]>nckx: did you investigate that module import warning already? <nckx>Did I not push a removal? I thought I did. <GNUtoo>hi, is (define-module (system) [...] #:use-module (guix channels) #:export (some-stuff-to-export)) sufficient to get (channel [...]) ? <GNUtoo>Thanks. For some reasons using "channel" (like even in (pk channel)) results in "Unbound variable: #<variable 7fe543a4b7c0 value: #<undefined>>" <GNUtoo>And I'm unsure where to start looking for how to fix that <nckx>I'm not at a comfy puter just now but it's probably syntax, not a real variable. <nckx>But why do you want to do this in the first place? <GNUtoo>The background here is that I've an arm64 board (rockpro64) that did boot fine with Linux 6.3.5, so I want to use Linux 6.3.5 somehow in the system.scm <GNUtoo>Another option would be to build the kenrel but for some reason building 6.3.5 failed with some modules not available <nckx>If it was ever packaged at any point in time you could use an inferior if you don't want to maintain your own package/channel. <GNUtoo>Yes that's exactly what I'm trying to use <nckx>Guix's linux-libre@6.3.5 fails? <GNUtoo>Well my version of linux-libre@6.3.5 on top of current guix without inferiors fails <GNUtoo>I'm unsure of why as there is only 1 defconfig in the tree (arch/arm64/configs/defconfig) <nckx>Ah. Guix System does hard-code assumptions about which modules exist, by default at least. <GNUtoo>No here it's more me that used some modules when 6.3.5 was there and they're now gone <GNUtoo>Did guix provide defconfig long time ago? <GNUtoo>There was gnu/packages/aux-files/linux-libre/6.3-arm64.conf <GNUtoo>So I guess diffing the config is probably the best way to get it fixed <fries>hi, so, im currently trying to update the rust package for guix to 1.71.0 and i've gone quite far and i almost have it working. one problem, it seems like the validate-runpath phase fails as rustfmt seems to depend on the librustc_driver and libstd shared object files and the rustfmt output doesn't seem to have that so it fails. do you know if i can depend the rustfmt output on the main rust output that contains the rustc and libstd shared libraries? <fries>starting phase `validate-runpath' <fries>validating RUNPATH of 0 binaries in "/gnu/store/7rhn5g4m1bqps7n7av3z3fnix08iq85m-rust-1.71.0-rustfmt/lib"... <fries>validating RUNPATH of 2 binaries in "/gnu/store/7rhn5g4m1bqps7n7av3z3fnix08iq85m-rust-1.71.0-rustfmt/bin"... <fries>/gnu/store/7rhn5g4m1bqps7n7av3z3fnix08iq85m-rust-1.71.0-rustfmt/bin/rustfmt: error: depends on 'librustc_driver-9ffe7c4ee4559b56.so', which cannot be found in RUNPATH ("/gnu/store/7rhn5g4m1bqps7n7av3z3fnix08iq85m-rust-1.71.0-rustfmt/bin/../lib" "/gnu/store/9lc5nl027q8q9gd34bk85hqsxx554fan-llvm-15.0.7/lib" "/gnu/store/930nwsiysdvy2x5zv1sf6v7ym75z8ayk-gcc-11.3.0-lib/lib/gcc/x86_64-unknown-linux-gnu/11.3.0/../../.." "/gnu/store/gsjczqir1wbz8p770zndrpw4rnppmxi3- <fries>/gnu/store/7rhn5g4m1bqps7n7av3z3fnix08iq85m-rust-1.71.0-rustfmt/bin/rustfmt: error: depends on 'libstd-f3697f373a6dea5e.so', which cannot be found in RUNPATH ("/gnu/store/7rhn5g4m1bqps7n7av3z3fnix08iq85m-rust-1.71.0-rustfmt/bin/../lib" "/gnu/store/9lc5nl027q8q9gd34bk85hqsxx554fan-llvm-15.0.7/lib" "/gnu/store/930nwsiysdvy2x5zv1sf6v7ym75z8ayk-gcc-11.3.0-lib/lib/gcc/x86_64-unknown-linux-gnu/11.3.0/../../.." "/gnu/store/gsjczqir1wbz8p770zndrpw4rnppmxi3-glibc-2.35/ <fries>heres the output, sorry if i shouldn't of pasted multiline text <fries>my irc client (konversations) did say this might not be a good idea to paste multi line text <civodul>hmm i can't reconfigure on current 'master' because cross-compilation to i586-pc-gnu is broken, so no childhurd <civodul>cbaines: i reverted a041bbb4bf98cce72b14c554369fc56eeacc2f5d and i can't seem to reproduce the problem mentioned in the commit message <civodul>like "guix build libreoffice -s i686-linux -d --no-grafts" works fine <civodul>ooh, it's "-s i586-gnu" that has a problem <janneke>hurd-team is okay, jpoiret is looking to merge the bottom of that branch to fix this <civodul>problem with git-fetch in mig is twofold i think: (1) complications because we'd need autoconf/automake early on, and (2) circular dependency with Git <civodul>i think (1) is addressed on hurd-team, but (2) cannot be solved easily <civodul>janneke, jpoiret: how about uploading a new mig tarball to fix the immediate problem? <civodul>that way we can work on the rest later without pressure <civodul>i could look into it tomorrow if that make sense to you <janneke>civodul, jpoiret i'm fine with that, although i believe that pushing the bottom 7 commits of hurd-team, i.e, up to and including 4d1b4b60eab0fc9d850d7056a649ab8e7eb6ba5f would fix this too <janneke>(possibly the bottom-most commit should be pushed last, i.e., as the seventh commit) 