IRC channel logs

<apteryx>didn't know, no!

<apteryx>janneke: python 2.7.15 fails to build now because of expired SSL certs used in the test suite: SSLError: [SSL: SSLV3_ALERT_CERTIFICATE_EXPIRED] sslv3 alert certificate expired (_ssl.c:726)

<apteryx>cbaines: ^ this is when using guix commit 897f303d2fa61497a931cf5fcb43349eb5f44c14

<apteryx>rekado: dyndns mcron job: https://issues.guix.gnu.org/64883, should work with freedns.afraid.org as well.

<xelxebar>Argh... This is killing me ibus-anthy not showing up in available input methods in ibus-setup.

<xelxebar>This was working just fine until I had to reinstall my system due to the guix shutdown bug borking my FS.

<xelxebar>Entire home directory is git-tracked, so I know that ibus-daemon invocation and environment variables are exactly as they were when everything was working previously.

<xelxebar>About the only hint I have is that starting ~/.guix-profile/libexec/ibus-setup-anthy pops up an error now: The engine xml file does not exist: /usr/local/share/ibus-anthy/enginer/default.xml

<xelxebar>A while back I did mention the issue here and noted that ~/.guix-profile/share/ibus-anthy/engine/_config.py sets paths under /usr/local instead of the profile path.

<xelxebar>Someone did mention that they'd pick up the issue, but unfortunately it still seems broken.

<xelxebar>Brute force copying ~/.guix-profile/share/ibus-anthy/engine to /usr/local/share/ibus-anthy does supress the warning dyalog, but ibus-anthy still doesn't detect anthy, even after restarting ibus.

<xelxebar>When I get it working again, I'm definitely dumping the dconf config and saving it.

<juliana[m]>Inquiry: if I've updated my email since I began contributing to Guix, am I allowed to change the email in my copyright lines?

<juliana[m]>like, submit a patch to make this change

<juliana[m]>also, I submitted this a month ago and have had no responses: https://issues.guix.gnu.org/64305 in looking more at how supported-systems is used, I think I misunderstood its purpose so the last patch can be dropped, but does anyone think they could take a look at this?

<juliana[m]>it bothers the perfectionist in me to know a package i added is, well, imperfect XD

<mange>On the email changing: there's definitely precedent for this. I think you usually add an entry to .mailmap at the same time. See e81344428726f3dae5d2a2e7bb296f46fcde6cc5 as an example.

<juliana[m]>I have submitted a patch at https://debbugs.gnu.org/cgi/bugreport.cgi?bug=64886 to perform the update in line with that commit

<mobius_>hi :) does anyone happen have any experience with the midori browser? I use icecat for most things, but I'm trying to log into edx dot org and can't bc of either scripts or something. I've tried changing every setting I can find but still can't log in

<ChocolettePalett>Try changing user-agent as well, also IceCat comes with some preinstalled extensions and you could've forgotten disabling one of them

<mobius_>hi, chocolette :) yeah I've tried messing with the extensions in icecat but i always forget to turn them back on, so i want to leave it alone for regular browsing. but i need a browser for school and education, which is why i'm trying midori

<mobius_>curious though, what do you mean by user-agent exactly?

<mobius_>i'm not familiar with how to change that

<ChocolettePalett>You need to install some extension to change it, basically "user-agent" is just a string that your browser sends to a website in order to tell the website what browser it is, what features it has, etc

<mobius_>okay, let me see what I can find out about that. thanks so much!

<iyzsong>you can also try ungoogled-chromium, which may have better success rate..

<mobius_>this is really frustrating. i keep losing connection to irc.

<iyzsong>mobius_: which irc client? use a bouncer (znc) may help.

<mobius_>i'm using hexchat

<mobius_>okay, let me check that out

<mobius_>you try and learn one thing and you have to learn ten other things lol

<ChocolettePalett>Also using ungoogled-chromium can come in handy when the educational facility requires you to use discord-googlemeet-zoom or something like that (still might require switching user-agent since such sites usually reply with "your browser is not supported")

<iyzsong>yeah, that's a cool thing 🥲

<mobius_>yeah i just installed unggoogled-c. i think it'll work better than midori. thanks so much! i'll have to look into the user-agent thingy some mroe

<mobius_>it's just going to be for school and essentials, so

<iyzsong>sigh for edu/schools, in the good old days, we do it all using hand/papers even programming homework :\

<mobius_>i actually think it'd be fun to learn how to program with punchcards :)

<mobius_>long live ada lovelace lol

<iyzsong>yeah, that would worth the unversity fees :^)

<efraim>does anyone have wifi working on their pinebook pro?

<efraim>I have a known-good atheros dongle I've tested in x86_64 machines but its like the usb ports just don't recognize it

<iyzsong>xelxebar: okay, i guess so. and write assembly need hardware knowledges which seems huge to me. yesterday i tried duskos (forth baremental x86), but unable to boot it, which show many unknowns (bios/int13h and maybe hardware faults..) lol

<xelxebar>iyzsong: Oh sweet. DuskOS is what pushed me over the edge to start learning Forth in the first place.

<xelxebar>Have you read JonesForth? It's really good.

<iyzsong>yes, but can't say i honestly learn enough from it, need re do, okay, i'll talk with you in ##forth. sorry for OT here :)

<Parnikkapore_m>is there a well-explored way to run an xorg with bug 865 patched on Guix System?

<zamfofex>Hello, Guix! 👋 About my submission of Lc0: Since the neural networks being in Guix seem to have caused some controversy, would it make sense to package Lc0 without the neural networks, and instruct users to download and use whichever neural network they might want? It’s work less transparently, and (unlike e.g. Stockfish) it won’t work without the neural networks, but that feels like a simple enough conclusion.

<alreadyamar>anyone working on a package for stable-diffusion?

<zamfofex>alreadyamar: Oh, interesting that you asked this just after my previous question! 😄

<zamfofex>There is uncertainty about whether machine learning networks should be accepted into Guix.

<alreadyamar>i guess you can consider the weights the binary?

<zamfofex>alreadyamar: There are different views on that, and different people will have different reasons as to why it either should or shouldn’t be allowed. But that is one of them.

<alreadyamar>as far as i know it's just data to be loaded into the program like a database

<zamfofex>alreadyamar: There was some disccusion on the mailing list: https://lists.gnu.org/archive/cgi-bin/namazu.cgi?query=machine+learning&idxname=guix-devel&sort=date%3Alate

<jpoiret>anyone know of standards for reproducible research? something like a file format listing all the necessary artifacts or such?

<jpoiret>I don't want to make the reproducibility data part of the git repository itself, it should be part of the artifacts imo

<Irvise>jpoiret: this page may help you https://reproducible-builds.org/

<pret7>cargo fmt

<pret7>woops wrong buffer

<xelxebar>So, my operating-system def is packaging up https://github.com/StevenBlack/hosts.git and setting hosts-file to it's /etc/hosts output.

<xelxebar>Now hosts got nicely integrated with scheme, though, so I need to find a migration strategy.

<xelxebar>Not sure of the best approach.

<xelxebar>Parsing the etc/hosts into an sexp seems overkill, so it probably makes sense to extend the new hosts-service-type with something that can concatenate files or something.

<xelxebar>Any other ideas?

<reyman>Hi guixer

<reyman>I'm have some problem to update gnome-keyring without ssh agent in version 42.1 with the latest guix pull

<reyman>one of the test fail

<reyman>ERROR: test-import process failed: -5

<reyman>what can i do ?

<ngraves>Hi !

<ngraves>I'm trying to build an image with guix system image that is based on the installation-os. I can't find what might be going wrong :

<ngraves>the build fails late, on the disk-image derivation, with the following error : /gnu/store/8w32949qhgmwd1bsismdafakn0jsvdlj-grub-2.06/sbin/grub-bios-setup: error: failed to get canonical path of `/dev/mapper/enc'.

<ngraves>In principle, since it's a guix system image, it shouldn't have anything to do with my current file system (which uses /dev/mapper/enc indeed, but with no errors).

<ngraves>With the verbose option, it's even more strange :

<ngraves>[...]

<ngraves>grub-bios-setup : information : the size of hd0 is 10569768.

<ngraves>grub-bios-setup : information : /dev/mapper/enc is not present.

<ngraves>grub-bios-setup : information : Looking for /dev/mapper/enc.

<ngraves>grub-bios-setup : information : /dev/mapper/enc is a parent of /dev/mapper/enc.

<ngraves>grub-bios-setup : information : /dev/mapper/enc is present.

<ngraves>grub-bios-setup : information : Looking for /dev/mapper/enc.

<ngraves>grub-bios-setup : information : /dev/mapper/enc is a parent of /dev/mapper/enc.

<ngraves>grub-bios-setup : information : drive = 1.

<ngraves>grub-bios-setup : erreur : guessing the root device failed, because of `disque « hostdisk//dev/mapper/enc » non disponible'.

<ngraves>Has someone faced such an issue ?

<CatDisruptor6000>ACTION uploaded an image: (75KiB) < https://libera.ems.host/_matrix/media/v3/download/maunium.net/jcTPWQdlJMMPMxslBCOtEsRh/b9K_LTz079c.jpg >

<jpoiret>ngraves: please use paste.debian.net for long pastes

<jpoiret>what's your command line?

<ngraves>In the /tmp dir generated with the -K option, I run the command : grub-bios-setup -m device.map -r hd0,msdos2 --verbose -f -s -d . images/image

<ngraves>This command is generated in the disk-image derivation. I'll try to find a reproducible minimal example of the guix system image command.

<jpoiret>i'm just looking for the `guix system image` command you're using

<jpoiret>i don't trust grub-bios-setup outside of that isolated build process

<ngraves>I can reproduce the error with guix system image --expression="(begin (use-modules (gnu system install)) installation-os)"

<old>is there a way to do package transformation at a level of a manifest file? I'm not sure how to do it

<old>I need tons of package with debug symbol, for example `git', which lack the debug output

<old>I would like to include something in a (specifications->manifest (list ...)) form so I can have git with debug output

<old>similar to what I would get with --with-debug-info=git with guix-shell

<old>I guess that I could define a new package inherit from git with the desired transformation applied and with a different name

<jpoiret>old: you can use the package transformations defined in (guix transformations) in guile

<ngraves>You can use packages->manifest function with a list of packages. You can transform then individually with (package (inherit origin-package) fields-to-replace).

<jpoiret>package transformations operate recursively on the graph of dependencies, just doing (package/inherit ...) won't be enough to replicate it

<old>oh package->manifest sounds like something I want

<jpoiret>also, please use (package/inherit package ...) instead of (package (inherit package) ...)

<old>I guess there's a way to append manifests together?

<old>jpoiret: Already doing so!

<jpoiret>you can append manifests, but packages->manifest already takes a list of packages

<old>right but says I have a (specifications->manifest ...) form for my basic packages

<jpoiret>I don't have examples of (guix transformations) used in my manifest currently since I removed them, but it should be pretty straightforward

<old>and an extra manifest

<old>okay will try!

<jpoiret>old: ah, no, you don't need to

<jpoiret>I'd even encourage *against* using specifications in your manifest file

<old>why?

<old>Passing "guile" to specifciations->manifest vs (packages->manifest guile) ?

<old>sound like I will have to import a lots of gnu modules for this to work

<old>I do not mind, but why are you against it?

<jpoiret>I have a macro translating (@p zzzz package) to (@ (gnu packages zzz) package)

<jpoiret>that makes it easier to type

<jpoiret>I don't know, specifications don't seem very declarative to me

<old>I see

<old>it lack certain details

<old>can you specify the wanted outputs with packages->manifest?

<jpoiret>yes

<old>ah okay yes

<jpoiret>you need to put (list package "out")

<jpoiret>instead of package

<old>(list foo "debug")

<old>looks nice

<old>thanks!

<jpoiret>the one annoying thing is that package transformations choke on those (list foo "debug") things, and I used to map package transformations on my package list

<jpoiret>needed some glue to make it work, but it was quite ok

<old>hmm but the transformer in options->transformation expect a package name every time

<old>That would be okay if the transformer can be applied to a whole manifest I guess or a list of package

<old>But I wonder if just adding the output "debug" is enough to get debug symbols

<old>(package/inherit git (outputs (list "out" "debug")))

<apteryx>mirai_: hi! I was looking at your docbook refactor series; any clue which package could now be simplified as a result?

<apteryx>I'd like to put it to the test

<apteryx>ACTION checks the packages having a fix-docbook phase

<jpoiret>old: no, you need to actually specify the output

<jpoiret>I have some funny-looking things in my manifest to support this

<jpoiret>old: see https://paste.debian.net/1287131/ for some ideas

<jpoiret>might be too convoluted

<jpoiret>it's still in the process of moving away from specification->package

<jpoiret>you can just map a transformer over your entire package list

<old>yes but the transformer expect a package name typically: (options->transformation '((with-debug-info . "git") ...)

<old>I would have to create this list of with-debug-info for every package that require debug info

<old>So I'm kind of duplicating things here

<old>I could also just create the transformer on the fly: (define (with-debug-info package) ((options->transformation `((with-debug-info . ,(package-name package)))) package)

<old>But then again, this uses specification based on the package name

<old>not sure if we can pass package directly to options->transformation that would be great

<graywolf>If I have a one-line (well, merging two lines into one) patch, that just changes the formatting, should that be sent as a separate patch or can I just include it the commit doing the change I actually want to make? What is preferred in Guix?

<jpoiret>old: in the end options->transformations translates to some specific guile procedures

<jpoiret>you can use transform-package-with-debug-info

<jpoiret>and if you have a long list of packages for which you want debug info, you can just create a helper function to translate a list of package names to the above declaration

<jpoiret>that's the power of Guile ™

<old>oh neat

<old>but it is not public

<jpoiret>ngraves: I could reproduce, I'm working on a temporary fix

<pjals_fox>old: just use @@

<old>(@@ (guix transformations) transform-package-with-debug-info) could break in the future

<jpoiret>you're right

<jpoiret>it's even possible that it doesn't work right now

<jpoiret>because cross-module inlining and such

<old>I mean

<old>I'm just going to copy the procedure

<old>it is 5 lines ..

<jpoiret>it's not :p

<pjals_fox>meh, i write code that is 0% standard and 5% readable

<old>oh no you're right

<ngraves>jpoiret Thanks a lot! Let me know when you succeed :)

<jpoiret>looking at the implementation though, it does seem a bit weird regarding packages with a "debug" output

<apteryx>hm, elogind failed to build on core-updates

<apteryx>nckx: are you building core-updates with cuirass on one of your machines by chance?

<old>oh well even with @@: error: transform-package-with-debug-info: unbound variable

<old>not the first time I got problem with @@

<apteryx>nckx: nevermind, the breakage is introduced by the docbook changes under test ^^'

<jpoiret>well, options->transformations it is then :)

<apteryx>mirai_: the docbook series on core-updates breaks elogind like so: https://paste.debian.net/1287134/

<old>jpoiret: I found a way that match my case I think

<old>Trying it

<old>I do not need to actually rewrite inputs package in my case

<old>I think

<old>I really only want debug symbols of package so I can instrument them

<mirai>apteryx: hi! is this the “comprehensive” one or the already merged one

<old>So I can just take a smaller portion of transform-package-with-debug-info

<old>and move it into my manifest

<apteryx>mirai: the "comprehensive" one

<mirai>apteryx: iirc the series will need a v2 that is a follow-up to remove obsolete workarounds (from memory, the git package will need some adjustments)

<mirai>but thanks for noticing the elogind thing

<mirai>is there core-updates again?

<apteryx>yes

<apteryx>revived "by mistake" by nckx, but it's useful to have it

<mirai>is there a CI/QA page for this series?

<apteryx>core-updates is not built, so no

<apteryx>it's not too long to get there on a powerful desktop though (less that 1 hour)

<mirai>re simplified packages, I'm tempted to say anything you see a substitute* when grepping for docbook

<mirai>and kdoctools?

<apteryx>elogind doesn't have any xml touching phase

<apteryx>so it's a pure regression

<apteryx>but it could be because docbook-xml is now series 5 and not 4.5

<apteryx>I'll try s/docbook-xml/docbook-xml-4.5/

<mirai>but atm isnt docbook-xml at 5?

<apteryx>worked

<apteryx>no it's at 4.5

<apteryx>which is what it's at in Debian too

<apteryx>5 is mostly unused and different enough to break things apparently

<apteryx>so maybe it should stay at 4.5

<mirai>hmmm… looks to me like a chicken and the egg problem (5 isn't that new afaik :-))

<mirai>maybe elogind could use docbook-xml-4.5 instead?

<apteryx>yeah that works

<apteryx>but then I think every docbook-xml in Guix will need changing to docbook-xml-4.5

<apteryx>not much point

<mirai>I see that the tex-team merge introduced some conflicts

<apteryx>yeah, I had to fix these

<juliana[m]>is there a simply way to add patches when modifying an existing package?

<jpoiret>ngraves: just sent something to 64593

<juliana[m]>specifically i'm trying to modify packages with (some of) these https://github.com/LekKit/patches-misc for rvvm and both uboot and opensbi are packaged using a make-<program>-package procedure

<mirai>apteryx: huh, current docbook-xml is 5.1 though

<jpoiret>juliana[m]: apart from the (package/inherit ... (source (origin (inherit (package-source ...) (patches (append (search-patches ...) (origin-patches (packgae-source ...)))))

<jpoiret>no

<juliana[m]>jpoiret: ah, that's... exactly the simplicity i wasn't sure was available and now i feel silly. thank you!

<mirai>at least `guix build docbook-xml' is returning me /gnu/store/zf02dchwi6iqq0jprdxicv02jmg5m0bl-docbook-xml-5.1

<mirai>this is at master

<mirai>I don't know what exact commit the core-updates accidental from nckx is based from

<cbaines>mirai, QA has a page for most branches (all recent ones) https://qa.guix.gnu.org/branch/core-updates

<cbaines>although there's not much information there as it thinks the merge base (the commit core-updates is based on) is a56eafd28bdafda9824a6a85e1ab974b8210f9bb, which data.qa.guix.gnu.org doesn't know about

<mirai>iirc nckx created it by pushing so the core-updates is a snapshot of whatever was the last time nckx pulled core-updated

<mirai>ah, I think I know what's up with elogind: it's using labels

<RavenJoad>How does Cuirass's Zabbix stuff work? I could never get my Cuirass workers to connect their zabbix clients to the Cuirass coordinator's zabbix server.

<mirai>apteryx: I think you already manually set elogind to use docbook-xml-4.5 as a follow-up for the first docbook series

<mirai>that branch predates your edits at 579e8fd0030

<mirai>so the “new” core-updates is actually older than the last core-updates merge

<mirai>you might not want to count on it :-)

<mirai>cbaines: thanks!

<mirai>will it re-evaluate a v2 patch for old issues?

<apteryx>mirai: no, it's newer

<apteryx>make sure to delete your old core-updates branch and fetch it anew

<apteryx>unless nckx pushed something truly old... hm.

<mirai>master = <https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/freedesktop.scm#n757>

<mirai>core-updates = <https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/freedesktop.scm?h=core-updates#n791>

<mirai>git blame: 579e8fd0030 (Maxim Cournoyer 2023-04-20 14:40:45 -0400 757) `(("docbook-xml" ,docbook-xml-4.5)

<apteryx>janneke: is util-linux buildable on the hurd?

<jpoiret>yes

<jpoiret>i was also surprised by this :)

<juliana[m]>okay sorry to bother again but in a similar vein is there a nice way to modify make flags in an inherited package?

<juliana[m]>or do i have to do. funky list modification code

<podiki[m]>hooray, cuirass is building again

<mirai>substitute-keyword-argument

<juliana[m]>💜

<apteryx>jpoiret: thanks

<juliana[m]>now for the tricky one. linux-libre.

<juliana[m]>and then all i have to do is write a system service to generate an operating-system from a given configuration and plug it into rvvm in such a way that it will cooperate nicely à la qemu-binfmt-service-type (or something idk we'll see how far i get)

<old>jpoiret: I end up with this: https://paste.sr.ht/~old/88f37e7bdc70710b13cf3f88596df1a3c4a87997

<d00s>your guile skills are much better than mine. looks nice

<juliana[m]>old: need-extra-packages? will always be truthy

<juliana[m]>you probably want something more like `(> (string-length (getenv ...) 0))`

<juliana[m]>bah parens are wrong

<juliana[m]>but hopefully you get the idea

<juliana[m]>anything except an actual #f is interpreted as truthy in guile

<pjals_fox>just pretend the missing parens are part of the ...

<old>juliana[m]: I do not mind

<old>as long as the environment is set

<old>then extra packages are enabled

<juliana[m]>ah, i see

<juliana[m]>for some reason i thought getenv returned "" when the variable wasn't set

<old>fortunately no!

<old>getenv(3) return NULL

<old>NULL != "" :-)

<juliana[m]>yes... ignore me

<juliana[m]>lol

<apteryx>where should dbus services be installed?

<apteryx>share/dbus-1/system-services or etc/dbus-1/system-services?

<apteryx>the former it seems

<apteryx> https://dbus.freedesktop.org/doc/dbus-daemon.1.html

<podiki[m]>in share also sounds like what i remember too

<podiki[m]>what do build logs like https://ci.guix.gnu.org/build/1671444/log/raw mean? that there was a substitute available but it couldn't download so the build fails instead?

<podiki[m]>141.80.167.131 is in the build farm?

<apteryx>it's in the build farm yes

<apteryx>mirai: ugh, core-updates is indeed old (meson at 0.63). I'm merging master into it now

<podiki[m]>were there many commits to core-updates post-last merge?

<podiki[m]>it should now be for real "core" changes with our new branching strategy right?

<apteryx>just a few

<podiki[m]>and regarding that error log I linked; that means something wanted to be fetched and it couldn't so the build failed, correct?

<podiki[m]>seems a bunch of failed builds on the mesa-updates spec from that right now; hard to quantify though

<apteryx>podiki[m]: I see our policy doesn't mention core-updates anymore. But yes I'd say for more than 2000 rebuilds it should go there, unless covered by a dedicated team?

<Guest61>Why is IceCat in Guix a preview version and not a seperate package like IceCat next or something like it is done with Emacs?

<podiki[m]>apteryx: agree we should clarify this. I was thinking large rebuilds should get their own branch (if not part of a team already), and use the "core-updates" label for changes really low in the tree (guix internals, fundamental build changes, etc.); not the clearest but i think we need to prevent core-updates becoming a dumping ground of unrelated changes

<Guest61>" WARNING: IceCat 102 has not yet been released by the upstream IceCat project. This is a preview release, and does not currently meet the privacy-respecting standards of the IceCat project."

<apteryx>Guest61: I think that's the way it's maintained upstream, and since it's security sensitive, keeping an old version around wouldn't be reasonable.

<podiki[m]>apteryx: maybe a question of "just" rebuilds (say a version bump to something with thousands of dependents) vs behavioral/breaking changes (major version change that removes features or changes hardware support)

<podiki[m]>something for guix-devel to discuss probably :)

<apteryx>indeed

<apteryx>there was some tension between wanting to go micro (one large rebuild on its own branch), which berlin may be able to cope with on x86 vs minimizing load by grouping more packages together, a la core-updates, for bordeaux which is not as well equipped for mass rebuilds

<apteryx>for x86 at least

<trevdev>Heya! Quick question about reproducible shell envs. Is there a simple way to explicitly set some environment variable from a guix.scm file? For example, in nix, if I want to use Cypress for end to end web interface testing, it's not gonna go well unless I build the cypress package and export the CYPRESS_BINARY=${cypress}/bin/Cypress.

<apteryx>trevdev: I used to think '(setenv "SOMETHING" "somevalue")' was working, but was then advised against it. It doesn't work when the environment is cached, IIRC.

<Guest61>apteryx: Ah okay. If I understand this correctly, it is necessary since the latest version on the official website is based on 60. Therefore since development upstream goes so slow, we are forced to use preview for security reasons?

<apteryx>I think upstream uses Guix to develop icecat nowadays, and doesn't bother updating the source on the GNU ftp? Perhaps worth asking to their mailing list.

<trevdev>apteryx: Thanks, I'll keep digging. I use a similar process to inject my `lombok.jar` file into Eglot for LSP support with Spring Boot thanks to nix-shell. Would love to figure out how to make it work with Guix.

<Guest61>apteryx: Okay thanks. Another question. I see only a package for ublock-origin-chromium. Is it used for IceCat as well? I mean the package itself is defined in "chromium-extensions.scm" and I am kinda confused now

<podiki[m]>apteryx: I didn't know about the build farm side of this, thanks. I can send a message to guix-devel later today (if you don't want to first) to get some thoughts and see how we might move forward.

<podiki[m]>(a balance of resource usage more generally and keeping things easy for the humans!)

<apteryx>sure, that'd be welcome

<podiki[m]>👍️

<rekado>xelxebar: re ibus: there’s caching of store files in ~/.cache/ibus

<rekado>after upgrades I always delete that and confirm that “ibus read-cache” and “ibus list-engine” produce the expected output

<rekado>then I kill all ibus processes, launch ibus-setup in the known-good environment and configure the input method.

<rekado>then I read the cache file again to be sure the correct file names ended up in it.

<rekado>AFAIU it’s not *just* whatever happens to be in dconf.

<juliana[m]>If I'm trying to specialize extant packages by applying patches from a different project, what is the preferred manner to obtain those patches? Right now I just copied them by hand into the gnu/packages/patches, but it occurs to me it may be better to download them from upstream and put them in the store to use that way...

<juliana[m]>these patches are for separate packages but in the same git repository, further complicating the matter

<rekado>if you don’t need the package variants to be persistent you can use the “--with-patch” transformation

<rekado>doesn’t matter where you place the patch files then

<apteryx>does 'beep' works for someone?

<apteryx>I get: beep: Error: Could not open any device

<juliana[m]>rekado: I am attempting to package versions of u-boot and opensbi that will work properly with rvvm, so I do in fact need them to be persistent

<rekado>okay

<rekado>juliana[m]: adding them to gnu/packages/patches would be the preferred way

<rekado>it’s a little clunky

<juliana[m]>thanks!

<apteryx>I've found a udev rule for beep

<rekado>the alternative is to add them to the native inputs, but then you can’t use them in the (source …) field as regular patches and have to apply them manually in a build phase

<rekado>that would be uglier

<apteryx>for the PC speaker

<juliana[m]>yeah

<rekado>it would be nice if we could declare URLs for patches

<apteryx>here's the beep pcspeaker udev rule: https://paste.debian.net/1287155/

<Ren[m]>What is the best way to just run some commands as root at startup? For context I want to have a super simple static network between this and another computer, to get it running I just need to run these commands: https://paste.debian.net/1287158/ I have tried putting them in an activation-service-type with three system* calls, but that does not seem to be the right way since it doesn't work.

<podiki[m]>Ren: take a look at static networking service: https://guix.gnu.org/en/manual/devel/en/html_node/Networking-Setup.html

<Ren[m]>Oh yes, I should have mentioned, using static network and network manager resulted in an error about having two network services "guix system: error: service 'networking' provided more than once". I don't want to set up my home network connection statically, just the direct with the other computer. Also this doesn't have anything for the iptables command I need to run anyways.

<Ren[m]>I am guessing there is a basic way to just run commands as root on startup, that is a pretty basic ask, I just can't find any examples

<podiki[m]>there's an iptables-service-type too

<podiki[m]>generally things should be specific services rather than just the raw commands, but you could look at the actual service code to see how it is run if you want to make your own service like that

<podiki[m]>i don't do any networking setup so that's the extent of my knowledge, but others do use static setups and can probably help

<apteryx>how do I produce a .pot files from a .texi file?

<apteryx>our build system does it via po4a-updatepo

<apteryx>hm, but "po4a-updatepo is deprecated. The unified po4a(1) program is more convenient and less error prone."

<Ren[m]>I didn't realize iptables-service-type could do nat rules but that worked perfectly, just need the address setup now, I'll see if NetworkManager can do it since it's what I don't want to get rid of

<RavenJoad>Unless I am being silly, can a "guix system vm" be accessed by the host? I want to test my web server before pushing to real hardware.

<juliana[m]>yes, see the manual page on invoking guix system

<apteryx>does 'perldoc' work in Guix?

<apteryx>it doesn't seem to find anything

<apteryx>oh, nevermind, it works

<apteryx>e.g.: 'perl -f print'

<apteryx>s/perl/perldoc/

<juliana[m]>RavenJoad: you may also want to look into guix container

IRC channel logs

2023-07-27.log