IRC channel logs

2021-02-09.log

back to list of logs

<Guest16037>[ FAIL ] A previous Guix installation was found. Refusing to overwrite.
<Guest16037>now i dont have the binary
<rekado>it checks for /var/guix and /gnu
<Guest16037>the guix bash installer dont want to overwrite
<Guest16037>yes
<rekado>if they exist it will not proceed
<Guest16037>but i cant remove it
<Guest16037>read only filesystem
<rekado>you would need to remount it as rw
<Guest16037>umount: /gnu/store: target is busy.
***leoprikler_ is now known as leoprikler
<pkill9>i sent another patch lfam
<pkill9>for openh264 support
<pkill9>in qtwebengine
<pkill9>forgot to replace a tab or two with spaces though, so slightly off
<pkill9>but should still work
<lfam>That will be alright
<raghavgururajan>leoprikler: Do I need to change any PLUGIN_PATH for farstream (https://gitlab.freedesktop.org/search?utf8=%E2%9C%93&snippets=false&scope=&repository_ref=master&search=PLUGIN_PATH&group_id=1275&project_id=910)?
<leoprikler>raghavgururajan: probably not, but you may need to propagate gst-plugins-good
<raghavgururajan>I see. I propagated the required gst-plugins
<raghavgururajan>Not sure, why A/V doesn't work in Gajim.
<leoprikler>you might want to use gst-launch et al. for debugging purposes
<leoprikler>assuming farstream actually has documentation on that
<raghavgururajan>Ah I see.
<raghavgururajan>May be I first need to confirm if its farstream or something else?
*raghavgururajan turns to gdb
<roptat>it's weird how cuirass schedules builds... it says it scheduled gtranslator for instance, but the log implies it's building php instead
<roptat> https://ci.guix.gnu.org/build/286097/details
<xelxebar>You sure it's not just building a dependency first?
<pkill9>lfam: I sent another patch cos i used two dashes instead of one
***leoprikler_ is now known as leoprikler
<roptat>yeah it's building a dependency first, but I would expect the dependency to be marked as started, and that package to be marked only as scheduled
<lfam>I agree with roptat
<lfam>I got used to the status quo but it would be better as roptat describes
<lfam>Some set of tests in 'tests/publish.scm' fails consistently on ci.guix.gnu.org, but not on my computers
<euandreh>I have to say, the unattended-upgrade-service-type is awesome
<euandreh>I just ran a recurring command on a server, and now it is downloading things from ci.guix.gnu.org. I initially thought: "why is this happening? I didn't change the environment, inputs or anything!"
<euandreh>Then it hit me: unnatented-upgrade-service-type ran yesterday, now I'm getting the new things
<euandreh>that's just great
<roptat>:)
<raghavgururajan>Gajim 1.3.0 released today.
*raghavgururajan gonna update it in Guix.
***daviid is now known as Guest47549
***Guest47549 is now known as daviid
<BitPuffin>Hello folks, I tried installing the cinnamon-desktop package and adding it to my config.scm file along with i3 and all those, but it doesn't show up on the gdm screen like the other do, any ideas?
<wonko_the_sane>BitPuffin: restart Xorg / reboot ?
<wonko_the_sane>I seem to remember having the same issue and it resolved itself
<benoitj>BitPuffin: gdm picks this up from usr/share/xsessions if I recall. should be in your profile for cinnamon too
<dftxbs3e>missed so much stuff yesterday
<wonko_the_sane>dftxbs3e: I don't suppose there are any recordings ? That would be good
<dftxbs3e>wonko_the_sane, unfortunately I don't think so, only write ups.
<dftxbs3e>I was interested by the guile-netlink stuff
<dftxbs3e>but was too tired
<wonko_the_sane>well that's something at least, still seems like a wasted opportunity to turn ephemeral learnings into permanent resources
<dftxbs3e>there was a recording feature on bigbluebutton and all
<raghavgururajan>Guix! Any pythoners online?
<raghavgururajan> https://paste.debian.net/plain/1184636
<timmydo>does anyone know how to get a package to generate a ./configure using bash instead of the minimal sh? i tried to put ,autoconf-wrapper in the native-inputs
<raghavgururajan>timmydo: You mean the package source file doesn't have the 'configure' file and you wanna generate one?
<timmydo>raghavgururajan: the package i'm trying to build uses autoreconf in autogen.sh i think to generate configure
<raghavgururajan>timmydo: Ah, you need to add autoconf, automake and libtool to native-inputs.
<timmydo>./configure: line 4303: syntax error near unexpected token `CHECK,'
<timmydo>./configure: line 4303: ` PKG_CHECK_MODULES(CHECK, check >= 0.9.4)'
<raghavgururajan>Optionally, gettext-minimal and intltool.
<raghavgururajan>You can add ("check" ,check) to native-inputs.
<timmydo>i think this is because ./configure is using !/gnu/store/pwcp239kjf7lnj5i4lkdzcfcxwcfyk72-bash-minimal-5.0.16/bin/sh
<raghavgururajan>You also need to add ("pkg-config" ,pkg-config).
<timmydo>ah you're right :)
<wonko_the_sane>can't this stuff be visualised with 'guix graph ...'
<wonko_the_sane>?
<timmydo>the graph requires you to have already have a package?
<wonko_the_sane>: D
<timmydo>hm ld is failing with unresolved symbols in the check library
<dftxbs3e>efraim, to update deps according to semver in lock file we can use: https://doc.rust-lang.org/cargo/commands/cargo-update.html - then apply patch to lockfile with diff
<raghavgururajan>timmydo: Can you share the pack-def?
<timmydo>raghavgururajan: https://paste.debian.net/plain/1184642
<timmydo>guix package -f /s/timmy/guix-channel/channel/timmy/radvd.scm --verbose -K
<raghavgururajan>timmydo: You may also try ("check" ,check-0.14) or ("check" ,check-0.12), instead of ("check" ,check).
<timmydo>hm those don't work either. i think there is some issue linking the library rather than a version incompatibility with it
<timmydo>gcc -DUNIT_TEST -g -O2 -o check_all test/check_all-print_safe_buffer.o test/check_all-check.o check_all-device-common.o check_all-interface.o check_all-log.o check_all-send.o check_all-timer.o check_all-util.o privsep-linux.o device-linux.o netlink.o libradvd-parser.a -lc
<timmydo>hm it's missing -lcheck... fun
<BitPuffin>wonko_the_sane: yeah I've had many reboots since that time but it didn't change
<BitPuffin>benoitj: you mean the user guix-profile?
<raghavgururajan>timmydo: I tried this (https://paste.debian.net/plain/1184643) and it works for me.
<raghavgururajan>Oh you figured it out already. :-)
<dftxbs3e>hello! anyone know what is Mathieu Othacehe's IRC handle?
<dftxbs3e>efraim, and to add, what's taken into account for compiling .rlib is not only compiler version but all options cargo passes it. If any of them changes, all .rlib files change. Some projects explicitly require compilation options that will inevitably alter all dependent .rlib.
<dftxbs3e>all dependencies's .rlib *
<efraim>morning everyone!
<efraim>dftxbs3e: 22 hours in, I got a segfault while building guile-3.0.4. I updated guile on the wip-ppc branch to 3.0.5 and I'm going to try again
<efraim>is there a way to build generic rlibs, or a collection of useful ones?
<janneke>dannym: i have removed the premature v0.23 administrative commits from mes wip
<dftxbs3e>efraim, well there's basically no .rlib that are generic
<dftxbs3e>besides libstd.rlib maybe
<dftxbs3e>cbaines, I just noticed I can add your guix-patches repo as a remote to avoid having to deal with the ML/git-am to review patches, that's awesome!
<dftxbs3e>git fetch https://git.guix-patches.cbaines.net/git/guix-patches
<efraim>dftxbs3e: the mechanics to copy build artifacts from build to build is almost the same as copying cargo sources to fix the dependency graph. I'm close to a patch on the second part
<raghavgururajan>> dftxbs3e‎: hello! anyone know what is Mathieu Othacehe's IRC handle?
<raghavgururajan>It's mothacehe
<civodul>Hello Guix!
<dftxbs3e>raghavgururajan, okay! thanks!
<dftxbs3e>hello ludo :-)
<raghavgururajan>civodul, o/
<raghavgururajan>Folks! Gajim's 'check phase fails with the error (https://paste.debian.net/plain/1184636). Following is the diff file, which is to applied on top of current master.
<raghavgururajan> https://jabber.hot-chilli.net/jabberupload/share_v2.php/53ed2b9e-a1cd-4e00-955d-e80d0f36e0ca/gajim.diff
<raghavgururajan>Any ideas?
<dftxbs3e>efraim, question/answer to cargo devs: https://paste.debian.net/plain/1184655
<dftxbs3e>efraim, features are also another factor
<dftxbs3e>we would need to create libraries for each feature combination
<dftxbs3e>efraim, do you think it would be possible to generate the packages instead of writing them out one by one? By that I mean generate packages dynamically so they don't even appear in GNU Guix's source. Because at this point, many package we need to make will just be bloat unless generated by a function we call.
<dftxbs3e>many hidden packages I guess
<dftxbs3e>Also, GNU Guix resets time in /gnu/store and cargo depends on that to determine if they are to be rebuilt. So we could start by patching cargo to disable that functionality.
<dftxbs3e>I will do it.
<efraim>we can use package-transformations to generate some of the packages we need, especially when it comes to features
<efraim>do we have a function for deduplicating a list of items?
<dftxbs3e>efraim, for features, it means we must parse Cargo.toml for libs to detect available features and then generate a package for each possible feature combination.
<efraim>dftxbs3e: as part of guix import crate or just before build time?
<efraim>because at some point we cut off network access, so if we were to autogenerate packages to download sources (and build) it'd have to be before build time
<dftxbs3e>efraim, I meant build time, I was thinking we could generate those packages only from Cargo.toml of the packages (offline)
<dftxbs3e>A macro..?
<dftxbs3e>Build time is not what we want either I think..
<dftxbs3e>.scm file build time, not package build time
<dftxbs3e>efraim, https://paste.debian.net/plain/1184656
<dftxbs3e>By the way, the Cargo devs work there: https://rust-lang.zulipchat.com/#narrow/stream/246057-t-cargo
<dftxbs3e>efraim, we might have to update paths in .d files to point to correct directories when moved
<zimoun>hi!
<dftxbs3e>zimoun, hello :-)
<cbaines>dftxbs3e, I'm glad to hear you find https://git.guix-patches.cbaines.net/git/guix-patches useful :)
<zimoun>Is guix-sysadmin the alias for Guix folks managing the Guix infrastructure? It is to talk about details of public-inbox and how to implement it.
<aadcg`>is it possible to edit a read-only file in guix (under ~/.guix-profile/share)? I know it's against good practices, but I know what I'm doing
<zimoun>aadcg`: AFAIK, no it is not.
<dftxbs3e>zimoun, I find public-inbox more readable than mailman's web archive
<nckx>Morning Guix.
<nckx>aadcg`: It's just going to be a symlink to /gnu/store, which you ‘must never’ edit. Which is why I've done it only about ~50 times. Just be honest when asking for support ☺
<nckx>zimoun: Yes.
<dftxbs3e>zimoun, https://lore.kernel.org/linux-wireless/ - super readable vs mailman's web archives
<dftxbs3e>nckx, hello! :-D
<dftxbs3e>nckx, could you reset the OSUOSL machine? So that I can have an account on there?
<dftxbs3e>I have a binary installer for GNU Guix powerpc64le-linux now, so just use Debian Buster it will be fine.
<nckx>OK.
<zimoun>dftxbs3e: give a look at https://yhetil.org/guix :-)
<zimoun>nckx: thanks
<dftxbs3e>zimoun, \o/
<dftxbs3e>Is there a way we can centralize links to third party GNU Guix developer-oriented services like this?
<raghavgururajan>thigidy dhigidy bum dum gum
*raghavgururajan sleep types
<dftxbs3e>I'll create an awesome-guix repo on sourcehut
<dftxbs3e>awesome-guix-dev ?
<pkill9>that yhetil link is great
<pkill9>and so speedy
<dftxbs3e>cbaines, my unused powerpc64le guix-build-coordinator-agent id still exists right?
<dftxbs3e>I still have it
<dftxbs3e>with password
<dftxbs3e>About to use it
<cbaines>dftxbs3e, yeah
<civodul>Guix System users are encouraged to upgrade: https://issues.guix.gnu.org/46395
<dftxbs3e>cbaines, awesome! I could build guix-build-coordinator successfully
<cbaines>There are still no ppc derivations to build though, as far as I'm aware
<dftxbs3e>cbaines, Yes, maybe you can watch my branch https://git.sr.ht/~lle-bout/guix/log/wip-ppc64le ? Or wip-ppc64le from GNU Guix git repo (not up to date currently)
<cbaines>Using wip-ppc64le in the GNU Guix repository would be the easy option for me
<dftxbs3e>civodul, :O okay! doing now!
<cbaines>currently it looks like computing the channel instance derivation fails https://data.guix-patches.cbaines.net/repository/2/branch/wip-ppc64le
<aadcg`>nckx: I just want to edit a .desktop file from /gnu/store without having to build the package with the changes. how can it be done?
*pkill9 needs to set up auto-updating
<nckx>aadcg`: For example, you shouldn't type ‘mount -o remount,rw /gnu/store’ and hit Return, because then your store would be writable and you could edit things and void ur warrantee!
<dftxbs3e>cbaines, what exactly is the channel instance derivation?
<pkill9>yea you can't get a refund on your purchase of guix
<cbaines>dftxbs3e, it's the derivation computed to build Guix itself, things like guix pull, guix time-machine and the Guix Data Service all use that code
<dftxbs3e>nckx, thankfully there is: guix gc --verify=repair,contents :-)
<raghavgururajan>civodul: Thanks for the info.
<nckx>Indeed, but that does not restore the warrantee.
<dftxbs3e>cbaines, is that simply: ./configure --localstatedir=/var && make ?
<cbaines>dftxbs3e, no, make as-derivation I think involves computing the channel instance derivation though
<cbaines>I'm trying: guix time-machine --branch=wip-ppc64le -- guix build --no-grafts -d hello
<cbaines>to see if that works or fails
<efraim>build failure on guile-3.0.5 on powerpc, i'll try downgrading it to 3.0.2 and see if that makes a difference
<dftxbs3e>efraim, what's the failure?
<dftxbs3e>cbaines, okay I'll test it and tell you
<dftxbs3e>cbaines, what is -d ?
<nckx>dftxbs3e: Prints the derivations.
<dftxbs3e>I see
<cbaines>yeah, the guix build ... bit is more just something to run, what I want to find out is whether time-machine gets that far, or not
<aadcg`>nckx: ok, got it.
<efraim>ERROR: In procedure +: Wrong type argument in position 1: #<unknown-immediate (0x1 . 0x2c71) @ 0xb7e6d784
<dftxbs3e>cbaines, it says this: https://paste.debian.net/plain/1184662 - when I run make as-derivation with my branch (guix package builds fine using ./pre-inst-env guix build guix
<dftxbs3e>works better if I wrap in ./pre-inst-env
<dftxbs3e>cbaines, if this needs "guix" package working, then you need my branch, not GNU Guix's official, marusich is not here to pull my changes yet so
<dftxbs3e>I would need help to update my branch's commits to not change package hashes so it can be merged on master right now
<nckx>What needs to be pushed?
<nckx>(Find your third voucher yet? ☺)
<dftxbs3e>nckx, commits from here: https://git.sr.ht/~lle-bout/guix/log/wip-ppc64le - besides some last ones that need to be different for there but need commit hashes to create
<dftxbs3e>nckx, not yet!
<cbaines>I'm happy to review/push changes as well to wip-ppc64le, especially if it's broken currently, but I don't have time to look at this until this evening
<nckx>Same, although I don't understand exactly what the problem is with your hashes.
<dftxbs3e>nckx, so that it does not need to be merged on core-updates first
<nckx>Got it.
<dftxbs3e>Avoiding world rebuild and push the wip-ppc64le changes directly to master, that's what we need to do
<efraim>some of the patches I found a bit hard to apply so that they wouldn't affect other architectures, the ones against gcc/make-libstdc++/sed
<efraim>in the end it'll be cherry-pick to master and adjust
<dftxbs3e>efraim, sed one is a cherry-picked patch that's already in core-updates, it's not strictly required, only because I work on Fedora
<dftxbs3e>(I think, on Debian linux kernel isnt SELinux enabled AIUI)
<efraim>well that makes that one less patch to worry about :)
<dftxbs3e>efraim, so the trick to make changes without affecting other archs is to conditionally insert code or value in the upper layer? You use unquote-splicing for this?
<dftxbs3e>from the upper layer *
<dftxbs3e>How is the hash calculated exactly?
<leoprikler>civodul: do we need to reboot after reconfigure?
<cbaines>dftxbs3e, if you give me a SSH public key, I can give you push access to the guix-patches Git repository, which will allow you to push branches there, which will get processed by the Guix Data Service.
<dftxbs3e>cbaines, oh cool!!
<cbaines>I've been thinking about this kind of approach to provide an alternative path for submitting patches, maybe with some service to take a pushed branch, and send the emails for it
<dftxbs3e>cbaines, I will call it lle-bout/wip-ppc64le - is it OK to rebase that branch arbitrarily?
<cbaines>yeah
<dftxbs3e>super cool!
<dftxbs3e>cbaines, sent you by private message my private key
<dftxbs3e>public key **
<cbaines>dftxbs3e, got it, try accessing the repository via git@git.guix-patches.cbaines.net:guix-patches now
<cbaines>I think ssh git@git.guix-patches.cbaines.net will also show something sensible
<dftxbs3e>cbaines, works!
<cbaines>great :)
<raghavgururajan>Folks! Any commiters availble to push #45889 please?
*raghavgururajan very much interested in bring Nextcloud-Client (#45889) to all Guix users
<dftxbs3e>cbaines, https://git.guix-patches.cbaines.net/guix-patches/log/?h=lle-bout/wip-ppc64le
<raghavgururajan>Oh I forgot the link, Its https://issues.guix.gnu.org/issue/45889 and v7.
*raghavgururajan is under the influence of zopiclone
<raghavgururajan>leoprikler: As you suggested, could you push the kwayland patch separaely, so that I cam exclude that in v8.
<leoprikler>sorry, not yet
<leoprikler>if you want to, you can reorder them so it is 0001
<efraim> http://issues.guix.gnu.org/46399 propagate crates across builds, moves #:cargo-inputs to regular inputs and fixes the (lack of) rust packages dependency tree
<halfront>Hello, I'm having problems installing Guix; I had to patch Guix to account for my LVM in LUKS partition setup (force all mapped devices to be mounted by the initrd) which seems to work, but shepherd is failing to start every service with CP437: Invalid argument being printed all the time
<halfront>I saw a bug report which said something very similar, but that was due to FS corruption with empty files, I've re-installed a few times, and run fsck etc and found no fs corruption.
<halfront>Does anyone have a clue what I could do to further debug why shepherd fails to start everything?
<gmaggior>(newbie) Hi. I wonder if it is possible to use Guix to script some options of the installed applications. Eg. firewall configuration parameters or background file of a desktop environment, etc. Idea is to have the PC environment fully configured this way
<dftxbs3e> https://git.sr.ht/~lle-bout/awesome-guix \o/
<dftxbs3e>gmaggior, hello! firewall options are likely to be configured with the iptables service with GNU Guix System. Otherwise have a look at: https://framagit.org/tyreunom/guix-home-manager
<gmaggior>dftxbs3e, thanks!
<gmaggior>it seems exactly what I was looking for
<pkill9>my first thought regarding guix-home-manager is that what would be neat is for guix-home-manager to provide it's own file manager commands so you can do things like move, write and delete config files like nromal, except have it record them into it's config file
<dftxbs3e>pkill9, so write parsers for config file -> scheme code for each format?
<pkill9>nah, I'm thinking of it just recording the raw text
<pkill9>the scheme code would be written in the config file
<pkill9>I don't think home-manager is something I'd use, i'm thinking of a different use-case relaly
<pkill9>really*
<dftxbs3e>pkill9, maybe you want this: https://github.com/emacsorphanage/undohist
<pkill9>actually there is something else that would be neat, so I was thinking of using guix-container as equivalent of firejail sandbox
<pkill9>what you could do is chain commands together and automatically create sandbox where each command in that chain can only access it's own data, but each program in the chain can pipe to eachother
<dftxbs3e>pkill9, I think there was discussion between civodul and cbaines on this already here, something called runtime wrappers for installed programs in a profile, so that you can wrap them in any way you want, with firejail or flatpak for example.
<pkill9>oh sweet
<dftxbs3e>For GNU Guix 1.3.0
<pkill9>runtime wrappers is something i want
<pkill9>for other purposes too
<pkill9>like wrapping qutebrowser with python libraries for userscripts
<dftxbs3e>pkill9, found it: https://logs.guix.gnu.org/guix/2020-11-30.log#231201
<efraim>cbaines: how long does it normally take for the data service to process a patch? I'm watching one that I sent about an hour ago
<cbaines>efraim, what's the patch number/series number?
<cbaines>The server I'm using only has 8 cores and 16GB of RAM, so it only processes 4 revisions at a time
<efraim>ok
<efraim> https://data.guix-patches.cbaines.net/repository/1/branch/series-6912
<efraim>I was mostly curious about how it works
<cbaines>right, you can click through to the log and watch the progress https://data.guix-patches.cbaines.net/job/10696#bottom
<cbaines>currently it's computed the channel instance derivations, and is waiting for the lock to insert the data in to the database.
<pkill9>if only my toaster oven ran guix
<rekado_>the build farm *is* a toaster oven.
<rekado_>it gets plenty hot
<civodul>shouldn't our guix-publish.service systemd file encode a dependency on guix-daemon.service?
<pkill9>my system switches to tty2 once login service starts, and there's no login service on tty1 which is reserved for kernel output, it's pretty nice
<pkill9>just wanted everyone to know
<pkill9>cos guix is good
<civodul>:-)
<civodul>so, i guess i have yet to push a blog post for the security issue
<civodul>there are open positions on the security team, people! :-)
<nckx>There's a security team?
<civodul>nckx: https://guix.gnu.org/en/security/
<civodul>there's more than one person, so it definitely qualifies as a team, if that's what you meant
<civodul>but it could certainly use help!
<civodul>you can get a free seat in this prestigious team; interested? :-)
<nckx>I thought it was just lfam 😛
<nckx>What's the expected workload like?
<civodul>well, i see what you mean :-)
<civodul>nckx: quite small but with occasionally spikes
<civodul>like, when something arrives, that can keep you busy for a while
<civodul>but it's quite rare
<jlicht>Do phases on master still need to return #t, or is it optional, or should they not in the first place anymore?
<ArneBab>spk121: does that mean you’re already working on packaging notcurses?
<spk121>ArneBab: nah. All I've done is watch the video, which is pretty neat
<ArneBab>same for me *ducks*
<civodul>jlicht: optional \o/
<nckx>jlicht: Should be optional.
<ArneBab>Now trying to figure out how to replicate "at" on guix, because git is too clever with its hooks and waits for forked daemons …
<civodul>in other news: https://hpc.guix.info/blog/2021/02/guix-hpc-activity-report-2020/
<jlicht>civodul, nckx: with the recommendation being to leave it out, going forward?
<nckx>civodul: I'm interested but don't want to be a bottleneck. The way it's written sounds like folks might pick an address/key at random.
<nckx>jlicht: Yeah.
<nckx>Let it die, and rejoice in it.
<nckx>It never had advantages, it was just a wart.
<nckx>Is it too low level for a news item? (N.B. /me did not check to see if there is a news item ☺)
<civodul>the setgid-root issue?
<civodul>i think we need to publicize security issues
<civodul>even if they look silly or uninteresting
<nckx>civodul: I meant the deprecation of #t. The setgid-root issue: absolutely.
<nckx>Maybe even a priority level for security news but no strong feelings.
<civodul>nckx: ah yes, i agree about #t being a secondary not-news-worthy issue
<nckx>I just pulled after $shameful_time and got about 10 issues dumped on me. 't Would be cute if good news was green and bad news red.
<nckx>(It was an old forgotten box, I don't suggest people actually do this and expect smooth sailing.)
<nckx>See, I could spend 5 more enjoyable minutes with y'all if printing on GNU/Linux were a solved problem, but nope. Bye for now o/
<rictjo>Hi all
<rictjo>I was wondering about module packages. When I add jansson as a use-module package I get the complaint that it doesn't contain any code, but I can easily find and install it with guix install... anyone know what this noob is doing wrong
<rictjo>?
<roptat>hi rictjo :)
<roptat>packages are declared in modules, but the module does not necessarily have the same name as the package (a module can contain multiple packages)
<roptat>when you run "guix show jansson", it will print some information about the package
<roptat>in particular you'll see "location: gnu/packages/web.scm:882:2"
<roptat>that's the name of the file it's declared in, with line number and position on that line
<roptat>you can convert the filename to a module name. In this case, you need the module (gnu packages web)
<roptat>(remove the .scm extension and replace / with a space, that'll give you the module name)
<rictjo>thank you
<rictjo>has anyone already written a .scm file for cgminer ? I'm playing around with it and saw that it is GNUv3 but that there wasn't a package for guix
<joshuaBPMan>Hey guix, does anyone have any tips for launching the flaptak "not-icecat" (the actual mozilla browser) with proper font rendering?
<joshuaBPMan>when I run "not-icecat" via a flatpak my fonts look super bad.
<roptat>isn't that a generic issue with flatpak?
<roptat>(sorry I don't use it, so I can't comment further ^^')
<joshuaBPMan>roptat: I think it may be.
<roptat>rictjo, probably not, there are so many packages out there that it's hard to package them all :)
<roptat>want to help? :)
<joshuaBPMan>roptat: I'm seeing an email thread that says that I can put the fonts in ~/.fonts or ~/.local/share/fonts...
<joshuaBPMan>I'll try that.
<roptat>yeah, they probably ship their own fontconfig, which doesn't work like guix's fontconfig
<joshuaBPMan>roptat: ahhh.
<joshuaBPMan>roptat: what's weird is the fonts seem just fine when I open firefox in X
<joshuaBPMan>sorry "not-icecat"
<roptat>you mean outside flatpak?
<zimoun>cbaines: regarding discussion about Data Service and API. Is all in (guix-data-service web repository html)? Especially about the reachable JSON files?
<nckx>joshuaBPMan: Just say Firefox.
<zimoun>cbaines: I mean (guix-data-service web <stuff> html).
<cbaines>zimoun, the JSON API stuff is in the controller modules, rather than the html ones, since it's not about rendering HTML
<zimoun>grepping \.json returns only stuff in different html.scm
<joshuaBPMan>nckx: sorry I thought it was frowded upon to mentoin non-free software.
<nckx>It is. Firefox is free software.
<zimoun>where are the “controller modules”?
<zimoun>do you mean (guix-data-service web controller)?
<rictjo>@roptat sure if I can get it working Ill share it
<rictjo>but it is old so using autogen (autotools) and spitting out some error about aclocal failing with exit status 63. there is a nice cgminer.nix file but I don't understand scheme guix or guile well enough yet
<rmra>:q
<rmra>ups
<rmra>sorry
*zimoun AFK
<pkill9>with the hurd's translators, could you theoretically mount youtube as a filesystem?
<joshuaBPMan>pkill9: I don't believe so. But I think it is because youtube does not have an index of their videos...
<joshuaBPMan>as in ls ~/youtube/ would not work.
<joshuaBPMan>pkill9: on second thought perhaps you could still mount it, but you'd have to manually specify the video index that you want.
<roptat>is that an issue, does a translator have to implement that?
<joshuaBPMan>9sJUDx7iEJw
<joshuaBPMan>perhaps not an issue. I'm just specifying that many coreutils will not work on this youtube translator.
<pkill9>yea you wouldn't be able to list every video youtube has i guess, but yea if you knew the IDs i was thinking it would work
<pkill9>youtube-dl returns the URL to the actual video file which is just http, so i think it would work
<pkill9>so maybe the translator could let you mount a directory containing all videos from a channel for example, or the first x from a search
<pkill9>and obviously it would be read-only
<pkill9>but you could open and copy them, or pipe them
<pkill9>i just thought it would be neat
<pkill9>you could import them directly into programs like kdenlive
<dftxbs3e>hey, who has a sourcehut account and wants to be able to merge things to https://git.sr.ht/~lle-bout/awesome-guix? So it's more durable than relying on just me.
<argylelabcoat>Greetings all, is anyone uses `guix system` to create docker images? If so, have you had any issues with shepherd within docker?
<nckx>That a-word is only going to attract tech-bros and other a-words with rocket emoji and I will not be held responsible for my actions.
<nckx>Also, I don't have a sr.ht account 😛
<argylelabcoat>I don't really understand why shepherd in docker would fail to start the guix service
<civodul>nice to see more jobs per workers and less .aarch64 stuff at https://ci.guix.gnu.org/workers
<civodul>nckx: oh and thanks for joining the security team!
<civodul>make sure to subscribe to the list if you haven't already
<leoprikler>🚀👨‍🔬👩‍🔬.guix.gnu.org when?
<dftxbs3e>nckx, so for some reason trying to use substitutes on the OSUOSL p9 machine errors with something like: https://issues.guix.gnu.org/46362 - that's the default. Substitutes don't exist anyway so luckily using $ guix build --no-substitutes hello - works!
<dftxbs3e>I ran it, waiting for build to finish now!
*dftxbs3e reboots
<jonsger>I'm asking a reseller on the availabilty of the Ampere Altra (aarch64), but they require a company contact. If someone runs a small company please ping me...
<bonz060>is there a guix-security ML around?
<jonsger>bonz060: only a private one for reporting security bugs: guix-security@gnu.org
<bonz060>Also, I'm thinking of shifting all my emacs packages to use those defined from guix-- I saw talk of that a while back in the ML. Can someone point me to how to do this-- if you have such a setup?
<bonz060>jonsger: Thanks for the info :)
<cbaines>zimoun, I'm around now if you have questions about the Guix Data Service
<cbaines>dftxbs3e, how did you push to https://git.guix-patches.cbaines.net/guix-patches/ ? I'm a little confused that no branch appears here https://git.guix-patches.cbaines.net/guix-patches/refs/
<dannym>jonsger: I do. office@friendly-machines.at
<jonsger>:)
<dftxbs3e>cbaines, I was confused too, well.. I cloned your repo, added a remote with mine, git fetch mine, then checkout to my remote/wip-ppc64le then git push origin lle-bout/wip-ppc64le
<cbaines>dftxbs3e, I'd try creating a lle-bout/wip-ppc64le branch in the guix-patches repo, then pushing that
<dftxbs3e>cbaines, but is it not working? Since if I specify the ref manually it appears in your cgit
<cbaines>dftxbs3e, well, if you push a branch, the Guix Data Service will pick that up and try to process it
<dftxbs3e>cbaines, done
<dftxbs3e>cbaines, okay, I didnt check, but the branch was already there, although weird it wasnt in the refs list
<dftxbs3e>I could access the branch by this link: https://git.guix-patches.cbaines.net/guix-patches/log/?h=lle-bout/wip-ppc64le
<dftxbs3e>it's in the ref list now
<cbaines>great
<cbaines>I can see the Guix Data Service has picked it up as well https://data.guix-patches.cbaines.net/revision/ceb6ef93dd87b81a456fc7396cd242029e4305fc
<dftxbs3e>cbaines, strange phenomenon that was!
*dftxbs3e reboots once again and will be able to create guix-build-coordinator-agent VM on their Talos II.
<pineapples>o/
<pineapples>I'm having a problem downloading the latest ISO: https://ci.guix.gnu.org/search/latest/ISO-9660?query=spec:guix-master+status:success+system:x86_64-linux+image.iso Can anyone else reproduce?
<Whyvn>unless I get a free and open wifi chip I will not be able to use guix?
<Noisytoot>Whyvn: You can get a USB WiFi dongle
<roptat>you'll be able to use Guix, but no wifi
<roptat>you can also use guix as a package manager on any other distribution you like
*Noisytoot accidentally pressed the button to leave
<nckx>pineapples: Yeah, that ‘happens sometimes’ (sorry for that shitty non-answer). It should point to the last successful build but there's a bug somewhere (maybe it only works if the last build == successful).
<nckx>civodul: Er, how do I do that? I assume it's not open or that would defeat the purpose 😉
<nckx>dftxbs3e: Oh, there are ppc64le substitutes now?
<nckx>Anyway, I hope you still have the complete backtrace, it might help fixing the bug.
<dftxbs3e>nckx, no but working on it :-)
<Whyvn>I am testing out guix before installing guixSD, when I install icecat, not fonts render its all runes. is there a base font package that hsa to be insstalled first? I installed fontconf
<nckx>dftxbs3e: Thank you.
<dftxbs3e>Whyvn, freefont thingy, use guix search
<Whyvn>dftxbs3e: ty
<dftxbs3e>nckx, for the backtrace, unfortunately no because it's not printed in any log AFAICT
<nckx>No.
<nckx>Scrollback is your only log yolo etc.
<dftxbs3e>Whyvn, also run "$ fc-cache -rfv" after that
<cbaines>It could be related to https://issues.guix.gnu.org/45828
<dftxbs3e>nckx, basically the command when it fails only prints first line of error, and it is not helpful
<nckx>Whyvn: basically, installing any font should work (within limits, a don't go installing a Tamil-only one).
<nckx>dftxbs3e: Oh, so the unclear report == the bug? That's bad ☹
<Noisytoot>nckx: What if Whyvn only wants to view Tamil?
<nckx>Then I'd be very impressed by IceCat localisation (not to mention the rest of the system) if everything actually renders ☺
<Whyvn>dftxbs3e: I install fonts-gnu-freefont and ran fc-cache -rfv and still icecat shows runes. i havent tried a system reboot, wasn't sure if that is required.
<nckx>Shouldn't be.
<nckx>Are you sure IceCat didn't keep running when you restarted it?
<dftxbs3e>Whyvn, try restarting your shell then run icecat from it..?
<dftxbs3e>Whyvn, also go in fonts in the IceCat settings, see if freefont is there
<nckx>Whyvn: Does ‘fc-list’ show it?
<Whyvn>nckx: i am running icecat from cli and closing from there, not as a job or background process so i beleive it is getting closed each time i ctl-c
<Whyvn>nckx: shows a bunch of fonts in .guix-profile/share/fonts
<nckx>Yes, probably.
<Noisytoot>I have (or at least had, I am running IceCat again now) the same problem
<Whyvn>dftxbs3e: ill see if I can get to the icecat font settings
<nckx>Whyvn: Is Freefont there (I don't know its ‘display name’).
<nckx>At least fontconfig is looking in the right place (.guix-profile/share/fonts).
<dftxbs3e>speaking of font problems, ungoogled-chromium justifies all text weirdly on https://privacytools.io/ - only site that does this for me. IceCat works fine.
<Whyvn>nckx: there is freeMono, freeSans and freeSerif in truetype, I dont see any reference to Freefont
<Whyvn>Noisytoot: do you still have the issue? if not how were you able to fix it?
<Noisytoot>Whyvn: I still have it
<Whyvn>RIP
<dftxbs3e>Whyvn, I think FreeMono etc.. is freefront
<dftxbs3e>is it selected? if not, select it, take freemono for example
<nckx>I think so too.
<Noisytoot>In my case everything is showing up in an icon font
<nckx>Heh? This is weird and (to me) new.
<Whyvn>I just opened it again, i think it fixed itself?
<Noisytoot>I can fix it by copying a font to ~/.local/share/fonts, how can I get it to load fonts from elsewhere
<Noisytoot>It seems to only load fonts from ~/.local/share/fonts
<Whyvn>lol nope, I had a seperate compiled version of icecat outside of guix and that overrid the guix version.
<Whyvn>running the guix standalone icecat still has issue, going to try and select the font manually in preferences.
<Whyvn>no luck manaully selecting a font in preferences, all runes still. weird..
<dftxbs3e>cbaines, hey, https://data.guix-patches.cbaines.net/repository/1/branch/lle-bout/wip-ppc64le - I think Guix Data Service may not take into account that branches can have "/" in their name?
<cbaines>dftxbs3e, yeah, I noticed that too, it's just that page which is broken I think
<cbaines>it's not that big of a problem, but I'll fix it shortly
<cbaines>I probably need to escape / in the link, or something like that...
<Noisytoot>cbaines: https://data.guix-patches.cbaines.net/repository/1/branch/lle-bout%2Fwip-ppc64le works
<cbaines>cool, I hadn't tried it, but that's good :)
<cbaines>I (or someone else?) just needs to fix the link then
<Whyvn>if i am on debian and switch to guixSD, can i keep my /home dir the same or does the whole system need reformated?
<Whyvn>does guix use the same dir conventions
<roptat>I think you can keep your /home if that's a separate partition
<pkill9>you can keep it if it's the same partition as well i think
<pkill9>not sure how safe it is though, always good to have a backup
<lfam>roptat +1
<lfam>I never tried what pkill9 suggests
<roptat>there's an advanced way to install guix where you can keep all existing files from your current distro, but I wouldn't recommend it
<Noisytoot>roptat: What is that way?
<roptat>from your current system, as root, write a configuration file (say in /etc/config.scm), and run "guix system init /etc/config.scm /", then "mv /etc{,.bak}; mkdir /etc"
<pineapples>nckx: Thanks though
<lfam>It's both advanced, and primitive :)
<roptat>and dangerous, I've broken some installs like that without knowing exactly what went wrong
<Noisytoot>What happens with your packages from the old system?
<roptat>I think it's related to the store database loosing some info when you do that
<roptat>they stay in place, but then you can rm -rf /bin and stuff
<pkill9>Whyvn just wants to keep the home directory, not /etc, etc
<roptat>having an empty /etc is necessary though, otherwise the new guix system doesn't boot
<Whyvn>thanks for info, that is good to hear.
<Whyvn>since guix keeps generatations of states of packages does this create a lot of extra space used to keep all the history? or is it not that big of a difference? what is the recommended root dir (/) size for a system? Ive been able to use a root dir of 30G on debian, what should it be with guix?
<Whyvn>or is it a dance of keeping as few generations as needed and cleaning up old packages?
<Noisytoot>Whyvn: It probably depends on your hard drive size
<leoprikler>guix is not really friendly to "small root dir" setups, since that's where all your programs land
<leoprikler>Although if you were to allocate a huge enough partition for /gnu, that'd work out
<lfam>30 GB would be enough unless you kept a lot of old generations of desktop systems, IMO
<lfam>I seem to remember that the Debian installer recommends single-digit gigabytes, and that will be small for Guix
<Noisytoot>Even with Debian programs are in /bin and /lib
<lfam>Does Debian recommend separate partitions for those directories, though? I expect they are part of the / partition
<Whyvn>all / partition
<leoprikler>plus after the /usr merge everything /bin and /lib are symlinks
<lfam>For reference, my workstation is Guix on Debian. My / partition is 38 GB. I have 114 Guix packages, including "big" packages like libreoffice and blender. I can comfortably keep about 12 packages generations, although they are usually not more than 2 months old. The longer time they span, the more space they'll use, because more packages will have changed
<lfam>I use a lot of space on Guix development, like testing builds and working on multiple branches
<lfam>We *do* aim to reduce space usage of Guix packages. We even have a tool `guix size` to help. But our packages are not as space-optimized as on Debian, and we lean towards enabling features over saving space
<Whyvn>thanks for the information
<lfam>Originally, Debian encouraged me to make the / partition like 4 GB or something. That was plenty, but I've expanded it a few times since getting involved with Guix several years ago
<Noisytoot>Is there a solution to the IceCat font issue yet?
<civodul>nckx: re guix-security, you should have received an invitation
<Whyvn>Noisytoot: I had no luck ><'
<Noisytoot>Whyvn: In my case I found a workaround of copying the fonts to ~/.local/share/fonts
<Whyvn>Noisytoot: that did work, thanks. guess icecat is not checking the .guix-profile/share/fonts dir
<lfam>Hm... seems like something we should fix :)
<lfam>I don't know how fonts work but it seems like Guix packages should look there, right?
<bavier[m]>I feel like we should be using `open-pipe*` in `invoke`, instead of `system*`.
<bavier[m]>so that it's possible to provide input, or capture output on current-input-port and current-output-port
<lfam>It would make invoke "pipe-able"?
<bavier[m]>there'd be some other plumbing involved, I think.
<bavier[m]>something like `invoke/quiet` with making stdin, stdout, stderr available over the current-*-port's
<bavier[m]>idk how broadly useful it'd be, but I've at least had a few occasions where I need to invoke a program while providing input.
<bavier[m]>or examine the output if the test doesn't reliably use the exit code to indicate success/failure
<lfam>Yeah, I feel like that use case is always a little too complicated in Guix. It would be great to have a simple abstraction
<Whyvn>given any tar file with a linux program, can it be installed on guixSD? say I find some package that is not on guix, am I not limited to what outside packages I install when using guixSD? I am not sure how compliant guixSD is with other gnu/linux systems yet.
<leoprikler>you might get them to run via patchelf but it's tricky
<bavier[m]>the Guix System generally does not conform to the linux file system hierarchy assumed by many binary program releases
<leoprikler>the only compatibility guix offers is /bin/sh and /usr/bin/env
<lfam>You can also use the extra-special-files-service to make libraries available in the locations expected by the program
<lfam>It can work, but no guarantees :)
<leoprikler>if you have the source code on the other hand, compiling and later packaging it should be possible, assuming the dependencies themselves are packaged
<Whyvn>so its best to running the system the guix way and not try to make some frankenstein super hybrid between the different system types? my only fear of switching to guixSD is that it will not have pacakges that are needed. (i dont use many odd packages so probably rare, there is still that "what if" thought)
<leoprikler>you can sometimes bridge that gap with flatpaks, but if you do encounter such packages, it's often much rather an incentive to package them for guix
<leoprikler>that's how we lure people into become contributors :)
<lfam>:)
<jlicht>Some people used guix' container facilities to pretend to expose a more traditional environment. I vaguely recall someone getting Android Studio to run that way
<jlicht>It's still quite a bit more involved than "unpack, fire and forget" though :-)
<leoprikler>guix environment --container --spoof-fhs sounds like a great idea tbh
<lfam>Uh-oh: https://seclists.org/oss-sec/2021/q1/128
<lfam>We might need to graft ncurses soon
<bavier[m]>just finished a package for https://www.edbrowse.org, I'm sure it's just the thing everyone's been waiting for.
<leoprikler>?
<civodul>lfam: i can confirm the xterm crash, fun
<lfam>:(
<lfam>I'm guessing it's in ncurses, since it works on screen too
<civodul>xterm doesn't use ncurses though
<civodul>so it must be something more fundamental?
<lfam>Our xterm package does depend on ncurses, right?
<civodul>oh indeed
<civodul>hmm dunno then
<lfam>I'm also starting a conversation with the Savannah crew about if this was supposed to be made public. The Savannah bug report is private but a public email was generated
<civodul>nice
<lfam>Maybe the bug report started as public, or maybe screen has configured it to do this
<lfam>It would be good to understand what happened, though
<lfam>Previously, we grafted ncurses in commit 625e7cd654418aa8c5af9f49189d67b9d550b8ea, so hopefully it's still a viable approach
<lfam>Curl-ing the URL doesn't crash xterm on my Debian
<lfam>(It's Debian's xterm)
<lfam>Same with Guix's xterm
<lfam>Ah, git it
<lfam>Got it
<lfam>FuN!
<cbaines>Noisytoot, do you have a specific issue in mind? When I've encoutered issues with fonts (or lack of) in Icecat, I've resolved it by installing fonts, usually font-dejavu
<cbaines>Sorry, thought that was the latest message, but I'd scrolled up in Icecat, so that may be out of date...
<civodul>lfam: yeah you have to select the line :-)
<nckx>civodul: I did, thanks.
<lfam>Nice! There are 4 slots per worker on CI now :)
<lfam>Let's see how it goes
<nckx>lfam: 'got it' as in reproduced the crash?
<lfam> https://ci.guix.gnu.org/workers
<lfam>nckx: Yeah
<nckx>‘Yay’.
<lfam>You have to select the sample with your mouse
<lfam>Lol
<jonsger>oh there is a visual bug, when you select the search field in the workers view...
<lfam>I see it too jonsger
<civodul>lfam: yup, 4 slots, and only half of them are emulating
<civodul>now we need some work for the others
<lfam>I feel like... we should be able to rebuild the distro quite fast with the resources we have, at least for x86_64
<civodul>and and... we can click on the worker name!
<civodul>woow
<civodul>sneek: later tell mothacehe you're my hero!
<sneek>Got it.
<civodul>sneek: botsnack
<sneek>:)
<lfam>I had thought the worker nodes were equivalent to head nodes, but it seems they "only" have 64 cores.
<lfam>25 nodes * 64 cores = 1536 cores
<lfam>It's substantial
<rekado_>there are two different types of servers in use
<rekado_>most of the big servers are not available right now, though
<rekado_>we’re using one of the big nodes as the new head node
<rekado_>I don’t know what’s up with the other big nodes; Madalin would know.
<civodul>rekado_: did you try clicking on all these nodes?
<civodul>i know i know, it's just graphs and not as nice as Grafana and all that
<civodul>but still, i find it so cool
<rekado_>it’s super cool!
<rekado_>the first three nodes don’t have any graphs, so I missed it at first
<roptat>btw, we don't have any overdrive running behind berlin?
<civodul>well, it's complicated
<civodul>they're not connected until mothacehe and the rest of us figure out how to do it, network-wise
<civodul>which is a bummer, but choosing zmq means we have to open more ports or set up a VPN
<dftxbs3e>cbaines, quick bug report, getting these over and over: https://paste.debian.net/plain/1184791
<Whyvn>cbaines: intall font-dejavu did not seem to fix the icecat issue
<Whyvn>installing*
<cbaines>dftxbs3e, it might be possible to fix that by updating Guix, although I should probably make the guix-build-coordinator code backwards compatible with respect to Guix, I'll have a quick look...
<dftxbs3e>cbaines, Will do that, it's set up to update every day already.
<jlicht>civodul: poor man's vpn over (reverse) ssh tunnels wouldn't work?
<roptat>civodul, sounds like a VPN might be the easiest solution? we have the openvpn service, that would work for clients and servers
<dftxbs3e>wireguard's much easier and much faster! :-D
<dftxbs3e> https://guix.gnu.org/cookbook/en/html_node/Connecting-to-Wireguard-VPN.html ?
<cbaines>dftxbs3e, actually, I think it's just a compatability issue with newer versions of Guix... I'll push a fix shortly
<lfam>The problem is that it's not trivial open the Wireguard port from the berlin build farm
<cbaines>Whyvn, did you refresh/rebuild the font config cache?
<lfam>There has been a request about it open for a while now
<civodul>yeah so we have a chicken-and-egg problem for that thing
<dftxbs3e>lfam, and openvpn it's easier to open the port?
<civodul>we have no open ports -> use VPN -> need open ports
<lfam>No, networking in general is very locked down on the build farm
<lfam>Which tool we use is not relevant to the problem
<roptat>oh well, if wireguard works, no objection :)
<dftxbs3e>Silly hosting policy I guess
<lfam>Serious hosting policy :)
<dftxbs3e>When you can't work due to it, can't be serious
<lfam>It's not just some host, but a research institute. So, it's not designed for open network access
<Whyvn>cbaines: i did fc-cache -rfv
<rekado_>¯\_(ツ)_/¯
<civodul>dftxbs3e: i think you have to realize that it's a research institute hosting all this for free
<lfam>The price is right :)
<jlicht>Free as in beer, not freedom ;-)
<civodul>i mean it's huge support
<cbaines>I'm still of the opinion that the Guix Build Coordinator offers an escape from some of the architectural difficulties associated with Cuirass...
<rekado_>they have been getting better about opening ports for us, actually
<dftxbs3e>I understand, if only they would let you be in a DMZ with all ports open so you can't possibly mess with the rest of their infrastructure at all.
<lfam>Sure, but it's never "just" that easy
<cbaines>Whyvn, I guess that should do it, can you share a screenshot showing what issue you're encountering?
<civodul>cbaines: yeah... i can see the shortcomings of zmq rather than http in particular here
<lfam>Things that seem unreasonable usually aren't when you are inside of them
<rekado_>so, if there’s a port you need to be opened please send me details so I can ask them.
<lfam>They are saving us... probably over $100k per year
<rekado_>(and if that enables us to stop asking them for new ports: even better)
<lfam>Let me find the message rekado_
<rekado_>thanks!
<rekado_>it’s been difficult for me to keep track of things
<lfam>I know, it's okay
<lfam>It can be overwhelming, and now "normal life" has disappeared
<lfam>rekado_: https://lists.gnu.org/archive/html/guix-devel/2021-01/msg00393.html
<dftxbs3e>lfam, I've been at places with similar situations and everyone was burned out or there was so many policies everywhere not really fitting use cases but no one can do anything about it. Don't know what happens there, may be similar.
<civodul>damnit, sorry for the stressful topic (again) rekado_
<lfam>For me, it's been a tremendous struggle this last year
<rekado_>civodul: heh, I’ll cope :)
<civodul>:-)
<lfam>dftxbs3e: It's maybe a bit like that, but also, in general, these high-performance computing clusters are designed in a different way than a "normal datacenter", so access is generally more locked down
<civodul>cbaines: the BuildSteps thing, too
<lfam>Even when they aim to help host things that have a more typical architecture, we still have to go through their processes
<Whyvn>cbaines: https://i.imgur.com/ahXKidW.png
<lfam>And then, administering it for us is yet another task on top of their actual job
<lfam>So, it's tough
<cbaines>civodul, indeed, and that's not even touching on the features that become useful when trying to do far more dynamic work when testing patches and branches, there are plenty more features already implemented that are pretty essential for that
<cbaines>Whyvn, OK, that's useful to see, what's the locale set to?
<paulj>evening all. I am having problems getting emacs to run in server mode. I have a shepherd service starting the daemon, and everything appears to be working. A quick 'ps ax' shows emacs running in daemon mode, but when I run 'emacsclient -c' I get an error message indicating the server isn't running. Have any of you come across this before - I am sure I am missing something here!
<civodul>cbaines: yes, and also retrying builds, finding out about flaky builds, etc.
<civodul>yeah, dunno
<lfam>It's a shame we can't get together in person
<rekado_>lfam: thank you for the pointer
<civodul>yup
<lfam>It would be good to discuss over a long dinner
<lfam>A long dinner with 30 people :)
<cbaines>dftxbs3e, I've pushed a fix for the exception you mentioned. Is it useful for you to update the guix-build-coordinator package in Guix?
<civodul>lfam: heh, good memories of such things :-)
<lfam>This weekend helped lift my spirits
<civodul>yeah that was nice!
<lfam>And I even got to simulate jet lag ;)
<civodul>i realized we didn't even turn on the cameras to take a "group picture" like we did in November
<civodul>heh, how nice :-)
<rekado_>I’m not a very social person, but meeting you in the past at, before, and after FOSDEM was always really enjoyable
<dftxbs3e>cbaines, you want me to selectively update the package?
<lfam>I'm surprised you think of yourself that way rekado_ :)
<civodul>me too actually :-)
<civodul>(but that's because i'm not a very social person)
<cbaines>dftxbs3e, I don't know/can't remember if you're running from the Git repository or package, so I was wondering if it would be good to update the package?
<dftxbs3e>cbaines, I use GNU Guix System so I can't selectively do it
<lfam>Not that it's bad or wrong to not be social
<dftxbs3e>It's on x86_64 this error, so nothing unusual
<cbaines>Ok, it sounds like updating the package will help, so I'll do that in a moment
<dftxbs3e>cbaines, ah! understood
<Whyvn>cbaines: LANG=en_US.UTF-8
<civodul>cbaines: so in the end i'm happy we have "better" CI infrastructure in many ways, but i am yet to be convinced by the design choices :-)
<civodul>maybe it's okay to have two different tools, after all
<civodul>+ synchronous offload
<cbaines>Whyvn, hmm, unfortunately I have no more ideas
<rekado_>(social encounters usually are very draining for me and they require a lot of attention. In many encounters it happens that I can’t remember what was discussed because I was so focused on getting *through* the conversation. The FOSDEM dinners and pub settings felt unusually unconstrained in comparison.)
<dftxbs3e>Whyvn, it sounds to me that solving this error on foreign distro is another beast than on GNU Guix System.
<lfam>I see rekado_, I'll keep it in mind
<Whyvn>cbaines: as Noisytoot said, copying the fonts from .guix_profile/share/fonts ./local/share/fonts seems to be a quick fix for the moment.
<Whyvn>dftxbs3e: yeah that is probably it.
<rekado_>FYI: I just submitted the firewall update request to the network team. Sorry for the delay!
<ejh>how can i run appimages in guixsd?
<cbaines>dftxbs3e, I've pushed the guix-build-coordinator package update now
<rekado_>ejh: appimages make at least one assumption about the target system
<rekado_>that assumption is the location of the loader executable
<rekado_>with /lib64/ld-linux-x86-64.so.2 pointing to $(glibc)/lib/ld-linux-x86-64.so.2 you should be able to run them
<dftxbs3e>cbaines, thanks, updating!
<rekado_>(where glibc is one of the outputs of the glibc package)
<dftxbs3e>woops 502 from guix git on savanah
<dftxbs3e>and it just worked again..
<pkill9>ejh: yes you can, like rekado_ said, but you'll want to build glibc with ldconfig re-enabled and build an ld.so.cache with all the libraries you want it to access and put it in /etc
<pkill9>i made a service that does that for you
<rekado_>pkill9: oh, that’s also necessary? Why?
<pkill9>rekado_: so it looks for libraries 'in' /etc/ld.so.cache
<rekado_>aren’t we already building glibc with an ld.so.cache? I remember discussing this with civodul as a possible runtime optimization.
<civodul>rekado_: yes that's on core-updates
<civodul>/etc/ld.so.cache is never loaded
<civodul>neither on master nor on core-updates
<pkill9>nope i don't think so, the package explicitly disables ld-config witha snippet
<civodul>so i'm not sure what you're trying to achieve
<rekado_> https://issues.guix.gnu.org/44899
<civodul>(on core-updates, $prefix/etc/ld.so.cache is loaded)
<pkill9>ejh: my channel has an fhs-support-service https://gitlab.com/pkill-9/guix-packages-free
<ejh>Thanks everyone.
<rekado_>ah, now it falls into place; sorry, pkill9, this is unrelated.
<pkill9>I'm working on a script though that adds fhs support without needing it in system configuration
<pkill9>so it doesn't download/build all the libraries when you update
<pkill9>or glibc
<rekado_>pkill9: something like the “guix pack -RR” wrappers perhaps?
<pkill9>i'm not sure how those wrappers work
<pkill9>do they change all the references to store paths to be relative?
<bavier[m]>no, they wrap the executables, and the wrapper sets up chroots and namespace mounts and such
<pkill9>the script i'm working on (well intend to work on) does the same thing as the fhs-service - place symlinks in /lib64/ld-linux...so, /lib/ld-linux...so, and /etc/ld.so.cache
<pkill9>but it will create the garbage collector roots so it doesn't get garbage collected
<pkill9>and all be in one script, so you can just run it and it will install FHS support with the libraries specified in the script
<pkill9>and when you want to update, you just run it again
<rekado_>there are a few different implementations; one uses proot, another fakechroot, etc
<lfam>nckx, civodul: Whoever just updated the website, I pushed a followup commit. Can you do it again?
<dftxbs3e>cbaines, my system is on 03b5db565e9db834f7565e7c7f80a1dd272af36d - with all services restarted, it still has the same error, not sure what to do
<dftxbs3e>I stopped the agent for now
<cbaines>hmm, I'm probably not understanding enough about how Guile modules work :(
<cbaines>I'll make some more drastic changes...
<cbaines>it probably doesn't help that I have a copy/paste bug as well
<cbaines>I've pushed another commit which may work better, but I'm not managing to test this locally
<cbaines>for some reason, Guile tells me it's fetching narinfo-references from both modules, which doesn't make sense to me, because it moved...
<cbaines>anyway, I need to get some sleep, I'll pick up trying to work out what Guile is doing in the morning
<dftxbs3e>cbaines, have a good night, no rush :-)
<civodul>lfam: should happen automatically (at every hour)
*civodul -> zZz
<civodul>ttyl!
<mroh>I'm confused... `guix refresh -l inetutils` -> Building the following 724 packages would ensure 1838 dependent packages are rebuilt...
<nckx>lfam: That should happen automatically. Hourly or so.
<nckx>Oh, Ludo responded, nv you m.
<nckx>mroh: ...and?