IRC channel logs

<Tecjor[m]>Hola, siempre despues que presento un fallo electrico el NTPD no sincroniza correctamente mi hora del sistema, haciendo que falle mi navegador Icecat.

<apteryx>mirai: hm, I thought mpc was available from $mpd/bin/mpc

<apteryx>it's not

<mirai>Tecjor[m]: is ntp-service-type configured

<mirai>apteryx: it isn't but it's not needed

<mirai>I'm thinking on issuing commands via socket

<mirai>since the protocol is text-like

<mirai>and documented

<mirai>sidenote, liliana's idea on using shepherd socket / endpoints would be terrific

<mirai>we could connect to it straight away since we'd know the value from the field is really something “connectable”

<apteryx>OK! I had forgotten to set my new auto-update? field to #t

<apteryx>hopefully that also fixes that automatically

<mirai>is it as maybe-boolean?

<apteryx>(cause the update to be init)

<Tecjor[m]>mirai: yo configuro fecha y hora manualmente lo del NTPD esta por defecto en mi sistema.

<apteryx>nope, I've defaulted it to #f

<apteryx>the same as mpd does

<mirai>use a define-maybe so the directive isn't serialized

<apteryx>i was on the fence about it

<apteryx>it's nice to match upstream behavior, but it sucks to have the user have to refer to another doc to know what's the actual default

<mirai>that way it obeys how most of the config is worked

<apteryx>OK

<mirai>upstream mpd.conf is actually just an “example”, since it doesn't automatically write the file

<mirai>and having it as define-maybe ensures that should upstream switch defaults (that are set at runtime) we don't end up shipping obsolete values

<apteryx>I mean, maybe-boolean doesn't tell you what is the default; so you are forced to 'man mpd.conf'

<apteryx>right, that's the benefit

<apteryx>but they probably won't change that on a whim (it'd break many people expectations)

<mirai>heh, I've spotted a few values in our services that are long obsolete

<mirai>but no one checks those right? if the service is still working...

<mirai>:)

<mirai>I've been hesitating about sending a 1-line patch for correcting our avahi service defaults

<mirai>been deferring it until I give that service a define-configuration + … refactoring

<mirai>Tecjor[m]: ntp is using the incorrect time in your system because the tzdata package in guix needs to be updated

<Tecjor[m]>mirai: Justo antes del fallo electrico ya habia realizado completamente Guix pull y presento el inconveniente o como debo actualizar ?

<mirai>Tecjor[m]: it's a guix “bug”, we're shipping version 2022a right now when we should be using 2023c

<mirai>I think there's nothing that can be done about it short of updating the package, you might want to send an email to bug-guix mailing list about this

<Tecjor[m]>mirai: Gracias asi sera, por que es algo que se repite mucho.

<mirai>np

<Tecjor[m]><mirai> "Tecjor: ntp is using the..." <- No sabia de ese paquete ya lo busque y lo instalare a ver que tal.

<ChocolettePalett>Does GNU/Guix system has many bugs?

<mirai>if you look for them

<mirai>or if you count the issues in bug-guix

<apteryx>mirai: ah!

<apteryx>mirai: I think #31769 is fixed, right?

<ChocolettePalett>Are there more bugs than in e.g. Gentoo or some other mainstream distro?

<mirai>apteryx: hmmm... I'd say that technically “yes”, since that issue is mostly due to pulseaudio daemon being launched by a different user (it was launched by "mpd" since it was hardcoded)

<apteryx>by bc30a9ee889fb1b81c43a7f94ea4c2b95a15db75

<mirai>the “new” mpd service is intended to be used “standalone” i.e. pulseaudio daemon isn't shared

<mirai>now, idk how that plays out if you use mpd and an interactive user, will they fight for control of the soundcards?

<mirai>I'm using it with only network outputs and a pulseaudio rtp setup (it's a headless machine)

<mirai>bc30a9ee889fb1b81c43a7f94ea4c2b95a15db75 was needed for pulseaudio to work otherwise the launched pa daemon has no configuration

<mirai>and quits immediately

<mirai>ChocolettePalett: I don't think anyone has done some quantitative study on the matter

<mirai>apteryx: I'd say its a close/“wontfix” since the correct solution is a home shepherd service for this case

<mirai>no amount of hacking will make mpd-service-type play nice with multiple pa-daemons all contesting for the same output or multiple users vying for pa-daemon control

<mirai>well, short of using a systemwide pa-daemon but it's a very bad idea security-wise

<podiki[m]>woop! took like 2-3 hours but built up to poetry in python after updating pyproject-build-system packages

<apteryx>podiki[m]: neat!

<apteryx>mirai: I see.

<apteryx>do we have such a service yet?

<apteryx>(home mpd service)

<podiki[m]>apteryx: surprisingly nothing along the way failed to build, but I didn't build all 6k dependents

<bjc>if i have a test that's failing due to SIGABRT, how do i enable core dumps, and where would i find them?

<mirai>apteryx: afaik no

<apteryx>mirai: I've checked lilyp's patches for the mpd service; it looks cool, but I'm not sure about exposing the endpoints stuff

<apteryx>I'd rather it be encapsulated like for our other services

<mirai>the argument for endpoints iiuc was for shepherd systemd constructor

<mirai>was about*

<mirai>in that the user shouldn't care how the service is constructed

<mirai>simply give it an 'endpoint' and things would sort themselves out

<apteryx>right; and 'endpoint' being tied to the lower level jargon, an 'address' and 'port' would be best, I think

<apteryx>hm, my crude 'mpc update' action hangs

<apteryx>probably needs some environment variable to find the mpd daemon's socket?

<apteryx>and 'sudo -E -u mpd mpc update' says: MPD error: No database

<mirai>and without sudo?

<mirai>it shouldn't require sudo

<mirai>MPD_HOST=path-to-socket-or-ip mpc update

<mirai>hmmm… I'm tempted to add a covert endpoint here strictly for shepherd to use

<mirai>but the logic is somewhat subtle regarding the presence of bind_to_address directives <https://mpd.readthedocs.io/en/latest/user.html#listeners>

<apteryx>hm, now that we do not have core-updates, where are the core-updates going to be applied? haha

<AwesomeAdam54321>what if a package update/addition affects multiple team branches? Will it just be split?

<mirai>apteryx: 🙂🙂🙂🙂🙂🙂🙂

<apteryx>mirai: same thing for 'mpc update' as my user

<apteryx>I don't get how I can get this to work ^^'

<apteryx>but you do have it working, right?

<AwesomeAdam54321>nvm

<mirai>yes, I'm using it right now

<apteryx>under which user?

<apteryx>mpd?

<mirai>just my regular user

<mirai>I've been using guix shell mpc to issue updates manually

<mirai>when needed

<apteryx>guix shell mpd-mpc?

<mirai>yes

<apteryx>ah, you run it as your user, OK

<apteryx>but via the system service?

<mirai>mpc works by sending commands via socket

<mirai>to the daemon which is a system service

<apteryx>ah right, so it's just a client as any other, such as the M.A.L.P. thing I have on my phone.

<mirai>yep

<apteryx>it seems that the default setup is broken (as user mpd), at least i don't know how to make it work

<apteryx>I'll try it as my user again

<mirai>by broken, you mean mpc update hangs?

<mirai>what do the logs say?

<apteryx>I mean I can't get it to list any music, it just throws an error about Apr 25 21:11 : exception: No database

<apteryx>amd 'mpc update' doesn't find it

<ChocolettePalett>Did you create the database file and all the other corresponding paths?

<apteryx>err, wrong, it says the same: MPD error: No database

<apteryx>ChocolettePalett: no; I thought the 'update' request would have mpd create its own database

<ChocolettePalett>Idk about GNU/Guix, but on Gentoo I had to touch a new empty file for database, socket and make directorites for other stuff

<mirai>It “works for me™”, see <https://paste.centos.org/view/4682069b>

<mirai>let me see what I've got in my config

<apteryx>the db_file is not specified in the config

<apteryx>and 'man mpd.conf' doesn't say where it defaults to

<mirai>can you try putting '(database (mpd-plugin (plugin "simple")

<mirai> (extra-options '((path . "/var/lib/mpd/database")

<mirai> (cache-directory . "/var/cache/mpd")))))'

<mirai>oops

<mirai>change the paths to suit your taste?

<mirai>but I am using these

<mirai>does it work if you manually configure this?

<mirai>'man mpd.conf' is missing a lot of what actually can be put in that file

<mirai>I'm suspecting that either db-file or a database plugin must be configured (but not both) for it to work

<ChocolettePalett>Isn't mpd.conf populated with a lot of comments and examples?

<ChocolettePalett>For me an example config looks like this (not sure if it's applicable to GNU/Guix):

<ChocolettePalett> https://github.com/andrewrk/mpd/blob/master/doc/mpdconf.example

<mirai> https://github.com/MusicPlayerDaemon/MPD/blob/master/doc/mpdconf.example

<mirai>> This setting defaults to disabled which will allow

<mirai># MPD to accept files over ipc socket (using file:// protocol) or streaming

<mirai># files over an accepted protocol.

<apteryx>that's weirdly worded

<apteryx>it still needs a db, even if it's disabled

<apteryx>it seems to default to ~/.cache/mpd/db

<apteryx>since 'mpd' has no HOME, that must be failing

<apteryx>in news, for 0.23.11: simple: move default database to ~/.cache/mpd/db from ~/.cache/mpd.db

<apteryx>is 'simple' the simple plugin?

<mirai>simple database plugin

<mirai>it's not the same as a db_file iiuc

<mirai>but is a database nonetheless

<apteryx>why do I need a plugin to configure the main database

<apteryx>ACTION 's head spins

<mirai>you can use different databases

<mirai>well, I only used the simple one

<apteryx>thanks for the config, I guess it'd work; I'm still trying to figure out the most minimal thing to do to get it to work, so that if I find it I can arrange to have the service default to use that

<ChocolettePalett>AFAIK, it defaults to some weird directory in /var/... when launched as mpd user (as a system service) so I don't think $HOME is a problem

<apteryx>I'll try it after I've run out of things that look simpler to try :-)

<mirai>it uses xdg variables if available

<mirai>but setting HOME in constructor? if you can figure out the home-directory from the user-account used, sure

<apteryx>"If a music directory is configured, one database plugin is used" (doc/user.rst)

<apteryx>so I guess it uses an implicit simple database plugin by default

<ChocolettePalett>As far as I understood, you can either configure database using db_file or plugin. I usually set up db_file and everything works fine, I don't remember tackling any plugins

<mirai>apteryx: can you set the logging level to “verbose”

<mirai>and see what it spews out

<apteryx>ACTION tries

<apteryx>at least mpd has rw access to /var/lib/mpd/

<apteryx>looks like that: https://paste.debian.net/1278487/

<apteryx>seems it now works? what the...

<apteryx>ah no: Apr 25 21:53 : exception: No database

<apteryx>when I tried accessing it from that MALP android client

<apteryx>this is what it says to 'mpc update': https://paste.debian.net/1278488/

<apteryx>nevermind, 'mpc update' also returns 'MPD error: No database'

<apteryx>eh

<apteryx>sudo -u mpd ls -al /data/maxim/Musique -> Permission denied ^^'

<apteryx>OK, that's fixed with 'chmod -R 777 /data/maxim/Musique', but the error persists.

<apteryx>mirai: works with your database field addition

<apteryx>so the default paths, whatever they are (I couldn't figure it out), are wrong

<apteryx>(simply creating /var/cache/mpd was not enough)

<apteryx>thanks for all the help... let's find a solution to make the service work out of the box

<apteryx>the 'update' action now works too

<apteryx>one problem I now have is that audio doesn't seem to be produced

<ChocolettePalett>You have to specify outputs I guess

<ChocolettePalett>Oh nvm you already did

<apteryx>I'm trying now with this 6.2 trick detailed here: https://wiki.archlinux.org/title/Music_Player_Daemon/Tips_and_tricks#Local_(with_separate_mpd_user)

<apteryx>"Local (with separate mpd user)"

<apteryx>mirai: you said you were using your user; but what do you use for the group?

<apteryx>I think it's important to get onto the same pulseaudio session

<apteryx>weird, it started working after 'pacmd list-modules'

<apteryx>but it's not super deterministic; it seems to depend on how the pulseaudio session got started, and whether something is playing outside mpd

<apteryx>(I've got it to work using my own user)

<mirai>I've left the group as default but it's there if there's some need for access to group owned files

<apteryx>do you see mpd in pavucontrol?

<apteryx>I don't, even if it runs as my user

<mirai>I'll take a careful look at your findings after I wake up

<mirai>re pavucontrol, you shouldn't since the pa-daemon is launched for mpd only

<apteryx>OK

<apteryx>talking about sleeping, I shoud do that :-)

<apteryx>o/

<apteryx>we need to fix the mixer-type to a maybe field

<apteryx>the "none" doesn't work for playback; according to the doc https://mpd.readthedocs.io/en/latest/mpd.conf.5.html#optional-audio-output-parameters, "By default, the hardware mixer is used for devices which support it, and none for the others."

<apteryx>some notes: https://paste.debian.net/1278498/

<unmatched-paren>morning guix :)

<PurpleSym>podiki: But pyproject-hooks itself does not use python-wheel as far as I see. So it shouldn’t be propagated.

<PurpleSym>If a build system (like flit, setuptools, …) uses it, then that should propagated python-wheel instead.

<jpoiret>bjc: you need to write a filename to /proc/sys/kernel/core_pattern

<cnx>how do i use udevil? it wants suid bit set and just installing it (either in system manifest or guix shell) doesn't do that

<unmatched-paren>cnx: OPERATING-SYSTEM has a SETUID-PROGRAMS field

<cnx>ah, thanks!

<unmatched-paren>try this:

<unmatched-paren>(setuid-programs (cons* (setuid-program (program (file-append udevil "/bin/udevil-program"))) %setuid-programs))

<unmatched-paren>obviously you'd want to replace "/bin/udevil-program" with whatever string is appropriate :)

<cnx>thanks (that's verbose lol

<abrenon>hi guix

<minima>o/

<AwesomeAdam54321>o/

<smmm>hey all, I am writing a service to manage a daemon and I am having some trouble actually using it in my system config: https://paste.debian.net/1278502/ when I use the guile repl to load the path, things like (define s ...) (service? s) do return true, but `guix system search -L ....` comes up empty, any ideas?

<ngz>Hello. I get a "Throw to key `gnutls-not-available' with args `("(gnutls) module not available")" error when trying to use mumi from a Guix worktree. Are there additional steps required to make use of this tool?

<andreas-e>Hello, Guix!

<abrenon>o/ andreas-e

<abrenon>smmm: what do you actually put in place of those "...." as value for -L ? a directory containing services/tailscale.scm which content is what you uploaded, right ?

<smmm>correct abrenon , I usually "./guix/services" which contains the service, or just "./guix"

<smmm>usually set*

<smmm>and running guile with the same -L allows me to (use-modules (services tailscale) etc, so I imagine that part is okay

<abrenon>ok, yeah should be (although I'm surprised -L ./guix/services works, but ./guix should so fine)

<abrenon>wait, they're not public !

<smmm>ah! :)

<abrenon>I've never defined a system service, but when you want a package to show up, you have to use (define-public …), not just (define …)

<smmm>let me give it a go

<smmm>a follow up question: how do these service definitions work? https://github.com/guix-mirror/guix/blob/master/gnu/services/auditd.scm

<abrenon>ok so apparently I'm wrong in my assumption about define-public… : (

<smmm>:' (

<abrenon>sorry I really thought I could help, but I'll let someone who actually knows these things answer your questions to avoid adding more confusion and I'll read eagerly because I'm interested in the subject too

<smmm> https://github.com/guix-mirror/guix/blob/2bf96f2d9e1f1415acf96c9a4620e2314af955bb/gnu.scm#L40-L62 seems like, for the official channel at least, it may be making them public using this

<jpoiret>ngz: probably it needs guile-gnutls as a propagated input

<jpoiret>smmm: for a service to show up in `guix system search` it needs to be in a specific directory

<jpoiret>but you should still be able to use it

<ngz>jpoiret: A naive "guix shell guile-gnutls mumi -- mumi search whatever" throws the same :(

<abrenon>jpoiret: which directory ? shouldn't -L still work ? is it only for packages and not services ?

<jpoiret>ngz: you probbaly need to include guile as well for the search path to work

<ngz>jpoiret: duh, you're right! Thanks. So, it works, but not out of the box.

<jpoiret>ngz: it's probably because of the gnutls binding now being standalone, instead of being included in gnutls

<jpoiret>abrenon: I don't think there's any extensibility mechanism for it right now

<jpoiret>at least judging from the code

<jpoiret>so only gnu/services/ and gnu/system/

<jpoiret>there's no way for guix to guess what directory the services are in, just from -L

<abrenon>oh I see. and so I suppose the module should accordingly be named (gnu services tailscale)

<smmm>ah, so it should be fine to use in my config, will give it a go thanks jpoiret

<jpoiret>not necessarily, it just needs to be in that directory somewhere (and publicly exported)

<jpoiret>it's the same for packages, but that one is actually extensible iirc

<ngz>jpoiret: OK. So, as you suggest, mumi package definition just needs an additional guile-gnutls in its inputs, right?

<jpoiret>ngz: yes

<jpoiret>it seems that for packages, the whole channel is scanned, so it's not really extensible per se. That could probably also be done for services then

<jonsger>what is the gexp equivalent to this statement: https://paste.debian.net/plain/1278507

<jpoiret>jonsger: the append part?

<jpoiret>you can just do (modify-inputs (package-native-inputs xxx) (prepend (origin ...)))

<jpoiret>although the origin will be hard to use there. What/how are you using the origin?

<jonsger>jpoiret: nope, thats documented. Its about the origin thing

<jpoiret>ah, so it's rather a old-style vs. new-style input thing, right?

<jpoiret>you can actually embed the origin in the phases if they're using gexps

<jpoiret>seems like the simpler solution to me

<nutcase[m]> 'rofi' does not start, because it can't set locale ("Failed to set locale."). Similar to this post: https://www.reddit.com/r/i3wm/comments/zpy9g6/rofi_failed_to_set_locale/ my LC_ALL is unset and 'rofi' starts after setting LC_ALL manually. Why is LC_ALL not set and how can I set it?

<Gremlin8483>how customizable is guix? on a scale of linux from scratch / gentoo / debian / rhel

<Gremlin8483>like can you install and build anything from source from outside repos and still have a maintainable system

<alethkit>Gremlin8483: It's between Gentoo and LFS

<alethkit>Is the Guix derivation format and store compatible with Nix, or has it diverged?

<Gremlin8483>so its has a bit more package installation flexbility than gentoo? im installing that one right now

<civodul>alethkit: hi! the .drv format is the same, the store is the same, the protocol has some differences

<Gremlin8483>gentoo locks the system into its profiles, so i wonder if guix does something like that

<civodul>people, thoughts on what to put in news for core-updates? https://issues.guix.gnu.org/63073

<alethkit>civodul: Thanks! I'm looking into what the tvix project is doing to see if cross-collaboration is possible

<civodul>what's tvix?

<alethkit> https://tvix.dev/

<alethkit>They're rewriting Nix so that it's more composable

<alethkit>Uh, that's not actually the README: https://code.tvl.fyi/about/tvix

<alethkit>Details about the components are here: https://code.tvl.fyi/about/tvix/docs/components.md

<Gremlin8483>is the guix daemon a requirement for using guix?

<alethkit>Gremlin8483: I believe so, yes

<alethkit>FWIW, you can run Guix the package manager on top of any distro

<janneke>civodul: i pushed a draft post

<Gremlin8483>thanks for the info

<Gremlin8483>maybe i can just kill the daemon manually when its not doing anything

<alethkit>Gremlin8483: Sure, but why

<alethkit>are you trying to deploy guix to an embedded device?

<Gremlin8483>nah just like lightweight

<alethkit>Not worth the bother, IMO

<Gremlin8483>appreciate the advice

<alethkit>Good luck if you want to figure it out, though?

<alethkit>s/?/!

<alethkit>daemonless guix/nix would be interesting to see

<Gremlin8483>its not really a priority, just curious about it

<Gremlin8483>i mean it would be like gentoo you would be manually running build commands all the time

<Gremlin8483>i can see why a daemon was made

<Gremlin8483>still for a server or minimal build the less the better

<andreas-e>Well, if there is nothing to do, the daemon does nothing... It is mainly an interface to the store. I think it is a daemon because it needs root rights and then interacts with different users.

<jpoiret>it technically would be possible to run the daemon as user in a PID+mount namespace, on demand

<jpoiret>Gremlin8483: you can basically tweak Guix in exactly the way you want, but you'll have to rebuild all packages that change

<jpoiret>compared to gentoo, where modifying one package in the dependency graph doesn't cause all dependents to be rebuilt (I believe)

<jpoiret>as long as the ABI is preserved

<andreas-e>I suppose that if you do not put the packages into /gnu/store, but into $HOME/store, you could just run the daemon as user?

<andreas-e>Ah, there is also the chroot for building.

<jpoiret>andreas-e: you'd be unabled to use substitutes this way

<jpoiret>hence the mount namespace

<andreas-e>Yes, without substitutes, of course.

<jpoiret>with a mount namespace, you would be able to still use /gnu/store as the store path

<ulfvonbelow>I know how to specify dependencies between filesystems and mapped devices, but how do I specify dependencies between mapped devices and other mapped devices?

<ulfvonbelow>e.g. lvm on luks on mdraid

<jpoiret>civodul: so, looking at the git history, a lot of basic tools have been updated, but I'm not sure if it's enough to warrant a comment in the core-updates news

<jpoiret>i guess there's the update of wayland-protocols that is quite noteworthy

<Guest26>hello. Since recently when I log into gnome xorg on guix system I get the gnome error page asking me to log out. No matter what generation I roll back to. May this be because of the core-updates merge?

<jpoiret>i'm not seeing any exciting changes

<Guest26>I stripped down the home and system configuration as much as possible. Doesn't help

<jpoiret>Guest26: does it give any other information?

<jpoiret>ulfvonbelow: we don't have this yet

<jpoiret>you have to order the list properly

<ulfvonbelow>ah, but it does map them in-order?

<jpoiret>yes

<jpoiret>at least, for those needed on boot

<jpoiret>for others i'm not so sure

<Guest26>jpoiret: it's just the white page stating: an error occured which can not be solved by the system. please log out and try again

<jpoiret>gotta love gnome error messages

<bjc>jpoiret: thanks. looks like no core files are being left behind. dunno why it didn't occur to me today to just run the failing tests in gdb, though =)

<jpoiret>i wonder how this could be debugged

<Guest26>applications seem to work normally, i just can't do anything with them because the error screen pops back in as soon as i leave the "shell view"

<jpoiret>wdym shell view?

<jpoiret>i'm not super familiar with GNOME

<jpoiret>do "dmesg" or "/var/log/debug" contain any lines that could be related to this error?

<Guest26>in GNOME when you press the super key the desktop gets smaller and you can select apps amd stuff. thats what i mean with "shell view". when you press the super key again you get the desktop fullscreen again. but in my case instead of the desktop i get a blank page with the error message

<Guest26>would be helpful if someone who already uses gnome (wayland) could try xorg and report if they get the same error or if its just an error on my side

<Guest26>i'm not seeing any obvious errors in /var/log/debug or dmesg afaict

<rekado>Guest26: works for me with Xorg.

<rekado>I’m not on latest “master” though

<rekado>you may have logs in /var/lib/gdm/.*

<jpoiret>not sure that user sessions are logged there

<Guest26>thanks, i will look there

<rekado>right, gnome-shell should log somewhere to the user’s home directory

<Guest26>i got gnome xorg working again by removing all of the packages from my profile (the profile you get by guix install something)

<jpoiret>did you update that profile after reconfiguring?

<Guest26>no i didn't. then that was probably the issue

<panosalevro>hey all, does anyone else get conflicting entries for zlib?

<zamfofex>panosalevro: What led to it? And have you tried running ‘guix upgrade’?

<panosalevro>zamfofex: it occurs after `guix upgrade`

<zamfofex>Ah. Which packages do you have installed? It’s probably a mismatched propagated input of two specific packages you have installed.

<panosalevro>guix says `glib` and `network-manager`

<zamfofex>Are both of those important to have installed for you?

<panosalevro>hmm I use network-manager for internet access. idk what would happen if I uninstalled glib?

<zamfofex>Is glib directly installed to your profile, or is it a depenency of a different package you have installed?

<zamfofex>Note that you can’t really cause packages to malfunction by “uninstalling glib” in Guix. Usually you’d have it installed to your profile if you want to e.g. write GTK applications and compile them.

<panosalevro>let me check which package causes the problem and will get back to you. thanks!

<panosalevro>removing `network-manager` seems to have fixed the issue

<panosalevro>nvm.

<civodul>is Savannah down? or just sleepy?

<rekado>savannah’s web page loads for me

<rekado>git.savannah.gnu.org also loads for me

<rekado>and I can browse the cgit interface

<civodul>hmm!

<civodul>maybe it's just SSH access

<civodul>i have 'git pull' stuck

<rekado>git fetch works for me

<civodul>then maybe PEBKAC

<civodul>vcs2.savannah.gnu.o:ssh SYN_SENT 14990/ssh

<civodul>that's over IPv6

<andreas-e>"guix pull" was really slow for me yesterday, with around 50kB/s. I noticed it because I had deleted the checkout cache.

<civodul>it eventually succeeded for me, but connection establishment took a minute or so

<PotentialUser-6>Has anyone got guix with linux working on a new-ish Dell XPS 13? I can't figure out how to get the sound working. I think I need to add `sof-firmware`, which I've added to my config.scm and reconfigured...but I think I might be doing something wrong. The only potentially helpful error I can see in dmesg is: "unknown sof_ext_man header type 3 size

<PotentialUser-6>0x30"

<PotentialUser-6>Does anyone have an example of how they've set up sof-firmware in their config.scm?

<rekado>PotentialUser-6: better ask in #nonguix, they might know

<PotentialUser-6>Thanks rekado!

<civodul>hey ho! https://guix.gnu.org/en/blog/2023/the-full-source-bootstrap-building-from-source-all-the-way-down/

<rekado>yay!

<rekado>typo: “This [+is] a major milestone”

<civodul>ACTION noticed a couple others, will push

<alethkit>woohoo!

<zamfofex>civodul: janneke: Congrats! 😮 🎉 🎉

<apteryx>jpoiret: hm, not much problems when using my own user in the end

<apteryx>(for mpd)

<apteryx>I get away with just specifying user and music-directory

<apteryx>it seems the actual problem with using mpd is that the card is not correctly set to the profile it should be in, per my /etc/pulse/default.pa.d/audigy.pa config

<apteryx>and then its pulseaudio process complains that "Sink alsa_output.pci-0000_01_01.0.analog-surround-40 does not exist"

<apteryx>*mpd user

<apteryx>not sure why that's so, but it's a pulseaudio issue rather than a mpd one

<attila_lendvai>civodul, another issue: the "[remarkably small change]" link is not formatted in the final render, as visible at the link you pasted above

<attila_lendvai>nah, scratch that! not anymore. i had to SHIFT + CTRL + R the page.

<civodul>attila_lendvai: should be fixed now!

<apteryx>civodul, janneke: interesting! thanks for the hard work to reducing the binary bootstrap

<dthompson>woo what great news re: bootstrapping

<dthompson>congrats janneke

<bjc>finally found the issue with the failing sssd tests: the samba upgrade. reverting its input to samba/pinned has it fixed

<bjc>not a satisfying answer, but one none-the-less

<minima>i'm also very grateful for the bootstrappability work - thanks janneke and everyone involved

<civodul>apteryx: my contribution is limited to reviewing the blog post :-)

<civodul>but yeah, it's amazing news!

<apteryx>I'm not clear on the 25 MiB Guile 2.0 driver though; I'll have to read carefully

<abrenon>I don't understand it at all, I don't understand the focus on hex0 if there are other binaries required by the build

<abrenon>also, why 357 bytes ? following the hex0-seed link to https://github.com/oriansj/bootstrap-seeds/blob/master/POSIX/x86/hex0-seed on page https://guix.gnu.org/en/blog/2023/the-full-source-bootstrap-building-from-source-all-the-way-down/ I can download a 256 bytes binary

<alethkit>abrenon: The driver is technically speaking orthogonal to the actual sources required

<abrenon>and a commit from last July mentions the reduction to 256 bytes https://github.com/oriansj/bootstrap-seeds/commit/12c7930b45c8bd2585bb8c3171ccf37e43487ab3

<abrenon>alethkit: as in the data/program duality ?

<podiki[m]>PurpleSym: re: pyproject-hooks and setuptools; right agreed. I left it as a propagated input to avoid me changing however many packages that used it via pep517; but I also didn't do the actual deprecation in my patches. let's see how it looks first and I'll get some review, and if so can go through with that change and hopefully not too many packages needing setuptools

<mekeor[m]>wow, this bootstrap news is HUGE

<mekeor[m]>even still after reading about the 25MiB guile binary

<podiki[m]>PurpleSym: actually, I will remove the setuptools propagated-input and at least see how bad it is trying to build to yubikey-manager; I'll have to see about the deprecation for pep517, but I've been holding on to this series for too long already

<attila_lendvai>the warning "imported module (guix build utils) overrides core binding `delete'" is very pervasive... it would be nice to have a solution for it that doesn't involve every package writing #:use-module ((guix build utils) #:hide (delete))

<jpoiret>isn't #:replace for exactly this?

<jpoiret>changing it would cause a world rebuild though teehee

<attila_lendvai>i'm not sure i understand guile modules enough to answer that. it's discussed here: https://issues.guix.gnu.org/26805

<bjc>no wonder ghc takes so long to build: >6500 tests, running one at a time, and they take tens of seconds

<bjc>or, at least, a lot of them do

<andreas-e>Yes, I wondered whether they could be made parallel, but it is just a shell script and not an automatically parallel autotools based "make check".

<unmatched-paren>afternoon, guix :)

<bjc>o/ (

<Guest19>hello

<andreas-e>janneke, this is exciting, thanks for the blog post! Like abrenon I did not get the differente between 256 and 357.

<andreas-e>Apart from it being 101 and anyway small :)

<abrenon>: )

<alethkit>Does guix already fall under the intensional model?

<alethkit>Dostra's PhD thesis mentions that multiple outputs for a derivation is only possible with intensional equality

<jpoiret>alethkit: where is that mentioned?

<jpoiret>both nix and guix follow the intensional model of dolstra's phd thesis

<jpoiret>ah no, i'm wrong on this one, sorry

<jpoiret>it's the extensional model *

<jpoiret>from what I can see, eelco's argument that it's impossible to build some outputs if the other ones are in the store and ungc'able can be remedied by using chroots and mount namesaces

<mekeor[m]>regarding bootstrapping, what's the problem with gcc 4.8.0 introducing c++ as build requirement? do versions≤4.8.0 not ship with a c++ compiler?

<jpoiret>mekeor[m]: gcc>=4.8.0 need c++ to be compiled

<mekeor[m]>jpoiret : yes but whats the problem with that?

<jpoiret>and thus you can't build gcc>=4.8.0 with just M2-planet

<jpoiret>it's not a blocker for bootstrapping a whole system of course, but it's just one more step

<jpoiret>just like how you can bootstrap some languages in one step and then you have rust

<janneke>mekeor[m]: what c++ compiler would you build gcc-4.8.0 with?

<mekeor[m]>janneke: g++? but thats why i was asking if gcc≤4.8.0 does not ship with a g++

<janneke>ACTION is enjoying all the praise :)

<mekeor[m]>jpoiret: okay, i see

<mekeor[m]>personally, i feel like this bootstrap attempt within the guix community is one of the very few things in recent software development that brings hope...

<mekeor[m]>would it make sense to directly and dedicatedly share this blog post in the mailing-lists of gcc and glibc? because they are explicitly criticized

<janneke>of course gcc-4.8.0 comes with g++, but in _source_

<janneke>you need a _binary c++ compiler_ to compile that first g++

<mekeor[m]>yeah, i understand that making the path of bootstrapping gcc4.8.0 longer is tedious, but i guess it's not a fundamental issue. a fundamental issue, for me, would be not be able to bootstrap at all...

<janneke>no, it's fundamental

<jpoiret>mekeor[m]: like the GHC one, where you can't really find a suitable version

<janneke>bootstrapping gcc-4.8.0 is not tedious, it's impossible

<vagrantc>well, you'd just have to implement a c++ compiler in mes!

<vagrantc>"just" :)

<janneke>vagrantc: true!

<janneke>ACTION takes patches :)

<mekeor[m]>jpoiret: exactly...

<mekeor[m]>janneke: i thought bootstrapping gcc@4.7.x is possible and it ships with a g++ that can compile gcc@4.8.0?

<janneke>luckily, we can bootstrap gcc-2.95.3 and hopefully gcc-4.6.4 in a year's time

<vagrantc>janneke: you mean directly to gcc-4.6.4 ? skipping some intermediary steps?

<janneke>vagrantc: we'd like to drop gcc-2.95.3

<jpoiret>aha, got a reply from mailman@gnu.org about the "via bug-guix" issue! they don't know either, but they're looking into it :)

<janneke>so tcc -> gcc-4.6.4

<janneke>mekeor[m]: yes, that's the issue; we can "build" gcc-4.8.0 if we have a c++ compiler, but we cannot bootstrap it

<janneke>that means we need to maintain gcc-4.6 indefinately or lose the bootstrap path

<janneke>it would have been so great if the people who added c++ into gcc and then left to do clang had been outvoted

<janneke>we might have been able to bootstrap gcc-12 directly from tcc

<mekeor[m]>i thought bootstrapping means "to have a bootstrap path", not "being able to build with mes"

<janneke>well, terminology is not strict

<mekeor[m]>jpoiret: regarding rust, let's hope gcc-rs will help some day

<janneke>maybe your question was misread

<mekeor[m]>janneke: alright, i guess we all agree then :)

<jpoiret>can gcc 11 be built with gcc 4.6?

<janneke>no idea :)

<jpoiret>I would expect the path to halt at some other versions along the road

<andreas-e>I think a long path makes it more complicated also with new architectures. You need to implement/backport them for every step.

<indieterminacy[m>Over in the room #general-forgefed:matrix.batsense.net I get the feeling the developers may need to ensure that issue-tracking and bug-tracking are not treated as one and the same.

<indieterminacy[m>Any opinions?

<janneke>we have (two?) intermediate steps anyway

<mekeor[m]>indieterminacy: sorr, i dont understand how this relates to guix

<janneke>andreas-e: exactly, every extra step is a burden, and esp. relying on ancient, non-supported software is less than great

<mekeor[m]>*y

<janneke>it would be so nice if we could bootstrap the latest gcc, and possibly even file bootstrap bugs against them if the need arises

<mekeor[m]>ACTION nods

<jpoiret>andreas-e: right, I guess the riscv story would've been easier (as well as others)

<Mari[m]>Do you guys install packages by using your config.scm or by using guix package -i

<Mari[m]>What's the recommended way?

<vagrantc>ACTION wonders how much insanity it would be to rip the c++ dependency out of modern gcc

<mekeor[m]>janneke: are you already in touch with the gcc team?

<vagrantc>might be worth it in the long run

<jpoiret>Mari[m]: guix package for user packages, guix system for what's strictly necessary

<Mari[m]>jpoiret: Ahhh ok

<jpoiret>ie. setuid programs and basic stuff that is system-specific I would say

<indieterminacy[m>mekeor[m]: ah, well Im just used to hearing things within the Guix community from time to time.

<indieterminacy[m>I was citing Guix manual wrt to this in that room, Im trying not to spam.

<indieterminacy[m>Consider it polling (if thats not offensive), just trying to ensure that package-managers are represented in opinion by developers.

<andreas-e>It is so evident that relying on anything but C is a mistake for gcc... One really wonders how this decision has been taken.

<Mari[m]>So only config.scm for system level stuff?

<unmatched-paren>Mari[m]: I use ``guix home'' for packages

<mekeor[m]>Mari: i dont think either one is recommended. i'd say it's a matter of taste. you can always export a manifest, afaik...

<unmatched-paren> https://guix.gnu.org/manual/devel/en/html_node/Home-Configuration.html

<Mari[m]>Ahhh ok alright

<jpoiret>you can do as you wish though! just note that package additions to guix system require a reconfigure, which is more costly

<mekeor[m]>ACTION uses guix-package--i

<jpoiret>I use `guix package -m some-manifest.scm`

<Mari[m]>Ive been doing guix package -i for user level stuff and the config.scm for system level stuff

<mekeor[m]>Mari: that perfect, i do the same!

<andreas-e>Mari[m]: I add packages I need for every user to the system. Such as vim :) And nss-certs for a reason I have forgotten.

<janneke>mekeor[m]: no, we're not in touch with gcc or glibc teams

<janneke>i'm not sure that makes much sense before we can bootstrap gcc-4.6.4 with tcc

<andreas-e>I agree with valgrind. Bad decisions can be reversed :) But it takes work.

<jpoiret>andreas-e: vagrant you mean? that powerpc valgrind issue seems to have taken a toll on you!

<andreas-e>vagrantc, sorry; my working on valgrind this morning has had effects on my brain, I think.

<mekeor[m]>:D

<andreas-e>jpoiret: Exactly! Time for a little vacation :)

<vagrantc>andreas-e: i've been called worse

<janneke>hehe

<person5>hi. i can't install guix system because of gpu drivers. however, i have

<person5>another gpu that is integrated into the cpu and that should work. how do

<person5> i tell guix to use the other gpu?

<bjc>you may have an option in the bios to specify the primary gpu

<person5>will check, thanks

<person5>however, when i liveboot pureOS it automatically chooses the right one and screen gets displayed flawlessly

<mekeor[m]>vagrantc, valgrind, vacation... https://www.youtube.com/watch?v=wKn1R6fekk4&t=39

<bjc>person5: i think there are kernel options you can set, as well, but i don't know them off the top of my head

<mekeor[m]>hm, sorry, vagrantc, i didn't think about my action. i don't like making fun of names/nicks...

<person5>okay

<jpoiret>persona5: you can use modprobe.blacklist=... to disable some drivers manually

<persona5>jpoiret: when i try to install linux-libre isn't that automatically as if the proprietary drivers are blacklisted? i think the problem is that guix wants to use that device nevertheless, instead of considering the other gpu

<jpoiret>persona5: some drivers are still included because they might have some completely free support for some gpus but not all of them

<jpoiret>amd comes to mind I think

<bjc>there are poor quality open source nvidia ones too, iirc

<bjc>noveau? i think it's called

<soygirl>do wonder how long until noveau is usable considering nvidia did open source their drivers

<soygirl>so theoretically it should be able to improve much faster, but that's still a lot of work

<jpoiret>soygirl: nvidia did not "open source" their drivers

<bjc>iirc their "open source" drivers still have blobs

<lilyp>they """open sourced""" their blobs

<persona5>ah okay. yes i use amd

<lilyp>same as amd

<jpoiret>they really won the PR battle here unfortunately

<soygirl>ah right. well now they just need to write the blobs :D

<bjc>everyone loves it when a giant corporation pretends to do the right thing

<jpoiret>the blobs are signed now iirc

<jpoiret>you could also say that it's the same for cpu microcode :)

<soygirl>but yeah i pray every day for nvidia to fall due to their hubris

<soygirl>they're really cruising for it

<apteryx>jpoiret: OK, I've found something new: Apr 26 13:48:45 localhost pulseaudio[1736]: [pulseaudio] module-udev-detect.c: /dev/snd/controlC1 is accessible: no, by adding (log-level . debug) to the puseaudio's daemon.conf

<apteryx>I've added the mpd user to the 'audio' supplementary-group, but that doesn't change that

<soygirl>i hate being stuck between the options "works but blobs" (nvidia), "doesn't work but open source" (amd), and "lol" (other (intel))

<lilyp>didn't i just say that amd has the same blob shit?

<unmatched-paren>A rock and a hard place and another hard place.

<lilyp>intel is the least bad option using linux-libre – unless you're trying to be a pro gamer, in which case stop and get some help

<lilyp>in fact get some help regardless of whether you want to use linux-libre

<soygirl>i like playing video games and i like framerates so yeah the help i got is just using nvidia's drivers

<bjc>unfortunately, it's bad for other reasons. i can't use freecad on guix because of how slow it is

<vagrantc>ACTION knows a handful of the people who worked at intel for the libre graphics stack but most of them have since moved elsewhere and it shows

<bjc>i've done simple modelling, but for anything else it's just too painful

<unmatched-paren>it seems like even the latest intel cards refuse to work without blobs

<vagrantc>exactly

<bjc>yeah, it's igpu only

<bjc>which is not great

<apteryx>I wonder if Matrox has free drivers: https://video.matrox.com/en/products/graphics-cards/m-series/m9120-pcie-x16

<bjc>is.. is matrox still around?

<apteryx>they used to compete in the mainstream before Nvidia bought all their employees

<bjc>i still have one of their cards. from 1996. in my bebox

<ieure>bjc, Yes, but they're not a player in the consumer space anymore.

<ieure>I had some of their cards ages ago, pre 3D era. Worked fine, but nothing special.

<bjc>they had hardware video decoding, and fast blitting, as i recall

<unmatched-paren>unless some miracle occurs and $COMPANY's executives magically obtain souls i honestly don't see how linux-libre is going to be survive in the long term, given the three have all abandoned open drivers for their latest gpus

<soygirl>when i tried using beos on my old computer in the 90s and it didn't support my network card but everything else worked :( im still sad about that

<unmatched-paren>it will eventually become unusable on anything remotely modern...

<attila_lendvai>soygirl, hardcore users bought a supported network card... :)

<bjc>i only ever used it on the bebox. i understand why they ported it to intel, but by that point it was already dead

<attila_lendvai>ACTION was a beos beta tester for years

<bjc>there's still haiku

<soygirl>i was a kid and couldn't afford it nor did i have a real use case to run beos lol

<ieure>BeTa?

<unmatched-paren>with the network card issue you can at least "just" buy a working card, but that's not possible for GPUs of course... depressing situation :(

<lilyp>well, there's always the sliver of hope that risc v will magically fix things

<unmatched-paren>actually, doesn't that apple silicon project aim to create completely reverse-engineered video drivers for apple silicon?

<lilyp>keyword is reverse-engineered

<lilyp>so you get nouveau basically

<unmatched-paren>true...

<bjc>riscv is built around the idea of proprietary extensions. i have no hope for it

<unmatched-paren>don't riscv computers useregular gpus anyway?

<unmatched-paren>s/useregular/use regular/

<unmatched-paren> https://drewdevault.com/2022/01/15/2022-01-15-The-RISC-V-experience.html <- this seems to suggest as much; they used an ARM GPU with their riscv board

<apteryx>I've just asked Matrox if they had free drivers without proprietary firmware, we'll see ;-)

<lilyp>probably maybe, there's an off chance that some arcane driver written in assembly won't work

<apteryx>if we all started to ask around perhaps they'd get the cue

<gnucode>fun fact of the day, I just installed guix on chimera linux on a talos II. And it pretty much works.

<andreas-e>This is powerpc, no? Good to hear. When I look at our number of packages that do not build, I am surprised!

<jpoiret>unmatched-paren: if they used signed blobs it's not going to happen either :(

<jpoiret>gnucode: with latest master?

<gnucode>jpoiret: I did the guix-install.sh

<gnucode>I shuold probably do guix pull

<person5>do you think Purism will be the solution for free hardware longterm?

<attila_lendvai>quilt fails to build on master due to one failing test: [44] $ quilt patches -- /dev/null dev/null null --- -- failed

<Guest3>When I give a package a native-input and run it with "./pre-inst-env guix shell some-pkg -- some-pkg" and that works, does that mean that native-input is enough or could it still be that e.g. propagated-input is necessary?

<rekado>if you have that package installed then this test doesn’t allow you to make a decision either way

<rekado>a native input is one that must run on the host architecture at build time

<rekado>a propagated input is one that must be installed into the same profile as the target package

<jpoiret>Guest3: in general it depends on what kind of input it is

<attila_lendvai>ACTION gives up for today with the hope that the opensource fairies will fix this overnight, and substitute availability will be better, too

<Guest3>so there is no easy way to check if i make the right decision? i'm packaging a gtk app and for me it works having glib:bin as native-input only, but that could be because i have that already installed from some other package

<jpoiret>cbaines: seems like the data.qa website is being extensively crawled by search engines. Searching for "gnu quilt" on duckduckgo returned 3 hits

<jpoiret>Guest3: you can test your package out by using `shell -C`, although it might break more than expected

<jpoiret>what are you using glib:bin for?

<Guest3>dialect, a translator

<jpoiret>I mean, what is this specific input used for?

<Guest3>i don't know. found out by trial-and-error that it is needed to build the app

<jpoiret>what are you using as build-system?

<Guest3>meson-build-system

<jpoiret>Guest3: did you use #:glib-or-gtk? #t in arguments?

<Guest3>yup

<jpoiret>ah, I thought it would be somehow included by default

<jpoiret>no, glib:bin is great in native-inputs

<jpoiret>it's not used at runtime

<jpoiret>the binaries inside of it are used to create glib schemas, resource stuff and whatnot

<Guest3>okay, thank you

<apteryx>jpoiret: found the fix to run as mpd, thans to garisson in #pulseaudio on the oftc server

<apteryx>mpd changes the group itself, and ignores supplementary groups

<apteryx>the group must be 'audio'

<apteryx>i'll check if that's a not a bug in mpd

<podiki[m]>gajim users, it builds locally, patch incoming (for python-k5tests and python-gssapi)

<carmenshea[m]>Hello Guix. Updated my system last night, Guix running Sway. Alacritty crashes now with the following error [wayland-client error] Attempted to dispatch unknown opcode 0 for wl_shm, aborting. Aborted. I've done some digging and found that this was occurring a couple of years ago (2020 - 2021), as noted in the alacritty issues #4206, comment indicates that this was a wayland.xml issue. At the moment everything else seems okay.

<bjc>carmenshea[m]: yes, it's an incompatibility with alacritty 0.9 and the current version of sway. alacritty 0.12 fixes it, but unfortunately requires *a lot* of dependency updates, so is being worked on separately

<bjc>hopefully it will be updated soon

<carmenshea[m]>bjc: Great! Thanks for the reply, I shall use Foot for the meantime...it seems to work okay.

<jlicht>hey guix! Happy "1 day since core-updates existed" to all \o/

<bjc>carmenshea[m]: exactly what i'm doing when i'm not just using emacs :)

<apteryx>does shepherd preserve supplementary groups when lowering privilege (switching the user/group) ?

<apteryx>civodul: hello! perhaps a question for you? ^ :-)

<civodul>apteryx: hi! if you pass #:supplementary-groups to make-forkexec-constructor & co., the child process is going to run with those

<apteryx>oh!

<apteryx>didn't know it had that argument, than you

<apteryx>*thank you

<civodul>yw! :-)

<civodul>it appeared in 0.9.0 so it's not that old

<apteryx>jpoiret: the configuration of mpd is confusing me, because a group appears both in the 'user' object provided as well as in the 'group' one, which are distinct configuration fields.

<apteryx>I think we want the 'group' field to always prevail, making the group of <user-account> unimportant?

IRC channel logs

2023-04-26.log