<lfam>darth-cheney: I'm at a loss <lfam>I'm guessing you waited a while to see if the login prompt appeared? Maybe it was being slow? <darth-cheney>ok I'm going to give this a shot without any preinstalled WM/DE and see what happens <lfam>Or maybe the login prompt was covered up by some messages? You could try switching TTYs with e.g. ctrl+alt+f2 <lfam>And to clarify, this was the 1.2.0 installer <lfam>Sorry for the frustration <darth-cheney>I am able to use the system on the usb without issue, which is the interesting part <darth-cheney>otherwise I'll take it to the mailing list, unless you recommend something else <lfam>Depending on your schedule, I would recommend waiting a couple hours longer for advice here <lfam>Or, asking during the European day <lfam>And we do want to hear if it works without a WM / DE <lfam>And then we do want the bug report :) <lfam>We are actually going to release 1.3.0 soon. There should be a release candidate installer soon <darth-cheney>yeah this is a spritely little laptop, I would love to run my first guix system install on it! <fnstudio>"guix describe" doesn't seem to say anything about the particular generation i'm on <lfam>Can it not determine the origin, fnstudio? <fnstudio>lfam: hm not sure, can it be related to me running time-machine without a particular commit? <lfam>So it includes the other information? <lfam>`guix package -p ~/.config/guix/current --list-generations` <fnstudio>lfam: cool, yeah, there i get "Generation 40" <lfam>`guix time-machine` is like a `guix pull` that doesn't add anything to that ~/.config/guix/current profile <fnstudio>cool, thanks, anything i need to bring back to a prev state after that time-machine command i ran earlier? <lfam>What command did you run? <lfam>No, simply building a package should not affect either the `guix pull` profile or the package installation profile <lfam>That is, ~/.config/guix/current and ~/.guix-profile, respectively <fnstudio>sorry i feel i'm asking very basic questions <lfam>If you had done `guix time-machine -- install meld`, it would be a different story <fnstudio>ok, now things are clearer, thanks, i'll go on and experiment with time-machine a bit further <pkill9>what were you doing darth-cheney? <pkill9>i was thinking of a no-window-manager setup <pkill9>run an application in the cage wayland compositor (not packaged yet though) <pkill9>and just do everything in console <lfam>civodul: I noticed that offloading from berlin.gnu.org to aarch64 is not working currently <lfam>For example, `guix build /gnu/store/4l21sjr2mkzbq3sjnpvj5y7ciqnnda94-audacity-2.4.2.drv` <lfam>pkill9: darth-cheney is trying to debug a system installation failure <irfus>pkill9: I understood 'compositors' for wayland to mean more or less the same thing as a wm for x11. is that wrong? <pkill9>irfus: yes pretty much, but they are also the 'x server' itself <civodul>lfam: oh sorry, i broke it while fixing the childhurd issue; should be back now <pkill9>but yea functionally it's pretty much a WM for x11 <lfam>Thanks, I confirm the fix <lfam>civodul: I'm still rebuilding my systems based on wip-ungrafting. <darth-cheney>pkill9: I'm trying a system install on a laptop from usb. The install goes off without a hitch but on boot I get to the following point and it hangs: <lfam>Should I proceed with merging it into master tonight if things go well? <lfam>Hm, the ACPI errors are suspicious <darth-cheney>lfam: yeah I thought so too, but they also appear when the usb stick boots up <darth-cheney>Of course, I have no idea what they mean. Beyond my pay grade <lfam>In that case they must be harmless <lfam>I wonder if this laptop needs some extra kernel modules <lfam>System installation is not as easy to debug as other things in Guix :/ <lfam>I'm just thinking out loud <darth-cheney>I've never paid close attention, would there normally be kernel modules listed specifically in a basic system config? Or are there defaults behind the scenes <ryanprior>Was there a feature added so you can create a manifest from a profile? <ryanprior>If so, how do you do that? I would like to turn my profile into a manifest :) <lfam>`guix package -p ~/.guix-profile --export-manifest` <lfam>I'd guess you can pass any profile to the -p argument <lfam>There is also --export-channels <ryanprior>I wish it used "specifications->manifest" instead of "packages->manifest", any chance it already has that power? <lfam>That's what it does for me <lfam>It uses "specifications->manifest" <lfam>Maybe it learned this after the version of Guix you are using <lfam>I use Guix in a very simple way <ryanprior>As an experiment, can you install a transformed package into a profile and export the manifest and see if that causes it to use packages->manifest for everything? <lfam>Can you suggest a transformation? <lfam>(I've never used them for real) <ryanprior>Sure, something like "guix package -p myprofile --with-latest=python-pip -i python-pip" <lfam>How about you create a profile that only uses non-transformed packages? :) <lfam>Then you could do the test yourself <lfam>I don't really want to build pip now <ryanprior>lfam: that's fair, I tried building a new version of my profile just now without any transformed packages and now it uses specifications->manifest <lfam>My computer is already fully loaded with other tasks <ryanprior>Is there a scheme function for concatenating manifests, such that I can add a short packages->manifest to a long specifications->manifest? <jackhill>ryanprior: there is a meifest-add in (guix profiles). It's arguments are a manifest and a list of package. So not quite what you wantl, but almost there. <jackhill>My option, it seems like the sort of thing that could belong in (guix profiles) <ryanprior>That seems fine, because I've already got a list of packages I'm passing to packages->manifest in the first place <jackhill>ah, and there is map-manifest-entries which could be useful as well <jackhill>I kind of want to collect all these interesting things people do with thee programming APIs and add them to the cookbook. Over time, I think we might see oppertunities for some gernally useful higher-level APIs too <darth-cheney>lfam: I got a little further. Noticed the grub boot settings for the usb stick include "modprobe.blacklist=radeon" but the installed grub didn't have it <ryanprior>Totally with you on both points jackhill, happy to pair with you on it if that would be helpful <darth-cheney>once I added that, I was able to successfully boot. But of course now there is no graphical capability... <jackhill>ryanprior: +1 to paring. Dinner time for me now, but you can find me here and the @jackhill.us from the mailing lists <lfam>darth-cheney: Huh, weird <vagrantc>oops, i sent to guix-bug not guix-patches. <lfam>vagrantc: You can reassign a bug with debbugs <lfam>Although, there is no guix-bug, but rather bug-guix <vagrantc>oh yeah ... it's not like i haven't been using debbugs for nearly twenty years. heh. although i sometimes wonder about the differences between bugs.debian.org and debbugs.gnu.org <lfam>That's probably about as much as anyone can do... wonder <lfam>darth-cheney: I'm totally ignorant about GPUs (I've only ever had Intel integrated graphics) <lfam>Maybe on #linux-libre somebody will know if your GPU is supposed to work <lfam>Or, maybe somebody here too :) <darth-cheney>I feel like it's amd integrated but still might require non-free stuff based on what I'm reading. I'll check over there in a bit though thanks <roptat>mh? what do I need to get gcc:lib in an environment? <roptat>it doesn't seem to be provided by gcc-toolchain <roptat>also, trying to install an extension on ungoogled chromium, and I can't find how <lfam>roptat: We have a package 'ublock-origin-chromium' which is a popular extension. Beyond that, I don't know <lfam>It maybe that we disabled the extension mechanism entirely <mbakke>roptat: there's an entry in the ungoogled-chromium FAQ, but I would recommend packaging the extensions you need ;-) <raghavgururajan>The name misleading. Its not a store. Its an extension to manage extensions on ungoogled-chromium. It can use any web store. <roptat>lfam, ah, ublock is exactly the one I wanted :) <lfam>Heh, what else is there? :) <apteryx>janneke: retrying now, it worked (herd start childhurd). Perhaps it needed some warmup ;-) <apteryx>hmm, but restarting it leads to a similar problems (trying to start it 3 times in a row now, times out after 60 retries) <apteryx>that was a problem with my config this time <apteryx>janneke: ah, the net-options default value shown in the manual was not copy-pastable as-is; we should reformat it with string-append <apteryx>also, by the default value of 127.0.0.1 means that it will listen only to localhost; dropping 127.0.0.1 as in "hostfwd=tcp::10022-:2222," would have it listen to any interface, which was useful for my use case (connecting to a remote childhurd via wireguard). ***iyzsong-- is now known as iyzsong-w
<apteryx>janneke: I've fixed the space issue in the snippet with ef63a4fa3b <janneke>apteryx: ah great, thank you -- sorry for the trouble ;) <apteryx>I'm still seeing very slow boot/warmup times for childhurd on a 2nd machine <apteryx>it must try at least 3/4 times the 'herd start childhurd' for it to succeed <apteryx>QEMU uses traces of CPU at that time (1-3%) <apteryx>the secret service ends up failing to send the secrets <apteryx>I'm using it with a rather large disk image of 20 GiB, perhaps that can impact something? <apteryx>I just sent the config fragment I'm using <tissevert>checked for guix weather ungoogled-chromium but not libreoffice because I'm not really using it, just have to have it installed because of the people I work with and no my guix system reconfigure is taking ages… noooo <brendyyn>i put that stuff in my user profile instead <tissevert>wait, what's in the use profile doesn't get updated by every reconfigure ?! <brendyyn>thats why i just keep a minimal profile for fast reconfugring <tissevert>I'm gonna do that right now, thank you so much for the tip ! <tissevert>I would «environment --ad-hoc» right into it on a case-by-case basis up to last week, then I installed it «for good» in my system configuration <tissevert>no problem up to this morning when I thought it'd be smart to update my laptop a bit not to remain to far back <tissevert>wait what ?! now it's doing ungoogled-chromium ?! I had checked it right before : ( <tissevert>ok well not the right morning to update apparently ^^' <brendyyn>civodul: i noticed you fixed some xfce things. i submitted 47863 to try fix a bug but im not sure just adding gsettings-desktop-schemas like that is the right way to do it? <civodul>brendyyn: the patch looks reasonable to me, i'll push it later today <brendyyn>thanks. leo probably would have reviewed it too bit i think it slipped under the radar <merazi>just switched to guix... Today, I'm learning how to use it (this is fun hehehe) <red-neck[m]>sneek, later tell mhw: Whats with the harsh accusatory tone towards the brown fella, bro. Are you trying to show white power or something? Watch yourself in public, snowflake! <merazi>I now have my emacs config loaded, icecat installed and my git ssh keys remade :-) <merazi>for some reason the icons look really weird <merazi>The epiphany icon looks weird, also (for example) when I open the gnome-screenshots app, there are no icons on the GUI at all, it just shows some sort of missing icon place holder <Noclip>What's the difference between "lambda" and "lambda*"? <brendyyn>merazi: I was able to reproduce it in a VM, so it looks like a bug we need to fix <brendyyn>There is currently work in progress to update to GNOME 40. im not sure if these things will be fixed there <merazi>:0 really? That's a big update, from 3.34 to 40 <Noclip>brendyyn: Is this part of scheme or a guile specific extension? <merazi>(btw, Is the bug already documented somewhere?) <brendyyn>merazi: no particular reason, it just takes time an effort to maintain these things <merazi>well, nice to meet you all, I may pass by more often, it's time to sleep now, have a wonderful rest of your day *raghavgururajan blabbers "Did someone say GNOME?" <raghavgururajan>I am hoping to fix them during the upgrade. That's why I am not just updating stuff, but also look for issues and missing features. <brendyyn>im running guix time-machine --branch=wip-gnome -- system vm to generate a vm, pretty awesome ***sneek_ is now known as sneek
<raghavgururajan>Folks! If package B inherits from package A, how do I make package B to inherit arguments from package A, but except configure-flags field? <brendyyn>raghavgururajan: you would just add an arguments field to change it manuallly i guess? <brendyyn>the default configure flags for gnu-build-system is just an empty list <brendyyn>raghavgururajan: maybe see libva-without-mesa <brendyyn>there is strip-keyword-arguments, and substitute-keyword-arguments <fnstudio>hi, anyone can help me reproduce a potential bug with meld? the latest version of meld doesn't start on my guix <fnstudio>i'm a bit hesitant in filing a bug report as i'm on a foreign distro <fnstudio>i was able to pin it down to the switch from meld 3.20.2 to 3.20.3 that happened in 93872098eb4c66c01ee56ba5f0e568e029def326 <brendyyn>it starts for me on guix system distribution <fnstudio>brendyyn: thanks for checking, we avoided wasting somebody's time <fnstudio>i'm on a foreign distro (debian) and i realise that this may be difficult to debug, but yeah, i'd be glad if anyone had some ideas <brendyyn>first trick is to use guix environment to test with. ill give you a command in a sec <brendyyn>try: guix environment --ad-hoc --pure -E XAUTHORITY meld adwaita-icon-theme -- meld <fnstudio>brendyyn: yeah, my fault, i thought of omitting that bit in the first pastebin as i thought it wasn't relevant <brendyyn>not so cool. in theory that should have made it work. <fnstudio>but decided to keep it now because, well, it might be <brendyyn>if you add coreutils to the environment, you can run env, you can see all the variables that are set. its not truely 100% for example it still has HOME set <brendyyn>if you just run it without -- meld, it will run a bash shell that you can play with and use exit to get out of <brendyyn>like what happens with HOME=/tmp/test meld <fnstudio>ok lol, this is... weird... very likely to be completely unrelated, but this is puzzling me, XAUTHORITY seems to be set to "/xauthority" within the guix env, despite the --preserve option, sending a pastebin in a sec <raghavgururajan>What should be the commit title when the commit involves changes to two packages? <brendyyn>fnstudio: is there nothing funky in your .bashrc? <brendyyn>raghavgururajan: that sounds like it should be two commits instead? <brendyyn>often one of the first things people learn with guix is that there are things that you often put in .bashrc that should actually go in .bash_profile <raghavgururajan>brendyyn: It is interlinked. Package B inherits from Package A. I am adding a change to package A which should not be inherited by package B. So I make changes to B too. <brendyyn>fnstudio: just open your .bashrc and look at it @_@ <fnstudio>brendyyn: nothing to see here... well... except a 'export XAUTHORITY="${XDG_RUNTIME_DIR}/xauthority"', so sorry, absolutely my fault then <fnstudio>but can that have something to do with the initial problem? <fnstudio>were where we, ah right, coreutils and investigating the env <fnstudio>setting HOME to /tmp/test (and manually setting XAUTHORITY to the right thing) still reproduces the issue <brendyyn>if you run it with strace, you can see every file it tries to open. <brendyyn>if i can get --container to work then even that influence can be ruled out <fnstudio>hm right, i think i might have issues with --container on my distro unfortunately, but will try in a sec <fnstudio>shall i try strace from within a pure env or outside <fnstudio>yeah it definitely seems related but it's weird because i'm not on gnome and i don't think i've any dark theme enabled <fnstudio>and also, i seem to be able to reproduce the issue with HOME=/tmp/test, anyway now doing some more attempts <krusnus>Hello everyone, i'm having problems with fonts on guix, i've installed `font-liberation` but libreoffice cant find the fonts ant they dont show up on `fc-list` <brendyyn>ok now /i'm/ confused, why cant i do --expose=/run with --container <brendyyn>guix environment: error: mount: mount "/run" on "/tmp/guix-directory.00YSKA//run": Invalid argument <brendyyn>krusnus: i think its a bit of a limitiation with fontconfig. i might try improve it so that isnt needed one day <civodul>brendyyn: i can reproduce that --expose=/run issue, weird <brendyyn>i thought maybe due to permissions, so i tried just /run/user/1000 but it still does it <civodul>maybe /run cannot be bind-mounted because it itself contains additional mount points? <fnstudio>(was able to reproduce my system's meld 3.20.3 issue also when unsetting HOME and all XDG_ env variables) <fnstudio>(the strace log seems to confirm no file is being read from my home) <brendyyn>but i can --expose=$XDG_RUNTIME_DIR/gdm and /pulse, but not just $XDG_RUNTIME_DIR <brendyyn>fnstudio: was it reading from /etc/ or /var though? <raghavgururajan>sneek, later tell lfam: I just saw your commits regarding gstreamer, in master. Would you be able to merge gstreamer changes from staging to master? <fnstudio>brendyyn: yeah, there are a couple of places where var and etc get mentioned, such as /etc/ld.so.preload and /var/cache/fontconfig <fnstudio>in particular, it seems to go great lengths to try and access /var/cache/fontconfig but to no avail :) <fnstudio>i went through meld's repo changes between 3.20.2 and 3.20.3 and there's nothing that makes me think of the "Couldn’t find colour scheme details" issue <fnstudio>brendyyn: oh thank you so much for helping me anyway <fnstudio>brendyyn: i've learned a ton of useful things <brendyyn>fnstudio: perhaps its best to post a bug report <brendyyn>and show the commands youve tried running <fnstudio>brendyyn: right, ok, i can definitely do that, there might be someone else who's affected <fnstudio>brendyyn: thanks, have a great day/evening <fnstudio>brendyyn: i suppose so, although it comes with a gui (not sure diffoscope does?); i'm not that much into guis but i must admit that meld has saved my life in quite a few circumstances and i've grown some attachment to it <brendyyn>diffoscope just prints to the command line <fnstudio>but yeah, i should probably spend some time familiarising myself with diffoscope <fnstudio>brendyyn: my meld use is usually "meld dir0 dir1" which gives a nice diff of the dir trees and allows you to conveniently cherry pick and sync things by "copy to left" or "copy to right" <brendyyn>the gtk file selection window doesnt even let me put a path in. it either searches recent files or it uses some non-editable view of the file path <brendyyn>this is why people get angry at gtk/gnome developers <fnstudio>brendyyn: yeah, i tend to get quite frustrated with these things too and usually prefer tuis *raghavgururajan nods at brendyyn <brendyyn>pineapples: yeah what else does kde refer to? <leoprikler>brendyyn: in the meld file window use C-l to swap the breadcrumbs for a free text entry <leoprikler>the same keybinding also works in nautilus et al. <pineapples>brendyyn: Say, a wider application suite under the umbrella of the KDE community <brendyyn>leoprikler: ok it works but it took 10 seconds to autocomplete when i entered an exact /gnu/store path <leoprikler>in that case i don't quite understand "autocomplete", but point taken <brendyyn>that it takes over 10 seconds to autocomplete a complete path <Noclip>Is there a function called "wrap-script" in guix? <Noclip>Is that documented somewhere in the manual? <Noclip>Where can I get some info about it then? *raghavgururajan watches Mortal Kombat while the Rust builds <Noclip><brendyyn "its buggy though"> How? <brendyyn>Noclip: it doesn't handle command line arguments correctly. <Noclip>brendyyn: wrap-script or wrap-program? <apteryx>civodul: I've run 'make release' from a 'git clean -xfdd' checkout, and it './pre-inst-env guix pack guix' packed /gnu/store/rsya5hkyq3fixl2r36lq2g892jadq1fc-guix-1.2.0-21.4dff6ec instead of 1.3.0rc1 again :-/. The first commit bump (the one going to v1.3.0rc1) is there. <apteryx>Seems like I'll have to put the workaround of deleting package-management.go before the guix pack command in the release target recipe <Noclip>brendyyn: So far not all of the bugs are fixed as the issue is still opened? <civodul>apteryx: hi! no, changing package-management.scm updates its mtime, so afterwards guile should ignore the .go file <civodul>you should get a "source file newer than object file" Guile warning, no? <civodul>but... "make assert-binaries-available" currently fails <civodul>how did you manage to get past it? :-) <brendyyn>Noclip: yep, one of these things that gets put near the bottom of the todo list <brendyyn>Noclip: I might create some test cases for it. <Noclip>jackhill: lol "Copyright © 2021 raid5atemyhomework" (inside your bees definition) <apteryx>civodul: probably because it's using that old guix instead? <apteryx>it's the same problem I got tricked with before (hey, make release finished! -- goes on testing, only to find out it's Guix in the 1.2.* pack/images rather than 1.3) <apteryx>civodul: ./pre-inst-env guix show guix in my tree (with the automatic 'gnu: guix: Update to 1.3.0rc1.' at the top): version: 1.2.0-21.4dff6ec <apteryx>well, it shows that the go file is older <apteryx>and indeed 'strings gnu/packages/package-management.go | grep 1.3' doesn't find the new version string of Guix <apteryx>the process from a clean tree (git clean -xfdd) was that documented in doc/release.org, but where the correct tag 'v1.3.0rc1' was already present: guix environment guix --ad-hoc imagemagick perl; ./bootstrap && ./configure --localstatedir=/var --sysconfdir=/etc; autoreconf -f (out of paranoia); make release <apteryx>I had that on berlin before, so it's not like something very special about my filesystem or the likes <brendyyn>how can i capture the output of invoke, or should i use system*? <apteryx>I still don't know how to capture both stderr and stdout at the same time though <brendyyn>wait-a-minute. why is (test-build-utils) called that instead of (tests build-utils) <apteryx>there's something of a convention of having the tests not proper Guile modules <apteryx>perhaps to ensure they don't depend on each other, but that's just a guess <apteryx>unfortunately it breaks some workflows with Geiser <civodul>yes, they're not meant to be used as modules <civodul>because they do things at the top level <civodul>apteryx: from Geiser i typically C-M-x the define-module form <apteryx>right; if you were to change it to (tests build-utils) and switch to the module with geiser, it'd run the tests <civodul>and then i C-x C-e the relevant test <apteryx>that's what I usually do, but that's not optimal either (I don't necessary want to run all the tests of the 'module' in Geiser) <civodul>apteryx: "make assert-binaries-available" uses ./pre-inst-env, so it can't be using "that old Guix" <apteryx>civodul: as I wrote, ./pre-inst-env guix show guix shows the wrong version in my tree. I don't get it. <brendyyn>i think scheme is a language that makes easy things hard and hard things easy <civodul>apteryx: so it loads the stale .go file without a warning, right? <civodul>.go files in the store have mtime = 1, so they always "win" <civodul>but ./pre-inst-env preprends to GUILE_LOAD_PATH & co., so normally there cannot be interference <civodul>does gnu/packages/package-management.go exist? <civodul>this is no different than when contributing "normal things" to Guix <apteryx>GUILE_LOAD_COMPILED_PATH has /home/maxim/src/guix coming first too <nly``>can guix use activitypub to federate substitute servers? <civodul>nly: hi! what would it mean to federate substitute servers? <wingo>abcdw: that was a nice bug :) <nly>civodul, i could have emacs-with-gccemacs in my guix, and serve it via my guix-daemon at guix.nly.com and people connecting to ci.guix.gnu.org will be able to download it <civodul>nly: for that it's enough to run "guix publish" on your machine <civodul>you can additionally fetch substitutes from ci.guix.gnu.org if you want <civodul>in which case your machine becomes some sort of a mirror <nly>i was thinking of a network of `guix publish` servers that can find each other <apteryx>civodul: I'm trying to understand how '/gnu/store/mnlzz2zhnn9y8xqla2p95xy7ghc45xsf-guix-module-union/share/guile/site/3.0/gnu/packages/package-management.scm' gets onto my GUILE_LOAD_PATH <apteryx>civodul: ah, it comes from the guix wrapper itself I think, the one under: /home/maxim/.config/guix/current/bin/guix: (set! %load-path (append (list (string-append "/gnu/store/mnlzz2zhnn9y8xqla2p95xy7ghc45xsf-guix-module-union" [...] <civodul>apteryx: ok, but how does that wrapper come into play when you run "make"? <civodul>the wrapper does not set environment variables, right? <apteryx>and modifies the %load-path and %load-compiled-path <apteryx>so when we use ./pre-inst-env guix pack guix as part of the release target, the guix wrapper from my PATH would get used and insert that /gnu/store/mnlzz2zhnn9y8xqla2p95xy7ghc45xsf-guix-module-union prefixed path, correct? <apteryx>there's no output else than /gnu/store/rsya5hkyq3fixl2r36lq2g892jadq1fc-guix-1.2.0-21.4dff6ec <apteryx>but it's really the load paths which are wrong because I've moved that package-management.go out of the way now, and it still picks that one from /gnu/store/mnlzz2zhnn9y8xqla2p95xy7ghc45xsf-guix-module-union <civodul>apteryx: ./pre-inst-env preprends to PATH, so unless scripts/guix is missing from your build tree, what you describe cannot happen <civodul>"cannot happen", famous last words :-) <apteryx>ls: cannot access 'scripts/guix': No such file or directory <apteryx>is this file generated or versioned? <apteryx>one thing is I don't 'make all' before running 'make release', so it's probably a matter of adding the target responsible for 'scripts/guix' as a prerequisite <leoprikler>It's closed, because we don't advertise those features as working: We build GNOME Builder without them. <luis-felipe>The messages don't seem to give a reason for closing it... <luis-felipe>Yeah, that part I think I understand: that it seems like a nightmare to make it work. But from a user point of view it still a bug, since Builder is advertised everywhere for Python development. <civodul>apteryx: ah yes, you could add a dependency on scripts/guix for the 'release' target <civodul>i always start by running "make" so i didn't notice <apteryx>civodul: we can either add 'all' as a pre-requisite to the 'release' target, else document that the project is to be fully built first <apteryx>I'm happy this turned out to be a simple thing :-) Thanks for the assistance. <apteryx>that's probably true for all the other targets such as 'assert-binaries-available' too, right? In which case, documenting that 'make' should be run first would make more sense <civodul>apteryx: yeah, "release" can depend on "all" or "scripts/guix $(GUILE_OBJECTS)" <civodul>maybe we can just document it, indeed <apteryx>I'll add it to the 'Bootstrapping' section <civodul>meanwhile things are building on berlin but progress is slow <apteryx>it was really slow at building 1.2, even on overdrive1 <apteryx>I think it'd be faster to use the BeagleBords than QEMU <civodul>it's commented out in /etc/guix/machines.scm <apteryx>hmm, so armhf is native to the aarch64 Overdrive machine, the same as i686 is native to x86_64 machines? <civodul>when you run "make release", you should offload armhf + aarch64 to overdrive1 and comment it out of machines.scm so it's all for you <civodul>yes, because the OverDrive has an appropriate CPU <luis-felipe>leoprikler: I can't help solve the problems, but out of curiosity, do you think there's anything GNOME Builder developers can do to make the program easier to work on Guix? <efraim>sbcl failed to build on my aarch64 board <leoprikler>w.r.t. GI_TYPELIB_PATH, that's a difficult problem, that I haven't looked at in all detail yet. <leoprikler>IIRC organizing your typelib imports in a particular manner is the way to go, but it's quite fragile. <leoprikler>w.r.t. jedi, definitely, but it requires a solution to GI_TYPELIB_PATH first <civodul>apteryx: maybe "make assert-binaries-available" will be good in 4-5h, and maybe you can try running "make release" at that point? <apteryx>yeah, otherwise we'll load the machines double <civodul>have you set up qemu-binfmt for armhf/aarch64/powerpc64le on your laptop? <civodul>that'll be useful for derivations that don't get offloaded, such as grafts <apteryx>I've made sure that only 'real' machines will be used for ARM/powerpc64le stuff <civodul>apteryx: yes, but IIRC you also need emulation for the "cheap" derivations marked as non-offloadable <civodul>i guess you can give it a try: try running "./pre-inst-env guix pack -s powerpc64le-linux coreutils" on your laptop <brendyyn>I was wondering recently. I noticed in core updates gcc was set to gcc 8. How is it decided what gcc version to use in guix. is there some secret organisation deciding this? <brendyyn>gcc 11 has microarchitecture targets, which seems maybe something to incoperated, instead of customised cpu features. much simpler <efraim>civodul: I'm building gcc-11 and gdc-11 ATM <efraim>brendyyn: generally whoever wants to do the work and test stuff. with powerpc64le and the newer glibc we needed at least gcc-8 and I found that gcc-9 and gcc-10 caused more build failures than I was able to fix, while gcc-8 built fine to mesa <brendyyn>makes sense, so its about not leaving other architectures behind, and bug hunting <civodul>efraim: yay, i knew you'd be on top! :-) <efraim>i've added gcc-toolchain-11 and gdc-11, but not gdc-toolchain-11 or any of the other libgcc or gcc-lang variants <pineapples>Does anyone use Nitrokey's products here? I'm having a problem setting up my Gnuk token; gpg doesn't see it <pineapples>Well. It looks like it works under Fedora just fine.. <luis-felipe>leoprikler: So maybe it would be good to try Builder on another system to see if these features work at all, before wasting time trying to fix something that doesn't actually work. <leoprikler>I didn't look at the video, but perhaps they configured Builder without Jedi or disabled it? <apteryx>civodul: eh, I got: guix build: error: corrupt input while restoring archive from #<closed: file 7fb1c21c2af0> <apteryx>otherwise failures to substitute gts, glib and gobject-introspection so far <roptat>hm, the devel manual is stuck again, since the 22 <apteryx>the './pre-inst-env guix pack -s powerpc64le-linux coreutils' test on my desktop passes OK. <apteryx>although it was offloded to p9.tobias.gr it seems <apteryx>(offloading build of /gnu/store/iymmkv7nw7xdgywrc4mdkymy7xy91v19-tarball-pack.tar.gz.drv to 'p9.tobias.gr') <apteryx>roptat: :-/ What's the tool that gets stuck every time? <roptat>po4a I think, or the step after it <roptat>it's the translate-texinfos derivation <apteryx>OK; is it a known issue with that tool (po4a)? <roptat>I don't know, it's something we've seen in the past apparently, given the comment a few lines above the call to po4a (limiting to 4 cores) <roptat>yes, I can build that derivation with -c1 <roptat>just building with 4 cores would trigger the issue <roptat>at least on my computer, and berlin apparently <roptat>looks like berlin failed once an hour since the 22 <roptat>I only tried a few times on my computer <roptat>it doesn't work anymore since there are more texinfo files to translate to <apteryx>and when you run the derivation with -c1, does that eschew the problem? <roptat>with -c1 I can build the derivation <apteryx>OK. So is this a workaround we can put in place for now for the CI? <roptat>I don't know, maybe? but it's built from a cron job, not the CI <roptat>and it's one of the derivations the build depends on <roptat>though, I wonder why it was not reported before, the derivation is part of guix/self.scm, so it should be part of guix pull, right? <roptat>maybe the proper fix is to make it single-threaded in guix/self.scm? <abcdw>wingo: Thanks a lot for fixing it!) Yep, looks quite tricky. It was kinda unexpected, spent two days trying to understand what am I doing wrong >< <civodul>apteryx: if you try "./pre-inst-env guix build guix -n -s powerpc64le-linux --no-grafts", you'll see only 'guix' itself is missing (it's being built) <apteryx>roptat: Im' not too familiar with (guix self); it probably ends building Guix the usual way? <apteryx>civodul: I'm curious why running the same on berlin (without -n) doesn't seem to make use of the 10.0.0.5 and 10.0.0.6 beagleboards machines? <apteryx>I mean, with -s armhf-linux, which lacks lots of substitutes still <civodul>apteryx: maybe their load is too high? <apteryx>it only seems to acquire slots with overdrive1 and dover <civodul>dunno, i think i did see things go to 10.x.x.x, not sure <apteryx>they are indeed busy building stuff ATM <apteryx>probably they have no build slots available <mothacehe>apteryx: you can "herd stop cuirass-remote-worker" if you need to build stuff <civodul>building Guix on POWER9 seems to take forever *vagrantc found it to be quite fast building the debian package on power9 :) <apteryx>mothacehe: ah, I don't think the beagleboards are registered Cuirass workers for now <apteryx>they're simply offload machines so far, IIUC <mothacehe>yes you're right, I was referring the overdrive1/dover machines <apteryx>civodul: I see that /tmp/guix-build-guix-1.2.0-21.4dff6ec.drv-0/source/guile ... is running on p9.tobias.gr *mothacehe just sent an installer patch to solve one of the last 1.3.0 blocking issues <apteryx>are you sure you didn't get the problem I was having earlier? It'd be a shame to waste time building guix-1.2 again! <mjw>But my guile is terrible and I keep getting this error: <mjw> /etc/config.scm:49:21: error: (qemu-binfmt-configuration (platforms (lookup-qemu-platforms "arm" "aarch64" "mips64el" "ppc64le")) (guix-support? #t)): extraneous field initializers (guix-support?) <mjw>apteryx, Thanks. So in return, where do I clone the manual and how do I sent in a patch to fix that? <apteryx>it's already fixed in the latest manual, I believe <sneek>lfam, raghavgururajan says: I just saw your commits regarding gstreamer, in master. Would you be able to merge gstreamer changes from staging to master? <apteryx>lfam: how does one find that manual from the front page? <lfam>Hm... type "devel" into your browser's address bar and find it in the history :) <apteryx>I go to 'Help -> GNU Guix Manual' -> ? <mjw>O, so because I guix upgraded I need to read the /devel/ manual? <lfam>The other manual is just corresponding to the 1.2.0 release, but after you've done `guix pull`, you'll get changes that should be documented in the devel manual <lfam>Guix is "rolling release" both in terms of the packages and Guix itself <lfam>Like apteryx says, this is a UI problem that we need to fix *mjw is always confused about this fact of guix. <lfam>It's really different from other distros <apteryx>roptat: the issue for the devel manual failing to build is 47428 <lfam>mjw: But, you can think of it like Linux, where the drivers ("packages") and core code ("Guix itself") are developed concurrently <mjw>lfam, right, but you do have "core" branches, etc. I am not getting those, only when integrated into "main" guix. <lfam>Ah, I see another confusing thing now :) <mjw>On the other hand I am probably almost at 1.3 already, just saw gcc 11.1 :) <lfam>We can't change the core packages without having to rebuild every package, so we batch those updates on a 'core-updates' Git branch and only tackle it periodically <lfam>raghavgururajan: If there are changes you can cherry-pick from your staging patches that fit, we can put them on master <lfam>Do the plugins and the main package need to be exactly the same version? <lfam>Anyways, that's the reason why I picked bug-fix patches instead of using your patches from staging to fix these bugs <lfam>mjw: And the 'staging' branch is core-updates lite. It's like the middle layer of application libraries, such as mesa <lfam>The command `guix refresh --list-dependent foo` is used to count the number of rebuilds to make decisions about this stuff, although it doesn't count dependencies of build systems. So there is an element of "you just have to know", which it would be great to reduce <lfam>You can kind of count those rebuilds, if you know a package is used by a build system, by doing `git grep foo-build-system gnu/packages | wc -l` <lfam>Changing the subject, should we merge the ungrafting branch into master, civodul? Did you test it on your end? It's working okay for me <lfam>But, I don't use any desktop environments or window managers from Guix <mjw>yeah, last time I tried updating something (elfutils, which contains libelf, although there is another libelf in guix, which some packages use) I got told it would need the whole world to be rebuild... :) *vagrantc wonders about encoding something into "guix refresh" to recommend what branch a change should land in <lfam>vagrantc: That's a great idea <lfam>Oh yeah mjw, `guix refresh --list-dependent elfutils` prints a lot of lines :) <lfam>By the way, does it make sense that there is another libelf? Or did we mess something up? :) <mjw>lfam, it might have made sense ~15 years ago. But these days the elfutils libelf is what everybody uses and the "other" libelf has fallen off the interwebs. <mjw>lfam, they aren't binary compatible (and might have a few small source incompatibilities, but those are really bugs) <mjw>now guix doesn't care about binary compatibility (and here I was so proud of elfutils using symbol versioning and a stable so name for multiple decades...) <lfam>Does `guix graph --type=reverse-package libelf | xdot -` to see how thousands of packages come to depend on this 'libelf' <lfam>Oof, I wonder if we improve the layout chosen by the dot viewer <mjw>It probably works, libelf is a funny "unix standard". It isn't really an official standard library, but everybody has an implementation anyway. We still coordinate new interface additions (with Solaris and BSD) <lfam>It looks like the world of R comes to depend on this libelf, and that's a huge number of packages <mjw>lfam, does that work for you btw? I get a errors <mjw>TypeError: <window.DotWidget object at 0x7fce8b729300 (xdot+ui+window+DotWidget at 0x202c0f0)>: unknown signal name: draw <lfam>Hm, it works for me using xdot from Guix <lfam>I also did `./pre-inst-env guix graph --type=reverse-package libelf | xdot -`, since I was already in my development source tree <lfam>It seems that some parts of our GCC toolchain use this libelf <lfam>Or even, the entire thing <mjw>lfam, it is probably a good choice if you want a library that never updates (because upstream is dead) <mjw>the elfutils libelf sees a new release every ~3 months <lfam>Well, maybe there is a good reason it was done this way <mjw>so in a guix world that then means, rebuild the whole world if gcc depends on it... <lfam>Yeah, but we can make a package like 'libelf/stable' and only update it during core-updates <lfam>I mean, 'elfutils/stable' <lfam>I guess I'm worried it's a mistake of the sort caused by "libelf not found" error messages, which I've seen mislead people before <mjw>yeah, another thing I don't really get about guix, how do you do that? <lfam>They satisfy the dependency with the project named in the error message, although there may be a canonical implementation under another name <lfam>Let me find an example for you <mjw>I mean, gcc sees fixes every couple of days/weeks and you really want them. <mjw>but you only update gcc once every couple of months? <lfam>Well, we also are not using the latest version of GCC to build packages. We offer (most of) the releases, but we are currently using GCC 7 <mjw>that is really bad (imho) <mjw>sure, but even the "stable" gcc branches get regular bug fixes <lfam>We try to update it in each core-updates cycle. The reality is that updating it causes so much fallout that we can't feasibly do it more quickly <lfam>When I joined in 2015, we were using GCC 4 <mjw>haha, yes, that is one way to do it. Depend on gcc-7 which isn't maintained anymore. <lfam>What can I say. We can only do so much <mjw>then you don't get any bug fixes anymore indeed :) <lfam>If we updated it more quickly we wouldn't have a distro <mjw>Because you rebuild the world on every gcc update? <lfam>And it breaks a lot of things <lfam>So, we have to fix dozens or even hundreds of things <mjw>but other distros already did that, can't you simply pick up their fixes? <lfam>Not to mention that it has to be coordinated with updates of other core packages, since they may depend on particular versions of each other <lfam>That's where we get these fixes from <lfam>It's a matter of humanpower and priorities <lfam>(Remember we are almost entirely run by volunteers) <lfam>It's not like there is some manager who can direct employees to focus on this <mjw>OK, well, I can see how I can help. <lfam>Motivation is not fungible, so people work on what they want to work on <lfam>There's only a few people who are willing to spend weeks on this kind of thing <mjw>but maybe I won't start with a core package :) <lfam>It's "hidden", so it doesn't appear in the Guix UI <lfam>Users will install the package defined below it, and we can update that one freely, without causing a huge number of rebuilds <lfam>Over the years I have come to realize the value of coordination in a project like this. The most impactful thing you can do is motivate people to work on some task they wouldn't otherwise do <lfam>I'm slowly trying to get better at it but it's easier said than done :) <lfam>And also, when I said "Not to mention that it has to be coordinated with updates of other core packages, since they may depend on particular versions of each other", it would be great if core GNU packages coordinated among themselves too <lfam>I think this could be something the Assembly might talk about <lfam>Already, Guix has effectively "Tom Sawyer-ed" a distro. Packaging is really easy and maybe even addictive <lfam>But there is more to it than just packaging <lfam>I think we are only at the beginning of this project :) <lfam>raghavgururajan: I'm not sure. Personally I don't have a plan in mind post-1.3.0. Maybe others do <lfam>Maybe we could do staging really quickly, at the same time as we start core-updates <lfam>I think we will be able to move a little more quickly going forward, thanks to mothacehe's great work on Cuirass <lfam>I got some good feedback on how I managed the previous staging branch in December / January. Maybe someone could repeat that process and improve it <roptat>yeah, I think the plan was to work on staging and core-updates after the release <lfam>I think we could probably work on them as separate branches but at the same time, since staging will probably go very quickly <roptat>sure, but let's focus on the release right now <cybersyn>hiya guix, anyone else failing to build openjdk? <roptat>we're already 10 days behind schedule ^^' <roptat>cybersyn, I just got a substitute for openjdk 14 yesterday <lfam>What's the status of it? Are we still going to make a release candidate? *vagrantc keeps hoping for a release candidate to upload to debian :) <cybersyn>ropat: thanks for that, it could be that i'm on notlibre rn. i keep a libre configuration handy and will boot into it to see if it installs there <lfam>I'm going afk. The parts for the macchiatobin arrive so I'll be putting that together today <roptat>cybersyn, unless you have a non free openjdk package redefined by some channel, it's the same package, and there's a substitute for it (on latest master, maybe you need a guix pull) <PotentialUser-81>Hi all, how would I go about configuring opendoas part of the operating-system configuration? <PotentialUser-81>(it's a sudo replacement which usually reads its config from /etc/doas.conf) <roptat>PotentialUser-81, if it needs setuid root, you'll have to add it to setuid-programs in your operating-system configuration at least <leoprikler>👆️ + potentially writing a configuration record for the doas.conf <roptat>or more simply use an etc-service-type to write that file to /etc ***lukedashjr is now known as luke-jr
***lukedashjr is now known as luke-jr
<apteryx>jonsger: hi! I'll post something to guix-devel after the RC1 is out; we're currently building substitutes for all the archs (mainly for armhf-linux, but also powerpc64le). Assuming there are no more build problems, we should be good for RC1 soon (TM). <lubrito>cbaines: Hi. by symbol null you mean 'null? <PotentialUser-81>roptat: so I did that, but it seems like the etc-service-type is adding a "^J" to the end of the file, which is causing doas to error <roptat>PotentialUser-81, I need to go, but others can help you. How did you specify the content of the file? <PotentialUser-81>roptat: Np, thanks for the help so far. I'm simply defining it like so: (plain-file "doas.conf" "permit persist :wheel\npermit nopass keepenv root") <roptat>ah, maybe because the file doesn't end with a new line? <roptat>what if you add an \n at the end of that string? <jonsger>apteryx: oke, so that gives me a bit time for polishing some guix channels :) <PotentialUser-81>I can confirm that if I copy the file to my home, open it with nano, write it out(without making changes), the ^J is removed and doas can parse it <PotentialUser-81>and yes adding a \n to the end also removes that character and it works! <cbaines>lubrito, yeah, although with quoting, it might not be 'null, if it's part of a large quoted thing like '((foo . null)) <civodul>lfam: hi! i didn't actually test wip-ungrafting, i mostly focused on getting things built on version-1.3.0 (which includes it) <civodul>never underestimate the cost of adding an architecture... <civodul>lfam: anyhow, if your testing was positive, i think we can go ahead <lfam>I do not underestimate that cost at all :) <apteryx>civodul: the 1.3.0 version stirng is taking its signification ;-) <civodul>ok it's still 404 but within a few seconds (minutes?) you'll see <lfam>It showed me that "we're still baking" <civodul>right, that's what it's doing: baking it :-) <lubrito>cbaines: I have a small problem, I told you I could do something like this (or (vector->list items) '()) but as it turns out, I can't! <lubrito>in the case items is #f vector->list won't work <lubrito>I tried using an if, in place of the or, but it doesn't seem to work with map *civodul feels like it's been a day waiting for build results <apteryx>hmm, that narinfo has on first line: StorePath: /gnu/store/jl0qc6n1m9scz26ssvkm62jzisalbq8d-guix-1.2.0-21.4dff6ec <apteryx>did you fall into the same trap I did? :-) <civodul>no, i'm not attempting to make the release :-) <lfam>That build farm has been busy repeatedly failing to build SBCL <civodul>apteryx: the important bit here is "System" <apteryx>yeah, it built it for powerpec64le :-) <apteryx>it should have already existed though, because I've been generating release artifacts for all supported archs since last weekend for guix-1.2.0-21.4dff6ec ;-) <apteryx>if you scroll back in history you'll see some milesone I announced where 'make release' had succeeded; that was for guix-1.2.0-21.4dff6ec... :-( <apteryx>still, it's reassuring that Guix from the 14th of April can be built on all archs; that's not too far back <lubrito>cbaines: thanks, that did the trick! <gagbo[m]>Hello, have people have issues installing Guix on Fedora ? The systemd service status says permission denied on guix-daemon (/var/guix/profiles/per-user/root/current-guix/bin/guix-daemon) <lfam>gagbo[m]: I guess you need to do something regarding selinux <gagbo[m]>yeah I’d guess so, but I couldn’t find the doc online :( I’ll keep looking <civodul>apteryx: yeah, it's ridiculous that so much has to be taken care of manually, but it'll improve soonish i hop <cybersyn>roptat: so it turns out it was due to a conflict with a prop graphics driver I had installed. after uninstalled, it installed fine <roptat>cybersyn, ah, thanks for letting me know :) <roptat>I wonder what could have been the interaction that caused the issue, kinda worrying <cybersyn>nope, my poor ethics caused the madness :) <roptat>well, what if a similar problem was caused by a free driver, only for some graphics card models? <lfam>However, the connection is unstable. Sometimes it stops displaying messages during boot, sometimes it reaches the login prompt but doesn't respond to my keystrokes. I'm using minicom from Debian stable <lfam>Does anyone have any tips? I've worked at the serial console using screen to interact with a PC Engines APU2, and that works reliably. But it is less stable than minicom with the macchiatobin <lfam>I'm asking in the vendor chat room but maybe somebody here has advice, too <lfam>It looks okay to me cbaines <lfam>cbaines: It just either stops printing at some point, or gets to the login prompt but is unresponsize <roptat>maybe the baud rate is incorrect? <cbaines>hmm, I was going to suggest tweaking the baud rate, but I've usually seen garbled output if it's wrong <lfam>I'm using 115200 8N1 as the vendor suggests <rekado_>gagbo[m]: if you feel like debugging this, please apply the guix-daemon.cil file (it’s part of a Guix source checkout), and then look at the SELinux audit logs to figure out what permissions might be missing. <rekado_>gagbo[m]: note that messages relating to the daemon may appear as “(x-daemon)” in the SELinux logs, which is a little confusing. <civodul>apteryx: i've tweaked release-manifest.scm on version-1.3.0 <civodul>with these changes, there's only one substitute left: guix on armhf <civodul>it should take another 1-2h to become available <lfam>I got past my USB serial console problem by disabling hardware flow control in minicom <apteryx>civodul: is this the manifest used by distcheckÉ <darth-cheney>hey all, on a regular guix system install should a non-root user be able to run `herd status`? <darth-cheney>I'm getting /run/user/1000/shepherd/socket: No such file or directory <lfam>It's expected that you need privileges <lfam>`herd status` as an unprivileged user will try to get the status of a shepherd that your user might start <darth-cheney>btw lfam: the solution to my issue yesterday was to pass `nomodeset` to the kernel at startup <lfam>I'm glad it's working for you now <bluekeys>Hi guix. Can anyone point me to how to start using sway wm? I can't find it in the manual under desktop services <darth-cheney>Apparently this is common for certain kinds of system graphics chips <lfam>I wonder if there is anything we need to do <gagbo[m]>rekado_ roptat thanks, I don’t really have the motivation to go through all this while setting up my new machine, so I’ll just setenforce 0 and see later <vagrantc>bluekeys: i just login at a console prompt and run "exec sway" ... needed elogind service in my config <vagrantc>bluekeys: you also probably want to make sure xwayland is installed <vagrantc>i could never get display managers to work reliably, and honestly, kind of prefer logging in at the console anyways :) <vagrantc>raingloom: i haven't been doing that ... wonder what i'm not getting :) <vagrantc>you really want exec, otherwise someone can switch to the tty and background the process to get around your screen locker <raingloom>vagrantc: i remember some desktop stuff being borked, like icons and stuff. now i just use it to be safe. <vagrantc>maybe there's some other way to fix that issue <vagrantc>but exec seems simple and reasonably robust ... *vagrantc laughs nervously :) <bluekeys>I'm currently using exwm. Is it possible to run emacs a service on guix? I'm used to always having emacs around, and autostarting on boot more or less. Also, would love if it could survive between leaving and restart x sessions when playing with various wms <leoprikler>bluekeys as long as you manage to get shepherd running as a user, you should be able to do anything <lfam>This is for unprivileged shepherd run by your user, not the system <lfam>I see we have packages of trusted ARM firmware <lispmacs[work]>hi, I seem to recall there was some way to run `environment --pure' while still preserving your display environment variables. Could somebody help me out remembering that... <lfam>I guess I'd need to create a 'make-u-boot' package that bundled the trusted firmware and mainline uboot? <sneek>bluekeys, you have 1 message! <Formbi>I'm trying to «guix import go github.com/chzyer/test» <Formbi>does somebody have an idea what is going on? <lfam>Maybe the importer requires use of Go modules, idk <Formbi>it seems you're not supposed to use https:// <lfam>It fails in 'go-module->guix-package', so I'm guessing it assumes use of modules <lfam>IIUC, the lack of a go.mod file in this programs source tree means that it is not using Go modules