<lfam>You'll need to figure out how that support is switched on and off and then check if our package does it <lfam>You can do `guix build --no-grafts qtwebengine --log-file` and should find some information in the log <lfam>You can also get logs for specific store items, like `guix build /gnu/store/...-qtwebengine --log-file` <lfam>I'm suprised that reddit is using h264 though, which is why I asked if you're sure about which codec is in use <lfam>IIRC, they introduced their video hosting only a few years ago, and royalty-free codecs have been viable in that timeframe <lfam>Is that other link you shared an example of a video that doesn't work for you? <pkill9>since it's the most obvious reason <lfam>Youtube opportunistically serves the least expensive encoding that the client supports. Reddit's video hosting seems... unsophisticated <lfam>I used youtube-dl to download that video file from reddit, and then I used exiftool to check what it's actually using. <lfam>I'm surprised! They must pay a ton of money for that <lfam>We need to build the package with "-webengine-proprietary-codecs" <lfam>TIL: h264 is royalty-free if the end-user can view the video for free. So reddit wouldn't have to pay <bqv>Proprietary codecs, I was right <lfam>Just to clarify, sorry if you weren't implying it's nonfree <bqv>Oh, ok now I'm just confused <keysemble[m]>Hi folks, any news on Gnome packages updating to 3.38.X? <lfam>It's patented (thus called proprietary), but copyright license of the implementations that we are free licenses <lfam>keysemble[m]: There are work-in-progress branches for GNOME 3.34 and 3.36, but I don't know if anyone has started working on 3.38 <keysemble[m]>I just started using Guix for the first time today. I suppose I need to learn the ropes first and get familiar with Guile I imagine? <lfam>You don't really have to know Guile to work on packaging, which is a lot of the work involved in updating things <keysemble[m]>Gotcha, so it's just a matter of version bumping and testing? <lfam>Yeah, that's probably about half the work. The other half will be fixing :) <pkill9>you can learn guile as you go along packaging <lfam>The way that all the GNOME parts work together can get complicated but hopefully it doesn't change too much between versions <keysemble[m]>Understood. Hopefully I can help out with my limited experience from packaging in other distros. <lfam>Alright, please feel free to ask for help or advice at any point <lfam>And I agree with pkill9. You'll start to learn Guile (Scheme, really) as you go <keysemble[m]>I played around with Racket a while ago, I haven't used it since though <lfam>It's the story of where something came from <bqv>Ah, so guix can't tell where my system's from... that's cause it's currently not guix <rekado>(not to be confused with the region in France…) <lfam>If it's not from Provenance, FR, it's just a sparkling origin story <lfam>bqv: Is it blocking something? <keysemble[m]>lfam: Question, how can I reference the wip-gnome3.36 branch for bumping/testing/fixing with the guix package manager? I suppose though the use of a guix channel? <lfam>You could use channels, but you can also do it in an ad-hoc style with `guix pull --branch=wip-gnome3.36`. That command also takes an --url argument, but the correct repo for this is the default argument <lfam>"The thing" is that the branch is a little stale at this point, last updated in May 2020 <lfam>I also recommend searching our mailing lists for discussion of the branch. You should find a summary of its status somewhere ***chrislck_ is now known as chrislck
<bqv>lfam: nah, was just curious <bqv>Though, I have a problem new. The linux-libre kernel isn't finding my btrfs partition by uuid, can I switch it to by devname from grub? <bqv>I'm unfamiliar with this --root=<uuid> syntax <keysemble[m]>Decided to use the channel approach. There were "forwarding" issues doing the ad-hoc approach <keysemble[m]>Now the question would be, where do the package definitions get stored? <lfam>It ends up in ~/.cache/guix/pull <lfam>I think it's ~/.cache/guix/checkouts now <lfam>It can be such a drag to get started <keysemble[m]>It's not a big deal, I wanted to learn how to maintain stuff anyway, like making my own packages. <keysemble[m]>looks like the `guix pull` is building from the gnome 3.36 work, so I'll have to play around with it. <lfam>I found that to be really easy when getting into Guix. It's much easier than in some other packaging systems and it's nice that it is integrated with the rest of the package manager <lfam>The custom packages thing <keysemble[m]>I used to use Gentoo a lot and like doing custom configurations with use flags, but I started getting tired of always compiling over time. I appreciate the Guix offers both binary installing and source building. <lfam>I think it's a useful middle-ground between binary and source distros <lfam>There is a discussion ongoing about how to offer something like the use flags in Guix <lfam>Like, customization is already possible and used often, but Gentoo people have a nicer abstraction for that exact ghing <bqv>You know, I really just need a way to reuse my old kernel for guix <keysemble[m]>lfam: what would be an example of a package transformation? <lfam>I'm not sure how I'd approach it. Hopefully someone else has some advice bqv! <lfam>keysemble[m]: Take --with-input=package=replacement, "Replace dependency on package by a dependency on replacement." <lfam>You want to build VLC with a new version of ffmpeg <lfam>You write a custom package of ffmpeg and then `guix package --install=vlc --with-input=ffmpeg=your-ffmpeg <lfam>Or something like that :) <lfam>It's kind of ad-hoc. I usually write custom packages for everything instead <lfam>But, (I think) if you did `guix package --upgrade . --with-input=ffmpeg=your-ffmpeg`, all your packages would use the custom ffmpeg <keysemble[m]>I'm excited there is more than one way to approach custom packaging <lfam>The Guix slogan: Liberating, dependable, hackable <lfam>It's designed to be hacked <lfam>Whatever the good one is *pkill9 is compiling qtwebengine with -webengine-proprietary-codecs added to configure flags <lfam>I'm curious, are you using a powerful computer? That package is a big one <pkill9>i think it being liberating is the resultt of the second two <pkill9>lfam: no, i'm building it on a VPS <lfam>Yeah, free to experiment without fear of breaking the computer <pkill9>it's not a very powerful vps, hopefully it will be built by the morning <lfam>And, possible to experiment <lfam>I would make sure it has several GB RAM <lfam>If you send a patch we could use the build farm to build it... <pkill9>it's hackability is liberating in the sense of freedom to change things easily, and it's dependability is liberating in the sense of it being freed from unrealiability <pkill9>that's the problem with just hackability, if it's not dependable you can't realistically use it <keysemble[m]>I'm sure I have more to learn, though Guix is already feeling very special to me <pkill9>unlike say gentoo or arch, changing things almost won't break things <pkill9>because of system generations and the functional nature of it <pkill9>i haven't used gentoo tbh so maybe i'm wrong <keysemble[m]>Gentoo is pretty stable these days but it's possible to break if not careful. <keysemble[m]>I guess that the power of a declarative system, no fears. <pkill9>yea, there is however the possibility of broken GRUB somehow <pkill9>or broken grub config or something <pkill9>once i got dropped into a guile prompt i think <keysemble[m]>Hmm, can one chroot through a live session and fix it that way? <lfam>It's not like it happens all the time :) <pkill9>actually yea it's pretty simple to reconfigure from a live system <pkill9>although it would be nice to have a rescue USB set up such that I don't need to remember the commands <lfam>I'm not sure how Guix would represent that something had gone wrong and that the system was in a fallback state. It's not quite as simple as just implementing the grub stuff <lfam>I also haven't actually tried it <pkill9>lfam: if you could build webengine on the build farm that would be great, all i've done is run: guix build -e '(begin (use-modules (guix packages) (gnu packages qt)) (package (inherit qtwebengine) (arguments `(,@(package-arguments qtwebengine) #:configure-flags (list "-webengine-proprietary-codecs")))))' <lfam>Can you send a patch to <guix-patches@gnu.org>? <pkill9>I believe there are no configure-flags in qtwebengine <lfam>I'd like to preserve use of the build farm for patch submissions <pkill9>ohh i think it may add them in a phase <lfam>Thanks! Ping me once it is sent or if you get stuck <pkill9>sould i just put -webengine-proprietary-codecs? <pkill9>or --webengine-proprietary-codecs=yes ? <lfam>Does that phase fail if the flag is unrecognized? If so, you could try it and find out <pkill9>lfam: i think it's just -webengine-proprietary-codecs, it has an exmaple on the page <keysemble[m]>Man, I'm still trying to figure out the right workflow to use for manually updating Gnome. I guess I need food break. <lfam>It will build /gnu/store/q87bhig1v4hr9axcq7lhxb90znfmg2q5-qtwebengine-5.15.2.drv based on commit a68352ed903f6bc7abfbc33ffc551e1234a44043 <lfam>You might get the best results by filing a bug about the package <calher>I am getting very strange results with my internet connection. I am on ethernet. I can get google.com but not reddit.com. I can ping gnu.org. <calher>To be fair, I have not updated this Guix system in ages. Could it be an issue with certs?\ <lfam>You could try `herd invalidate nscd` to clear it cached names <lfam>I mean, the clear the cached names <keysemble[m]>lfam: so, assuming I have the default guix.git channel and a wip-gnome channel from wip-gnome3.36 branch of the same guix.git repository, shouldn't I have 2 directories in the ~/.cache/guix/checkouts directory? <keysemble[m]>I only see one directory that has the guix repo under the master branch <lfam>I'm not sure. The directory contains a git repo that is used to build from, and that wip-gnome3.36 branch is of the default repository <lfam>So, it could be the same thing <keysemble[m]>It does, but the thing is, that directory already has the remotes to both 3.34 and 3.36 wip versions, so it seems I don't really need to use a channel for the wip 3.36 version, but I'm confused how isolate the gnome3.36 stuff for testing from the default guix repo <keysemble[m]>because I don't want to mess with the main checkout directory for the `guix` tool <lfam>`guix pull` is used to update or change the available packages and Guix tools. Each time you run it, a new "generation" of Guix is created, and the effective generation is then referred to by the other Guix tools, such as `guix install` <lfam>It's kind of like `apt-get update` but you can switch to previous generations, rollback, things like that <lfam>This directory's name "checkout" is misleading. It would be more accurate to call it "git-repository" <lfam>So, to test things, you could do `guix pull --branch=wip-gnome3.36 && guix system vm-image config.scm` <lfam>After testing, you could do `guix pull --roll-back` and go about your business <lfam>So, `guix pull` is like `apt-get update` and `guix package --upgrade / guix upgrade` is like `apt-get upgrade` <keysemble[m]>Ah, okay. Thank you. See, I need to learn these workflows? :) <lfam>It's not an exact analogy but close <lfam>I recommend the Package Management section of the manual <lfam>It will introduce the concepts with some practical examples <lfam>It helps to know what a "profile" is with Guix, then it's easier to talk about <keysemble[m]>I was looking through manual, but since I'm a newb here, it's a lot of information to take in at once, so it helped me to see some workflow examples which will help understand the manual better <lfam>Did you try the Getting Started chapter? <keysemble[m]>I skimmed through it, but I will look through it thoroughly <keysemble[m]>I probably skipped some important stuff that I thought I was already familiar with <pkill9>lfam: does it build those automatically? <lfam>The Package Management chapter introduces "profiles" which are the things you have generations of, and allow rolling back <lfam>Actually, cbaines runs a patchwork instance that builds things automatically, I think <pkill9>there's a big list of third party files to preserve it seems, looking at the package definition, i think openh264 needs to be added to that <lfam>Looks like the change will be a little more than just the configure flag <lfam>Yeah, but we'd prefer to use the Guix package of openh264 <keysemble[m]>Ah okay, now I understand the significance of that $GUIX_PROFILE hint <lfam>Yeah, it's pretty important. On Guix System that kind of stuff is handled automatically. Getting set up on other distros requires a little bit of initial busywork, but only at the beginning <keysemble[m]>Ah, okay, I needed to use `--allow-downgrade` for that branch <keysemble[m]>and then I can create a vm-image of that branch which was an older snapshot of time, brilliant <bdju>can someone re-open issue #45280? not sure how to do it but it's not fixed. someone closed it doing clean-up on old issues it seems <user5578>is there an config example of gitolite and cgit working together? ***modula2 is now known as defaultxr
<apteryx>raghavgururajan: :-) I just packaged it in Guix. <timmydo>i'm trying to package a new service in guix and i'd like to add a new system service-type so i can put it in my config.scm. is there a good guide on authoring services? the manual sort of tells me all the options but i'm curious how i should test and iterate on the code. probably not repeatedly running guix system reconfigure? ***tgamblin-llnl is now known as toddgamblin
***toddgamblin is now known as tgamblin_
<keysemble[m]>Is there a way to configure guix to use a channel created locally? <ison>keysemble[m]: In the url field just put the directory, like: (channel ... (url "/foo/bar") ...) <wleslie>turns out `guix gc` while I have `guix environment` open in another shell is not a good idea <dummyuser>Hi, is there a boot setting for shepherd to boot only to TTY and not start the X-Server similar to systemd's target= and classic runlevel? After first install my system freezes when trying to start the login manager at which point "C-M-F2" don't let me change to other TTYs any more. <cbaines>woo, guix.cbaines.net has finally caught up now after the staging merge, at least with x86_64-linux *terpri idly muses about getting guix to run on the librem5 or the pinephone-whatever <terpri>probably best to wait for signal's desktop support to improve a bit, but my lineageos phone is getting long in the tooth <leoprikler>dummyuser: you can probably prepare something along those lines by using the barebones template instead of the desktop one <leoprikler>however, I don't think that's something you can do from grub <dummyuser>Too bad, then I'll have to fire up the installer again. Thanks though :) ***chrislck_ is now known as chrislck
<fnstudio>hi all, `guix environment --container ...` gives me an error ("unprivileged user cannot create user namespaces"), which i think is expected since i'm running guix on debian <fnstudio>i understand this can be fixed by `echo 1 > /proc/sys/kernel/unprivileged_userns_clone` <fnstudio>i was wondering if there could be any security drawback in doing that (on a single user machine) <civodul>some fear that unprivileged user namespaces might introduce vulnerabilities, but there's no serious known issue currently <hapster>I had a problem with my main user (regarding environment variables), and creating a new user did show that the problem was specific not general. Now I am thinking about how to best move my data from a to b. <hapster>or, to be more specific: I would generally like to keep the user. Thus, my idea would be to re-create the user after securing the data on a test user. Is there anything specific that I would have to keep in mind? <fnstudio>civodul: cool, yes i understand there's some risk but good to know there shouldn't be anything immediately serious, thanks v much <dummyuser>leoprikler: The startup messages disappear, the screen turns black with just a cursor blinking and the laptop is stuck there and then. Hitting Ctrl - Alt - F2 and the like don't take me to the console at that point <leoprikler>fnstudio: as an alternative, you might control over who gets to spawn containers through acls <dummyuser>Hmm, good idea. I selected it in the installer. <leoprikler>In that case ssh into your machine and reconfigure it with something lighter. In particular, you might just want to drop gdm so you can get terminal access <leoprikler>on the other hand, you might also want to investigate what stops gdm from spawning <leoprikler>/var/log should have some pointers in that regard <dummyuser>SSH works like a charm, thanks for the help. Should be able to get on from there :) ***modula2 is now known as defaultxr
<Rovanion>I got Geiser running in emacs, but whenever I run `(use-modules (gnu packages x))` the guile process locks up one thread at 100% and seemingly does nothing for a really long while. Is there a way to figure out why? <ioa>Good morning Guixers! Looking forward to Guix Days on Monday. :) <nckx>sneek: later ask wleslie: What happened? Probably worth reporting a bug. There's no technical reason Guix couldn't keep better track of active GC roots. <fnstudio>leoprikler: oh interesting, thanks for mentioning acls - although the idea is to finally move to guix system so i think i'm happy with a quick workaround now (i.e. echo 1 > ...) <nckx>sneek: later tell daphnis: Guix doesn't have any relevant Ada compilers, and I'm not aware of any that could be packaged (GNU GNAT isn't currently an option as it needs another GNAT to compile itself). The only Ada compiler in Guix is Ada/Ed, which is too old to be useful in practice. It could be useful to bootstrap an ancient -- and very hypothetical -- Ada '83 version of GNU GNAT, if any exist. <zimoun>the bar means what is already done based on previous build for the same package, right? <roptat>mh... if the guix daemon is offloading two builds to the same machine, I see it exports some dependencies (sources, inputs), twice if there is an overlap. Is that only duplicated in messages, or does it use twice as much bandwidth? <leoprikler>I don't think you can completely exclude that case, but there might be cases, in which only the message is printed before Guix notices, that it's already present. <leoprikler>That being said, I'm not quite sure how the exact same input would be sent twice in parallel – I haven't read that far into Guix' source. <PotentialUser-62>If I want to install tor through guix on top of my existing ubuntu, is it sufficient to run `guix install tor` as root? And will it pick up the existing torrc? <roptat>I don't think so, on the guix system we need to use a service for that <roptat>on a foreign distro, it's not possible, so I don't know what tor would do in your case <valerii_leontiev>I've added substitute for this channel but it is still trying to build kernel from source <leoprikler>While discussing that repo is somewhat taboo here (given our policy against nonfree software), they themselves point out, that there are no substitutes for nonguix. (See their README.) <davidl>How do you add a file to /etc/pam.d/? I am trying to run vsftpd but it seems that I must have a vsftpd.pam file installed. <civodul>you don't "add a file" to /etc/pam.d <civodul>instead, you would write a service that "extends" pam-root-service-type <civodul>where pam-root-service-type represents PAM <davidl>civodul: ok. I had hoped to test that all things work before I started with writing it as a service. Is it possible to add something quickly with modify-services? <roptat>maybe with simple-service, that allows you to extend the pam-root-service-type <roptat>does vsftpd package provide that file? it would be the easiest I think <davidl>roptat: Yes, there is such a file in the unpacked tarball. <pinoaffe>hi guix! `guix deploy' keeps failing, with guix deploy: "error: program `/gnu/store/ni87ig3m875yy6qh00n65xyg6p724gz5-guix-1.1.0-10.141b5c1/bin/guix' failed with exit code 1", where can I find logs? <civodul>pinoaffe: could you show all the output? <davidl>roptat: do you have an example of how to do that? <civodul>pinoaffe: did you register the signing key of the head node on the target node? <civodul>with "guix archive --authorize" or with the 'authorized-keys' field <civodul>i think error reporting improved a bit in this area, but i'm not 100% sure <civodul>before authorizing it, could you try updating Guix on the target node? <pinoaffe>sure, iirc I did that ~2 days ago but my memory may be failing me <roptat>davidl, nevermind, it doesn't take a file, but a more structured thing in guile; you can find an example of the value in some services, like lsh (gnu/services/ssh.scm) that extends the pam-root-service-type <roptat>for the simple-service, you can do something like that: (simple-service pam-root-service-type <associated-value-for-vsftd>) <roptat>sorry, I got it wrong: (simple-service 'vsftpd-pam-service pam-root-service-type <associated-value-for-vsftd>) <davidl>roptat: thanks! Ill see what I can come up with. <joshuaBP`>Hey guix, I'm trying to get my sway service running. I'm essentially trying to debug "sway-service-type", "sway-shepherd-service", "sway-activation", and "default-sway-config". I can run each of these functions. eg: (gexp->derivation "build-sway-config" (sway-activation (sway-configuration))), which returns a procedure. How can I execute that procedure to make sure it's "working"? <pinoaffe>civodul: `guix pull`-ing on both machines and authorizing the key sadly did not change the output one bit :( <civodul>pinoaffe: could you try "guix copy --to=target whatever" from the head node? <pinoaffe>civodul: okay, that fails in much the same way <civodul>pinoaffe: on the target machine, could you run "strace -p $(pidof sshd) -f -s 500 -o /tmp/log" (as root)? <civodul>and then run "guix deploy" from the head machine <civodul>note that /tmp/log will contain sensitive material such as keys, so don't publish it as is <civodul>but you can share just the relevant bits, or redact it, or send it privately <Rovanion>I may have asked this before but is it possible to ask why a package is installed? Similar to to `aptitude why` on a Debian system. <Rovanion>I've got a library that is failing to build on my system, and I was figuring that I might just remove it. <roptat>are you explicitely asking for the library, or is it a dependency of one of your packages? <Rovanion>It's a dependency of something that I've got installed. <roptat>when the library fails to build, I think guix should show a trace of all affected packages that you were trying to build <roptat>or maybe not with the default verbosity level, not sure <Rovanion>You're right, it does. Nomacs. Damn. That's a package that I've added and now its borked :/ <Rovanion>Well, one of its dependencies (vtk) is broken. <roptat>are you on a recent guix revision? <Rovanion>Was just running `guix pull` and `guix upgrade`. So I hope its the latest revision. <Rovanion>Yeah, its weird that its building to begin with. <Rovanion>guix is hashed (/home/rovanion/.config/guix/current/bin/guix) <wonko_the_sane>will i have to wait ages to see a recording if i miss the stream ? <ioa>This is an excellent talk. <bqv>How does guix deploy work? <ioa>The drawings, the narrative, the pace of speech, 100 points to all <ioa>I love this format, the speaker can and does answer questions in the chat during the talk <ioa>you get to ask and answer way more questions, and the talks are of higher quality <dftxbs3e>we all know there is only one correct syntax : lisp /troll <ioa>:D I guess here we all agree that's true dftxbs3e <dftxbs3e>there lacks some kind of awesome-guix list *dftxbs3e is back to debugging gnutls build failure on ppc64le <Rovanion>Right, getting things done: Is there a function for resolving a string, like "python-django", into a symbol for a package that can be used in a list of packages for a guix environment? <bqv>Meh, nevermind, I'll work it out later <bqv>Here's a more interesting question: theoretically could I take a guix NAR and insert it into nix? <civodul>bqv: theoritically i'm not sure, but practically no <bqv>NAR is a pretty dumb format right, I feel with trivial cases I could run it through a s/gnu/nix/ and maybe get away with it? <bqv>Dumb in the academic sense, of course <bqv>Thought it was basically just tar. Fair enough <civodul>bqv: it's conceptually "like tar", minus metadata like permissions and owner/group, plus an appended signature <civodul>pkill9: the HPC devroom is done for today, but the GWL discussion keeps going in the talk's channel <pkill9>does anyone know of a tool for wayland/wlroots that just takes user input? <pkill9>actually I can use rofi, and give option to move all windows to other workspace <pkill9>dftxbs3e: i mean something you type into and it returns what the person typed ***amiloradovsky1 is now known as amiloradovsky
<fnstudio>i've made it to watch ricardo's talk on GWL, any guix-y (or guile-y) things that i missed from today's fosdem? <fnstudio>civodul: thanks, sure, i won't miss it! :) <bluekeys>Hi guix, I'm struggling to understand how to get a bluetooth headset working. Can anyone give me some pointers? <bluekeys>My pulseaudio doesn't appear to be running as a daemon. pacmd gives no pulseaudio daemon running. <bluekeys>I assumed it would be running as part of desktop-services <hapster>I am trying to update a package where I need to replace the build phase's "make" with "make -C build all build-data" <hapster>somehow I cant manage to get it to work, I've tried different combinations <hapster>so far I managed to get to (invoke "make" "-C"), but I am unsure how to put the others <dftxbs3e>hapster, (invoke "make" "-C" "build" "all" "build-data") ? <dftxbs3e>that will run exactly the command you said you want to <hapster>the command has failed with status 2 <hapster>I am not sure if I am doing this right though, I am following the tips mentioned in a github issue <apteryx>rekado_: thanks for the carefully crafted presentation. I enjoyed it. <rekado_>good thing this was pre-recorded. I can barely even form sentences today. <apteryx>Too bad your chapman stick was unplugged ;-) <Ikosit>Was there an attempt to use pipewire-media-session with guix? <bqv>Guys, can I deploy a system if I know it's storepath? <bqv>Without "guix system" etc <sneek>Welcome back marusich, you have 1 message! <sneek>marusich, dftxbs3e says: about libstdc++, I remember that nckx told me everything had to go in /lib so we should rather patch gcc to lookup libstdc++ in /lib instead of /lib64, I remember starting to patch that but never committed anything. <marusich>dftxbs3e, nckx, so lots of other packages will break if we don't do that? I haven't built much else but have not encountered a problem so far. If you saw problems in the past, then it's something we should change, yeah. <bluekeys>You might not be able to connect to the Bluetooth network via this machine <dftxbs3e>marusich, I got cmake-bootstrap failing now <dftxbs3e>marusich, re /lib - it's a GNU Guix convention apparently, not sure if anything will break due to that but I remember having some issues that pushed me to this yes. <marusich>It's a GNU Guix convention to put 64-bit libraries in /lib rather than /lib64, you mean? <dftxbs3e>marusich, to put all libraries no matter what they are in /lib yes <marusich>Hm OK. Regarding https://paste.debian.net/plain/1184292, it's in core-updates... I did try merging core-updates into wip-ppc64le the other day, but I didn't push that to Savannah because (1) cbaines said core-updates isn't at a stable point (guix pull apparently doesn't work due to build failures) and (2) other stuff failed after I merged it. <marusich>Since there's no guarantee that everything is working anyway right now, perhaps we should just merge core-updates now and deal with whatever breaks. <dftxbs3e>marusich, I wouldnt do this, it will increase our trouble. <marusich>We can just wait until core-updates is at a stable point. <dftxbs3e>Better cherry-pick individual patches so things work and merge in master, also because this bootstrapping works with Glibc 2.31 but core-updates has 2.32 and soon 2.33 if not already and I don't want the ground the move again I've been going through this several times already it's annoying <marusich>In the meantime, I think we should probably cherry pick the individual commits we need. <marusich>My understanding is that cherry picking will not make it difficult to merge things later, although it will "uglify" the history a little bit (but Git can actually do quite a good job of filtering out changes that introduce the same thing, in "git log" etc.) <marusich>I already did it with one of efraim's commits from wip-ppc anyway <marusich>unless somebody has strong feelings about it <apteryx>marusich: I think it's rather stable at that point, the guix pull problem must have been the guile-ssh test suite failures, which were fixed. <cbaines>dftxbs3e, would you be able to update your Guix Build Coordinator agent at some point? <dftxbs3e>it has unattended-upgrades on, and with the agent in the restart list <cbaines>dftxbs3e, I assume so, the uuid is 79cc... <cbaines>I'm not sure when I last updated the package, but if you're using that, I can update it shortly <cbaines>marusich, dftxbs3e also, I should be getting some ppc64le hardware next week, so I'm going to probably be more interested in the Guix porting then... <dftxbs3e>cbaines, system is on 221985ce6bd8036ceac3d1973be3dc084f52b1de <dftxbs3e>it was set to update every hour.. a bit too short, will make it daily <pinoaffe>okay, so if I have a public key I want to authorize in my guix-service type, how do I create a "string-valued gexp" that returns it? <pinoaffe>(or does anyone have an example of a guix config that adds extra authorized keys?) <pinoaffe>never mind, the guide contains an example :) <pinoaffe>civodul: thanks for all the help, it seems like just running `guix archive --authorize` was insufficient, adding the key to the new system configuration seems to have done the trick <pinoaffe>(though now I'm having issues with postgres :) ) <efraim>marusich: everything needs to go in /lib, I ran into that problem with aarch64. b773e9b005fe0479f6504dcbb9d44d5a380de95e <marusich>efraim, understood. so that is ineed a guix convention? <marusich>On traditional distros, my impression is that /lib64 exists mainly because it might conflict with /lib on the same file system, i guess <efraim>I think it was something like that. with how guix works we try to stick everything back in /lib <marusich>I already pushed a commit to change gcc-final to link against libstdc++'s /lib64 directory, but I will see about reverting that <marusich>dftxbs3e mentioned we should patch gcc to look in /lib... but should we instead patch libstdc++ so it installs to /lib? <marusich>gcc-final was already looking in /lib for libstdc++ <marusich>the problem was that libstdc++ installed its things to /lib64 <efraim>for aarch64 it was a suprisingly small snippet for gcc <dftxbs3e>marusich, hmm if gcc is already looking in /lib then yes patch libstdc++ to install in /lib <marusich>I'm going to step aside, make a list of things mentioned here, and try to do some of them on the wip-ppc64le branch. <efraim>unhelpfully, I don't see an gcc/config/powerpc folder in the gcc tarball <marusich>i was wondering why the name rs6000 kept coming up in ppc-related things <efraim>I'd poke gcc/config/rs6000/t-linux64, i'm not sure about t-linux64bele, t-linux64le, t-linux64lebe <apteryx>raghavgururajan: I was planning to use it as a proxy to the different SMTP servers I have to deal it <rekado_>civodul: I’m trying to package GWL 0.3.0, which needs all Guile packages to use the same Guile as the “guix” package (i.e. guile-3.0-latest) <rekado_>I’m trying to use package-input-rewriting but get weird errors. <rekado_>probably because of top-level circular references or something like that <dftxbs3e>cbaines, running upgrade after your last commits <cbaines>dftxbs3e, is that the change I've just pushed? If so, you picked up on that rather fast! <dftxbs3e>cbaines, I'm subscribed to guix-commits heh.. <fnstudio>is it a coding best practice? or are they interpreted by a processor for creating docs? <fnstudio>or am i supposed to enable a specific emacs mode to take advantage of them on my system? <dftxbs3e>marusich, It would be good to push to master as soon as possible something that builds guix-build-coordinator things on powerpc64le-linux <dftxbs3e>We absolutely need to do it against master because core-updates is already on Glibc >2.31 where bootstrapping doesnt work anymore <civodul>rekado_: the trick would be to delay the reference to 'guile-3.0-latest', such that it's only ever accessed from an 'inputs' field <dftxbs3e>marusich, make sure to download the patches I sent you as paste.debian.net because they expire in 24h <dftxbs3e>marusich, more specifically when we can get the guix package to work with bootstrap binaries we should push to master <dftxbs3e>so that we can iterate from there, and secure the Glibc 2.31 bootstrap and be done with it <marusich>If we do that, it will certainly rebuild the world, so we might have to talk about it with others first. <civodul>rekado_: but wait, that means GWL 0.3.0 is out! wo0t! <dftxbs3e>marusich, I am not certain it requires rebuilding world but yes should check carefully <marusich>Why does dftxbs3e, regarding guix-build-coordinator need to build on master specfically? <dftxbs3e>marusich, Ignore that, I meant guix, but guix-build-coordinator is the nextgen CI thing which will allow us to get better feedback and collaboration around powerpc* <marusich>OK. But why does "guix" need to be buildable from master? For "guix pull" etc. you can specify an alternative branch. <dftxbs3e>I was trying to think at what point can we stop stressing about missing bootstrapping with Glibc 2.31 and I think I found how: make guix package work using bootstrap binaries and glibc 2.31. <dftxbs3e>core-updates uses Glibc >2.31 where we cannot bootstrap anymore <dftxbs3e>I don't want to deal with them really, I'm tired of them. <dftxbs3e>I absolutely want to merge this within the Glibc 2.31 window where master currently is <dftxbs3e>Glibc 2.32 introduces new requirements for powerpc, in terms of GCC version etc.. and floats mess again. <dftxbs3e>I remember it causing breakage in my tests. Don't want to risk it anymore. <dftxbs3e>This is also why we should not merge core-updates in wip-ppc64le branch for now. <marusich>OK. Do you think we should introduce logic to keep using glibc-2.31 for bootstrapping? Currently the bootstrap code uses whatever glibc version is current, and it happens to be glibc 2.31 on the wip-ppc64le branch and master <dftxbs3e>marusich, yes well it would be nice but everything is so interdependent I'm really not confident with doing that either. <dftxbs3e>I like when it works like now, I'm almost terrorized to touch it again now. <marusich>I guess what I mean is, suppose we do what you suggest. The people working on core-updates will want to upgrade glibc anyway - so what is the path forward for them/us to upgrade glibc? <marusich>Right. I hear you. It's exhausting when nothing seems to work. <marusich>It seems to me like retaining glibc-2.31 for bootstrap on all arches seems like the right approach. <marusich>I mean, we could selectively do it just for ppc64le, but why not just do it for all arches? <dftxbs3e>marusich, powerpc64le bootstrapping will work at a particular commit with glibc 2.31 and then it wont. It wont be a big deal (it's already that way for other arches, if you try bootstrapping from latest commit it doesnt work). <marusich>when you say bootstrapping, do you mean "building up all the packages from the bootstrap binaries" or "building the bootstrap binaries"? <dftxbs3e>Once you bootstrapped a guix package then all future commit revisions will build fine (even glibc 2.32+) <dftxbs3e>marusich, building from the bootstrap binaries <marusich>oh. ok. I guess I misunderstood what you meant. <marusich>Huh. I don't really understand why that is true, but I believe you and I see what you mean. <marusich>But to build Guix, we can do that without merging to master, right? <marusich>We could build Guix from the wip-ppc64le branch and then use it, right? <dftxbs3e>marusich, yes we can do it without merging to master but then the bootstrap path is unclear and not very well documented <marusich>I mean we would merge the branch eventually. <dftxbs3e>And as soon as "guix" package builds with it, that's what I want to do to set it in stone! <marusich>I'm thinking we would build guix from wip-ppc64le, use it, eventually merge core-updates into wip-ppc64le, and then merge wip-ppc64le into core-updates, and then merge core-updates into master. <marusich>It would just arrive in master via core-updates. If we build guix from wip-ppc64le early on, we can bypass the issues you mentioned, right? <marusich>well, either way, we can focus on building guix first, and then decide where to merge later, right? <marusich>for now i don't plan to merge core-updates into wip-ppc64le. <dftxbs3e>marusich, yes, well that's what I am doing now <dftxbs3e>valerii_leontiev, Run $ bzip2 -cd <log_file_path.bz2> | less <dftxbs3e>valerii_leontiev, You will find more clues as to why <valerii_leontiev><dftxbs3e "valerii_leontiev, You will find "> What means <log_file_path> ? What do I need to put there? <gnutec>Sad! So guix can't fix a profile, restore or create a new. That is bad! Back to Ubuntu. Hope he create a boot recover and show a way to conect to a wifi in a manual instalation, because what is write in Guix.pdf, doesn't work. 😥 <dftxbs3e>valerii_leontiev, in the screenshot you sent there's a log file path that ends with .bz2 <dftxbs3e>gnutec, How exactly is GNU Guix broken in the way you describe "can't fix a profile, restore or create a new"? Do you have any logs? <dftxbs3e>gnutec, and if you do not feel comfortable using GNU Guix System as your system you can always use GNU Guix on top of Ubuntu! <valerii_leontiev><dftxbs3e "valerii_leontiev, in the screens"> Are you kidding me? Look at this log <dftxbs3e>valerii_leontiev, Press "END" key to go to the end of the log, it'll be more telling there <cbaines>that package materialdecordation looks to fail to build <dftxbs3e>valerii_leontiev, GNU Guix is a rolling release distro so it's normal some packages do not work some times, it just needs to be fixed. The best is you send over that log file by uploading it somewhere. Like on https://drop.infini.fr/ for example <gnutec>dftxbs3e: I use a Guix System for a long time. When I upgrade to 5.10.11, the boot system broke. When I finally access the system, I use "sudo guix system init config.scm /" to recover the boot, but fail and broke my profile. All my app is there, but I only can access using "find /gnu/store -name *-abiword*". So why is there not a command to restore/fix/create a new profile? <cbaines>gnutec, profiles are very different things from system generations <marusich>Maybe it "just works" most of the time, I guess. <marusich>I can definitely add logic to the package definition of libstdc++ to tell it to install libs to /lib, but I'm wondering why the gnu-build-system doesn't do that already. <gnutec>dftxbs3e: it's crasy! For so long I try to follow guix.pdf to get in the wifi with wpa_suplicant.conf, but always fail. <dftxbs3e>valerii_leontiev, I could try building the same package and get the same error so no need to upload the log, I've got it too now. Will try fixing when I have some time, until then you'll have to wait! <gnutec>cbaines: No! I just need to fix it. Simple like that. I don't care if I have to create all file guix to my user. <dftxbs3e>marusich, not sure how that works, but I've seen packages being patched when they install elsewhere than /lib <cbaines>gnutec, that's great, it's always helpful to have people like yourself working on finding simple solutions to complex problems, like recovering a system that won't boot. I think there's plenty of room for improvement. <marusich>regarding lib64 and gnu-build-system, I suspect that perhaps gnu-build-system should be changed to always set --libdir to /lib, but there might be existing package definitions that would be broken by that "correct" change because they fixed the problem by e.g. telling a package to look in /lib64 <marusich>so i think for now i will just make a change specifically to set --libdir in libstdc++ <gnutec>dftxbs3e: I access the system using my Guix System pendrive, press c on grub. I try everything. Create a link by my self of .guix-profile but nothing work. <gnutec>I only need a command to fix/recover/create my profile. Is there possible? No? Simple. <dftxbs3e>gnutec, hmm if you can access a grub instance from a usb pendrive I think you can boot using parts of the (broken?) config already present in your system. It will contain lines to boot into previous system generations that still should work, or the store is completely broken? There's no such command I am afraid, but if you still have your config.scm file just backup your home directory and reinstall, should get you up and running again quite <dftxbs3e>I think it's a lost cause trying to fix the GNU Guix System installation as-is, better to reinstall and restore home directory backup. <gnutec>dftxbs3e: yeh! I did "guix pull" then "sudo guix system reconfigure /etc/config.scm". But spend to much of my mobile data. So there is not a profile recover command. Ok! <apteryx>civodul: random thought; about setuid programs: if someone was to give a symbolic link instead of real target as part of setuid-programs list, the chmod 0 0 would attempt to change the mod of the owner file; no? <gnutec>I hope next update they create it, and add boot-repair in the pendrive instalation. <dftxbs3e>gnutec, I think there is manifests inside the home directory that can be used to reinstall each user's packages <apteryx>seems we should dereference the target, copy it, rename it if the base file name is different than that of the link, then apply chmod to that copy <gnutec>And back to Ubuntu and install guix make non sense. Why should I do that? Guix app still can broke and I'll lost at all again. <gnutec>Sorry! Put a "boot-repair" on guix instalation and a way to fix/recover or create a new profile and I'll try again. <nckx>Oh, s/chmod/chown/ I guess. <dftxbs3e>gnutec, GNU Guix is not a product with a warranty so we first and foremost all use what we build. You have the experience of a broken system so maybe you could document something to help create such a feature. <nckx>apteryx: If this is about security, what's the threat model? How does an unprivileged user abuse this? <dftxbs3e>gnutec, it's unclear in what way your system was broken, so without a record of this information it will be hard to do anything. <nckx>gnutec: It's not possible to create that because the problem is too vague. So the only way it will exist is if you create it, as dftxbs3e says. ☺ <gnutec>nckx: that is what I want. Create a new profile. <pkill9>i like guix cos i can leave it for a while and work with it some other time <nckx>gnutec: User or system profile? <nckx>Most ‘guix system’ or ‘guix package’ operations create a new profile. <gnutec>nckx: but I need a internet conection. <Rovanion>Is `make check` supposed to spew a lot of failures about failing to load modules? ***Noisytoot is now known as [
<civodul>apteryx: it's the sysadmin who choses what goes into 'setuid-programs', so there's no particular issue here <nckx>gnutec: It will re-use anything that's still in the store, so if you use the same version of Guix that was used to create the profile you've lost, and haven't GC'd in the meantime, it shouldn't download much. <nckx>But again, far too many unknowns to say anything particularly useful to you. ***[ is now known as ]]
***]] is now known as [[
<fnstudio>what's the recommended approach to deploy guix onto a VPS provider? i'd be looking for something that can automate the largest possible part of the process. i see guix deploy offers something for digital ocean <fnstudio>on some blog posts, however, i see a different approach: create an image locally and upload it to a VPS provider for then creating machines out of it ***[[ is now known as Noisytoot
<fnstudio>(relatively recent blog posts, i mean - post guix deploy and the digital ocean backend were introduced) <fnstudio>i'd also be interested to know of any guix-friendly VPS provider (i found one already) <gnutec>nckx: No. Now the system stop in "scheme@(guile-user)>". This is new. hahahahahaha <nckx>gnutec: That's the ‘rescue mode’ and TBH it's close to useless. It's technically possible to rescue your system from it if you're a very patient wizard. <fnstudio>s/onto a VPS provider/onto a VPS machine/ <civodul>noproto: lfam is frequently here, but perhaps you can ask your question anyway? <nckx>So I heartily recommend booting back into the installer instead, for luxurious luxuries like ‘tab completion’ and ‘globbing’. <nckx>You will not have a good time at the early boot REPL. <zimoun>rekado_: does it mean that GWL is almost releasable? ;-) <noproto>civodul: it isnt a question, just looking to deliver something to him <bqv>hey can i have some help. <bqv>so i tried to lustrate guix onto my laptop <bqv>it gets to the point of booting <bqv>but, when loading modules, it has an error when it reaches btrfs.ko's dependencies and throws an exception: "in proedure load-linux-module/fd: no such file or directory" <zimoun>rekado_: awesome! Even I am late by half hour. :-) Thanks for the inspiring talk today. <bqv>i don't know why that error's thrown, because if i use the bournish shell and the debugger i can manually verify that the paths it wants do exist <bqv>i tried building a kernel without btrfs as a module, to circumvent the issue, but then it won't build my initramfs <bqv>please, instruct me, i'm at an initrd repl now :) <gnutec>nckx: ??? Boot in "Install using the shell based process"? ***Noisytoot is now known as [\
***[\ is now known as Noisytoot
<nckx>Yes, and then switch away from the installer with C-M-F2 for a shell. <gnutec>nckx: Are you tell me to reinstall the system? <daphnis>does one have to use a module or something to boot from lvm? <sneek>daphnis, you have 1 message! <sneek>daphnis, nckx says: Guix doesn't have any relevant Ada compilers, and I'm not aware of any that could be packaged (GNU GNAT isn't currently an option as it needs another GNAT to compile itself). The only Ada compiler in Guix is Ada/Ed, which is too old to be useful in practice. It could be useful to bootstrap an ancient -- and very hypothetical -- Ada '83 version of GNU GNAT, if any exist. <bqv>oh, oh, ok! narrowed it down <bqv>every module loads fine except libcrc32c.ko <valerii_leontiev>Is it possible to add configured sway with waybar as one of desktop environments option? <bqv>ok, well maybe i should just make libcrc32c builtin <gnutec>So for the good of the guix system, do what I ask. Please! <dftxbs3e>gnutec, I think your behavior here is really bad and is getting us nowhere! <Rovanion>gnutec: I do not think they told you to reinstall. I think they told you to use the live-USB in order to rescue your system. <dftxbs3e>gnutec, nobody here owns you any help and if you are not being nice about it I do not think I am willing to help you in any way and that could be the same for everyone else. <gnutec>dftxbs3e: I don't speak english very well. <dftxbs3e>gnutec, I think that does not prevent you from being nice with people here. "So for the good of the guix system, do what I ask. Please" - Since when explicitly giving orders to volunteers is an acceptable behavior. <dftxbs3e>Things happen at their own pace, there's so many things to do, and each has its own varying priority. <civodul>mothacehe: hey! you gonna be around on Monday? <nckx>gnutec: Sorry, I was away (as mentioned). I'm not telling you to reinstall, just that the shell that you'll get from the installer (used as a ‘Guix live CD’) will be miles better than the initrd REPL and actually give you a fighting chance of getting your system to work. The actual work of doing so, however, is entirely yours. <gnutec>Add a boot-repair on guix instalation. Create a command about profiles, "guix package -m manifest -p profile" doesn't work. The guix.pdf instrution to "wpa_suplicant.conf" doesn't work, so try more. And in the guix blog, there is a instruction to create extra profiles, try hard about there too. Looks like GNU project has serious problem to write instruction. <gnutec>So for the good of the guix system, do what I ask. Please!* <nckx>Believe it or not, we've all been where you are, most of us many times. Asking for a rescue wizard to be written for you by volunteers instead... well, it tends to elicit a poor reaction in free software/hacker communities. <dftxbs3e>gnutec, if the manual isnt good enough, help make it better, we can't tell how bad it is because we don't need it like you now and don't have time to test things. <nckx>gnutec: Contributions welcome. <gnutec>I try to help! Something happen to my guix, because of me some time. But I do think they need to add this. <vagrantc>cbaines: your post about a qa site for guix seems to be answering it's own question. the answer is "of course!" :) <dftxbs3e>gnutec, If you don't explain how things do not work *precisely* here or in an issue submitting by email nobody can do anything, it's not even about willing to do it or not. <nckx>There is no mysterious force of people motivated by problems that aren't theirs. <nckx>And you're not motivating them any other way, so... <marusich>gnutec, for what it's worth, I don't think anybody is denying your frustration. It is frustrating when things don't just work. I find it helpful in times like that to take a break, or ask for help if you're just really stuck on something. You're not alone, and many people (like those interacting with you now) are willing to help, especially if you explain the details of what you tried and why it did not work. We're all trying to make things <marusich>better. But like nckx is saying, you are uniquely positioned and motivated to solve the problems that you face. <marusich>I often get stuck on things I cannot solve, so I understand. <gnutec>But now my system stop work anyway. Any help is unseless now. <nckx>It's not that we don't care about you, or about increasing the number of Guix users (although we care a lot less about that than you seem to think). <nckx>But nobody is going to put hours of work into something they don't need based on a vague ‘it broke’ spec... <dftxbs3e>gnutec, Quit GNU Guix System and use it on top of Ubuntu for the time being, maybe in few years GNU Guix will have a stable channel where this will not happen. For now, it's work in progress. <cbaines>vagrantc, haha, well, even I don't think listing problems on a page is an effective strategy for reducing the number of problems, I'd really like to see more done before changing things on the master branch to stop problems appearing there <vagrantc>cbaines: being able to find issues is, though :) <dftxbs3e>gnutec, But I am also certain you can just reinstall GNU Guix then restore a backup of your home directory and that particular issue probably wont happen for a while, never happened to me ever. <vagrantc>cbaines: i guess i use the tests.reproducible-builds.org infrastructure to look for things to work on, so various angles on broken things is really useful <cbaines>vagrantc, well, if someone wants to fix things, then maybe they'll be helped/motivated by having a clear list of problems <nckx>cbaines: Just read your mail &: absolutely! <dftxbs3e>cbaines, this would be really helpful for me, I've been poking around with "$ guix refresh" to try and update some packages at random. Would be easier with all the data sorted and ordered nicely. <dftxbs3e>Automated "issues" on outdated packages (that you can filter if they go to core-updates or not, or if a patch is already available..) <cbaines>dftxbs3e, right, that's a bit of a more complicated problem, but I'd also really like to see more automation around that <dftxbs3e>cbaines, ultimately I would like to trust the data service to tell me what I can work on without duplicating anything (if a patch is already available..) <cbaines>I think it would be great to have some tool that pushes branches with package updates, so that people can come along and "adopt" upgrades that they can see don't cause anything to fail to build <gnutec>dftxbs3e: No. I will use Ubuntu with snap. <cbaines>dftxbs3e, ah, and yeah, the "is there a patch sitting somewhere which touches this package?" problem is also one I'm interested in <cbaines>I've contemplated using the Guix Data Service data to help with that, and it probably could do, especially with version upgrades <dftxbs3e>By the way, I am interested by commit access, is there a way we can do this quickly? <nckx>dftxbs3e: You can do so without commit access, which is given only to people with a history. <nckx>cbaines beat me to the link ☺ <gnutec>Remember. wpa on guix.pdf, create profiles command and some boot-repair. <nckx>Basically, you submit a good deal of good patches & get 3 people to vouch for you. <dftxbs3e>By that I meant, are the 3 people ready to vouch for me here? <dftxbs3e>I know nckx and marusich expressed intent to do so, but I'm missing a third. <cbaines>dftxbs3e, I'd also really like to encourage reviews by people who don't have commit access <cbaines>in some sense, less people with commit access is less attack surface <dftxbs3e>But it kind of defeats the point because the person with commit access will not trust the review? <nckx>dftxbs3e: I haven't seen enough patches of yours to do so myself. Are there, in guix.git? <nckx>dftxbs3e: That's not how it works. <marusich>dftxbs3e, I tried this patch but it seems like libstdc++ ignores --libdir? <cbaines>dftxbs3e, on the trust issue, maybe there needs to be a list of people who are "reviewers", who have a history of properly reviewing changes <nckx>Nobody cares about your commit bit if your review is good. If you raise good points, you raise good points, the end. <dftxbs3e>marusich, yes.. that doesnt surprise me. "$ grep -R /lib64 ." in the rs6000 folder of gcc <dftxbs3e>Substitute that with /lib, and be done with it <nckx>Committers won't blindly accept your LGTM but you're significantly lightening their load. <cbaines>dftxbs3e, it's more an issue of trying to really scale the rate of change, the rate at which patches are reviewed, without having to have it linearly correlate with the number of people with commit access <cbaines>(I also think less changes should be pushed without review, so having some separation would help there too) <lfam>I agree with cbaines, reviews by noncommitters are really helpful <lfam>I definitely find them valuable <nckx>gnutec: The first one sounds like a great first contribution (assuming it's your first); the second is too vague and probably not something actually useful and the third can only be done by the person having the boot problem -- i.e., you. <dftxbs3e>I feel like reviewing as a non-committer means duplicating work with the committer (compiling, running tests, ..) in case the non-committer missed something the committer will check. <nckx>That's too binary a view. <lfam>In cases where I have used these reviews, the only thing I've done as a committer is applied the patch and built whatever the patch adds <vagrantc>i felt mixed about getting commit access ... before i had it i really appreciated the review as i don't really understand this guile stuff :) <cbaines>dftxbs3e, well, compiling and running tests sounds like it can be automated entirely, then no one has to do it! <lfam>But, I understand your concerns. They are valid and it's tough to know if you are doing enough as the noncommitter reviewer <nckx>dftxbs3e: It's like saying double-checking or team review is redundant because the others are duplicating work that one person could do. <vagrantc>and when i'm not 95%+ sure of my changes, i still submit it for review <dftxbs3e>cbaines, yes it would be great to do it automatically. <vagrantc>but i can see the argument that all patches should be reviewed even with seasoned committers <dftxbs3e>cbaines, I noticed your patchwork instance already does it, but it doesnt append to issues with results so <nckx>Having gitlub-style automated check(list)s would be great. <dftxbs3e>vagrantc, yes of course, commit access does not mean push without review. <nckx>dftxbs3e: Hm. It frequently does. <cbaines>dftxbs3e, yeah, currently people have to go digging around in the Guix Data Service to find the results/status, I've got plans to fix that and put the information in the right places <nckx>We trust committers' judgment on that. <dftxbs3e>But it certainly means I can as an individual lighten the total number of pending patches by reviewing them and pushing them without time-consuming back and forth. <dftxbs3e>I see lots of patches that are trivial to review and push. <nckx>Trust isn't binary, and it is transitive. <dftxbs3e>The other reason I want commit access is because I would need to work on the wip-ppc64le branch.. <dftxbs3e>And I currently cannot that I have to pipe patches through marusich <cbaines>At least for now, if you've reviewed something and think it's ready to be merged, you can always say so in IRC <nckx>Yeah, that's entirely our/Savannah's shortcoming on branch-level access control. <lfam>I have often wished to be able to let people commit to e.g. "feature branches" <marusich>I would personally prefer it if dftxbs3e had commit access to make it easier to collaborate for the power9 port, since honestly he is more knowledgeable about the domain than I am. I don't mind committing on their behalf, but I imagine it's probably discouraging for them and increases friction. As long as dftxbs3e is following the guidelines that we all follow about what branches to commit, the format of commit messages, and seeking review of <marusich>non-trivial changes before putting stuff into master/core-updates/staging, I think it's good. <cbaines>I think there's a precedent been set with the recent Outreacy round for having commit access, but for branches other than master right? <cbaines>I wasn't really paying attention, but I think that's the changes I saw <dftxbs3e>I think I have numerous patches that I submitted where I learned a lot about how to contribute to GNU Guix and I feel like I am ready now. <cbaines>dftxbs3e, don't let the discussion of reviewing without commit access put you off going through the process to get commit access <nckx>dftxbs3e: I definitely trust you enough to grant you commit access to a ppc64 branch with no access control but your word ☺ <dftxbs3e>From the manual it says that I must find 3 people to vouch before even sending any email, so here I am :-) <nckx>dftxbs3e: How did https://issues.guix.gnu.org/46139#5 (gnu packages tls) happen, by the way? Just want to make sure you've adjusted your workflow to reduce the chance of ‘guix pull’ breakage before I vouch for you. <pkill9>would it be a bad idea to have a --roll-forward flag to complement --roll-back? <cbaines>dftxbs3e, asking on IRC is probably not direct enough, I'd directly and privately ask people who've reviewed your patches <dftxbs3e>nckx, when you sent that I had already sent another patch with a fix. I initially contributed this to a third party channel and copied the definition without the imports, then committed that, then figured out I forgot the imports, made the modification then committed again but without "git add", so it went out by email by mistake. <rekado_>nckx: we missed you at Au Bon Vieux Temps! <nckx>dftxbs3e: OK. Basically I trust you to submit good code (never doubted that!) but just want to make sure you're well-versed in our conventions & habits too. <nckx>Which seems to be the case. <dftxbs3e>nckx, I had already tested the package definition with the third party channel and neglected re-testing when integrated within GNU Guix. But I'll admit I just wanted to get it over with and sent it over to come back to it later. Just in case some other people wants to do the work. <nckx>rekado_: I really wish I could have made it. <dftxbs3e>nckx, also, I am not in the same mindset when I review some contribution vs I contribute something that I know will be reviewed. <nckx>dftxbs3e: I'll happily vouch for you, but then I would have needed little convincing for quite some time. <nckx>I'm very happy you're around. <dftxbs3e>(the latter case I allow myself to be a bit less rigorous, and I submit -v2's as soon as possible) <nckx>dftxbs3e: Right. I thought as much, but hey, have to ask at least one interview question ☺ <dftxbs3e>The reason is that I prefer to share code so other people can take over than keep code that does not work on my computer forever because I lack time to finish. <Anonymous_>Someone have used profanity after the upgrade to 0.10 ? <bqv>haha! checkmate bastards! it booted <nckx>bqv: Damn it! You showed us. <nckx>Anonymous_: What's wrong with profanity? <Anonymous_>it dont initiate sessions even with myself if i try with two instance of profanity in my computer using the same version <nckx>Best file a bug report by mailing bug-guix at gnu.org. <Anonymous_>the problem is just with criptography.. profanoty is running "ok" <nckx>Maybe CC tanguy at bioneland.org, who updated it to 0.10. <nckx>They probably didn't use OTR. <lfam>I think I saw another report of OTR not working in profanity recently <nckx>lfam: Where? I didn't find one on issues.. <lfam>Maybe the same person :) *nckx dives back into Linux hibernation voodoo. dftxbs3e, if I wasn't explicit enough above: I vouch for thee. <dftxbs3e>nckx, cool thanks! marusich I believe should be second, and I am missing one last :-) <maxxcan>the last day I asked about the use of jitsy in guix. Today I discover ungoogled-chromium package and works perfectly <maxxcan>I say if anyone have the same problem <bqv>So I really like the fact that boot is interactive, in the initrd. It was annoying at first, cause I'm not used to it, but then it became insanely useful in working out the issue <bqv>That and the lack of systemd, I've got high hopes for this OS... <nckx>[nervously] bqv: What's wrong with systemd these days? <bqv>nckx: same qualms as ever. It's poorly written, obscenely bloated in code and scope, seems to be growing like a virus, and at this point functionally removes the element of choice w.r.t init system <dftxbs3e>Not sure about that, lots of FUD around it. <bqv>I use nixos and the consensus there is "but why would you not want systemd?", which upsets me enough on it's own <vagrantc>Anonymous_: also, you could pretty easily test reverting the profanity update and see if that works around the problem <OriansJ>dftxbs3e: well FUD is easy and cheap. Getting people to work together on an INIT is a miracle <vagrantc>Anonymous_: to test if it isn't a problem in some other library <bqv>Yeah, sure, "poorly written" is subjective I guess, but the rest is hard to deny... <nckx>Maybe, but only because it's entirely subjective. <dftxbs3e>bqv, I think GNU Guix uses GNU Shepherd not because of systemd being anything but because having an init system that can be programmed in Scheme is a major advantage for GNU Guix. <rekado_>not trying to troll, but doesn’t “growling like a virus” also fit Guile in PID 1 (and *everywhere*) <nckx>‘Yeah but it's *our* virus.’ -- every ‘bloat’ disccussion ever ☺ <dftxbs3e>One could argue GNU Guile is an insecure C program that JITs untrusted code some times as root *rekado_ doesn’t need to “try” trolling; is naturally gifted <OriansJ>rekado_: and replace everything above a shim microkernel like hurd <dftxbs3e>I happen to care less about security than I care about GNU Guix philosophy and values this time. But I can't wait for GCC to grow a Rust frontend and for GNU Guile to be rewritten in Rust so memory-safety yay! <OriansJ>I mean you have got Gash (bash replacement) Gash-utils (coreutils replacement), MesCC (GCC replacement) a bunch more all running on Guile <rekado_>dftxbs3e: I like to see more of Guile written in Scheme. wingo just wrote in #guile: wingo has "read" port to scheme almost done, respecting reader options and everything <dftxbs3e>nckx, the GCC Rust frontend will help bootstrapping since it's written in C++. <OriansJ>So a scheme only Guix is certainly a possiblity if we are talking viral expansion. <dftxbs3e>I am more concerned about the security of the GNU Guile's code in terms of memory safety, even more with the JIT. <OriansJ>nckx: well didn't we already have a bootstrap for rust? (It is kinda long but not unexpected) <nckx>Guile's primary aim (besides ‘do the scheme good’) is to integrate deeply with C programmes, so a Rust rewrite is not happening soon. <nckx>OriansJ: It's not quite n → n+1 → n+2 … but still too close (and long), maybe a GCC front-end would help. I'm just happy GCC will do the Rust and remain relevant beyond free software nuts. <dftxbs3e>Writing anything in C today for me as person who works in IT security professionally usually is creating inevitable new memory-safety bugs and therefore security issues. All that when there is a solution available that works well for most of it: Rust. <dftxbs3e>There's still a cultural issue in Rust when it comes to licensing so I hope GCC Rust will help that. <dftxbs3e>(Lots of misinformation about copyleft licenses, most people choose MIT/Apache2 by social conformism when it's not even in their interest) <bqv>dftxbs3e: no doubt, but it not being systemd is still a plus in my books <nckx>That's true for most trendlangs/‘open source’ in general though. <dftxbs3e>nckx, This time that comes from the core team itself. <OriansJ>dftxbs3e: working as a security professional myself; I can say even Haskell and Rust have memory-safety bugs because they were written by humans. Programs with formal proofs of correctness also have later been found to have bugs too. <bqv>OriansJ: but the kernel isn't scheme ;) <dftxbs3e>OriansJ, they do, but day-to-day core-writing isnt concerned by this risk. <pkill9>i thought formal proofs of correctness would prevent bugs <dftxbs3e>It is better to minimize locations where memory-safety bugs can happen than to not even try to do that (like with C). <OriansJ>dftxbs3e: well dat-to-day code writing isn't concerned about security either generally. <dftxbs3e>OriansJ, software in the GNOME eco-system is commonly written in C for example. It is day-to-day for them. <OriansJ>pkill9: proofs only work if the assumptions hold and humans are bad at making assumptions. *OriansJ doesn't mention all of the Node.js brogrammers <pkill9>here's an assumption: I am right, therefore, I am right <OriansJ>one needs to accept that the world doesn't care about security, only those of us who do care about security are able to improve the security problem. <dftxbs3e>Proofs quite expensive to obtain, Rust gives memory-safety on the code you write by default with little effort and top performance so that's why it gets vote. Other languages with memory-safety are slower in general. (e.g. NodeJS) <dftxbs3e>OriansJ, I don't think it's possible without everyone's cooperation unfortunately, either by choosing a safe language or learning more rigorous programming/testing techniques.. <OriansJ>how many security people even care about Trusting Trust attacks in their software stack to actually do something about it? Answer currently 1. 
