IRC channel logs


back to list of logs

***Server sets mode: +cntz
***stefanc_diff_ is now known as stefanc_diff
***av0idr is now known as avoidr
<lle-bout>I think it is really bad when people writing long messages on the mailing list going on with things you havent even said or thought about
<sneek>lle-bout, you have 1 message!
<sneek>lle-bout, raghavgururajan says: I think we could merge (after test-build) the gst patches to master instead of c-u, because, it indirectly enables A/V support in XMPP clients like Gajim. WDYT?
<lle-bout>And when other people go on about them even, thinking, because of the message of the other people, that you have said things you are not and then it's basically a mob of reactions over and over, it feels really bad I think everyone should think and stop doing this.
<lle-bout>E.g. this message basically telling me how I should cooperate with Raghav (a choice that's about us, not everyone else, really):
<genr8_>stupid socio-politics as usual
<lle-bout>genr8_: what?
<genr8_>i think its really bad also
<genr8_>yet normal
<genr8_>i will leave it at that, or the cycle of reactions will continue
<lle-bout>I think people should rather be happy that something is happening on the GNOME 40 upgrade
<lle-bout>I think that if more GNU Guix committers want to cooperate in a way that using cbaines's repo is really so incovenient because access have to be duplicated between Savannah and their repo then we can talk but for now only Raghav and myself have showed up for this GNOME 40 upgrade.
<lle-bout>We can probably debate on how to do things forever but probably debating them now will just make us give up on the GNOME 40 upgrade and nothing will happen.
<genr8_>you are right in the middle of a giant can of worms. GNOME is a very political organization
<lle-bout>I don't think it is related to GNOME in particular
<genr8_>shouldnt we be redirecting this into specifically "why can't raghav obtain access, and how can he, and what is the path to do so?"
<lle-bout>genr8_: They already submitted their commit access application
<genr8_>well I would concentrate on that, vouch for raghav or something. its only 1 person and a known person
<genr8_>i get what hes saying but going from 1 commiter to 2 commiters is not a big ask
<genr8_>my mistake. "If not you, then any of the other ~64 Guix committers can do so." <-- so 65 then. ?
<lle-bout>genr8_: I have no influence in that process and I don't want to pressure it also, it will just happen when it does
<genr8_>this would be a good time to bring it up. if theres 64 people and only 2 are working on it, and 1 doesnt have access, it seems logical that a squeaky wheel needs some grease
<genr8_>the key point here to me seems to be that only 2 actually showed up and 1 doesnt have access
<lle-bout>the maintainers know, receiving more mail about this wont speed it up
<genr8_>maybe you can send out a bat-signal to the other 64 for help so the burden doesnt all fall on you
<genr8_>GNOME40 seems like a significant event that should have more than 1 and a half people
<lle-bout>in theory but also GNOME is at 3.34 now so there hasnt been enough interest that converts into actual work it seems
<lle-bout>otherwise we'd be doing a GNOME 3.38 -> 40 upgrade rather
<lle-bout>but of course I would like it to become some kind of event but also it's mostly Raghav and me now and we organized how it felt right for us both but of course once they are approved we can very well move the branch to Savannah
<genr8_>I would be interested to know how many people A) use gnome B) like the new gnome C) would go so far as to commit to it, or D) actively avoid it. I'm option D.
<lle-bout>I would prefer if there was something more lightweight than GNOME that provided better desktop integration out of the box
<lle-bout>and supported Wayland
<lle-bout>I don't want to be configuring my desktop environment, I just want things to work
<lle-bout>GNOME is very good at that, however it's massive software
<lle-bout>Also I feel like for us to provide a gnome-service-type it also means we kind of commit to maintaining it and we havent been doing that, if we can't maintain it I would say we should remove it and focus our efforts at things we know we will have an easy time upgrading in the future.
<lle-bout>I feel some times like GNU Guix is trying to do lots of things at the same time and maybe we could benefit from focusing our efforts on some specific software stacks to increase quality
<lle-bout>It happened to me more than once that things are broken in ways that suggest nobody ran them before
<lle-bout>Or actively uses them
<lle-bout>Example is: ddclient-service-type
<lle-bout>It's also attractive, GNOME that is, because basically all the UI/UX innovation is happening there.
<genr8_>but at what cost. its a monstrosity. they're building a new Windows. #include *.* and no way to contain the bloat
<lle-bout>It's not that bad, we also have to accept that software is complex at times
<genr8_>i cant allow it. I have more faith in KDE Plasma
<apteryx>I think I've asked this question before; but I forgot (sorry!). Is there a GTK+ notification lib that works on bare WM? libappindicator? something else?
<apteryx>I use ratpoison
<iyzsong-w>apteryx: i don't know about menu/icon notifications, but the dbus one can be send by gdbus etc. (, a service (eg: dunst) then will show them.
*apteryx tries to remember about dunst this time
<apteryx>thank you :-)
***bloomyca` is now known as bloomycat
***iyzsong-- is now known as iyzsong-w
<apteryx>is there a way to define an alias for a package *name*?
<apteryx>eg, both the package names x and x-y should correspond to x when using the guix command line
<marusich>apteryx, I haven't heard of a way
<marusich>i wonder if you could define two packages A and B, so that B inherits from A and changes just its name?
<marusich>It might influence the output, though.
<marusich>you could try it.
<apteryx>marusich: that's a idea of a thing to try!
<jackhill>I haven't tried it either, but I wonder if inherit is even nessisary. Why not (define primary-name (package …)) (define alias primary-name) ?
<marusich>I think apteryx is talking about the package name, not the variable name.
<apteryx>that creates an alias at the scheme level
<jackhill>ah yes, of course
<marusich>The field of the package that contains the string that is the name shown in places like "guix package --show"
<apteryx>yes, I'm looking for an alias at the CLI (user interface) level, where the package name field is what matters
<marusich>apteryx, I"m not sure but you might look into the logic for selecting versions, like foo@3
<marusich>It's called something like specification->package or similar
<apteryx>I think they'll be 2 different packages with the inherit approach, as the package name is part of the store file name
<apteryx>that's an expensive alias :-)
<contrapunctus>I saw in the documentation that 'support for LVM is missing'. But someone told me it was recently added. Is that the case?
<i1l>Hello Guix.
***sneek_ is now known as sneek
<apteryx>anyone thrilled to try a fresh jami build?
<apteryx>if you are, head here ->
*apteryx zzzzzzzz
***nbren12 is now known as Guest6505
<cbaines>morning all o/
<abcdw>I mean hi guix!)
<tissevert1>hi there !
<abcdw>tissevert1: o/
***tissevert1 is now known as tissevert
<contrapunctus>I saw in the documentation that 'support for LVM is missing'. But someone told me it was recently added. Is that the case?
<contrapunctus>I see there's a commit for it. Does that mean that I can set up LVM, then install Guix System on one of the LVs and have it work?
<link2xt>shouldn't `guix environment` modify PKG_CONFIG_PATH?
<link2xt>I run `guix environment --ad-hoc sqlite`, but pkg-config still uses system-wide debian package sqlite3-dev config
<link2xt>so `pkg-config --cflags sqlite3` outputs nothing rather than an -I flag pointing into /gnu
<link2xt>and C_INCLUDE_PATH only contains ~/.guix-profile/include, which doesn't have a symlink because I run `guix enviroment` without installing `sqlite` into my profile
<link2xt>if I install with `guix install sqlite3`, it works, because PKG_CONFIG_PATH contains ~/.guix-profile/lib/pkgconfig
<mroh>link2xt: `guix environment --ad-hoc pkg-config sqlite -- pkg-config --cflags sqlite3` seems to give a correct include path.
<link2xt>hmm, that's right
<link2xt>but I have pkg-config installed into my profile already
<link2xt>is it still required to add pkg-config to the list of ad-hoc package "dependencies" for it to set the search path?
<Ikosit>Is there a function that unpacks an archive based on its extension in the guix modules?
<civodul>Ikosit: there's probably a couple of them, but mostly likely you can just do: (invoke "tar" "xf" file)
<Ikosit>civodul: thx
<davidl>@nckx: Hi! I have got 2 more patches today, if you would like to review: 47517 and 47519.
***daniel is now known as Guest71195
<Guest71195>Has anyone successfully installed Guix on a recent iMac?
<civodul>Guest71195: hi! you mean Guix System (the full-blown distro), right?
<civodul>i don't know, it would be worth asking on
<Guest71195>yeah the full blown distro using Linux as the kernel
<Guest71195>I'm having issue which relate to KMS I think ...
<Guest71195>Ok, I'm asking on then :) thank you
***BualmaShow[m] is now known as Bualma[m]
<lle-bout>hello! :-s
<yoctocell>Is anyone here familiar with the Go build system? I am trying to package 'gh', the Github CLI tool, but I have run into som problems.
<lle-bout>raghavgururajan: instead of disabling tests, I suggest we either fix it or use the --without-tests package transformation to build things for our purposes, as we cannot possibly tackle all problems in all packages in the scope of that GNOME upgrade only, it's a lot.
<lle-bout>raghavgururajan: I think I am going to test like this for GNU Shepherd for now, and probably about python-sphinx you can do the same!
<pineapples>I'd like to guix challenge a package but I don't know how to initiate compilation of it. Which guix command do I need to execute?
<pineapples>I've read the manual but I'm still having a problem with this, regardless :-/
<pineapples>Hmm. Doing `guix build --no-grafts --check <package>` did the trick. Shouldn't an attempt to rebuild the package made, regardless of the presence of the --no-grafts argument? Is this an expected behaviour?
<civodul>pineapples: hi! if you don't pass --no-grafts, Guix attempts to rebuild the graft, not the package
<civodul>from that perspective, this is expected behavior
*lle-bout there ludo answered it faster
<efraim>well i've built out to mesa again on core-updates, time to get aarch64 building out to it again also
<efraim>still on llvm on powerpc, but that's before ludo's patches
*efraim should just send the patches to the mailing list already
<lle-bout>raghavgururajan: if you want to submit gst patches to master, please send the patchset by email to guix-patches, I will review, maybe wait a little I test and pre-review so you don't send it for nothing, then we will have to do another master to core-updates merge!
<pineapples>civodul: Thanks! Perhaps it'd be a good idea to elucidate that in the manual?
<apteryx>raghavgururajan: impressive navigation chart for GNOME!
<apteryx>I'm talking about this:
<lle-bout>impressive it is yes :-)
<lle-bout>It's like there's a whole lot involved I have missed ongoing with that GNOME upgrade, still have to learn the plan fully
<raghavgururajan>Hello Guix!
*raghavgururajan didn't get any of the messages on that email thread
<raghavgururajan>lle-bout: --without-tests will only work if I build *that* package right? and not if it gets built as a dependency?
<raghavgururajan>apteryx,: Thanks!
<lle-bout>raghavgururajan: it can do deep transformations also
<lle-bout>And it *does* do deep transformations
<lle-bout>AFAICT, anyway, and by experience also
<raghavgururajan>Ah cool!
<lle-bout>I have experienced cases before where that wasnt the case but it feels like it's been the case more recently maybe there's been changes there
<raghavgururajan>Hmm. While I updating versions, I also fix that's broken and enable missing features. If I am fixing a tests for, say gst-editing-services (which triggers building shepherd), if I don't pass --without-tests, then shepherd is gonna fail.
<raghavgururajan>I think we have to make sure (at the end) the c-u branch, as a whole builds fine, so that it can be merged to master later.
<lle-bout>raghavgururajan: sure but we shouldnt feel blocked by shepherd if we can't manage to figure it out
<lle-bout>Probably after the 1.2.1 release, people will look at GNU Shepherd more closely with more expertise than us
<lle-bout>I am a big foreigner to GNU Guile myself
<raghavgururajan>So I think ---without-tests will bit us back at the end. So we can disable failing tests with a comment "FIXME". That way anyone else can pitch in and fix.
<raghavgururajan>*bite us
<lle-bout>raghavgururajan: Creating commits to disable tests is not mergeable
<raghavgururajan>that's for master right?
<lle-bout>raghavgururajan: also core-updates
<lle-bout>If we are certain the tests themselves are faulty, we can disable specific faulty tests, but disabling all tests is too much
<raghavgururajan>Hmm. Wait a sec. Why so on both master and c-u?
<raghavgururajan>That's what I meant
<raghavgururajan>disabling only (specific) failing tests.
<lle-bout>raghavgururajan: because I think the effect of disabling tests in practice is for people to not look at it anymore while it might hide a specific fault
<civodul>nckx: looking at commit aae012e91e6, i wonder if GitHub patches are reproducible; i have a vague recollection of having problems with them in the past, WDYT?
<lle-bout>Disabling specifi tests is fine if we know it's not an actual fault I think
<pineapples>lle-bout: I'm not involved in this discussion, but what does GNU Shepherd have to do with it? Does — by any chance — it have something to do with the critique of GNU Shepherd, which was posted on the guix-devel mailing list?
<lle-bout>raghavgururajan: I hadnt looked at the specifics of that python-sphinx commits it sounds like some specific tests were disabled but I feel like it's better to use --without-tests than to add FIXME because the latter is less likely to draw attention to people that work on core-updates
<lle-bout>pineapples: nope! we just hit a test suite failure when running GNU Shepherd with GNU GUile 3.0.5 that's on core-updates
<raghavgururajan>lle-bout: Hmm. It depends on perspective I guess. Because, I saw "FIXME" in gst-editing-services, and I worked on it for a possible fix.
<raghavgururajan>Likewise, someone will see FIXME in python-sphinx and do the same.
<lle-bout>raghavgururajan: In the context of the core-updates to master merge later I think nobody will be looking for FIXMEs
<lle-bout>raghavgururajan: I think we can delay such decision to ignore failing tests to the core-updates to master merge
*raghavgururajan gets 🍵️
<lle-bout>raghavgururajan: but otherwise I think yes FIXMEs do work when people look at code during their endeavours
<lle-bout>but when trying to make a branch work as a whole, I think people don't look at FIXMEs
<raghavgururajan>So you are okay with adding FIXMEs for this endeavour or no?
<pineapples>lle-bout: I see. Thanks!
<lle-bout>raghavgururajan: I think we should not disable specific tests unless we have evidence the test suite is faulty and not GNU Guix packages, for the context of the core-updates to master merge I think we should rather hold ourselves to fix all issues rather than delay them in FIXMEs which I believe people are less likely to look at for the later merge of core-updates into master.
<lle-bout>And that if those tests were disabled to be able to build packages and test other changes, we can use --without-tests for that instead
<raghavgururajan>lle-bout: --without-tests it is.
<raghavgururajan>rekado \ rekado_ : Would you be able to help us with fixing build failure of shepherd in c-u?
<avalenn>I have a problem using `guix environment --root`
<avalenn>new paste as I misclicked the previous one
<abcdw>At the beginning of /etc/profile MANPATH and few other variables are set to contain /run/current-system/profile... . Few lines below same pathes are added to the same variables by sourcing /run/current-system/profile/etc/profile. Is it intended or it is a bug?
<raghavgururajan>guix build: error: invalid argument: Missing required argument after `--without-tests'
<raghavgururajan>lle-bout: what to pass with that?
<raghavgururajan>I did ./pre-inst-env guix build gvfs --without-tests --keep-going
<apteryx>leoprikler: by the way, jami-qt built fine using the qt-build-system, and also adding the binary with QTWEBENGINEPROCESS_PATH; I guess this later is what was missing (not sure why it'd crash instead of print a useful message though!)
<leoprikler>sorry, I forgot that I contributed know-how to the packaging of jami-qt :)
<leoprikler>but I think this is the age old problem of "it compiles != it runs an produces useful results"
<civodul>raghavgururajan: should be --without-tests=gvfs or similar, see
<raghavgururajan>civodul: Thanks!
<civodul>yw :-)
<raghavgururajan>civodul: Will gvfs's dependencies also build without tests?
<civodul>nope, just gvfs
<raghavgururajan>lle-bout: ^
<raghavgururajan>shepherd test is failing. So can i do guix build gvfs --without-tests=shepherd ??
<apteryx>any idea why pulseaudio doesn't work well in a pure environment unless it's started there by itself?
<raghavgururajan>apteryx: dbus?
<apteryx>and when it's started there by itself, pavucontrol cannot connect to it from outside the environment
<apteryx>raghavgururajan: does dbus use some environment variables?
<apteryx>env | grep -i dbus suggests not
<raghavgururajan>I remember 'dbus-launch' is involved somewhere.
<apteryx>glib does it under the hood automatically
<apteryx>(I remember patching its full path so that propagating dbus is no longer needed)
<apteryx>(commit 7da3e81aa1b95ba2d72118e393c4531da44d5536)
<pkill9>hello guix
<vagrantc>guix is back on track in debian ... should still make it into the next release :)
<lle-bout>civodul: hello! about --without-tests not doing deep transformations, do you think it would be useful for it to at least optionally do so or any objections?
<lle-bout>civodul: nevermind I probably misread you, it probably does deep transformations already
<raghavgururajan>lle-bout: timeouts and/or no route to host.
<apteryx>vagrantc: awesome!
<vagrantc>although without most of the bugfixes for guix-daemon (just the security one applied)
<vagrantc>if there are other guix-daemon fixes that are reasonably simple to apply to 1.2.0, it might be worth pushing them to a debian point release...
<pineapples>apteryx: How do you start your DE? if from a TTY, you need to pre-append dbus-run-session to the command that starts it. Absolutely, yes — there's DBUS_SESSION_BUS_ADDRESS
<lle-bout>raghavgururajan: sorry DNS should update soon
<raghavgururajan>lle-bout: No worries!
<lle-bout>vagrantc: awesome!
<abcdw>yoctocell: I'll reply on the message about home-shell-profile-service-type tomorrow. Also, another commit for that service is coming, it's a minor improvement, will push without review.
<yoctocell>abcdw: Ok, sounds good to me :)
<lle-bout>apteryx: I have sent you a query
<pineapples>home-shell-profile-service-type? That sounds of interest to me. Is there public correspondence about it on our mailing lists?
<abcdw>We plan to upstream `guix home` after we do a 2-4 weeks run with few early adopters.
<lle-bout>raghavgururajan: do you still want to submit gst to master?
<pineapples>Oh my.. I'm pretty hyped up. `guix home` is going to solve a lot of my problems, limitations that I've imposed upon myself by restricting myself to declarative configuration only
<pineapples>I can't wait for it to hit master!
<pineapples>I mean, upstreamed :-)
<lle-bout>abcdw: also so happy about this! I've been watching the streams the idea of limiting persistent state as a philosophy really echoes into me and I feel like this is the major causes for lack of tidy-ness on my systems, useless state here and there I accumulate over time
<raghavgururajan>lle-bout: Yes. But as you said, if it doesn't cause too many rebuilds.
<lle-bout`>raghavgururajan: on wip-gnome-40 branch, running: "$ ./pre-inst-env guix build -v1 --without-tests={shepherd,nss,libsoup,python-pygobject} gstreamer gst-plugins-base gst-plugins-bad gst-plugins-good gst-plugins-ugly gst-libav gst-editing-services gvfs" - I get faac and iqa failures
<raghavgururajan>lle-bout`: For now, build gsteamer, gst-plugins-base and gst-plugins-good.
<lle-bout`>raghavgururajan: I see you force-pushed the branch again, testing again
<raghavgururajan>I am working on ugly, libav and bad, in this order.
<raghavgururajan>Ah sorry, was about mention.
<lle-bout`>raghavgururajan: no need to be sorry just noting, the branch is no longer based on core-updates however now, it's missing a commit, can I rebase it on core-updates and re-force push?
<lle-bout`>There shouldnt be any conflict
<raghavgururajan>Just a sec. lemme push good and editing-ser
<raghavgururajan>*ugly and editing
<raghavgururajan>lle-bout`: Never mind. You can rebase now.
<raghavgururajan>I added just ugly
<abcdw>pineapples: You can join the the early adopters program to get it even earlier than it will hit guix's master :D I'll announce it next week.
<jonsger>oh GIMP doesnt start anymore, complains about gegl or so...
<pkill9>what's guix home?
<pineapples>abcdw: I'll think about it :) Anyway, where will it be announced?
<abcdw>pkill9: It's a subcommand like `guix system`, but for user's $HOME instead of /
<pkill9>is this the guix home manager?
<abcdw>For now it's developed separately from guix
<abcdw>pkill9: Nope, but the purpose is similar.
<abcdw>pineapples: ~Tuesday, next week.
<pineapples>abcdw: If you don't mind the query, is there support for managing multiple profiles in guix home? I found the idea of profiles and manifests appealing but there's no way I'll touch the default .bash_profile to enable extra profiles because that's against my declarative configuration only principle
<abcdw>lle-bout`: Yep, actually, the idea of making state very dedicated is pretty common in functional programming. I think my background with Clojure is a main source of inspiration for this feature.
<pineapples>abcdw: >"~Tuesday, next week" Mailing lists or the project's Source Hut page?
<pineapples>Mailing lists as in guix-devel lists :-)
<m6locks_>hi, trying to install guix but the process stops because cannot find wifi. then there's a backtrace of some sort that gets printed
<m6locks_>iwlwifi works on BSDs, it's an intel integrated wifi
<abcdw>pineapples: The short answer is no, it's technically impossible to have few profiles for `guix home`. Maybe I'll need to make a FAQ soon) The similar question:
<abcdw>pineapples: I'll make an announcement on rde-announce, guix-devel mailing list and during the next stream.
<pineapples>abcdw: Thank you for the clarification as well as your hard work ;-)
<vagrantc>so, i just figured out how to use 64-bit aarch64 hardware to run kvm-accelerated 32-bit OS in libvirt ... wonder if this would be viable for building substitutes for armhf
<lfam>vagrantc: Please send mail :)
<lfam>I think it's the only option, once we get some more aarch64 machines
<cybersyn>hiya guix. just a heads up on the guix-mind-map community research project i proposed at guix days, i'm finding that i'm still in the space of discovering new guix "tricks", experimenting with configurations, deployments etc, so I think I will just continue to learn and get good at packaging for now.
<apteryx>rekado_: it's possible the mishandling of my patches by MUMI was caused by my erroneous use 'Content-Type: text/plain; charset=yes' in the patch messages produced by git send-email
<apteryx>I had set 'assume8bitEncoding = yes' in my git config, and that turned out to be wrong; I 'wanted assume8bitEncoding = utf-8'.
<lfam>Hey cybersyn, that sounds like a cool projet
<cybersyn>I think i'm a bit eager to contribute because i'm using guix day and night since november, but haven't had much reason to interact with the community because the documentation is (mostly) really solid. but i've realized i need to master packaging first and foremost
<lfam>Here is a simple trick, but a useful one. How to build a package from source without having to build all of its dependencies:
<cybersyn>lfam: thanks!
<lfam>`guix environment foo -- guix build --no-substitutes foo`
<lfam>So, it uses substitutes to set up a development environment, and then we build the package without substitutes
<cybersyn>wow, yeah i didn't think of that, but it makes sense
<lfam>This command doesn't actually make use of the build environment, but just uses it to make sure that all the dependencies are available
<lfam>It can be useful for debugging build failures :)
<vagrantc>lfam: i have a few apm mustangs with i think 8 cores and 16GB of ram i could offer up
<cybersyn>thats a good trick, thanks for the heads up.
<lfam>That would be great vagrantc
<vagrantc>lfam: but i'm already running a reproducible builds farm for debian, so not sure my network can handle more
<lfam>Well, just having the instructions will be useful
<vagrantc>haven't tried with libvirt on guix yet, but woudl probably work, and wost case could host on debian
<abcdw>bye guix! Have a nice evening or any other part of the day)
<davidl>Is there an official patch review order and queue among ppl who work full-time with Guix or have commit access? Otherwise, anyone who feels up to reviewing some new patches of mine; I've sent in a few new packages: 47517. 47519 and 47523.
<lfam>vagrantc: Yeah, we could use another distro. The important thing is to use linux-libre as the kernel
<m6locks_>the installer is not finding my wifi, modprobe loaded iwlwifi fine, how do I create the interface?
<vagrantc>lfam: oh, i assumed Guix System would run inside the virtual machine :)
<vagrantc>lfam: wrapping up some end-of-month reproducible builds stuff, but hope to carve out some time in april to poke at this for guix :)
<lfam>Cool :)
<lfam>m6locks_: I'm sorry, but the installer doesn't support iwlwifi
<lfam>It uses the linux-libre kernel, which disables use of devices that don't have freely licensed drivers and firmware
<lfam>Same story for Guix System, in general, but we do make it easy for users to use whichever Linux kernel they like. That's not so easy for the installer, though
<m6locks_>ah ok
<lfam>There are some vendors that focus on providing wifi hardware that works with completely free software support, like Think Penguin
<vagrantc>sometimes you can swap out the "built-in" wifi for one with free firmware/drivers
<vagrantc>though some laptops forbid non-approvied wireless interfaces
<lfam>Yeah :(
***Noisytoot is now known as []{}\|^`-
<vagrantc>i've been pretty happy with various usb wifi adapters from thinkpenguin, though they're getting a bit old by modern wifi standards
<m6locks_>might need to grab one of them USB wifis
<vagrantc>lfam: now i want to set up one of these boards just to host my own aarch64/armhf substitutes :)
<lfam>I think it's important for the free software movement that we get some 802.11ac wifi hardware with free support
***[]{}\|^`- is now known as Noisytoot
<vagrantc>but i've use usb-wifi on the pinebook and pinebook-pro since the built-in ones aren't free
<m6locks_>ethernet would have been way easier, but I just don't have a connection here
<vagrantc>there are also wifi routers that have ethernet ... you can connect your laptop to them with ethernet, and then set it up to route via wifi :)
<vagrantc>so many workarounds
***Noisytoot is now known as ||||||
***|||||| is now known as Guest7851
<roptat>hi! trying to translate the guix manual, I found this sentence: "To add the binary path @code{_jll.jl} packages, ..."
<roptat>I'm having a hard time understanding it
<roptat>which of the four last words is the noun that gets added?
<roptat>btw, I sent a patch to weblate so they support scheme format, and it landed on the fedora instance recently :)
***Guest7851 is now known as Noisytoot
<roptat>it's broken and very limited, but it let me find a few instances where the English and French translation didn't agree on the ending ~%, and one example where I used ~a instead on ~s
<lfam>roptat: I don't understand that sentence either
<lfam>There are some typos that make me think we should copy-edit the English translation to clarify it
<lfam>For example, "Julia packages usually manage they binary dependencies via [...]
<roptat>right, I just translated this sentence and didn't even notice ^^'
<lfam>Did you translate the correct meaning? :)
<lfam>I'm just curious
<roptat>I think so
<roptat>I mean, I didn't translate it with a typo ^^
<lfam>It's a typical description of packages having dependencies
<roptat>bah, I did make a typo ^^'
<lfam>So, "their" communicates the possessive meaning
<roptat>forgot the plural mark, but used the possessive :)
<lfam>Thanks for your hard work :)
<lfam>If only each package had a single dependency!
<roptat>290 sentences left, but to be honest I feel tired, so I'll stop there
<oreoking[m]>libgccjit is building from source 😑
<lfam>Is that unexpected, oreoking[m]? I mean, do you want to use binary substitutes, or do you want to build?
<lfam>Hm, looks like --check interferes with offloading
<lfam>I tried to do `guix build /gnu/store/rbij9c994hda3wjlbirlfc18bgk785c4-cuirass-1.0.0-5.eb94e7d.drv` on This derivation is for aarch64, and normally it would be offloaded to one of the Overdrives
<lfam>I want to make sure it builds natively on aarch64, rather than using emulation
<lfam>However, it's already been built.
<lfam>So, when I use --check, I get the "while setting up the build environment: a `aarch64-linux' is required to build `/gnu/store/rbij9c994hda3wjlbirlfc18bgk785c4-cuirass-1.0.0-5.eb94e7d.drv', but I am a `x86_64-linux'"
<lfam>I'll log in to one of the Overdrives directly and invoke the build from there
<jackhill>Hi, any tips for applying a v2 patch series from the bug tracker? In the past, I've downloaded invividual mbox files (or the whole bug when there was only one set of patches), but beyond a handful that is tedius. I think emacs-debbugs might be the right answer here. I've found the bug in emacs-debbugs, but need some more direction on what to do next.
<lfam>There must be some tools that can make it easy
<lfam>I usually send long patch series as a single file, for this reason
<lfam>`git format-patch origin/master --stdout > series.patch`, for example
<jackhill>I guess the "right" way to do it is have my MUA dump a selected set of messages to an mbox, but I'm still on alpine, so I don't think that's easy for me. Maybe it'll finally get me to swith to emacs for mail (or perhaps mutt). For now, time to read more emacs-debbugs documentation
<apteryx>jackhill: if you use Gnus from Emacs, go to the first message, M-x cd ~/your-guix-checkout, then C-u N | git am, where N is the number of mail (patches) to consider
<apteryx>I hink debbugs open Gnus when you visit the thread, so that'll work the same
<lle-bout`>raghavgururajan: rebased on core-updates
<raghavgururajan>Fixing ibus now
<lle-bout`>raghavgururajan: thank you very much, I don't think I'll be able to review gstreamer today since I am in a place now I also have to socialize and work on some other things
<raghavgururajan>lle-bout`: No worries! Take you time. :)
<jackhill>apteryx: thanks, that really helps. One step closer to getting me sucked into doing everything in emacs :)
<jackhill>apteryx: hmm the opendht patch is still giving me trouble: "error: corrupt patch at line 112" but the ones before that applied fine
<apteryx>OK, I only changed jami-gnome so if you could apply the v1 one you should be good
<apteryx>I'll be curious to know if Maxime had problems applying the v2 series too
<rekado_>the latest version of Mumi lets you do this: wget -qO- | git am
<rekado_>not deployed yet
<lfam>The Guix package failed to build on aarch64:
<rekado_>the patch-set endpoint gathers all “[PATCH” emails (“v2” in this case) in the issue thread, sorts them, and concatenates them as an mbox
<rekado_>I hope this will make mumi a little more useful for patch review.
<lfam>Hm, looks like it has since succeeded
<jackhill>rekado_: oh, cool, that sounds promising.
<apteryx>I wonder why debug symbols are downloaded when generating a "guix pack"
<civodul>rekado_: oh, that's nice!
<apteryx>rekado_: very nice indeed!
<jackhill>apteryx: I get the same error with v1 of the opendht patch. Whacky.
<civodul>rekado_: ah so it applies the whole series, not just one patch?
<civodul>even better
*civodul didn't know "git am" can take several patches at once
<jonsger>congrats to the POWER crew!
<civodul>+1! POWER to the people!
<apteryx>jackhill: if all else fail, you can get the commits from
<vagrantc>so does this mean i should be able to build the future guix 1.2.1 on ppc64le on Debian?
*lle-bout` reads cheering also happy it finally happened
<rekado_>civodul: it takes an mbox; an mbox can contain more than one message. Messages need to be separated by an empty line, with the message beginning with “From”.
<rekado_>I needed to filter the raw Debbugs emails to remove the first line that’s Received instead of From.
<lle-bout`>vagrantc: yes
<raghavgururajan>How to lower the idle-time for tests?
<pkill9>what's the power crew?
<raghavgururajan>idle-time or time-out
<raghavgururajan>(for gnu-build-system)
<lle-bout`>pkill9: powerpc64le-linux port
<civodul>rekado_: that's pretty cool, we should add this to the manual when it's deployed
<civodul>thanks for the nice hack!
<lle-bout`>rekado_: looks very useful thanks
<jackhill>apteryx: thanks, I've grabbed the patches from there so I can test for now. I do feel like I've made some progress on the email patch workflow today though, so that's nice.
<jackhill>apteryx: make works now :) Now to wait on the actual packages to build for testing :)
<vagrantc>lle-bout`: always like adding additional architectures
<nckx>civodul: Hm, the patches themselves, even? OK. Your recollection's good enough for me. I'll change it.
<apteryx>jackhill: nice!
<civodul>nckx: not sure if it was GitHub, but some hosting services would for instance include the version number of Git used to generate it
<civodul>dunno, might be safer to copy
<nckx>The footer. Makes sense. Let's err on the side of caution.
<apteryx>civodul: i get this error with a 'guix pack -RR jami-qt' pack: std::runtime_error seems related to locales; any idea?
<apteryx>oh, I guess I need to source the profile as usual
<apteryx>that didn't help
<apteryx>I'll add glibc-locales to the pack
***nbren12_ is now known as nbren12
<Gooberpatrol66>is stage0 or gnu mes able to run without an underlying operating system?
<pkill9>civodul: there's a small thing that bothers me about the shorter download outputs, they produce a blank newline every line, otherwise it's nice
<janneke>Gooberpatrol66: stage0 can run on the knight vm
<apteryx>setting GUIX_LOCPATH allowed jami-qt from a Guix pack to launch on that Ubuntu 20.04 VM :-)
<Gooberpatrol66>janneke: this?
<janneke>Gooberpatrol66: yes, i think so
<contrapunctus>.o(... janneke of Lilypond fame? :o)
<janneke>contrapunctus: o/
<apteryx>civodul: it just works :-) this is amazing
<jeko>Hello Guixters
<pkill9>it would be good if guix pack could produce appimages
<civodul>pkill9: you'll need to upgrade your daemon for that
<pkill9>ah ok
<civodul>apteryx: glad "guix pack -RR" works for you!
<civodul>locales and an endless source of sufferings
***stikonas_ is now known as stikonas
***Noisytoot is now known as ihatecoronaandih
***ihatecoronaandih is now known as Noisytoot
***lukedashjr is now known as luke-jr
<lispmacs[work]>my thanks to whomever packaged PDF Arranger. Has made my life soooo much nicer
<lispmacs[work]>i wish PDF Arranger had OCR capabilities built in. I haven't figured out an easy way to add OCR text to PDFs using Guix packages
<apteryx>civodul: I saw if I add 'glibc' it defines GUIX_LOCPATH for me, but also adds 40 MiB to the pack
<apteryx>because apparently it's not the same variant as the one implicitly added already
<pkill9>what is all the module-import and module-import-compiled derivations?
<pkill9>weird, since reconfiguring, the output is back to the old way
<pkill9>oh no, it's just with guix build
<jeko>I am working on the setup of an on-demand Guix VM to host remote pair programming session with Emacs. I am looking for people (to try?) to ssh to it for few minutes and give me their feedback. anyone interested ? (I can't speak right now but I just need to know if I can host it locally or if I need to rely something more powerful)
<civodul>apteryx: yeah
<contrapunctus>jeko: crdt.el?
<jeko>contrapunctus: I tried it but I finally opted for a VM I can easily create and throw away haha
<jeko>contrapunctus: crdt needs you to add buffer to the collaborative session manually and you don't know what your pair is doing
<jeko>contrapunctus: so I use lockstep.el to provide the "follow" feature and a Guix VM where I can git pull the repo to work on
<jeko>contrapunctus: but the crdt way of joining a session really seduced me. I will keep an eye to the project for sure
<apteryx>is kernel 2.6.32 still the oldest kernel we support with Guix? (to run a Guix pack for example?)
<apteryx>seems too good to be true
<apteryx>I'm basing this guess on the "glibc-allow-kernel-2.6.32.patch" patch applied to our glibc
<apteryx>it's amazing how fast zstd compresses compared to even gz
<apteryx>28s to build a pack vs 4m43
<apteryx>while managing to squeeze 70 MiB more
<apteryx>or rather, reduce the size of he pack by 70-80 MiB
<apteryx>the pack*