<civodul>nckx: yes, sorry, i'll email the list <civodul>the plus sign is about contributing to the translations <nckx>I noticed only the menu. <bdju>is there any way to enable full disk encryption without reinstalling guix system? I'm getting a new drive soon but I kinda wanted to just clone it to save myself some fuss. otherwise I was thinking if I did a fresh install on it I could enable FDE and then copy data over afterwards somehow <vagrantc>you could "guix system init config.scm /path/to/mounted/encrypted/filesystem" and manually do all the cryptsetup commands to mount /path/to/... <vagrantc>but you have to be pretty confident in failure recovery skills ... might be a bit tricky to get everything right and might have to try a few times <vagrantc>but using "guix system init ..." should copy much of what you already have installed, so shouldn't have to re-download or re-build much of anything <bdju>as far as packages go I just have a few in config.scm and then a bunch in my manifest so that'd probably give a fairly barebones system <bdju>so in that scenario would I format the new drive and set up luks on it before anything else? for some reason I was imagining I had to go through the guix system installer again and let it handle things for me <bdju>another question, if I do just do a fresh install on the new SSD and then mount the old one over USB and copy stuff over, will I run into any issues like keys or IDs not matching stuff? how much can I copy back over? what about my store? would I just want to copy over my home dir and let the rest be built fresh? has anyone done something like this lately? <bdju>and inside the installer can I grab my config.scm from elsewhere to apply it right away or should I just use what the installer gives me and then modify it later? <vagrantc>bdju: you can either do it manually or reinstall through the installer ... kind of depends on what you're confident with work :) <kennyballou>what am I doing wrong to specify a mirror and luks container on the mirror for install? I'm specifying the mirror exactly as the mapped-devices documentation. However, after unlocking the drive in grub, I get "invalid argument" after stage one(I think) attempts to assemble the mirror. I started with the /etc/configuration/desktop.scm as a start and filled in the mirror and updated the luks uuid to match. <kennyballou>does grub need to be built with something extra to read the raid? Or does the raid need to be constructed with the metadata at the front? eg, --metadata=1.0? <SeerLite[m]><ngz> "I see 0.10 was released." <- Alacritty 0.10 requires a newer version of glutin than what's on Guix ;_; <SeerLite[m]>Should I package a new glutin version or bump the existing one? <SeerLite[m]>How do you all keep track of all this versioning ;_; <eonn>I've been thinking about setting up separate profiles for suites of things that are related. e.g. all my emacs packages, and then a profile for all my x11 related packages, etc. Is this the right way to be thinking about profiles? <kennyballou>I was able to boot by adding "raid1" to to initrd-modules: `(initrd-modules (append (list "dm-raid" "raid1") %base-initrd-modules))`. <kennyballou>"dm-raid" alone wasn't sufficient.. I plan to write this up somewhere and will link when complete. ***califax- is now known as califax
<bsturmfels>hi folks, is anyone familiar with getting a yubikey working in Guix? I've installed python-yubikey-manager, but `ykman` can't see my key <porcupirate>bsturmfels: I think you need the pcscd service running. <bsturmfels>porcupirate: awesome, ykman can now see the device. Doesn't seem to work in Chromium or Icecat just yet. I wonder whether a reboot might help <bsturmfels>no luck with rebooting unfortunately, still not seen by either web browser <Ribby>Just the other day, I saw that people were talking about getting more users or consumers to guix. <flatwhatson>howdy, looks like nautilus is missing python as a native-input since 5d20d7e1 (similar to ea0e8022) <Ribby>Other than reformatting the data storage device, guix, like linux brands, may require the internet to complete its installation process. <Ribby>It's not a bad thing because it's definitely data allocation, and a convenient one at that. <Ribby>the data storage device would probably be more expensive for its physical size. gotta put it in a safer place! <Ribby>that is, if we stuff all the OS installation files into that device. <vagrantc>all the files sufficient to run the installer are already on the installer media, which would *probably* be able to install a very minimal system without network <vagrantc>though the installer may make some assumptions about network availability <Ribby>So, what's with the mentioned updates/upgrade? <Ribby>Oh, and what would that very minimal system would look like? command line? TUI? <Ribby>If the net based updates/upgrades are required, it would not be a problem for consumers with a high enough internet access. <dumbdemic[m]>Is there a way to access environment variables in guile? I would like to print current user home dir with display. <Ribby>For those in internet incapacity, it would not be easy to get installation updates/upgrades, provided that it will access GUI and user friendly variables. <Ribby>That's why I talked about bridging connection (or maybe ad hoc networking) during a OS installation. <vagrantc>Ribby: is there anything unresolved about that? <dumbdemic[m]><SeerLite[m]> "dumbdemic: `getenv` procedure" <- Cool that works, thanks! <Ribby>With one computer as bridge, one usb-ethernet adapter, and few ethernet cables, the installing computer would have no problem getting updates/upgrades on a public network. And probably as acceptable behavior in public. <Ribby>It's probably just me, but I don't see myself buying internet before buying a non OS computer with a guix usb in hand. However, computers usually come with OS already. <Ribby>Back to public networks, if the updates/upgrades makes the GUI and other user friendly terms, the question would be "Now, how would I get to a accessible network?" It is technically up to the user's responsibility, but it could be a very creative process. Almost like a text adventure game. <vagrantc>Ribby: that seems like a very general question and a bit off topic for #guix <vagrantc>Ribby: i mean, it's fine to mention it, but to keep bringing it up after it's already been worked out <Ribby>I thought that maybe someone would like to know the theory than a hypothesis. Libraries, wifi, and probably internet cafes would be potential sources. It's just a matter on how to remedy missing updates/upgrades during a Linux-like installation. <vagrantc>Ribby: it's really pretty off-topic for #guix <vagrantc>it's one thing to get help actually doing something like that with guix, but another to talk about the theoretical possibilities of bridged networking <vagrantc>where theoretical is largely completely known and sorted out <Ribby>I guess you can say it's more of a bootloader thing. <vagrantc>Ribby: what do you mean when you say "bootloader" ? <Ribby>Like the BIOS or something of the sort. <vagrantc>Ribby: other than getting guix to boot from BIOS or UEFI, and load a bootloader, that loads guix ... it's pretty much off-topic here. <Ribby>Maybe I'm going too hardware though. It's a hardware thing. Still, it would at least interesting, even more so if GNU develop programs like that. Which channel works with such context? <vagrantc>a bit of off-topic is fine, but if someone says "hey, that's pretty much off-topic <vagrantc>generally you should listen and back off a bit :P <vagrantc>trying not to be too pushy here, this is a great and generally welcoming community :) <bsturmfels>yay! after hackily copying some udev rules from libu2f-host-1.1.10/lib/udev/rules.d/70-u2f.rules into my system config and rebooting again, my yubikey is working in browsers :) <Ribby>Anyone know of a good guix (terminal) manual? Website included? I am just starting out and haven't got the know-how down. <drakonis>`info guix` `info guile` and `info guix-cookbook` <Ribby>I get a help guide window or is it in terminal text? <drakonis>but it is the same manual you get on the website <porcupirate>Is there a shortcut to wrap a program so there's a hard-coded parameter? <kitzman>what were the motivations behind switching to Hurd? bringing developers to both Hurd and Mach? sorry if this question is uninformed <kitzman>the technical reasons I understand, but given the fact that Mach is (afaik?) not really maintained, I would assume one of the goals would be to revive it. <kitzman>compared to other microkernels I totally understand the decision <gnoo>i guess it's because of the focus on making a complete gnu operating system <gnoo>and it fits nicely due to it using guile for configuration <gnoo>which is kinda the biggest part of guix <kitzman>one point for my question is that now i feel more inclinded to contribute to Mach (i'm not a regular opensourcer). <kitzman>and yeah i agree, guix using hurd would be one of my dream OSs - probably one could adapt the configuration to be suited for embedded devices as well <kitzman>(choosing a minimal set of translators) <kitzman>seL4 and Genode are actively maintained but I think the Mach/Hurd choice was because they're GNU projects + Hurd has more translators <xelxebar>I assume there is a plurality of motivations: Hurd == cool! Official GNU kernel; Good test of underlying Guix assumptions; ... <kitzman>i am; i haven't been up-to-date with latest guix developments tho. <gnoo>well the more i use free software the more i want to contribute to it :P <xelxebar>kitzman: I'm sure the Hurd would smile at any love you sent its way! <kitzman>oh! that explains so much. i think i misread one of the other posts. <kitzman>still, guix was what got me look into microkernels in the first place <kitzman>the android project would be so much better with a microkernel for example, as well (better codebase) <munksgaard>Good morning everyone! I'm trying to build a cabal (haskell) package that depends on z3. I'm on a foreign distro, but both cabal-install and z3 are installed with guix. I first had problems passing the right flags to cabal so that it could find the z3 include files, but I think I've gotten that to work. It also seems to be able to find the lib files, but now when I compile I'm getting undefined references to some GLIBC functions. I haven't <munksgaard>installed glibc with guix, so it's not much of a surprise, since the distro-glibc is too old, but if I do `guix install glibc` a lot of other stuff seems to break. Does anyone know how to tackle these glibc errors? <munksgaard>Aha! I was supposed to install gcc-toolchain instead of glibc, I think? <efraim>munksgaard: installing glibc is almost always the wrong move. I assume gcc-toolchain is what you'd want, but I haven't tried manually building a haskell package by hand <munksgaard>efraim: That seemed to help a bit, but now I'm getting segmentation faults after manually setting LD_LIBRARY_PATH manually <efraim>munksgaard: If you're going to combine guix packages and other packages I'd suggest looking at guix/build/haskell-build-system for run-setuphs to see what Guix does with haskell packages <efraim>have you tried using 'guix shell'? It normally does the right thing™ when it comes to things like this <munksgaard>efraim: I've tried that in the past, without luck, because the haskell packages in guix were too old <munksgaard>But perhaps I should try again and see if has improved. Anyway, thanks for your help :) <attila_lendvai>importing countless rust packages from crates.io simply feels wrong <attila_lendvai>let alone filling out the repetitive New variable notes in the commit message. this all feels like creating noise, manually... <efraim>attila_lendvai: I suggest using etc/committers.scm to add rust packages. You might need to adjust some commits later but it automates some of the process <efraim>libtorrent-rasterbar tests fail if there are 24 cores :/ <efraim>attila_lendvai: is this with libtorrent-rasterbar built from before the merge? <efraim>I've also updated the point release with the update I'm trying out <attila_lendvai>efraim, i have no idea. if the lib wasn't updated, then that could be the case. <efraim>attila_lendvai: the easiest way to check would be to follow 'guix gc --references' to see the glibc version. if its 2.31 then its from before the c-u-f merge and that might be the issue <attila_lendvai>efraim, guix gc --references /gnu/store/hgpkylvgvn15acni6i4y4k5mkvs5xx28-libtorrent-rasterbar-1.2.14 => /gnu/store/2fk1gz2s7ppdicynscra9b19byrrr866-glibc-2.33 <efraim>well there goes that easy answer <abrenon>hmmm, uppercase, not lowercase, ahh ha, good one, CRAN <attila_lendvai>how do i decide for rust packages whether to #:skip-build? or not? <attila_lendvai>probably something like this: when skip-build is false, then the sources are not packaged, only the built binary (?), and if other packages want to import it as source, then they will fail. <attila_lendvai>so, a bunch of the rust packages that i'm adding require rust-1.57, while the default is rust-1.54. how do i deal with this? shall i add a #:rust ,rust-1.57 to every one of them? that will mean maintenance burden in the future when the default rust is updated... <attila_lendvai>i guess moving the default rust forward is not an option (without a world rebuild)? <vldn>ist there a qt-wrapper for a package definition? my package trys to install to /usr/... <vldn>i try to build moonlight-qt <jbv1[m]>Hi guix! The interoperability of guix package manager and julia package manager still needs to be improved. Julia keeps on upgrading some minor dependencies, it makes it quite hard to understand why an environment stops working suddently, until one realizes that a cairo wrapper has been replaced... I'm thinking maybe a guix-julia package with a function that users can run which automatically checks for decrpencies. thoughts ? <mbakke>attila_lendvai: rust 1.57 is the default as of current master <gnoo>how do you package a git-package ? like something you're supposed to always build on master <attila_lendvai>mbakke, damn, thanks! i was a few days behind, and i thought that shouldn't matter... :) <ennoausberlin>Hi. I want to create my first own channel. I created a git repository to store it and now I want to declare it in a file. There is a hash parameter to (make-channel-introduction ... Where is this hash coming from? <ennoausberlin>attila_lendvai: I created a gpg key before. How do I mark this commit as trusted with my gpg-key? I did not use gpg and git before together <abrenon>trying to time-machine an old version of chromium fails on building a .drv for a non-official channel chromium isn't even on… <abrenon>I don't really understand the error: what do other channels have to do with a specific commit for guix ? <abrenon>I don't even understand if the problem is with time-machine or the guix environment command it spawns <xelxebar>abrenon: Mind sharing the command you invoked and resulting output, error, etc? <abrenon>guix time-machine --commit=f91ae9425bb385b60396a544afe27933896b8fa3 -- describe <abrenon>(it fails even with the describe command, so I guess it's a matter with time-machine) <abrenon>the error message in the bzless mumbles something about my nonfree kernel <abrenon>I don't even understand how this can be needed to prepare an old version of guix to install chromium <vldn>are using the linux kernel instead of libre on your system? <abrenon>on Guix System, replaced the libre version by the linux kernel <abrenon>the error is on the channel providing it, I just don't see how that is linked to preparing an environment with chromium so I think I'm missing some key aspect of time-machine here <abrenon>like, on which channel the --commit parameter applies or something <vldn>the error suggests that the linux-libre kernel is missing or just the headers for the environment i guess <vldn>works pulling to that specific commit? <xelxebar>abrenon: Sounds like our setups are similar. Running locally as a sanity check. <vldn>gnu packages linux is required in chromium.scm <xelxebar>Hrm, the shared error is for the `describe' command, right? <vldn>maybe as a debug you could set the specific commit on a specific channel via a channels.scm file @ abrenon <vldn>and providing the channel file to guix time-machine <abrenon>seeing that environment then build were failing, I replaced it with describe <xelxebar>abrenon: Yeah, I see a similar error. I'm guessing that time-machine only pulls in the official guix channel, so when you do describe, the variables defined in your profile that come from non-official channels are chocking. <abrenon>ahhh, good point, describe is not that innocuous <xelxebar>A sharper tool might be to use the -C flag to time-machine. <abrenon>but wait, why did it choke for the build ? other channels weren't needed in that case ? <abrenon>yeah, -C is what vldn suggested and I'll try that <xelxebar>Not sure. What was the other command that choked? <xelxebar>Whoops, yeah, didn't see vldn's message. Beat me to it! :D <xelxebar>Hrm. I gotta run, but will check later if you haven't figured it out already. <abrenon>I launched the build from a channel file containing only the official guix channel from my current-system where I replaced the commit with the one I want <abrenon>thank you again for the good tips you two ! <vldn>someone knows of an example for a qmake *.pro output path wrap? don't know where to look for the path that i have to substitute, can't find a /usr definition in the *.pro file :D <nckx>attila_lendvai: Use a domain-specific tool like sed or gawk. <nckx>Or write your own minimal Scheme substitute (no pun intended). <ss2>Are there any extras I need to take care of when extending the guix manual? <ss2>I've added a new node, but the compiler now stops. <nckx>I don't think adding new @nodes to a menu is mandatory. What does the error say? <nckx>(And maybe it is, dunno!) <ss2>ah, just stashed the modification away, and trying to compile a clean tree. <ss2>no, it exits. It hasn't got to do with my texi. <nckx>I say lunch; it's coffee & a waffle. <Digit>coffee and a curried mince dish, should keep energy going longer than the crash of a waffle. <vldn>woop woop :) good to know! <ss2>forgot to clean my build. <johnhamelink>Hey folks, I'm running Emacs out of guix foreign (I plan on slowly building my guix config to the point where I can swap to using guix as my OS). The cursor on Emacs is almost entirely black - is this something I can change with guix and if so what should I read up on? I am very new to Guix so please excuse me if what I'm asking is obvious? ***iyzsong- is now known as iyzsong
***josibake_ is now known as josibake
***futurile is now known as Guest945
***efraim_ is now known as efraim
<yewscion>I'd like to avoid running `guix pull --disable-authentication` as soon as possible. <nckx>yewscion: Version 3? Does that exist? <yewscion>nckx: I thought that the version needed to be bumped when You change the authorizations file. Is that not the case? <nckx>No, it's the format version. <nckx>Digit: I'm out of curry ☹ (I'd say you can't eat curry every day, but that's a lie.) <yewscion>That would explain it, then. Dang, thanks, I dunno how long it would have taken me to figure that out. <nckx>yewscion: I missed it at first too! I hope that fixes it. <vldn>mh (assoc-ref %outputs "out") unbound variable "outputs" :/ <vldn>try to substiute the output path within the qt-build-system <nckx>johnhamelink: Does (set-cursor-color "Yellow") do anything? That's about the extent of my emacs knowledge. It's certainly not expected, and Guix does not handle .emacs configuration at all. <nckx>Well, guix home probably can, but you'd presumably know if you use it (I don't). <ngz>(set-cursor-color "Gray") <ngz>I think the problem is the mouse cursor, not the "cursor". <nckx>johnhamelink: I thought you meant the text cursor (that indicates point). If you meant the mouse pointer, no idea, and feel free to file a bug at bug-guix at gnu dot org if nobody has clues. <nckx>vldn: <within> You're editing the build system? <vldn>i'm replacing the configure phase <nckx>* (and similar like %build-inputs) are deprecated and slowly being torn down. <nckx>Don't use them in new code. <nckx>They only work in random places. <vldn>alright, whats the alternative then the assoc-ref to %outputs? <nckx>My god that thing takes forever to clone. <nckx>I ^C'd the ridiculous checkout, but that should work. <vldn>maybe, the prefix path in the app/app.pro file is hardcoded, if it don't work i have to substitute it in the configure phase i think, let's see, thank you! <nckx>If the comment is still needed, adjust it similarly. <vldn>very helpful example to update my packages :D ***robin__ is now known as robin
*attila_lendvai still feels that it's a complete waste of time/effort to duplicate all these rust crates <nckx>Fair, but I hope this won't become a daily scheduled reminder. <nckx>vldn: For completeness: if you want to refer to other outputs than the default :out, you can use #$output:foo. assoc-ref for both outputs and inputs will eventually go away completely. <attila_lendvai>nckx, that depends on how long it will take for me to package openethereum... :) <attila_lendvai>ngz, it's basically about whether to duplicate all the golang or rust packages within scheme, or to allow their native build systems to fetch the dependencies <ngz>But if their native build systems fetch the dependencies, wouldn't that hinder reproducibility of the package? <attila_lendvai>ngz, that depends on whose definition of reproducibility you prioritize *nckx imagines the world's scariest computed origin; maybe that could ‘work’… <SeerLite[m]>nckx: Should inputs be referred directly by their name? e.g. `#$bash`? <jpoiret>reproducibility as in: "I can build it right now" <attila_lendvai>jpoiret, that can be overcome by importing/snapshoting the vendored deps into the guix store <jpoiret>pinning dependencies to a specific version as well (such as in golang) is also a curse <nckx>SeerLite[m]: You cite a rather special case, since bash is often an implicit input, which are currently hard to address 😉 In general, I'd say no, use #$(this-package-input "bash") instead. This will in effect look it up in the inputs list, as assoc-ref used to do, which is generally what you want. <jpoiret>"oh, you actually want to use a 4 yo version of a dep because you never took the time to update your code to work with the newer version?" "well, no security/bug fixes for you then" <jpoiret>vendoring is what caused the log4j vulnerability to be this hard to patch <jpoiret>one thing i wish languages would not do is try to do package management by themselves <attila_lendvai>jpoiret, importing/duplicating golang's build system and packages, and making a mistake in the process that then results in miscompiling an app... is also a curse. i don't see any good solutions here. <jpoiret>attila_lendvai: duplicating packages is basically what we're doing, that's cjust packaging for a distro <jpoiret>there are upstream projects that are packaged downstream <attila_lendvai>jpoiret, sure, but golang and rust probably has more packages than the rest of guix... :) <jpoiret>the issue is because the languages think they ought to take over package management, people have started shipping smaller and smaller packages that 1) don't do much 2) aren't updated <jpoiret>and people think it's cool to have a lot of them as dependencies <jpoiret>attila_lendvai: i wouldn't say that's a meaningful metric <nckx>The fix has to be in addressing the fundamental design mistakes in Cargo/Go/etc. That seems… unlikely, but ‘just keep the broken tools, it's less work in the short term’ is not a reasonable answer. <jpoiret>nckx: i think upstream should keep escape hatches, like manual builds and external dep managament <jpoiret>GOPATH being deprecated is a huge step back for distros <attila_lendvai>jpoiret, IMO packages should be as small as possible/meaningful, *and* allowed by the costs of the packaging system. i don't think golang or rust libs are too small. <jpoiret>well, I have tried packaging a professionally-made go app (proton-bridge), and among the dependencies that I had to add, way too many of them were more than 5 years old, deprecated/unmaintained, some of them were very simple utility functions <nckx>vldn: For example, if this thing points users to a web shop that offers proprietary software, that's a problem and it needs to be patched not to do so. <nckx>That's just an example of what seems probably based on the README. <ngz>There must be a way to batch close bugs, right? <jpoiret>all in all, it's just a better reason to work on those importers :) <nckx>vldn: Hm, the more I read, the more of an ‘interesting edge case’ it sounds 😉 ‘GPLv3’ … ‘allows you to stream games from your Windows gaming machine’ … hmm. IMO there has to be a reasonable way to use this to stream a libre game from a libre system to another libre system, without proprietary ‘driver support’ or whatever, for it to belong in Guix. But this should probably be discusse <nckx>d on the ML if you submit the patch. *attila_lendvai is reminded to send his go importer patches <jpoiret>nckx: the main issue is that it's only a client, and the server has to be geforce experience <jpoiret>otherwise you'd just use a standard libre remote desktop protocol <nckx>You say those words like they mean something to me, but alas. <nckx>I'm guessing ‘bad’ from the tone. <vldn>yep only a client to connect to a geforce card , simliar to rdp but with full gpu support and really minimal latency <vldn>another way to keep windows away from your working rig or stream it from inside a vm with full gpu support :) <vldn>i'll submit it as a patch and we'll see :) <nckx>Sorry, I'm still giggling at ‘GeForce’ apparently still being a thing. <jonsger>has it any real world usage while using nouveau driver? <attila_lendvai>there's so much repetition in this that it feels like a religious ritual... :) <xelxebar>Memtester86+ for uefi has a proprietary license?! :/ <nckx>Something like that yeah. <xelxebar>nckx: Hehe. Looks like we're having the same series of thoughts. <nckx>Oh, go ahead if you were, didn't mean to poach. <xelxebar>It would need to be a system service that adds a grub entry, no? <nckx>I (literally) don't know if that's even possible. I just boot it manually. I hope nobody's booting memtest that often… <nckx>The grub.cfg generation code isn't a system service, and I don't know if it can be extended at all. I personally doubt it. <zimoun>autoconf and automake are not included by default with gnu-build-system? <zimoun>so why the bootstrap phase is done by default? <nckx>Only if configure's missing. <nckx>gnu-build-system is (especially was) the good-old-fashioned-gnu-bootstrapped-tarball-build-system. Less so now, but it still assumes a ‘release’ tarball by default and lets you add the autotools only when needed. <zimoun>Yes, but it is weird to try something which cannot be successful, all by default <nckx>I don't see it that way. <zimoun>especially when the manual is not clear about that, IMHO. <nckx>patch-shebangs will patch, e.g., python shebangs *if* python is an input, but it won't abort the build if it python's not an input and it encounters a python shebang. <nckx>The gnu-build-system also runs ‘configure && make’ by default, both things that will certainly fail if you don't have the right inputs. I really don't see a difference. <apteryx>is it discouraged to use canonical-package? <nckx>zimoun: If you find a good place to document it, that sounds like a better ‘fix’. <nckx>Other build systems like to inherit from gnu- (dunno about 'bootstrap specifically) so not sure where that would be. <zimoun>nckx, I agree. My point is about implicit inputs with the build-system. I do not list python when I select python-build-system. Why do I have to add autoconf and automake to the gnu-build-system? Especially when it runs a phase requiring them. <nckx>Because they are very seldom needed and the phase almost never runs. <nckx>Lots of packages fail the 'configure phase when pkg-config is missing. We still don't add pkg-config to every g-b-s package. <zimoun>So this bootstrap phase should not be done by default, but turned of by an arguments, as #:bootstrap? #t and in this case, it would make sense to me. <nckx>I don't understand why 'bootstrap should be treated specially and different from any other phase. <nckx>‘No’ in that it doesn't make sense. <nckx>I maintain that there's no bug or design deficiency here. What *is* lacking, perhaps, is a clearer error message and/or docs. <nckx>Is this about command-line transformations, by any chance? <zimoun>because as you said, almost all the packages have ’configure’ so this phase is useless (nothing is done). And when the phase is required, the tools are missing. <nckx>I don't agree with your characterisation of ‘useless’. <zimoun>Pick the correct word for just display that «GNU build system bootstrapping not needed~%». <nckx>This bothers you so much you want to hide it behind a #:bootstrap? #f by default? I don't understand. <homeostat[m]>Hi there. Would anyone be able to offer advice on freeing up disk space used by Guix? My foreign install is using near to 30gb but I'm sure a lot of that is just old revisions, etc <Guest75>Hi there. Would anyone be able to offer advice on freeing up disk space used by Guix? My foreign install is using near to 30gb but I'm sure a lot of that is just old revisions, etc <zimoun>nckx, it is not because that bothers me. :-) (I never noticed bedore ;-)). It is the contrary, when it is really required to produce the file ’configure’. <homeostat[m]>yikes! didn't realise the irc was feeding into this chat :) woops! apologies for cross posting <nckx>Hehe. I was a bit… not concerned, but intrigued by what would either be an ‘oops’ or a prelude to bot spam. <zimoun>I am surprised that a phase fails because tools are not in the implicit inputs of the build system. <nckx>homeostat[m]: Look into, e.g., ‘guix pull --delete-generations=1w’ and ‘guix package --the-same’. They will break GC ‘roots’ (old references) so ‘guix gc’ can remove more trash. If that still frees far too little, LMK, maybe there's another one I forgot. <nckx>zimoun: I feel like if this exact same thing happened it 'configure you'd be fine with it and add pkg-config or gettext whatever and be totally fine with it. You wouldn't try to add both to the implicit inputs of *all packages*. 😛 <zimoun>nckx: Since the phase is almost never used, it would make more sense to me to have #:bootstrap? #f by default, and when I would do #:bootstrap? #t, I would understand that I would have to add more inputs. As we do for #:tests? <nckx>That's just making users jump through tedious hoops. <nckx>The use case for #:tests? is different. And it's not even #f by default, so I don't get the comparison at all. <nckx>zimoun: Now they have to add another magical keyword in addition to the inputs, to get the same behaviour as before. It's artificial. <nckx>It's a regression, too. Instead of ‘autoreconf is missing’ (in the horrible ‘127’ secret code, but I suggested fixing that above), users now get ‘no configure script’. Then they have to know to add ‘#:bootstrap? #t’, *and* they still have to add autoconf/make. Nothing is gained, but more work is needed, and the error is nearly identical. <homeostat[m]>nckx: Great that seems to have cleared a good quarter of the space. Probably good enough, thanks! <nckx>Less than I expected TBH but glad you're happy. <homeostat[m]>Well there's still 14.4GB in .links. Does that sound reasonable? <nckx>Guix deletes nothing by default. Every action is append-only apart from ‘guix gc’. So unless you have a lot of space, you'll want to occasionally run it. <nckx>homeostat[m]: .links should be as big as the rest of /gnu/store, all files in .links are hard links to files in /gnu/store. <nckx>So don't count them as using additional space. <nckx>I think du is clever enough to know that if you point it at /gnu/store, but more primitive tools might not. <zimoun>nckx: I do not understand. What you are proposing to catch the error and instead display: «add autoconf and automake in native-inputs». What I am proposing is to add #:bootstrap? and why not extend the list of implicit inputs when it is #t. <nckx>I understand what you're proposing :) <zimoun>So I am missing why it would be worse than the current situation. :-) <zimoun>(aside it is a world-rebuild ;-)) <zimoun>For sure, the manual is lacking soemthing. I will give a look for improving, or not. :-) <nckx>See? Basically identical. <nckx>I think there's an optimisation now to not hard-link tiny files because it's not worth and actually degrades performance for little gain, so that might account for the difference. <homeostat[m]>Great! thanks so much, really helpful. I shall guix gc every so often from now on <nckx>But .links is all just pointers into /gnu/store, using very little storage (almost none). <nckx>homeostat[m]: Run the commands I gave above before you do so; Guix is very conservative in what it will delete otherwise. Conversely, running those commands will break roll-backs to generations older than a week (or whatever you choose), so that's the trade-off. <nckx>Can't have infinite roll-backs without near-infinite storage :) <nckx>zimoun: Would you propose the same change if there weren't two siamese-twin packages (autoconf/make) but only one you needed to add? <homeostat[m]>oh i get it. Being hard links Disk Usage Analyser, which I was using, considered it to be an extra 20G, but actually that's just because it contains hard links to all the generations in /gnu/store! I think I've just understood guix a little better! <nckx>Well, it's not a crucial Guix concept, just an implementation detail to save some space, but it's always nice to gain 20G of (perceived) space completely for free! 😉 <zimoun>nckx: yes, I think. In any case, any improvement is a world-rebuild, so it is for later. ;-) <homeostat[m]>nckx: Makes sense! I wonder if it would be helpful for useless people like me who have not digested guix as well as I should to have guix package say something about using guix gc once in a while? Just an idea. <nckx>zimoun: Interesting, I thought maybe you were trying to save a line. Now I really don't understand which advantage you see, but that's all right, I'm just me. Don't wait too long to discuss it if you want to make the next rebuild 😉 <nckx>homeostat[m]: Guix (I can't say off-hand which subcommands, or all) will warn you if it detects ‘little free space left’. You must not have hit that threshold yet. <zimoun>nckx: “too long” depends on the next core-updates cycle. ;-) <nckx>That's always too long. :( <gnoo>how do you reference a local git dir for a package? <nckx>apteryx: Could you explain in a sentence what canonical-package actually *does*? <jpoiret>imo, current-guix should always refer to the current guix package, while the `guix` package could only refer to major versions, but I don't have any knowledge wrt Guix bootstrap so that may be completely bonkers <jpoiret>we could make it so that the install image always uses the current-guix, which would make testing guix changes in a vm much more manageable (unless I'm missing something, as right now I've been mounting the source inside the VM and using ./pre-inst-env there) <apteryx>nckx: it maps a user exposed package to a package used implicitly by the gnu build system. <apteryx>(that's my high level understanding of the thing) ***zap1 is now known as zap
<apteryx>mbakke: is 1589f09729072e35d28e9e5466d4c5d9ed9461a4 really needed? I thought attrs was only required for Python < 3.8 <apteryx>and hmm, you just taught me that package/inherit was not just syntax sugar over (package (inherit ...) ...) <apteryx>in 4d7134c37222a19d8719f2ea7fef53bdad10ac9b <civodul>jpoiret: not yet, but yes, you can take a look! current-guix kinda does the job, but only if called from a working tree <civodul>the other option is to have current-guix use channel-build-system (currently in (gnu ci)) <jpoiret>yes, i was thinking of expanding that to all guix invocations as well <jpoiret>so that we can use current-guix in the installer indiscriminately <civodul>right, with channel-build-system, that could work <jpoiret>uh, I was looking up if we couldn't simply pass the store path of the currently running guix <civodul>the only problem is that when running "make release", the current commit is not known to 'current-channels', and not public <jpoiret>store path can be used in gexps directly, right? <jpoiret>maybe there's a bummer wrt cross-compilation <jpoiret>hmmm. The issue (and why i want to take a look at this) is that we'd also like to specify potential channels <civodul>in (gnu system install), we could also do (or (current-guix) guix) or similar <civodul>probably the easiest solution wrt. "make release" <jpoiret>right, but it does seem strange to be going backwards when using guix system init and friends <civodul>so you'd like to change the guix used in %base-services as well? <jpoiret>are there any guarantees that we can expect guix to come with the full profile? <jpoiret>something like .config/guix/current/ <nckx>apteryx: Thanks for the attempt. It's not your fault it still won't just click 😉 <nckx>I mean, I almost get it, I just don't grok it. <vagrantc>any compelling reason not to update guix? on aarch64 it was fixed in master a while ago, but hasn't been updated since, so guix-daemon fails to build on aarch64 ? i think basically the patch applied for https://issues.guix.gnu.org/52943 just needs an updated guix with that commit <civodul>jpoiret: ok, i don't get your question then :-) <civodul>vagrantc: wasn't it updated already? <vagrantc>it was committed, but the guix package is still an older version <civodul>vagrantc: isn't it what 195bb1fb9d55d8e5187d669c63a3cde747fc5f64 did? <vagrantc>i've had an aarch64 machine running guix pull for coming close to two days now, and should be able to actually test it on master <jpoiret>ah, apologies. I mean, in the case guix is running normally (ie not a source checkout), can we take for granted that it is contained in a profile created with `guix pull`, with a manifest? <zimoun>apteryx or mbakke: oh, what is the difference between package/inherit vs (package (inherit …))? <jpoiret>that would allow us to simply reuse that profile's manifest <civodul>jpoiret: instead of playing tricks to reuse store items, i'd rather use channel-build-system, that sounds safer <civodul>jpoiret: so a plan could be (1) extract channel-build-system, (2) use it in (gnu system install) <vagrantc>civodul: the fix was committed in 24c3485bb3ffc05e687ef6513ac287b8d3048bab ... <civodul>and then: (3) add cross-compilation support to channel-build-system, and (4) use it in %base-services <civodul>(3) and (4) are less obvious but should be doable <vagrantc>i managed to test it successfully on an older version before the version-1.4.0 branch merge, but then the world rebuild happened <civodul>vagrantc: i see, i can update 'guix' then <jpoiret>okay, seems good to me! if I understand correctly, the guix that would install would be the latest available, not just the one you're running then, right? <civodul>jpoiret: no, that'd be the one of the current commit, as returned by (current-channels) <vagrantc>i was tempted to just push it but ... guix-daemon and all that ... a bit sensitive <civodul>vagrantc: heh, not so sensitive, but i always build it locally first and sometimes there are surprises <jpoiret>oh, i wasn't aware of (guix describe)'s current-channels! seems exactly what i was looking for :) *vagrantc has ~4 concurrent builds of updates to the guix package running :) <civodul>vagrantc: oh, should i let you commit when you're done, then? <civodul>jpoiret: yup; so i gather you'll look at the issue? we can chat if needed <jpoiret>yes, i'll be poking around and see if I can successfully do that! <vagrantc>civodul: i won't have a chance to test on anything other than arch64 at the moment ... <antlers>zimoun: as I understand just from peeking at the commit that was mentioned, package/inherit will cause a package to inherit it's parent's replacements, where as the usual inherit field/mechanism doesn't extend to a package's replacements (when using eg. grafts, transformations?) <jpoiret>wdyt about adding that code to (current-guix) rather than in the installer? <antlers>So package/inherit might be appropriate if two package objects are fundamentally the same package? (x & x-final, or x-with-y?) <apteryx>screen sharing couldn't work with Google Meet* <vldn>sneek is life :* botsnack <jpoiret>screensharing is a complicated beast <jpoiret>are you on X/Wayland, which DE if any? <apteryx>jpoiret: I'm pretty sure the issue with Google Meet is due to 'enable_hangout_services_extension=false'; I'm using Xorg <apteryx>that's a build flag for (ungoogled-)chromium <jpoiret>right, after reading the thread i understand <jpoiret>it's a bummer that you can't selectively add only screensharing <apteryx>antlers: about package/inherit, yes that seems to be the use case it is intended for (variants of the same package) <vagrantc>oh, wait, i do have an x86_64 machine i can test on ... <zimoun>apteryx, antlers: package/inherit adds the field ’replacement’. <podiki[m]>log says "/gnu/store/99c25918hl9pihix8hparmc96q6zrpwy-tar-1.34/bin/tar: /gnu/store/n1kzba52c58jpm7pivhrl4a36b55xh4q-gcc-10.3.0.tar.xz: Wrote only 8192 of 10240 bytes" <antlers>zimoum: the field is present in all package records, but isn't usually inherited because it's marked as innate <antlers>I dug a little deeper, and see that where the usual mechanism inherits from a package without considering it's inmate replacement field, package/inherit will inherit from either it's parent *or the replacement of it's parent* if present <podiki[m]>recent breakage: wine-minimal fails somewhere between c9f9e78 and 4d7a997 <podiki[m]>from the git log not sure what could have done it <apteryx>mbakke: I guess it sadly should be left disabled, to stick to the package's motto "with some functionality disabled in order to protect the users privacy"; leaving door open for Google would be a precedent. <podiki[m]>though wine just had big update to 7.0 that might be better to do (should have less 32bit dependencies too, if I understand correctly) <_73>How can I import a module that comes from a channel? For example I would like to use a service definition from rde which I have set up as a channel but I cant figure out how to import the module into my scheme file. <antlers>zimoum: I may be going too far in, but once again, there are more details: the returned package inherits from it's parent, with any overrides applied to it, wether said parent has a replacement or not; when it does, said overrides are also applied to it's replacement, which is returned in the replacement field of the new package- effectively inheriting from the present replacement, but specifically via populating the replacement field, so I see that <antlers>Thx for helping push me to root around and learn more specifics <jpoiret>_73: what scheme file are you talking about? If it's one consumed by guix home, and your guix contains the rde channel, you can just use #:use-module (rde whatever) or (use-modules (......)) <_73>jpoiret: ok that is simpler than I expected thanks <mbakke>apteryx: screensharing works for me in Sway for Jitsi and Zoom, at least <mbakke>dunno why google meet would be different, weird if it requires those private APIs <jpoiret>mbakke: are you using xdg-desktop-portal-wlr w/ pipewire? <jpoiret>i find it pretty annoying to set up personally <mbakke>apteryx: wrt 1589f09729072e3, I just noticed in a dependent package that attrs was missing, and found it came from aiohttp's requires.txt ... is it part of the stdlib now? <mbakke>jpoiret: no pipewire or xdg-desktop-portal <jpoiret>hmmmm, i wonder if it uses Sway-specific apis then <gnoo>hello, is there any way i can reference a local directory for git clone in a guix package definition? <ekaitz>apteryx: remember the meson thingie from yesterday? nautilus also fails <mbakke>apteryx, jpoiret: does screen sharing not work on xorg? are there any related messages in the terminal (when started from one)? <jpoiret>i don't use chromium personally, was just curious about your Sway setup <apteryx>mbakke: I think it's a Google Meet specific thing (they use features not yet part in the WebRTC spec) <vagrantc>gah. new on aarch64 FAIL: tests/publish.scm <jpoiret>firefox uses xdg-desktop-portal and friends, so it requires a lot of setup <ss2>which is the recommended way to add a personal key to .guix-authorization in my local tree of guix without inferring with, say, the master channel? <jpoiret>you can't, unless someone else signs the commit that adds your own key <jpoiret>that's the whole point of authentication :) <ss2>I'd like to sign my own commits, so that I don't have to disable authentication when pulling. <ss2>okay. At least I figured channel authentication. <antlers>gnoo: I haven't tried this, but I think you can just put a file path into the origin, where the URL would go, or maybe like "file:///home/user/repo" <gnoo>antlers: i tried /home/user/repo, i'll give file:///home/user/repo a try. thanks! <antlers>I'm not too hopeful if the raw path didn't work :c <gnoo>nope, didn't work, git says check if permissions are valid <gnoo>but i can clone it from another location so that's not an issue <mbakke>gnoo: try (source (git-checkout "/the/directory")) <mbakke>gnoo: uhm, that should be (source (git-checkout (url "/the/directory"))) <apteryx>mbakke: the error is a nice "Your browser is not supported" in Google Meet upon attempting to use the screen sharing feature *apteryx tries screen sharing in jitsi <gnoo>mbakke: which module should i use? i get git-checkout: unbound variable <nckx>podiki[m]: Greetings! Are you testing Wine 7 as well? (At this rate, Wine will soon surpass Windows in version number — and hence quality — at least until Wine 95.) <gnoo>mbakke: thank you! the build failed but it did clone! <gnoo>hmm, git-checkout is only mentioned twice in the guix manual and never is it described, even in 'Origin Reference' node <podiki[m]>nckx: wine 7 looks interesting but might need work; they bundle more libs to build as PE (? windows format?) so I don't think we would unbundle? but less inputs then; might be beyond me <podiki[m]>looks like wine would have less 32bit needs, which will be nicer to build *podiki[m] -> lunch for real <nckx>I don't get the ‘nicer to build part’. Is that an i686 thing? <nckx>podiki[m]: You'll be back. Lunch has tempted many, but they always return to Guix. <nckx>drakonis: You build wine-minimal to build wine (this is how, e.g., CUPS works, too) but that has nothing to do with 32-bitness. <nckx>Or at least that's not documented anywhere. <mbakke>apteryx: good to know! I guess we can safely file the meet issue as "not our problem" :) <vldn>how to handle guix pack packages? <vldn>can i import them on my guix system? <vldn>or do i have to use guix copy <pkal>Does anyone know what packages to install so that org-mode can compile to latex? <antlers>vldn: according to the blog post from it's release, guix pack is meant to be more like an application image, so you probably ought to use guix copy for your purpose <podiki[m]>nckx: I don't really know the wine internals, but their release notes talk about not needing to install 32bit libraries at some point (still need them, but less so I guess) to run from 64bit <podiki[m]>in our packages eventually that would mean no more wine/wine64? i'm not sure, but at least things seem to be converging <podiki[m]>found the libratbag problem, it was that meson doesn't propagate python anymore (other fixes the last few days) <nckx>podiki[m]: What the release notes mean is that they no longer link to ELF (‘Linux’) binaries, they build their own PE (‘Windows’) DLLs (or equivalent) from source. The binary package inputs are hence useless here. If you build Wine you'll notice that it runs perfectly if you delete every single input mentioned in the notes. <nckx>It's not that it needs them less, it both doesn't need them and still does but uses its own copies. But it's not lazy bundling either. It's complicated. <nckx>I'm still not sure what the Guix answer is. <podiki[m]>nckx: right, that's what I would guess would happen. but also sounds like they aremoving to have 32/64bit run together <nckx>This actually makes sense. <nckx>Well, WoW64 Wine was always a dork so good. <podiki[m]>sounded like you could build your own system PE versions and provide instead of bundling (not sure if there are other use cases?) <nckx>You can, but that doesn't sound sane to me. <nckx>The only argument beyond unthinking reflexing ‘durr bundling bad’ would be grafts, and I'm a bit sceptical grafts would actually work the way we expect them to across a virtual OS boundary. <nckx>(Did I test that assumption? No. Testing it would require implementing the whole thing, a lot of work.) <jacereda>Anyone got Pipewire desktop capture working on Sway? I get: [4800:4800:0119/201758.043616:ERROR:base_capturer_pipewire.cc(746)] Failed to create a screen cast session: GDBus.Error:org.freedesktop.DBus.Error.UnknownMethod: No such interface “org.freedesktop.portal.ScreenCast” on object at path /org/freedesktop/portal/desktop <lilyp>I'm pretty sure grafts didn't work with Wine even before the PE thing <podiki[m]>nckx: yup. I did build wine-minimal 7.0 (failed, but was able to manually build it, I think some SHELL setting in configure needs to be patched), but only to see it compiled <nckx>Actually, even if it did somehow work, we'd still need to graft the PE variant [used only by Wine] separately, negating any hypothetical advantage of having it at all. <podiki[m]>lilyp: have you taken a look at wine 7.0 at all? <nckx>podiki[m]: It's actually pretty easy to build once you substitute* the /bin/sh. I've been using it all day for $work. <nckx>Almost suspiciously smooth, good thing there's this PE matter to obsess about :o) <lilyp>We already build PEs currently, so I'm not sure what the fuzz is about with 7.0 <lilyp>did something corey get PE'd? <podiki[m]>at the least it needs that and then we can delete a bunch of inputs <nckx>diffoscope has been running for an hour to compare the inputs/no-inputs versions. I wonder when it will finish. <nckx>It's probably disassembling all of Wine. <podiki[m]>from the release notes they do more (but not all) as PE, not sure how much more from the most recent staging <lilyp>podiki[m]: No, I haven't, last time I checked it was 6.20 or so <nckx>About 8 more previously native libraries are now PEs. <nckx>lilyp: ‘We already build PEs currently’ — not sure what you mean, if that's about Wine. <lilyp>nckx: Wine has been building with PE libraries since 6.1x for some pretty small x. <nckx>And which ‘fuzz’ dym above? <nckx>I seem to have missed any fuss. <nckx>I don't follow Wine closely. <lilyp>I'm not quite sure, but I think ntdll.so was a PE for example <apteryx>mbakke: it's not convenient but yeah, I agree. If jitsi can do it, meet shouldn't *require* browser-side customizations. <apteryx>they could at least offer a "downgraded" mode, like they seem to for other browsers (some reported it works in firefox, albeit very inefficiently) <nckx>lilyp: I don't understand the connection. <nckx>I thought you brought it up 😛 As long as we both agree it's irrelevant all is good. <lilyp>My main claim is "we have been building Wine PEs for a while" <apteryx>mbakke: I tried enabling the hang services in chromium just for the kicks, and couldn't share a screen either. Perhaps relevant in the output: [2212:2212:0119/143403.799942:ERROR:context_group.cc(184)] ContextResult::kFatalFailure: ES3 is blocklisted/disabled/unsupported by driver <lilyp>Possibly relevant side claim: "We're not grafting Wine for the foreseeable future." <nckx>Which is triviall true, but (neutral) ‘so what’? <nckx>I can't imagine Wine not containing PEs since day 0. It's kind of the point. <lilyp>I simply thought there were technical issues with the 7.0 upgrade related to PEs <lilyp>Has it been upgraded yet? I'm currently lagging behind. <podiki[m]>current wine is failing to build, which is why I brought it up <podiki[m]>not sure where it broke in the last day or so of commits (didn't see anything related), but figured any effort should just go to updating it anyway <nckx>Would you know, I never even tried current Wine… It's horribly unshiny all of a sudden. <podiki[m]>(probably due to the more i686 failures since 1.4.0 merge) <lilyp>x86_64 still relies on the i686 build, so... <podiki[m]>nckx: i think wine64 has subs? ci says yes, guix weather says no; wine-minimal fails (i686) <lilyp>if wine-minimal fails, nothing else should have subs <podiki[m]>I'm always confused about wine and subs; sometimes guix seems too, depending on build/install/shell? (some discussion recently here) <lilyp>unless wine-minimal did succeed on CI and fails on your machine non-deterministically <nckx>wine 7: ./libs/tiff/libtiff/tiff.h:28: error: tiffconf.h: No such file or directory <nckx>Our libtiff: This file maintained for backward compatibility. Do not use definitions from this file in your programs. <podiki[m]>lilyp: failed locally with same error as in the log (some kerberos linking?) <lilyp>podiki[m]: is this the same evaluation you're currently running? <nckx>Sorry, thinko. *Our* libtiff doesn't have it for presumably that reason. It's only in the bundled copy. <nckx>Was Wine ever reproducible? <lilyp>nckx: I'd say it was somewhere between "maybe" and "try next time". <podiki[m]>oh, is wine-minimal only used in vkd3d? (per comment in code) <lilyp>does wine no longer require vkd3d? <lilyp>because the chain used to be wine-minimal -> vkd3d -> wine <podiki[m]>arch's 7.0rc build included vkd3d as make dependency, for what that's worth <lilyp>I'll git blame the person who removed it, but current wine should fail to build <podiki[m]>so...yeah I don't understand why there are newer succeeding wine builds when wine-minimal fails, but probably I'm reading it wrong <lilyp>look at the CI output, wine does not have vkd3d as input <podiki[m]>I see vkd3d in the wine inputs in the code though *podiki[m] confused, more than usual <nckx>diffoscope's current opinion is ‘hell to the naw’, but that's a sample size of 1. <nckx>I mean it could in theory be my fault. <podiki[m]>diffoscope finished? or just doesn't want to <nckx>Ah, no it did finish eventually. I mean it was noisy but ‘functionally identical’ all that differed were hashes and addresses, but no symbols were lost by removing inputs, they were already unused. <nckx>podiki[m]: Yeah, I was not complaining, all the work it did was real. Nice objdumps. Very dumpy. <podiki[m]>okay, so no surprise that the inputs aren't used <nckx>Anyway it's possible the load addresses are deterministic and removing inputs somehow changed that. It's extemely unlikely, but I can't point fingers yet. <podiki[m]>random q: would a guix size reflect that as well? no more refs to those inputs? <nckx>But it won't catch all ways they could affect the build (only, arguably, sane ways :) <podiki[m]>lilyp: was that vkd3d line changed recently? I see it in current version <nckx>Then again these are all heuristics anyway, I didn't actually check each line of a 400000+ line diff, even one so pretty as this. <lilyp>It wasn't, it should be there but CI doesn't show it *podiki[m] further confused <nckx>I'm giving it one more sanity build & will push 7.0 shortly. <lilyp>@ substituter-succeeded /gnu/store/73qg4rb95pbpkpw716b00r8g1lk1qh3p-vkd3d-1.2 <podiki[m]>I like "fixing" build problems with a package update, like a 2 for 1 sale <nckx>In addition to the $work test suite, it has also successfully passed the $pinball fuzzer. <lilyp>pinball is a really good test though <lilyp>because of the way floating point arithmetics broke between processors, Microsoft was unable to correctly implement it for a while <nckx>Yes. Which I just realised is a no-no here. I literally use it only to test Wine, because I feel like it's a more ‘interesting’ test than rendering text fields, and I don't have any other Windows software. <lilyp>so if it works in Wine, you're good :) <nckx>I love that anecdote slash fact. <podiki[m]>lilyp: not to get off topic, but do you have a link about that handy by any chance? <nckx>Had to do with the unusual way they pre-tested 64-bit Windows, which was — hold on — not on Intel. <nckx>Very off-topic, sorry. I just love computer history. <podiki[m]>I wonder if there is a collection of software like that, good for testing preservation and the like? <podiki[m]>but yes, sorry to go too far off topic, facinating stuff <jonsger>feels like a world rebuild on master. I have built icedove some days ago and it now downloads a ton of packages for the same build... <lilyp>your-favourite-invidious.instance/watch?v=3EPTfOTC4Jw <lilyp>jonsger: 1.4.0 was merged into master and caused a world rebuild <jonsger>ah the packages were prebuilt by cuirass maybe on the 1.4.0 branch <podiki[m]>yes they were, but seems there were unintended rebuilds/breakage <lilyp>we typically avoid those by merging master into the respective branch first <ngz>lilyp: Thanks for 2c9f13ba6379afdad8df82166ea512c35d25aa4a. It has bugged me a lot recently. <podiki[m]>nckx: years in your copyright line for the wine commit... <nckx>I'm clearly still living in the past. <nckx>I'll fix it up with the next substantial commit, it's not worth the noise on its own. But thanks! <PotentialUser-50>Hi I am totally new to guix, and I am trying to do an initial 'guix system reconfigure', but it seems to hanging on the check phase when installing mutter. Anyone got any advise? <lilyp>PotentialUser-50: Mutter has a pretty long check. If you want to skip building, you can wait for a nicer weather (see `guix weather mutter' to check whether substitutes are available). <civodul>PotentialUser-50: you're installing 1.3.0, right? <johnhamelink>nckx: thanks for your reply earlier - I was stuck on the phone for hours! I will file a bug as that is indeed what I meant :) <nckx>I just hope it wasn't an emergency. <PotentialUser-28>Hi. I'm trying to install guix system on a server, but the iso fails to resolve a partition so I don't get to the installer. The server is a KVM. I can connect only through VNC. <johnhamelink>nckx: Nope! It was just a long-winded work thing. The catchup on work life has meant I'm only just back to having time to investigate this bug now lol <johnhamelink>nckx: sorry to ask a potentially silly question, but is there a code of conduct for the mailing list I'm about to send to? I'm unsure if it's good etiquette to attach screenshots or not and want to check before bothering people. <PotentialUser-28>To answer myself: nope. I tried with another image that included nonguix, same problem. <lilyp>podiki[m]: why not make imgui shared tho? <lilyp>and no, this is not a full review <lilyp>johnhamelink: if it can be expressed by a log, please use a log <lilyp>if it needs a screenshot otherwise, go ahead <f1refly>I think the helix editor needs a non-standad install phase (cargo install --path helix-term) when building, but I can't figure out how to do that, can someone spoonfeed me? <johnhamelink>lilyp: its an issue with the rendering of my cursor while hovering it over Emacs, so I do think it's justifiable. Thanks for the pointer :) <lilyp>f1refly: helix-term should be built as part of helix-editor, no? <lilyp>if not, try packaging that first <podiki[m]>lilyp: that mangohud links to? I assume they wanted static for a reason (performance?) so I matched upstream <lilyp>johnhamelink: is it by any chance not respecting your local display settings? <johnhamelink>I found evidence of other people having this issue too online <f1refly>lilyp: I don't think so, and when I look into the resulting store path there's only a /share/cargo with the source there <nckx>I agree with lilyp but that's when people send clearly in-screen screenshots of their desktop terminal… <nckx>for some reason that is a thing that happens. <johnhamelink>nckx: thank you! Just trying my best to be courteous - I don't have much experience with mailing lists so I'm not sure what normal looks like! <lilyp>In case it's on a foreign distro: I recently found out that Guix' GSettings are actually divorced from your distro's GSettings. So chances are you just have to install the cursor themes through Guix as well as configure them and it ought to work fine. <lilyp>Note that I haven't tested this hypothesis myself yet, I only did fonts so farr. <johnhamelink>lilyp: yeah that might be the case - I'm not far enough along in my Guix knowledge next to know how to do this idiomatically so I'm still pretty stuck at this moment in time. Given that this might *not* be a bug, would I be better suited mail help-guix instead? <jacereda>Hmmm... font-service shouldn't be in %base-services, the selected font just sucks on hi-dpi monitors and the default one is perfectly readable. <nckx>johnhamelink: Disable HTML mail if your client lets you, don't top-post if you remember not to, and you're already doing great. To vaguely paraphrase someone: if you're even *wondering* if you're being an arse, you're very unlikely to be one. (It's not fool-proof but it's a good filter 😉) <johnhamelink>nckx: Ha! That made me chuckle :D I'll be mailing with mu4e, which I am beginning to fall in love with :) I had no idea what top-posting was until I duckduckgo'd it just there haha <nckx>jacereda: It's not about readability but about coverage. Without it you're stuck with an extremely limited CP437 character set. It should be possible to rewrite the service to query the console size and choose a ridiculous (e.g. 16x32) font based on that, but it would require a rewrite. <apteryx>rekado_: I'm curious; in your past bazel packaging effort, had you looked at what Nix does? It seems they have it in their repo <nckx>johnhamelink: mu4e++. It has the least annoying warts. <apteryx>ah, but they fetch a bunch of java and other things, probably as binary seeds <nckx>jacereda: That said making it %base is a judgement call I wouldn't personally make either. I don't use it myself. <johnhamelink>nckx: agree! I like contexts & the GPG integration is very nice. I'm using org-msg too which lets me blend in at work 👀 haha <civodul>looks like sneek has become super warm and welcoming <civodul>notmaximed: yes, i just pushed a fix :-) <civodul>twas preventing an update of the 'guix' package <notmaximed>I noticed it while testing some changes to (guix test http) to make it usable for the minetest and github tests <jacereda> nckx: someone with perfect vision won't have any problem with a big font in the installer, but someone with visual problems might have trouble following it <jacereda>I guess the simplest thing is to just leave the default font <jacereda>the one you have when font-service isn't in %base-services <nckx>The logs sometimes get truncated, ytc. <nckx>I've restarted the build. <ytc>i didn't understand what you meant by "truncated". <nckx>It was substituted from a build node that had already built it successfully, so I don't know what happened to cause the spurious failure. <jacereda>is there a time limit for the jobs? Maybe it took too long to download and got killed <nckx>It's hard to say. The truncated log was a genuine build log (it contained the output of unpacking the tarball until it was cut short), the ‘new’ log is just that of a substitution. So I don't think it was a download gone wrong. <nckx>The failing build failed after 636 seconds IIRC, which is certainly no timeout we have. <podiki[m]>hate to be a bother, but can anyone look at (and hopefully push) https://issues.guix.gnu.org/53372 (fixes failing test due to meson not having python anymore, prevents me from reconfiguring since I use the dbus files) <podiki[m]>but now I see that doesn't fix piper, I think it needs the same python fix, and maybe no more librsvg....testing now <nckx>So adding this to every consumer is the fix? Does every single Meson package require Python? Is there a pending patch for (say) c-u that addresses this in the build system? I'm willing to push it but I'm a bit lost. <nckx>Do the majority of Meson packages build? <podiki[m]>I think the majority do, but e.g. libratbag needed python to run tests <podiki[m]>while piper wouldn't build without python as input <podiki[m]>I count ~25 commits like this, from the past week or so <nckx>Yeah, I was sensing a meme as well. <nckx>I don't pretend to know or like Meson, but I thought the whole shebang was written in Python to begin with. <podiki[m]>bah, the commit referenced doesn't exist 5d20d7e1369fc7d93de19c0bd219937d697ceae6 <nckx>So Meson is just completely patched/wrapped not to need any Python propagation whatsoever to perform the average build? <podiki[m]>I'm speaking with no knowledge at all, but yes? <nckx>If so, that's impressive. <podiki[m]>seems only ones that actually need to run python directly broke <podiki[m]>and I would guess this is what we want, a clear input of python for those that actually used it <nckx>I'll change the commit to 6f and push. <apteryx>nckx: meson doesn't need to propagate python, but python custom scripts are often written to complement meson; in these case adding python as an input is necessary <nckx>podiki[m]: I'll leave the bug open to receive more similar patches. <podiki[m]>the python for native-input lets it build, but then it doesn't run for me (piper); I need to do a full reconfigure and update first though, in case it is something on my end <nckx>If you decide not to for some reason, please remember to close it, as I sure's hell won't :) <podiki[m]>I wonder where that wrong commit hash came from <podiki[m]>nckx: will do. I sometimes go back and look at old bugs I participated in to close <drakonis>i still cant upgrade my system because of gnome's dependencies <podiki[m]>nckx: PS: you really are in the past, your commits on savannah show up as 2022-01-16 01:00:00 +0100 for a while now. just fyi. <nckx>Nah that's by design. The copyright header was not. <nckx>This is the new and improved forge-o-matic that does handle GPG signatures and no longer randomises dates. <nckx>‘Stoopid script in my .local/bin’ ain't got the ring to it. <drakonis>right now, i wish there was kde because gnome is giving me shit <rekado_>I think I know what’s wrong with koma-scripts <rekado_>what is now texlive-updmap.cfg used to be run as part of a profile hook <drakonis>hmm, how would i actually use the guile libraries i installed? should i point my load path to them? <rekado_>apteryx: yes, Nix is a constant source of disappointment for me whenever I wonder how they solved a problem. <lfam>I'm convinced that Bazel is just a google recruiting test. They only hire people that can figure out how to set it up <drakonis>nix solves things by throwing roller-compactors at things <jgart>is anyone working on packaging caddy server? <jgart>just curious because drakonis and I are going to start working on it together <nckx>lfam: In the sense that if you meekly accept that and don't begin ranting, you're a ‘good fit’, I can believe. <cbaines_>to be fair, data.guix.gnu.org hasn't processed past 6e92790 yet either <cbaines_>looking at the log, it's building things, Cuirass on ci.guix.gnu.org may be busy building things too ***cbaines_ is now known as cbaines
<nckx>Strange that it's only ‘guix’ too. <vagrantc>uhhhh... did my update to the "guix" package break something? :/ <cbaines>I don't believe so, the issue seems to predate that <drakonis>i've been having issues with gnome for the whole week <KE0VVT```>Looking for bugs related to ldconfig and Flatpak. <cbaines>drakonis, are those guix specific gnome issues, or gnome issues in general? <lfam>What trouble drakonis? Have you updated to include the recent fix for nautilus, from the last hour or so? <drakonis>there's some problem with meson during the install phase <phf-1>Hello! So, i've 25 packages to add: https://paste.debian.net/1227741/ . I guess they are not that good quality wise (e.g. #:test? #f) in various places more by convinience than anything else. Where do I start from here? To add them if that's of any value? <lfam>drakonis: It's from about an hour ago, like I said <drakonis>alternatively, someone's got the wrong dates there :V <lfam>Dates don't mean anything in Git <lfam>You can set the date to anything you want <lfam>Don't pay attention to timestamps :) <nckx>drakonis: Not recently enough :) <lfam>phf-1: If there are things in your packages that you would identify as "not that good", then add code comments explaining why they are like that. Or else it will discourage people from reviewing your patches <nckx>My :) earlier was meant as a hint but I got distracted before I could follow up. <nckx>drakonis: Duped by the forge-o-matic. <jgart>What was the reason that a monad implementation was needed for Guix? Just trying to understand better the design choices and the benefits of using a monad to put stuff in the /gnu/store/... <phf-1>lfam: So, I guess that I should carefully send them one by one and explain quirks in each case. That's the process?