IRC channel logs


back to list of logs

<raingloom>how come populating /etc at boot takes so long now?
<elais[m]>I thought this was a bug. I always just press alt until it goes away
<elais[m]>Not only that I thought it was a bug I created when messing with my config.
<malaclyps>no, it definitely started after the last big core upgrade
<elais[m]>That's bad but you don't know how much of a relief it is read that
***shikhinCube is now known as CompanionCube
<nckx>malaclyps, elais[m]: I haven't seen any bug reports about that. Either of you mind filing one at bug-guix at with all details (if any)?
<malaclyps>nckx, i'll try!
<nckx>Thank you!
<malaclyps>is there anything I can do to make what's going on during boot-up a bit clearer or more useful for you? The symptoms are just a long hang after the "populating /etc" message (possibly awaiting a keypress, which I can test), but there's no obvious way of ascertaining where the system is hanging...
<elais[m]>malaclyps does it ever finish updating?
<malaclyps>elais[m], I think I do what you do and impatiently press a key, and it restarts some time after that. I've never actually resisted pressing the key...
<alextee[m]>does anyone know a package off the top of their head that uses a trivial build system that runs a custom install script from the tarball? looking to see how it's done
<alextee[m]>I am grepping / for trivial-build-system but most of them just copy files
<alextee[m]>"invoke" might be what i'm looking for
<mange>You're almost certainly looking for "invoke".
<alextee[m]>that makes things a bit easier, thanks
<elais[m]>Is there something I can send besides the error that says populating /etc? Like a log I should look at ot something? It showed up quite a few derivations ago
<elais[m]>* Is there something I can send besides the error that says populating /etc? Like a log I should look at or something? It showed up quite a few derivations ago
<alextee[m]>how can i get the source directory inside a builder?
<alextee[m]>or even the path to the downloaded tarball
<alextee[m]>hmm i think it's the source object
<dongcarl>Hey guys, might be stupid question but... How does the mailing list know which emails form a thread?
<dongcarl>E.g. I want to reply to, do I just have to match the subject?
<mange>I think it uses the In-Reply-To header, which should match the Message-ID of the email that it's a reply to.
<dongcarl>mange: How can I extract the message ID from the mailing list (if I wasn't subscribed when it was sent)?
<mange>It looks like it's in the form on that page. If you click the "reply via email to" button I think it will set you up correctly, otherwise you can look at the HTML for the form for the hidden input with name "d".
<dongcarl>mange: I think the "d" hidden input is just a mangled version of Ludo's email to guard against scrapers
<dongcarl>I guess I can download the mbox file... But this button's setup seems to indicate that the mailing list matches by subject as well?
<mange>It matches the Message-ID of that message in my email client. I think "a" and "c" are the mangled email address. Matching the subject is common when replying on the same topic, but the subject can be changed during the thread without breaking the threading.
<dongcarl>mange: Oh that's good to know!
<dongcarl>Thanks for explaining
<alextee[m]>so after a lot of trial and error i managed to build this gtk theme package! but it uses the standard /usr/share/themes location
<alextee[m]>what's the guix equivalent of that?
<alextee[m]>installing the package doesn't seem to have any effect although i can see the correct directory structure in the store
<alextee[m]>~/.guix-profile/share instead of ~/.guix-profile/usr/share
<elais[m]>I believe you can declare "share" as an output target along with "out"
<mange>I don't think you want a second output, you just want it in the $out/share folder of the "out" output.
<alextee[m]>yeah that's what i did:
<alextee[m]>any feedback welcome, i will run through the checklist and prepare to send it upstream
<peanutbutterandc>alextee[m], There is a 'checklist' somewhere about how to send packages upstream? o.O
<alextee[m]>peanutbutterandc: yeah, 14.6 Submitting Patches
***amiloradovsky1 is now known as amiloradovsky
<alextee[m]>how do you "update" when a channel changes?
<alextee[m]>like when you comment it out from ~/.config/guix/channels.scm
<mange>If you run "guix pull" it will update your guix based on your channels file, so I think the answer to your question is "guix pull".
<alextee[m]>guix pull: error: '/home/alex/.config/guix/channels.scm' did not return a list of channels
<alextee[m]>oh you need to return %default-channels
<alextee[m]>ok, thanks
<alextee[m]>i am getting an error that the builder for my channel failed to produce the output path....
<alextee[m]>i am not sure what happend, all i did what push a new change and ran guix pull
<mange>Is there more detail to that error message? Or a build log you can check? My guess is that you have an error that's stopping it from compiling in the change that you pushed.
<alextee[m]>oh i didn't realize it was a build error. thought it was a conflict or something. yeah you're right the log says that there was a syntax error in the package
<peanutbutterandc>alextee[m], I see. Thank you. I haven't yet gotten to that section in the manual. :D
<alextee[m]>im trying to build my program for the first time in guix and i get a bunch of redundant redeclaration errors for fscanf and friends
<alextee[m]>is this a guix issue?
<alextee[m]>from the headers it looks like it is
<peanutbutterandc>Question: What exactly is (wrap-program) doing? It seems to be taking things like `("XDG_DATA_DIRS" ":" prefix (,out)) --- what exactly is happening there?
<peanutbutterandc>P.S: I am `/wrap-program`-ing in gnu/packages/music.scm
<PotentialUser-21>Is it possible to run `guix install` inside an `guix environment --container`?
<reepca>sneek: later tell peanutbutterandc: wrap-program takes the filename of an executable program and search path definitions to {prefix|suffix|replace} environment variables, renames the program, and creates a shell script with its original name which modifies the environment variables as specified, then executes the (renamed) original program. In that example, "XDG_DATA_DIRS" is the name of the search path to affect, ":" is the delimiter
<reepca>that separates elements in the search path (optional, defaults to ":"), prefix tells it to prefix the search path with the listed directories, which in this case is just the output directory for the package being built.
<leoprikler>PotentialUser-21: Haven't tried yet, but I wouldn't count on it even if the command itself succeeds.
<reepca>sneek: later tell peanutbutterandc: that separates elements in the search path (optional, defaults to ":"), prefix tells it to prefix the search path with the listed directories (other valid values here are 'suffix and '=), which in this case is just the output directory for the package being built. In your case, you'd want `("PATH" ":" prefix ,(string-append (assoc-ref inputs "ffmpeg") "/bin")).
<sneek>Got it.
***pc is now known as Guest94276
<faraway>hi everyone
<civodul>Hello Guix!
<roptat>hi guix!
<roptat>well, I managed to forgot about the overdrive and the patch yesterday ^^'
<civodul>ah ha! :-)
<civodul>that happens to me quite frequently, org-mode is my prosthetic memory :-)
<roptat>it took me like 15 minutes to forget about them :/
<civodul>speaking of which, i wanted to test how fcntl/flock works on NFS
<wargreymon> Hi all, i cant get the USB stick boot on my Acer Swift 5, which is model SF514-54T.
<wargreymon>it hangs, black screen, i have disabled secure boot.
<wargreymon2019>Hi all, I cant get my USB stick(which is 64bit version 1.01) boot on my Acer Swift 5 (which is model SF514-54T). Help appreciated.
<civodul>hello wargreymon2019
<civodul>wargreymon2019: could you explain how you populated it, and what exactly you do and see on the screen?
<wargreymon2019>black screen, nothing
<civodul>how did you populate the USB stick?
<wargreymon2019>i use dd if=that iso of=usbstick, which boots on my desktop
<civodul>ah ok
<civodul>did you enable booting from USB devices in the laptop's BIOS?
<wargreymon2019>I cant find this option but the USB shows up on the boot menu, i am assuming it can boot from USB
<kmicu>Hi wargreymon2019, are you able to boot any other distro on that laptop?
<wargreymon2019>havent tried yet
<kmicu>(Maybe the issue is more general and it’s worth to check whether that’s the case before digging into Guix System iso.)
<efraim>its 'cat archive.nar | guix archive --import'?
<PotentialUser-74>what is the use-modules that need for qemu-binfmt-service-type?
<PotentialUser-74>i use qemu-binfmt-service-type in my scm.
<PotentialUser-74>how i could understand?
<leoprikler>(gnu services virtualization)
<civodul>efraim: something like that, assuming you obtained archive.nar "the right way" :-)
<PotentialUser-74>leoprikler: Thanks, how you understand it? i want learn the way, when encounter with same issue.
<efraim>civodul: I created it myself on another machine with 'guix archive --export --recursive /gnu/store/---package-version
<civodul>PotentialUser-74: "guix system search qemu" gives a hint
<civodul>efraim: alright, then "guix archive --import" is the thing
<leoprikler>All I did was rgrep on my local guix clone tho ._.
<PotentialUser-74>civodul: leoprikler: Thanks.
<efraim>is it ok to compile gsettings schemas during package build or is it really a profile hook?
<zimoun>I am doing "guix repl" then ,use(guix scripts environment) and for example %precious-variables and I get "ERROR: error: %precious-variables: unbound variable". What am I doing wrong?
<zimoun>I would like to use `package-environment-inputs'
<roptat>(guix scripts environment) doesn't export that variable
<roptat>you can use ,module (guix scripts environment) to enter the module and have access to its private variables though
<zimoun>roptat: ah yes, sorry! Thank you for the explanations
<roptat>don't be sorry :)
<leoprikler>efraim: there should be a profile hook for that, but without compiling the schemas, you can't run the application directly from build
<efraim>ok, so I won't look to strip it from the build then, just the icon cache creation
***pc is now known as Guest52574
<nckx>roptat: Thanks for ,module! I've been using @@ all these years.
<roptat>It can be abbreviated as ,m
<str1ngs>efraim: guix archive --import < arxchive.nar should work too
<efraim>Building the kubernetes test binary is going to exhaust my RAM
<efraim>It's using about 6.5 GiB, 400 MiB for me, 400 MiB free
<str1ngs>using less CPU cores, can help with RAM
<nckx>efraim: How quickly are you able to type dd && mkswap && swapon? 😛
*civodul learned about something really cool:
<civodul>ANSI escape sequences for hyperlinks in the terminal!
<civodul>21st century! \o/
<str1ngs>now we need emoji too! :P
<str1ngs>civodul: these escape codes are nice. should help with console formatting and real estate
<smithras>that's cool!
<nckx>str1ngs: Emojos work perfectly in my terminal (termite)… not in Emacs 😛
<str1ngs>this reminds me, I need to add VTE support back into nomad using gobject introspection
<xd1le>nckx: what emoji font are you using? i think emacs might only support bitmap color fonts for now
<xd1le>assuming you mean gui emacs
<nckx>xd1le: Yes. Console emacs is more graphically capable (go figure). I use Google Noto simply because it's the only one I know of.
<xd1le>noto color is a bitmap color emoji font, it works in gui emacs
<xd1le>or it should at least,
<xd1le>emacs 27
<xd1le>you need to set it in init file though, something like: (set-fontset-font t 'unicode "Noto Color Emoji")
<nckx>I'll look forward to Emacs 27 then, and someone packaging Noto Color.
<nckx>Last I tried using Emacs's font mapping it was ridiculous and I gave up.
<xd1le>yeah emacs font features are lacking, still no native font ligatures. (however, we might get that for emacs 28)
<roptat>would it make sense to split qtbase into multiple outputs (like debian: I think it would help reduce the size of qt applications
<roptat>like, if a package needs qt, but not its sql module, you wouldn't have to download mariadb, sqlite and mysql :)
<roptat>it would make it a bit inconvenient to properly define a qt package though, because you'd have to specify all the outputs you need
<str1ngs>roptat: on the note of qtbase, I think for qt module packages it would make sense to use a union and reuse a qt.conf for all modules packages. packaging something like qtwebengine as a module is not currently feasible. since module packages assumes the same install prefix as qtbase, which is not possible with guix. for example qtwebengine will never work without some crazy hacks for locale.
<str1ngs>roptat: also maybe qt module packages could use a qt.conf dirived from the store for sanity. instead of inheriting qtsvg
<nckx>str1ngs: Didn't we do this once (maybe with qt4)? Or am I confusing it with SDL, which takes exactly that approach today?
<str1ngs>roptat: or maybe even a qmake build system would be a better idea
<str1ngs>nckx: modular qt package do not use a union.
<nckx>Not now but in the past. Which means I might even be thinking of Nix. Doesn't matter; I agree this would be a good idea if these parts aren't interdependent.
<str1ngs>I'm not sure of the past. I just know based on my work to package qtwebengine for nomad and next.
<str1ngs>my solution interm has been to package qt monolithic with qtwebengine. see it's still WIP
<nckx>roptat: I understand you're trying to be fair, but having to specify more exact dependencies isn't much of a drawback in my book.
<nckx>str1ngs: Interesting.
<str1ngs>I think qtbase is fine as is in terms of output. so I agree with nckx
<nckx>str1ngs: Good to have someone familiar with the details of qt composition around.
<str1ngs>some top down work needs to be done on sanitizing qt modules packages.
<str1ngs>nckx: it was kinda out of necessity, not my choice of expertise :P
*nckx has to leave, will read backlog later.
<smithras>str1ngs: is your monolithic qt currently? I want to package Anki but I've been waiting for a qtwebengine workaround
<smithras>s/currently/currently working/
<alextee[m]>where should gui themes go in gnu/package/ ?
<str1ngs>smithras: yes, its using 5.13.1 . also I have a substitute server to save you building
<alextee[m]>i am guessing gnome.scm, even though this specific theme works with other environments too
<str1ngs>smithras: the substitute server is and the public key can be found here.
<str1ngs>smithras: you can report issues to me here or #nomad-browser IRC channel
<str1ngs>smithras err substitute server should be
<smithras>str1ngs: thank you so much!
<str1ngs>smithras: you are welcome. I'm interested any issues you run across
<str1ngs>smithras: right now I'm kinda limited by CPU and RAM. I'm currently using AMD Ryzen 5 3600 6-Core Processor with 16GB or ram. more cores and ram would help with development iterations
<str1ngs>smithras one known issue I have is qtwebenine does not know how to dlopen some nss libraries. I have a hack/fix here for that I eventually need to substitute this path as a more stable fix. which would require more rebuilds. which I'm trying to avoid for now.
<kirisime>Krita has stopped working when running on a second graphics card. Did something fancy happen with GPU drivers, Qt or krita itself recently?
<smithras>str1ngs: Oh I think I've run into that issue before, but I definitely would have forgotten about it without the warning!
<str1ngs>smithras: it's a runtime issue so as long as you set LD_LIBRARY_PATH it should fix it. though if you are not using guix system that will probably break. I hope you are using guix SD?
<smithras>yeah, i've got SD running on my laptop
<smithras>I was trying to get a prebuilt anki binary to run with a guix environment and a LOT of manual environment hacks. It was really ugly though, and only half worked
<str1ngs>okay, and for a laptop you most definitely need to use substitutes. with out a high end cpu/ram builds can easily take 12 hours
<smithras>str1ngs: Yeah, I tried doing that once a few months ago, never again
<str1ngs>smithras: I'm assuming you want to build anki manually and use this qt as an input?
<smithras>str1ngs: Yep!
<str1ngs>I do also have a modular qtwebengine but do to issues I mentioned above. it requires to many hackes for locales to work. and depending on how you use the library it might not even be feasible.
<str1ngs>I plan to re visit the modular qtwebengine at some point. for now though the monolithic qt with qtwebeninge seems to be the most sane approach.
<smithras>str1ngs: Yeah I don't know much about how qt works internally, I've got some spare hard drive space though so I don't mind grabbing the monolithic version
<smithras>thus sparing myself several headaches
<str1ngs>smithras: I get it. I've invested quite a bit of time getting this to work myself. on the bright at least others can possible benefit.
<smithras>I've got a final exam Saturday though, so it might be a few days before I get around to working on this :)
<smithras>str1ngs: yeah, thank you again for the help! I was beginning to think I would have to run anki in a VM or something
<str1ngs>smithras: no worries. once this is stabilized I hope to add it to until I can resolve the third party issues. blocking it from being added to guix proper.
<str1ngs>smithras: also I'll be providing substitutes for quite sometime. which is the biggest issue when dealing with qtwebengine
<alextee[m]>does guix have a notion of "groups" like arch so you can install all software in a group?
<alextee[m]>eg arch had "pro-audio" and "lv2-plugins"
<civodul>alextee[m]: there's no such thing
<civodul>it sounds like it could be useful, though!
<bavier>we do have certain "meta-packages"
<alextee[m]>it is VERY useful! a lot of people usually want to install all available audio plugins
<bavier>like gcc-toolchain, xfce, gnome, ...
<alextee[m]>maybe ther should be something like a (group "xyz") inside the package definition
<nckx>Tags like that have been suggested before.
<alextee[m]>bavier: is that baked into guix? i can't find any info on "meta-package" in the manual
<nckx>alextee[m]: A meta-package is just a package that ‘pulls in’ other packages, not a separate core concept.
<alextee[m]>oh you mean you define a new package that simply has a bunch of inputs. that could work too
<nckx>alextee[m]: Take a look at gnome. It uses propagated-inputs to do it.
<alextee[m]>at least for audio/music plugins this should be added imo
<alextee[m]>nckx: thanks. i will likely send a patch for it when i'm done packaging a few plugins
<nckx>Sure, it can then be further discussed via mail.
<alextee[m]>nckx: is the patch tracker a good place to discuss, or should i email the developer mailing list?
<nckx>Pragmatically, I think this discussion is better focused on a concrete patch.
<nckx>Like I don't think groups like ‘pro-audio’ make sense (‘I want to install all different image editors’ said nobody ever), but plugins: perhaps 🙂
<alextee[m]>thanks, yeah i agree on pro-audio.
<nckx>It makes sense to *search* for all software that does X though, but that's more a tagging effort than a grouping effort. OK, it's the same graph with arrows pointing the other way, but still. The interface would differ.
<nckx>Operative word: effort.
<ggoes>how is the guix experience on an x200 if anyone is running one on there? i tend to shy away from any distro involving much compilation on them -- even though i do know guix has substitutes etc. i'd shudder to think how long an icecat compile would take
<bandali>a couple of days, i’d guess :p
<bandali>(compiling a chain of rust compilers)
<bavier>the rust bootstrap takes longer than the icecat build, in my experience. But that's only rarely required.
<nckx>The IceCat maintainer uses an x200 and bootstrapping Rust takes 90 hours.
<bavier>and with 'guix weather' you can often just wait until substitutes are available
<ggoes>oh no
<bandali>i never figured out how to properly use guix weather
<ggoes>neither have i, haha. and i also forgot about it. so i should probably look into that
<bavier>bandali: most useful if you maintain a manifest for your user packages
<bavier>for use with 'guix weather -m manifest.scm'
<efraim>civodul: i686-linux -> powerpc-linux still has guile segfaulting on native ppc hardware
<bandali>bavier, ah cool! i’ve seen some recent chatter about guix profiles and such on the lists, but haven’t followed closely
<bandali>i wish there’s a nice guide on having per-machine profiles/manifests
<bandali>with like a core set of packages for all machines, and some machine-specific ones
<str1ngs>bandali: I have done that, but what I do is have machine-a.scm and machine-b.scm and then load a common.scm and varies for common parts
<civodul>bandali: nowadays you can even run "guix weather icecat"
<bandali>str1ngs, that sounds like what i was hoping for. are your dotfiles available anywhere?
<civodul>which is not very different from "guix install icecat -n"
<bandali>civodul, ooh, TIL, awesome!
<str1ngs>bandali: I would have to redact to much sensitive information sorry. but the idea is simple us hostname.scm and define common variables in common.scm then use those variables in hostame.scm
<str1ngs>simply use*
<str1ngs>I hope to add guile secret support so maybe one day I can make the config public
<bandali>str1ngs, thanks for the pointer. sadly, my guile-foo is currently not nearly sufficient to roll that out myself
<str1ngs>sneek: later tell nly. have you use secret sensitive system configuration?
<str1ngs>sneek: later tell nly. I meant have you used secret for sensitive system configuration?
<sneek>Got it.
<str1ngs>bandali: though a cool way to do this is probably to use scheme macros. but that requires even more scheme foo.
<str1ngs>bandali: common.scm is not too hard just use define to bind the variable like so then user default-user in place of your current user expression.
<str1ngs>bandali: there is probably better ways to do this. but I find this works for me right now
<str1ngs>I think part of the reason I used this approach was to keep filesystem configuration etc explicated to avoid HD destruction :P
<zimoun>What is the English convention about the dot ending a sentence and the closing parentehis? See for example commit ba7ea5ce33. Because "ag '\.\)' doc/guix.texi" still outputs. I am not English native speaker and for example The New York Times (US) vs The Guardian (UK) do not seem to fully agreed on.
<fart>Hi everyone,
<smithras>zimoun: hmm I'm from the US and I've always put the dot after the closing paren
<fart>I execute "guix system disk-image beaglebone-black.scm" on my Guixsd for instantiate of my system.
<fart>and it tooks more than 5 hours on my system and still running!
<alextee[m]>parenthesis end goes before period in both US and UK english i think zimoun
<fart>what's happen? is it normal?
<fart>address of beaglebone-black.scm :
<vagrantc>fart: probably a lot of missing substitutes
<alextee[m]>should i send a patch with >5 packages or should i split the patches per-package?
<fart>vagrantc: the way of instantiation is true?
<vagrantc>fart: support for the arm architectures, while technically supported, still is very much even more a diy "i'm doing this to learn and fix bugs" sort of project
<vagrantc>fart: and on a beagleboneblack ... is going to be very slow.
<vagrantc>once you have a system instantiated, it should run ok
<vagrantc>but updates tend to be slow, etc.
<fart>vagrantc: : i run above command on my x64 host to generate image for ARM
<fart>vagrantc: i forgot to tell i run this "guix system disk-image beaglebone-black.scm --no-substitutes"
<fart>am i right?
<str1ngs>fart: you probably don't want --no-substitutes this builds everything
<fart>str1ngs: OK, I think it's the reason of this long time build :(
<str1ngs>fart: most definitely
<str1ngs>though it really depends on which substitutes are available as well.
<vagrantc>fart: you also need to set up foreign-architecture building with qemu, or worker nodes on native hardware
<jonsger>alextee[m]: one patch per package :)
<fart>vagrantc: i add a "qemu-binfmt-service-type" services to beaglebone-black.scm, is it enough?
<vagrantc>fart: you'll need to add it to your system configuration
<alextee[m]>jonsger ( thanks!
<vagrantc>fart: the qemu stuff is for the host system, not the system you're building
<alextee[m]>is there a way to invoke guix download for a git branch?
<alextee[m]>maybe download the branch tarball manually and run guix hash
<fart>vagrantc: i have a customized Guixsd on x64 architecture and i want instantiate it for ARM, so what is the way?
<zimoun>smithras, alextee[m]: Thank you. For example, the sentence (l.4814:doc/guix.texi) "The spawned process runs as the current user outside the container. Inside the container, it has the same UID and GID as the current user, unless @option{--user} is passed (see below.)" is typographically incorrect in English, right?
<zimoun>We should read: "... (see below)." Right?
<alextee[m]>zimoun: yes, at least afaik
<vagrantc>fart: you're not wrong, per se, but it's a very rough road and i'm sure guix would appreciate bug reports and fixes
<vagrantc>fart: just saying that it's not something i would expect to work out-of-the-box at this time
<vagrantc>fart: in my experience, i've had better luck installing some other distro (e.g. Debian), installing the guix binary distribution, and then instantiating it natively ... but this is *slow*
<xd1le>zimoun: yes. basically the sentence should be valid if you remove the parens and everything inside them.
<xd1le>if the sentence in parentheses is on its own, the period i think should be inside the parentheses
<xd1le>if it's a sentence*
<xd1le>but that example is not on its own
<fart>vagrantc: so , for instantiating my custom OS (that based on Guixsd) there is no way else such this on my custom OS:"guix system disk-image beaglebone-black.scm"
<vagrantc>fart: all that does is creates a bootable image ... and i'm not sure how recently tested it is, or how well it works cross-building it on x86
<vagrantc>fart: just expect there to be some bugs
<vagrantc>fart: and help the community by reporting them :)
<zimoun>alextee[m], xd1le: Thank you. It is what I have read on stackoverflow and so on about English typo. But I was not sure because time to time I also read "(see below.)" style. I think the manual contains around fifty typos of this kind.
<zimoun>Thank you.
<xd1le>zimoun: yw
<fart>vagrantc: I hope it's work fine. Any way, thanks. :)
<dongcarl>Would like some feedback on how best to get clang to find libstdc++ so that our clang toolchains are useful:
<str1ngs>dongcarl: you can use the -DGCC_INSTALL_PREFIX cmake option to tell Clang where the gcc containing the desired libstdc++ is installed. quote assuming this is for building clang with C++ support?
<sirgazil>After updgrading the Guix System, I'm having font rendering problems in several applications. Like this:
<dongcarl>str1ngs: that's very good to know. Yes! It's for building clang with C++ support.
<str1ngs>dongcarl: probably this is what you need then. not sure which input provides this gcc or gcc:libs ?
<dongcarl>str1ngs: I was kinda hoping we could use the packages that the MAKE-LIBSTDC++ procedure produces...
<str1ngs>it's annoying that guix show gcc does not work :(
<dongcarl>str1ngs: Yeah... We should add an `--all` flag to show even hidden ones
<str1ngs>dongcarl: side note for gcc I use --with-native-system-header-dir=$PREFIX/include to enforce something on this lines
<dongcarl>str1ngs: To point gcc to the right libstdc++?
<str1ngs>something like that. it will use that include path before anything else
<str1ngs>libstdc++ is part of gcc:libs correct?
<dongcarl>str1ngs: I think clang wants the headers... Not the built lib?
<dongcarl>Or maybe both, I'm not sure
<str1ngs>seems maybe the headers are part of gcc
<alextee[m]>sirgazil: why does guix rebuild the man page database every time you install something? shouldn't it only do that if the package contains a manpage?
<alextee[m]>oops didn't mean to tag you sirgazil
<dongcarl>str1ngs: Yeah so the things that clang wants are split across gcc and gcc:lib?
<dongcarl>I guess we need to first have a dummy package that merges them, then point -DGCC_INSTALL_PREFIX to it?
<nckx>alextee[m]: Because Guix creates a new profile from scratch every time. There's no special-case code path to say: ‘the only difference between <profile - 1> and <profile> was <package without manpage>, so just copy the opaque database from <profile - 1> to <profile>, verbatim’. I don't even know if that would be possible.
<alextee[m]>oh i guess that makes sense then
<nckx>alextee[m]: I agree that the current behaviour is not ideal, but that solution is too complex to be worth it. Maybe you can think of a better one 🙂
<alextee[m]>im not exactly sure how this works but i guess something along the lines of keeping track of what gets installed for each package (does it have a manpage? does it have fonts? new icons?) and then when installing the new profile you could check the sum of those flags and if any of them is 0 you could copy that part (manpage or icon cache or font cache etc.) verbatim from the previous profile
<str1ngs>dongcarl gcc has an install target for install-libcpp . I wonder if that installs headers too. where maybe
<alextee[m]>the way pacman does it is i think it auto-detects what gets installed by checking the output
<elais[m]>The clear command is missing from bash. Is there something I should install that is missing?
<nckx>elais[m]: I don't think it was ever part of bash, it's part of ncurses.
<elais[m]>I've never known that.
<elais[m]>So its presence in shells is due to them using ncurses?
<str1ngs>dongcarl or maybe install-target-libstdc++-v3
<nckx>alextee[m]: Sure, my reservations were more about the final step: if(nothing changed) → cp .oldprofile/man.db .newprofile/man.db. I haven't a clue about what the DB contains (store refs?) and whether that would work.
<dongcarl>str1ngs: Have you seen MAKE-LIBSTDC++ in (gnu packages gcc)?
<alextee[m]>nckx: oh, yeah im not too sure either for manpages but for the font caches and icon caches and glib schemas at least it's straight forward.
<str1ngs>dongcarl I'm looking now
<dongcarl>str1ngs: Thanks for helping btw
<nckx>elais[m]: Yep, although other shells or things like Busybox might have it as a builtin. But bash never has.
<nckx>alextee[m]: I run a pretty minimal ship but profile hooks run in a matter of seconds here.
<str1ngs>dongcarl: I guess this has the same effect. just this requires an additional build libstdc++ could potentially be an output. I guess the question is how to best produce an output with stdc++ headers
*nckx comes across horrible ‘How to clear the screen using Linux’, ‘10 BASH commands to clear your screen’ articles; understands the confusion.
<alextee[m]>it takes like 10 seconds here, probably because of the gtk docs
<str1ngs>clear screen ^l :)
<nckx>str1ngs ssh nooo that's secret
<str1ngs>yeash, everytime I try to center the terminal... thanks emacs. I always clear my screen . I should rebind it in ~/.inputrc
<nckx>Whenever someone asks about ‘clear’ I assume they're writing a script; shirley nobody types ‘clear’ every time…
<nckx>Then, the pain comes.
<nckx>str1ngs: Your terminal supports centering?
<str1ngs>no, its just a habit thanks to emacs
<jackhill>I type clear because thati's in muscle memory, but I'm learning to type C-l.
<stikonas>well, one thing that is true, guix teaches you that some commands that we assumed are core to the system are actually just pulled in as dependencies
<dftxbs3e>hello Guix!
<dftxbs3e>I would like to know, what is the current gcc version used to bootstrap?
<stikonas>dftxbs3e: it should be in gcc-mesboot package, I can look up exact version\
<stikonas>dftxbs3e: I think 4.7
<stikonas>sorry, it's actually 4.9.4
<stikonas>but it's actually just part of dependency chain anymore, it's bootstrapped from mes
<dongcarl>str1ngs: Not 100% sure what you mean... I think `libstdc++-4.9`'s output definitely has the headers... But not the libs
<dongcarl>str1ngs: Because in the gcc package, we put the libs in a "libs" output, but in MAKE-LIBSTDC++, we don't declare that as a valid output
<nckx>Yeah, we don't bootstrap ‘from’ GCC at all, if that's what you mean dftxbs3e.
<str1ngs>dongcarl: I guess what I means is libstdc++ could be a potential output of gcc. and not require the extra build
<nckx>GCC's just an intermediate step now.
<dongcarl>str1ngs: Oh that's kinda interesting... I've never thought of outputs being used that way...
<str1ngs>dongcarl: I do this with libgo for my personal toy package manager
<str1ngs>dongcarl: but I'd try to work within the bounds of the libstdc++ package since that would be lesss disruptive to the overall toolchain. but it's something to consider down the road.
<dongcarl>str1ngs: Okay cool... So right now, I'm hearing that we do what I proposed on the mailing list with adding a procedure, and pointing clang to libstdc++ thru the GCC_INSTALL_PREFIX flag?
<dftxbs3e>stikonas, I'm speaking about non-x86 archs bootstrap chain
<dftxbs3e>GNU Mes is x86 specific
<stikonas>dftxbs3e: oh I see, well, you didn't mention non-x86...
<dftxbs3e>stikonas, yes I'm sorry, that's not your fault.
<stikonas>not sure about e.g. arm. Although arm port of mes is almost ready...
<dftxbs3e>I'm looking at porting to ppc64le again and was waiting for some non-ppc64le specific progress
<dftxbs3e>I just rebased my branch on latest core-updates
<str1ngs>dongcarl: right if not a procedure then some kinda output that has the c++ headers.
<str1ngs>dongcarl: actually I'm kinda surprised clang is not already built with c++ support
<str1ngs>dftxbs3e: btw I have made progress getting guix to run in a rootless container. so I can now help with ppc64le . I have access to power8 and power9
<dongcarl>str1ngs: We do have `clang++`, but it doesn't know where the c++ headers are apparently
<dongcarl>Which is... weird.
<dftxbs3e>str1ngs, great! I made container images with prebuilts few months ago to provide that!
<dftxbs3e>podman run -it /bin/bash
<dftxbs3e>should work.
<dftxbs3e>it's currently rebuilding with latest core-updates:
<dftxbs3e>str1ngs, just to describe what must be done for GNU Guix on powerpc64le
<dftxbs3e>What's left to make it work is quite simple for someone who knows about GNU Guix works quite well. All we need to do is make a powerpc64le-specific bootstrap chain that does this: gcc 4.9.4 built with glibc 2.25 -> gcc >= 6.2 built with glibc 2.25 -> gcc >= 6.2 built with glibc 2.latest
<dftxbs3e>glibc 2.26 introduced a change in double precision floating point format on powerpc64le which means that you cannot compile glibc >= 2.26 with gcc < 6.2 which GNU Guix uses (4.9.4)
<jgibbons[m]>hello guix
<dftxbs3e>str1ngs, if you think you're capable of this, your help is VERY welcome! :D
<str1ngs>dongcarl ah this might not help then. since GCC_INSTALL_PREFIX is used for building clang++.
<dongcarl>str1ngs: I mean... since clang++ can't find the c++ headers... Perhaps that IS what we need
<str1ngs>dongcarl so gcc uses spec files. maybe clang has something like that.
<str1ngs>dongcarl: also clang already uses -DGCC_INSTALL_PREFIX= which makes sense
<str1ngs>I will think more on this
<dongcarl>str1ngs: Thank you, I'll try experimenting more as well. Let me know either thru IRC or mailing list if you have any more thoughts/insights
<dongcarl>str1ngs: Wait that makes sense!
<dongcarl>In llvm.scm, we set GCC_INSTALL_PREFIX to the gcc-lib build input!
<str1ngs>configure:4328: clang++ -O2 -pipe conftest.c >&5
<str1ngs>clang-8: warning: treating 'c' input as 'c++' when in C++ mode, this behavior is deprecated [-Wdeprecated]
<str1ngs>ld: cannot find crt1.o: No such file or directory
<dongcarl>gcc-lib doesn't have any of the hedaders!
<str1ngs>it seems it's only using it for libs as documented
<dongcarl>Oh that startfile thing already has a patch
<dongcarl>that's a separate issue...
<str1ngs>that's something gcc-toolchain helps with. I'm testing locallly
<dongcarl>what I'm saying is: GCC_INSTALL_PREFIX has to point to a prefix that has both the libs and the headers
<str1ngs>CC=clang++ ./configure --enable-gold with binutils sources. only c++ project I could think of haha
<str1ngs>dongcarl: that makes more sense. and then clang probably hardcode that path somewhere
<str1ngs>what ever clang uses for spec files I guess
<str1ngs>though I thought clang had its own stdc++
<dongcarl>str1ngs: Yeah it has libc++, which is different from libstdc++
<dongcarl>But we want to be able to do either
<dongcarl>And preferably libstdc++ by default (which is what debian does I think)
<str1ngs>that makes more sense useing libstdc++ less packages to support
<nckx>I didn't know that was possible. That's great.
<dongcarl>nckx: to use clang with libstdc++?
<nckx>dongcarl: Yes.
<str1ngs>dongcarl: so maybe once the headers are packaged in the same GCC_INSTALL_PREFIX this might resolve it's self?
<dongcarl>nckx: Haha yeah it's great!
<dongcarl>str1ngs: I think so... I think we need to create a package that merges together the "out" output and the "lib" output of gcc
<dongcarl>If there's a procedure that already does that... That would be handy...
<alextee[m]>is there a way to specify a dual dependency? (one or the other exists)
<dongcarl>alextee[m]: Use a make-blah-blah procedure! :-)
<alextee[m]>hmmm im not sure how to do that. what should i grep for in the guix distribution to find an example?
<nckx>alextee[m]: I was going to say no, because package ‘dependencies’ (inputs) are always pulled in, there is no either-or, but what's your situation?
<str1ngs>dongcarl: for via I subpackage libstdc++ with install-strip-target-libstdc++-v3 which provides the libs and headers
<dongcarl>str1ngs: Oh could you show me?
<alextee[m]>nckx: jack and jack2 in guix have the same API
<alextee[m]>and apps using jack can work with either one
<str1ngs>dongcarl here is the reference
<str1ngs>dongcrl: its a sub package of gcc. so there is some inheritance here. basically it's like guix outputs
<str1ngs>guix is better of course :P
<alextee[m]>i see a lot of jack based apps in guix explicitly depending on jack1, but this is probably not how it's supposed to work
<nckx>alextee[m]: You can create jack1/2 variations of each package, but there's no (possible) concept of ‘just use whatever's lying around’ in Guix.
<dongcarl>str1ngs: Ah okay... Perhaps the Guix package for libstdc++ could be modified... Anyway, I think it's time to experiment
<dongcarl>alextee[m]: Gimme a min
<str1ngs>dongcarl: personally it would be better to make libstd++ an output of gcc
<str1ngs>less building and redundancy
<nckx>alextee[m]: You could create a jack2ify procedure that replaces any jack1 inputs with jack2, though.
<dongcarl>str1ngs: That's probably true
<alextee[m]>i see, hmm
<dongcarl>alextee[m]: have you seen input rewriting?
<alextee[m]>well, for reference, this is how it works in arch:
<alextee[m]>see dependencies: (jack, jack2)
<dongcarl>alextee[m]: Right yeah I understand the arch part...
<dongcarl>Here's how it maps to Guix
<nckx>alextee[m]: We do something similar with most python2- packages. You'll see that the vast majority of them are modifications of python(-3) ones.
<dongcarl>our inputs have names
<dongcarl>so, for example, the name of the input might be "libjack"
<dongcarl>and these input names can be associated with a package
<dongcarl>which might be jack1 or jack2
<dongcarl>does that make sense?
<dongcarl>so both jack1 and jack2 "provides" (in the Arch Linux sense) "libjack"
<alextee[m]>oh input != package?
<alextee[m]>yeah i can understand that. let me check for examples in python then
<dongcarl>Gimme a sec, I can find you a link
<dongcarl>alextee[m]: Take a look at
<dongcarl>Or the one below
<dongcarl>alextee[m]: Understanding the composability of packages is a key step towards understanding how powerful Guix can be
<dongcarl>Happy to answer any questions
<dongcarl>alextee[m]: Also feel free to describe to me your overarching goal
<dongcarl>probably better to help on that level
<nckx>alextee[m]: An input is (for our purposes here) always a package. It's not not a ‘spec’, not a pattern that is matched against all packages (as in Arch and most other distributions), it's a value. There's no way for a Guix package to depend on ‘something like this’, including ‘either JACK 1 or 2, whatever's handy’.
*nckx doesn't quite understand dongcarl's explanation angle but isn't doing any better :-/
<nckx>It often just needs to click.
<dongcarl>alextee[m]: well... inputs are specifically outputs... not packages... right?
<dongcarl>nckx: ^
<nckx>Yes, absolutely, I thought that would be confusing though.
<alextee[m]>hmm so basically you write one of these replacement functions and use it to write a package replacement?
<dongcarl>alextee[m]: Yes, that is one way to do this
<alextee[m]>so in the end you will have 2 packages: one with version 1 of the library and one with version 2
<nckx>(dongcarl: Someone once asked me the equivalent of ‘ah so I can just make a jack:1 and jack:2 output!!’ in such a situation…)
<nckx>alextee[m]: Yes!
<dongcarl>alextee[m]: Yes!
<alextee[m]>hmm this could work, although it can get messy when searching for packages
<dongcarl>nckx: Oh noes
<dongcarl>alextee[m]: yeah, perhaps there's something to be done on the TUI front, but it's always good to know what exact package you've got, down to the dependencies
<dongcarl>Helps with debugging the edge cases
<alextee[m]>yeah i prefer explicitness too
<alextee[m]>well, for now i'll make the packages depend on jack1 and think about it for a bit
<alextee[m]>thanks for the help
<dongcarl>alextee[m]: No worries!
<str1ngs>dongcarl: it's possible the current make-libstd++ could be used to install headers as well. so this could just be a small tweak
<nckx>alextee[m]: If JACK2 is fully compatible with 1, would it make sense to use jack2 as the default everywhere?
<alextee[m]>nckx: there is a loooong debate about this. a lot of people in the audio field are split about it
<alextee[m]>mainly because jack2 is in C++ and jack1 already works fine
<nckx>😃 as they are about almost anything.
<alextee[m]>but jack3 aims to fix this
<dongcarl>str1ngs: True. Going to put forth my current thinking on the ML
<nckx>JACK4 will be in JavaScript so everybody hates it equally.
<alextee[m]>there's also pipewire coming which hopefully will put an end to this alsa-pulse-jack mess lol
<str1ngs>dongcarl: sounds good. I'm not confident we have a set fix. but atleast there is a better overall understanding. I think the libstdc++ gcc ouput is the best approach. but I don't know what impact that might have on guix toolchain as a whole.
<nckx>alextee[m]: Thanks for the overview! I'm not a pro audio buff but I do like to play around with synths, and I'm afraid I've heard plenty of criticism about PipeWire too. Ignoring lessons learnt, not listening to audio people, etc. I hope it really does outcompete the current mess.
<alextee[m]>well, let's hope lol
<alextee[m]>there's this talk from a month ago by the main jack maintainer, and the main pipewire developer gave a small intro at the end
<alextee[m]>it sounds like they're starting to take in the feedback/criticism and improving
<alextee[m]>but its current API is unreadable and undocumented so i can't tell lol
<dongcarl>str1ngs: Very useful:
<dongcarl>Seems like clang assumes too much about your gcc installation
<str1ngs>dongcarl: is there a way to bypass libstdc++ being hidden. ideally I just need to compute a libstdc++ output
<dongcarl>str1ngs: try using my manifest in that ML post
*civodul likes the new RYF web site:
<str1ngs>dongcarl: hold on while gcc builds! :P
<str1ngs>dongcarl: I guess (make-libstdc++ gcc) creates a derivative ?
<dongcarl>str1ngs: Right
<str1ngs>dongcarl: this is where an output would be better. since it only needs to build gcc once.
<dongcarl>str1ngs: True
<bavier>civodul: oh neat! looks nice
<nckx>alextee[m]: Thanks for the link. Not saying the criticism is warranted, just that the universe's audiophile background noise won't be silenced that easily.
<str1ngs>dongcarl: --with-gxx-include-dir should install to that prefix . so I'm wondering if thee make target need to be overwritten in make-libstdc
<str1ngs>as should install headers
<dongcarl>str1ngs: Right, but take a look at where GCC_INSTALL_PREFIX is pointed
<dongcarl>Maybe I'm misunderstanding what you're saying
<jonsger>oh the TalosII is now RYF. So I need only to wait some time until by Blackbird becomes RYF :P
<civodul>bavier: much clearer than before; it'd be nice with even more products, but it's already an improvement!
<str1ngs>dongcarl: right, though as it documents it using that to find startup libs.
<str1ngs>dongcarl: also Clang will detect the best version of libstdc++ headers available and use them - it will look both for system installations of libstdc++ as well as installations adjacent to Clang itself. quote
<str1ngs>dongcarl: maybe a symlink the right include output is enough in the clang output
<dongcarl>str1ngs: Symlinking might be a good way to try things out
<dongcarl>Gotta experiment
<str1ngs> GCC_INSTALL_PREFIX might not fix evertying I think it assume a complete gcc. not partial why probably gcc-libs is used
<dongcarl>str1ngs: right, we need to point GCC_INSTALL_PREFIX to a complete gcc
<bavier>we should see if we could get Guix listed in ThinkPenguin's "supported distributions"
<roptat>civodul, I think the overdrive is back online
<roptat>and I posted new patches :)
<jgibbons[m]>I am trying to mount a thumb drive with the exFAT format.
<jgibbons[m]>I installed exfat-utils and fuse-exfat locally but that doesn't work.
<jgibbons[m]>Do they need to be installed system-wide?
<nckx>jgibbons[m]: exfat-utils isn't needed to mount. Define ‘doesn't work’: you ‘[sudo] mount.exfat /dev/foo /bar’, and…? Anything useful in dmesg?
*nckx doesn't have an exfat handy to test but it used to work.
<jackhill>I added fuse-exfat to my operating-system config, and that allowed me to mount exfat through udisks and gui tool, so system-wide
<jackhill>I decided to do that not because I tried it as a user and it didn't work, but because I wanted it to work system-wide, so it was the first thing I tried :)
*nckx completely forgot about GUIs 😃
<jackhill>heh :)
<civodul> <- looks like this application passed?
<jgibbons[m]>From the command line it works. But it didn't work when I tried it with gnome-disks.
<jgibbons[m]>Now it's working.
<jackhill>jgibbons[m]: woo! what did you end up changing?
<jgibbons[m]>It could be that guix reconfigure finished with those packages added system-wide.
<jgibbons[m]>Or it could be that I launched from bash instead of clicking the "disks" icon.
<nckx>civodul: Cooool! …now what does that mean?
<civodul>nckx: i wonder!
<civodul>i think Pjotr and/or Pierre applied maybe?
<civodul>we'll see
<civodul>sounds like it might be good news anyway!
<nckx>civodul: Aha indeed.
<jackhill>jgibbons[m]: That could be. if I remember correctly, GNOME won't pick up new (or upgraded) items in a user's default profile unless it is restarted. If GNOME is running in X (which is is currently in Guix), that can be done without logging out by Alt-F2 and the pressing r and return.
<jackhill>When we get wayland GNOME working that will not longer work. It would be cool to have better GNOME/Guix integration.
<bavier>has anyone looked at upgrading our gnunet package?
<str1ngs>I was talking with pierre not to long about ipfs support. that's pretty exciting
<nckx>bavier: I was just ’looking’ (literally). I'm not up with current GNUnet development, though; are you?
<bavier>nckx: not much lately, but reading the recent release news seems like it'd be nice to get on 0.11.*
<bavier>the ipfs mention reminded me that gnunet had also been thrown around as an option
<nckx>Yes. I'd prefer to see GNUnet-first, but that's just an opinion with no work behind it.
<bavier>but if the ipfs work could be done with a gnunet alternative in mind, that would be nice
<bavier>I would also like to see gnunet first, but have little time to put behind it
*bavier afk for a bit
<ng0>bavier: if you have build time questions which aren't explained by the pkgsrc-wip package and the documentation, sent an email and I'll get to it as soon as I can :)
<bavier>ng0: great, will do. I was hoping you'd still be available for assistance :)
<ng0>I'd update it if I had the time. Great to read someone else is willing to do it eventually
<elais[m]>Ok I have a question: are chrome multitouch drivers free software? If so would anybody mind helping me generalize my package of them with a code review and advice 🙂?
<ng0>you'll find Nix patching something which they shouldn't patch, don't copy that patch
<ng0>I'll need to get in touch with them to find a proper solution
<elais[m]>I should probably ask this in the mailing list *if* they are free drivers.
<ng0>like they just went wholesale replace on the sourcecode without reading why the other thing was used
<elais[m]>* I should probably ask this in the mailing list *if* it is a free driver.
<elais[m]>* Ok I have a question: is the chrome multitouch driver free software? If so would anybody mind helping me generalize my package of it with a code review and advice 🙂?
***apteryx_ is now known as apteryx
<nckx>elais[m]: Your message doesn't have to be perfect 🙂 What do you mean by ‘chrome multitouch drivers’? Chromebook? Something else?
<nckx>Both my ThinkPad's touchpad and -screen support multitouches on Guix System using libinput, and I assume the older ‘synaptic’ driver supports it as well. Both of those are free software.
<elais[m]>nckx chrome has an xf86-input-driver that's optimized for Chromebook touchpads. It comes with xorg conf files that are optimized for many older Chromebook models.
<nckx>So ‘chrome’ = ChromeOS?
<elais[m]>Yeah. Sorry.
<nckx>elais[m]: If it's this <>, it looks like free software, but I don't actually know nothin' about ChromeOS.
<elais[m]>Yeah. It's that right there
<nckx>elais[m]: By the way, don't be too afraid to ask ‘is X free software?’. That's not ‘promoting non-free software’ in my book.
<nckx>It happens regularly that people submit a patch and that something about it turns out to be non-free. It happens. I recommend sending your patch for review to guix-patches at, or, if it's really rough or you're unsure, to guix-devel at
<nckx>It's much easier to review patches over e-mail.
<elais[m]>Ok thanks. I will send it to guix-devel because I need to know what the cleanest way is to let users choose which xorg config they use. Right now I've hardcoded in the configs for the Chromebook pixel.
<nckx>elais[m]: Okido. And thank you very much for contributing!
<nckx>Out of curiousity: that repository is old (2015). Are you packaging a more recent port?
<elais[m]>Sort of. I'm packaging the galliumOS fork.
<elais[m]>I'm not sure if Google is still doing more than maintenance on this driver at this point. ChromiumOS has moved on to Wayland via sommelier
<nckx>Maintenance is fine, as long as it keeps working on new kernels.