IRC channel logs


back to list of logs

<vivien>TODO Updates remaining for gnome-team: gssdp, gtk+, gtkmm-3, gtksourceview-4, gupnp, gvfs, json-glib, libgee, libgweather, libnotify, merge rest and rest-next, libsoup, mm-common, mutter, pangomm@2.46, python-pyatspi, rygel, simple-scan, sushi, vte, xdg-desktop-portal-gnome, yelp, yelp-tools, yelp-xsl
<ieure>If I have GuixSD set up on a machine how I like, what's the easiest way to get the same setup on another machine? `guix system image -t iso9660 /etc/config.scm' and boot it with that?
<vivien>Still quite a lot before we have GNOME 44.6.
<vivien>Oh and I forgot gnome-tour, but it’s rust so I don’t know how to do that.
<Kolev>vivien, what features does GNOME 44 have?
<Kolev>Does it have gestures?
<vivien>It has a bunch of them, although I guess 42 had many too.
<Kolev>vivien, it doesn't have the gesture where you swipe three fingers up to get the Overview.
<Kolev>I mean, the current Guix GNOME.
<Kolev>ieure, yes, that will give you a live version of the system you love.
<ieure>Kolev, It just boots into a text console with a root shell, which doesn't have ls. That's uh. Not quite what I'm looking for.
<vivien>Kolev, I’m not sure exactly what gestures gnome-shell implements in 44, I hope it will be a good surprise to you!
<ieure>Is it possible to have a package which builds from a source tarball, but whose updater looks at a Git repo?
<sner>ieure: updaters in guix are executed according to the predicate in the %${name of updater}-updater struct found in each of the files in guix/import/*.scm. Right now, the %generic-git-updater is only executed on packages with git-fetch origin methods set. An extension to the package and/or updater syntax which gives the updater access to the git url would be needed to do what you're asking.
<ieure>This thing I have a package for is a Firefox fork, the repo just has patches and scripts, and a CI job runs everything and spits out a source tarball. It'd be very difficult to build directly from the Git repo.
<ieure>But the HTML parser can't figure out version numbers from the release page, and I'm not going to build from Git, so. ugh
<sner>trying to build librewolf?
<ieure>sner, I have it building! Works good.
<ieure>It's in my channel:
<peanuts_>"ieure/atomized-guix - atomized-guix -"
<sner>ieure: nice! thoughts on upstreaming it to guix proper? that inherit statement would need to be expanded out to avoid the 3rd party repo dependency, but it would be nice to have another browser package available in guix.
<sner>also, the auto updater wouldn't be able to help you with that static %librewolf-build-id define at top of file regardless, so if you want auto-updating you'd need to write a custom updater script
<ieure>sner, I'd be very into upstreaming it, but I think it's probably not free enough for the same reason Firefox isn't. The DRM stuff is disabled by default, but present.
<sner>ieure: my understanding of firefox's distribution format was that media DRM plugins aren't packaged with the browser proper, but rather downloaded dynamically on an ad-hoc basis at runtime. Since librewolf uses arkenfox's policy config by default, drm and all update checks for it are disabled
<sner>I'm not sure exactly where things stand regarding guix's policy on free software which has the mere capability of running/downloading non-free software (at the user's explicit command), but it does feel like a strange hill to die on, given that any web browser with a js engine is capable of this when browsing the web.
<sner>ieure: it's also on the libreplanet Guix package wishlist[1], so if you're willing to give it a shot, submitting a patch to at least generate some mailing list discussion wouldn't hurt
<sner>[1] -
<peanuts_>"Group:Guix/Wishlist - LibrePlanet"
<ieure>I'm not sure why Firefox isn't in the official repos, then?
<ieure>Yeah, I'll send in a patch. Already have the package working, so not much more effort.
<ieure>Though I have like 5-6 patches submitted already and zero have merged.
<sner>ieure: my understanding was that the primary issue was with the trademarked firefox name/branding, and the builtin user anti-patterns (homepage ads, etc.)
<ieure>Hm. Well, the nonguix stuff removes all the official branding.
<ieure>The advertising and crapware are terrible, which is why I switched to LibreWolf.
<isaneran>hmm, it feels like racket almost never has substitutes
<lechner>sneek / later tell luix-felipe / Hi Felipe, thanks for the pointer! I have trouble with ibus (for pinyin, actually) but will try text-to-speech. Do you customize your environment in order to enable ibus?
<sneek>Got it.
<Franciman>hi, I notice a strange behaviour in weechat. Often there is a huge delay from when i send a message to when i see it on the screen
<Franciman>like about 1s
<Franciman>i wonder whether this is a networking issue or something else. Has anybody encountered this behaviour?
<efraim>sneek: later ask civodul can I use (guix platform) inside (guix build cargo-build-system)? I want to move gnu-triplet-for-rust somehwere more generic for cross-building
<efraim>sneek: botsnack
<f1refly_>I recently got a microsd read for my computer and now have the issue that the reader itself is recognized, but when I insert a card into it nothing happens. The reason seems to be that udev doesn't have a polling interval set up, so I set /sys/module/block/parameters/events_dfl_poll_msecs to 2000 and now it works. Is this not included in the %base-services for some reason or did I just break them by
<dan-k>hello, i'm trying to install guix 1.4.0 amd64 on ms hyper-v but after i select 'GNU Guix installation 1.4.0' i'm getting this error
<dan-k>> [some pthread_* and couldn't read /proc/stat warnings]
<dan-k>> Welcome, this is GNU's early boot Guile.
<dan-k>> Use 'gnu.repl' for an initrd REPL.
<dan-k>> loading kernel modules...
<dan-k>> waiting for partition '31393730-3031-3031-3139-333333313833' to appear... [x21]
<Franciman>i have the impression that pulseaudio service is not started on my system
<Franciman>do I need to explicitly say so?
<Franciman>it is as if pulseaudio only gets started when i start pavucontrol
<efraim>I think it only gets started when needed
<Franciman>oh ok cool
<Franciman>that's why i have issues with the bluetooth headset lol
<Franciman>it only connects properly when pavucontrol is open :)
<efraim>do we have llvm-unwind?
<efraim>there's another unwind that's part of llvm
<Franciman>iirc zig uses it
<Franciman>so probably in a way yes, not sure whether it's exposed
<isaneran>Franciman: I usually get it working manually with bluetoothctl
<Franciman>isaneran: uh yes, i also connect manually via bluetoothctl. But if pulseaudio is not running, the connection fails because bt-connction-profile-unavailable
<isaneran>ah yeah I get that a lot
<Franciman>so basically they connect on the bluetooth level, but then it fails to recognize them as headphones
<Franciman>until pulseaudio kicks in
<isaneran>but it started working after I trusted the headphones
<Franciman>uh yes i trusted them too
<efraim>I'm trying libunwind-headers instead of libunwind. I suppose I could just use clang instead of cross-gcc but then I'd have to change more of the package definition
<Franciman>isaneran: yes, i have to first start pavucontrol or the connection won't work. Now it connected automatically lol
<isaneran>yeah it's odd
<isaneran>in my experience pipewire works better
<isaneran>but there is no service shipped for it yet in guix
<isaneran>trying to learn how to write services though
<Franciman>lol isaneran thanks for the tip, i had to retrust them after pairing them
<isaneran>Oh did that fix it?
<Franciman>the other fun thing is that pulseaudio doesn't always start i think. For example qutebrowser didn't stream thru my headphones
<Franciman>until i closed it and opened pavucontrol and reopened it. What a mess T.T
<isaneran>I had been struggling for a few weeks with always removing pairing and removing pairing etc lol
<bumble>ACTION hopes someone with power will take a look at these bumble-anticipated patches
<peanuts_>"[PATCH]: Add PyQt 6."
<peanuts_>"[PATCH] gnu: qutebrowser: Update to 3.0.2."
<ekaitz>hi, does guix daemon stop working after some time? its like it's hanging with no CPU usage in long processes
<efraim>is your memory steadily increasing?
<efraim>more likely you have a cycle
<ekaitz>efraim: nope, memory is alright
<ekaitz>it's also a compilation I did yesterday
<ekaitz>and yesterday it worked
<ekaitz>and i just run it again and it will probably work
<ekaitz>this kind of behavior happened to me in Mes too
<civodul>ekaitz: egun on! could you describe what you’re running and what you’re observing?
<sneek>civodul, you have 1 message!
<sneek>civodul, efraim says: can I use (guix platform) inside (guix build cargo-build-system)? I want to move gnu-triplet-for-rust somehwere more generic for cross-building
<civodul>efraim: i think you can’t because (guix platform) pulls in too much from the “host side”
<ekaitz>civodul: I'm running a custom package, but in the bootstrapping system, with Mes I had this kind of hang when linking a libtcc.a
<ekaitz>but it doesn't happen always
<civodul>so if the build process itself hangs, it’s not Guix’s fault :-)
<efraim>fair enough, I tried it anyway and it said it wasn't possible. I added a note to keep it synchronized from (guix platforms) and not from upstream
<civodul>now, if you’re ensure where things are hanging, you can check out “sudo guix processes”
<ekaitz>civodul: great, I'll try that
<civodul>that lists all the current “sessions”, clients connected to the daemon, sub-processes of ‘guix-daemon’
<ekaitz>and what should I see if it is actually hanging
<civodul>first i’d check if it’s hanging or spinning (as in: one process is at 100% CPU)
<civodul>then, keep in mind that problems are more likely to be either in the build process (the thing you’re building doesn’t terminate)
<civodul>or in the client (there’s a dependency loop in the package you just wrote)
<ekaitz>this kind of hanging happens in linking steps or even in the tests
<ekaitz>which run yesterday
<ekaitz>(and the package is reproducible)
<civodul>yes, so that’s really the build process of the package
<civodul>in that case, guix-daemon and Guix are pretty much out of the picture
<ekaitz>but the cpu going to 0 usage
<civodul>you could check the process tree at that point
<civodul>like see if there are build processes still around
<ekaitz>and see which one is frozen, right?
<ekaitz>last time it was ld
<ekaitz>bit now it's happening on a very different package
<civodul>there’s actually one relevant bug here:
<peanuts_>"[PATCH core-updates] guix: Reap finished child processes in build containers."
<civodul>rarely manifests, but who knows
<ekaitz>i'll keep an eye on this
<ekaitz>i mostly considered guix was related because it was one of the few things in common these packages have
<ekaitz>one is zig and the other was mes
<ekaitz>maybe it's my cpu?
<civodul>as a rule of thumb, when debugging things, i keep in mind probabilities: problems are very very likely to be in my own code, then in (say) Guile, then in libc, then in the kernel, then in the CPU
<civodul>when you reach libc, you’re already at very low probabilities :-)
<efraim>yay typos! I was trying to compile for x86_64-unknown-rust-gnu
<ekaitz>civodul: sure, but why does the same code happen to work sometimes? it's pretty weird
<ekaitz>civodul: OH they have something else in common! qemu!
<efraim>With as slow as the build machines are for arm I almost have rust cross compiling for windows too
<efraim>ekaitz: I haven't forgotten the zig patch, I'll do it today
<ekaitz>efraim: no pressure mate
<lechner>civodul / Hi, I think I have a patch for a pretty serious bug in 'guix shell' here is the reproducer
<peanuts_>"~guix shell -C -f guix.scm ~ should not always need ~--rebuild-cache~ option to build the expected environment."
<peanuts_>"lechner/shell-bug - shell-bug -"
<efraim>/gnu/store/vikzqlhnvcgch2az5l93cxjx58ckhhnx-zoxide-0.8.3/bin/zoxide.exe: PE32+ executable (console) x86-64 (stripped to external PDB), for MS Windows, 10 sections
<luis-felipe>lechner: Hi, regarding ibus things, I have ibus-libpinyin installed and it seems to work for me. Although I'm not familiar with that method, I can type Chinese characters.
<luis-felipe>lechner: And this is my .profile file:
<peanuts_>"dot profile file content ($3624079) ? Snippets ? GitLab"
<Kabouik>When submitting a patch, can I submit a package variation of the main one that would install the latest master commit instead of the latest release in the main package? This would be two different packages, one with the latest release as version, the other with "master" as version, so users would have a choice when installing.
<Franciman>do you think guix can work okay on a modern pentium?
<lechner>Kabouik / we usually do not offer multiple versions unless there is a compelling reason. Which package is it, please?
<jpoiret>Kabouik: that's impossible, you need to choose a reference that does not move
<jpoiret>(or you could use the git-checkout method, but that won't be accepted)
<jpoiret>in any case, if users want the latest and greatest they can always use a package transformation option
<lechner>Franciman / which iteration? i think you will be okay as long as it's a 64-bit model. not sure if you need hyper-threading, too
<jpoiret>is it i686?
<jpoiret>if not you'll have to build everything yourself
<apteryx>why is it so hard to find actual SPDX examples?
<apteryx>I just want to denote a license and author
<lechner>jpoiret / do we still support i386?
<lechner>apteryx / what kind of examples are you looking for, please?
<apteryx>like, how to replace a typical Copyright + License source header with SPDX attributes
<apteryx>the spdx site is focused on the spec and everything but fails short of giving practical basic examples it seems
<apteryx> helps for the SPDX-License-Identifier, but doesn't mention how to declare the author
<lechner>apteryx / i think people just use the codes, and nothing else. did you see this?
<lechner>hang on
<apteryx>you need to put a comment at the top of the file that looks like '# SPDX-License-Identifier: GPL-3.0-or-later'
<lechner>apteryx /
<peanuts_>"spdx-examples/software at master ? spdx/spdx-examples ? GitHub"
<apteryx>ah, that explains why I'm not finding what I want: "Copyright notices ‐ statements about who owns the copyright in a file or project ‐ are outside the scope of SPDX short-form IDs."
<apteryx>so the existing copyright notices lines must be left alone, not expressed via SPDX
<lechner>it's not a popular way to do things, i don't think. is work forcing you?
<apteryx>nope, SRFI 160 has like 30 small files or something, not already marked with their license info in their source
<peanuts_>"SRFI 160: Homogeneous numeric vector libraries"
<apteryx>so as I add them to Guile I thought at least I'd add a 1 line SPDX tag
<apteryx>to each of them
<lechner>jcowan is on #scheme
<apteryx>I know; perhaps I can add these upstream
<lechner>luis-felipe / thank you so much!
<peanuts_>"REUSE - Make licensing easy for everyone"
<mirai>for particulars, see: <>
<peanuts_>"Annex H: SPDX File Tags - specification v2.3.0"
<mirai>in short, you're looking for “SPDX-FileCopyrightText: 2019 Jane Doe <>”
<mirai>apteryx: REUSE is the keyword for what you're looking for
<apteryx>doesn't that go against what I quoted earlier from their site?
<apteryx>(that it's outside the scope of SPDX to capture license notice)
<mirai> <>
<mirai>> The SPDX-FileCopyrightText tag records the publication years and copyright holder of the contents of the file.
<mirai>I interpret “SPDX short form IDs” as the license tags
<mirai>I've seen other projects replacing their notices with SPDX without any hassle
<mirai>you can always do '$ reuse lint' to verify if everything is in order
<apteryx>thanks, reuse is a nice resource