*nckx notices that they confused bavier and roptat above, bit late now. Ta, roptat. <nckx>Into the corner of shame I go, I guess. *nckx brings gnu-shaped biscuits & tea. <roptat>It's a bit crowded over there :) <quiliro>i received this private message from civodul: <quiliro>"i saw you asked about the blog" "there's a guix-blog@gnu.org alias" "however, we're not going to use the blog to have statements from everyone, as you can imagine" <vapid>removing the abort joke makes sense; i don't think the emacs virgins part was that offensive though <quiliro>so that means that Guix is not representative of its users, just of a hierarchy (we as civodul says) <vapid>i feel like people are either too easily offended these days or are just hunting for good boy/girl/other points from their own social bubble <quiliro>I think Guix is not the project I thought it was. <nckx>quiliro: I think we've been over this. The Guix home page does not reflect or aggregate opinions from (parts of) the Guix user base and it's not the right place for that. <quiliro>i will ask all references of me to be removed from the guix website and forums <nckx>That change.org page is hilarious. *nckx gets out the conspiracy bingo cards. <nckx>quiliro: Your name does not appear on the Web site nor do we have a forum. So… done. <nckx>quiliro: Those mailing lists aren't run by us. <quiliro>help-guix, bugs-guix and maybe devel-guix <nckx>I guess the GNU sysadmins? <dkorzhevin>Hilarious is that "Joint statement on the GNU Project" listed on subproject page <dkorzhevin>I can't recall that guix represents "GNU Project" <nckx>dkorzhevin: It also doesn't make much sense. ‘…given the speed… contrary to the spirit of GNU’. <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. <jlicht>it keeps you busy and off the streets, at least <nckx>The statement was already drafted when we joined (of course we were consulted), so I don't know any of the planning involved. <jlicht>I was referring to dealing with the influx of reactions to the statement <jlicht>Is core-updates still being merged? <nckx>Oh, I know 🙂 I actually cleared my schedule for this sh*t. My partner was not amused. So make that another person who has a great impression of GNU now. Well done, everyone! <nckx>jlicht: Yes! civodul merged master into c-u today. <nckx>So unless CI. catches fire we're good to go. *vagrantc has been running core-updates+merging master for a couple weeks now <vagrantc>which i'm excited for, as the only two dependencies left for guix in Debian are sitting in the NEW queue... indefinitely. <nckx>vagrantc: Is that like… core-updates for Debian? Pardon my noob. <vagrantc>nckx: e.g. the first time a package does into Debian it has to be reviewed, after that, any developer can upload it for the most part <mbakke>vagrantc: what packages are those? <vagrantc>the hardest one was guile-gnutls, but finally just nudged gently enough with enough patches and enough people that they finally reconsidered :) <mbakke>what is the hold-up on guile-git? <mbakke>I think civodul also overhauled the GnuTLS bindings recently. <vagrantc>mbakke: basically license review ... which should be dead simple. <jlicht>wait, this would mean 'apt install guix' would work? <vagrantc>mbakke: but it's a small number of people trusted with that processing <jlicht>that would help a lot in trying to subvert all of the CI-pipelines at work to actually use guix behind the scenes :-) <vagrantc>then, of course, guix itself will have to go through NEW for license review ... <nckx>And it would be great for my mother. \o/ *vagrantc is a little terrified about gnu/packages/patches* <mbakke>vagrantc: I'm really excited for 'apt install guix', thanks for all the work on that :-) <vagrantc>the licensing on guix is overwhelmingly clear overall, except for gnu/packages/packages/ <nckx>That had never occurred to me. It's absolutely true. <vagrantc>worst case, at least if all the dependencies are in debian, i can maintain a separate repository <mbakke>perhaps it would make sense to separate "upstream" patches from guix-specific ones <nckx>vagrantc: Can it not be reasonably assumed that a patch to x-licenced file y contains code under licence x by definition/default? Or is that too optimistic? <vagrantc>nckx: heavy on the optimism, at the very least :) <vagrantc>but we'll burn those bridges when we get to them! <nckx>Right, sure, but patches are never (IME) sent to mailing lists with an explicit licence header. <nckx>Not ones I frequent anyway 🙂 <vagrantc>i suspect quite a few debian packages have a debian/patches directory that is maybe leaning on optimism as well ... but with guix, the whole distro is in one package... <vagrantc>fwiw, "nix" was uploaded to Debian and has been stuck in NEW for 9+ months :/ <nckx>No argument there. It's also why optimism is, in a way, a more ‘realistic’ option compared to getting explicit permissions for 762 patches. <mbakke>we only have 762? not too shabby... *nckx coming to you over IRC-over-DNS again and lagging like hell, sorry. <nckx>No: IRC-over-SSH-over-DNS. <nckx>mbakke: I was expecting something more spectacular too. 🙂 <mbakke>I wonder what the Debian average patch-per-package is :) <nckx>That's much less than 1 patch per 10 packages. <vagrantc>worst case, i guess guix could split the patches out into a separate tarball or something weird like the bootstrap binaries <vagrantc>then it could be downloaded at run-time. <mbakke>that bootstrap binary trick still amuses me :) <jlicht>Would debian not reject the concept of bootstrap binaries? <jlicht>well, no wait, not the "concept", but rather "our concept" <vagrantc>debian would definitely shipping the bootstrap binaries <mbakke>jlicht: so instead of shipping them right in the source, Guix was patched to download the binaries from a previous revision of Guix instead <vagrantc>but the "download the bootstrap binaries" trick is one thing i've been waiting on to even consider trying to get guix into Debian <jlicht>I understand that; but why would that suddenly be okay? <vagrantc>well, you wouldn't expect a web browser to ship all of the web pages accessible on the internet? this is just a web browser. :) <mbakke>jlicht: because the won't be found by an analysis of the release tarball :P <vagrantc>it's technically (probably) compliant, though certainly skirting the grey areas of acceptibility <nckx>It's about the level of ‘downloading the DRM plugin’ letter-of-the-lawing but a lot less evil. <jlicht>"technically (probably) compliant", loving it <vagrantc>that's why i'm also very excited about GNU Mes and the bootstrappable stuff <jlicht>Seeing as the intent is to shrink the bootstrap binaries over time (right?), I guess it would be an informed compromise <nckx>jlicht: Reduce to a single ~682-byte (from memory; could be off) human-readable binary, even. <nckx>Something with most of those digits 🙂 <nckx>And heavily-commented (not included in the size), assuming you trust the comments ;-) <jlicht>I don't even trust my own comments after more than a month :( <jlicht>but still, I can already imagine some sort of undergraduate seminar where the assignment is to verify the bootstrap seed :-) <nckx>Well, it's better than trusting ~125 MiB of uncommented, machine-generated binaries. <nckx>Or are you comments really really bad. <jlicht>we use random container images where I work, if they were *only* 125MiB images I would be happy <nckx>jlicht: No Guix yet? You're our inside man, man. <jlicht>I actually started packaging a WAF and a IDS last week, and will be deploying them tomorrow (bar core-updates shenanigans) as a test-run :-) <jlicht>using Guix to build the images, not for deployments ***nckx sets mode: +q jmarciano!*@*
***nckx sets mode: -b jmarciano!*@*
<Nardos>Hello Guix, I am a new outreachy participant, and if anyone has time, I need help with setup. <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 <Nardos>but when i try to verify I get Gpg: no signed data. Gpg: can’t hash datafile:no data. <vagrantc>sounds like you're missing the .tar.xz ... <vagrantc>good, keep following the manual ... and feel free to propose fixes if there are things that aren't clear <vagrantc>a fresh set of eyes on documentation can be very helpful :) <Nardos>it is working now based on vagrantc suggestion. I completely missed that I needed to download the .tar.xz file as well <Nardos>i will keep an eye on the documentation. <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>Vagrantc: it would make sense to add it. <Nardos>Nckx: I was wondering why it was quite. <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). <Nardos>nckx: I am willing to try anything that will get me started. <nckx>Actually, that goes for emacs importer defaults as well. ‘Here's the URL. Never use it.’ 🙂 <nckx>vagrantc: Requiring Python 2 & 3. Maybe it's a normal thing in Python land. <vagrantc>i know the official specs recommend against using "python" and instead calling "python2" or "python3" ... but i seem to get the impression that the PYTHONPATH is indiscriminantly set <nckx>Nardos: Is there any little tool you like to use on other distributions that's missing in Guix? <vagrantc>as usual, the upgrade to u-boot builds fine on all the platforms, but u-boot-tools fails tests left and right, which ... most of the tests aren't even for u-boot-tools. <nckx>vagrantc: I really thought we versioned those variables. If not, it was suggested and never merged, and I'll shut up about Python. But I'd be suprised. <vagrantc>nckx: i vaguely recall mention of that now that you bring it up <nckx>5 a.m. here, daytime in the US, #guix hasn't burnt down, cross fingers until the next op comes on-line I guess. <Nardos>Vagrantc: thanks again for your help. I am about to exit as well. *vagrantc waves to Nardos <bdju>it flashes white on the screen for a split second only <mange>Well, I can very unhelpfully say "it works for me". <bdju>I think that makes 2 "works" and 2 "doesn't work" that I've heard now <bdju>I've got a few sketchy things in my install that I don't have confidence in, would be nice to get that figured out someday <bdju>like ssl issues with some stuff, dbus issues with some stuff. none of it quite making sense <mange>Does `guix environment -E DISPLAY -E XAUTHORITY --ad-hoc next --pure -- next` fare any better than just running `next`? <bdju>am I to run that literally or should DISPLAY be :0 or something? <bdju>guix environment: error: next: unknown package <bdju>hm thought they renamed sbcl-next to next, but now I see the opposite. wonder if I somehow moved to an old guix <mange>Actually, that command didn't work for me. I think it's still missing an environment variable or something. <bdju>agh is there really not a search for the package list on the website <mange>Okay, `guix environment -E DISPLAY -E XAUTHORITY -E DBUS_SESSION_BUS_ADDRESS --ad-hoc next --pure -- next` worked for me. <bdju>still getting the same error <mange>I assume you've tried with -Q? <bdju>no, but that doesn't work either <bdju>did a quick guix pull and applied my manifest. still can't launch next <bdju>mange: I'm on wayland, I tried the suggestion of unsetting WAYLAND_DISPLAY when launching next and now it works <bdju>I wonder then what I'm supposed to do longterm and if that is a bug <mange>It could be worth opening an issue against Next itself? That doesn't sound like a Guix specific problem. *kmicu is positvely surprised about calmness on #guix <roptat>kmicu: does it mean people are asleep now? ***freedom_ is now known as freedom
<shrdlu68>My system config is just the base-config in examples. The same config worked perfectly in a local qemu VM. <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.... <kmicu>Hi rain2 could you elaborate please? Helping someone with Linux-libre setup should not be discouraged here. ***daviid is now known as Guest16914
<mbakke>civodul: I don't have any more 'core-updates' blockers :-) *civodul hits the "merge" button for real today <civodul>mbakke: thanks for the MariaDB hot fix for ARM! <civodul>hopefully you can post the article today! <civodul>basic_waitable_timer.hpp:698:3: warning: mangled name for ‘typename boost::asio::async_result<typename std::decay<_U1>::type, void(boost::system::error_code)>::return_type boost::asio::basic_waitable_timer<Clock, WaitTraits, Executor>::async_wait(WaitHandler&&) [with WaitHandler = std::_Bind<void (mpdclient::*(mpdclient*, std::_Placeholder<1>))(const boost::system::error_code&) noexcept>; Clock = std::chrono::_V2::steady_clock; <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 <civodul>i'll take a look hopefully today, but if you have any comments, they're very welcome <civodul>gentlefolks, "core-updates" has been merged! <roptat>now, I'd like to push my changes to mariadb (https://issues.guix.gnu.org/issue/37239) to a separate branch (it can't be master directly) and start evaluating (and hopefully merge) it more quickly than staging. Is that possible? <nckx>Yes, I came here to say ’yay core-updates’ 🙂 <civodul>roptat: it's certainly possible, maybe to 'staging' though you'd have to check the status <civodul>so yes, maybe you can make a topic branch and have it evaluated on berlin <truby>yay for core-updates :-) the pull is running on my aarch64 box now! <mbakke>roptat: I'm going to start a staging round in the next few days, I can push the mariadb patch at the same time? <bdju>truby: which aarch64 device are you using? I would like to run guix system on an arm thing in the future <truby>bdju: I'm not running guix system unfortunately (I don't control the machine) just running guix as a package manager on top of debian <civodul>bdju: the SoftIron OverDrive works well and it's easy to install Guix System on it <civodul>however, i think they were planning to discontinue it <bdju>oh wow, looks to be a rack-mount server <bdju>that is good to know, I am thinking more along the lines of an SBC to act like a desktop pc <civodul>ah well, the OverDrive 1000 has a regular case, it's not a server you'd put in a rack <civodul>but the 3000 (?) is indeed a rackable server <bdju>oh yeah I clicked on the 3000 <truby>the problem I've always found with non-server aarch64 stuff is just getting it to boot... since there's usually no UEFI or similar <civodul>the 1000 has UEFI, which is why it's easy :-) <civodul>but it's really a developer box, not something you'd use as a desktop machine <truby>fwiw the machine I'm on is a racked server as well, but as I said it's also not running guix system <truby>I still don't really understand why stuff like the raspberry pi doesn't have UEFI <truby>I mean, it works. You can get a tiano core based uefi for it that even lets you boot windows (not sure why you'd want to though...), it's just not officially supported <civodul>truby: regarding your aarch64 server, you could probably install Guix System with the "guix system init config.scm /" method if you felt like it <truby>I don't control the machine so that would probably make people unhappy :) <truby>much as I would like to do it! <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 <Gamayun>--> (exception unbound-variable (value "module-lookup") (value "Unbound variable: ~S") (value (python-sphinx)) (value #f)) <nckx>rain2: Hi! You are right: Guix cares a lot about inclusion. That doesn't mean anybody can (or must be expected to) permanently patrol all Guix communication channels. All Guix participants must abide by the <http://git.savannah.gnu.org/cgit/guix.git/tree/CODE-OF-CONDUCT>, though, and I urge anyone to get in touch when something nasty happens. <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. <nckx>(Maybe I just suck at searching :) <truby>bdju : It doesn't look like the rockpro64 has uefi :( <nckx>bdju: The 1000 is nice, if you don't care about having the quietest tiniest desktop. <bdju>hmm... not sure how much I care <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>there's nothing special about aarch64 relative to x86 on that front, if you want the same performance as an x86 desktop you'll be running at the same temperature (roughly) <bdju>well I want performance on par with a sandy bridge mobile i5 <bdju>in other words, not a downgrade from my thinkpad x220t *nckx kind of impressed it's (roughly) the same as x86. <bdju>I think it could be easier to cool just by not being crammed in a laptop case <nckx>bdju: Problem is, I suspect, all Overdrive keepers here host them as Guix build farm machines. We have no idea what they ‘feel’ like. I don't. ‘guix pull’ is slow, but then… ‘guix pull’ is slow. <truby>If I'm getting things downloading from ci.guix.gnu.org I assume those are substitutions <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. *nckx throws the empty tin of weasel words away. <truby>I'm obviously not expecting many substitutions right now anyway, as I assume stuff hasn't been built for core-updates yet :-) <nckx>peanutbutterandc: Welcome! Is this on Guix System or a ‘foreign’ distribution? <peanutbutterandc>nckx, This is a foreign distro. Actually, it's running on a docker container based on alpine <nckx>truby: Actually, the point of ‘delaying’ core-updates like that is to wait for the build farm to build it before it's merged back into master (which doesn't change the derivations, much). <nckx>peanutbutterandc: Ah, I'm afraid I can't really be of useful help with that, sorry ☹ <nckx>truby: But then, I never thought about whether that includes guix proper. You may well be right! <truby>peanutbutterandc: I found that I had to install the locale packages for root as well to make that warning go away (I didn't have to set the GUIX_LOCPATH for root though) <truby>I didn't really understand why that was I just did it and the warning dissapeared :-) <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>look like `foo` doesn't have 'locales' pacakges or GUIX_LOCPATH, or LANG is not match with them. <roptat>mbakke, ok, we can do that too :) <peanutbutterandc>iyzsong, I just install guile and ran it, but to no avail. $GUIX_LOCPATH is set and $LANG is currently C.UTF-8 <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 <truby>roptat: Its not something that really bothers me, I just have it run on a timer in the middle of the night :-) <truby>I'm only running it manually today because of core-updates \o/ <peanutbutterandc>nckx, Sorry to trouble you again but could you please tell me what an empty manifest file looks like please? I just wanted to try the hack out <nckx>peanutbutterandc: (use-package-modules guile emacs) (packages->manifest '()) ; works, don't know if it's the shortest form. <nckx>Wait, without the use-package, of course. <peanutbutterandc>nckx, I tried it out but I get this error: 0f7dd7fe92da:~$ guix package --install-from-file=emptymanifest.scm <nckx>(It worked with the unnecessary (use-package-modules …) too.) <peanutbutterandc>nckx, It works without the (use-...) part. Thank you very much! This is awesome! <nckx>peanutbutterandc: You can use that manifest as a defaults skeleton if you ever so decide. Just never add ‘guix’ itself to it. <jlicht>The `news' feature is really nice with the core-updates changes! Does this core-updates merge also mean there will be a release soon? <kmicu>☇BREAKING NEWS☇ Our amazing IRC folks has reported that after recent core‑updates merge Guix has a news feature! <g_bor>I made a make check today, and it asked me for my private key passphrase in several tests. <g_bor>I believe it must be because I have in my global git config the option to sign commits. <nckx>g_bor: That's possible. So do I, but I use the agent (enter passphrase once after booting) and have probably never run checks before committing something. <g_bor>Do we have some way to arrange so that the git config does not iterfere with test? <jlicht>kmicu: were you being sarcastig, or are you actually impressed as well? :-) <nckx>g_bor: GIT_CONFIG_NOSYSTEM=1 HOME=/invalid XDG_CONFIG_HOME=/invalid git? (Untested.) <kmicu>jlicht: internet is confusing place so I always mark sarcasm with ⸮ (REVERSED QUESTION MARK aka Irony Mark). I am genuinely happy cuz that news feature is really helpful for (casual) users. <nckx>kmicu: ‽ is the true sarcasm mark you heathen. <kmicu>That’s interrobang and for sure that’s not sarcasm. <zimoun>hum? on fresh clone, I did: guix environment guix then ./bootstrap <zimoun>then ./configure --localstatedir=/var <zimoun>configure: error: Guile-JSON is missing; please install it. <zimoun>Why? I thought all the dependencies were included by "guix environment guix" <nckx>zimoun: I bootstrap from an ad-hoc environment that contains guile-{gcrypt,git,json,ncurses-with-gpm,ssh} (some of those might be obsolete). <g_bor>nckx: ok, I will have a look if that helps, and I believe we should incorporate that into our test suite, so that guix is tested, not the user's git config. <nckx>zimoun: Actually, I don't anymore, this is an old script. You're right, I use --pure guix. <kmicu>Did you discuss that news feature on the mailing list? I don’t recall anything. <kmicu>Thank you. I must start reading more carefully then. <nckx>kmicu: It was also mentioned in ‘guix pull --news’! Geez. <zimoun>nckx: hum? without adding by hand guile-json, I still have the error <nckx>zimoun: And if you add it, it works? <civodul>kmicu: i was planning to write a blog post about it because i find it pretty cool <civodul>(and not just because i was involved in its implementation :-)) <zimoun>nckx: argh! I did 'guix pull' and something was twisted. After re-sourcing, it works out-of-the-box as expected. <kmicu>civodul: It looks like that’s your baby. Thank you so much. <civodul>janneke: BTW, are you able to push the blog post? this would be a good time :-) <kmicu>I see #:use-module (guix colors) so I assume the news features supports formatting so we can make important/breaking changes show in bold red in the terminal (like in Nix(OS)). Cool. <g_bor>nckx: no problem, I will add an entry to my todo list. <civodul>kmicu: Nix/NixOS has a news features? <civodul>there's almost no coloring for news because it's just text (actually Texinfo) <civodul>but the headlines show up upon "guix pull" completion <civodul>i'm actually seeing a build issue with the web site :-) <kmicu>civodul: Nix(OS) shows messages about upcoming breaking changes, depracations, etc in redish color during update so a user can easily spot and fix config during usual update operations. <kmicu>(Maybe Nix uses deprecations for news… I didn’t see any messages longer than ~2 lines.) <civodul>janneke: it's in the build pipeline on berlin, hopefully done within a few minutes <roelj>Has anything changed with regards to SSL certificates in the R package? It seems that setting the CURL_CA_BUNDLE does not make R find SSL certificates.. <g_bor>I have a test failure on container-excursion. I just did a git pull to see if it fixes it. <str1ngs>brendyyn: yes it is in a working state. but removing all of the in source third party libraries is daunting work <g_bor>nckx: setting the environment for git like you described avoids the prompts, but makes 4 tests fail. <g_bor>The reason of the test failures is that no user email can be extracted. <str1ngs>brendyyn: I have used guix dependencies were possible but that is not enough for guix standards <g_bor>Maybe we could set up a fake home for these tests to work. <nckx>g_bor: so Guix should ship (or generate) a little gitconfig and point one of those variables to it. <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. <civodul>janneke: could you send a heads-up to the list? <roptat>" We those seeds to weigh in at ~550MB" -> what does it mean? *janneke will amend, thanks! <jlicht>"from the bootstrap lateron." -> seems to be missing a space <roelj>That's some serious awesome work janneke! :D <jlicht>but this is amazing! I never expected it to actually be deployed to real-world systems this quickly when I first heard about the Mes project some time ago <roptat>and "we need no longer depend on" might me missing a "to" :) <roptat>unless it's an English construct I'm not familiar with <janneke>civodul: eh sorry my being green; which list? <janneke>roptat: yeah, i think it's fine...but i'm also not a native speaker <civodul>we're finally running code that builds upon all your work! <civodul>someone should send it to HN and all *dongcarl steps out of the bath mid-shower <g_bor>The pull solved the container test failure for me. <g_bor>Now I only have the git related ones. <janneke>dongcarl: thank you! and yes, i'm hoping for a release soon <dutchie>i've had this fail a few times since i pulled this afternoon (after the core-updates merge), any hints? or should i just go file a bug report <nckx>nss-certs is (or at least was) known to have some weirdly-encoded file names that have broken Guix before. Maybe? <nckx>dutchie: If it's reproducible, please do. <nckx>dutchie: Thanks! Although reproducible on one is enough. More data can only help. <dutchie>it'll take a while to get there by the time it's downloaded everything else i expect <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. <nckx>CcxWrk: Right, I remember 🙂 Sounds good. <nckx>As annoying as it may be, I too must add my explicit thanks to the heap. Thanks janneke. This is really cool. <rekado_>I’m so glad this has finally been merged into the master branch! <joshuaBPMan>In procedure struct_vtable: Wrong type argument in position 1 (expecting struct): #<procedure mysql-service (#:key config)> <roptat>can you paste the complete backtrace to paste.debian.net? <brendyyn>str1ngs: I see so it's aleast free software? <str1ngs>brendyyn: yes it's free and already already un-googled by QT <bavier>str1ngs: I was wondering about that. Is it "un-googled" to the same extent that ungoogled-chromium is? or would we need to have the same review over again? <bavier>it's too bad there can't be more sharing, rather than each being it's own fork <str1ngs>bavier: to the same extent. I will find a reference for you <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 <nckx>bavier: (substitute-keyword-arguments (package-arguments foo) ((#:configure-flags fooflags) `(cons* "--bar" fooflags)))… <nckx>bavier: I don't understand your cadr'ing, I don't think it's necessary. <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>bavier: Oh, like that. Got it. <truby>for now I just copied the relevant flags over by hand which might eventually be what we want to do anyway <bavier>truby: is this anything that's built against llvm also needs those flags? or just clang? *davexunit is currently running guix pull <nckx>…there has to be a better way to do this… <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 <truby>(which is not the llvm default) <nckx>davexunit: The problem was simply that it pointed at a CI-generated master.zip-type thing. <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. <nckx>I.e. environment variables will be set based on which other packages in that profile provide /search/path. <nckx>But this doesn't change anything about the contents of /gnu/store/package-that-defined-the-search-path/. <truby>nckx: I'm not sure I understand this code, what is the match for? <str1ngs>maybe I'm not understanding search paths then. I need my package to set an environmental variable *truby realises how little he knows about scheme <nckx>str1ngs: That's not possible, I'm afraid. <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. <str1ngs>I guess I thought guix was functional in terms of the while expression. this is good to know thanks <str1ngs>nckx: mbakke thanks for the help. I now know that I need to use guix package -f ./foo.scm not guix build -f ./foo.scm :) <roptat>joshuaBPMan: can't check cause I'm on the bus, but I think it means mysql service <roptat>Because it doesn't have a default one <rekado_>joshuaBPMan: can you show us the configuration file? <rekado_>it says that you passed the procedure “mysql-service” to something that expects a struct. <joshuaBPMan>I tried (mysql-service :#config (mysql-configuration)). <joshuaBPMan>nevermind... I've been putting (service mysql-service) <joshuaBPMan>the info documentation says (mysql-service) not (service mysql-service-type) <bavier>does icecat disable desktop notification support? <joshuaBPMan>bavier: I've got icecat notifactions...the tor browser plugin notifies me... <bavier>joshuaBPMan: I've got a website that says "You've disallowed notifications in your browser", but icecat gives no such indication <nckx>raghavgururajan: (…and Maxim :) Thank you! And hi. <nckx>jje: How did you get there? <jje>guix pull that is all I did <nckx>That ‘(repl-version 0 0)’ leakage is weird, though. At least I've never noticed it. ***apteryx_ is now known as apteryx
<roptat>nckx, jje I've noticed it when there's an issue with a channel <roptat>are you using a channel, beside guix? <jje>yes pkill9 guix-free channel <roptat>try to pull without it, to see if that's the issue. If yes, report it to pkill9 :) <verbasidor>i want to install it without internet connection <roptat>you'll need to download what you install, or at least their sources <roptat>like, the kernel is a package for instance <verbasidor>so if someone want to install the distro then plugin the internet for it he cant ?? <verbasidor>all gnu/linux distro you can do that , why this one not? i dont get it <roptat>I don't think it's possible, but I might be wrong <roptat>it has to do with how the set of packages is defined in Guix <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 <roptat>I understand, but I have no solution for you :/ <verbasidor>differential of package versions cant be done with upgrades? <roptat>but you'll need network access for an upgrade <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 <nckx>‘Crazy’ it certainly is not 🙂 <roptat>verbasidor, but using the installer image is not the only solution, you can use any other running operating system (live or not) that can run guix to install the guix system <roptat>so if the installer image doesn't have what you need for internet access, you can use another distro that does <roptat>then use it to install the Guix system with all the configuration you need to make your network access work <verbasidor>its not easy to make guix compatible with other distros <janneke>would it be helpful to open a bug about this? <verbasidor>already done but no one responded thats why i came here after while <roptat>I don't see how we can solve that, but with more people, we might find a solution, I think it would be helpful <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 <roptat>it wouldn't be as stateless as we'd like, but it could be a trade-off we want to make, if it works <janneke>verbasidor: reading your bug report, i do not see a request for offline installation? <verbasidor>true , because the is GuixSD cant having an internet connection because i need to modify the IP,Gateway,DNS to manual set <verbasidor>since it doesnt has this feature , so another one can solve the issue is to modify things after installation <verbasidor>also according to Debian security advise to not plugin internet until after installation <janneke>verbasidor: i don't understand your problem yet; you can run ifconfig ...; route add ...; to get internet and install? <roptat>you can switch to a different tty and configure internet manually from there though <janneke>someone could have replied to that bug though, at least to ask for information. sorry about that verbasidor... <roptat>ip a add ... ; ip r add default via ... ; echo 'nameserver ...' > /etc/resolv.conf <verbasidor>janneke how to run ifconfig while cant pass GuixSD request for internet connection in order pass the installation ? <nckx>verbasidor: From a different VT. <roptat>verbasidor, you can switch to another tty with Ctr+Alt+Fx where x is between 2 and 6 <roptat>the login is root, with no password required <verbasidor>one question i have in mind is there any intended efforts to make GuixSD over Qubes? <verbasidor>it has now Debian , Fedora , Arch , Kali coming soon <roptat>I know what it is, I meant I haven't heard of anyone wanting to run guix on qubes <verbasidor>ah i see , it would be real awesome thing to have it there <dongcarl>Specifically, how we'll expose the -posix threading variant <nckx>verbasidor: Some Guix contributors have talked positively about Qubes here. Maybe someday. <janneke>i know that qubes developers took an interest in how guix does bootstrapping <verbasidor>janneke yes i can imagine in the near future Qubes can be based on guixsd <janneke>dongcarl yes, that needs attention -- does the nonstandard triplet approach work? i have no idea what might happen if you append `-win32' <nckx>janneke: Great point, I was typing the same thing as verbasidor. <nckx>Maybe not based on, but there's a lot more to Guix than just running it on top as yet another run-time. <verbasidor>btw why tar -xf cant detect guix.xz by terminal? <dongcarl>janneke: The nonstandard triplet approach can be made to work... I'm only hesitant because it is afterall non-standard :-/ <roptat>guix.xz doesn't sound like a tar achive? <roptat>so there's nothing tar can do about it I guess... <dongcarl>janneke: Perhaps the easiest approach for now is just to package the `-posix` variant as a package, and we can think about triplets later <verbasidor>roptat what tool to extract it then? xarchiver or what? <nckx>verbasidor: tar can only auto-detect compression when invoked as ‘tar xf ….tar.xz’, not ‘tar x < ….tar.xz’, maybe that's the problem? <nckx>verbasidor: Is it? Or is it an iso/image? <verbasidor>.iso.xz cant be detected as tar compression type <nckx>verbasidor: tar can only handle tar. <verbasidor>cant get to console to change tty because ctrl+alt+Fx will get Qubes tty <roptat>maybe jast Alt+Fx then? or alt+arrow key <nckx>verbasidor: I've never actually used Qubes. Can you ask it to send ‘raw control keys’ or otherwise ask it not to intercept your strokes? <nckx>verbasidor: Sorry about that, but I don't think that was Guix's fault. *nckx promised not to spend another whole evening on #guix so good night all o/ <verbasidor>manual modifying the net , bypassing the installation with offline mode <verbasidor>btw there is a bug with the installation and i have log with red screen <roptat>verbasidor, sure if there's no alternative... <verbasidor>it contains 4 images , each image showing portion of the text <verbasidor>i cant sadly test guixsd unless giving internet access at the beginning meaning i cant use over static VMs <verbasidor>i hope to see these 2 features implemented , and you have one bug now for enjoyment