IRC channel logs

2021-04-14.log

back to list of logs

<lfam>It's not great that your previous generations were broken too
<ss2`>but it is a user that is calling ./configure. Shouldn't this not happen?
<lfam>It's a developer's tool, not a user-facing program
<lfam>It's important to use it correctly
<ss2`>Too sad that I deleted the old partition. Can't find out anymore why this happened.
<ss2`>okay.
<ss2`>what makes the difference then?
<lfam>The difference between using Guix from a development checkout, and using Guix packages, is that developers have ./configure-d the packages to work correctly
<lfam>In both cases, this step must be carried out properly
<lfam>I missed the earlier part of this conversation. What happened is that the localstatedir argument to ./configure was omitted?
<lfam>And then, work was done, referring to the wrong Guix database?
<ss2`>I rebooted early on, and then the kernel would kernel panic. Resorting to previous generations would also panic too.
<ss2`>After testing several generations I concluded all was broken and reinstalled.
<lfam>Were the relevant store items garbage collected?
<ss2`>I garbage collected yesterday!
<ss2`>and rebooted today.
<lfam>I mean, is that what triggered the failures?
<ss2`>probably
<lfam>Or, did your system break before garbage collection?
<ss2`>no
<lfam>Right
<lfam>So, you built Guix, and then did something like `./pre-inst-env guix system reconfigure ...`?
<ss2`>I never did that!
<lfam>Okay
<lfam>What did occur?
<ss2`>but I have been ./configuring, and probably forgot to add localestatedir
<ss2`>nothing that I can recall anymore. I rebooted to kernel panics..
<lfam>Simply building Guix should not affect the installed system. Were you using the Guix you built?
<ss2`>no
<lfam>You didn't use the pre-inst-env script at all?
<ss2`>I was building packages locall, using pre-inst-env
<ss2`>but they where not for the system
<ss2`>I guess
<lfam>I'm trying to figure out what happened
<ss2`>no worries. :)
<lfam>Only building packages, with a command like `./pre-inst-env guix build ...`, should not have broken anything
<ss2`>The last thing I remember what I did (that was yesterday), that I gced, (with --delete-generations=3m), and cleared 25Gigs or so.
<ss2`>and left the system as it was.
<ss2`>And the bootloader early on still had entries going back to August last year, which I could still select.
<lfam>Do you have your command history available?
<ss2`>yes
<lfam>Okay. If you'd like to get to the bottom of this, it will be best if you can share the exact commands that you used
<lfam>When you build from Guix from source, but omit the localstatedir argument to ./configure, it uses the default value of /usr/local/var, instead of the standard Guix location, which is /var
<lfam>This means that there will be two different store databases, one in each location
<lfam>So, if you collect garbage using the Guix that is configured to use the database at /usr/local/var, it will delete all the store items that are registered in the database held in /var
<roptat>mh, someone updated the manual :/
<nckx>‘:/’ For evil?
<lfam>You could revert it roptat
<lfam>And send a reminder email to the committer
<nckx>Oh, the string thing.
<rekado_>roptat: was it me?
<lfam>ss2`: That should explains why it matters exactly which commands you ran — so that we can understand exactly "which" Guix you used
<ss2`>alright
<lfam>Or, you could leave it in the past
<roptat>rekado_, I don't think so
<rekado_>phew!
<roptat>unless you didn't say that in your commit messages
<roptat>I see an update from Leo Prikler (pushing a commit for someone else)
<rekado_>(I’ve always been bad at remembering what day / time it is, but since a few months I’ve lost *all* track of time.)
<lfam>civodul: I noticed you updated guile-git. Should I update the Guix package now?
<roptat>mh, it adds only 2 sentences, and none of the manuals have been translated fully so far, so I'm tempted to let it go through
<lfam>It's your call, roptat
<roptat>but then maybe some translators have downloaded the file and are working on it
<lfam>You should still remind people to avoid these changes
<roptat>true
<ss2`>lfam: https://paste.rs/n3T.bash
<ss2`>search from --delete-generations
<ss2`>I left things upwards from ./configure
<ss2`>things are unclear where the entries come from. My shells always unconditionally append what happens, so there's that.
<lfam>Oh, it looks like you ./configured correctly. It's the fourth command
<ss2`>but I did ./configure without localstatedir!
<ss2`>*a, and then configured with.
<lfam>Yes, but then you immediately tried again, with the correct argument
<lfam>Assuming the second (and correct) invocation succeeded, it would be fine
<ss2`>it did. I had a special terminal open for my build deeds. It's last state was a guix environment.
<lfam>Then, my hypothesis is likely false. This ./configure thing probably has nothing to do with your issues
<ss2`>I don't think so either.
<ss2`>I rather believe that it has to do that I garbage collected everything and went to bed without thinking any further.
<ss2`>I mean, I've seen it that after garbage collecting only 5GB, a system reconfigure would still need to download things. That has always left me wondering in which state old generations are left at when items are removed.
<ss2`>*redownload things.
<lfam>Old generations are protected against garbage collection
<lfam>The programs needed to reconfigure a system are not part of any generation, by default, and are thus subject to garbage collection
<lfam>If old generations are being garbage collected, that's a very serious bug. But, I don't see a reason to think it happened here
<lfam>You could clarify what you mean by "garbage collected everything". It's not really possible to garbage collect everything in the store, or you'd even delete the `rm` command itself
<ss2`>I garbage collected as shown in my history. I'd never touch things directly.
<ss2`>And I never work with root (, but only when I reconfigure)
<ss2`>anyway, I'll see that I can reproduce this again (I hope not!). :)
<lfam>I hope not too!
<lfam>I mean, I would love to figure out what happened...
<ss2`>yeah, it's really weird actually. Things where running very stable lately.
<lfam>roptat had a problem with an ARM computer a few days ago. Are you on ARM?
<ss2`>no, AMD.
<ss2`>next time I'll keep the dead partition.
<ss2`>was too quick to delete it.
<lfam>It's okay, you didn't do anything wrong
<roptat>I still have an issue with the board, it's build the kernel
<roptat>took half a day to produce the deblobed sources ^^'
<lfam>Ugh
<lfam>That process is slow
<roptat>the CPU is not idle often on that board ^^
<lfam>I can imageine
<lfam>Imagine
<lfam>Does it have a good heatsink? Fan?
<roptat>natural convection
<roptat>seems to work ^^
<lfam>I was looking at some high performance fanless industrial computers. The whole case is a giant heatsink
<lfam>I thought it would be good for my apartment in the winter
<Aurora_v_kosmose>That's probably the only way you'll get that to work, yes, having the whole thing be heat conductive.
<lfam> https://www.onlogic.com/
<ryanprior>just freed >140gb disk space with `guix gc` =D
<marusich>Greetings to all Guix
<marusich>So, I tried using usertags. I used the user guix-devel@gnu.org. I am not sure if it will cause emails to be sent to the list, but I suppose we will find out...
<marusich>I think that maybe the updates to the bug report are only sent to the actual person who opened the bug report, but Debbugs is anything if obvious, so I apologize in advance if there are a few errant messages.
<marusich>Oh, for context: I added the usertag "powerpc64le-linux" for powerpc64le-linux bugs.
<marusich>I used the guix-devel@gnu.org "user" for the purpose of making it easier to "share" the usertag.
<iskarian>Hello :) I'm trying to install nyxt on a fresh guix system 1.2.0 install. However, it's installing an old version (2-pre-release-3) instead of the current version (2-pre-release-6).
<iskarian>It seems like this because prerelease-3 is specified in /gnu/store/...-guix-1.2.0/share/guile/site/3.0/gnu/packages/web-browsers.scm. However, ...-guix-packages-base-source, ...-guix-a758a8a/gnu/packages/web-browsers, and ...-guix-a758a8a3c-modules/share/guile/site/3.0/gnu/packages/web-browsers.scm all seem to contain the correct prerelease-6... wh
<iskarian>at is going on here? How to I get the right package version?
<iskarian>(I have tried guix pull follows by a guix package -u, but that did not seem to change anything related to this)
<kozo[m]>Did you do hash guix after the guix pull?
<iskarian>nope, that fixed it! I feel silly now...
<kozo[m]>Sweet =]
<iskarian>might be useful to have guix pull print a hint to do that after guix pull is done!
<kozo[m]>It does but not in a straight forward way =P
<kozo[m]>I agree with you though, it should tell you to run it. In 0.14? I think it did
<kozo[m]>I remember it did at some point in time.
<iskarian>thanks though :) if I stick with this I'm sure I'll be back at some point!
***iyzsong-- is now known as iyzsong-w
<marusich>Grrrr. Gnus isn't using the Subject from the correct patch when I reply to Efraim's powerpc-linux patches...
<marusich>It's just re-using the top level subject, which was "[PATCH 0/9] Add 32-bit powerpc support"
<apteryx>marusich: you can use the 'guix' user if you want to share tags on debbugs
<marusich>I saw that both guix and guix-devel@gnu.org had one or more usertags already
<marusich>I guess we should agree on one
<apteryx>'guix' is shorter ;-). Emacs uses 'emacs'.
<apteryx>weird you Gnus problem! Do you hit S W to wide reply to the article being read in Gnus?
***lukedashjr is now known as luke-jr
<logiz>hey, how do I get header files from `guix install` I'm trying to install openjdk11 and running `ldd ./java` I have `libz.so.1 => not found`
<logiz>or I guess library files :|
<logiz>I guess specifically `guix install zlib` doesn't satisfy it
<logiz>I have libz.so.1 in my .guix-profile, so do I just need to update my lookup path?
***iyzsong-- is now known as iyzsong-w
<raghavgururajan>Hello Guix!
<rekado>logiz: linkage in Guix is fixed via RUNPATH, so not finding needed libraries sounds like a bug.
<efraim>Also we have a package for openjdk 11
<rekado>logiz: I can’t reproduce this:
<rekado>logiz: https://elephly.net/paste/1618385908.html
<zzappie>hello guixers!
<zzappie>anyone also afraid to run built-derivations in repl?
<zzappie>most of the time geiser hangs emacs on long ouput
<zzappie>there are mentions of it in mailing list, anyone hase overcomed this issue?
<rekado>Emacs has so-long-mode, but I just try to avoid doing anything in geiser that could lead to very long lines.
<rekado>I also prefix things with ,pp to pretty print long expressions
<terpri>a quick workaround for icecat's inexplicable replacement of the normal duckduckgo search engine def with a worse one:
<raghavgururajan>leoprikler: You around?
<leoprikler>What's up?
<raghavgururajan>leoprikler: I wanted to continue our talk with cherry-pick in command-line
<leoprikler>As far as I understand it's "git cherry-pick <hash>"
<raghavgururajan>I am loooking to cherry-pick those 9 commits (gst) in staging, into wip-gnome.
<raghavgururajan>I should do that command by being in wip-gnome checkout right?
<leoprikler>Yep
*raghavgururajan tries
<terpri>load duckduckgo.com and download the opensearch <link>'s href via the inspector (not view source); change the engine's name not to conflict with the built-in one (e.g. sed -i 's/DuckDuckGo/DDG/' $FILE); enable devtools.chrome.enabled in about:config; then open the browser console and evaluate 'await Services.search.addEngine("$FILE", null, null, false)'
<terpri>then your back button will finally work again after searching, as it will (correctly) use GET instead of POST for searches
<terpri>(i have no idea why icecat overrides the default search the way it does)
*terpri adds a TODO item to fix it upstream
<terpri>addEngine("file://$FILE", ...) rather, as it expects a URL
<zzappie>rekado: thanks for the so-long-mode tip, ill try it out :)
<zzappie>when emacs will unhang...
<raghavgururajan>leoprikler: Worked. Thanks!
<rekado>zzappie: does it ever uhang? I usually lose patience and kill it.
<brendyyn>hitting C-z or C-c a few times usually stops the repl for me
<zzappie>I usually start new emacs and start working on other things, when it unhangs swithch back to it, this way I don't lose repl history
<bdju>has anyone else experienced duplicate emails from the bug-guix mailing list? it's not for every person/email but I am seeing two identical emails next to each other once or twice per day I think
<raghavgururajan>cbaines: Was offloading removed on bayfront?
<cbaines>raghavgururajan, yeah, I'm trying to get the Guix Build Coordinator running on there
<raghavgururajan>Ah cool!
*zzappie killall -r emacs -9
<Ikosit>Hi guix! I'm currently trying to use java on guix (me and a friend have to program sth in java) and we want to use fxgl (which is based on openjfx), but java doesn't find libx11, has anyone experienced sth similar?
<Ikosit>(It would also help, if sb has a working java setup for guix to develop games)
<Ikosit>nvm, i switched from fxgl to litiengine
<Ikosit>now it at least builds
<Ikosit>¯\_(ツ)_/¯
*terpri tries building mono v6 (vs v4)
<canant>Hi Guix,
<canant>I'm working on the "Set a more informative page title for Guix Data Service". Now I'm on the Revision part. But I have a question for all the Guix Data Service users.
<canant>Which of these do you prefer in the page title (little reminder: title, what you're seeing on the tab name)?
<canant>1.Revision + commit hash + Guix Data Service
<canant>2.Revision + Guix Data Service
<canant>Commit hash has about 40 characters. I think the first option is too long for the title. But maybe you want to know which specific revision you're browsing?
<canant>Thanks :)
<pkill9>maybe just the first 5 characters of the hash?
<civodul>mothacehe: hello! what's the status with dover? do you think we could add dover + overdrive1 for a subset of armhf builds in preparation for the release?
<canant>pkill9 It's a good idea thanks :)
<civodul>weird, https://ci.guix.gnu.org/workers suggests it's vacation
<mothacehe>civodul: hey!
<mothacehe>i've been exchanging with andread regarding dover
<mothacehe>on guix-sysadmin
<civodul>mothacehe: oh my bad, i didn't follow closely enough
<mothacehe>the only blocking point is andreas router NAT
<civodul>i see
<mothacehe>but the bad news is that he won't be able to fix it soon
<civodul>ah
<mothacehe>regarding workers, I'm updating them to add ppc64le emulation support
<civodul>yay!
<civodul>awesome :-)
<mothacehe>and experiencing some issues :p
<mothacehe>i think we could then add a specification building the core subset on armhf and ppcle64
<pkill9>how do you diagnose an issue where you suspend the laptop and sometimes you open it to find the system is powered off?
<canant>pkill9 According to the abbreviated commit hash format, we can use the same length of the hash 7 chars.
<canant>->c7d04418af3d9a107330063192eee32d1457a2a5
<canant>->c7d0441
<canant>pkill9 What do you think?
<pkill9>that looks good canant
<rekado>so, I naively tried to build gnat (GCC Ada compiler), but … I need an Ada compiler :-/
<brendyyn>I think I've read that plot somewhere...
<efraim>rekado: we have ada-ed, no one's built out from there yet though
<raghavgururajan>Is there way to make `guix refresh --list-dependent foo` to give numbers?
<raghavgururajan>leoprikler: Looks like ibus can go to staging as well?
<smartineng>rekado: it's a quite old issue already https://gcc.gnu.org/legacy-ml/gcc/2007-11/msg00090.html
<abcdw>Hey guix! We are still looking for 1-2 more early adopters for guix home (declarative configuration management for user software). Today during the jitsi call I'll give a brief introduction, how to setup and use it. We'll ask you to report issues via email and provide a brief feedback after 2-3 weeks of usage experience. Let me know if you are interested.
<terpri>tfw you waste half an hour bc git submodules
<terpri>abcdw, what's guix home? the same project as https://framagit.org/tyreunom/guix-home-manager ?
<leoprikler>raghavgururajan: yep, ibus is a staging candidate
<leoprikler>unless your changes to ibus depend on other stuff on c-u, but let's hope they don't
<brendyyn>raghavgururajan: it does give numbers at the start doesn't it?
<rekado>terpri: there are two different projects that aim to manage the user’s home directory
<raghavgururajan>leoprikler: Cool! Let me know if they look good.
<raghavgururajan>brendyyn: You are right. I does.
<raghavgururajan>*it does
<ekaitz>hi all, could anyone point me to a git server configuration example? I'm looking to migrate my debian with cgit+nginx+gitolite to guix but I'm afraid of myself.. did anyone do it before? :)
<leoprikler>raghavgururajan: w.r.t. refresh: sed -ne "s/.*following \([0-9]\+\) packages.* \([0-9]\+\) dependent.*/\1 \2/p"
<raghavgururajan>Thanks!
<leoprikler>btw. you just marked it as "PATCH v2", should this be "PATCH wip-gnome v2" instead?
<leoprikler>and what happened to the missing indices?
<roptat>ekaitz, I use gitile instead of cgit (and the server is currently down for unrelated reasons), but gitolite and nginx were running well: https://framagit.org/tyreunom/system-configuration/-/blob/master/systems/ene.scm#L139
<roptat>and https://framagit.org/tyreunom/system-configuration/-/blob/master/systems/ene.scm#L181
<ekaitz>roptat: thanks!!! I'll use it as a reference, thank you very much!
<raghavgururajan>leoprikler: Yeah. the missing indices were gst patches.
<roptat>(note that gitolite is not part of guix yet, though it's free software)
<roptat>gitile
<raghavgururajan>Btw, look like we have to push ibus to c-u, as it depends on ab62cbb340aa943c56ff01da93220b3212f714dd
<roptat>gitolite *is* part of guix
<ekaitz>i don't know about gitile... i'll take a look
<leoprikler>imo you should send a "PATCH wip-gnome v3" with indices counting from 0001 again
<leoprikler>so that there's no confusion
<leoprikler>If you want to explain, that the gst patches are no longer part of it, you can do so in a cover letter.
<raghavgururajan>They are going to c-u right? I then cherry-pick them for wip-gnome.
<leoprikler>What branch are you currently on? c-u or wip-gnome?
<roptat>ekaitz, well, I host it on that server that's down, so there's nothing you can do for now :/
<ekaitz>:)
<raghavgururajan>leoprikler: I am currently in c-u.
<leoprikler>If you are currently on c-u, then yeah, address them on c-u. If you are currently on wip-gnome, then we'll have to cherry-pick them for staging/c-u (whichever is appropriate) first.
<raghavgururajan>Okay.
<leoprikler>Okay, then try to make it so that the ibus patches form a consecutive chain based on c-u.
<leoprikler>I.e. you have c-u - ibus0001 - ibus0002 - ... ibusNNNN - non-ibus-whatever
<roptat>still building the kernel since yesterday
<leoprikler>format-patch c-u..ibusNNNN
<leoprikler>claim a new bug number by sending a cover letter [PATCH core-updates 0/N] Update ibus
<leoprikler>And then send-email to that new bug number
<raghavgururajan>Why new bug no? These patches were initially sent in 47643, among gst patches. But gst patches were pushed selectively. So these are rest of the patch set.
<leoprikler>Yeah, I abused 47643 for that and I'm sorry for doing so, but we shouldn't have too many patches claiming the same bug number.
<leoprikler>It'll just be confusing.
<raghavgururajan>Okay.
<abcdw> terpri: A different one. https://git.sr.ht/~abcdw/rde/tree/master/item/examples/home-environment.scm.tmpl
<terpri>aha, thanks
<leoprikler>I think 47643 has stuff that's not Gst and not Ibus in it, so letting those non-topic changes remain in 47643 is imo the better choice
<leoprikler>However, if you want, you can also send your isolated patches to 47643, but make sure to have an appropriate cover letter then.
<leoprikler>(and also make sure to properly explain that mess to your reviewer; I'm not qualified enough to even build c-u, sadly)
<raghavgururajan>leoprikler: For cover-letter, git send-email or MUA?
<leoprikler>whichever you prefer, both work
<raghavgururajan>how did you add the brach name in git send-email?
<pineapples>Hi!
<abcdw>pineapples: Hey!)
<raghavgururajan>leoprikler: I have the bug no. 47770. How do I mention branch-name in the command `git send-email --to="47770@debbugs.gnu.org" HEAD~4`?
<nckx>raghavgururajan: --subject-prefix="PATCH core-updates"
<raghavgururajan>Thanks!
<nckx>Morning Guixen.
<raghavgururajan>nckx: How do you send a cover-letter to existing bug-thread?
<raghavgururajan>`git send-email --to="47643@debbugs.gnu.org" --subject="PATCH core-updates 0/5" --compose`??
<nckx>I think so, I don't write cover letters that way. That will reply to the initial message in that thread (the one that opened the bug). If you want more control you can look up the Message-Id header of the message to which you want to reply, then use --in-reply-to=<that>, "<>" included.
<raghavgururajan>Ah thanks!
<janneke>civodul: it seems that LD_LIBRARY_PATH (and probably LD_PRELOAD) "leak" into the binary pack relocations
<Akawama>Sice microcodes are proprietary, what is guix system's take on it?
<raghavgururajan>lle-bout[m] and iyzsong: Just letting you know that I have sent some more patches to 47643 and 47770.
<raghavgururajan>Akawama: https://guix.gnu.org/en/blog/2021/new-supported-platform-powerpc64le-linux/
<rekado>Even as far back as GCC 2.95.3 GNAT was available only as Ada source files.
<nckx>Yes.
<civodul>janneke: the wrappers don't do anything special with LD_LIBRARY_PATH, so if you define it, it has "an effect"
<civodul>as a rule of thumb, Thou Shall Not Define LD_LIBRARY_PATH
<iyzsong>raghavgururajan: nice!
<janneke>civodul: yes, i agree with that rule -- that's what i told them
*janneke is now wondering whether to reset it in wrappers scripts anyway, or not and try to educate the world
<civodul>janneke: there are legitimate uses of LD_LIBRARY_PATH, but in general, it's a dangerous tool
<janneke>yes, that's exactly why i don't really want to reset it; users should take care of that...
<civodul>it's a hard choice: i wouldn't remove the tool altogether (esp. not in wrappers because they're just a special case), but i can see that "educating the world" isn't appealing either
<civodul>rekado: i remember discussions around FOSDEM 2019 (?) where Danny explained a plan to bootstrap GNAT, in particular using an Ada parser written in Python
<civodul>that's python2-libadalang
<civodul>my recollection is that the plan sounded realistic as in "it didn't involve writing tons of things"
<civodul>(though some here have demonstrated that "writing tons of things" can *also* be realistic :-))
<nckx>civodul: Oh! Was this recorded?
<civodul>nckx: it's a discussion we had while wandering in Brussels, off-the-record :-)
<civodul>that may have been in 2018 because that's when Danny added python2-libadalang
<civodul>and python2-langkit
<clacke>oh cool
<clacke>are these ada bootstraps used?
<clacke>or are they still in proof of concept stage?
<nckx>I'm not aware of anyone bootstrapping a full Ada/GNAT compiler but it's been a while since I last looked.
<logiz>rekado: yeah I was trying to install the openjdk binaries from their archive, but wound up realizing 11 was in the package manager, whoops. Thanks for $RUNPATH
*rekado updates python(2)-langkit
<brendyyn>it was cool that you added openmolar. pity development stopped because their practice stopped using it in favour of proprietary software tho
<clacke>oh cool it's under the AdaCore org on GH
<clacke>but only an analyzer at this point apparently
<rekado>actually… the newer langkit depends on GNAT
<rekado>so … yeah. I won’t upgrade this now.
<civodul>:-/
<ekaitz>hi, does anyone know if python-pyside-2 package provides QtSvg?
<ekaitz>i'm searching in other distros and they have a separate package for that, but also for some other things that are included in our package
<civodul>roptat: hi! regarding the string freeze, one commit was reverted because it added 3 lines of doc for the mysql service
<civodul>what's your preference regarding these?
<civodul>i'd be tempted to not block small and "peripheral" changes like these, but i wonder what you think
<brendyyn>Anyone in favour of ditching gnupg for signing and using something simple like minisign?
<civodul>to sign what?
<pkill9>isn't gpg the bog standard
<brendyyn>commits for example
<brendyyn>ekaitz: looks like its not an input. it maybe be possible to insall it in the environment along side it and it will be used
<civodul>i don't think OpenPGP is well suited for all this, but Git uses it, and now Guix does too: https://guix.gnu.org/en/blog/2020/securing-updates/
<civodul>IOW, "ditching OpenPGP" isn't realistic :-)
<ekaitz>brendyyn: but we don't have it packaged then, right? PySide has QtSvg as an input, but it doesn't provide a python binding for it
<brendyyn>ditching it just means choosing not to use it for these purposes, not eradicating it everywhere
<brendyyn>ekaitz: i dont see it in the inputs
<ekaitz>hah right below qtspeech
<brendyyn>oh ok im blind
<ekaitz>:D
<ekaitz>so weirdly enough it's using it but not providing its bindings
<brendyyn>how do you test that?
<brendyyn>ekaitz: do you have guix build from git?
<ekaitz>yes
<brendyyn>ekaitz: try changing cmake-build-system to qt-build-system
<ekaitz>oh
<brendyyn>not sure if it will work but it wraps some variables
<ekaitz>i'm checking the code and it might be related with the version of pyside we are providing
<ekaitz>it might be too old IDK
<ekaitz>well, not that old because the commits are from 6 years ago so it should be included
<ekaitz>i'll try the qt-build-system
<brendyyn>what are you running to test the usage of qtsvg
<roptat_>civodul, I'd prefer if we do not change the manual and guix at all
<roptat_>the thing is, if we announce string freeze, translators don't expect changes to happen
<ekaitz>brendyyn: i'm opening an environment with pyside-2 and python and importing PySide2 and see what it exports
<roptat_>for instance, they may have downloaded the pot to work on it offline, and push it on the deadline
<roptat_>then they discover there are changes, and it's too late :/
<brendyyn>ekaitz: try adding qtbase to the environment
<ekaitz>ok
<roptat_>the problem with small peripheral changes is that they could accumulate and make translator's life harder
<brendyyn>im sorta guessing here but maybe it will be helpful
<ekaitz>btw, i found all this compiling freecad: on runtime it says it doesn't find PySide.QtSvg
<roptat_>civodul, so, unless we really have to (say we find a security vulnerability we can't delay), I'd prefer to be relatively strict on the freeze
<civodul>roptat_: alright, sounds good to me; perhaps that means we'll have to branch now?
<roptat_>we can do that any time, I don't think it's related to the freeze
<roptat_>what does branching bring us exactly?
<roptat_>does that mean we can have a release candidate to test, and fix issues on that branch until the release?
<roptat_>so the release would be based on current master rather than master on the 18?
<ekaitz>brendyyn: nah didn't work... it looks like I need to fixup the pyside-2 package or something... so there are packages that might be broken, like current freecad
<ekaitz>oh it is broken, yeah...
<ekaitz>so it looks like I have to fix another package :)
<civodul>roptat_: branching would allow people to keep working on the main branch
<civodul>we would cherry-pick relevant bits from master
<roptat_>I see, then maybe that's best
<civodul>ok
<civodul>roptat_: BTW, i'll push the fix for https://issues.guix.gnu.org/44593, and ideally i'd change "0.3.0" to "0.5.0" in guix.texi, under "Requirements"
<civodul>does such a change involve extra work for translators?
<civodul>at least manual approval i guess?
<roptat_>yep, it invalidates the string in the manual
<civodul>does weblate propose the "obvious" change in that case?
<roptat_>not really, the "obvious" change would be to suggest the previous translation, with 0.3.0
<civodul>ok, tricky
<civodul>what would you suggest?
<roptat_>if they use the web interface, it's easy, because it highlights changes in the English string, but otherwise, it's hard to tell
<roptat_>Is it ok to push the patch without changing the manual for now?
<civodul>it's not great, but acceptable in that it's a super nich functionality
<civodul>*niche
<civodul>you won't notice unless you use --with-git-url & co. with submodules
<civodul>is an @c command in guix.texi OK?
<roptat_>@c is for comments right? in that case that's OK
<civodul>yes, Texinfo comment, but i'm not sure what po4a does
<civodul>but ok, i'll assume it's fine
<civodul>tx!
***av0idr is now known as avoidr
<bavier[m]>Anyone know of an emacs feature for referencing line numbers that auto-update with changes?
<tricon>bavier[m]: That would be slick.
<bavier[m]>I'm thinking of something where I can write in a comment "See variable foo at line 27" but have that 27 adjust if there are lines removed or added.
<jas4711>civodul: hi! i'm trying to get guix-x15*.sjd.se online. does it have to be reachable on a public IP? or is inbound SSH access through a jump host sufficient? outbound connections works on the machine works fine (NAT'd)
<efraim>jas4711: many of the machines are connected with wireguard
<hpfr>bavier: I feel like this is what goto definition is for, bringing line numbers into it feels brittle. What if you move the variable to a different file?
<jas4711>efraim: running wireguard on the hosts would be the simplest -- what peer ip and public key should i use? i can send the machine's public key if someone can add it on the server
<lfam>Hey jas4711, I saw your message but was waiting for advice from the sysadmins
<jas4711>lfam: i'm happy to wait for best advice
<lfam>I'm collating the set-up steps now
<jas4711>lfam: setting up inbound ssh to the machine is quite messy for me though. wireguard running on the machines would be much easier
<lfam>We'll need to make some higher-level decisions about armhf stuff, though. We stopped building for armhf in December, although it was not a decision made by consensus, but the main CI sysadmin's formalization of the de facto situation
<jas4711>lfam: i don't have an opinion there, just happy to provide the machines if they are useful
<lfam>Now, the CI software has been improved and we are no longer limited by e.g. database problems, so we could probably re-add the armhf jobs without any problems
<lfam>I do think that, if we want to keep building for armhf, the x15 is our best bet
<jas4711>i have a rockpro64 pine64 board as well but i think that is aarch64 rather than armhf. is there aarch64 support in guix?
<lfam>Yes, there is aarch64 support, and we are building for it. We are also in the process of buying hardware to improve our capability to build for it
<lfam>With aarch64, there are actually a small number of workstation / server level options available
<lfam>To be clear, we do want to use your x15 :)
<lfam>At least, it can build core packages and substitutes for `guix pull`
<lfam>jas4711: I've tried to summon the person who can give direct advice
<lfam>jas4711: It will require something like this, I think: https://git.savannah.gnu.org/cgit/guix/maintenance.git/commit/hydra?id=c705a726c2b71e5067f1efd53f12329933593075
<lfam>IIUC, you can generate the Wireguard public key like this: `guix environment --ad-hoc wireguard-tools -- sudo -E wg`
<jas4711>lfam: the machines are running debian right now, and it pulls system configurations from a git repo. so i think that is easiest to setup now
<lfam>Yes
<lfam>Okay, we'll see what Mathieu says
<jas4711>lfam: thanks! i can set it up one side of the wg peer on each machine if you provide remote info
<guixy>Is there a build system for programs written in racket?
<lubrito>cbaines Hi! I think I might have finished my task. How should I submit my code for revision?
<sneek>Welcome back lubrito, you have 1 message!
<sneek>lubrito, nckx says: I don't know why it took so long, but your mail should've been delivered to guix-devel@ now. If you've sent anything that's still AWOL from the archives, please let me know.
<vagrantc>jas4711: beagleboard-x15?
<lubrito>nckx thanks, I don't have any missing messages. Do you think they could be delayed because I sent images?
<nckx>lubrito: If they are large (IIRC > 500 KiB or thereabouts), yes.
<lubrito>I see :)
<cbaines>lubrito, you can use git send-email to guix devel if you have that set up, otherwise generate a patch and attach that to an email, or share the location of a branch where the commits can be fetched
<bavier[m]>hpfr: my use-case would be more limited than that, so I don't think it would be an issue.
<hpfr>bavier: why wouldn't goto definition handle your use case
<bavier[m]>hpfr: I think it doesn't work for assembly source? and I'd like to reference arbitrary lines, not just be able to jump to them, for visual reasons.
<hpfr>I see thanks
<bavier[m]>thanks thinking about it
<mdevos>I don't see an installation image for GNU/Hurd on <https://guix.gnu.org/en/download/>. Is that a bug?
<civodul>mdevos: hi! that's because we're not there yet :-)
<civodul>it's at https://guix.gnu.org/en/download/latest/
<civodul>hey jas4711! thanks for looking into all this!
<jeko>Yo Guixters !
<civodul>o/
<tricon>jeko: 'Ello, gov'na!
<mdevos>civodul: Thanks!
<mdevos>Perhaps there should be a link from the "Download" page to ‘Download > latest’
<mdevos>I only now noticed the ‘Download’ link at the top has a submenu (?) Stable and Latest.
<civodul>mdevos: we don't want people to inadvertently end up on the "latest" page
<mdevos>‘You have chosen to open: "[...]-image.iso" which is: raw CD image [..] What should IceCat do with this file? [A]: Open with [VLC media player (default)] [B] Save File’. If I were a person that uses "LOL", I would write "LOL" here
<mdevos>since when performs VLC virtual machine emulation? (-:
<mdevos>civodul, makes sense, though a bit inconvenient at times
<mdevos>Perhaps place a link at the bottom along the lines: ‘GNU/Hurd is currently not well-supported, but adventurous users with some pain tolerance can download it from [link to download/latest]’?
<ekaitz>hi all, I realized that pyside2 is not finding many optional Qt modules, did we change anything on that lately?
<ekaitz>cmake says it's finding configuration files but not the modules...
<mdevos>civodul, I was wondering how file descriptor passing could be done in shepherd
<mdevos>I have an idea (partially implemented), but it has some warts
<nckx>mdevos: Making a ‘hybrid’ Guix installer ISO that not only boots both BIOS & UEFI but also plays in a DVD player would make a great easter egg.
<mdevos>one complication is that file descriptors need to be shuffled around, and we don't want to inadvertently close one we actually need
<mdevos>nckx: ‘Someone’ should do that
<nckx>Honestly, if I had time I would, skirting the limits of fs standards is straight up my alley... hmm.
<mdevos>nckx: Or if it is infeasible, add a patch to Guix' definition of VLC that recognises GNU Guix ISO's and then plays some ‘Guix music’
<nckx>We already have Guix music from the last release.
*nckx hmmmmmm.
<mdevos>civodul, on GNU/Linux, we have a /proc/self/fd file system
<vagrantc>i don't think i've done typo fixes this release cycle, we'll have to generate lyrics some other way
<mdevos>but that doesn't exist on GNU/Hurd (I've checked in a childhurd)
<lfam>It would be great to fix <https://bugs.gnu.org/47567> for the upcoming release
<mdevos>and it would probably be messy to implement
<mdevos>however
<lfam>It's registered as a block
<mdevos>the file descriptor table is purely implemented in user space on Hurd
<lfam>It seems very esoteric to use FAT16, but it's a bug
<civodul>mdevos: for file descriptor passing, you can use sendmsg, but unfortunately its libguile bindings don't support that
<civodul>i'm curious what you want to do with fd passing in the Shepherd :-)
<mdevos>civodul, something else I think. Now continuing ...
<mdevos>I have this patch that extends some .c file in Shepherd, that adds a procedure to Guile that allows you to determine a list of which file descriptors exist. Let me dig it up ...
<mdevos>here it is: <https://notabug.org/mdevos/shepherd/commit/69a9cc5be045c4ebd769e0f2b57da9342e7b778a>
<mdevos>(it's etc/open-fdes.c)
<mdevos>What I have in mind with "file descriptor passing"
<mdevos>Some daemons (all the gnunet-service-SOMETHING services if I understood the daemon code correctly, and nginx I think, probably some other daemons as well) support
<mdevos>*not* directly binding to some port, which can be a privileged operation (or we want to sandbox the daemon inside an empty network namespace), but instead listening on a passive socket, that is inherited from the init process
<mdevos>(without sendmsg + recvmsg + SCM_RIGHTS shenanigans, only by *not* closing the relevant file descriptor before exec)
<mdevos>Does that make sense?
<midnight>Adam has basically zero input into the bitcoin dev process and people, last I checked..?
<midnight>er.
<midnight>Apologies, wrong window. lol
<nckx>...psi-plus-real-real-real
<nckx>Was there no patch floating around to mitigate that?
<mdevos>Are there are Memory + Disk recommendations for a persistent Hurd in a VM?
<mdevos>Hmmm ... 703 GB (disk)available. Let's go with 40 GB
<mdevos>Oops I choose the Linux installer
<mdevos>I don't see a GNU/Hurd installer on latest (<https://guix.gnu.org/en/download/latest/>), only a VM image
<mdevos>Are there technical problems with a GNU/Hurd installer, is a GNU/Hurd installer untested, or does it work but there is no download?
<mdevos>I don't see anything relevant on <https://issues.guix.gnu.org/search?query=hurd+sort%3Aid+is%3Aopen>.
<lfam>It was probably added after the 1.2.0 release, so there is no "1.2.0 Hurd image"
<lfam>Oh, you asked, where is the installer?
<mdevos>lfam, yes, where's the GNU/Hurd installer?
<lfam>Since Hurd doesn't really run on hardware, I think we don't need an installer
<lfam>It's really a VM-only project, if I understand correctly
<mdevos>I usually create VM's by loading an installation ISO into a VM.
<mdevos>It's late, I'll try to figure something out with the qcow image later
<lfam>I think you can create a VM directly with Guix tools. Maybe like `guix system image --system=i586-gnu config.scm`
<lfam>That's the canonical method for creating Guix VMs
<civodul>--target=i586-pc-gnu rather (to cross-compile)
<lfam>Installing in a VM is supported and documented, but I figured we mostly used that for testing the installer
<mdevos>my command: guix system image -e '(@ (gnu system install) installation-os)' --target=i586-gnu --root=../hurd-install.iso -t iso9660
<mdevos>let's see how that goes ...
<mdevos>oops i586-pc-gnu
<lfam>Right
<lfam>However, I would choose to make an installer image. I'd make the installed image
<mdevos>aaargh: glib@2.26.6: build system `meson' does not support cross builds
<lfam>I mean, I *wouldn't choose to make an installer image*
<lfam>Hm
<lfam>Well, that's that I suppose
<raghavgururajan>I am very sad to see this. https://nitter.snopyta.org/gnome/status/1382361929981825024
<mdevos>lfam: I probably don't really need an installer image, but I'm used to installer images and find them rather convenient
<raghavgururajan>(leoprikler, lle-bout[m] and iyzsong) ^
<lfam>raghavgururajan: It's been de facto true for many years
<lfam>Sadly, one of many valuable projects forced out of GNU
<raghavgururajan>lfam: I heard them colloquially, but never seen officially told by GNOME.
<lfam>I'm not sure to what degree an official announcement was made, but the people involved made it known repeatedly
<lfam>It's not an uncommon situation for projects with "GNU" in their name
<Noisytoot>it's still in the GNU software list
<lfam>Sure, and GNU claims all free software as part of the "GNU system"
<Noisytoot>GNU Libreboot was successfully deGNUed (although leah wants to reGNU it)
<lfam>It's why Guix packages are namespaced as '(gnu packages)
<Noisytoot>Not all free software is GNU
<lfam>"What is GNU? GNU is an operating system that is free software"
<lfam> https://www.gnu.org/home.en.html
<Noisytoot>GNU is one specific operating system that is free software, but not all of them
<Noisytoot>GNU is not BSD
<lfam>There is no specific "GNU operating system"
<lfam>GNU has helped develop certain important components, but GNU never created an OS that you can use
<Noisytoot>lfam, Guix GNU/Hurd
<Noisytoot>I can use it in a VM
<lfam>I respectfully think you have misunderstood
<lfam>I'm not making this point of view up. It's been espoused by the GNU project for decades
<Noisytoot>GNU have a working userspace, and a working kernel (on some systems)
<mdevos>I don't really understand how GNOME can be considered non-GNU. It is historically tied to GNU (the project), it is part of GNU (the operating system, in practice used as GNU/Linux+stuff) (of course, you can choose to use an other desktop environment), it is free software, I presume the developers maintain free software values ...
<nckx>mdevos: <aaargh> It's TODO, if you feel so chosen...
<mdevos>nckx: maybe I'll try tomorrow
<Noisytoot>"The GNU operating system consists of GNU packages (programs specifically released by the GNU Project) as well as free software released by third parties."
<lfam>mdevos: What GNOME is saying is that they don't want to be associated with the GNU project, as it exists.
<civodul>mdevos: did you check https://guix.gnu.org/en/blog/2020/childhurds-and-substitutes/ ?
<civodul>in particular the use of bare-hurd.tmpl
<mdevos>I did
<civodul>hmm ok
<nckx>mdevos: Only ‘historic ties to GNU’ distinguishes it from KDE on those points.
<mdevos>question: the cow image is N bytes. But I want to give my Hurd in a VM 40 GiB or so.
<mdevos>Does that imply a 40 GiB store item would be created?
<Noisytoot>lfam, All software on non-GNU Savannah is free software, but non-GNU
<lfam>Sorry, we are talking about different things. It's okay
<lfam>mdevos: It should use the "balloon" mechanism
<lfam>If not, please let us know
<mdevos>lfam: not sure what that means. I presume things will just work. Let me test ...
<lfam>mdevos: It means the qcow2 file will inflate like a balloon as you fill the disk, up to a limit of 40 GiB
<apteryx>a service one-shot takes a lambda as its start slot... it is safe to put (use-modules ...) in this lambda? ISTR this isn't safe/good with Guile 3.
<nckx>lfam: Whoa, that's a confusing use of ‘balloon’ to mean the opposite of what it does for RAM. Is it QEMU's?
<lfam>Yes
<nckx>Sigh.
<lfam>Or maybe it's from KVM / virtio. Close enough
<nckx>I doubt it. In virtio it means the opposite (the storage equivalent would be TRIM, and that's how it's usually implemented) so that's an exceptionally poor choice of words on QEMU's part if so.
<mdevos>I don't see an option to load qcow2 into GNOME Boxes, unfortunately
<lfam>For example, `qemu-img create -f qcow2 foo.img 50G` will create a file that is <1MB
<lfam>What formats does it accept?
<mdevos>Only ISO's.
<lfam>Pity
<mdevos>I have a (non-persistent) childhurd running, so I can use --system=i586-gnu. Let's try that
<leoprikler>raghavgururajan: I don't think I understand the full context or impact of that statement, but it's a technical truth afaiu.
<leoprikler>GNOME is (if I understand correctly) not under the managerial influence of GNU and can thus do its own thing. For instance flirt with Rust.
<pkill9>why would it not be able to do that under gnu?
<avalenn>I just found out about Crev and think it has some merit.
<avalenn> https://github.com/crev-dev/cargo-crev/blob/master/cargo-crev/src/doc/getting_started.md
<lfam>pkill9: They would be able to do that within GNU
<rekado>the thing with GNU as a project is that it is so loosely tied that it barely even exists. Except when it unexpectedly does because “your boss” suddenly appeared for the first time and introduces himself with what appears to be an outlandish demand (or worse: causes a big stink and *you* suddenly get to do damage control).