IRC channel logs

2021-03-07.log

back to list of logs

<lfam>sneek: later ask raghavgururajan: Do you know if the nimf package can be updated to use Qt 5? I'm planning to remove Qt 4 from Guix in the upcoming release
<sneek>Got it.
<lle-bout>lfam: Okay! Thanks for the info! By the way have you been doing security patches or noticed many of them are done recently? What are your information sources?
<lfam>Mostly, I subscribe to oss-sec and the Debian security advisories (I use Debian)
<lfam>Beyond that, just news on twitter and similar sites
<lfam>I have noticed many of your commits in this area lately :)
<lfam>It's really great
<lle-bout>lfam: I suggest you follow: <https://nvd.nist.gov/feeds/xml/cve/misc/nvd-rss.xml> - also we should maybe create convention so we don't try to investigate individual CVEs or security issues twice?
<lfam>I can't follow things like that or I'll burn out, to be honest
<lfam>I used to put more effort into security updates (you'll see it in the git log) but I got tired and had to step back a little
<lle-bout>lfam: okay! well I only read summaries it's often enough to tell if it's something to look at. I use quiterss which I packaged earlier, it has quite nice UI for that.
<lle-bout>lfam: I understand, I am feeling the same somewhat, I feel like I need more tooling and then I'll feel better.
<lfam>Good tooling definitely helps
<lle-bout>Personally I think tooling is really a lot, especially with limited number of people
<lfam>Good tooling is basically the premise of Guix :)
<lle-bout>I think with the same number of people we are now, we could do so much more with better tooling
<lle-bout>Information isnt well accessible for many aspects of GNU Guix right now
<lle-bout>I put big hope into Guix Data Service
<lle-bout>and Cuirass as well
<lle-bout>lfam: yes :-)
<lfam>Something that I have been thinking about is the value of improved communication and team coordination
<lle-bout>Also very much this! Right now we're a lot each on our sides
<lfam>In the past, the project was small enough that it was not very difficult to keep everyone on the "same page" ,so to speak
<lfam>Now it is more difficult
<lle-bout>I have no idea what is the plan in people's head like for guile-netlink? What do they plan to do with it? I saw GSOC project page, something with dustyweb's capability library being rewritten in GNU Guile
<lfam>Right, 5 years ago I would have known the answer to this and many other questions
<lfam>It's an important project for Guix
<lle-bout>lfam: is the libreplanet wiki easy to access..?
<lfam>I've never had an account :)
<lle-bout>Same
<lfam>I always preferred to focus my efforts on things internal to the Guix project, although the libreplanet wishlist is used by a lot of people
<lle-bout>For example in the #talos-workstation community we have a wiki where registration has to be confirmed but pretty much open, there's not much verification
<lfam>I don't have any concrete ideas for improving communication and coordination. But I was thinking of a more regular video / voice chat. Maybe a weekly thing
<lle-bout>So we can all centralize information there, which we do
<lfam>I see
<lle-bout>lfam: I am impressed by the quality of the wiki: https://wiki.raptorcs.com/wiki/Main_Page
<lle-bout>I know we could do all this in info manuals probably but.. barrier to entry's higher right now
<lle-bout>Also non-committers can't contribute
<lfam>In the past, Guix resisted wikis because they tend to become obsolete / out of date, but visitors don't know. Whereas the mailing list emails have a date on them, so it's obvious is they are old or not
<lfam>For example, the Arch wiki is often presented as a model we should emulate, but I often found really obsolete advice there
<lfam>But, I think there is a "sweet spot" for wikis, in terms of how many people are involved
<lfam>If there is energy to maintain the wiki, it could be a good move
<lle-bout>Arch Linux wiki is top notch! I rarely found wrong info there..
<lfam>I've found really bad advice there
<lle-bout>I can't remember any case of wrong info
<lle-bout>Well then!
<lfam>Sometimes it's good, sometimes it's bad
<lfam>But everyone seems to like it, so what do I know
<lle-bout>I think it's in general way more good than bad :-)
<lle-bout> https://libreplanet.org/wiki/Group:Guix/GSoC-2021
<lle-bout>"Project: Trusted computing: Goblins for GNU Guix"
<lfam>I also think a distor wiki can cause energy to be misdirected, from software manuals to distro wiki
<lle-bout>What's the plan?! I want to know!
<lle-bout>We should all write more blog posts most certainly
<lfam>The other difference between the manual and the wiki is that the manual is tied to a version of the software
<lfam>But overall, they serve different purposes
<lfam>Yeah, more blog posts. I am always telling people, "that would make a great blog post!"
<lle-bout>I was told for PowerPC 64-bits porting as well
<lle-bout>I will feel better writing something when it's finished
<lfam>These kinds of discussions are very fruitful when the happen "in person", I think. It's a shame we have to skip years of meetings
<lle-bout>Yes..
<lfam>I wonder if Europe will be able to host FOSDEM next February
<lfam>I think it will be possible to host events in the USA by then
<lfam>lle-bout: I'm curious if you have experience in C++
<lle-bout>lfam: yes, I'm no expert but I can find my way around averagely I would say
<lle-bout>My primary languages I know are Rust and C, but then I've done lots of the rest as well..
<lle-bout>I don't like C++ so much because it has high cognitive complexity to read/write code
<lfam>The guix-daemon is written in C++, and it's an area of the Guix codebase that perhaps languishes a bit, as Guix tends to attract Schemers
<lfam>I was just curious. It's useful to know people's skills :)
<lle-bout>lfam: ohh! then yes definitely can look!
<lle-bout>I would rewrite it in Rust when Rust GCC frontend is merged :-)
<lfam>Heh
<lfam>I think we'd rather rewrite it in Guile ;)
<lfam>There has been some work towards that goal, but it's slow
<lle-bout>Okay I see! It doesnt look that complicated to be honest!
<lfam>It could be a nice showpiece for GCC/Rust,
<lfam>Well, I think we will be glad to replace our Rust bootstrap with GCC
<lle-bout>My concern with GNU Guile is all the bits written in C, it's not memory-safe, would be nice if it was, but again we lack a model for memory-safe JIT so it's bound to be bunch of memory-unsafe code there. Scheme is memory-safe (?) so that's good but the platform that runs the Scheme also should be!
<lle-bout>(As much as possible..)
<lfam>It's true, but there can still be an improvement, if you can abstract the C parts away
<lle-bout>I see wingo is rewriting GNU Guile in Guile, which is nice, reducing amount of C code
<lfam>Although, as we saw recently with Python, there can still be serious bugs from the underlying implementation
<lfam>Although, I think that was sort of a brainfart
<lle-bout>You mean in CPython? I didnt follow Python security stuff
<lfam>The recent CVE I patched in Python was a string-safety bug
<lle-bout>I see, in Python 2? I saw it briefly was happy you patched it but didnt look closely. Strangely I didnt see it in my NVD CVE RSS feed.
<lfam>But, if I remember correctly, it was a case where they chose not to (forgot to change it?) use their safe implementation of that function
<lfam>In all versions of Python
<lfam> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-3177
<lle-bout>I see..
<lfam>It's interesting to think that, not very long ago, this sort of thing was not considered exploitable
<lfam>I wonder, in 20 years, why will we need to replace Rust? ;)
<lle-bout>lfam: Rust definitely doesnt solve logic bugs, but it still narrows down the overall risk.
<lfam>Well, we will always have logic bugs :)
<lfam>At least, until people are completely removed from the picture
<lle-bout>lfam: The next big thing when it comes to blue team security is probably this: https://hacks.mozilla.org/2019/11/announcing-the-bytecode-alliance/
<lfam>Hm, it will be tough without involving the Chromium project.
<lle-bout>WebAssembly and WASI with "nano-processes" (in that each individual piece of code, a.k.a. library would be constrained to it's own capabilities, so you could distrust libraries you use..)
<lle-bout>lfam: what do you mean?
<lle-bout>Lucet can basically AOT compile WebAssembly.. (and keep it's isolation guarantees..) which is really interesting..
<lfam>I guess that I don't really know what wasm is. I thought it was something that browsers use. And chromium is the big one
<lle-bout>It basically means you can split the memory space of a process in several (since in WebAssembly each "module" has it's own), so C code can become safe to use (can't reach the rest of your code's memory anymore)
<lle-bout>lfam: It can also be used standalone, it's a bit like Java byte code..
<lle-bout>lfam: with this: https://github.com/bytecodealliance/wasmtime
<lfam>To me, the future of secure computing is like iOS
<lle-bout>If GNU Guile can compile Scheme to WebAssembly then it can benefit from all this.
<lle-bout>There's this: https://github.com/google/schism
<lfam>Already, there are a lot of client-server applications that are only allowed to run on mobile devices, because the security model on those devices is so much better. The companies that offer services via these apps have decided to leave the desktop behind, for security reasons
<lfam>For example, banking apps
<lle-bout>lfam: The things ByteCodeAlliance do goes another whole level further, by further putting strict permissions between each individual libraries or pieces of code in a single application (without breaking POSIX)
<lfam>It does sound reminiscent of these mobile OS APIs
<lle-bout>It's capability-based security, even more robust than iOS permission system
<lfam>I think, we should feel comfortable leaving POSIX behind
<lle-bout>lfam: yes but lots of software still goes by POSIX assumptions so it's really great they found a transition path there.
<lfam>That is true
<lle-bout>I don't know what it's going to give in practice..
<lfam>We never know where our creations will lead us :)
<lle-bout>How developers will be using it in practice, in general
<lle-bout>I feel like the capability tagging is something nobody wants to do, after all.
<lle-bout>So it has to be "natural" (no additional effort to obtain it)
<lfam>Sometimes, a small group has to do a lot of boring busywork to begin the project
<lfam>Like package things for Guix in the early days
<lle-bout>lfam: yes :-)
<lle-bout>I really need to wrap my head around Scheme
<lle-bout>Then I will feel so empowered to improve GNU Guix in every way possible aa!
<lfam>It will come
<lle-bout>Automate all the packager things!
<lfam>I came from C and shell stuff, and it has been slow to learn Scheme
<lle-bout>Importers, refreshers, linters, package transformations..!
<lfam>In C, it's clear what is a statement, expression, etc
<lfam>In Scheme... everything is code, and that made it hard to understand
<lle-bout>At first I thought in Scheme there was no line-by-line execution of code
<lle-bout>That everything had to be arguments of functions
<lle-bout>But then I realized nope
<lle-bout>GNU Guix packages are very imperative after all
<lle-bout>I'm only more or less starting to grasp the idea of "escape levels", it really helped me when I read somewhere they were compared to the '\' escape characters, I didnt get that before.
<pkill9>lfam: does that mean we lose all our existing software?
<lfam>Does what mean that?
<pkill9>that the iOS structure is the future of computing
<pkill9>and leaving POSIX behind
<lfam>iOS and Android both take a similar approach in this area, although iOS is further along
<lfam>I think that there are more people using smartphones as their only computing devices than use POSIX-type systems, and that isn't going to change :/
<lfam>And from the other end, the enterprise, applications are being removed from "operating systems" and plugged directly into AWS Lambda-style services
<lle-bout>I am not sure iOS or Android are role models top-down when it comes to securing the platform, there's much better to do in the kernel area in particular I think
<lfam>They aren't perfect but iOS especially is way more secure than GNU / Linux or any other old-school OS
<lle-bout>iOS/Android exists today but I think it's only a limited version of what we could do in terms of capability-based security, permission-based security is only a stripped down version of it
<lfam>Yeah, and the functionality is also fairly limited
<lfam>But it seems that people don't mind
<lle-bout>Software freedom is not really present there
<lfam>That's true
<lle-bout>In some ways there's a way to do security with software freedom spirit, some times security is going against software freedom..
<lfam>Yeah
<lfam>Apple decided on security at all costs
<lfam>But, on the other hand, exploits against iOS are priced in hundreds of thousands or millions of dollars, whereas exploits in GNU / Linux are more or less free
<lfam>And you could do a lot more damage with a remote exploit against GNU / Linux
<lfam>So, if you only care about security, it seems like their approach is working
<lle-bout>I think there's more precious data behind GNU/Linux systems than iOS.
<lfam>That's what I'm saying
<lfam>Even though the demand for Linux bugs seems like it would be much higher, the price of compromise is extremely low
<lfam>Apple also hires most people hacking iOS, so that helps drive the exploit price up
<lfam>So, I think we should be bold in improving GNU / Linux
<pkill9>what's the price of compromise mean?
<lfam>I mean, if you want to buy an exploit to hack some kind of computer, there's a market for that.
<pkill9>i don't get it, why is the price of linux/gnu exploits lower if the data it hides is higher value?
<lfam>Because it's really easy to break into GNU / Linux
<pkill9>ok
<pkill9>i thought it was supposed to be really secure
<pkill9>atleast over networks
<lle-bout>I don't think it's *that* easy but easier than Darwin? Maybe..
<lfam>I think it got that reputation when it was competing with Windows in the 1990s and early 2000s, and it was more better
<lfam>I mean, it was better, or more secure
<lle-bout>It's still better conceptually, but it's lacking some kernel isolation facilities
<pkill9>so i've been living a lie :/ lol
<lfam>But compared to iOS, it's full of holes, and basically lacking a security model at all. Remember, UNIX was created in the early 1970s, and GNU / Linux evolved from that.
<pkill9>linux is used in a lot of servers, i would have thought it's secure for that
<lfam>In the early days, security wasn't considered to be necessary, since the only people with access to computers were considered trustworthy
<pkill9>hmm
<lle-bout>I think it's a bit of an exageration to go that far, price of exploits arent only driven by difficulty to exploit, Apple pays, many actors in GNU/Linux world pay but it's more spread out.
<lfam>I would consider Linux servers to be secure against mass exploitation attempts, if the server is kept up to date. It's less sure if some organization chooses to target the server
<lfam>That's a good point lle-bout. There's no major buyer for GNU / Linux bugs
<lle-bout>Red Hat has good internal security team so doesnt "buy" bugs
<lfam>I think it's a mistake to not pay bug bounties
<lfam>For a group like Red Hat, especially
<lfam>They can afford them
<lle-bout>I think it's better to hire security people than pay bug bounties
<lfam>Well, you do both
<lfam>Even with a great security team, the attackers have a massive advantage
<lle-bout>Because bug bounties are actually less rewarding for researchers in the long run.. as an individual you might be extremely brilliant and find one RCE in a year, you could still be quite poor doing it.
<lfam>Yeah, that's a good point. It's part of why Apple just hires them and makes them sign confidentiality agreements
<lle-bout>"hire" or sign longer term contract with
<lle-bout>bounties don't reward research that isnt fruitful but that research is still important
<pkill9>are there any FOSS alternatives to linux with security built in?
<lfam>Heh, it's not a simple question to answer. First you have to define security :)
<pkill9>the iOS model I mean
<lfam>Not that I know of
<lle-bout>pkill9: security's hard to define but there's the sel4 kernel that's interesting. iOS's kernel darwin is Free Software, but no mature Free Software userspace works on it AFAICT.
<lfam>There are projects that try to improve Linux, like Qubes
<lle-bout>pkill9: Also Redox: https://github.com/redox-os/kernel
<lle-bout>sorry, gitlab link rather: https://gitlab.redox-os.org/redox-os/kernel
<pkill9>sel4 does sound interesting "Security is no excuse for bad performance" https://sel4.systems/
<lle-bout>The big problem is hardware support, Linux gets all of it.
<pkill9>yea
<lle-bout>Other kernels often are forced to implement things to wrap Linux drivers so they can use them somehow.
<pkill9>is the hurd structured for security?
<pkill9>i'm guessing no
<pkill9>it was born roughly around when linux was born
<lle-bout>pkill9: yes if it worked better it would be a better base than what Linux is today, but it may have worst performance etc..
<terpri_>there are also the netbsd rump kernel drivers that can work with e.g. the hurd
<terpri_>there were experiments with replacing mach in the hurd as well, about a decade ago: https://www.gnu.org/software/hurd/history/port_to_another_microkernel.html
<terpri_>well, more like 15 years ago
<bone-baboon>Previously I was unable to install Guix using the stable x86_64 Gnu Guix system 1.2.0 and I shared the issues I was having in this channel. I have now got Guix installed by using the 1.1.0 install ISO. There may be an issue with the 1.2.0 install ISO.
<vagrantc>there's a more recent wip installer image somewhere...
<vagrantc> https://guix.gnu.org/en/download/latest/
<bone-baboon>vagrantc: Thanks for pointing that out.
<pkill9>how insecure can linux be really? it's used in all sorts of things
<pkill9>i suppose the same could be said for windows
<vagrantc>bike locks are used on lots of bikes, too
<dftxbs3e>pkill9, do not worry so much, you are not at severe risk
<pkill9>yea, i am a worrier by nature
<dftxbs3e>pkill9, Linux is insecure in that any flaw in any part of the code can have severe consequences with little mitigation but lots of the code is reviewed/audited a lot and doesnt change a lot since a long while. A kernel with a better security model would adopt preventive measures in that a flaw in a local part of the kernel cannot have overreaching impact on the whole system's security.
<dftxbs3e>Linux is a monolithic kernel, it's also what makes it so great with performance and all, other attempts are good but also experimental in many ways
<dftxbs3e>pkill9, also lots of the code present in the Linux kernel actually doesnt need to absolutely be there, a kernel with a better security model would strictly minimize privileged code or adopt mechanisms to make parts of the kernel as privileged as they need to be instead of fully privileged.
<dftxbs3e>Microkernels on the other hand try to isolate functionality in modules that talk to each other via a safe IPC interface
<dftxbs3e>And each module would be isolated in some way (not a kernel engineer so can't tell much more)
<dftxbs3e>pkill9, in a way, Emacs is also monolithic which makes it insecure in similar ways though not totally because ELisp is a memory-safe language (?)
<dftxbs3e>I can't tell what are common security issues in Emacs and it's packages
<dftxbs3e>pkill9, the paragraph about the Linux kernel specially speaks about security of kernel code itself, but the abstractions exposed to user-space are quite good when it comes to monolithic kernel security
<pkill9>ok, thanks
<dftxbs3e>pkill9, you are not going to get your machines compromised so easily because the TCP/IP stack is really well tested in general do not worry
<dftxbs3e>(the main and worst remote attack vector)
***apteryx_1 is now known as apteryx
<raghavgururajan>Hello Guix!
<sneek>raghavgururajan, you have 1 message!
<sneek>raghavgururajan, lfam says: Do you know if the nimf package can be updated to use Qt 5? I'm planning to remove Qt 4 from Guix in the upcoming release
<raghavgururajan>lfam: For nimf, can you merge attached patches to master?
<raghavgururajan> /s/attached/following
<raghavgururajan> https://jabber.hot-chilli.net/jabberupload/share_v2.php/a0d22572-5d93-47a2-9cfa-5b49662d459e/0001-gnu-nimf-Use-separate-outputs-for-gtk-and-qt-modules.patch
<raghavgururajan> https://jabber.hot-chilli.net/jabberupload/share_v2.php/0dd9edbe-f528-4ae9-b3fe-a12ffdc3910d/0002-gnu-nimf-Disable-qt4-support.patch
<bdju>thanks for updating the qutebrowser package to 2.x!
<brown121407>I had to install some things with Nix last week and I noticed that it felt a lot faster than Guix. Why is this speed difference between the two package managers?
<marusich>Has anyone else noticed that on core-updates, emacs now only supports x86_64-linux?
<marusich>It seems to be becuase of a newly (not sure when?) introduced transitive dependency (via inputs) on rust.
<marusich>The rust package is only supported on x86_64-linux; this is explicitly declared in the rust-1.29 package definition and inherited in various places by other rust packag definitions.
<marusich>As a result, any package that ever winds up with rust in its transitive inputs, will only be supported on x86_64-linux.
<marusich>Emacs is now in that situtaion.
<marusich>There are likely many more, so I feel like I can't be the first one to have noticed this.
<marusich>I noticed because this indirectly causes "make check" to fail if you try to run it on a non-x86_64-linux system.
<marusich>I was wondering if anyone knew anything about it. Not being able to build Emacs (and likely other packages) on non-x86_64-linux arches seems like a bummer.
<marusich>Previously, at some point in the past, it seems Emacs did not contain rust in its transitive closure of inputs.
<marusich>Incidentally, dftxbs3e, we can fix the wip-ppc64le tests/guix-package.sh test failure by changing the test code so that it creates dummy packages by inheriting from something else, other than emacs, which is supported on any system. Changing it to coreutils fixes the test failure.
<leoprikler>marusich: I'm trying to graph the situation, but I get https://paste.gnome.org/pfceazdnm
<marusich>I'm also gonna send an email about it
<marusich>just to start the discussion, since i didn't find any emails
<marusich>leoprikler, that link shows an error; maybe you meant to share something else?
<marusich>Oh, I see
<marusich>You got this error when trying to make a graph.
<leoprikler>Okay, I got it, Rust gets included through librsvg@2.50.3.
<marusich>I am able to run "guix graph", so maybe it's specific to your verison. I was using wip-ppc64le, for what it's worth. I imagine you could use the commit from core-updates that it is based off of, which is currently 4f4b749e75b38b8c08b4f67ef51c2c8740999e28
<leoprikler>Damn you librsvg.
<marusich>yeah, that's what i see also.
<marusich>my notes about this: https://paste.debian.net/1188201/
<marusich>i have to run
***rekado_ is now known as rekado
<efraim>I think I have a fix for building guile-3.0.5 on powerpc-linux, I'm testing it on my G4 now. If it works I can update the wip-ppc branch
<raghavgururajan>leoprikler: I am trying to package qtlockedfile separately for Nextcloud-client. Strange, I don't see any .so/.a files built in the build-dir. https://paste.debian.net/1188210/
<brown121407>Hi Guix, I'm trying to learn how multi-output packages work, but I don't really understand it... I don't see any kind of "do this for this output" code. Do all outputs get built anyways? I looked at coq:ide and rust:doc.
<efraim>brown121407: by default all the outputs have the license file installed into them. Some outputs have special treatment in the build code, so if you include a 'lib' output with gnu-build-system it automatically gets the lib and includes directories
<brown121407>efraim: thanks. Is there a way to say in the arguments field, for example in a build phase, "do this if the user selected this output"?
<brown121407>I do not want to build documentation, unless the user selected package:doc
<efraim>I don't believe there's currently a way to do that. When it builds the package it follows the build recipe, so it either builds the docs or it doesn't
<efraim>I suppose you could create a separate package without documentation, but normally there's a good reason for it.
<brown121407>Thank you.
<nckx>Good morning, Guix.
<raghavgururajan>nckx, Morning!
<nckx>marusich: I don't think I've ever said oof before, but... oof. ‘Supported’ architectures without emacs is close to an oxymoron.
<nckx>Nor any regular GUI browser.
<raghavgururajan>Any ideas on how to build this? https://paste.debian.net/1188216/
<leoprikler>raghavgururajan: only object files?
<nckx>raghavgururajan: It's not actually building anything, you need <https://paste.debian.net/plain/1188217>. I don't understand the root cause of the error that follows though.
<nckx>A missing libQt5Solutions_LockedFile-head.so.1.0.0.
<nckx>Using mv -f in Makefiles is bestest practice.
<nckx>Oh, but it still means it existed at some point, hm.
<raghavgururajan>> leoprikler‎: raghavgururajan: only object files?
<raghavgururajan>You mean, it gives only object files?
<nckx>Yes.
<raghavgururajan>nckx: I was wondering if I could manually invoke gcc to build the lib.
<nckx>No. See paste.
<leoprikler>It's technically possible, but you shouldn't.
<nckx>(You undoubtedly could, don't.)
<leoprikler>Using available configure options (and if lacking patching the build to add them) is a preferable solution.
<leoprikler>Do we have package parameters yet?
*raghavgururajan checks
<nckx>No.
<nckx>libQt5Solutions_LockedFile-head.so.1.0.0 exists, then ‘make install’ deletes it, then tries to install it.
<nckx>👍
<raghavgururajan>leoprikler, nckx: Phew! https://paste.debian.net/1188218/
<leoprikler>LGTM
<nckx>Ew.
<nckx>raghavgururajan: If it works, it works!
<raghavgururajan>nckx: \o/ Thanks!
<leoprikler>could you check whether the same recipe applies to all qtsolutions?
<leoprikler>if so, you could write a function to generate the packages for a specific commit
<leoprikler>s/function/procedure/:)
<leoprikler>although for install I think you want to define that in terms of copy-build-system
<raghavgururajan>leoprikler: Sure!
<leoprikler>i.e. install all shared objects in lib and all headers in include
<nckx>raghavgururajan: If you keep your ‘Phew’ solution, could you add a comment explaining that ‘install’ is performed as part of the ‘build’ phase, and that the two are hard to separate? Assuming that's the case.
<raghavgururajan>nckx: Sure!
<kcurtet>Hi people
<nckx>Hi kcurtet.
<kcurtet>Any knows how to add a menu entry for grub to chainload a debian grub or configfile to
<kcurtet>it
<kcurtet>Sry for my english :P
<kcurtet>I want to load the grub of my debian install from my guix grub
<fnstudio>i seem to have hit a wall with my (simple!) experiments with org-mode + guix environment for literate programming
<fnstudio>i naively thought that a guix environment could be set up in a shell code block for then a scheme/python/etc... code block to be able to use the env itself, its libraries, etc...
<fnstudio>that doesn't seem to be the case as the env variables set in the shell block are not shared with the other envs - apparently
<fnstudio>there are a few block posts around on how to do this (some of them are about python's venvs or nix, but it doesn't really matter i guess) but they seem to hinge around direnv
<fnstudio>direnv doesn't really seem to be a solution to my problem, as i liked the idea of being very declarative in a visible way, eg to tell my reader "look, this is a shell (or elisp, ...) block and i'm now going to install this library here"
<nckx>kcurtet: I don't think that's currently possible out of the box, sorry. Guix's GRUB configuration support is very basic and only supports Linux kernel+initrd+command line menu entries.
<fnstudio>direnv seems to be doing things very nicely but too much automatically and transparently for my scenario, i think
<kcurtet>I can maybe create a custom menu entry
<kcurtet>its lisp
<kcurtet>xD
<kcurtet>But im not sure how to start
<kcurtet>just adding it before my config maybe
<nckx>An inverse approach is to use (installer #~(const #t)) in your Guix GRUB configuration record. This will disable (re)installing GRUB altogether on every ‘guix system reconfigure’, but will still update Guix's grub.cfg, so you can configfile that from Debian's GRUB.
*nckx AFK.
<kcurtet>fnstudio: i think u can create a profile for u env and then load it to emacs with emacs-guix but not sure about that
<kcurtet>nckx: Yes its my alternative solution but im triying to hack into guix
<fnstudio>kcurtet: thanks, i'll look into that
<kcurtet>Any advaice about setup emacs to edit my /etc/config.csm to have autocompletion now i just adding a guix repo to my geiser load path an then ,use (gnu) ,use (guix)
<kcurtet>maybe i have to go to emacs channel
<lambdanon>Hi, I seem to have run into trouble with guix archive --authorize. I tried to fix a problem where my Guile REPL said I was missing locales. I found this issues page for the fix, but I can't install packages as root and Guile no longer launches outside of geiser
<lambdanon> https://issues.guix.gnu.org/41603
<lambdanon>This told me to do guix archive --authorize < /root/.config.guix/current/share/ci.guix.gnu.org.pub
<lambdanon>so I did sudo guix archive --authorize ~/.config...
<lambdanon>I think that input redirection didn't apply to sudo, so it took the public key from my home directory? Either way, when I try any GUIX command as root, I now get an error saying "error: directory /var/guix/profiles/per-user/<username> is not owned by you". It is, in fact, owned by me
<nckx>lambdanon: Input redirection is applied by the shell, as is ~ expansion. So your ~ here was ~lambdanon, not ~root. It shouldn't matter though, since both keys are probably the same.
<nckx>lambdanon: How ‘as root’?
<lambdanon>The issues page seemed to simply denote the # symbol, implying `su`. I used sudo
<nckx>That's fine, as long as you understand the difference.
<nckx>lambdanon: Can you provide the exact command you ran to get the ‘not owned’ error, and the exact output (no ‘<username>’ replacements)?
<nckx>You can use paste.debian.net if it's more than 2 lines in total.
<lambdanon>I tried `guix pull`, `guix install`, `guix package -u`, all have the same error
<lambdanon>The error message is "guix {pull,package,install}: error: directory /var/guix/profile/per-user/blueberry is not owned by you. hint: please change the owner of `/var/guix/profiles/per-user/blueberry to user "blueberry"`"
<lambdanon>When I look at the permissions, the file in question is already owned by me
<lambdanon>When I change the group from blueberry to root, the issue persists
<lambdanon>and when I change it back, the issue persists
<nckx>So ‘stat -c %U:%G /var/guix/profiles/per-user/blueberry’ returns blueberry:root?
<lambdanon>It did, but then I changed it to blueberry:users in an attempt to fix it, but the same error cropped up
<nckx>And you are not using sudo and your shell is running as blueberry?
<lambdanon>I'm using su
<lambdanon>When I use sudo, guix package seems to work fine. Probably because it's using the authorization in /home/blueberry/.config...
<nckx>So you're at a root shell, you run ‘guix pull’, and Guix says that /var/guix/profiles/per-user/blueberry is not owned by you.
<lambdanon>Yes
<lambdanon>Okay, I entered another TTY and logged in as root. No issues with guix pull
<lambdanon> I was using su from vterm. Perhaps that was causing issues?
<nckx>‘guix archive --authorize’ reads stdin (https://git.savannah.gnu.org/cgit/guix.git/tree/etc/substitutes/berlin.guix.gnu.org.pub) and appends its contents to /etc/guix/acl. It has nothing to do with users. It can't have the effect you describe.
<nckx>lambdanon: I think this is because you used ‘su’ and not ‘su -’.
<nckx>If you run ‘env | grep blueberry’ in a ‘su’ and ‘su -’ shell respectively you'll see the huge difference.
<nckx>I think it's ‘expected’ and ‘correct’, as Unix goes... just complex and arcane.
<lambdanon>nckh: Ah, that's it
<lambdanon>Problem solved. Apologies for using up your time
<nckx>That's why we're here.
<nckx>That said, /me AFK. Enjoy your day lambdanon.
<raghavgururajan>leoprikler: How do I skip a sub-dir during install-plan? For example, foo/src/foo.h should be installed as foo/foo.h.
<leoprikler>I think you should do something like ("src" "include" #:include-regexp ".*\\.h")
<leoprikler>Instead of ("." "include")
<pkill9>is there a reliable regex for extracting the package name from a store path? I think the version can be anything so I don't think there is
<pkill9>hmm actually for my usecase it would be beneficial to keep the version
<cbaines>pkill9, if you want to work with packages, you should probably work with the package, rather than store items
<pkill9>yea
<pkill9>I'm doing it the hacky wya for now
<pkill9>way*
<civodul>apteryx: hey ho! i have tests/{builder,pack}.scm failures on core-updates that may have to do with patch-and-repack and changes and the new python-build-system tests
<civodul>does that ring a bell?
<leoprikler>pkill9: There is a method to strip the store prefix, but I can't recall its name. You'll be left with <package>-<version> though.
<pkill9>i've done that for now
*civodul made good progress on wip-build-systems-gexp
<cbaines>civodul, sounds good :)
<cbaines>the Guix Data Service is attempting to process it, but hasn't succeeded yet https://data.guix-patches.cbaines.net/repository/2/branch/wip-build-systems-gexp
<cbaines>maybe this revision will be the first success...
<civodul>cbaines: great that you've plugged it in!
<civodul>i still have to convert a bunch of build systems
<civodul>perhaps that's what causing failures
<cbaines>the https://data.guix-patches.cbaines.net/ instance of the Guix Data Service automatically processes all branches
<civodul>but we should soon be able to build it
*civodul crosses fingers
<cbaines>(at least those that are updated)
<civodul>oh cool
<civodul>also there are probably typos here and there in (guix build-system *)
<civodul>like those that lead to "no code for module (unquote-splicing modules)" :-)
<raghavgururajan>leoprikler: What if I wanna install foo/src/foo.h and bar/src/bar.h?
<leoprikler>then it depends where you want to put them
<leoprikler>e.g. ("foo/src/" "include/foo") ("bar/src/" "include/bar")
<ruffni>i have some trouble getting an AMD machine to run after quasi-successful (meaning: no failure during installation, but now it won't boot) installation of guix. i guess i should disable some kernel-modules, but adding to /etc/modprobe.d won't change a thing. also, adding the directory to the directory where guix populates /etc from fails (it throws me into a guile-shell). is it even possible or should i restart with the installation
<ruffni>process?
<leoprikler>if it's just modprobe, you might want to change the boot parameters on grub?
<leoprikler>just f2 like always and do your modifications
<leoprikler>if that fails then yeah, you'll have to redo your install
<raghavgururajan>leoprikler: Cool!
<ruffni>leprikler: k, thanks!
<ruffni>i also get this mysterious(?) "error in finalization thread: Success" message. what does it mean?
<ruffni>huh. no luck. it's weird though since the installer boots/works just fine.
<raghavgururajan>leoprikler: Looks good? https://paste.debian.net/1188248/
<ruffni>on top of the screen i see `GC Warning: "pthread_getattr_np or pthread_attr_getstack failed for main thread"' and `GC Warning: Couldn't read /proc/stat'
<leoprikler>those GC warnings are harmless, the true error probably pops up due to graphics
<leoprikler>you could do a minimal install – then you'd get a shell, but no desktop stuff
<ruffni>i guess that's alright. since i'll then be able to roll-back any misconfiguration ;)
<leoprikler>If you reinstall everything, you won't have your old config, I'm afraid.
<leoprikler>Hence why you ought to try to get to just a shell first.
<ruffni>there was literally nothing in it :) i'm just trying to get GUIX to run on that machine
<leoprikler>okay, in that case go ahead
<leoprikler>Remember to add an SSH service. Even if you can't get graphics, the ssh server should give you a (remote) shell.
<ruffni>even if it "crashes" so early on? no luck btw, boot is stuck at the very same position....
<leoprikler>"crashes" how?
<ruffni>it's stuck after the messages above
<ruffni>+ one from udev about ignoring a message
<leoprikler>raghavgururajan: Now you're packaging all solutions as one package. I was thinking about a "one package per solution" kind of deal.
<leoprikler>when it's launching udev you're already midway into graphical territory
<raghavgururajan>leoprikler: It follows the Qt norm. Like QtBase consists of QtCore, QtGui etc. Likewise, QtSolutions consists of QtLockedFile, QtSingleApplication etc.
<leoprikler>hmm, very well, but then do a for-each please
<raghavgururajan>leoprikler: I was actually trying to do that. Got confused. Could you give me an example please?
<raghavgururajan>Not sure how to pass two arguments to for-each
<leoprikler>(replace 'configure (lambda _ (for-each (lambda (solution) (with-directory-excursion solution (invoke "./configure" "-library") (invoke "qmake"))))))
<leoprikler>(replace 'build (lambda _ (for-each (lambda (solution) (with-directory-excursion solution (invoke "make"))) '("qtlockedfile" ...))))
<leoprikler>the first one is missing the args sadly
<leoprikler>also the phase you called configure should be patch-sources and you should patch all sources in one go then
<leoprikler>and since you're now using directory-excursions you no longer need those gratuitous ".."s everywhere
*pkill9 is making a tool to containerise all the applications
<dustyweb>pkill9: ooh
<raghavgururajan>leoprikler: Thanks! Did introduce args correctly? https://paste.debian.net/1188258/
<leoprikler>why the args?
<leoprikler>seems like you're going to get an unbound variable there
<raghavgururajan>leoprikler: You said the first one is missing args
<raghavgururajan>oh you meant the lists?
<leoprikler>yep
<raghavgururajan>Cool!
<leoprikler>the second one had the list, the first one did not
<leoprikler>btw. if you only have strings, prefer '(...)
<raghavgururajan>leoprikler: The 'install phase is fine right?
<leoprikler>it's missing the shared objects afaict and there's spurious ".."s
<leoprikler>you shouldn't rely on the "\\$\\$PWD" hack if you have copy-build-system at your disposal
<raghavgururajan>The .so files got installed.
<leoprikler>see above
<raghavgururajan>you mean version numbers?
<leoprikler>"you shouldn't rely…"
<leoprikler>the ..s come from jumping up a directory. That's not necessary when using excursions
<pkill9>how safe are guix containers from code breaking out of the container?
<raghavgururajan>leoprikler: I tried the same scheme on 'install. But no files got installed. https://paste.debian.net/1188263/
<raghavgururajan>Am I doing something wrong?
<raghavgururajan>*no headers got
<pkill9>with a sandboxing tool, guix will be a great desktop system
<pkill9>not that it isn't already
<pkill9>but it will feel more complete
<leoprikler>raghavgururajan: yep, you're creating a procedure instead of actually evaluating the code
<leoprikler>(with-directory-excursion solution (lambda ...)) → (with-directory-excursuion solution (apply ...))
<fnstudio>pkill9: you mean something along the lines of qubes os?
<pkill9>fnstudio: more like the android model
<pkill9>but simpler
<pkill9>and hacker friendly
<fnstudio>pkill9: i see (but not terribly familiar with android); something like apparmor?
<fnstudio>anyway, i got it
<pkill9>i'm not sure
<fnstudio>sounds like a very intersting line of development
<pkill9>it's already working really nice
<pkill9>i need to redo the whole thing though to structure the code nicer
<pkill9>but atm all the aplications keep their data in their own directory
<pkill9>my home directory is no lnger a monstrosity
<pkill9>longer*
<fnstudio>how did you achieve that?
<raghavgururajan>leoprikler: Correct? https://paste.debian.net/1188267/
<pkill9>a guile script that calls guix environment --container (which i used from elsewhere)
<pkill9>and sets the home directory differently for each application
<leoprikler>this is not C++, go away with your immediately invoked lambda expressions
<leoprikler>The prophecy said, you were going to reduce extraneous parentheses, not add more to them! (Apologies for the Star Wars reference.)
<raghavgururajan> https://paste.debian.net/1188271/
<fnstudio>pkill9: nifty! i must admit i never tried "--container" for gui apps, does X handle that with containers?
<leoprikler>you need to pass through some variables for X, but it's fine
<fnstudio>(can i do containers if running on a foreign distro? maybe if i installed docker?)
<leoprikler>raghavgururajan: yep, that looks better. Still worrying about indentation and .sos, but better
<raghavgururajan>leoprikler: In procedure apply: Apply to non-list: "src"
<fnstudio>leoprikler: cool
<leoprikler>yeah apply is really gratuitous here
<leoprikler>((assoc-ref ...) #:install-plan plan) should do it IIUC
<leoprikler>if not, capture args in lambda and pass them after plan
<raghavgururajan>Umm.
<leoprikler>in the top-level lambda that is
<raghavgururajan>After (lambda _ ?
<leoprikler>in lieu of _
<leoprikler>but that's only if you really need apply
<raghavgururajan>I am confused.
<raghavgururajan>You are saying (apply can be removed?
<leoprikler>exactly
<leoprikler>though the bracket must stay
<raghavgururajan>Can you help with the syntax for the thing in lieu of _ ?
<leoprikler>you just rewrite "_" to "args" if you need args anywhere
<raghavgururajan>So the args will be the plan?
<leoprikler>no, the "args" are the arguments passed to gnu-build-system
<leoprikler>As far as I understand you don't need any of them for copy-build-system
<raghavgururajan>I do not get it. :(
<pkill9>fnstudio: what leoprikler said, you just pass it some environment variables I think, and also expose /tmp/.X11-unix
<pkill9>i use wayland though
<pkill9>although xwayland would still require that
<pkill9>actualy i think the contianer isn't working with wayland apps, not sure yet
<leoprikler>raghavgururajan: install is defined in copy-build-system as (install #:key install-plan outputs #:allow-other-keys)
<leoprikler>install-plan comes from (package-arguments pkg) normally, but here you construct it locally.
<fnstudio>pkill9: very interesting, yeah i heard of some clever mechanism to do something like that with x or wayland; is there any blog post or repo out there where i can grab some more info?
<pkill9>i haven't written anything
<pkill9>i'm gonna rewrite the whole thing
<leoprikler>outputs comes from (package-arguments pkg) normally and is passed to all build system phases (at least those based on gnu-build-system) through the the argument keylist
<pkill9>it's spaghetti now
<pkill9>gonna do a flow diagram and do it properly
<raghavgururajan>leoprikler: So I do (lambda* (#:key install-plan outputs #:allow-other-keys) instead of (lambda _ ??
<leoprikler>no
<leoprikler>you don't have an install-plan yet, do you?
<leoprikler>you do (lambda args instead of (lambda _
<leoprikler>so that any arguments applied to gnu-build-system can properly picked up by copy-build-system
<leoprikler>(with apply)
<raghavgururajan>leoprikler, https://paste.debian.net/1188276/
<leoprikler>where's your install plan?
<raghavgururajan>Wait. You want me to declare #:install-plan, outside of (replace 'install??
<leoprikler>no?
<raghavgururajan>Can you show me via paste-bin please? I am now able to understand.
<fnstudio>pkill9: cool, i'll be glad to have a look and learn from it if you end up publishing something
<pkill9>you can have a look at it now if you like
<pkill9>fnstudio: very very WIP mess I'm gona overhaulhttps://files.pkill9.com/containerise
<pkill9> https://files.pkill9.com/containerise
<raghavgururajan>*I am not
<pkill9>it currently uses symlinks, I want to revamp it so it generates a 'profile' consisting of wrappers pointing to the actual binaries, that runs them in the container
<pkill9>currently it needs to show the directory of shortcuts in the container
<pkill9>anyways it's kind of a mess
<pkill9>I didn't write most of it, I cargo culted it from somwehere
<leoprikler> https://paste.debian.net/1188279/
<raghavgururajan>Thanks!
<fnstudio>pkill9: very interesting, i can more or less follow the gist of it, well done for making it work, it's clever
<pkill9>ty
<fnstudio>pkill9: yeah, having a well established / semi-standard way of doing this in guix would be great
<pkill9>eventually I want to make it easy to give applications access to files, and copy those files to a new directory shared with the applications
<pkill9>and then when you're finished you can decide to copy them back over to your normal files path, which is like 'committing' them in git
<raghavgururajan>leoprikler, https://paste.debian.net/1188283/
<leoprikler> https://paste.debian.net/1188285/
<raghavgururajan>leoprikler: [1] It evaluates to creating a plan? [2] The '() of plan is passed to #:install-plan. Correct?
<leoprikler>No and no.
<raghavgururajan>leoprikler: Can you please show me the correct one. I'll learn from that.
<leoprikler>where was the install plan in https://paste.debian.net/1188263/?
<raghavgururajan>under #:install-plan
<raghavgururajan>with-in lambda args
<raghavgururajan>You mentioned that https://paste.debian.net/1188271/ is better.
<cbaines>leoprikler, thanks for sending a v3 series for the fractal patches, I've now got a branch so I can try them out easily :)
<leoprikler>raghavgururajan: indeed it is. did install-plan move between the two?
<leoprikler>cbaines: yeah, thank the rebasing gods, that it's less than 50 patches now
<cbaines>leoprikler, are those patches ready to merge in your opinion?
<leoprikler>I still haven't done the licensing review, but the packages should at least build (without skipping anything major other than the broken aesni)
<raghavgururajan>leoprikler: Between 1188263 and 1188271? No, its with-in (apply (assoc-ref.
<leoprikler>Exactly.
<leoprikler>Why is it no longer there in 1188279?
<raghavgururajan>You mentioned to do it on the top level lambda
<leoprikler>no, i did not
<leoprikler>You want to capture the arguments to gnu-build-system in the top-level lambda (form)
<raghavgururajan>leoprikler: I appreciate that you are helping me to learn. But at this point its consuming too much time. If you could show me your version of 1188271 to fix "In procedure apply: Apply to non-list: "src", it would be great. :)
<leoprikler> https://paste.debian.net/1188287/
<leoprikler>cbaines: somewhat importantly I haven't actually checked fractal beyond the point of launching. Not really a Matrix user myself.
<cbaines>leoprikler, I've managed to launch it at least
<leoprikler>"beyond launching", so I did launch it :)
<cbaines>there's a schema wrapping issue if you try and launch it from the store (and don't have it installed)
<cbaines>it did seem to pull in some messages though, I haven't tried properly using it yet
<leoprikler>I learned that using ad-hoc environments with glib do the trick
<leoprikler>there's an XDG directory that's not scanned otherwise
<cbaines>right, it's possible to do a wrap-program thing with the right search path so that the relevant things are always available
<cbaines>there's some prior art for other packages
<leoprikler>indeed, XDG_DATA_DIRS get wrapped in some packages, but most don't do that
<raghavgururajan>I don't know.
<morgansmith>hey does anyone know how to start a dbus-daemon for a packages tests? You can see the package dee does this but if you actually build it then you'll see dbus-daemon fails to start saying "No configuration file specified."
<pkill9>has anyone worked on packaging this?
<pkill9> https://marble.kde.org/
<morgansmith>is there any feasible way to automate manpage build regressions? In my limited time working with guix, I've come across two packages that had explicit man page building configs in the package that where no longer building man pages. (The two are picom and polkit)
<lfam>raghavgururajan: Thank you for the patches for nimf / telegram!
<raghavgururajan>morgansmith: Try replacing 'test with (invoke "dbus-launch" "prog" "target").
<raghavgururajan>lfam: Pleasure!
<civodul>morgansmith: hi! i don't think there's a simple way to track such regressions
<morgansmith>raghavgururajan: That definitely got me a step farther! Thanks!
<morgansmith>civodul: I wonder if adding a "we didn't see any documentation" warning to guix lint would be helpful...
<civodul>morgansmith: 'guix lint' is designed to not build anything currently, so it's not the right place for that
<lfam>I'm curious, does anyone have an estimate of how long it takes to bootstrap Rust on the build farm?
<lfam>For the wip-next-release branch, the Rust bootstrap is the primary bottleneck, since it cannot be parallelized
<morgansmith>civodul: oh ya. forgot it was a static linter :P
<lfam>(Updates to python-2 affect the rust bootstrap)
<raghavgururajan>> That definitely got me a step farther! Thanks!
<raghavgururajan>morgansmith: Glad!
<raghavgururajan>> lfam‎: I'm curious, does anyone have an estimate of how long it takes to bootstrap Rust on the build farm?
<raghavgururajan>On bayfront, about 3 days, with --cores=28 --max-jobs=1 --keep-going --no-offload.
<lfam>I see
<raghavgururajan>With offload, it bay be faster.
<lfam>Do you know if it is parallelized per-core? Like, would it go about twice as fast with 2x28 cores?
<lfam>On berlin there are machines with 96 or 64 cores
<raghavgururajan>That I am not sure.
<lfam>Alright
<lfam>I think it must be...
*pkill9 is compiling marble
<pkill9>on the nokia n900 I remember it was a pretty nice piece of software
<Noisytoot>Could someone merge my latest improvement™ to https://issues.guix.gnu.org/46449?
<Noisytoot>It should now apply to master
<morgansmith>if a program relies on cpp includes of systemd/sd-bus.h and systemd/sd-journal.h, would it need to be rewritten to work on guix? I know some systemd things have compatibility libraries, but I don't know which things
<leoprikler>afaik the only noteworthy systemd replacement is elogind, which tackles neither
<leoprikler>you might find a way to patch some other dbus in, but journal seems pretty systemd-y
*pkill9 compiled marble