<kcurtet>Hi im trying to build a ruby gem anystyle-cli. after the build the ruby-build-system tries to test the gem but it throws an error no Rakefile found. I want to bypass the tests to check myself the package. *kcurtet going for a cup of coffe <kcurtet>How to get info about the build systems? your read the code? <jackhill>kcurtet: to your first question: you may want to look in the code for other packages that set #:tests? #f or (modify-phases … (replace 'test … <jackhill>I think what knowledge I have as come from reading the code/working with them. I can't remember if there is a particularly helpful section of the manual or not (if not, there probably should be ☺) <Gooberpatrol66>Is it possible to build a guix image that is larger than the root drive? <zimoun`>nckx: thanks for the GHC substitutes! <lle-bout>iyzsong-w: hello! :-D Is there a way there could be some mentoring on writing GNU Guix services you could do? <iyzsong-w>lle-bout: hello, I think I can't give a detail guide, but can answer specified questions. <lle-bout>iyzsong-w: okay! Maybe next time you write a service you can record yourself doing it so we can learn from your way of doing it! <lle-bout>iyzsong-w: When I try to tackle these services I will make sure to ask, thanks a lot! <iyzsong-w>lle-bout: a simple example is 'sysctl-service-type', it add a shepherd-service to run 'sysctl --load' <lle-bout>almost half way into the list from 'guix lint -c cve' <bone-baboon>I am having trouble installing Guix on a x86-64 computer. I have tried several Guix x86-64 installer images including latest, 1.2.0, 1.1.0 and 1.0.1. The system becomes unresponsive after the grub menu but before I am able to get to the graphical installer or a terminal. I am not able to switch to a terminal with `C-A-<function-key>`. Here is the output before the system becomes unresponsive for the different instal <lfam>bone-baboon: The main thing you can do to aid debugging is to share your config.scm and tell us what kind of computer you are using <bone-baboon>lle-bout: `lspci | grep VGA` outputs "00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (rev 03)" <lle-bout>bone-baboon: I guess follow lfam advice now <bone-baboon>lfam: The system became unresponsive before I could see or edit config.scm. `uname -mpi` outputs "x86_64 AMD Ryzen 5 3500U with Radeon Vega Mobile Gfx AuthenticaAMD". <bone-baboon>lle-bout: How would you suggest I get logs from an unreponsive system that is working off a live CD? <lfam>If you are able to mount the disk from another machine, you could get the config.scm. Are you able to do that? <lfam>It sounds like the installation completes, but the computer fails to reboot. This means the config.scm should be on the disk <lle-bout>lfam: mhm I guess there is different interpretations of their message but if they are talking about GRUB it must mean things are installed..? Not sure. <lle-bout>bone-baboon: I would suggest maybe downgrading/upgrading kernel version during install if you could even get to that. <bone-baboon>lfam: To clarify the installation does not even begin installation before the system becomes unresponsive. The grub menu is for selecting to begin the installation process from the install image. <lle-bout>bone-baboon: if you tried all installer versions I don't think there's much we can do, it must be a kernel bug or freedom issue. <lfam>How are you interacting with the computer? With a monitor? Over VGA? HDMI? Or over a serial console? <lfam>It could also be a bug in the installer, to be honest. There have been some serious bugs in them <lfam>Alright I have to afk. I'll probably be back in a couple hours <lle-bout>lfam: getting the computer unresponsive..? <bone-baboon>lle-bout: At what point in the insatall do I have the option to upgrade/downgrade the kernel version? <lfam>I don't see why it would fail to boot entirely ***iyzsong-- is now known as iyzsong-w
<bone-baboon>lfam: I am interacting with the computer by keyboard and laptop screen. <bone-baboon>lle-bout: Are there freedom issues with that graphics card or processor? <lle-bout>bone-baboon: I don't know, you would have to investigate here. <lle-bout>bone-baboon: most (all?) such issues are due to freedom issues and linux-libre hard way of getting rid of them. <lle-bout>so I believe that Cuirass at ci.guix.gnu.org being broken we are no longer getting new substitutes. <wehlutyk>Following up with my question about poetry <https://www.mail-archive.com/help-guix@gnu.org/msg11274.html>, I'm getting Phil's and zimoun's drift that I should stick with guix for packaging, so considering introducing colleagues to guix. So question: does anyone have experience installing guix on macOS? Is it possible? Should I try to discuss this on other channels as it involves a non-free OS? <lle-bout>wehlutyk: macOS is completely unsupported AFAICT. Use GNU/Linux. <wehlutyk>lle-bout: is it not supported because nobody did it, or because it goes against policies? <wehlutyk>I'm asking because in many research environments the primary laptops are macs, and while HPC infrastructure runs GNU/Linux, people will already be doing a lot directly on their laptops whenever possible. That is at least my experience in several research institutions, whether they are more or less computation-oriented. <lle-bout>wehlutyk: It's going to be quite an amount of work, but I don't think it goes against policy. Nor do I think people have much motivation to get GNU Guix working there. <lle-bout>wehlutyk: GNU/Linux works well on Apple computers! <lle-bout>Just choose a distribution, maybe not GNU Guix System, but another then install GNU Guix on top. <wehlutyk>lle-bout: I don't have the resources to convince my colleagues to move away from macOS, but I do have them to convince them to use guix if I can make it work on macOS (and I know they have incentives to do that). Then flipping them could be a second step, but I think it involves a lot more convincing, so it's not my topic here 😛 <lle-bout>wehlutyk: Supporting macOS in GNU Guix will takes years (to actually get to a support as good as on GNU/Linux), so that gives you plenty of time for convincing, the latter is certainly easier :-) <bone-baboon>Using the 0.16.0 installer I am able to attempt a manual install. This is better than the system going unresponsive as it does with the 1.x.x series of installer images. However I get an error at the last step `guix system init /mnt/etc/config.scm /mnt`. The error as well as other relevant information including config, partition information, file system information and luks information are here: https://termbin.com/ <lle-bout>bone-baboon: try disabling substitutes altogether <lle-bout>I suppose that the way GNU Guix handles substitutes has changed since then <lle-bout>bone-baboon: --no-substitutes on GNU Guix commands but I really don't know how 0.16.x installer works. <bone-baboon>lle-bout: Okay I will try using that flag to disable substitues. <lle-bout>bone-baboon: beware, it will try to build everything from source, but that's the only thing you can do. <bone-baboon>lle-bout: I expect it to take a while. I will check back here when that attempt is completed and will share the results. *bone-baboon begins Guix manual install with 0.16.0 installer <lle-bout>seems I screwed up a bit on the docker update, forgot to update source hashes that also depended on that %docker-version variable. Doing so now. <wehlutyk>lle-bout: (sorry for the lag, had to go to lunch.) Again, I don't see a macOS->GNU/Linux conversion of colleagues happening in the time span of my contract here, and I'll have to start over with new colleagues at the next contract (whereas support for macOS is something I can transfer to another lab). If you think support for macOS would be a bad idea (as in providing the benefits of guix without bringing people to a <wehlutyk>free/libre OS), then maybe we can discuss that. I think macOS support could bring a big change to scientific reproducibility, so I'm interested in what kind of effort that could be 🙂 <wehlutyk>More to the point: I had no idea it would take years to get support comparable to that on GNU/Linux... where should I start looking if I wanted to dig deeper there? <lle-bout>wehlutyk: You will need to create a new bootstrap path, e.g. x86_64-darwin <lle-bout>wehlutyk: have a look at the wip-ppc64le branch, similar thing but for powerpc64le-linux <lle-bout>wehlutyk: But many details of GNU Guix depend on GNU/Linux and it is likely even more complex that this port to powerpc64le-linux we have been undertaking. There's areas of totally new research for me there, so I wont be able to help on everything. <lle-bout>I don't know if glibc works on darwin at all <brendyyn>lle-bout: i think the issue is that it requires proprietary compilers to build for macos and those arent ever going to be included in guix <lle-bout>wehlutyk: You will need to get GNU Guile to work on macOS, first. <wehlutyk>I'm starting to see the scale of this with the wip-ppc64le branch... <lle-bout>wehlutyk: only the last commits are specific to the branch just to clarify <lle-bout>wehlutyk: your first step is getting GNU Guix dependencies to work natively on macOS, so GNU Guile, and the libraries on top. <lle-bout>wehlutyk: It seems brew may help you there <lle-bout>wehlutyk: so few steps: package (or install) all deps of GNU Guix within brew, cross-compile 'bootstrap-tarballs' package to x86_64-darwin from GNU/Linux <lle-bout>wehlutyk: build GNU Guix with --with-courage added as arg to ./configure on macOS, add previously cross-compiled 'bootstrap-tarballs' to GNU Guix sources, try to get './pre-inst-env guix build hello' to work natively on macOS. <lle-bout>Once you're there, you've probably done the most difficult work. <lle-bout>wehlutyk: they suggest using Docker to run GNU Guix inside it on macOS, Docker runs a GNU/Linux VM under the hood so :-P - Install GNU/Linux still kind of wins. <wehlutyk>Thanks for all this information, I'm still sieving through <wehlutyk>lle-bout: yes, I'm also thinking it's the simplest and maybe best way <Whyvn>I am trying to edit my /etc/pulse/default.pa but since its from gnu/store I cannot. What is the recommened way of editing this? I am trying to comment out a line so that .esd_auth is not im my $HOME dir and people suggest commenting out the line module-esound-protocol-unix.so inside of /etc/pulse/default.pa ***iyzsong-- is now known as iyzsong-w
***regtur_ is now known as regtur
<i1l>sneek: seen minetest? <sneek>Not as far as I can remember. <efraim>lle-bout: can you try out the wip-ppc64le-for-master branch? I want to see how it works on ppc64le hardware <bone-baboon>Is there a way to have Guix skip building and running test when using the `--no-substitutes` flag? <nckx>bone-baboon: Not without editing the package definition. (I assume 0.1.0 is a typo for 1.1.0? 0.1 is from 2013) <nckx>bone-baboon: If nobody can help you here, please send a bug report with the above output to bug-guix at gnu.org. *nckx has to go, but the error doesn't look familiar at all. <nckx>bone-baboon: But first try the 1.2.0 installer, 1.1.0 is not the latest either. <sneek>civodul, you have 1 message! <sneek>civodul, rlb says: guile-3.0 3.0.5-3 is in debian unstable now, with the gmp fix -- thanks again <n1x_>does anyone have any advice for handling circular dependencies? I'm taking the new golang importer for a spin and running into a bunch ***iyzsong-- is now known as iyzsong-w
<lle-bout>nckx: can we give access to efraim to p9.tobias.gr? <civodul>hi lle-bout! thanks for all the security updates! <lle-bout>civodul: I have security updates to apply to desktop packages in GNOME or KDE eco-systems and since these are very interdependant it is more complicated.. right now I am thinking gvfs or kdeconnect <lle-bout>Let's say security situation is GNOME/KDE desktop in GNU Guix right now is uncertain, on the other hand, since XFCE is easy to bump in general, we're pretty much clear there. <raghavgururajan>lle-bout: I just responded to the email. Let me re-start the work on GNOME/wip-desktop. <lle-bout>raghavgururajan: We should at least stay in the GNOME supported releases, at this time, 3.36 is still supported AFAICT, but I am not so knowledgeable about GNOME release policies. <lle-bout>raghavgururajan: if not GNOME upstream supported, I think we should look at the support some other mainstream distro is providing like Ubuntu, Debian or Red Hat then nourish ourselves from their work by closely following the versions they are supporting to lower our maintenance load. <raghavgururajan>lle-bout: I understand. Also, then reason GNOME work got messed up is that, in wip-desktop, [1] I was not just working gnome packages, but also its dependencies [2] Work involved not just updates, but also improvements. This kinda complicated the "update stuff" norm. <lle-bout>raghavgururajan: That's great, maybe we want to get stuff merged as soon as possible then work from there instead of delaying bunch of changes for too long because they would be WIP <lle-bout>I think we are suffering the same kind of syndrome (somewhat) in wip-ppc64le <efraim>lle-bout: I'm in and out a lot today, right now I'm not at home <raghavgururajan>lle-bout: On a note, I put more work on myself. When I was working on wip-desktop, I made larget commits instead of 'one change per commit'. So after a discussion, I was asked to split them into smaller chunks. So I need to get #42958 out of the way. <lle-bout>raghavgururajan: ah.. yes that's annoying <rekado_>raghavgururajan: should I review 42958? <raghavgururajan>rekado_: I wanted to ammend my email with my messages above. That is all. :-) <rekado_>I just replied to your mail: I do think that we can build things on ci.guix.gnu.org <rekado_>effective build farm capacity has increased dramatically since mothacehe’s improvements, so I think we should make use of it. <lle-bout>rekado_: ohh is that recent or are you speaking of older improvements? <jlicht>lle-bout: over the last ~6 weeks, afaik <lle-bout>jlicht: okay, yes :-) - was wondering what the recent outage of Cuirass was about, if it was just removing "hydra" support or.. else. <jlicht>Could it be our current mono package bundles quite a lot of pre-built binaries [note: very uncertain could]? Or, are these binaries bundled, but regenerated in the build process? ***vlorentz1 is now known as vlorentz
<leoprikler>raghavgururajan, lle-bout: what about wip-gnome3.36? Is that a good base? <leoprikler>I'm currently rebasing it onto master and it seems to be ~100 commits <nckx>jlicht: It could certainly be; don't ever hesitate to ask/investigate such things. If they are bundled and rebuilt, they should never be included in ‘guix build --source mono’; that's a bug in itself if they are. <lle-bout>leoprikler: no idea, 3.36 sounds better than 3.34 though, but 3.38 wouldnt hurt <leoprikler>thing is we don't have a wip-3.38 branch and it's have to go to c-u first anyways unless we squint really really hard <cbaines>leoprikler, hey, just looking at #44492 (fractal) *lle-bout compiles efraim's wip-ppc64le-for-master branch <cbaines>something about rust-pangocairo-0.10 being unbound <montxero>I just installed Guix System with gnome. However, Gnome does not start. I subsequently installed xfce but cannot launch that either <leoprikler>i've skipped some patches, because of merge conflicts (usually meaning they've already been applied to master) *lle-bout worries some of the security updates may actually have broken desktop on GNU Guix <montxero>It boots into a terminal, when I try gnome-session, I get lots of warnings. The first is `gnome-session-binary[495]: Warning: Falling back to non-systemd startup procedure due to error: GDBus.Error.ServiceUnknown: The name org.freedesktop.systemd1 was not provided by any .service files` <montxero>then a while page of more errors and warnings <nckx>efraim: Your Savannah GPG key has expired. Could you update it? <cbaines>civodul, just looking at the Guix Data Service processing of the wip-build-systems-gexp again. Looks like the profile-collisions checker generates some invalid G-expression input error <montxero>With xfce4, when I try `xfce4-session`, I get `Unable to init server: Could not connect: Connection refused <lle-bout>montxero: can you send output of 'guix system describe' and your config.scm? <nckx>n1x_: You'll have to try to build ‘minimal’ versions of such packages for others to depend on. They can be private (‘define’ instead of ‘define-public’) or public depending on how useful they are for end users. <leoprikler>cbaines: does patchwork test intermediate commits as well or only the series as a whole? <cbaines>leoprikler, the series as a whole (although checks are reported per-patch) <n1x_>nckx: thanks, that what I was thinking I'd probably have to do based off the other packages I see in the repo <nckx>I can't think of another way around it, but I don't know anything about Go. If it has anything approaching ‘./configure --disable-foo --without-blah’. <lle-bout>nckx: our go package needs security update but I think it is a difficult one to graft, so can we just push it to master even though it would cause rebuilds of 450+ packages? <leoprikler>cbaines: yep, the commit for pangocairo seems missing, it should be between 26/46 and 27/46 *nckx points at caveat above 😛 Are Go packages cheap by any chance? That would be an argument. <nckx>Depends on the nature of the CVE, I'd say. 450 isn't terrible... <nckx>lle-bout: I've added efraim BTW but don't have a GPG key to send the password. <lle-bout>nckx: okay! sudo (root) password then I guess <nckx>But efraim's key on Sav & SKS pool expired in 2020. <nckx>Oh, sorry, you said ssh. ***chrislck_ is now known as chrislck
<nckx>I can only speak for myself but it's OK for me. <lle-bout>nckx: do you use ci.guix.gnu.org substitutes? <nckx>Machine time for 150 extra packages is cheaper than your time doing a tricky graft (which has its own risks) & I trust your judgment. <nckx>I mean, on some machines. Why? <lle-bout>civodul: to push or not to push go package update fixing 10+ CVEs without graft? It causes 450+ rebuilds but difficult to graft. <leoprikler>I have no experience with Go, so that tells me nothing. <lle-bout>I don't think it has an ABI? go packages are static? Grafting would not rebuild dependents and not fix the issues I think. <nckx>Is Go sane re: dynamic linking or is one of those broken static-linking-was-cool-in-2019 langs? If the latter the discussion is moot anyway. <nckx>You've answered that. Sigh. Then I don't see what a graft would buy us and you should push. <lle-bout>nckx: I am not certain of my answer, I don't know if we dynamically build go things in GNU Guix somehow. <lle-bout>But I doubt Golang has a stable ABI of it's own, it would be bigger news otherwise <nckx>Add a short comment to the commit message. <nckx>So people don't mail the list thinking they've discovered something. <lle-bout>nckx: pushed 500189b4d2f1e3a2d4ee8ab73d889e3d8ac70632 <nckx>pretzel: Sure, I would've if it had crossed my mind. But mirror operators should be prepared to deal with that; there was no problem for ‘normal’ users of the main Savannah repository. <nckx>But thanks for mentioning it. <lle-bout>montxero: can you also look at /var/log/messages? Don't share that just yet it may contain sensitive info but do look for odd things or other errors. <nckx>If your mirror silently stops updating without sending you mail, you're not going to have a good time. <lle-bout>efraim: I am building hello on your wip-ppc64le-for-master branch <montxero>lle-bout: `kernel reports TUNE_ERROR: 0x41: Clock Unsynchronized <nckx>pretzel: I've send a note to info-guix@. <pretzel>nckx: Thank you. :) (Re 'should be prepared' & 'sending you mail': I agree.) <nckx>pretzel: Please ask your mirror operator to change their configuration so it requires no manual intervention. It's not a security feature to do so. <nckx>pretzel: We'll try to fix our processes so this ‘never’ happens again, but... 😉 <i1l>montxero: do not use gnome. use sway. <lle-bout>i1l: it should be fine for them to use XFCE or GNOME, we just have to find whyt his happens. <i1l>but sway will most likely work, and can be started from console. and He will get access to GUI at least for now. untill it fixed <lle-bout>montxero: also check other files in /var/log <lle-bout>montxero: I forgot, xorg logs are separate <i1l>(sway is wayland: true;) <nckx>pretzel: Thanks for bringing it up. I forget about mirrors being a thing. *nckx has been moderated by their own info list. Sigh. Let's hope I have the password written down on an old sock. <lle-bout>nckx: I was asking for ci.guix.gnu.org to figure out if your opinion came from a substitute user or not. <montxero>lle-bout: this may be interesing. It is the tail of /var/log/gdm/greeter.log <lle-bout>If anyone is interested, fixing security issues in GNU Guix is often only about knowing about them, so you can follow <https://nvd.nist.gov/feeds/xml/cve/misc/nvd-rss.xml> with an rss reader and at a glance you can view the most recent entries any day you can and filter out the ones about nonfree software or unpackaged free software with few GNU Guix searches. <nckx>Well, I build my own substitutes, so I'm not average. I also don't use Go. <lle-bout>It is average traffic RSS feed (~10 entries per day) <nckx>lle-bout: Do you know about any good (Free) RSS-to-e-mail adapters? <nckx>I'd actually read it then. <lle-bout>nckx: oh well they may also offer email service directly, let me check, but I do not, but should be easy to find I think. <lle-bout>I use quiterss which is quite good for following lots of feeds and getting info from summaries quickly <nckx>I know myself enough to know that a separate programme just for CVEs will not be opened after the first week. <nckx>Or allowed to consume resources in the background. <nckx>I can always run a script on my VPS or something. <nckx>Pre-Python 3, but yeah, something like that. <lle-bout>a bit too old yep.. well popular seems rss2email <zimoun>“guix weather” is really slow… when it does not break. <nckx>zimoun: I've been running ‘until guix weather … :; done’ for close to 24h and it has yet to succeed. <zimoun>yeah, I am doing similar thing. But the feedback loop is really slow to spot out the missing substitues and then fix for the next release. <lle-bout>nckx: we can set paste.debian.net in topic again now it's up <raghavgururajan>sneek, later tell dannym: I am re-working patches in #42958, for applying them on current c-u. <nckx>The problem is the frequency with which is down, I'm kind of sick of manually dancing around that. I'd prefer something as uppy & Free as paste.gnome.org with a longer default expiry. <nckx>Suggestions welcome but I'm sticking with p.g.o otherwise. <lle-bout>nckx: oh okay never seen it down before besides the other day. <nckx>I've had to change the topic too often :) <leoprikler>I personally like the default of 30 minutes in p.g.o., much privacy :) <lle-bout>raghavgururajan: have you considered applying for commit access? <lle-bout>zimoun: have you considered applying for commit access? <lle-bout>raghavgururajan: Shoot an email to people who reviewed your code, I think they will be happy to vouch for you. After that, no doubt approval is near. <lle-bout>raghavgururajan: I'll apply, but it's a bit blind now <raghavgururajan>lle-bout: Danny was about to push those 11 patches, but then the c-u breakage happened. I think now c-u is healthy and danny is busy. :-) <raghavgururajan>> lle-bout: raghavgururajan: Shoot an email to people who reviewed your code, I think they will be happy to vouch for you. After that, no doubt approval is near. <raghavgururajan>Yeah, I was gonna do it. Have been on packaging spree these past days. Will be doing it soon. <lle-bout>raghavgururajan: doesnt apply cleanly :-S <lle-bout>raghavgururajan: thanks a lot for all the work :-) <leoprikler>raghavgururajan: would you mind rebasing those packages onto current c-u and sending a revised patch set? <raghavgururajan>leoprikler: Yeah, working on it. That's why I said "Shoot! Gimme few minutes." :-) <leoprikler>It would also help if you could send them via git send-email --reroll-count=2, so that patchwork can pick them up as well <efraim>wow, so many messages. nckx, lle-bout I updated my gpg key on savannah <lle-bout>it seems ENABLED_ENCRYPTED_MEDIA=ON (DRM) has been explicitly enabled on wpewebkit, why ever? <lle-bout>raghavgururajan: I am updating them as well as disabling that DRM stuff right about now <lle-bout>since there has been many security issues since then <zimoun>lle-bout: about your question, yeah it is not the first time someone says so. :-) The idea is to explore how it is possible to contribute to Guix without commit access. As it is pointed out, yesterday for example, more committers means more potential weakness. And from my point of view, there is too much granted people and until we will not have a clear rule to ungrant people (who do not often use their commit access or do not review, <zimoun>for instance), then I will not apply. <lle-bout>zimoun: I think that we can trust committers, but we need to provide better tools for them to secure their computing, e.g. require hardware security key for PGP signing of commits somehow (that GNU Guix can fund) <nckx>zimoun: A simple ‘commit access is removed after N months of inactivity and can easily be rerequested’ policy has been suggested, but as you say the problem is deeper. <nckx>efraim: Thanks! I've sent you ~encrypted mail~. <nckx>Or, as it's called in Belgium this week, crime-mail. <zimoun>nckx, I agree and I even did stats to evaluate this N and sent the result to guix-maintainers I guess. :-) <nckx>Thank you. I haven't read all my mail. <lle-bout>Today GNU Guix without as many committers would grind to a halt due to human bottleneck issues, it already kind of does. We need better review tooling and better flows of information for everyone to see easily. <nckx>lle-bout: Eek, nice catch. <zimoun>lle-bout: no, it is not a technical problem but a social problem. Anyway. <lle-bout>zimoun: the hardware security key thing reduces risk of compromise to near zero <apteryx>does someone knows what provides the GNOME 'gio' abstraction in Guix? It seems it might be glib, as it has a gio.pc file <nckx>lle-bout: [citation needed] (and I don't agree or even think it mitigates anything, but it's another low-level implementation detail) <lle-bout>nckx: hardware security key is e.g. over USB and has interactive button + screen to validate cryptographic operations, malware can't extract keys or validate malicious requests <lle-bout>even if your machine was infected you still could push commits and ensure it's what's being signed on the key <lle-bout>so I do think it reduces risk to near zero <nckx>Your screenkey is fancier than mine. How does it protect against a compromised machine? <lle-bout>nckx: I don't understand your question it should be obvious how it does already, it would protect GNU Guix from committer's compromised machines <lle-bout>zimoun: I tried this earlier, breaks dependents <apteryx>could you say so in the issue, and mentionning how they can find this out? (e.g., trying to build the dependent packages that can be gotten from 'guix refresh -l python-numpy') <apteryx>so that they have something to chew on <lle-bout>apteryx: very tired now about to go sleep sorry :-( <lle-bout>in the middle of webkit upgrade but can't finish before going to sleep I think.. <nckx>lle-bout: <it would protect GNU Guix from committer's compromised machine> How? <lle-bout>nckx: because malware will not be able to sign commits without the committer explicitly pressing the button and approving the malicious request displayed on screen which will raise concerns to the committer (or should) <nckx>I don't know what's displayed on the screen, I've never had such a key. <nckx>It displays the commit hash? <apteryx>lle-bout: whatever pops a message on screen could be altered if the attacker had gained control of the machine, no? <lle-bout>nckx: information to verify the request, so full text or hash inside signature, whatever you want, it could display commit hash <nckx>Sent by the compromised machine. <lle-bout>nckx: the key would have to receive the whole repo with the commit to actually display commit hash <nckx>Unless the key mandates some kind of structure. <nckx>Then no, it's not obvious how this protects against a compromised machin, or how ‘malware will not be able to sign commits’ in any way. <nckx>BTW I agree that it's a *layer* of protection. It means malware can't sign commits at the hour it would like. But nothing more, I think, and far from the original ‘close to zero’ claim. <lle-bout>it is obvious, if screen's big enough you can display the whole text being signed <nckx>Do you have example models of such a device? I've never seen one that could do that. (Which means little.) <apteryx>any suggestion of one of these keys? I'm curious to try for myself. I have an old mini yubikey (before they went closed source), could this do? <apteryx>(sorry for keeping you awake with questions) <lle-bout>apteryx, nckx: the trezor model T is quite nice because programmable and sizeable screen <nckx>So you programme this device to (say) display the entire signed commit text, and it's then locked? (All the images I find are marketing logos/simple keypads.) <lle-bout>one would have to find the best way to implement screen verification for the git use case and program it inside the trezor model T with an app <lle-bout>transfering git repo and using commit hash sounds best to me, but one needs to find a way to securely parse a git repo <lle-bout>nckx: can't say for sure for the Trezor Model T, don't own one, will have to do extensive study how this can be done. <nckx>Thanks. This is turning from ‘we could buy a thing’ into ‘we could design a thing’, though. <leoprikler>raghavgururajan: you can cut diffs with text tools, but I think `git commit -p` after applying might be your friend <leoprikler>sorry for the delay btw., graph theory keeping me busy rn <lle-bout>nckx: Trezor Model T is explicitly programmable so <leoprikler>re: hardware solutions, what if the USB key is lost or compromised? <nckx>(hardware is €200/key without the cost of actually making it work, by the way.) <nckx>Good thing we're removing committers. <nckx>‘Sign the GCC backdoor that malware just substituted for your GNU hello update? [Y/n]’ ***janneke_ is now known as janneke`
<lle-bout>nckx: but I don't exclude it may still contain unsophisticated verification screens, I do agree there has something specific to git to be done for it to be really convenient to verify *nckx in class, so browsing slowly. ***modula is now known as defaultxr
<leoprikler>When we're saying reproducible builds, we don't mean reproducible signing keys. <nckx>lle-bout: Not just convenient, but actually secure. If malware can send whatever it wants to the key, a hardware ‘sign’ button isn't security. Unless the key shows the actual data being signed in a readable form, a screen isn't either. <lle-bout>nckx: the point of the screen is not the computer sends whatever it wants to the key, it never does that <leoprikler>It's actually less secure than the same information on the computer screen. <lle-bout>it's the key gets data being signed and produces useful verification screen inside the key <lle-bout>I don't know if commit hashes can be produced standalone or need the whole repo to generate <lle-bout>webkitgtk,wpewebkit,libwpe,wpebackend-fdo has many unpatched CVEs if you feel bored <leoprikler>btw. once you grok text files, cutting diffs manually (e.g. via emacs) can really be helpful ***janneke` is now known as janneke
<raghavgururajan>A patch failed to apply, was wondering if I could ignore the conflicting chunk. <leoprikler>you'd better do git mergetool or something on that then <leoprikler>No particular feelings either way; I won't commit it rn, but I won't stop you from committing if you feel strongly about it once you have commit access. <nckx>lle-bout: Thanks for the explanation, that's a relief at least. ***aweinsto1k is now known as aweinstock
<i1l>if i will see a price tag of 200 for an usb thing irl, i will be relieved really fast. <i1l>and will need to visit Eliza for unscheduled talk <nckx>‘What kind of idi--‘ “USB Bitcoin Wallet”’ ‘...oh.’ <efraim>nckx: I'm still not able to connect <nckx>I haven't read your mail yet, sec. <pineapples>I want to know if it's nothing serious. Whatever that garbled mess is, it doesn't evoke a positive connotation; I saw similar "stuff" used to run arbitary code.. <roptat>I've already seen that before, I thought it was fixed <nckx>pineapples: It just means there was a ‘network error’. It should not be anything serious, although it is worrying from a reliability PoV. <nckx>pineapples: I understand that '\x1d...’ looks worrying in HTTP logs, but it's not here. <roptat>I think it's confused (compressed) data for http headers <pineapples>Oh, okay! Thanks nckx and roptat. Nevertheless, it's updating now :) <nckx>I have the very subjective impression that Guix networking has become more unreliable the past few months or weeks. <pineapples>I have noticed a few connection issues here and there but they weren't a huge deal to me <roptat>yeah, we've had more reports related to networking issues lately I think <nckx>I still need to respond to zimoun's answer to a similar bug report, I just *really really* dislike debugging network stuff ☺ <pineapples>Oh, and, in unrelated news, I have packaged `seatd' and `basu' for Guix :') Both are working with Sway <nckx>It's not searchable if you don't know what it does ;) <nckx>pkill9: “Seatd is a minimal seat management daemon, and a universal seat management library. Seat management takes care of mediating access to shared devices (graphics, input), without requiring applications like Wayland compositors being granted root privileges” <i1l>ah, the new part of systemd to be! <nckx>pkill9: I thought it was a good description... <pkill9>i think i extrapolated from 'why not (e)logind' section <nckx>pkill9: I think it can replace elogind, but only for software that uses its own libseat... <pineapples>nckx, it's said it supports (e)logind; though, I only tested it with Sway, without libseatd support compiled-in <nckx>What's ‘it’ here though. <pkill9>i was trying to package somethign that needed the sdbus part <pineapples>I need it for mako and xdg-desktop-portal-wlr, which I also packaged <nckx>pineapples: So Sway without libseat support was still able to use seatd instead of elogind? <pkill9>oh desktop-portal is designed to work with things other than flatpak,t hat's good <nckx><without libseatd support> Not sure if that means seatd or libseat (there is no libseatd mentioned on the home page). <pkill9>that way it can be used with sandbox native applications with firejail <pineapples>nckx: Hold on. I think I'm wrong. I think I only tested sway with libseatd support compiled in, with elogind, not seatd, to see if I was to implement a change that allows Sway users to use seatd wouldn't affect elogind users <pineapples>Either way, if anyone wants to upstream my packages for me, I'm open for suggestions <bone-baboon>nckx: Yes that version number of the installer was a typo. <bone-baboon>I am trying to install Guix on a x86_64 computer. I have tries several x86_64 installer images but am running into different issues. <bone-baboon>When I try the latest, 1.2.0, 1.1.0, 1.0.1 installers the system becomes unresponsive before the install is able to begin and before I can get to the graphical installer or a terminal. This is the output I get when I try using those installers: https://termbin.com/xkk1 <bone-baboon>With the 0.16.0 installer I was able to work through a manual install but when I try running the last command `guix system init /mnt/etc/config/scm /mnt` I get this error: https://termbin.com/n2w6 <bone-baboon>With the 0.16.0 installer and that same same manual install setup described previously when I try to run `guix system --no-substitutes /mnt/etc/config.scm /mnt` I get this error and build log. <bone-baboon>I am not sure what else to try but still want to install Guix. <pineapples>nckx: Nevertheless, I daemonised seatd (copied auditd service and modified it), and it's been working great for the last two weeks <pineapples>Apart from Sway, Wayfire also adopted libseatd AFAIK ***zimoun` is now known as zimoun
<i1l>bone-baboon: did you tried to re-run `guix system init`? also, try append 'nomodeset' in GRUB with newest image (idk, but maybe?) ***sneek_ is now known as sneek
<apteryx>yikes, there's no substitutes for rust for the staging branch <roptat>I thought the chain took more than a day to build <rekado_>does it really take that long even on the build farm? <apteryx>roptat: that's on the fastest machine I can get my hands on <apteryx>on core-updates it now takes 'only' 8 hours <apteryx>rekado_: the problem is that it's sequential <apteryx>the inital bootstrap from mrust takes close to 1 h <apteryx>he rest is about 15 minutes per rust <apteryx>and every new version of rust (every 6 months?) adds up; so we depend on mrust to improve and be able to bootstrap newer rust otherwise the chain will just grow and grow <leoprikler>iiuc mrustc can get us to 1.39-ish on c-u tho, am i correct? <bone-baboon>i1l: Yes I have tries to rerun the `guix system init` commands and they have the same result. <rekado_>bone-baboon: it’s a Linux thing, not a Grub thing. <apteryx>bone-baboon: that's a linux kernel flag <bone-baboon>rekado_: apteryx: Thanks. I am not sure how I would use that Linux kernel flag to help resolve the Guix install issues that I mentioned. <paniash>hi! are there any alternate init systems for guix other than shepherd? <lfam>It's very highly integrated with the rest of the system <paniash>also, is it possible to run proprietary bits in guix? <paniash>like say I need nvidia drivers for my graphics card <Noisytoot>paniash: noveau exists, which is free software, and might work <rekado_>paniash: Guix does not prevent you from running proprietary software. <Noisytoot>There are nonfree channels, but they are unofficial and not recommended <lfam>It would be great to get some help here <roptat>lfam, maybe drop the "service" bit? default-sysctl-settings is a procedure that takes a configuration and returns a service <roptat>well, actually I don't know what it returns, I can't find it in the repo <lfam>It's defined in my diff, from the email <roptat>so yes, you defined it as a procedure <roptat>with service, the first argument needs to be a service-type record type (the struct that the error message is talking about) <paniash>Noisytoot: noveau is pretty shit tbh <lfam>I was wondering, which struct is it talking about? <roptat>also, your simple-service-type won't work: it expects something that can extend the sysctl-service-type, not a sysctl-configuration <lfam>As you can tell, I don't understand services on Guix <roptat>if you look at the definition for sysctl-service-type (gnu/services/sysctl.scm), you can extend it by passing a "settings", which is whatever can go inside the settings field of the sysctl-configuration <roptat>so, I'd pass '(("fs.protected_hardlinks" . 1) ...) to the simple-service, not the whole sysctl-configuration record <roptat>paniash, we don't propose non free software, but we don't prevent you from using them either <lfam>It's not crashing immediately roptat. Thank you so much! <lfam>I really was banging my head <roptat>yeah, tricky and not very well documented <roptat>there was a talk by ludo I think, it gave a very good overview of the way service extension works <lfam>I think it might actually be easier for me if I didn't know a lot about other areas, like packaging. These two very different levels of knowledge are hard to reconcile <lfam>I did read the manual section on services very closely, and studied some other services <lfam>I'm going to take your advice and re-read those sections with it in mind <paniash>roptat: I understand, i'd rather use a piece of software which is officially supported. but good to know that proprietary blobs can run. thanks! <roptat>paniash, if you're talking about firmware in the kernel, we use linux-libre wich will actively prevent you from loading binary blobs. Though, you can still build your own kernel from mainline and use it in your system declaration <nckx>lfam: This network seems to block mail (whut?) but LGTM on the ping. <roptat>we don't officially support that, but it's not too hard either (and most likely already documented elsewhere) <lfam>Just to clarify... you're not talking about my mail server blocking your messages, right? <nckx>Public wi-fi blocks ports 25 & 587 (somewhat explicitly, or IRC wouldn't work). <nckx>I think it's a sorry comment on the reality of how many people still use real mail over the big Webmails. <lfam>Ah, this happens when I "tether" through my mobile phone <roptat>it builds the bindings in a separate output, instead of a separate package, because they're part of the same source, and it doesn't look like it's possible to build them separately <roptat>if nobody answers, I think I'll push tonight <lfam>Yes, I think that that's fine. As long as you are confident it works, committers can push without review after a couple of weeks <roptat>oh yes it works, I use it at work :) <roptat>I'm just not very happy it's part of the same package, because it's less discoverable <lfam>Multiple outputs are very often overlooked <lfam>Maybe the package UI could display them as separate packages <roptat>it might increase the clutter though, especially if you have lots of *:debug <lfam>And it could automagically munge the package name. Like, it would accept the concatenation of the package name and the output name <lfam>Well, since we are creating magic, we could leave the debug outputs within the UI report of the main output <lfam>I'm just "brainstorming", maybe it's too windy <lfam>I do think we should try to find an improvement here. People often are missing the outputs of Git <roptat>do we match against output names (other than the common ones)? <lfam>Or, maybe the UI could include descriptions of the outputs. And then peole wouldn't miss them <roptat>ah yes, we could have per-output description, that would be great <lfam>That's better than my first idea <roptat>(for the UI, but probably hell for packagers who'll have to come up with more text ^^) <lfam>send-email: Git program for sending patches with email <lfam>I think we ought to be documenting the outputs anyways <Noisytoot>What's the difference between multiple outputs and the different packages? <roptat>we could do that inside the outputs field directly, maybe: (output '("out" ("send-email" "Git program for sending patches with email"))) <lfam>Basically, you build the package and then split it up into different store items, Noisytoot <jas4711>what's the problem with updating inetutils to 2.0? i see it was committed and then reverted because of caused rebuild of lots of packages, is that a problem? <PotentialUser-47>Good apps have been added to the Guix Wishlist, great if these are packaged soon! <roptat>jas4711, when a change introduces lots of rebuilds, the build farm cannot keep up, and users end up building dependents for ages <roptat>so we push these changes to staging or core-updates usually <apteryx>bone-baboon: from the grub menu, you can press 'e' to edit a menu entry, then you'd add nomodeset at the end of the kernel line, IIRC *roptat has no idea what these apps are ^^' <apteryx>bone-baboon: it's also possible to add it to the kernel-arguments of you operating-system declaration once you've found something that works <lfam>Thanks PotentialUser-47 :) I'm sure someone will pick them up eventually. <lfam>jas4711: You can explore this area with the command `guix refresh --list-dependent inetutils` <lfam>Sometimes, this command doesn't report all of the packages that will be rebuilt. It's based on the full graph of Guix package dependencies, but it doesn't account for changes to Guix build-systems <lfam>And it's like roptat said. We batch big changes together, to save time, human energy (debugging), and electricity <lfam>And it also provides something like a stable base for the system <lfam>Although, that's not an explicit goal <roptat>PotentialUser-47, looking at kooha, the first commit is from 8 days ago, so no wonder I didn't know about it ^^ <roptat>it doesn't look too hard to package though :) <roptat>it's not very clear from the "manual" build instructions how to build it from source though ^^' <roptat>but I guess just meson, python and maybe some gnome stuff are all it needs <roptat>PotentialUser-47, do you want to give it a try? <zimoun>roptat: from how “guix search” works today, to have ocaml z3 more discoverable, the only way is to have a separate package with a specific synopsis+description. <zimoun>because in “guix search ocaml z3” the “ocaml“ term will only be granted by 1 of weight (output) ***warren_ is now known as warren
<roptat>well, then it'll be discoverable, "guix search ocaml z3" doesn't return anything now <roptat>PotentialUser-47, it's fine, we're all volunteers and your patches will be reviewed anyway ;) <roptat>also guix is pretty solid, there's no way you can damage it with a bad package declaration <lfam>Maybe we could have a contest ;) <roptat>(unless you intentionally package a malware) <zimoun>roptat: yeah, personally I am always confused by the multi-output, fetching and building a lot of stuff that I am not necessary interested in, as for git:send-email. And now ‘guix build z3’ will drag ocaml. <roptat>zimoun, but I don't really have a choice, it's part of the same repository, and if I build it separately, it rebuilds z3 <roptat>and doesn't link to the one we currently have :/ <roptat>and, hopefully, you get substitutes, so you don't have to pull in ocaml for z3 itself <roptat>and of course, ask any question you might have here, we're here to help! ***aidalgol_ is now known as aidalgol
<PotentialUser-50>Friends, what do you think about this new app? And this is a free software? <lfam>The license is AGPL 3, which is a free license <roptat>now, it's an android app, which is... hard to package in guix :) <lfam>One would need to poke around in the source code and check if there were other programs "bundled". But if that's not the case, then it is free software <lfam>roptat is correct, it will be hard to use in Guix <roptat>(though not impossible, just a matter of dedicating a few years of hard work :p) <roptat>maybe add one or two years for the javascript stuff too :/ <leoprikler>Fun how Fractal got added to the list after two separate efforts of packaging it. <leoprikler>Cuttlefish looks like it'd be fun to package were it not for c++2a. <Noisytoot>nckx: Could you use Tor or a VPN to access your email? <nckx>Noisytoot: Yes, I could use an SSH tunnel or Wireguard. ***soheil_ is now known as soheil
<nckx>(Unless they did DPI which I seriously doubt.) <lfam>Techniques for surveilling encrypted traffic <jackhill>leoprikler: what is Cuuttlefish? I found something that assists in doing mass emailings, which I think is a different cuttlefish :) <nckx>Noisytoot: It's a fancy (and somewhat ‘marketing’) name for looking at the data instead of just the metadata. A normal firewall just (dis)allows specific ports, IP addresses, other ‘envelope’-type stuff; DPI will try to open them & decode the packets themselves. <nckx>Let's reset master again. *nckx cancels the air strike. <jackhill>leoprikler: at least it's not rust ;) I was wondering when we'd need GTK4 <lfam>What's wrong emoji in commit messages? :) <lfam>Could be the case for other non-English languages as well, though, and we have put that in our commit messages <nckx>They're less clear than text and rely a lot on cultural/temporal/meme context. <lfam>Well, we avoid colloquial language in commit messages, usually <lfam>Or, maybe we don't, and I'm too mono-lingual to notice <lfam>I'd use them more here if it was easier to type them on my system <leoprikler>Emoji are not serious business enough for commit messages. <roptat>I remember someone telling they had trouble hitchhiking in a country where having a thumb up is basically the same as the middle finger in the US :) <lfam>The good news is that Guix is not a business ;) <nckx>Good point, really. We have pretty ‘serious’ commit messages. For projects that use ‘fix it’ and ‘dammit’ emojis would improve the information density. <lfam>Our commit messages have spoiled me for other Git repos <mdevos>Noisytoot: what's up with gnunet-guile2? <nckx>Noisytoot: Hey! I shared that in good faith! <nckx>paste.debian.net does not. <lfam>It's interesting to read the recent pastes on the debian paste site <lfam>And, logs.guix.gnu.org doesn't quite remember everything. It automatically removes certain things, and maybe some admins remove other things manually <leoprikler>hank you for creating a pull request to contribute to FreeCAD! <lfam>Sometimes, if you load the IRC logs web site at the right moment, it will display some lines at the bottom that haven't been removed yet. I guess the cleaning process is batch-oriented <lfam>It removes the "user joined" messages, to avoid displaying their IP addresses to the web <nckx>lfam: Good guess, but it's just an artefact of the algorithm. The actual logs are not modified, in batches or otherwise. <nckx>I sed out the porn, that's it. <leoprikler>Meanwhile in some R&D centre: "Could we train an AI to do that?" <lfam>Where do you think sneek came from? <apteryx>ah, fun, I think I discovered why a local build of Jami was not able to load its SVG icons <apteryx>on our packaged jami: ldd $(guix build jami)/bin/jami-gnome | grep -i svg => libgdk_pixbuf-2.0.so.0 => /gnu/store/irjan5wq7j25fa2m6n2xhl8mglsaqxn4-gdk-pixbuf+svg-2.40.0/lib/libgdk_pixbuf-2.0.so.0 (0x00007fe3a965a000) <apteryx>in my dev tree (jami build from an environment): ldd jami-gnome | grep -i svg => nothing <apteryx>it seems to have linked against plain gdk-pixbuf instead of gdk-pixbuf+svg, despite gtk+@3 propagating it <bandali>ahh, that sounds like it'd be relevant indeed <lfam>It's okay if that's not your thing. Your name was suggested as somebody who might know about it <lfam>Maybe there is something I can do to make it easier to review, or whatever the process requires <bandali>so i'm not intimately familiar with the process myself, but i can try nudging the audio-video folks to have a look at it <bandali>it may have gone unnoticed because it was reported to the 'support' tracker, whereas it seems most other requests for that project are under the 'tasks' tracker <lfam>I can re-submit it as a task <bandali>though it may be completely unrelated; i'm just guessing :-) <lfam>I can also remove the level of indirection about where the videos are currently hosted <bandali>am not sure. but anyway, i'll ping two of the people in charge about it, and see if i also could help move things along <lfam>In the ticket, it says "These videos are currently stored on personal server (see the links in the announce)." <lfam>It's just a little extra friction <lfam>Better to include the link in the request <lfam>I still have a copy too :) <roptat>and they should still be available on ipfs too, I think <bandali>aha. that shouldn't really be an issue. i'll just ping the right people and see if it's on their radar, or if they're too busy whether i could help do it <lfam>Okay. Don't hesitate to let me know if I can do some work to help <lfam>Thanks for you assistance, too <bandali>and sorry these couple of things have been taking some time. past few weeks/months have been crazier than ever for me :-/ <roptat>could it be a side effect of the master branch reset? <ngz>It sounds plausible. <roptat>if the server did pull the faulty commit, it can't advance further now <roptat>civodul, we had to remove one commit from master yesterday because it was signed with an unauthorized key <roptat>nothing malicious, just a mistake <roptat>we noticed quickly since guix pull failed as expected :) <civodul>actually i'm surprised it didn't happen before <civodul>it's always the same problem with fault tolerance features: you don't see them until you need them <civodul>so in a way, it was a good way to show the feature actually _is_ in place <civodul>like the burning data center is a good way to demonstrate there are backups <roptat>could you reset the cached checkout the website uses to generate the list of packages? <janneke>always remember to first make backups before you burn the data center *vagrantc hopes civodul doesn't get any dangerous ideas about visiting ci.guix.gnu.org <nckx>civodul: You didn't see any of the mails? 😮 <lfam>The question is... which mails ;) There are so many *nckx has no right to participate in any convo on inbox hygiene and esses the f u. <nckx> * [bu] Unread messages (8525/8525) <nckx>But I've done that twice already. <civodul>nckx: i'm lagging behind as always, and trying to focus <civodul>which is kinda hard for me these days <lfam>Don't worry about missing this civodul. I think the issue was handled well and is now resolved <nckx>No worries. It all went remarkably well, considered. IIRC I thanked your ‘sane guix pull’ design in the report & I meant it. <lfam>Yeah, everything worked as expected <civodul>lfam, nckx: i'm not worried, i'm confident y'all did the right thing :-) *vagrantc cackles sinisterly <lfam>The only thing that could be improved is that it would be nice if we could manually reset the Savannah repo on our own, but it's not a big deal <nckx>One hitch was: I had to ping rwp in #savannah to do the actual rewinding, luckily they responded immediately. Even ‘maintainers’ can't undo a DoS which is problematic. That and of course the remote hook not catching it despite lfam's old bug report. <civodul>vagrantc: the data center of a major hoster in France/EU burnt yesterday, leaving thousands of web sites off-line <lfam>I think, it's always been known the remote hook wouldn't catch this kind of thing <lfam>These kinds of mistakes are a risk when people come back after a long absence <nckx>lfam: Right, I meant that that's (very mildly) worse than if we hadn't known. <lfam>But, that's a "good problem" to have <nckx>We knew and DID NOTHING. <civodul>nckx: you weren't able to delete and push? <nckx>As far as fire alarms go this one went well. <lfam>Oh, another thing that could be improved is if `guix pull`'s rejection of the unauthorized commits would not be cached, so allow-downgrades was not necessary later <apteryx>libnotify propagates gdk-pixbuf, which clashes which gtk+'s own propagation of gdk-pixbuf+svg <apteryx>should be update libnotify to propagate the later instead? <narispo>efraim: I checked the license before updating mongodb and it's not the case, license still AGPL there <nckx>Lol. ‘They're gossiping about you on #guix.’ <rwp>I am here because I was going to ask if something has changed with regards to guix-ci mailing list recently? <lfam>Hm, I know that mothacehe was working on Cuirass / CI yesterday <rwp>But as to the other topic, if you guys have different hooks then that would be awesome too. :-) <lfam>Looks like guix-ci has been quite busy <rwp>Yes. Thousands and thousands of messages busy. <rwp>I am trying to understand what the situation is and if there has been any recent changes to account for the huge amount of mail today. <euandreh>I just found out (after a lot of hitting my head against the wall) that Perl's MakeMaker doesn't honer $LIBRARY_PATH <lfam>I think we will have to ping mothacehe about this via email, rwp <narispo>I think the right medium for guix-ci is RSS :-/ <lfam>Do you want me to CC you? <apteryx>we really should rename gdk-pixbuf+svg to gdk-pixbuf, and have the later variant gdk-pixbuf-sans-svg or somethhing; that's confusing <rwp>lfam, Yes please CC me on it. That would be great. <rwp>I woke up to having about 3,500 messages of queued mail through the anti-spam today. And about 2,800 of those messages were from the guix-ci. <rwp>Yes. Things are a little backlogged today due to the queue. So I started digging trying to figure out what might be different today over other days. <rwp>Yesterday the queue load was high but things were getting processed through spamassassin okay. So I didn't dig into it further at that time. <rwp>It looks like this new process is new since Feb 22, 2021 so it's still new and not yet fully mature yet. <lfam>Alright I sent the message <narispo>efraim: what matters is what is in the repo? <narispo>otherwise, let's just remove that package <narispo>version 3.4.x is under AGPL, even for latest versions AFAICT <rwp>lfam, Perfect! I added some more information to it too. But I think I am getting a handle on things now. So I know how to tune things. <narispo>efraim: did you look at the branch? because I explictly checked before updating. <narispo>I wouldnt have pushed the thing if that wasnt the case <efraim>narispo: it looks like I was mistaken, I thought all the code after the switch was changed to the new license <narispo>efraim: check the release tarball just to be sure (I didnt do that), but yes, should be fine still <lfam>mongodb in Guix is stuck using the unsupported openssl. Am I too optimistic that 3.4.24 can use current openssl? <nckx>rwp: Sorry if this was mentioned above, but could we exempt the ci list from spam filtering + disable posting by anyone except the CI? <efraim>narispo: I'll revert my reversion and update the note <narispo>In fact, even much later versions are still under AGPL <rwp>nckx, Yes. And that is basically what I have half done already to mitigate the wave. But was wanting to understand the context before I just made changes. <lfam>Oof, I made a typo in addressing that message to guix-sysadmin <narispo>efraim: switch to SSPL happened at 4.0.4 it seems <efraim>narispo: I should've double checked before reverting the update <narispo>efraim: No worries, I could've included something more precise in the commit message, but now we know, collectively, what the licensing situation is actually like for mongodb <narispo>it seems some branches like 3.6.22 also are under SSPL <narispo>3.4.x is EOL by mongodb now, 3.6.x isnt but switched to SSPL as well <narispo>so if 3.4.x doesnt support openssl 1.1.1 then we will remove the mongodb package shortly it seems <lfam>Yeah, it seems that mongo is on its last legs <lfam>Pity, after all the work that went into it <narispo>3.4.x release branch supports openssl 1.1.1 <lle-bout>we can keep it around for longer, probably <lfam>I tried to make it use openssl 1.1 but IIRC it didn't work <lfam>But, I don't recall the details now <lle-bout>lfam: when is that? It seems 3.4.24 may have changed something <lfam>I did an initial survey of openssl 1.0 in Guix <lle-bout>lfam: but mongodb wasnt updated to 3.4.24 so let's try again now (doing so) <lle-bout>lfam: you got a compiler error or at runtime? seems it built for me <lfam>I don't recall the details now <lfam>I would have made it use openssl 1.1 if it had worked <lle-bout>lfam: okay, because I can't test mongodb for much, don't have a scenario <lfam>I don't think we need to worry about comprehensive testing. It's not widely used in Guix and their test suite should work <lle-bout>I'm not sure we have even a single current user of our mongodb package.. <lfam>There are some mongo-related packages that depend on it <efraim>I suppose the mongo test uses it <efraim>no i mean I think there's a system test <lfam>"Version 1.1.1 will be supported until 2023-09-11" <lfam>Maybe next time we will be able to work on their schedule <lfam>And maybe by that time, we can improve our Rust bootstrap to not depend on openssl 1.0 <lfam>It's not a security risk, but it's kind of annoying <lle-bout>lfam: not sure why a bootstrap should ever depend on a TLS lib, since it couldnt do networking <lfam>I'm not familiar with the details <lfam>Also, openssl is widely used to provide cryptographic implementations, not just networking <lfam>The process of removing Qt 4 started in 2016 <lfam>I think we could do it more quickly in other cases <lle-bout>lfam: yes.. also telegram-desktop? will it go? <lfam>No, the packages were tweaked to avoid depending on Qt 4 <lfam>The good thing is that Qt 4 has been abandoned upstream for so long that nothing really depends on it anymore <lfam>It was already abandoned in 2016 <lfam>But at that time, we were focused on adding packages, not removing them. The project was too young to have developed a workflow around this <efraim>looks like they still target python27 for building <lle-bout>efraim: running your new wip-ppc64le-for-master branch now! <lfam>efraim: What targets python27? <efraim>also it needs more than 32GB of ram to compile on 24 cores <lfam>Well, we will probably keep python 2 for a bit longer. There is still some support from other distros <efraim>I have 64 but I left tmpfs as a ramdisk, which defaults to 50% of ram <efraim>*left tmpfs as a default ramdisk <lfam>I actually am considering updating to python 2.7.18 (final version) for the upcoming release. We are changing the python package anyways, by ungrafting a security patch update <lle-bout>"[testsuite] Fatal Assertion 28561 at src/mongo/db/storage/wiredtiger/wiredtiger_kv_engine.cpp 274" - after openssl 1.1.1 upgrade, maybe non-deterministic, will try again <lfam>It would be less "safe" of an update for what is supposed to be a minor release <efraim>wiredtiger might also just be old <lfam>I'm concerned that we don't have the coordination to fix any fallout in time <lfam>Like, if a lot of dependent packages need to be adjusted <lfam>Whereas a single minor patch probably won't break anything <lfam>It's the kind of things we have to think about when scheduling releases or big branch merges <lle-bout>What I find great about security it's that it gives a reason to move forward and don't keep things ancient, it actually ensures we only package supported things more or less <lle-bout>Which boots package quality, unrelated to security <efraim>if wip-ppc64le-for-desktop works I might do the same for 32-bit ppc and mark it as just experimentally supported in the manual <lfam>But a contrary point is that it's important to give some advance notice about removing important things, like python 2 <lle-bout>efraim: it doesnt cause world rebuilds for non-ppc? <efraim>i'd slide it in like with ppc64le and then fully merge it in core-updates <efraim>that's the plan anyway for wip-ppc64le-for-master <rwp>lfam, nckx, I think the mailing list issues are all solved now. Have the mail queues drained out and things seem good to go moving forward. <lle-bout>efraim: I mean your wip-ppc64le-for-master branch already doesnt cause world rebuilds for non-ppc[64le]? If so that's really awesome! <lfam>Thanks for your efforts rwp :) <nckx>rwp: Thanks and sorry you had to deal with that. It certainly wasn't expected. <efraim>lle-bout: yeah, it took a couple of tries to make sure everything worked <rwp>Things change and then there are unintended consequences. It's not a big deal. Not in the long term. Just in the short term there are growing pains! <lfam>While the channel is busy, I should just ask: Should we try to update Python 2 to the final version in this upcoming release? <lfam>Or should we stick to the "safer" option of just ungrafting a patch <lfam>Actually, it would be nice to schedule a chat about coordinating for this next release. I think there are a number of things to decide <nckx>♥ putting scare quotes around the word safe. <lfam>It's already in core-updates <lfam>I guess it was epxected that we'd be finishing core-updates now <nckx>I agree with efraim, do the actually safer thing on master, hope the tests will catch any regressions. <lfam>Other questions I'm wondering about: What architectures do we officially support in the next release (armhf...)? When should we start building the release branch, for an April 18 release? And who will actually "do" the release? <efraim>oh wow, I've been holding my ppc binutils-final patch for almost a year <lfam>nckx: Wait, which is the acually safer option? The full update? Or just ungrafting the patch? <apteryx>lfam: I volunteer to participate closely in the release process <apteryx>I haven't done a release by myself yet, so I'll need some guidance, but I've studied the process relatively well during the last one. <zimoun>lfam, for the previous release, we branched something like a couple of days before releasing. So when we are almost done, one week of string freeze, then branching, then release. <lfam>So, we should start building the release branch now. I think it will probably take several days to build <zimoun>about the architecture, I am not following closely. We can disable some architectures. <lfam>We aren't building armhf substitutes at all anymore <lfam>aarch64 is barely being built <zimoun>so armf will not be included in 1.2,1. As it was not in 1.2.0 <zimoun>what do you mean by «building the release branch now»? <lfam>It will take longer than a couple days to build the changes on that branch <lfam>For one thing, it has to bootstrap rust <roptat>but we don't really want to have too much difference between that branch and master <lfam>It's not very different. It undoes the grafts, and removes some obsolete packages <apteryx>lfam: I guess this was the reason some applications failed to display some icons, perhaps <roptat>I mean, we'd like to have that in master too, right? <apteryx>gdk-pixbuf is not able to render scalable SVG icons (pretty basic stuff nowadays for an application) <lfam>We can build it now, merge it to master, and then create the release-1.2.1 branch <lfam>The important thing is that the release shouldn't include any grafts <roptat>what I mean is that we'd like to prepare the release on master, branch when ready and make sure we have substitute for everything on that branch (in addition to what cuirass managed to build), then release <lfam>This might mean delaying some grafts, or rebuilding the world twice <roptat>so we can have a wip-release or whatever, but we should merge to master before we branch release-1.2.1 out <lfam>I'll update the wip branch now. There are some new grafts <lfam>The other side of this is coordinating access to the CI resources <lfam>But, I think we are in good shape for x86_64, which is what really matters <lfam>It would be nice to get the rest of the overdrives connected to the build farm, but I don't know if it's going to happen <zimoun>ah sorry, I have overlooked at wip-next-release because for 1.2 we did (almost) everything directly on master. <lfam>I've been discussing it in the email thread you started <lfam>We can't really do these things on master since they will rebuild almost every package <zimoun>yeah, I agree. That’s my fault. And I agree about ungrafting too. <lfam>But given my recent experiences with grafts masking serious problems, I think it's important to avoid including grafts in the release <lfam>Alright, I'm going to update that branch today, and then I'll coordinate with mothacehe about building the branch <lfam>I think we can merge it to master within a week, assuming there are no big problems <lfam>I guess I am doing things a little backwards from how they've been done in the past. Sorry about that <zimoun>ok, thanks. Well, currently I am checking the avaibility of substitutes on master. And try to fix «important» (to my eyes) packages that are broken. <apteryx>raghavgururajan: as a GNOME package maintainer I think this is an important detail that you should know: anything that propagates gdk-pixbuf should propagate gdk-pixbuf+svg to stay in harmony with gtk+'s own propagated libs. <apteryx>lfam: just to be clear, that 1.2.1 would include ungrafting changes mostly? <zimoun>apteryx: yeah, and packges updates. And minor improvements. <lfam>Yes, ungrafting, update of tzdata, and removal of Qt 4 <zimoun>Bioconductor update I guess, etc. <lfam>lle-bout: I'm curious, do you see anything that will be grafted in the next week or two? <lfam>If so, we could delay building this release branch until then <lfam>I'm trying to avoid release 1.2.1 with grafts in place <lle-bout>lfam: well.. run: 'guix lint -c cve' I'm not done yet <lle-bout>efraim: glibc has few CVEs.. unsure what to do <lfam>I mean, considering that this work will never be "done" <lle-bout>lfam: I think it can! Just we are very late now. <zimoun>apteryx, lfam: one thing is to test the installer and the script. <lle-bout>It's unlikely we get more than 2-3 security updates per day then <lfam>Yes, we should coordinate a "test" weekend where we all try things <lfam>Right, I don't expect that you can see the future. But if you had anything in mind, that you know you are going to do soon <lle-bout>(we don't package go 1.15.x / 1.16.x yet) <lle-bout>lfam: well I don't check for if grafting is needed actually *before* doing them <lfam>Go is technically too big to change on the master branch, but I think we can relax the rules there. Go packages are usually very cheap to build <lfam>But, I don't think we can do it before April 18. <lle-bout>"gnupg@1.4.23: probably vulnerable to CVE-2019-13050, CVE-2019-14855, CVE-2018-12020" <lle-bout>"librsvg@2.40.21: probably vulnerable to CVE-2018-1000041" (part of the GNOME series sort of) <lfam>Updating glibc requires a core-updates cycle. It can't really be done in isolation <lfam>zimoun: I will check, thanks <lfam>If `guix pull` still works, then we are okay <lfam>Alright, this is a fruitful conversation but I have to go afk soon <lfam>I think java stuff can be done on master, not sure anymore though <zimoun>lfam, I will send an email to report the elements of the discussion. <lfam>It's really valuable to have a coordinator <lle-bout>lfam: oh yes wpewebkit and friends. but unsure needs grafting <lle-bout>lfam: perl has at least one 'high' severity one <lle-bout> perl@5.30.2: probably vulnerable to CVE-2020-10543, CVE-2020-10878, CVE-2020-12723 <lfam>In terms of what to do for the next release, I would focus on packages with a lot of dependents (`guix refresh -l`) and bugs that are remotely exploitable <lle-bout>lfam: well as you can see, there's few left, at least sqlite, perl and openjpeg. <lfam>It's a matter of judgment, but that's my approach <lle-bout>we should have severity colors in guix lint <lle-bout>if someone knows Scheme, please do! color CVEs according to severity in guix lint -c cve *lle-bout feels overwhelmed by what's left <lfam>Yeah, it can be that way <lle-bout>Let's not be late like this ever again :-) <lfam>It's tricky because we had to delay major rebuilding for a while, so a lot of fixes that would have landed via core-updates are pretty delayed <nckx>lle-bout: The dirty ANSI code work is already done in (guix colors). But don't burn yourself out over pretty colours please :) <lle-bout>nckx: they would be really useful to me *right now*, if you mean I shouldnt do it <nckx>I just meant it's not as ‘important’ as the CVE work you're doing, but (a) do whatever the hell you want, you deserve it and (b) if it helps, even better. <lle-bout>nckx: I'm not burning out, I don't think so, I like what I am doing now :-D <lle-bout>The major problem is me not knowing Scheme well enough <lle-bout>I was reading the GNU Guile manual in full the other day but had to stop because security updates don't wait <lfam>Taking 'patch' as an example <lfam>For the most part, Guix uses patch in the build sandbox <lfam>It would be helpful if there was a new release of GNU Patch <lle-bout>lfam: yes.. I asked on the mailing list to start building GNU Patch from git <lfam>The patch development seems ... low activity <lfam>Well, except for these bugs, where it doesn't work right at all :) <lfam>unzip hasn't been updated since 2009. There's no fixes available upstream, from what I can see <lfam>Debian made a patch for it, which broke things, and they had to write a followup patch <lfam>I would say, it's clear why unzip has been allowed to linger in Guix with these CVEs <lfam>On the other hand, it's an important program that handles untrusted input <nckx>Because it's freaking unzip. <nckx>I'm sure there are tools that do the same job, but I'd be unable to name them by name :) <lle-bout>Fedora made a quite good patchset so I just imported that. <lfam>Fedora is a great source for things like this <lle-bout>Fedora and Gentoo have the best security teams I think <lfam>I use Debian so I rely on them often <lfam>And, they have a comfortable user interface for security issues <nckx>lle-bout: I could try adding colours if it would really help you. <jackhill>nckx: I bet libarchive (aka bsdtar) could handle unzipping as well :) <lle-bout>nckx: it would help be prioritize work on most critical issues <lfam>Alright, now I'm really going afk <lle-bout>lfam: see you soon (aww you left already) <nckx>N.B. not today, and tomorrow is full-time non-desk work, but Saturday evening with some luck. <nckx>What kind of highlighting or is that written above? <lle-bout>there's a color code for them, just use that <lle-bout>nckx: there's reporter score and NVD review score, so use NVD review score if it exists otherwise reporter score, if nothing at all, then no color 