IRC channel logs

2019-11-25.log

back to list of logs

<kmicu>Breaking newz in 20 years: oriansj and janneke on nsa payroll backdoored libre computing 😺
<oriansj>safinaskar: if you are curious about the details of the guix bootstrap and our future goals feel free to join us on #bootstrappable for more in depth discussion
<oriansj>kmicu: State of Michigan thank you very much
<nckx>kmicu: At least I know what one of looks like and can kick them in the shin at the next FOSDEM. And that, my friends, is accountability.
*nckx would never do that.
<kmicu>oriansj: is cool. Awalys repeats that the goal is to not trust him.
<kmicu>(Would be a terrilbe blockchain evangelist.)
<nckx>I've used the blockchain angle a few times when explaining Guix.
<oriansj>kmicu: just straight bad at sales in general
<nckx>You need to take a loooong shower afterwards, but it works.
<kmicu>Is Guix a distributed ledger?
<atw>hashes-for-identity equals blockchain? why not!
<smithras>nckx: the sacrifices you make for guix
*kmicu wants to invest all OneCoints in Guix.
<nckx>kmicu: As long as Savannah's up.
<nckx>Last I heard it was distributed over 2 drives. /s
<kmicu>Savannah is a distributed VCS created by Linus Torvalds.
<nckx>kmicu: *CVS
<nckx>jeez.
<smithras>ahh the 2-1 backup strategy :) two drives one computer
<oriansj>don't you mean the old, no backup strategy
<oriansj>that way there will be no traces of how badly things were
<nckx>Oh no no no did someone just compare RAID to back-ups with oriansj in the room what have you done.
*nckx tries to guix pull again.
<nckx>‘Our recovery process is taking longer than expected. We are expecting extended downtime. Sorry for the inconvenience.’ Aww.
***ChanServ sets mode: +o nckx
<kmicu>I’m curious… why you all guix pull all the time?
***nckx changes topic to 'GNU Guix | ⚠️ ‘guix pull’ and more is down: https://hostux.social/@fsfstatus | 1.0.1 is out! get it at https://guix.gnu.org | videos: https://guix.gnu.org/blog/tags/talks/ | bugs & patches: https://issues.guix.gnu.org | paste: https://paste.debian.net | Guix in high-performance computing: https://hpc.guix.info | This channel is logged: http://logs.guix.gnu.org'
***ChanServ sets mode: -o nckx
<safinaskar>nckx: "I don't see how shipping pregenerated files" - autoconf uses itself. :) thus it is theoretically possible that autoconf itself is attacked using trusting trust. so if you regen autoconf and compare output you will see no difference because autoconf is infected, and both versions you compare are infected. of course, all this is purely
<safinaskar>theoretical, but, again, i want scientific method. i want everything to be verifiable
<kmicu>Could you commit new patches to your local guix repo and pull from them instead?
<oriansj>safinaskar: it isn't going to be an issue anyway
<nckx>safinaskar: But this is the same autoconf used during the Guix bootstrap/build process? No?
<nckx>So you're automating your own undoing.
<oriansj>safinaskar: have you seen https://github.com/oriansj/mescc-tools-seed yet?
*kmicu would love to see how an evil patch to autoconf looks like; a patch which infects generic source code and is easily accepted.
<nckx>kmicu: That's what I do, I have several custom channels + guix upstream. I reconfigure from ‘guix’, not ‘./pre-inst-env guix’, unless I'm testing a specific patch. Feels… safer. In this case, I was really just pulling to see whether it worked for other users.
<safinaskar>janneke: "have you seen https://guix.gnu.org/blog/2019/guix-reduces-bootstrap-seed-by-50/" - 1000+ is closure of full build of gcc. it is not the same thing as seed
<alextee[m]>is gparted broken for everyone?
<oriansj>safinaskar: I am personally mentioned in it
<alextee[m]>it auto-exits when you run it
<kmicu>Thank you nckx.
<alextee[m]>fails to load a bunch of theme icons
<smithras>alextee[m]: yeah, I see the same behavior on my computer
<oriansj>safinaskar: guix is going to be bootstrapped from a 257 byte binary, that I personally wrote and which is trivial to reproduce or replace
<safinaskar>nckx: "Optional autoreconf’ is a completely different beast" - we can compare binaries got from this autoreconf with standard ones and see that they are equal
<nckx>alextee[m]: It started fine here (sudo `which gparted`) but ‘Search[es] for /dev/sda partitions’ for… well, a very long time now.
<safinaskar>nckx: "not an optional side route" - why not have several routes, which get us to same binaries, which compare equal?
<alextee[m]>hmm interesting
<nckx>alextee[m]: This is what it printed to the console: http://paste.debian.net/plain/1117776 . It's still searching, by the way, I wonder if it's choking on something in use…
*nckx never really uses gparted because of drama like this.
<smithras>Is it possible to specify a local file url for a guix channel?
<nckx>smithras: Trivially: (url "file:///home/foo/you")
<alextee[m]>nckx: mine is a bit different: https://paste.debian.net/1117777/
<safinaskar>kmicu: "oriansj and janneke on nsa payroll backdoored libre computing" - yeah! for this kind of thing it is good idea to have multiply roads to same binaries (i trust oriansj and janneke, i speak about verifyability here, again)
<nckx>Only caveat is that it must be a git repo and Guix wont see uncommitted changes.
<nckx>smithras: ☝
<kmicu>safinaskar: what do you want to verify exactly?
<alextee[m]>it looks like it's missing an input or something
<alextee[m]>i'll report it as a bug i guess
<smithras>nckx: thanks for the uncommitted changes tip, that would have surprised me
<nckx>safinaskar: I share your desire for verifiability but something about the ‘diverging-paths’ approach does not sit well with me at all. I'm too tired to delve deeper though.
*kmicu thinks to make Guix secure we should deploy build farm on Parasoya Disks https://framapic.org/gallery#LwoSYG0Tx5gU/M14LDjYhUcvL.jpg
<nckx>alextee[m]: Well, you won't, because debbugs is down, and I suspect ‘guix install adwaita-icon-theme’ will solve your problem.
<nckx>If so, we're in the same discussion as fonts: some programmes insist on a(ny) font, and adding it as a propagated input ‘fixes’ that, but it's also crossing a vague user-choice line that some (including me) are not happy about.
<nckx>kmicu: ‘Soycure Systems’? And this is not a racist parody, you say?
<smithras>is that why some GDK apps have still need evolution-data-server?
<nckx>What is that man doing to that poor disk.
<nckx>Is he eating the disk.
<smithras>yes he it
<nckx>Why is he eating the disk.
<smithras>is
<nckx>Please make him stop.
<oriansj>just remember all bootstrapping discussions and debates are to be moved to #bootstrappable, so that people who need help with guix can get it here
<kmicu>To erase the data. Securly.
<nckx>This is not good for the disk, or for the man.
<nckx>Yes, back to that sweet on-topic #guix chat.
<kmicu>That disk is organic to allow proper erasing.
<kmicu>If some program dosen’t work properly w/o a font then that font is a dependency.
<nckx>I'm still oscillating wildly between ‘obvious joke’ and ‘some low-density magnetic substance is probably edible’.
<smithras>^could we at least add a warning or something in the descriptions?
<safinaskar>nckx: "But this is the same autoconf used during the Guix bootstrap/build process?" - i imagine scenario where all autoconf copies over the world are infected
<nckx>kmicu: That's the other side's argument, yes.
<soda__hobart>hi everybody, where do I find the public key for Guix? The hyperlink in the installer shell script does not work.
<sneek>soda__hobart, you have 1 message.
<sneek>soda__hobart, amz3 says: I reported the bug against guile-redis regarding pub/sub at https://github.com/aconchillo/guile-redis/issues/3
<nckx>kmicu: The real bug™ is that propagated-inputs is the only hammer we have to solve all these niggles, and propagated-inputs suck barf.
<ng0>nckx: fwiw, http://hoaxes.org/af_database/permalink/soybean_computer_disks
<safinaskar>oriansj: "have you seen https://github.com/oriansj/mescc-tools-seed yet?" - possibly
<nckx>Aw.
<kmicu>nckx: I belong to purists camp. I would use real dependency for real isolation.
<kmicu>I understand that’s too much work so preinstalling fonts to desktop-conf is an acceptable workaround.
<kmicu>(Too much work for folks using binsubs.)
<alextee[m]>nckx: didn't work either with adwaitta. i'll send a report when the s ervers are back :-)
<kmicu>Thank you alextee[m].
<nckx>kmicu: That sounds preferable but I'm not actually familiar enough with Gstuff to know if that's doable. I'm familiar enough with Gstuff to know that it *loves* to run everything in a big, shared, filthy hot-tub of global state.
<nckx>alextee[m]: Oh, that's interesting.
<nckx>Yes, please do.
<smithras>I think it's a bug when you can install a package and it doesn't work because some dependencies were intentionally omitted
<safinaskar>kmicu: "what do you want to verify exactly?" - well, my ultimate goal is to verify absolutely everything. i. e. to verify that both hardware and software are correct and free of any kind of backdoors including trusting trust attack
<smithras>If we are worried about polluting a user's profile, 'guix install' could display a list of propagated inputs with a proceed[Y/n]? prompt
<kmicu>Not intentionally but some deps are implicit cuz desktop stuff is a ‘complicated mess’.
<nckx>smithras: Let's not make Guix interactive, that breaks all kinds of things.
<kmicu>aka full of gloabal mutable vars
<oriansj>safinaskar: then used stage0; it even involves custom hardware
<nckx>kmicu: Sure, but that's mostly by design, not necessity.
*nckx AFK a while.
*janneke -> zZzzz
<nckx>o/
<smithras>kmicu: okay that makes more sense
<smithras>sorry if I made it sound like I was accusing people here of omitting dependencies :)
<kmicu>smithras: for examle if my desktop depends on Computer Modern and Zenburn Icon set but your desktop on Fira mono and Adwaita then we cannot share closures cuz they are different.
<kmicu>So desktop has plenty of workarounds to stay closer to traditional distros.
<kmicu>safinaskar: I understand but you can catch an evil code by openning a random pdf or executing js on some website. So for me your goal is like spending millions on super armored door but leaving the window open.
<kmicu>(But I was always an OpSec folk so I’m biased.)
<slyfox>guix pull seend to hang on 'https://git.savannah.gnu.org/git/guix.git' and timeout for me
<slyfox>s/seend/seems/
<bandali>slyfox, see topic. savannah git is down
<alextee[m]>slyfox: you can use a mirror like github and it will work
<slyfox>ah, thank you!
<bandali>cheers
<alextee[m]>slyfox: this is my current ~/.config/guix/channels.scm https://paste.debian.net/1117789/
<alextee[m]>worked for guix pull
<lispmacs>I'm having trouble doing a guix pull, but otherwise my Internet connection seems to be fine
<slyfox>lispmacs: /topic says infrastructure has problems
<lispmacs>slyfox: ah, sorry, didn't see that right away
*slyfox asked the same thing 5 minutes ago :)
<lispmacs>hey, another question: do the point releases (0.11, 1.0, etc) get some special system testing, or how does that work?
<smithras>^also is there a period where master is frozen before a new release?
<lispmacs>I did a guix pull && guix system reconfigure, and I wasn't able to log in to Gnome afterwards, so I had to roll back
<lispmacs>which, thankfully, is very easy to do in Guix
<vagrantc>lispmacs: i know they make sure substitutes for those versions are kept around longer or something
<lispmacs>everything built fine, just after reboot couldn't log in through GDM. But I don't seem to have any trouble with reconfigures if I keep guix pointed at the 1.0.1 commit
<kmicu>At some time there were some issues with caching in Gnome and folks had similar issues.
***ChanServ sets mode: +o nckx
***nckx changes topic to 'GNU Guix | ⚠️ ‘guix pull’ and more is down: https://hostux.social/@fsfstatus | 1.0.1 is out! get it at https://guix.gnu.org | videos: https://guix.gnu.org/blog/tags/talks/ | bugs & patches: https://issues.guix.gnu.org | paste: https://paste.debian.net | Guix in high-performance computing: https://hpc.guix.info | This channel is logged: http://logs.guix.gnu.org'
***ChanServ sets mode: -o nckx
<alextee[m]>ok something is wrong with icecat... 2nd time today that i clicked on a link in an external app and my pc froze
<nckx>lispmacs: There is no formal pre-release testing process, but the bar is a bit higher than for a random commit: the test suite probably passes completely, quite a few volunteers have ‘tested’ the installer by at least giving it a try, the worst bugs are fixed before releasing, that sort of thing. That said, 1.0.0 contained a few embarrasingly bad bugs and should not be used. 1.0.1 fixed them.
<alextee[m]>ah the classic finding critical bugs after release :-)
<nckx>alextee[m]: %base-packages completely missing from the standard installion. That was fun.
<smithras>alextee[m]: IIRC guix is using a preview of the upcoming icecat 68, so there's still some serious bugs
<smithras>When I asked about it in #icecat, they told me that "it wasn't suitable for end users yet
<kmicu>We can use older IceCat releases (though better in a disposable vm).
<smithras>yeah IIRC the old stable has some bad CVEs that won't be fixed
<kmicu>(Or not if you only open trusted web pages and have js turned off by default ;)
<nckx>smithras: OTOH, Guix's IceCat package is done in very close collaboration with IceCat upstream. Or even *by* (part of) upstream. A WIP browser is considered better than an insecure EOL one.
<alextee[m]>i really wish we had abrowser or iceweasel too
<smithras>nckx: true! I'm definitely sticking with 68, even though it's a little inconvienent
<nckx>(Typed in response to your ‘not suitable’ quote while I tried to remember whether mhw was an IceCat maintainer.)
<alextee[m]>im used to having a main browser (icecat) a less strict browser (abrowser) and tor for anonymous stuff
<alextee[m]>epiphany crashes a lot and i also think it's insecure
<nckx>Oh definitely.
<nckx>It's only suitable as a back-up browser.
<kmicu>I’m not sure why Abrowser exists. It’s Firefox‑based, it’s FSDG, and it’s Ruben too.
<alextee[m]>it was my favorite browser
<alextee[m]> https://www.reddit.com/r/trisquel/comments/2jxaxs/what_is_the_difference_between_abrowser_and_icecat/
<oriansj>I have a minor bug report: guix package -d file-roller results in: guix package: error: invalid syntax: file-roller
<kmicu>alextee[m]: maybe you could contribute a patch to Guix? It should be basically the same thing as code for IceCat.;)
<kmicu>(Cuz it looks like Ruben’s priority is abrowser https://devel.trisquel.info/trisquel/package-helpers/commits/flidas )
<alextee[m]>kmicu: i'll give it a try!
<nckx>alextee[m]: IceWeasel is packaged as IceCat 😛
<nckx>Hasn't been a thing for years.
<nckx>But wow that brand recognition. I'm jealous.
<alextee[m]>icecat's package definition is scary
<alextee[m]>400 lines lol
<atw> https://atw.name/ ← got certbot working \o/ the trick was that I had to create /var/www/.well-known manually.
<atw>not sure if the manual made that clear to me :/ worth adding?
<alextee[m]>is it acceptable for a package to fetch a precompiled deb package and install it?
<alextee[m]>im guessing not, but i can do it locally for abrowser
<alextee[m]>this is what the AUR package does https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=abrowser-bin
<nckx>alextee[m]: Correct.
***jonsger1 is now known as jonsger
<ScaredySquirrel>lol my elogind dbus service is broken
<ScaredySquirrel>I can't login as travism for I get System error
<ScaredySquirrel>ok guys, why does my xorg not have any input drivers?
<ScaredySquirrel>ah
<Diagon>For systems where I don't have root access, "If your administrators are enlightened they may create /gnu/store for you and allow you to copy files across built on a system where you have root access." Would that mean the build would have to be done on a system that's identical to the one where it will be run?
<Diagon>(Quote is from https://github.com/pjotrp/guix-notes/blob/master/GUIX-NO-ROOT.org)
<leoprikler>I don't think Guix uses any architecture-specific compilation flags beyond distinguishing e.g. x86 from arm.
<leoprikler>Theoretically you should be able to copy from one x86 machine to another.
<Diagon>Fantastic!
<Diagon>Do you guys know hosts that are "enlightened"?
<Diagon>(So I take it that means guix doesn't use any of the local machine's binaries; but the ones that it installs itself.)
<efraim>It means that Guix doesn't have an unpriviledged install path, if you want to install it to a shared machine you need whoever is administering the machine to do the initial install for you and then you can manage your own profiles from there.
<zig>guix must be installed like a system dependency, then you can manage your package as a user without root permissions.
<Diagon>Ok, so Opalstack is a host that is just getting up and running (they are ex-employees of webfaction, which got bought out by GoDaddy). I want to make a case to them.
<Diagon>(1) I can tell them it's really easy to create /gnu/store in their VPS's (managed, but not shared) and allow us to write there.
<zig>it is not the user that write in /gnu/store but the guix build daemon (workers)
<Diagon>zig, right but I understand we can build on another machine and then copy there, so the daemon doesn't need to exist where the package is to be run, correct? (That's the quote above.)
<roptat>hi guix!
<Diagon>So (2) If they install guix the manager on their shared hosts, that would allow each person on the host to have their own "store", is that right?
<Diagon>I'm just looking how to convince them that this is worth their while to look into.
<roptat>Diagon, it does because it still has to "install" the packages in the store, which is owned by root
<roptat>the store must be /gnu/store, otherwise you won't get any substitute
<Diagon>That quote says, "they may create /gnu/store for you and allow you to copy files across built on a system where you have root access."
<roptat>mh... I never tried that...
<Diagon>So as long as a non-privileged user can copy over to that directory, it seems we dont' need the daemon running. That coudl work on a non-shared VPS.
<zig>guix without the daemon does not really work, i guess.
<zig>maybe i am wrong.
<Diagon>Yes, ok. So I just want to convince them. I can tell them that at *least* creating that directory and making it writable is a trivial thing for them to do and does not introduce any security issues.
<roptat>right
<Diagon>zig - two paragraphs at the beginning, here: https://github.com/pjotrp/guix-notes/blob/master/GUIX-NO-ROOT.org
<zig>maybe you can convince them to provide guix images for the shared hosting
<roptat>I guess you can run "guix pack" on that other machine and uncompress on the machine where you have no priviledge
<zig>Diagon: then that is prolly true.
<Diagon>Ya,that seems to be the idea. It says that it's already used on some HPC systems.
<zig>like roptat said, you can use guix pack.
<Diagon>So, how is /gnu/store structured? Is there one subdirectory for each person's store? If so, on a shared host that person's subdirectory could be made writable? (On a VPS that's not shared it wouldn't be an issue.)
<roptat>no, there's only /gnu/store, with one directory per package
<roptat>it's supposed to be shared between users
<roptat>because it's supposed to have the same content for the same hash
<roptat>so one store per user wouldn't make sense
<Diagon>I get it. So what happens if they installed the guix daemon? How can I make the case to them that this is a sensible thing to do and doesn't introduce any security issues, even on a shared system?
<roptat>the daemon only writes (and removes) to /gnu/store. It doesn't need write access to anywhere else
<roptat>and the admins control where the binary packages can come from, not the users
<Diagon>Alright, but a shared system will have a number of users. They would not want one user's packages interfering with those of another.
<roptat>it cannot interfere
<Diagon>Alright ... That sounds good. And you're saying that the admins control... The package repositories that the daemon can access, was that your point roptat?
<roptat>either that other user uses the same package as you (with the same hash), in which case it's the same, bit-to-bit, package, or it uses another variant of that package, in which case it has a different hash, so it's in another directory
<roptat>not the package repository, the source for substitutes
<roptat>as a user, you can decide to build anything you want, but the binary substitutes can only come from trusted sources that your admins decided
<roptat>if you want to build something that's not on a trusted build farm, it's built locally
<Diagon>I get it. So the admins could demand that all packages are built from source, correct?
<roptat>and with reproducibility, if another user wants to build the same thing, it will get the same result (so it doesn't actually build anything, since it's already there)
<roptat>right
<roptat>that's called "binary transparency" you cannot know if a binary came from a build farm or were built locally, because they are bit-to-bit identical
<roptat>there's no difference between a system that used substitutes and a system built locally (as long as the build farm is not corrupted)
<roptat>building locally can be expansive though :)
<Diagon>(That's interesting. That's not like Gentoo then, where building locally has the advantage of getting a speedup due to it being built for the specific machine you are on.)
<roptat>right, but on gentoo you get the speedup at the expanse of reproducibility
<roptat>you *can* distinguish two gentoo systems even if they're built with the same instructions
<Diagon>Ok, yes I see.
<roptat>however, reproducibility is more important to science: with guix, you cannot distinguish between a binary built in Germany today and the same binary built in Australia 10 years ago
<roptat>because they are bit-to-bit identical
<Diagon>I see the point. Alright, I'm going to make a go of it... If I convince them, would this be the first host to run guix?
<roptat>I think it's already running at Inria (France) and at the MDC (Germany)
<roptat>maybe elsewhere too
<Diagon>(Right now, any time you use a host, you're basically stuck with linuxbrew or junest. This would be a great option.)
<roptat>I think there are a few papers mentionning guix
<Diagon>Irnia and MDC are hosts where I can rent a VPS?
<roptat>no, they have their own hardware I think
<Diagon>Inria is a research institute, no?
<Diagon>Don't know MDC at all.
<roptat>it's also a research institute
<roptat>I thought that was your question?
<Diagon>I see. No, I was meaning whether there are hosts (eg. cloud hosts) that offer guix.
<roptat>mh... I don't know, but with a VPS, don't you have root access?
<Diagon>This would be a fantastic solution for them. I rent access to a shell or to a VPS, and then I can install my packages using guix, rather than the often broken linuxbrew or junest.
<Diagon>There are managed VPS's. You get your own machine, but not root.
<roptat>ok, that's weird ^
<Diagon>There are also managed *shared* VPS's.
<roptat>I think the guix deploy article on the blog mentions one VPS provider
<Diagon>You have a link?
<roptat> https://guix.gnu.org/blog/2019/managing-servers-with-gnu-guix-a-tutorial/
<roptat>it talks about digital ocean
<Diagon>Oh, now that would be excellent propaganda. If Digital Ocean is doing it, then perhaps that might convince them! :)
<Diagon>(a managed VPS has advantages over a managed shared machine. Namely, you don't have to be anxious about over-running your RAM limit and having your processes killed off.)
<Diagon>(So it's one step improved from a shared machine, but not quite a full blow VPS where I'm given root.)
<rekado_>oof, savannah is still down :(
<efraim>yeah :(
<wingo>irritating
<efraim>my patch queue backlog is growing and my need to apply updates is overwhelming
<rekado_>I guess we should also send out a notice via info-guix@gnu.org
<Diagon>roptat/zig/efraim - thanks all for your help. If I'm successful, I'll come back here and report. ;)
<efraim>In other news, after ~6 hours of compiling I built an installer image for my pine64 (which I still have to test out)
<efraim>then I need to find a KVM (?) usb switch so I can switch my keyboard/mouse between the two machines
<roptat>yes, I think KVM is the right term here, if we're talking about hardware :)
<efraim>yeah
<jonsger>efraim: pinebook?
<efraim>jonsger: regular pine64
<Franciman>hi efraim I wanted to ask a thing about the rust ecosystem
<Franciman>why are the packages in crates-io.scm defined without their dependencies?
<efraim>Franciman: ok. I'm about to head out but I can try to answer anything or reply when I get back
<Franciman>sure
<Franciman>I'm referring to rust-serde-json-1.0 for example
<efraim>The packages which made it into Guix before I purged the dependencies were all individually built and tested
<efraim>but we got to a point where to package serde or other packages we'd have to go and add a dozen or more at a time to deal with circular dependencies or go and find old versions that didn't have those requirements
<efraim>and using the crate importer we'd get dependencies on other crates we hadn't packaged yet, which meant they couldn't be added until their dependencies were also packaged
<Franciman>oh I understand. So should I need those deps, I need to repackage them, right?
<efraim>We're still trying to figure out a way to declare dependencies without needing to pull in a very long list of transitive dependencies that may never be packaged but there's not going to be a great method for a while unfortunately
<efraim>pretty much. What I did for rust-cbindgen was copy the info from the Cargo.lock file and replicate it across the #:cargo-inputs and #:cargo-development-inputs so it would find everything
<efraim>nowhere near as nice as saying "I need these 8 crates and their dependants" but it made it doable
<efraim>I have a file here with 500+ crates that I haven't upstreamed because we haven't packaged all the crates they depend on
<Franciman>Yep, I have the same issue
<efraim>I think the main thing is figuring out how many generations we want to go back when it comes to pulling in dependants. Before it was all the way back, but that's obviously too far. One or two generations may not be far enough, but it would allow us to get more popular crates in and start building with them
<Franciman>Have you had a look at how nix deals with this?
<Franciman>It seems to me that there is like an authomatic mechanism, and you don't need to specify the crates dependencies
<efraim>I don't remember how they do it, but it seemed like they automatically generated package definitions for the crates they needed
<efraim>if that is how they did it, it doesn't take into account declaring the package and its hash so we can make sure nothing changed
<Franciman>also, we already have it
<Franciman>guix import crate
<Franciman>but it fails lol
<Franciman>it tries to pull too many crates and crates.io stops answering
<ng0>could you delay request for a random time between 2 and 10 seconds?
*efraim has to run off now
<Franciman>bye!
<Franciman>thanks
<Franciman>ng0, guess so
<ng0>crate2nix? https://eipi.xyz/blog/packaging-a-rust-project-for-nix/
<ng0>but i think you were talking about buildRustPackage
***avocado is now known as Guest92188
<ng0>"Such a derivation for this project, built with crate2nix is available on GitHub. It should be noted that the length of these generated files is quite large, thousands of lines." wew
<Franciman>yes I did
<ng0>then the code is here: https://github.com/NixOS/nixpkgs/tree/master/pkgs/build-support/rust
<Franciman>thanks ng0
<efraim>server is back up
<Franciman>yay
<Franciman>I think one difficulty with rust is determining packages versions so that you minimize the number of crates to download
<efraim>apparently it's in the metadata available from 'guix import crate', it just needs to be adapted
***ChanServ sets mode: +o nckx
***nckx changes topic to 'GNU Guix | 1.0.1 is out! get it at https://guix.gnu.org | videos: https://guix.gnu.org/blog/tags/talks/ | bugs & patches: https://issues.guix.gnu.org | paste: https://paste.debian.net | Guix in high-performance computing: https://hpc.guix.info | This channel is logged: http://logs.guix.gnu.org'
***ChanServ sets mode: -o nckx
<civodul>Hello Guix!
<civodul>no news from Savannah? :-/
<Franciman>it's up now!
<rekado_>it seems to be back!
<civodul>oh, it is!
<civodul>neat!
<civodul>funny thing: i gave a training session on Guix at work just this morning :-)
<rekado_>oof
<civodul>so i told people to "guix pull --url=https://github.com/..."
<rekado_>hah
<civodul>not that bad, but not great either ;-)
<rekado_>I wonder if we can do better.
*chrislck wish I could understand guix
<rekado_>like a domain that will always point to an available repository
<zimoun>civodul: hi! ahah! training session to which kind of public?
<civodul>like git.guix.gnu.org or something
<rekado_>nckx already pointed out that HTTPS termination might be a problem then.
<civodul>zimoun: just with colleagues of mine, we were 8 people or so
<zimoun>civodul: nice!
<civodul>rekado_: also, that leads to a more serious issue, which is that as an end-user you need to be able to ensure the repo is really giving you the latest commit
<zimoun>because you use Guix on your cluster, or general Guix usage?
<civodul>(as described in work on TUF)
<roptat>TUF?
<zimoun>TUF?
<civodul>zimoun: well, it's mostly for HPC usage, and mostly on our cluster, but not just
<roptat>^^
<civodul>"The Update Framework"
<civodul> https://theupdateframework.github.io/
<civodul>hey roptat, now's a good time to publish your blog post if you feel like it! :-)
<zimoun>civodul: in the spirit of your "midi de la bidouille"?
<zimoun>because I found interesting use case and tricks/tips :-)
<roptat>civodul, if you agree with the latest changes, I'll do that this evening :)
<roptat>has there been any work on securing updates in guix?
<civodul>zimoun: ah yes :-), sort of like that, but for 2.5h
<civodul>roptat: regarding the post, cool!
<civodul>(i don't think you need *my* approval specifically, BTW)
<civodul>roptat: re security updates, the issue is described at https://issues.guix.gnu.org/issue/22883
<zimoun>civodul: if you publish somewhere your "notes", let me know :-)
<civodul>alright!
<civodul>actually, to me, "guix pull --news" was a way to get started with Git infrastructure needed to authenticate checkouts
***mabgnu is now known as bandali
*janneke pushes mes-0.21
<civodul>janneke: yay, thanks!
<efraim>ok, I figured out how to make the crate importer strip off the optional dependencies. now to work on the version number
<civodul>efraim: neat!
<civodul>hopefully their HTTP API gives us everything we need
<civodul>it provides a lot of info
<efraim>the /dependency API gives version numbers, I should be able to massage that
<efraim>guix environment --ad-hoc curl jq -- curl https://crates.io/api/v1/crates/serde/1.0.103/dependencies | jq
<roptat>ah, reminds me of my work on the node importer... I should resume it
<efraim>i removed the dev-dep by filtering for optional, next is to make cargo-input say ,rust-serde-json-1.0
<efraim>s/json/derive
<civodul>efraim: did you see <crate-dependency> in (guix import crate)?
<civodul>i think it corresponds to this
<efraim>yeah, that's where I am
<civodul>ah cool
<efraim>crate-dependency-requirement is really more of a version
<civodul>it has just a few fields but you can add more
<civodul>ok
<efraim>then later is modifying the updater to update the point release and not just to the largest release
<efraim>0.1.2 -> 0.1.3 not 0.1.2 -> 0.2.0
<civodul>yes
<roptat>mh... good point
<roptat>civodul, do you have your image with guix and docker together?
<roptat>I mean, where we see both logos, says "LOL" :)
<roptat>I'd like to use it in the presentation I'll give at JRES, if you agree
<rekado_>roptat: it’s on one of my slides in the maintenance repo
<roptat>oh
<roptat>thanks :)
<roptat>which one though? :p
<rekado_>I grep’d for “LOL” in the “talks” directory and found it at “talks/cern-2018/use-developer-4.svg” among others
<rekado_>or “talks/cern-2018/docker-5.svg”
<wingo>:)
***ng0_ is now known as ng0
<puoxond>Hey Guix!
<lnadav204>hello?
<zig>o/
<puoxond>The recent changes to the way that Emacs packages are handled broke my setup.
<roptat>puoxond, I'm not an emacs user, but maybe if you explain what happened others can help?
<puoxond>I use EXWM (the emacs window manager) so I put emacs in my system profile. Additionaly I have emacs packages (emacs-pdf-tools, emacs-org, etc.) in my user profile. Since the changes emacs doesn't find those packages any more.
<puoxond>Apparently emacs now uses EMACSLOADPATH to find the packages. But the variable isn't set if a profile contains emacs packages but not emacs itself.
<puoxond>I've figured out that installing emacs in my user profile fixes it. I just would like to know if this behaviour is intentional or if I should report it as a bug.
<roptat>it's expected, but I wouldn't say it's nice :/
<roptat>apparently it's hard to fix
<bandali>there was some recent discussion about emacs on guix-devel iirc
<bandali>don't remember the details though
<roptat>these environment variables are generated by guix when it builds a profile, but it will only generate environment variables of installed packages in that profile; and it has no knowledge of other profiles when building a profile, by design
<roptat>so it can't know you need EMACSLOADPATH unless you install emacs in the profiles you need that variable in
<puoxond>So it's like the issue with 'guix environment', where one has to add '--ad-hoc man-db' in order to be able to see the manpages?
<roptat>I think it's related, yes
<roptat>I tried to argue that it was a bad behavior in the past and even sent a (bad) patch for it, but I don't remember what happened to it
<roptat>I think people were not convinced... maybe that emacs issue is going to change their mind :p
<zimoun>puoxond: I do not know what your problem is exactly, but issues about EMACSLOADPATH is currently discussed here: http://issues.guix.gnu.org/issue/38309
<zimoun>roptat: why do you think it is a "bad behavior"? It is what I expect: stay minimal. For example, it does not make so much sense (to me) to honnor EMACSLOADPATH when installing only emacs packages without Emacs itself. (Or whatever else: R packages without R itself, manpages without man-db itself, etc..) I am still not convinced. :-p
<puoxond>zimoun: I believe that is a different issue (I don't use GNOME). The GNOME issue seems to be caused by the size of EMACSLOADPATH.
<zimoun>puoxond: I use another window manager and my setup has been broken too. Another bug has been opened here http://issues.guix.gnu.org/issue/38273 but it is maybe related to the introduction of EMACSLOADPATH.
<kmicu>Gnus are back on savannah. Happy chaps.
<bandali>psa: there may be some more intermittent outages with savannah, but hopefully only short ones, and ideally none
<kmicu>Thank you bandali!
<bandali>cheers kmicu
<bandali>i'll update y'all here as i learn more
<roptat>zimoun: I think guix doesn't have enough info to handle minimalism correctly in this case
<roptat>I would rather argue for maximality. Let's define every possible environment variable that might be useful ^^
<roptat>I already have an info reader, man-db and guile in my system profile, so why do I have to add them in my own user profile to be able to use them?
***jje_ is now known as Guest48335
<zimoun>roptat: because you want to keep clean the "isolation". On the contrary, if an info reader, man-db and guile in your system profile but you don't want them in your own user profile, why do you have to remove them? To me, it is easy to think: I want it, I add it; then I want this, let me check what I concretly have, then add and/or remove it. Maybe I miss a point.
<zimoun>s/then/than
<ng0> https://git.savannah.gnu.org/cgit/guix.git/commit/?id=377606238f0260a849a1f529d94e1546276a5db6 why? didn't we have a discussion about that and recommending the nc shipped with another software 2 years or so back?
<ng0>I'm not against it, it's just weird.
<elais[m]>Is there enough kde in the repo that I can create a desktop environment using a different window manager? For instance I'm using lxqt with stumpwm but I would like to
<elais[m]>Use kde just to see if I can
<elais[m]>Like with lxqt I just install the 'lxqt' package. What package would I install for kde?
<roptat>zimoun: having that level of isolation makes people want to add propagated inputs or add search-path specifications to packages that don't use them
<roptat>A concrete example is qtbase. It defines a qt plugin path, but I don't want a library in my profile. I expect my qt application to be able to find its plugins at runtime
<roptat>Same for any variable used by a library: it doesn't concribute anything except an environment variable when I add it to my profile. How is that minimal? :p
<anadon>I'm dumb and locked myself out of admin when following the "Build Environment Setup" page. Replaced my groups instead of adding to them. Ick.
***namtsui_ is now known as namtsui
***Guest48335 is now known as jje
<lispmacs>are issues with guix pull all supposed to be worked out now?
<lispmacs>I'm getting an error, but not the one I had over the weekend
<bandali>git.savannah is back up and should be working
<lispmacs>when I try to run guix pull, it updates a bunch of substitutes, but then dies with
<lispmacs>guix/ui.scm:1747:12: In procedure run-guix-command:
<lispmacs>Throw to key `bad-response' with args `("Bad Response-Line: ~s" (""))'
<lispmacs>bug report time, I guess
<TheZeus121>lispmacs: I am getting the same error on guix pull
<g_bor[m]>hello guix!
<g_bor[m]>I tried to guix pull, but I get a backtrace.
<g_bor[m]>Is something still down, or I just got unlucky with my current revision?
<g_bor[m]>commit is something like: 116787d4ab...
<janneke>g_bor[m]: lispmacs encountered a `bad-repsonse'; you have that too?
<g_bor[m]>yes, the same thing.
<g_bor[m]>it's coming from guix/ui.scm
<g_bor[m]>run-guix-command
<janneke>that doesn't answer your question, but at least you're not alone :P
<g_bor[m]>i will try to have a look around...
<g_bor[m]>it would be helpful to pass the arguments of the run-guix-command to the exception... I will try to find out out where that originates from
<g_bor[m]>what does a .go.something file do?
<g_bor[m]>something seems to be just a random alphanumeric combination
<janneke>g_bor[m]: that's a temporary file
<g_bor[m]>I had one such thing in my checkout after doing some stuff.
<janneke>unless you are compiling, it should have been remomved (i think) but wasn't
<finfin>can one just submit any package to Guix's git server? is there any discrimination other that non-free software/packages that don't build?
<g_bor[m]>git status showed it
<g_bor[m]>finfin: usually there is no such discrimination
<jcowan>Is this the right place for gash and GCU?
<janneke>jcowan: yes -- that's samplet (not present currently) and me
<finfin>g_bor[m], i see, then i'll push packages some, thank you
<g_bor[m]>Some things that should be considered though, is the case of packages that have known vulnerabilities
<lispmacs>janneke: okay, I had just sumbitted a bug report about 20 minutes ago, thought it might be a local issue
<g_bor[m]>also, I remember that once a tool that had the sole purpose to expolit a vulnerability was rejected.
<g_bor[m]>lispmacs: I encounter the same problem.
<janneke>lispmacs: i think that's a good thing, hoping g_bor[m] can shed some light on it
<g_bor[m]>that exception does not originate from the guix codebase...
<g_bor[m]>I think it is some of the guile core libs....
<g_bor[m]>janneke: I've just seen the release announcement. Really nice work...
<janneke>g_bor[m]: ty!
<g_bor[m]>this bad response seems netwok related.
<g_bor[m]>I just tried with another guix.
<g_bor[m]>pull still does not work
<TheZeus121>the guix-daemon log also outputs this when doing guix pull: guile[6775]: Libgcrypt warning: missing initialization - please fix the application
<TheZeus121>(It's with systemd, I'm on a foreign distro)
<pkill9>can someone link me a script that recursively searches references to derivations? e.g. it searches a .drv filefor "/gnu/store/.*\.drv" with grep, then does that same search for all the references it found, etc
<TheZeus121>hm nvm, that libgcrypt warning is emitted when just installing a package as well
<g_bor[m]>pkill9: I believe you could use guix graph for that
<pkill9>I want to do for a guix system derivation, gruix graph only works iwth packages
<pkill9>with*
<g_bor[m]>pkill9: it seems that if you are using the references option, then you should be able to use a store path as an argument.
<g_bor[m]>At least the manual says that...
<pkill9>ah nice, thanks
<pkill9>hopefully it works
<g_bor[m]>yw!
<g_bor[m]>let me know how it goes...
<pkill9>it works :)
<g_bor[m]>nice :)
***MinceR_ is now known as MinceR
<leoprikler>Are guix pull substitutes down for some reason?
<lfam>leoprikler: Not sure but I figure it's related to the downtime of all the GNU sites yesterday
<g_bor[m]>leoprikler: what do you experience?
<lfam>The git repo was offline so CI couldn't build from it
<leoprikler>substitute: Throw to key `bad-response' with args `("Bad Response-Line: ~s" (""))'.
<g_bor[m]>leoprikler: same thing here...
<g_bor[m]>I believe this is coming from a http request somewhere quite deep...
<g_bor[m]>could not yet track it down.
<g_bor[m]>Right now I am trying to get a pull form an olde guix, to see if it is not a regression introduced recently...
<g_bor[m]>Anyone succeeded in pulling recently?
*lfam tries with --no-substitutes
<lfam>Oof, it wants to build ghostscript
<lfam>Does anyone have a Guix pulled yesterday or the day before? What commit is it from?
<g_bor[m]>lfam: I just made a good pull from an older guix.
<lfam>Like, you pulled a commit besides HEAD?
<g_bor[m]>I will try to pull agai to see if the problem really goes away...
<lfam>My Guix is from November 4 so it's pretty old
<g_bor[m]>no, I used another one from my store.
<g_bor[m]>right now it says it has nothing to do...
<lfam>Huh
<g_bor[m]>and it is right now at the tip of current master.
<g_bor[m]>so far so good.
<g_bor[m]>lfam: can you try again?
<g_bor[m]>I have a feeling this was a network issue, or somethiing like taht, maybe it has simply gone away...
*lfam tries `guix pull --verbosity=9`
<lfam>Fails as before: https://paste.debian.net/1117909/
<lfam>guix describe: https://paste.debian.net/1117910/
<lfam>Ah, just ignore my home substitute mirror :)
<g_bor[m]>I guess I just got luck...
<lfam>Same thing with ci.guix.gnu.org
<lfam>I'm filing a bug report
<g_bor[m]>I believe it has been done already.
<lfam>Okay
<lfam>I will wait a few minutes for it to arrive; I don't see it yet
<TheZeus121>Yea, I believe lispmacs submitted one
<lfam>I didn't see any report so I filed my own
<g_bor[m]>ok
<g_bor[m]>what I know so far, is that my failing guix still fails.
<TheZeus121>maybe it is connected with the substitute servers not having the up-to-date guix yet because savannah was down
<TheZeus121>because installing packages from substitue servers seem to work
<g_bor[m]>I am trying to get the version number of the working one, but no luck so far...
<g_bor[m]>the funny thing, is that there is a storepath in my store for the substitute that it is trying to get...
<zimoun>roptat: I understand by I am still not really convinced. :-)
<g_bor[m]>lfam: I still don't see the issue on debbugs...
<g_bor[m]>however it seems to be working again...
<lfam>Huh
<roptat>Mh yeah, bad response-line in guix substitute
<lfam>I didn't get the acknowledgement message, so I guess the mail servers are behind...
<g_bor[m]>roptat: any idea where does that come from?
<g_bor[m]>It seems that sometimes it just works, sometimes it fails...
<roptat>No, it's trying to substitute something while computing the derivations, or just after
<g_bor[m]>I noticed that the store contains the path it was traing to substitute. Is that ok?
<g_bor[m]>I believe this is something on the substitute server...
<g_bor[m]>maybe the logs there could shed some light...
<g_bor[m]>it always dies for me trying to substitute guix-1.0.1-10.41b4b71
<g_bor[m]>hmm...
<jackhill>hmm, mine seems to die in the middle of "substitute: updating substitutes from 'https://ci.guix.gnu.org'... 61.1%Backtrace:…"
<jackhill>it is always a different percentage though
<g_bor[m]>yes, I also noticed that eariler...
<jackhill>and this time it worked…
<g_bor[m]>yes, it sometimes just works
<g_bor[m]>:) I guess when you can get that percentage to 100 accidentally...
<jackhill>heh :)
<g_bor[m]>so, yes... tring several times in a row seems to get trough finally...
<g_bor[m]>Is it possible that the substitute server is overloaded causing these artifacts?
<g_bor[m]>I believe we have zabbix monitoring runnig on the server, are the metrics exported public somewhere?
<civodul>so i'm "invited" to sign this "CLA": https://www.openucx.org/wp-content/uploads/2019/05/ucx-individual-contributor-agrement-v1.4.pdf
<civodul>that's for a ~20-line patch
<civodul>like one eighth of the CLA
<civodul>and the "CLA" actually very much looks like copyright assignment
<civodul>terrible
<alextee>2nd line "intellectual property" stopped reading lol
<g_bor[m]>hmm...
<pkill9>does bluetooth work on gnome for anyone? It says no hardware found, but running bluetooth-send shows bluetooth devices being found, so the bluetooth device is getting seen by the kernel and the hardware is working
<pkill9>I mean, it says "No bluetooth found" in Gnome settings
<alextee>pkill9, i remember my pulseaudio bluetooth wasnt working and i had to comment it out from the pulseaudio config
<pkill9>and "plug in a dongle to use bluetooth"
<g_bor[m]>civodul: any idea where these bad response on guix pull come from? Does the substitute server log have any info?
<jackhill>pkill9: my experience with bluetooth is that I had to pair the device with bluetoothctl. After doing so, the bluetooth icon appeared in the gnome-shell topbar to tell me a device was connected, but no bluetooth controllers appeared in the the gnome configuration app.
<jackhill>I guess I should have filed a bug, but I didn't know exactly what was going on and kept meaning to investigate mroe.
<jackhill>I did get a bluetooth speaker and a presentation remote to work though.
<pkill9>jackhill: did you encounter this issue?: https://wiki.archlinux.org/index.php/Bluetooth#Device_does_not_connect_with_an_error_in_journal
*jackhill suspects dbus/polkit is involved.
<pkill9>(it appears in /var/log/messages in guix system)
<jackhill>pkill9: no, I did not see that. Well, I may not have looked in /var/log/messaged, but I didn't have any particular trouble with the sounds bits.
<pkill9>it won't connect :/ i got it paired with bluetoothctl, had to run as root though
<pkill9>did you need to run it as root?
<jackhill>no, I ran bluetoothctl as my normal user
<pkill9>are you running guix system?
<jackhill>yes, guix system.
<pkill9>did you do anything to set up bluetooth?
<jackhill>I have the bluez installed as a system-wide package, and have the bluetooth service in my system services
<pkill9>i added (bluetooth-service) and added my user to lp group, but bluetoothctl doesn't see the device
<jackhill>Unfortunately I no longer have access to the bluetooth speaker to try again.
<pkill9>when i run as normal user
<jackhill>weird
<pkill9>i'll try adding bluez to the system profile
<civodul>g_bor[m]: what "bad response"? i must have missed it
<civodul>doh! i see it
<pkill9>that was a step forward, my user can see the bluetooth controller with bluetoothctl now, and the error message is gone, now i have a new error message: Nov 25 22:12:56 localhost bluetoothd[685]: Authentication attempt without agent
<pkill9>Nov 25 22:12:56 localhost bluetoothd[685]: Access denied: org.bluez.Error.Rejected
<jackhill>is there an agent subcommand of bluetoothctl?
<jackhill>I have to head out, good luck! (I think good luck is how I got it to work at least ☺)
<pkill9>yay it works
<pkill9>i'm listening to music through it now
<civodul>g_bor[m]: ENOSPC on berlin, working on it...
<civodul>it's terrible that this can happen at all
<g_bor[m]>civodul: ok, nice to know...
<g_bor[m]>I thought that the log will have something.
<civodul>when did it happen?
<g_bor[m]>I see the first report at 19:12
<civodul>it would seem to be around 6PM CET
<civodul>ok
<civodul>we'll have to think about what we can do to handle such issues more quickly
<civodul>anyway, thanks for the heads-up!
<g_bor[m]>ok.
<g_bor[m]>Is this a genuine disk full, or some other resources are out?
<rekado_>civodul: that’s probably disk/vm images again
<rekado_>37T, all used up…
<g_bor[m]>I believe we could get zabbix to send a notification to the sysadmin list when it reaches a treshold. Would that help?
<rekado_>I’d rather want to avoid build and then throw away those 2.2G disk images… :-/
<rekado_>but yeah, changes to the zabbix config are welcome
<rekado_>civodul: we might get to a usable disk faster by deleting the first 10 disk images directly before running “guix gc”
<g_bor[m]>rekado_: how can I reach that?
<g_bor[m]>I mean the zabbix config...
<rekado_>civodul: while “guix gc” is working we’re still at 100% disk usage.
<g_bor[m]>rekado_: do you think that isolating the disk image building in an overlay inside the build container that get transparently dropped is doable?
<g_bor[m]>These are for system tests, right?
<g_bor[m]>We are actually interested in the test results
<pkill9>where do you put modprobe options on guix system?
*rekado_ has to go
<pkill9>nevermind, found it in archwiki
<civodul>rekado_: it's probably the disk images, but that in turn must be because mcron stopped running jobs
<civodul>mcron is a bit buggy it seems
<Franciman>can I install a specific version of a package?
<Franciman>Or am I allowd only to install the latest version available in the repo?
<bandali>civodul, what's the general consensus in the guix community about size of the root partition?
*janneke composes extensive bug report for wip-bootstrap merger
<bandali>(for those considering a separate home partition)
<bandali>my laptop has 256gb, but i don't want to assign too little to / and run out of space soon
<g_bor[m]>janneke: just make sure to save it.
<g_bor[m]>It seems that bug reports get throught at least very slow...
<bandali>(others please free to chime in as well, i'd appreciate your answers equally as much regarding partition size)
<janneke>g_bor[m]: thanks for the heads-up! will do
<g_bor[m]>civodul: I see that the zabbix frontend listens only locally, on port 7878.
<g_bor[m]>Do you use ssh and port forwrding to confgiure it?