<nckx>that's the best Hurd joke I've seen in a while.
<nckx>quiliro: Yes, of course, this is not at all unreasonable.
<nckx>dkorzhevin: I agree that it's not the perfect place to put it (and AFAIK all the maintainers actually agree on that). gnu.org was not an option. I assumed it would be posted on *all* project sites, not just Guix, since it's not a Guix thing. However, that was my mistake for making assumptions. It's a minor issue.
<vagrantc>gotta say, there have been a few occasions where i really feel like guix is the right group of folks to have fallen in with in the gnu project
<vagrantc>and that blog post is definitely a re-affirmation of it :)
<dkorzhevin>nckx, how many maintainers GNU Project have now?
<nckx>dkorzhevin: Several hundred, I've been told.
<jlicht>nckx: would it be possible to add the disclaimer that Ludo' put in the email as a footnote to the statement, or perhaps somewhere linked to and reachable from the statement?
<nckx>Which makes the claim that the statement pretends to speak for all of them quite strange.
<nckx>jlicht: ‘The mail’ — you haven't seen my inbox today, have you? :-/// Could you elaborate?
<jlicht>The "for lack of a better place" statement, on why it was posted to the Guix blog in the first place
<jlicht>nckx: also, did you not become a part of the maintainer collective pretty recently? If so, congrats + TRIAL BY FIRE ;-)
<nckx>jlicht: Oh. Well, I'd prefer seeing it cross-published (for visibility, a disclaimer weakens the point instead of strengthening it), but there might be good reason for that. I don't know. & obviously I won't do that unilaterally, and Ludo's gone to bed, so it won't happen tonight.
<nckx>jlicht: OH GOD YOU DON—sorry—'t even want to know.
<vagrantc>Nardos: hi! do you have more specific questions? i don't know much about the specific outreachy projects, but i know a little about guix ... and there are others here too :)
<Nardos>Hi Vagrantc! I am installing it as a package manager on Kali linux, and I am having difficulties. I have downloaded the file - giux-binary-1.0.1.x86_64-linux.tar.xz. but while verifying I am getting this message. Gpg: no signed data. Gpg: can’t hash datafile:no data.
<vagrantc>Nardos: what's the exact command you're running?
<vagrantc>Nardos: you need to download both the .tar.xz and .tar.xz.sig into the same directory
<nckx>Nardos: Don't hesitate to keep a list of anything that wasn't clear about the documentation. It's impossible to write something that's clear to everyone (and still readable), but I'm sure we can do better.
<vagrantc>with that particular issue, it says to download the .tar.gz in the prose text, followed by an example of downloading the .tar.gz.sig ... seems like may as well move both into the example
<nckx>(Nardos: As you've probably noticed, #guix is quite calm during the European night.)
<Nardos>but now that i have you two, where do I start with packaging? any recommendation on where to start?
<vagrantc>ouch, tests for new version of u-boot require both python 2 and python 3 ... and some python libraries need to be available for both versions ... is that possible for a single package defintion?
<nckx>Nardos: Do you have any packages in mind? I'd recommend ‘classic’, simple C tools that use the GNU build system (autoconf &c.), but I think that's just my personal bias. If you're lucky, the ‘guix import’ command can do a lot of work for you. Have you read the packaging tutorial (https://guix.gnu.org/blog/2018/a-packaging-tutorial-for-guix/) and the manual section on packaging?
<nckx>Sorry to be so vague, packaging is often… a journey of discovery. It's never obvious which packages will be ‘interesting’.
<Nardos>I am actually reading the tutorial right now.
<nckx>vagrantc: I'd be optimistic enough to give it a try.
<mange>If you use Emacs, it's often pretty straightforward to package things from MELPA. You just have to make sure to change the source to not point to MELPA itself (because those sources are unstable).
<rain2>if guix cares so much about inclusion why did you let thaht guy bully me off of contributing for helping somebody set up gnu linux libre
<jlicht>silly question: How would I copy the gnulib sources into a project which does not have them checked into their git repo? Would I simply copy them over in a phase added after 'unpack, or is there some other (better) approach I can take?
<aitzkora>somebody remembers the url for downloading the script to install guix, i do no see on the website, it must be evident....
<civodul>WaitTraits = boost::asio::wait_traits<std::chrono::_V2::steady_clock>; Executor = boost::asio::executor]’ will change in C++17 because the exception specification is part of a function type [-Wnoexcept-type]
<civodul>C++ programmers must have extra wide screens
<Gamayun>Hmm... Compiling guix-package-cache.drv fails when running guix pull.
<brendyyn>str1ngs: Hi, I'm curious about your progress on qtwebengine. You said there it works but there is difficulty getting it to fit Guix's standards?
<truby>bdju: I guess actually if you have a raspberry pi 3 you could try using guix system with the UEFI port for it? Although I find that there's not many substitutions available for aarch64 which might be a problem on lower performance chips
<truby>(guix pull takes a long time even on this system and this has 64 cores)
<bdju>I do not personally own a raspberry pi 3, I have a zero w that hasn't had much use. if I knew something had good support and was somewhat powerful, I would probably buy it to put guix system on
<civodul>truby: do you get substitutes for at least some of the "guix pull" derivations?
<bdju>the rockpro64 looks appealing hardware-wise (also aesthetically) but I have held off getting one since I don't know what the software support is like
<truby>civodul: I'm not really sure how I would tell, I get substitutes sometimes when I install stuff with guix install, but guix pull usually takes at least half an hour
<nckx>rain2: I've searched the #guix logs back to 2018-08, and read all your messages and responses, none about linux-libre or even negative. Did this happen on a mailing list? All lists are archived at <https://lists.gnu.org/archive/html/> but unfortunately not very pleasant to search. I searched help-guix without success.
<bdju>I am concerned with thermals after intermittent thermal throttling with my thinkpad during video playback in recent months
<bdju>but maybe it would suck for it to be too loud also
<nckx>I don't know much about aarch64 but I assume the performance is proportionally related.
<nckx>bdju: It's not… loud, per se, and not louder than your average ATX [er, nckx shows their age] desktop (maybe even quieter; I have two). Having seen the tiny fans I'm almost impressed by the low frequency.
<truby>so I am getting some substitutions in my guix pull. But yeah, it's not super fast :-)
<truby>usually it's only really slow when guile gets rebuilt
<truby>I don't seem to get any substitutions for the "*.drv" things that guix pull builds, just some of the dependent packages. Would you normally get both on x86?
<peanutbutterandc>Hey there. I have installed `glibc-utf8-locales` and `glibc-locales` and also set GUIX_LOCPATH to "$HOME/.guix-profile/lib/locale" and yet I am getting `guile: warning: failed to install locale`. Does anyone have any ideas? The issue doesn't manifest itself for root user, only for other users ('foo'). And I have neither installed the locale packages nor set GUIX_LOCPATH for root.
<nckx>truby: It's hard to say exactly, but at least some and certainly not all should usually be substituted.
<peanutbutterandc>Another question then: Is there any guix command that one can use to build profiles for a particular user? For now, I have had to login as a new user, and run something like `guix install hello` and it sets up the profiles for the user. It would be nice if we - foreign distro users - could have a hook that we could run with the creation of every new user that would also generate the guix profiles for them
<peanutbutterandc>truby, I just installed the packages for root as well and it didn't solve the issue. :/
<peanutbutterandc>`cowsay` (installed with guix) works well for root but throws following error for `foo`:
<iyzsong>i don't know such a hook exist.. but you can debug the locale issue with: install and run guile (guix package -i guile; guile), if it warns, check GUIX_LOCPATH and the locales packages. If not but 'guix' warns, then check the user that run 'guix-daemon'.
<iyzsong>peanutbutterandc: try set LANG to 'en_US.utf8' (look at the directory of locales, we don't have C.UTF-8 there)
<peanutbutterandc>iyzsong, Whoa! I `$ unset LANG` (as root didn't have $LANG set to anything) and it works! No more warnings!!! Thank you! (:
<nckx>peanutbutterandc: Support for anything like ‘useradd’ hooks seems very distro-specific and ad hoc, not to mention it would only work for that command. As for Guix, I'm unaware of a ‘profile init’ command but you could hack around that by either installing a single programme or using an empty manifest (packages->manifest '()) or probably more ugly hacks.
<peanutbutterandc>peanutbutterandc, A `profile init` yes! Precisely that! It'd be nice to have that. empty manifest sounds like it's a bit neater. I'll try that once I get to that section in the reference manual. Thank you!
<roptat>truby, I don't get substitutes for "guix pull" very often, because the build farm probably didn't have time to build them, so I give a look at ci.guix.gnu.org to see what commit has been built and use it in "guix pull --commit="
<roptat>truby, also if you're the first person to ask for a substitute, it's not served right away, it has to be baked first, so you may want to stop a guix pull when it starts building stuff and try again a few minutes later
<str1ngs>brendyyn: also there are locale issues. since QT assumes that qtwebengine should be installed into the same prefix as qtbase. Which is not the guix way either. there are hacks to get around this. but nothing I'm 100% satisfied with yet.
<CcxWrk>nckx: Finally gotten around to looking, the libc patch was to support better password hashing scheme at the time (namely blowfish), other than that it's standalone set of NSS/PAM modules. I'm looking at musl handles it right now and likely we can go with SHA512-based crypt() instead.
<str1ngs>it would not be possible to use ungoogle-chromium. since QT already has a rebases/patches etc. also keep in mind qtwebengine is essentially a QWidget so there is much difference code base
<bavier>it doesn't seem like a great situation to me, but that's how it is, I guess
<str1ngs>ungoogled-chromium is nice, but it was designed for chromiumn only not for qtwebengine. they don't do the same thing.
<bavier>from a distribution POV, another giant package full of security issues.
<bavier>str1ngs: right, but I could imagine it'd be possible to reconcile the differences
<str1ngs>I'm sure it's possible, is it practical no I don't think so
<truby>is there an easy way to append the set of configure flags used by another package to a package I'm trying to write? I couldn't work out how to get the relevant info out of (package-arguments ...) but that's likely just because my scheme skills are lacking :-)
<nckx>truby: (substitute-keyword-arguments (package-arguments the-package)) wait we've been here before.
<truby>sorry, it's not quite the same question :) I am writing another separate package and I want to include the configure-arguments from a different package
<truby>perhaps the answer is exactly the same though and I'm just not smart enough to realise heh
<nckx>truby: I think the answer is the same, though, hence my confusion.
<davexunit>anyone here using the freecad package? seems that it cannot be built right now due to a issue with the source hash of the coin3d package.
<nckx>truby: Smart don't enter into it 🙂 Yes, it doesn't matter whether you use it with (inherit …) or not. ‘the-package’ is an explicit, straight use of the package record in both cases.
<bavier>substitute-keyword-arguments will give you other keywords other than #:configure-flags. To extract just #:configure-flags, I think you can do something like (cadr (memq #:configure-flags (package-arugments other-package)))
<truby>ok, I guess I need to understand better what substitute-keyword-arguments does :) I didn't end up using it in the other case because the package didn't actually have any configure-flags to start with so it didn't work
<bavier>davexunit: I saw yesterday mention that the origin points to a moving github archive
<bavier>nckx: if (package-arguments foo) also contains e.g. #:phases, the substitute-keywords will include that also
<truby>The context for this is that in the llvm.scm packages, the flags used to build llvm need to be used for everything else as well or you end up with issues sometimes. E.g. clang sometimes segfaults for me because llvm is built with -DLLVM_REQUIRE_RTTI and clang isn't
<nckx>davexunit: Could you explain how it still fails?
<nckx>davexunit: I thought I fixed that coin3D thing already, with all the nonsense y'day I don't remember.
<truby>bavier: it's complicated :). There's two separate issues here: 1. every LLVM project takes the same cmake flags and expects to be built with the same cmake flags as the LLVM you're building against. 2. if you link against _any_ library that is built with -fno-rtti you also need to build with -fno-rtti, or vice versa. and there are clang tools that do not build with -fno-rtti which is why the llvm package currently turns RTTI on
<nckx>It was just misleadingly named coin3d-4.0.0.zip 🙂
<truby>(n.b. debian and arch linux for example also build llvm with RTTI enabled so it's a perfectly sensible thing for the package to do)
<truby>but, if you build LLVM proper with RTTI enabled all the other LLVM projects also need to be built with RTTI enabled. And any other flags that LLVM specifies preferably
<bavier>truby: good to know, thanks for looking into it :)
<truby>I'd be happy to fix this up and submit a patch (and I'm currently sitting on a patch fixing clang++ in guix) but I have to wait for legal approval to submit changes as I did this stuff on work hours :(
<truby>I've also written a make-clang-toolchain function that lets you pick a gcc version to find the c++ standard library from, but that needs cleaning up a lot before I'd be happy sharing it :P
<Snai1>hello, i'd like to build a program with guix without create a new definition of package but still have it in the /gnu/store directory. I mean somenting like `guix build source.tar.gz`. Do you know such a command? thanks
<nckx>truby, bavier: The closest I can get to something that would make it into Guix is (cons "--foo" ,(match (memq #:configure-flags (package-arguments bar)) ((#:configure-flags flags _ ...) flags)))
<str1ngs>how can I enforce a rebuild. adding a search-path field does not seem compute a rebuild for some reason.
<nckx>Snai1: Hi! Guix can't build a tarball without being told (for example) which build system it uses, or what the store file name should be. That's really all a package does (+ some useful metadata). You can save this information to a separate file and use ’guix build --file=…’, but that's writing a package.
<nckx>str1ngs: It doesn't change the result so there's nothing to rebuilt. Search paths only affect how a profile with that package in it will behave.
<str1ngs>~/.guix-profile/etc/profile does this though. a common example is PATH. I thought search-paths did this
<nckx>Unless it happens to be a path itself, then perhaps you can abuse^Wconvince the search path mechanism to set one.
<str1ngs>also wrap binaries which I can't use for this
<nckx>str1ngs: I was just about to say: The way to do this is wrap-program.
<str1ngs>I could maybe wrap this. but it adds an extra layer of abstraction I'd like to avoid
<nckx>str1ngs: AFAIU, (native-)search-paths defines the paths (environment variables) that a package *consumes*. It cannot set variables; Guix sets variables for any package that provides a directory matching the pattern.
<mbakke>string: adding search paths to a package won't change its derivation, only dependent derivations (such as your profile) :-)
<str1ngs>I'd like something like gits GIT_EXEC_PATH
<str1ngs>mbakke: I'm find if it does not rebuild. but I guess I need to make sure it is working though
<str1ngs>my understaind is the new expression would use native-search-path but only in the context of environment and profile?
<nckx>So if your foo package defines (native-search-paths … FOOPATH … "foo/plugins"), *Guix* will construct a $FOOPATH variable that contains all the /foo/plugins directories it finds, but the foo package itself is not actually setting or doing anything.
<roptat>when we build an installer image, we use a version of the guix distribution that embeds a different version of the set of packages, so at least a few packages can differ between what the installer wants to install, and what it already has
<verbasidor>because sometime you can configure networking unless after installation
<nckx>verbasidor: The installation medium simply does not contain everything that will/may be needed for the end system.
<verbasidor>hmm isnt that the case for every operating system?
<roptat>verbasidor, what I can suggest is that you install another distro instead of Guix, install Guix as a separate package manager and use the "guix system init /etc/config.scm /" technique to install Guix instead of the distro
<roptat>then you'll have network access during system installation
<roptat>verbasidor, not all of them, but a large majority still
<nckx>verbasidor: No, most distributions don't require network access during installation. That requires a radically different installation (simply unpacking prefabbed archives instead of building a system) method than Guix uses now.
<verbasidor>i see , sorry but this is crazy i didnt think of a distro that internet while installation is mandatory
<roptat>we're doing things very differently from other distros, so that creates a few limitations
<nckx>verbasidor: Like roptat, I think Guix is perhaps unusual but certainly not alone. Plenty of other distributions do this too.
<nckx>It has some nice advantages too. No need to debug an entirely separate code path that ‘deploys images’ or whatever.
<roptat>it also gives us a lot of advantages that largely balances them though
<janneke>verbasidor: do you have a bug number or title of your bug?
<verbasidor>add ability of modifying connection before installation
<roptat>actually, maybe if we pulled the version of guix that created the image right after creating the image, and distribute that, the image would be able to build itself without requiring network access