*alextee[m] sends a torrent of patches to guix-patches
<brendyyn>did i break a record by neglecting a 1 line patch for 3 years?
<brendyyn>i think i went travelling in china at that point.
<alextee[m]>guix build: error: icu4c-CVE-2020-10531.patch: patch not found ?
<slyfox>i got by openldap patches merged recently. looks like i sent them in 2017 and forgot about them
<atw`>mbakke: just wanted to drop a quick thank-you for the work on synapse! And also to apologize for some mail fumbling, some of it was definitely my fault, but there was at least one message that arrived on the ML out-of-order ... bad day for debbugs and me :P
<dhanvanthri>Hello people, I tried guix system around the time that there was a usb disk image for installation
<dhanvanthri>However I was not able to get a prepackaged binary (specifically CDDA, which is now in the official repo) to work, some error involving unlinked libraries or something of that nature
<dhanvanthri>I understand that guix is a source based distro, and compiling programs from source is the reccomended mo
<dhanvanthri>But I was wondering if someone can give me a quick and dirty of getting prepackaged binaries to run in guix, I recently got into emacs proper, and I want a whole computing environment that feels like it
<Blackbeard>dhanvanthri: guix is not source based distro if you don't want it to be
<Blackbeard>dhanvanthri: are you running Guix the package manager right now?
<dhanvanthri>Blackbeard: Honestly, I want to run it as such as much as possible. I've invested so much into my computing freedom that this seems like the next step
<Blackbeard>Don't worry I'll by here to help as much as possible, and guix has a graphical installer now
<dhanvanthri>Blackbeard: This is the system onto which I'll be installing. The graphical installer worked great last time (I did have to edit libreboot grub for it to work last I tried). I'll be back on my phone as some anon user, tyvm for the moral support <3
<xelxebar>Finally! Putting vga=off on the cmdline ends up displaying a deprecation message, saying to use gfxpayload=text. However, since the guixsd iso and qemu images both use grub's graphics mode by default, this error message wasn't getting displayed on the serial connection...
<jayspeer>I had exported GEM_HOME and GEM_PATH since those were required; uaac is in the path, great! but it fails with `require': libstdc++.so.6: cannot open shared object file: No such file or directory - /home/jayspeer/.gem/gems/eventmachine-1.2.7/lib/rubyeventmachine.so (LoadError)
<zzappie>jayspeer: It may sound very bad but sometimes people pack gems or python packages that rely on some sort of object file on their say ubuntu machine and just push it to the registry never thinking about this dependency.
<jayspeer>zzappie: this seems to exactly be the case :/ I can't even build package locally. Since I need this thing for work I'll just use ruby on ubuntu
<zzappie>jayspeer: you can use 'guix environment' if you have to quickly install loads of packages alien and set LD_PATH there it will work, and won't break your profile
<Veera>rekado: need feedback for bug #40281; apologies if you are looking into it
<jayspeer>zzappie: it will take me a lot time to figure out ruby build system and hopefully I only need to use this tool once, maybe twice. If I happen to use more often I'll figure this out
<zzappie>sneek: later tell jayspeer: sorry I didn't say clear enough. I meant that you can use 'guix environment' to isolate 'ruby gem' installation. Without altering your profile. take a look at https://paste.debian.net/1138220/. will create isolated HOME where you can install arbitrary packages using gem. To get rid of libstdc6++ problem you cab install gcc-objc++@ 6.5.0 in that profile
<pinoaffe1>hulten: on the topic of guix in the sciences: I think that in branches where it's common to work with lots of software and lots of data, the appeal of guix might become clear
<pinoaffe1>i've heard several non-tech scientists complain about reproducibility issues with data analysis, so I think that once guix is more mature, they might be interested in using it (though a lot of issues / incompatibilities in workflow might prevent this)
<apteryx>civodul: is this why the keyboard defaults to US on GDM? I had opened an issue about it.
<roptat>on my fedora workstation, I have to enter the password in the default US keyboard at boot, but then when opening the session, it switches to bépo, and when I lock my screen, I need to enter my password in bépo
<roptat>which would be bad if I weren't the only user of that machine, us other users would have to know their password in bépo too :/
<roptat>it's annoying enough that I thought about sending a bug report to fedora. Should I send it upstream instead?
<civodul>apteryx: i had fixed it in 607fcc75404e2b1fc74affcf372b4a6a789ac55e
<civodul>roptat: so you're saying Fedora has the same bug?
<roptat>at least I can't find a way to change my keyboard in GDM
<roptat>the top right corner has some icons, but when I interact with it I can only shutdown, reboot, etc... or (iirc) change network settings
<ArneBab_>I get failures on guix system reconfigure: ice-9/eval.scm:619:8: Throw to key `srfi-34' with args `(#<condition &message [message: "'/gnu/store/xlcbi7dc89n4wvyz4jk6j0g4590ymi6q-grub-efi-2.04/sbin/grub-install --boot-directory //boot --bootloader-id=Guix --efi-directory //boot/efi' exited with status 1; output follows:\n\n /gnu/store/xlcbi7dc89n4wvyz4jk6j0g4590ymi6q-grub-efi-2.04/sbin/grub-install: error: /gnu/store/
<ArneBab_>xlcbi7dc89n4wvyz4jk6j0g4590ymi6q-grub-efi-2.04/lib/grub/i386-pc/modinfo.sh doesn't exist. Please specify --target or --directory.\n"] 7ff06ee688c0>)
<ArneBab_>i386-pc/modinfo.sh really does not exist, but x86_64-efi/modinfo.sh
<ArneBab_>do you have an idea why it tries i386-pc?
<ArneBab_>uname -a reports Linux fluss 5.1.2-gnu #1 SMP 1 x86_64 GNU/Linux
<ArneBab_>(I cannot boot this system natively since tuesday; I’m currently running grup from a USB-stick and rewiring the disk)
<lfam>Either that or have a generic source-only method as you suggested
<lfam>I have... a lot of free time now. But I want to spend it on packaging rav1e. After that is done maybe I'll turn my focus towards this stuff.
<lfam>It could be useful to just file some bug reports about the source-only thing and the missing Rust dependency graph thing
<lfam>Although, it's hard to feel confident about adding rav1e without knowing I'll be able to use the Guix tools to maintain the package later. It's a huge number of packages and lines of code that will need to be maintained
<lfam>The WIP recursive crate importer works great but if we can't maintain things later... that's tens of thousands of lines of packages with no real ability to work on them
<jonsger>lfam: so we need a `guix maintain` feature :P
<lfam>Combined with the difficulty of building Firefox, nobody has seen the work through to completion
<dustyweb>lfam: I'm not sure that makes sense to me
<dustyweb>what in particular would make it easier to fingerprint
<lfam>I don't know off-hand but something would leak through. Already it's really trivial to identify individual users through browser fingerprinting, and this is such a special case that the risk/reward is just not okay
<lfam>Plus, we would never be able to keep it up to date, which would be another way to start de-anonymizing users
<lfam>I mean... we almost removed icecat entirely due to issues with maintaining it. It's really on life-support
<lfam>There is not a lot of interest in working on it
<dustyweb>maybe we should just switch to tor browser bundle as our base
<dustyweb>I mean, I generally think a) the most interesting thing about tor is onion services as a p2p network rather than anonymnity and b) I'm skeptical the anonymnity works for a persistent state actor and c) brwosers are nearly fundamentally broken from a security perspective anyway
<lfam>I agree, I don't bother with Tor for those reasons
<dustyweb>but still, shipping tor-browser-bundle seems like a good idea
<dustyweb>I think tor onion services are interesting
<dustyweb>tor as an onion router for the normal internet is not
<dustyweb>but I"m interested in using them as a p2p network system
<lfam>There's been discussion within Guix and with upstream Tor previously. I think they are worried about 3rd parties creating alternative packages. They are extremely interested in keeping the deployed base totally homogenous