IRC channel logs


back to list of logs

***felixfahrbahn[m] is now known as tessssann[m]
<raghavgururajan>What package provides 'INOTIFY'?
<raghavgururajan>mroh: I used that package it doesn;t have library called[.a].
<raghavgururajan>But there is
<kozo[m]>Glee -
<mroh>raghavgururajan: inotify on linux is part of glibc, afaik. maybe you have some bsd sources that needs this lib?
<raghavgururajan>mroh: Ah thanks. Let me look into it.
<wleslie>so I've been somewhat aware that I'm "not doing it correctly" as I'm packaging my cross environment, today (while battling with some linker errors) I figured I'd actually test using --target
<wleslie>now, it's not picking up my cross toolchain, and I think that this is because I'm not using native-inputs vs inputs properly
<wleslie>probably most notable here:
<wleslie>how do I tie crt, newlib, and libstdc++ into the gcc that I export as part of the toolchain? and how do I get guix to find my toolchain from the requested --target?
<wleslie>janneke: when you have some spare time, I'd love your thoughts on those questions ^
<brown121407>Guix's IceCat seems to make Cloudflare protected sites loop infinitely on the "Checking your browser before accessing" page. Is there any way to make this stop besides using another browser?
*wleslie is reading commencement and is a little daunted but can probably muddle through
***jsndjsjsjsjaj[m] is now known as felixfahrbahn[m]
<pinoaffe>brown121407: I have not yet encountered this issue, it might be caused by one of the plugins that icecat comes with by default
<brown121407>pinoaffe, I have all plugins disabled. To provide an example where I'm stuck on "Checking on browser", the sign in page for gitlab is such a case:
***apteryx is now known as Guest67518
***apteryx_ is now known as apteryx
<leoprikler>I don't necessarily think that's IceCat. Cloudflare is prone to looping in Epiphany as well.
<pinoaffe>brown121407: oh wow, that site is not working for me either
<pinoaffe>even though I've previously used this particular site as well as lots of cloudflare-protected sites without issues
<pinoaffe>looking at the network log while loading that page, it does not seem to contact any cloudflare servers, so it may not be a cloudflare-related issue in the case of gitlab (or maybe that's the problem, I don't know)
<leoprikler>IIUC it should communicate with Cloudflare in some fashion to do some weird "sanity" checks.
<brown121407>pinoaffe, does this work for you: ?
<civodul>Hello Guix!
<janneke>hello civodul!
<pinoaffe>brown121407: yes
<pinoaffe>civodul: moin!
<brown121407>pinoaffe, weird, I have problems with it too...
<brown121407>Thanks for checking anyways
<janneke>wleslie: that's a whole lot of questions, that i don't fully get; i can have a look later
<raghavgururajan>Hello Guix!
<raghavgururajan>Annyone available to help me this issue (
<raghavgururajan>leoprikler: My instint say thya yiy ciyud firgutr it iut.
<raghavgururajan>on shoot
*raghavgururajan 's zopiclone is kiking in
<wleslie>thanks, I think I found a way to proceed for now
<leoprikler>raghavgururajan: building 73%
<leoprikler>I don't have bayfront substitutes, so it'll take some time
<raghavgururajan>leoprikler: Thanks for looking into it.
<civodul>hi tgamblin-llnl! looks like you have networking issues :-)
<leoprikler>raghavgururajan: small hint, you should probably call the package "telegram-desktop" (like the command)
<raghavgururajan>leoprikler: Yep, was gonna change the package name in the next revision.
<leoprikler>According to gdb it fails in Ui::Emoji::UniversalImages::generate(int, int) const
<raghavgururajan>Oh, patchable or too deep?
<leoprikler>I'm not quite sure
<leoprikler>I'll have to debug harder probably
<raghavgururajan>I think it is Qt related. My another package 'nextcloud-desktop' (#45889) also doesn't launch in similar way.
<leoprikler>I assume one of the following asserts fails:
<leoprikler> Expects(size > 0);
<leoprikler> Expects(index < _sprites.size());
<leoprikler>apropos qt if telegram depends on qresources, that probably won't work
<leoprikler>mumble doesn't get them either
<mdevos>does someone have an IPFS service definition for Guix?
<leoprikler>however, not grafting doesn't appear to be a solution
<jeko>Hey Guixters ?
<jeko>I have installed Emacs in a custom profile on my Guix System. Gnome app list does not contains Emacs. Do you know why?
<iyzsong>is the custom profile in gnome's XDG_DATA_DIRS, also it may need restart gnome to refresh the list.
<raghavgururajan>leoprikler, Can you try with "-DTDESKTOP_DISABLE_GTK_INTEGRATION=ON"?
<leoprikler>does it work for you without that?
<leoprikler>i.e. without gtk integration
<jeko>iyzsong: Hey! Yep I added it but don't remember if I restarted Gnome... let me retry it !
<jeko>iyzsong: I set XDG_DATA_DIRS in the .bashrc file. is it ok to do so ?
<iyzsong>jeko: how do you start gnome?
<jeko>it starts automaticaly
<iyzsong>i think it need to gnome-shell's environ. I don't know how to set environment varibales for gdm though.
<jeko>hm ok!
<wleslie>jeko: if you want your desktop session to pick up environment variables, you can put them into ~/.profile
<jeko>wleslie: Thank you, on my way to try it !
<jeko>sounds like I failed haha will retry after lunch
<wleslie>ok so I have a nice toolchain now, how do I get `--target` to use it?
<leoprikler>raghavgururajan: the issue is this->_sprites being empty
<leoprikler>Interestingly this code seems to run in the initializer, so…
<leoprikler>(Well in the initializer of Ui::Emoji::Instance)
<civodul>wleslie: hi! --target creates a cross-compilation toolchain by calling the procedures in (gnu packages cross-base)
<civodul>passing them the triplet
<civodul>cbaines: hey! do you know the status of the package browsing interface that Danjela worked on?
<civodul>IWBN to integrate it
<civodul>mothacehe: looks like the Cuirass web page doesn't show up at
<civodul>or maybe i'm looking at the wrong place?
<civodul>apparently the web site was rebuilt 20mn ago so it should be up-to-date
<mothacehe>civodul: it's here:
<mothacehe>and there's a (almost hidden) link here:
<civodul>mothacehe: ooh indeed, rather hidden :-)
<civodul>BTW, i'm sorry for commenting on the name "Cuirass"; i hadn't read the other thread on guix-devel when i did
<civodul>(i find the the logo pretty nice actually)
<mothacehe>hehe no worries, lots of exchanges about that recently. Maybe we need a new section on the website to point to Guix ecosystem software such as Cuirass, the Data Service and so on
<mothacehe>but the navbar is already quite furnished
<civodul>yes, not sure how to best present it
<civodul>but i agree it'd be nice to have pointers to these projects
<jeko>Hey Guixters !
<cbaines>civodul, it's still running here
<cbaines>I haven't had time to look further at it, I think there's still some thinking needed around where it could go and how it should integrate with the rest of the website
<mothacehe>hey zimoun!
<civodul>cbaines: alright; would be nice to move forward here
<civodul>building all the package pages statically has become a bit of an issue :-)
<kiwi_guixer>Hi is there some bug with recent GDM? I guix pulled and now I see black screen after reboot. I can login with previous revision but not with new.
<cbaines>civodul, ah, OK. One approach would be to have be the part of the website for looking at and searching for packages
<efraim>sneek: seen vangrantc
<sneek>Sorry, no.
<cbaines>and splitting it off to a separate domain would remove the need to tightly integrate the dynamic content in to the static website
<civodul>cbaines: we could keep /packages and have the nginx config direct it to the other thing
<efraim>sneek: later ask vangrantc do you have any suggestions for setting up a debian build environment in Guix System?
<efraim>sneek: botsnack
<apteryx>what would you think of moving a few core python building modules to (gnu packages python-build) ?
<zimoun>civodul, cbaines: hehe! thanks about option hints. Well, Friday procrastination, I have implemented levenshtein-distance and started to be able to hint. My question is: where do put this kind of stuff? (guix ui) or (guix scripts) or else?
<civodul>cbaines: having everything at might facilitate css sharing
<civodul>zimoun: neat! i'd put the Levenshtein bit itself maybe in a separate module
<civodul>and then hinting in (guix ui), i think
<zimoun>I was thinking to tweak parse-command-line in (guix scripts)
<cbaines>civodul, I think having a somewhat consistent style is a must, but how to implement that is one of the things remaining to work out
<cbaines>using the CSS from the website elsewhere could get a little tricky when making changes to either the website, or other things using the same CSS
<zimoun>civodul: a module for a 21 lines function?
<civodul>ah well, maybe not then
<civodul>cbaines: i think it's ok here; the generated pages could have the 2-3 CSS links that they need and then be done with it
<kiwi_guixer>Is there a working alternative for GDM, ideally with auto login support?
<zimoun>well, let propose a patch and then the v2 can revamp :-) Keep in touch
<kiwi_guixer>aH, it looks like regression RADEON(0): Setting screen physical size to 338 x 211
<cbaines>civodul, out of interest, what's the technical issue with the static generated pages?
<civodul>cbaines: building the web site in one language takes some time, largely due to the package pages, and now there are several languages
<kiwi_guixer>Anyone familiar with /gnu/store/8kvz928qp7fdv4bak5zjqhm05r3ccx9f-xorg-server-1.20.10/bin/X: symbol lookup error: /gnu/store/7nnnzsrlflq60pp08g1y1amjk891vgp3-xf86-video-ati-19.1.0/lib/xorg/modules/drivers/ undefined symbol: exaGetPixmapDriverPrivate
<cbaines>civodul, OK, makes sense
<rekado_>kiwi_guixer: I saw the same problem a few days ago! I had to revert to an older kernel.
<kiwi_guixer>Thank you, I am new user, any pointers what to set in config.scm appriciated
<civodul>rekado_: for an unresolved symbol?
<kiwi_guixer>To switch to an older kernel
<kiwi_guixer>I have default config from the manual.
<kiwi_guixer>(There is no kernel term in it)
<kiwi_guixer>Manual also has no relevant kernel entries
<kiwi_guixer>So operating-system takes kernel parameter but there is no reference to available values.
<kiwi_guixer>So should I set kernel = "linix-libre_5.4" to set ?
<kiwi_guixer>(honestly NixOS Options manual was less cryptic)
<kiwi_guixer>There is also that Warning about debugfs during reconfigure. Some match-error but I did not change my config.scm and it worked in the past.
<civodul>kiwi_guixer: you'd need to set the 'kernel' field as documented at
<rekado_>civodul: oh, it’s possible I only rolled back to an older system generation. I don’t remember; it’s a different machine.
<civodul>i see
*apteryx has a fix for the PYTHONPATH uglies
<rekado_>apteryx: like… for a *all* the PYTHONPATH nastiness?
<rekado_>what happened to you? You’re casually tackling all the difficult problems!
<kiwi_guixer>Thank you civodul but after reading those pages is not clear if adding (kernel "linux-libre-5.4") is what I should do.
<apteryx>eh, trying to catchup with 2020
<kiwi_guixer>Should I know Guile to use Guix?
<civodul>kiwi_guixer: you'd write (kernel linux-libre-5.4), without quotes
<civodul>that said, i doubt it'll fix the unresolved symbol issue you mentioned
<civodul>IWBN if you could report the issue by emailing with your OS config and the output of "guix describe"
<civodul>or rather "guix system describe"
<civodul>apteryx: thumbs up for addressing all these issues!
<kiwi_guixer>rekado_ wrote older kernel fixed the issue and Guix System worked for me too before pull
<civodul>apteryx: BTW, re patch-and-repack: (forgot to Cc you)
<rekado_>kiwi_guixer: I may be wrong. Could be that it’s just the combination of older kernel and older packages (including xorg-server) that fixed it for me.
***rekado_ is now known as rekado
<kiwi_guixer>Ah so it is a symbol and Guix suggest importing (use-modules (gnu packages linux)) Nice
<kiwi_guixer>I will try to downgrade xorg too if lower kernel is not enough
<kiwi_guixer>Then Mesa, I hope downgrading is as easy as downgrading kernel
<apteryx>civodul: will check a bit later :-) I'm still busy fixing the collaterals of Python 3.9.1 on core-updates.
<civodul>heh :-)
<kiwi_guixer>I am already thankful because now I know its not gdm. Tough pulling and seeing dead system sucks, fortunately thanks to Guix I could boot into a working revision yey
<kiwi_guixer>That warning about debugfs match-error is supr confusing to new users
<kiwi_guixer>Ok time to reboot, wish me luck. Thank you for excellent suggestions. Cheers
<davidl>janneke: thx for fixing the childhurd!
<kiwi_guixer>No luck, time to figure out how to downgrade xorg
<gnutec>I thought that Delphi died.
<kiwi_guixer>There is no 1.20.7 defined only
<civodul>i got "TLS error in procedure 'handshake': An unexpected TLS packet was received" from the substituter while talking to ci.guix
<civodul>i wonder if it's a problem on that network or if it's on our side
<civodul>but i don't see anything in the nginx logs on berlin
<civodul>is anyone else experiencing this today?
<kiwi_guixer>Ok, downgrading xorg looks super advance, is there a way to set a previous working revision as default boot?
<rekado>kiwi_guixer: you can delete the broken system generation
<civodul>or run "guix system roll-back" if you know the previous one was ok
<kiwi_guixer>From boot menu or by some guix system reconfigure invocation?
<kiwi_guixer>Can I take a working commit and reconfigure to it? Does guix system reconfigure take revisions?
<kiwi_guixer>I knew I should take btrfs snapshot that way I could easily revert to a working system.
<kiwi_guixer>I already generated dozen of broken generations but manual of giox system does not say how to roolback to a specific generation
<kiwi_guixer>guix system reconfigure does not take commit too
<rekado>kiwi_guixer: you can use “guix time-machine” to go to any commit you want
<rekado>and then pass the reconfigure command to it.
<kiwi_guixer>Can I guix pull --commit=workingrevision and then reconfigure?
<rekado>yeah, that would work too
<rekado>but if you don’t want this to be a full downgrade of your guix, then you can use “guix time-machine” to affect only the “guix system” command.
<kiwi_guixer>I did kostek@kos ~$ guix time-machine --commit=c03875b0361f114634caeb54935fe37a9b7b05af
<kiwi_guixer>kostek@kos ~$ sudo guix system reconfigure /etc/config.scm
<kiwi_guixer>That warning about debugfs match error is still there but I did not have it in my working generation
<rekado>I meant: “sudo su -”, then “guix time-machine --commit=… -- system reconfigure /etc/config.scm
<rekado>‘guix time-machine’ has no side effect
<rekado>it affects only the command it is told to run
<kiwi_guixer>Root now updates channel Authenticating channel 'guix', commits 9edb3f6 to c03875b (11 553 new commits)
<kiwi_guixer>I though I should not pull as root, dunno
<kiwi_guixer>Ok downgrade should fix the issue, I will wait with pull another 6 months.
<kiwi_guixer>BTW it is depressing that libre laptops now will stat get regressions, I assume you work on modern less libre laptops if that regression is barely known.
*kiwi_guixer reboots
<rekado>my laptop doesn’t have an ATI card
<janneke>davidl: yw, thanks for reporting it
<kiwi_guixer>I am booted into old working generation uname -a
<kiwi_guixer>Linux kos 5.4.51-gnu #1 SMP 1 x86_64 GNU/Linux
<kiwi_guixer>But guix system describe shows GNU with Linux-Libre 5.10.7
<kiwi_guixer>I noticed because I time machined into recent broken guix
<kiwi_guixer>How to show guix system describe *currently* run/loaded system?
<kiwi_guixer>Is that by design? To show guix system describe from not currently booted generation?
<civodul>kiwi_guixer: ah good point, it shows the "current" generation, but that's not necessarily the booted generation
<civodul>maybe that's confusing
<kiwi_guixer>Current as in the newest.
<kiwi_guixer>I thought it shows what I run. That's not clear from man page.
<kiwi_guixer>This time guix asked me to allow downgrades so maybe I will 'fix' default boot this time.
<bavier[m]>llnl peeps not really sure if they want to join :)
<kiwi_guixer>Folks I am lost. Is there a way to set /var/guix/profiles/system-1-link as default boot?
<kiwi_guixer>I know that generation works and time machine doesnt work for me, I also cannot find, for sure, the revision of that system profile, because guix describe shows only latest revisions.
<kiwi_guixer>Maybe I remove all other symlinks and garbage collect, then if gc regenerates boot entry that should only leave one working generations.
<bavier[m]>gc doesn't regenerate grub menus
*bavier[m] hasn't followed the conversation closely
<kiwi_guixer>guix system list-generations shows commits too. Maybe that could put time machine on track
<kiwi_guixer>Then I will try to bisect which bump broke Guix System here
<zimoun>civodul: draft for hint when command-line options typo in #45893 :-)
<civodul>zimoun: woohoo, awesome!
<civodul>i'll take a look hopefully later today
<Aurora_v_kosmose>Is there some equivalent on guix of needrestart?
***fever is now known as Guest31059
<Guest31059>I'm struggling to write a config.scm for SDDM that uses my xorg config, when I try and put xorg-configuration into sddm-configuration it throws "error: service 'xorg-server' provided more than once"
<jonsger>Guest31059: I think you need to remove the gdm service
<Guest31059>Ah thanks, I tried doing that but it's possible I messed up there. Let me send a snippet.
<Guest31059>(services (cons*
<Guest31059> (service openssh-service-type)
<Guest31059> (service mpd-service-type
<Guest31059> (mpd-configuration
<Guest31059> (music-dir "/mnt/home/fever/Music")))
<Guest31059> (service sddm-service-type (sddm-configuration (auto-login-user "fever")))
<Guest31059> (set-xorg-configuration (xorg-configuration (keyboard-layout keyboard-layout)))
<Guest31059> (remove (lambda (service)
<Guest31059> (eq? (service-kind service) gdm-service-type))
<Guest31059> %desktop-services)))
<Aurora_v_kosmose>You might want to use the paste site in the topic line.
<cbaines>does anyone know how to generate a client certificate to access Zabbix on berlin?
<civodul>cbaines: i just use "ssh -L" to set up a tunnel and connect that way :-)
<cbaines>ah, OK, let me try that...
<Aurora_v_kosmose>e.g.: ssh -L 8080:localhost:80 alice@server
<cbaines>civodul, are you sidestepping NGinx when doing that? Given it looks like NGinx is providing the Zabbix frontend, I'm not sure if the need for a client certificate can be avoided through SSH
<civodul>cbaines: hmm i was thinking of the Cuirass admin interface, but i guess that should also work here?
<cbaines>civodul, unless I've missed that Zabbix is available not through Nginx, I think you still need a certificate
<cbaines>it's reachable without SSH
<mzbm>hello everyone, i'm trying to switcht my workflow to free (as in freedom ;)) software. I'm used to using jetbrains intellij but thats obviously proprietary. What is a good IDE that comes close to IntelliJ? Is the majority here using emacs?
<cbaines>mzbm, are you looking specifically for something to use for working on Guix?
<mzbm>no, more in the direction of go programming
<cbaines>I'd try asking on #go-nuts perhaps then, I think that's a more relevant channel
<mzbm>ok, sorry if this was the wrong channel here..
<Aurora_v_kosmose>mzbm: Pretty much any editor which supports LSP is a valid candidate these days.
<Aurora_v_kosmose>Language-specific support is less of a priority than it was a decade ago.
<jgart[m]>Ohh this is awesome!
<jgart[m]>We need this service in guix system
<Aurora_v_kosmose>Ah yes, there's a few service frontends like that. Such as Nitter for twitter.
<jgart[m]>I tried nitter a few days ago. It's nice too.
<mroh>jgart: imho, invidious is a big burden to support, because it needs to be updated very frequently to function (often every few days, because yt changes something...) Also, it's written in crystal which we don't have (yet)...
<jgart[m]>If only we had a guile, racket, common lisp, or/and chicken port of invidious... :) We still need a racket-build-system.
<Sharlatan>If I pack buildapp, to which module I need to bind it ?
<roptat>I'd go with (gnu packages lisp)
<Sharlatan>It's tricky to pack pgloader it has all build wizardy inside Makefile depending on Quicklisp and Buildapp :)
<Sharlatan>I've packed all dependencies now time for the main app...
<luis-felipe>There is an old patch to add MyPaint package (, but a[nother] MyPaint package was added last year. Maybe the issue should be closed?
<roptat>yeah, unless they're different packages with the same name?
<roptat>looks like the same. Do you want to close it yourself?
<luis-felipe>roptat: I'd prefer if someone else closes it :)
<luis-felipe>But yes, it looks like the same package.
<roptat>ok, let me do it :)
<luis-felipe>I feel kinda bad for Yoshinori...
<apteryx>when a build produces many wheels; are they supposed to all be installed?
<roptat>yeah, same :/
<apteryx>oops, question was for #python
<apteryx>luis-felipe: it should! I think I made a review for MyPaint, there were still things to address but the conversation came to a halt IIRC.
<luis-felipe>roptat: Thanks.
<lfam>luis-felipe: I'm enjoying my Guix apparel :)
<luis-felipe>lfam: Oh, great to hear that :)
*roptat is learning more English words ^^'
<roptat>what's the difference between apparel and clothing?
<cbaines>I can spell the latter :)
<lfam>roptat: Same thing, but saying "I'm enjoying my Guix clothing" is not idiomatic
<roptat>I see, I'll try to remember it :)
<lfam>Instead, you might say "I'm enjoying my Guix shirts", if you didn't say apparel
<lfam>It's not too bad :)
<lfam>I consider it "European English" ;)
<Aurora_v_kosmose>Apparel appears to be a more generic term.
<Aurora_v_kosmose>Esp if considering its etymology.
<civodul>got my Guix t-shirt as well!
<luis-felipe>Thanks for the support :)
<lfam>It's so great to have beautiful and eye-catching graphics for Guix
<lfam>So, thank you as well!
<cbaines>I was trying to remember if I ordered one, then I remembered it's literally hanging in my cupboard!
<PotentialUser-38>Hi and thanks for gnu guix. The only available first language of Libreoffice in preferences is US English. It is not possible to add another one. What's will I have do to getting it localized? Thanks in advance
<PotentialUser-38>Excuse my bad English..
<roptat>PotentialUser-38, you can speak any other language here too (although less people might be able to help)
<roptat>but your English is pretty good :)
<roptat>PotentialUser-38, I think you need to install a language pack, as an addon
<roptat>I don't think they're packaged as part of guix
<PotentialUser-38>Yeah, I didn't detect anything like locales in the gnu guix package list.
<Aurora_v_kosmose>There's nothing strictly preventing them from being made as "multiple outputs" for those packages, but it hasn't been done so far.
<PotentialUser-38>Where could I get such an addon - from
<jonsger>does already provide zstd substitutes?
<roptat>PotentialUser-38, tools -> extension manager
<roptat>there's a link "get more extensions online"
<PotentialUser-38>Thank U both for your help I'll try it!
<roptat>PotentialUser-38, actually, looking for French for instance, I don't find anything interesting there
<civodul>jonsger: nope! i'm not sure what to do
<civodul>for the time being, we'd have to do zstd in addition to gzip + lzip
<civodul>which is going to be quite resource-intensive for the server
<civodul>plus, few users support zstd, and those who do for now would still fetch lzip most of the time
<civodul>because currently the only criterion is size
<roptat>ok, I think this is what we need to do:
<roptat>so languages are added at build-time only, so there's nothing a user can do if we only include English :/
<civodul>roptat: FWIW, a while back i started packaging LO translations:
<roptat>oh, cool!
<civodul>then i "ran out of time" and forgot about it
<civodul>so there's still some work to be done, but i think i had gone quite far already
<civodul>if you or anyone wants to start from that, feel free!
<civodul>+ libreoffice-locale-directory.patch:
<roptat>ah, thanks
<rekado>I always associated apparel with clothing that’s sold in stores.
<lfam>That's a good observation rekado. I wouldn't usually call the clothes in my closet "apparel"
<rekado>where the commercial part is worth mention
<lfam>It does have a commercial connotation
<PotentialUser-38>Thank you all, I'll just hold out with Epiphany and Ungoogled Chromium. Fortunately Abiword is available located but Gnu Icecat is also limited to US English.
*vagrantc is in the awkward position of wearing a guix t-shirt under a guix hoodie and not having run guix once this entire year
<vagrantc>don't know if i'll get the chance to try building guix 1.2 with guile-2.2 on debian to actually get it into the next release...
<vagrantc>only have a couple more weeks to even consider it
<zimoun>vagrantc: by entire year, you mean fifteen days? Because on Julian calendar, today it is the Janurary, 2nd 2021 ;-)
<vagrantc>zimoun: yes, about 15 days ... :)
<vagrantc>though in my heart, the year begins at solstice :)
<lfam>So, since the staging branch has gotten bogged down in CI problems, the ungrafting branch has also stalled
<lfam>It's rather frustrating
<lfam>Should we re-try the ungrafting branch separately, so that we can merge it soon? Does it matter?
<jeko>hey hey hey !
<lfam>The mesa test failure on i686-linux can't be reproduced upstream:
<lfam>Howdy jeko
<jeko>A reader of the Guile Hacker Handbook told me there is a default .guile on Guix System. Is it also created when installing Guile on foreign distro ?
<lfam>I don't have that file on my Guix / Debian system
<lfam>Or rather, I don't have one from Guix
<zimoun>I created this file by hand after installing Guile.
<jeko>on my guix system i have it !
<cbaines>lfam, I guess if merging branches is dependent on good substitute availability on, that'll require waiting until that's the case
<lfam>cbaines: True, but I don't think it's a matter of waiting, at least for the staging branch. The staging branch requires actual work, whereas the ungrafting branch should not
<lfam>It seems like we should cancel this round of staging
<lfam>It doesn't seem like people are interesting in working on it
<jeko>Thanks for your feedback lfam and zimoun
<lfam>But, we should skip ungrafting just because staging won't happen
<lfam>I mean, we shouldn't skip ungrafting
<lfam>I might also do an alsa-lib updates branch, since that fixes a serious bug
<lfam>We can extract the new commits from the existing staging branch and cherry-pick them to a new branch, and set it aside for a few months
<cbaines>I've been building ungrafting on the QA setup I'm working on, and it's "all" built. There's a non-0 number of breakages listed here, some will be false positives, but I'm unsure how many
<lfam>Right, and it's really useful to see, but it has build on in order to count as "ready", since that is where people get substitutes
<lfam>We also need to decide what to do about niche / obsolete platforms like i686 and armhf, since they are in poor shape and are not getting much attention from Guix hackers
<cbaines>I realise that, I'm more referring to the ungrafing branch not requiring work theory
<lfam>My bad
<cbaines>In principle, removing grafts can introduce build changes, and cause build failures
<lfam>Yes, and now that I think about it, I remember there being new failures on ungrafting
<Aurora_v_kosmose>Aren't most SBCs still armhf?
<Aurora_v_kosmose>Ah, niche, nvm.
<lfam>Most SBCs in the last few years are aarch64
<lfam>There is still a lot of 32-bit ARM hardware being produced but it will not be for products that can be used with Guix. For example, automotive embedded systems or locked-down TV boxes
<Aurora_v_kosmose>So stuff like beagleblack moved to aarch64 now?
<lfam>They moved to RISC-V
<cbaines>anyway, I'm still pretty excited about the future of QA and substitute distribution stuff, I still have quite a few exciting ideas
<cbaines>on that note, I'm going to go back to hacking on the Guix Build Coordinator :)
<Aurora_v_kosmose>lfam: owo That's new
<lfam>Aurora_v_kosmose: The previous beagle device (X-15) is the probably the only 32-bit ARM SBC worth using with Guix, but it's a poor value compared to aarch64, unless you need 32-bit for some reason
<Aurora_v_kosmose>Hmm, I wonder, does any distro support RISC-V atm?
<lfam>I think they are creating the hardware to drive software development
<lfam>If you want one, you have to explain what software you will develop on it
<vagrantc>there is a semi-official port of debian for riscv64, and i believe similar for fedora, and at least one of the embedded distros supports riscv
<jgart[m]><nij "jgart: That's usually how you se"> nij: This is what I'm using to jump to other code in a given source tree
<Aurora_v_kosmose>Huh. I suppose if I were a good low-level dev I might try porting SBCL
<lfam>cbaines: Your worse on QA / CI is the future of Guix :)
<lfam>I mean, your work!
<lfam>Damn autocorrect
<vagrantc> hasn' *moved* to risc-v, it's also supporting a new risc-v board
<lfam>Okay, but are they going to keep creating new 32-bit ARM boards? It seems unlikely
<nij>I have a working guile. While module should I load in for it to understand
<jgart[m]>nij: modified from here
<nij>(channel (name 'variant-packages) (url "") ?
<nij>jgart[m]: what?
<vagrantc>lfam: they might ... they might start doing some 64-bit arm as well
<lfam>What is the use case for 32-bit ARM now? When you can pay a fraction of the price for more capable 64-bit ARM
<lfam>Anyways, I also ranted about this on the mailing list
<lfam>We are supporting these platforms but I can't perceive that anybody is using them
<jgart[m]>nij: I'm just sharing how I integrate ripgrep into my editor to do recursive searching in a source tree. Continued from yesterday's convo
<lfam>(armhf and i686, that is)
<vagrantc>lfam: it's a reasonable question :)
<nij>jgart[m]: Oh oh! Thanks :D
<Aurora_v_kosmose>lfam: Presumably systems you can't replace easily due to widescale deployment.
<roptat>nij, (guix channels) I think
<lfam>At least, if people are not going to help maintain the support, they should let us know they are using it
<nij>roptat: lemme try
<jgart[m]>I'm using vis
<lfam>Aurora_v_kosmose: Right, but what does that have to do with Guix?
<vagrantc>i wonder if something like debian's popularity-contest package would work for guix? opt-in reporting about what you have installed, etc.
<roptat>I use an armhf board
<Aurora_v_kosmose>lfam: Well, in this case Guix is probably too young for it to have yet been used in such a way, but I can't certify that.
<roptat>it's painful not to have substitutes :/
<lfam>I agree Aurora_v_kosmose. But I don't think we will gain users on armhf in the future. Guix is just a poor fit for these devices, which lack CPU power or fast and reliable storage
<Aurora_v_kosmose>I used to build on a qemu VM for my stuff. The board I had died though so I retired it.
<lfam>armhf embedded deployments will likely never get software updates and, if they do, they will be ultra-optimized binary diffs, in order to extend the storage lifetime
<vagrantc>i had hopes i could get guix running reliably on my veyron-speedy ... but it's never been reliable enough ... really quite close, though
<lfam>What was unreliable about it vagrantc?
<lfam>roptat: I can imagine it's very painful!
<vagrantc>lfam: never managed to get a linux-libre kernel newer than 5.5 working on it
<vagrantc>and it's still just a bit old
<roptat>running "guix pull" for days... fun ^^
<lfam>And there's no 32-bit ARM server that we can use to build the substitutes
<Aurora_v_kosmose>Isn't emulation an option?
<nij>roptat: sigh.
<nij>I pulled the guix repo from savannah.
<nij>Add it to the load path.
<roptat>nij, try "guix repl" instead
<nij>But (use-modules (guix channels)) doesn't work.
<lfam>Yes, emulation is an option. But it means that the build farm will spend most of its time doing that
<srk>emulation is possible but too slow, armv7 on aarch64 virtualization is possible as well but there are corner cases where it fails
<nij>roptat: OH!
<nij>What's the difference?!?!
<roptat>guix repl launches guile with its modules available in its load path
<srk>there's tons of armv7 hw out there, NixOS has similar issues supporting it
<lfam>Anyways, there needs to be a critical mass of people-power to support these platforms, so that they are usable. It's a question of the chicken and the egg
<nij>what is "its"?
<roptat>sorry, it launches guile with guix's load path
<roptat>guix's modules in guile's load path
<srk>is cross-compilation to armv7 and similar viable with guix?
<roptat>so you should be able to ",use (guix channels)" in there
<nij>roptat: so I don't have to pull codes from savannah?
<roptat>it'll use the pre-compiled modules from guix
<nij>roptat: You won't believe me that I have wasted 8hrs on this issue yesterday.
<roptat>ouch :/
<nij>any chance for me to check the current load-path?
<nij>OH %load-path
<roptat>lfam, do you know of a good hardware we could use as part of the build farm? I'm seriously considering buying something to help the build farm
<lfam>roptat: For 32-bit ARM?
<roptat>unless we plan to drop it?
<Sharlatan>Hi folks
<lfam>I don't think we plan to drop it (I'm the only person suggesting that).
<lfam>I would research the BeagleBoard X-15 (we already have a couple). I think it's the only hardware available for retail purchase with what counts as high-performance armv7 CPUs and reasonable storage (eSATA)
<lfam>There could be some other devices available — I haven't searched exhaustively
<srk>I'm running armv7l Novena laptop (was running previously as part of build farm as well), odroid-xu4 is decent but no SATA
<Sharlatan>Could someone suggest packing stratagi for Buildapp, please?
<srk>there were some bananaPIs that had SATA but limited to like 10Mb/s due to (USB?) controller used, way faster to use ethernet and nbd/nfs
<lfam>The Novena uses Cortex-A9, but at this time I would only consider Cortex-A15 or Cortex-A17
<srk>yeah, imx6q is little dated
<lfam>We have (had?) some Novenas in the build farm. They were good for their time but are not really fast enough to be worth the high price anymore
<rekado>looks like the Overdrive is no longer sold any more. Otherwise we may have bought more.
<lfam>Sharlatan: We have an asdf-build-system. Maybe you could try that?
<lfam>rekado: For 64-bit there is the Honeycomb LX2K, which is sold at retail and has a good reputation. I don't know if it requires any nonfree firmware or anything like that
<srk>lfam: nice, I think it (Novena) reached EOL last year, still not fully supported by Linux :)
<lfam>That's a shame
<srk>LX2K does require binary blobs (at least for memory controller iirc0
<lfam>It would be good to have a citation, since it is by far the best and only option available for purchase
<srk>don't take my word for granted, I've only played with it for few weeks like a year ago
<lfam>I feel like we shoot ourselves in the foot if we avoid hardware because the DDR PHY firmware is not free
<lfam>Is it a case where the "good option" doesn't even use firmware but instead a ROM?
<lfam>My impression is that DDR firmware is always closed source and a trade secret
<nij>roptat: What if one day I want to contribute to the source repo?
<roptat>nij, you'll need the checkout, and to build it
<nij>Do I at least need to learn autotools for that? as the code directly pulled from savannah isn't complete.
<roptat>nij, there's a section in the documentation, basically, run "./bootstrap" then "./configure --localstatedir=/var" and "make"
<srk>lfam: anyway, you would hit issues when building in armv7 qemu on aarch64
<Aurora_v_kosmose>lfam: Right. It puts an annoying reverse-engineering burdne on support. But mostly meant ROM vs firmware?
<lfam>Aurora_v_kosmose: The GNU stance is that ROM is not software, because it cannot be updated, so it doesn't matter if it has a free license or not. Whereas upgradeable firmware must be free
<lfam>So, a memory controller based on non-upgradeable firmware is okay, whereas the upgradeable option is considered bad
<Aurora_v_kosmose>Isn't the difference only the existence of in-place runtime binary patching infrastructure?
<lfam>I don't quite understand your question
<Aurora_v_kosmose>The difference between upgradable firmware and a ROM is simply that you don't have to reflash it manually to upgrade it with firmware, no?
<nij>roptat: I got stuck while configuring. It requires "Guile-Git".
<lfam>That is a difference, yes. I don't see the significance of it
<Aurora_v_kosmose>lfam: I mean, isn't that the only difference?
<roptat>nij, oh, you can build in an environment: guix environment guix
<Aurora_v_kosmose>Teh fact you can easily upgrade it instead of with effort?
<roptat>that will give you all the dependencies you need
<lfam>It's not a matter of effort
<roptat>from a foreign distro, add --pure
<lfam>But rather of possibility
<roptat>(for the configure stage, then drop the --pure)
<lfam>If the firmware can be upgraded or changed, then GNU wants it to be freely licensed. If it is "baked in" at the factory and cannot be changed, that is considered okay
<Sharlatan>@lfam I could not find how to pass some lisp code to ASDF buld, there is #:lisp keyword but it's not docuemnted.
<Aurora_v_kosmose>Ah, so write-once required, okay.
<Aurora_v_kosmose>"It's a piece of hardware".
<lfam>A line has to be drawn somewhere. Personally I think it's a mistake
<Aurora_v_kosmose>It seems to be slowly disappearing these days.
<lfam>I think it's based on ignorance of how computers are designed and created, and how these parts (PHYs) work
<Sharlatan>Curtly patchin Makfile to exclude push (pwd) pard couse it's failing on bulid stage, tehre is an option to have binary by loading 'buildapp::build-buildapp'
<Aurora_v_kosmose>lfam: oh?
<lfam>It's also the reason that we can't ship CPU microcode
<lfam>But, GNU is about software, not hardware. So it's the way it is
<Aurora_v_kosmose>What about the ignorance bit?
<joshuaBPMan>lfam:  I totally agree that free software requires no proprietary software...
<nij>roptat: It is running T_T Wish you were here yesterday.
<lfam>I think there is a lack of understanding of how much software is running in a computer. It seems like every part has its own CPU and its own OS, and they are all totally closed. This is considered okay, but if it's possible to upgrade one of those OSs, that is considered to be going too far...
<joshuaBPMan>however, I run a T400, and without the updated CPU microcode, my laptop just craps out on me once a week.  Typically under heavy load.
<joshuaBPMan>I actually mentioned it in the #libreboot channel.
<joshuaBPMan>Leah Rowe started chatting to me and told me that the problem was that I was not using the updated microcide.
<Aurora_v_kosmose>lfam: Yeah. It seems weird that the existence of a write fuse is sufficient to make a difference.
<lfam>Of course, the CPUs are full of bugs that must be fixed in microcode
<joshuaBPMan>I then found out that uses librebooted machines with the updated microscode.  Essentially, you don't want your web server crashing under heavy load.
<lfam>Aurora_v_kosmose: The problem seems intractable, and GNU had to choose a line, in order to be able to make judgements. I think the placement of this line may have become less good over time
<lfam>joshuaBPMan: Right, many of us exercise freedom zero (the freedom to use the software as we see fit) to use things without a free license
<Aurora_v_kosmose>Personally I'd have drawn it at the component's ability to interfere with others' software.
<lfam>It's a hard problem
<lfam>I think the presentation "Impedance Matching Expectations Between RISC-V and the Open Hardware Community" by Bunnie Huang (Novena designer) is a good exploration of the problems
<lfam>And of how far we have to go
<Aurora_v_kosmose>I'll be taking a look at that, thanks
<lfam>I guess I feel that the free software movement seems to think that we have free implementations of everything we need, so that it's reasonable to only use free software and free firmware. But I think we are still quite far from the goal
<lfam>I think that by ignoring what is missing we are actually slowing down our progress
<joshuaBPMan>lfam: I'm aware of SSDs having proprietary code running...what else it there?
<lfam>Almost every bit of hardware has a little operating system at this point
<joshuaBPMan>actually this probably answers my own question:
<joshuaBPMan>I'll watch that talk that you mentioned.  Thanks
<lfam>"Computers" are really made of many different computers
<lfam>The CPU is really just another component
<lfam>The talk by Bunnie is really good :) I recommend it for everyone
<Aurora_v_kosmose>A GPU is a full secondary computer capable of DMA. With better specs than my early computers to boot. With a buggy IOMMU, it could basically take the machine over.
<Rovanion>When I do a `guix environment --pure` backspace stops removing characters in my bash prompt/readline. Which package do I need in order to get it working again?
<rekado>‘--pure’ unsets environment variables, so perhaps you need to restore the TERM variable.
<nij>On machines of different types (eg i686, x86_64), can I expect the binaries are built exactly the same, meaning that they have the same sequence of 0 and 1s?
<Aurora_v_kosmose>Fat binaries are a thing, but nearly no one uses those.
<lfam>What do you mean nij?
<rekado>nij: binaries for different architectures will not be identical
<rekado>re firmware: FWIW, I only cared about being able to use Linux libre when picking the servers for the build farm. You can’t get the purchasing department to buy old servers.
<Aurora_v_kosmose>That's spike up the costs a lot, having to buy new.
<nij>lfam: I'm just curious about what "reproducible" really means in this context.
<nij>rekado: But for same architectures, will they be identical?
<Aurora_v_kosmose>nij: If the package builds reproducibly, yes.
<lfam>The answer is maybe
<lfam>rekado: Understood
<Aurora_v_kosmose>Some packages, among which a lot of Lisp ones, don't currently.
<nij>Aurora_v_kosmose: so do guix volunteers have to package one for each architecture ?
<rekado>Aurora_v_kosmose: research institutes and organizations like them aren’t really concerned with cost as long as it fits in the budget and doesn’t steal resources from other things that need to fit in the budget.
<Aurora_v_kosmose>nij: Not usually no, Guix checks the checksums of inputs, but for outputs, you can challenge or do multiple build runs and find differences.
<rekado>a budget that isn’t maxed out will be adjusted to fit the reduced demand
<Aurora_v_kosmose>For those packages which build reproducibly, a challenge will find an indentical package after building it.
<rekado>so there’s an incentive to spend
<Aurora_v_kosmose>(Unless the buidler actually is compromised)
<Aurora_v_kosmose>rekado: It's always seemed an awfully wasteful way to manage budget.
<Aurora_v_kosmose>It essentially incentivizes bloating costs as much as possible just in case.
<Sharlatan>How to get the abs path to the source during the build phase?
<lfam>On the other hand, using old hardware will result in lower performance. It's worth it to buy new
<lfam>Plus, you will waste money on salaries dealing with broken things in the old hardware
<Aurora_v_kosmose>Sometimes yeah. Though a 20x as expensive machine won't necessarily (or usually) perform 20x as well.
<Aurora_v_kosmose>(Which is usually the difference between the very same machine new & used)
<lfam>The time spent acquiring dozens of identical old hardware is not worth the money saved, especially since you won't get a support contract for it
<lfam>I buy used computers for personal use, but for a high-performance computing clusters, you have to buy new
<lfam>I work in a different industry that also is technology-focused, and nobody buys used equipment. It's always more cost-effective to buy new and negotiate a volume discount
<Aurora_v_kosmose>Guix has support contracts for Librebooted machines?
<Sharlatan>While patching Makefile before build phase I need to provide full path to asd file, which symbol holds the abs path to the current source?
<Aurora_v_kosmose>lfam: I see.
<lfam>But I buy my personal equipment used on ebay :)
<Aurora_v_kosmose>Yeah, that or local businesses.
<rekado>Aurora_v_kosmose: yes, budgeting in institutes is … weird. In some years people had to justify their department budgets and felt compelled to order an office load of books.
<rekado>budgets are inflexible, so you get punished for being frugal
<Aurora_v_kosmose>I wonder if the management overhead would be justified by possible savings if budgets were made flexible instead. Or if it'd simply fail to work out.
<Rovanion>rekado: Thank you, that did the trick!
<rekado>Aurora_v_kosmose: budgets rarely have just *one* source, so making them flexible would involve a *lot* of work with an unmanageably large number of parties. It’s one of those things that probably cannot be fixed as long as we all behave like humans.
*rekado stops talking about budgets
<Aurora_v_kosmose>ah I see
<sss2>hi all