IRC channel logs

2022-08-23.log

back to list of logs

<nckx>As amusing as guix-commit voice mails are… is anyone else getting this spam or am I special?
<Lumine>nckx: well, it took an awful long time, but it reconfigured it finally
<Lumine>:)
<nckx>It does that…
<Lumine>Thanks for the help
<nckx>urw :3
<anhj>good morning!
<PotentialUser-89>Ok I'm back. I'm struggling to reference the cargo inputs I need. For instance, I need arc-swap. I have this line at the top of my package definition: #:use-module (gnu packages crates-io rust-arc-swap-1)
<PotentialUser-89>But I get the following error: no code for module (gnu packages crates-io rust-arc-swap-1)
<PotentialUser-89>Also, how do you do a code block in irc?
<mange>PotentialUser-89: It looks like rust-arc-swap is in the (gnu packages creates-io) module, so you need #:use-module (gnu packages crates-io), then you can reference it as the arc-swap variable.
<PotentialUser-89>mange: Yes that worked. thank you. I didn't realize you didn't have to specify the exact package in the use-module statement
<Cairn>Just learned about `specification->package`, since I finally have time to move further in the Guix manual
<Cairn>What a great interface!
<FriendFX>Hi Guix, I am using XFCE and GNU IceCat 91.0 and having trouble pasting text into a Discord chat (cutting & copying both work fine). Their support is asking for the OS version, what should I tell them? AFAIK, Guix is a "rolling release" and therefore there is no "version", am I right in that? What else could I tell them?
<mange>I'd tell them GNU Guix, and when you last updated. TBH I doubt they'll offer much support after you say that.
<FriendFX>'=D Yeah, I'm afraid you might be right.
<mange>Based on a cursory search, can you check the dom.event.clipboardevents.enabled setting in IceCat's about:config?
<FriendFX>I already told them that I use Firefox, not IceCat, just to avoid even more confusion...
<iyzsong>FriendFX: did you add the clipman panel plugin?
<iyzsong>that may help
<FriendFX>mange: To my surprise, dom.event.clipboardevents.enabled=false =$ ...shouldn't this be true? What are the implications of changing this?
<FriendFX>iyzsong: Not that I'm aware of... what's that?
<mange>I'm not 100% sure, but I think it controls whether IceCat emits oncopy/oncut/onpaste events for Javascript to intercept those actions.
<mange>If Discord is expecting to be able to intercept the onpaste event to do a more complex paste action, then it's possible IceCat just isn't letting Javascript do that.
<iyzsong>it's a plugin (widget) for xfce4-panel, which share clipboard between x and gtk
<mange>You could try to turn clipboard events on and see if that helps.
<iyzsong>yes, that dom.event thing sounds more related
<FriendFX>mange: Interesting. Discord support pages suggest to test the clipboard operation on this page https://danburzo.github.io/input-methods/index.html and everything there is working fine for me and I haven't seen that issue on any other websites, so their input element must do something different.
<mange>I think this is one of the default setting changes that IceCat makes to stock Firefox, so that would also explain why you're experiencing it in IceCat specifically.
<FriendFX>mange: I could check on my Xubuntu/Firefox machine if that setting =true... I just hope to not introduce a vulnerability (such as random websites being able to monitor my local clipboard content)... please let me know if my tinfoil hat is getting too big ;D
<mange>I don't think that setting controls pages being able to read the clipboard themselves (which is apparently under dom.events.asyncClipboard.dataTransfer), it just controls whether the pages can intercept the events that you trigger (e.g. to change what ends up in your clipboard).
<mange>Actually, that setting doesn't exist in my Firefox, so I think my information is out of date.
<mange>At any rate, reading/writing the clipboard without you triggering a cut/copy/paste operation requires the page to request the permission, so it shouldn't be possible for a page to read your clipboard without you knowing about it.
<mange>The about:config setting for that is dom.events.asyncClipboard.clipboardItem and disabled by default even in upstream Firefox.
<FriendFX>mange: Sorry, I am confused by what you said in `Actually, that setting doesn't exist in my Firefox, so I think my information is out of date` ...does that mean my IceCat is out of date?
<FriendFX>..because it still has that setting?
<FriendFX>In any case, good to know websites won't be able to read the clipboard via JavaScript, I would've found that scary.
<mange>I'm using upstream Firefox, which is version 102.0. IceCat in Guix is version 91.12.0 which is based off Firefox's ESR release. The name of this setting must have changed between those two releases.
<FriendFX>Interesting again. On my Xubuntu machine, I have Firefox 103.0 and there, `dom.event.clipboardevents.enabled=true` ...same on my partner's Win10 machine running Firefox 103.02.
<mange>Yep, because the default Firefox setting is for clipboard events to be enabled. IceCat disables it, I think here: https://git.savannah.gnu.org/cgit/gnuzilla.git/tree/data/settings.js#n127
<FriendFX>I just changed that setting to `true` here on Guix IceCat and now it's working! Thank you so much mange. I do wonder why IceCat disables it... that's certainly not obvious for new users.
<FriendFX>mange A slightly unrelated question: How did you install upstream Firefox instead of IceCat? I probably have un-done the changes IceCat introduced I found most annoying, but I do wonder whether I could just avoid such hassles in the future by using the "real thing" (which I've been mainly used to as well).
***Xenguy_ is now known as Xenguy
<mange>Unfortunately I'm not running on a Guix system at the moment, due to hardware requirements, so I have Guix installed on top of NixOS. Firefox is installed through Nix, which has it packaged in nixpkgs.
<Learning>Im running guix on a foreign distro (Triskel KDE) and it has filled up my root partition (only 18 gb). I had to delete some programs and heavy garbage collect, but i only got about 3 gb of space. My home partition is much larger, about 0.5 TB, but i learned that the file system is XFS, which apparently is much harder to resize. In the alternative, can I make guix install programs in another partition instead of root (e.g. home), and
<Learning>move the install files on larger partition? Any help would be much appreciated.
<trevdev>If I want to package something up like https://github.com/Junker/stumpwm-pamixer, which does not have any license at all, could it be contributed? Perhaps it's better to use my own channel?
<apteryx>it's better to repor the problem to upstream; after resolution it can be packaged in guix
<trevdev>Report as in send an email to one of the lists about it?
<trevdev>No as in submit a github issue
<trevdev>Sorry, tired.
<elais[m]>You don't need to package this do you? Why not just write the commands yourself?
<trevdev>The commands already exist and may be helpful for others :)
<elais[m]>If this is the usage then you should already be able to make something similar with playerctl or pactl install... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/303bf6fd568a6fd239606dfe3cd0460fc9be5ef4)
<elais[m]>Just looks like a lot to do very little.
<elais[m]>Or even just saying pamixer
<PotentialUser-89>how do specify the openssl directory for my package?
<cnx>i'm getting the following error with podman pull
<cnx>Error: writing blob: adding layer with blob "sha256:...": Error processing tar file(exit status 1): potentially insufficient UIDs or GIDs available in user namespace (requested 0:42 for /etc/gshadow): Check /etc/subuid and /etc/subgid: lchown /etc/gshadow: invalid argument
<cnx>could anyone successfully use podman?
<polyex>why is it guix-patches@gnu.org and bug-guix@gnu.org and not guix-patches@gnu.org and guix-bugs@gnu.org??
<elais[m]>Historical accident
<polyex>pls fix?
<polyex>i have ocd and it causes me anxiety
<cnx>welcome to the club?
<cnx>re podman: it seems it could be worked around with --storage-opt ignore_chown_errors=true per https://www.redhat.com/sysadmin/rootless-podman
<iyzsong>it seems GNU software lists all have bug- prefix, https://lists.gnu.org/mailman/listinfo
<elais[m]>At least his ocd will be left in tact with this knowledge
<cnx>hmmm now podman run gives me OCI runtime error: cgroups in hybrid mode not supported, drop all controllers from cgroupv2
<attila_lendvai>how come that guix pull gives me "Git error: failed to connect to github.com: No route to host", while a "ping github.com" works fine in the same terminal, repatedly? (it's on an IPv6 network with an IPv4 tunnel)
<attila_lendvai>it happened about 5 times, and now it works
***Guest8836 is now known as roptat
<polyex>can we work on guix in rust?
<polyex>like linux can do now
<cnx>what is that supposed to mean?
<polyex>like contribute to guix but with rust or its own guile and not have to use c or c++ or python
<cnx>you can propose that to the nix build system d-; but guix is mostly scheme stuff, no?
<polyex>low enough level isnt the OS in like C or smth?
<polyex>thought scheme was just higher level stuff like packages
<unmatched-paren>polyex: The daemon is in C++
<unmatched-paren>but there's no way to work on it in Rust
<unmatched-paren>that would make no sense
<unmatched-paren>the "OS" is just a bunch of third-party packages orchestrated by guix and the shepherd
<unmatched-paren>Linux is special because <mumble mumble kernel modules mumble mumble>
<Cairn>It'd be cool if `guix pack` could eventually generate flatpaks
<polyex>rewrite guix daemon in rust?
<polyex>linux kernel getting rust from bottom, guix daemon rust from top, premier linux distro
<polyex>i bet rust && scheme <3
***Dynom_ is now known as Guest7666
<Cairn>polyex: I feel like one of the appeals for Guix for a lot of people is the scheme. I'm interested in scheme, and so I wouldn't be as interested in Guix if it were written in Rust.
<Cairn>So I guess I don't quite understand your interest in doing that.
<amk>is the initiative to rewrite the guix-daemon in scheme still in the works?
<polyex>cairn well since i commented on the 1 part unmatched-paren said was in c++ dunno what ur saying about scheme. replace c++ or any other langs with scheme or rust
<polyex>wanna keep it scheme first, cool
<polyex>point is being scheme and rust, and no other crap
<Cairn>Haha, that's fair.
<polyex>like maybe a certain part of guix ecosystem or daemon itself is a frequent source of bugs, or a perf hot spot, so maybe a rewrite to rust would be right but otherwise stay scheme
<Cairn>It's kinda nice living in a world with a whole mess of languages. But I do like your ideas! So I'm internally conflicted about this 😅
<polyex>if ur gonna spend contributor brainpower it's not on scheme that's already so nice and simple but c++ will blow it out and noone's learning that shit anymore it's all rust from now on
<polyex>ya just let it stew my guy
<jpoiret>polyex: the """consensus""" (at least from what I've read) is that the guix daemon should be rewritten in guile
<jpoiret>which i agree with
<polyex>ya, nice
<polyex>so any part of guix eventually in guile, then anything generic linux in rust. kk
<jpoiret>let's say that rust is packaged in guix but would not be the language of choice for many maintainers
<jpoiret>rewriting the daemon in guile would lead to a tighter interaction with the rest of guix
<polyex>ya for sure
<polyex>better to have 1 lang for contribs to all guix too
<jpoiret>I'd tend to think that having the daemon in guile would simplify the bootstrap problems
<polyex>is shepherd in guile?
<jpoiret>yes
<polyex>siick
<polyex>where can we watch commits to guix?
<anhj>polyex: https://git.savannah.gnu.org/cgit/guix.git/ I suppose
<polyex>ty!
<polyex>1.4 coming soon?
<jbv1[m]>Hi guix, does somebody has a good ressource on how the bug tracking system works ? I would like to receive updates for a specific patch.
<jonsger[m]>jbv1: maybe https://debbugs.gnu.org/server-control.html has some infos...
<jbv1[m]>hmm I dont see a "subscribe" feature
<anhj>jbv1[m]: same, I also tried to see if there is an rss feed or something, but no luck
<declan>jbv1[m]: Only helpful if you are an Emacs user https://elpa.gnu.org/packages/doc/debbugs-ug.html . Otherwise I guess you have to stick to your email inbox or use a browser of course.
<jbv1[m]>I am so maybe I should do that yes. thanks. maybe next time that will help me avoid submitting an update for julia 1.6.7 when one for 1.8 is already in progress :)
<pinoaffe> https://issues.guix.gnu.org/57171 < could anyone review this?
<rekado_>pinoaffe: I can do that in a moment
<rekado_>I’d change the let* to let, see if we can avoid propagating pdfgrep, and remove the quoting in the synopsis.
<rekado_>we could avoid propagation by patching https://github.com/jeremy-compostella/pdfgrep/blob/master/pdfgrep.el#L59
<rekado_>maybe also line 81 (executable-find "pdfgrep")
<klm>Are there maturity/popularity/stability requirements for packages? I think my solvespace.com package might be a candidate for submission.
<rekado_>klm: this was on my list to package
<rekado_>klm: please do submit a patch
<rekado_>and X-Debbugs-Cc me (rekado@elephly.net) so I can review it right away.
<klm>rekado_: great, thanks. I'm new here, so I'll be looking forward to your feedback then :-)
<klm>But what are the package maturity requirements though? Is that documented anywhere?
<klm>rekado_: do you have any opinion on what to do with solvespace's extlib's? recursive checkout or package separately? mimalloc-2.0.6 it seems, is also used by rust-mimalloc.
<klm>I can submit a package that uses the submodules first, and perhaps we can take it from there
<rekado_>ideally we would unbundle vendored libraries
<rekado_>an exception can be made when those libraries have been modified
<rekado_>there are no maturity requirements
<rekado_>(or we wouldn’t have many packages in gnu/packages/bioinformatics.scm…)
<rekado_>packages get added when they are free software, build fine, and have users.
<rekado_>when a package falls into disrepair (fails to build, has known vulnerabilities, turns out to be malware, etc) it gets removed.
<antipode>Can this https://ci.guix.gnu.org/build/1229194/details cancelled build be restarted?
<antipode>Needed by rust-cexpr and rust-clang-sys
<rekado_>antipode: I restarted it.
<antipode>Thanks.
<klm>rekado_: I see, thanks.
<klm>`guix build --rounds=2 solvespace` is suspiciously quick to complete. isn't that supposed build from scratch twice and compare results?
<klm>(looking at bullet-point 11 on https://guix.gnu.org/manual/devel/en/html_node/Submitting-Patches.html#Submitting-Patches)
<rekado_>klm: use also --no-grafts
<rekado_>otherwise you might just be building the graft derivation twice
<rekado_>once you’ve built it already do “guix build --no-grafts --check -K solvespace” instead
<rekado_>rounds will not rebuild something you’ve already built before; but --check will
<klm>rekado_: Ah, yes, --check triggers new build. Does that mean bullet-point 11 in "Submitting Patches" should be updated, or am I misunderstanding something?
<rekado_>that section assumes you are building the package for the first time
<rekado_>I think that’s a bad assumption, because often we will try to build the thing, let it fail, tweak it, build again, etc, until it finally succeeds
<rekado_>only *then* do we check for reproducibility
<rekado_>at that point --check is really the only option
<rekado_>the section is not wrong, but I’d change it to better reflect the actual packaging process
***wielaard is now known as mjw
<klm>I've got `sudo reboot`, but how do I `sudo poweroff`?
<pkill9>loginctl poweroff
<bjc>sudo halt
<fanquake>Hi
<fanquake>Quick question in regards to the autotools:libtool package.
<fanquake>It was updated to 2.4.7 in 1da2834720c99c3707d17e4bf12e409b1a374b29. However as of master (d26b29d263e2a3ce5c7ef446f4bfcdcec75ab39f) it's back to 2.4.6.
<fanquake>Was the update reverted, or has there been some sort of silent merge conflict/similar that resulted in a reversion?
<fanquake>I can't seem to find a reversion commit. Other than 5b6b731c7d8ecbae0ead1600b4cd2f70c66d51ca, which supposedly was only meant to remove a duplicate 2.4.7 package.
<fanquake>Thanks
<mroh>fanquake: 1da2834720c99c3707d17e4bf12e409b1a374b29 was on branch core-updates and its still on that version, afaik.
<fanquake>mroh: we currently use a time-machine based on commit 998eda3067c7d21e0d9bb3310d2f5a14b8f1c681 (which is on the master branch), which includes a libtool-2.4.7 package and libtool (2.4.6). If we update to the latest commit on the master branch, the libtool-2.4.7 package has disappeared and libtool is still version 2.4.6.
<fanquake>So was the libtool-2.4.7 package just dropped from master for some reason then?
<mroh>fanquake: yes, in 5b6b731c7d8ecbae0ead1600b4cd2f70c66d51ca
<fanquake>mroh: right, but what's it a duplicate of then?
<mroh>idk, sorry. imho, the commit msg is misleading.
<fanquake>yea, the commit message doesn't make any sense at all
<fanquake>I'll just open an issue
<KarlJoad>Cuirass is not playing well with my guix-deploy machine configurations. The `guix pull` fails because the deploy operating-system record is technically incomplete.
<KarlJoad>Also, what does the `/var/cuirass/cuirass-mailer` mail script look like on the CI servers? I want to set up email notifications for my channel on my CI server.
<apteryx>KarlJoad: check the guix-maintenance repository
<apteryx>hm, last guix revision failed to build with error: guix offload: error: corrupt input while restoring '/gnu/store/kqwxpdlnksw1pafl79la8rn9z2n22b0n-guix-packages-base' from #<input-output: channel (open) 7f9bec7478c0>
<KarlJoad>That's where I found the sendmail command. I guess I should just clone the repo and do a quick `find`.
<KarlJoad>apteryx: Running `find . \( -name cuirass-mailer \) -ls` in the maintenance repo did not find anything.
<efraim>jbv1[m]: I'm near finished reviewing your julia 1.6.7 patch. I made the test suite pass and I have another build through before I test build the julia packages
<jbv1[m]>nice thanks
<jbv1[m]>efraim: what do you think about splitting out the stdlibs packages in the future?
<efraim>I hadn't really thought about it much
<KarlJoad>apteryx: In fact, the only instance of that sendmail command path is when it is called. It does not appear to be defined in the repository.
<nckx>KarlJoad: https://paste.debian.net/plainh/5e1961f9
<KarlJoad>I guess the next thing I should look into is the .rc conf file.
<KarlJoad>Thanks nckx!
<raghavgururajan>su: Not setuid and you are not root, expect this to fail
<raghavgururajan>Wasn't sure I was dreaming.
<jesse->hi all! does anyone have experience with installing Guix System on a new Dell XPS13? I tried the GUI installer but it does not recognize the network device or SSD so I think I need some drivers. could use some pointers how to proceed :)
<pashencija[m]>What kind of installer image do you use?
<pashencija[m]>If you're trying to use so-called "stable", then its kernel is probably too outdated for your device
<jesse->I was using the one linked in the docs (guix-system-install-1.3.0.x86_64-linux.iso)
<PotentialUser-89>My package definition is failing to build rust-openssl-sys with this message:   Could not find directory of OpenSSL installation, and this `-sys` crate cannot proceed without this knowledge. If OpenSSL is installed and this crate had trouble finding it, you can set the `OPENSSL_DIR` environment variable for the compilation process. How do I
<PotentialUser-89>fix this?
<jesse->I will build an installer image from the latest release, see if that helps
<rekado_>PotentialUser-89: set the OPENSSL_DIR variable in a build phase
<rekado_>PotentialUser-89: depending on the package you’re building you might be able to just add pkg-config and openssl to the inputs.
<PotentialUser-89>rekado_: thank you. I'm kinda new to all of this. How do I set the variable? do you have a reference you could point me to? openssl and pkg-config are already inputs to the rust-openssl-sys package defined in crates-io.scm. Do I need to provide them as inputs to my package?
<rekado_>PotentialUser-89: due to the way that rust package compilation works you may in fact have to add them as inputs to your package.
<rekado_>(I’m new to rust packaging myself)
<rekado_>I’m having a similar problem with rust-libz-sys in a package I’m working on right now.
<unmatched-paren>rekado_, PotentialUser-89: I think the alacritty package needs to do some patching of its dependencies because of this
<PotentialUser-89>I added openssl and pkg-config as dependencies and the build completed
***mark__ is now known as mjw
<muradm>hi guix
<muradm>apteryx: I could not understand your comment on this https://paste.rs/JRw
<jesse->pashencija[m]: using the latest install image it managed to see the SSD, thanks! but the installation still fails because there is no network (the installer tries to download packages). any ideas how to get the network driver recognized?
<unmatched-paren>jesse-: You have an Intel wireless card, I guess?
<pashencija[m]>jesse-: I can give you a bad idea
<pashencija[m]>You can connect you phone in usb tethering mode. This is not the best fix, but at least you'll install the system!
<pashencija[m]>That's what I did on my device that had network issues in the past
<pashencija[m]>Well, that's if you have a phone and it supports this mode. I'm not of much help otherwise
<unmatched-paren>Ah, yeah, I remember now; even with an ath9k dongle, the installer refused to connect to wifi
<unmatched-paren>I just used ethernet, that worked -.o.-
<pashencija[m]>My ethernet also didn't work so the phone connected via USB was the easiest solution
<pashencija[m]>jessie- didn't specify if their network is wireless
<sneek>Yey! atka is back!!
<nckx>KarlJoad: Sorry, I didn't know it would be useful. Here it is: https://paste.debian.net/plainh/dd6ba59a
<apteryx>muradm: nevermind, I think what I had on mind is not applicable (at least easily) here
***badc0dec is now known as TopExpert
<muradm>apteryx: nevermind, I solved it with ~@[~] :D
<apteryx>oh, fun :-)
<jesse->thanks guys for the tips! i will try to tether through USB with my phone to get the installation going. it is an XPS13 Plus that i just gut, pressumably with an intel wireless card
<nckx>Those are nice. I considered buying one.
<nckx>I know, great story, thanks.
***justache is now known as justache_
***justache_ is now known as justache
<muradm>apteryx: commented out line didn't work.. any idea why? https://paste.rs/MAo
<muradm>ahh.. i see, compose will take argument, which in lambda is ignored
<muradm>apteryx: 56608 updated. after i sent emails i realized that i missed shepherd-action thing
<supdood[m]>Where are the best notes on sysv-init commands for guix? Im struggling to rectify a guix package manager(foreign) install on Devuan.
<muradm>apteryx: nevermind, i will separate mail on that.
<Guest6034>hi
<PotentialUser-89>Alright. I got octocrab to build successfully. It is not a crates.io package it is hosted on github. How do I include it in the package that requires it? The package has this line:
<PotentialUser-89>octocrab = { git = "https://github.com/XAMPPRocky/octocrab", rev = "c78edcd87fa5edcd5a6d0d0878b2a8d020802c40" }
<PotentialUser-89>Do I have to replace that line? or is there a way to tell my package it doesn't need to go to github to get the source?
<jts>Hey, I just went to update my system and noticed `rtl8812au-aircrack-ng-linux-module` is no longer available? I need that to have wifi on the desktop I'm writing this on. Does anyone know why it was removed?
<nckx>It was non-free.
<nckx>Well, it had a ‘GPL’ binary blob in it, to be precise.
<jts>Darn binary blobs! well. I bought this wifi dongle explicitly because it was listed has having a free driver. guess I'll have to figure something else out...
<nckx>Wow.
<nckx>That's a shame :(
<nckx>Where was it listed?
<jts>let me see if I can find the website... it was GNU-supporting iirc, but not the official list of hardware
<nckx>Here's the problem: https://github.com/aircrack-ng/rtl8812au/blob/v5.6.4.2/hal/rtl8812a/hal8812a_fw.c
<nckx>(There are several such files, and I think each supported model needs one.)
<jts>gosh, companies will really just write binary data in an array and say it's free software, huh?
<nckx>Seems so :-/ Unless your mystery source points to a truly-free driver (the aircrack-ng fork was significantly augmented after all), which would be wonderful.
<nckx>Or maybe it is possible to meaningfully deblob the driver. But when I tried and removed the deleted files from the Makefile, it sure looked like nothing sensible remained to build.
<nckx>I didn't try modifying the actual C code to make loading attempts a no-op or anything, though.
<nckx>I no longer own any supported hardware.
<jts>well, presumably this is an 8-bit ISA; it might be possible to figure out which one and at least write assembly. assuming it's not a proprietary ISA, of course, which is unfortunately probable...
<muradm>nckx: hi, gnu/bootloader.scm exports bootloader-configuration-additional-configuration is it a bug?
<nckx>muradm: …why?
<muradm>nckx: there is no such field as additional-configuration?.. ripgrep on guix shows only one occurence which is in list of exports
<nckx>Ah.
<nckx>Then yes, because that field used to exist.
<nckx>I don't use ripgrep but assume it's a grep clone? Or is it something fancy that integrates with git?
<nckx>muradm: Yeah, so it was added in <https://git.savannah.gnu.org/cgit/guix.git/commit/?id=b09a8da4a2e>, then removed in <https://git.savannah.gnu.org/cgit/guix.git/commit/?id=8a0e1bb12b>, but the export was overlooked.
<nckx>(Fixed.)
<muradm>nckx: I tought you will ask for patch.. :D then 57369 should be closed :)
<KarlJoad>nckx: Thanks for the config! Hopefully I can get something going easily
<KarlJoad>Cuirass is not playing well with my guix-deploy machine configurations. The `guix pull` fails because the deploy operating-system record is technically incomplete.
<muradm>nckx: (closed)
<nckx>muradm: Ah, sorry, seemed as easy to do as to ask.
<nckx>I feel silly when announcing a trivial patch (‘don't worry little one, BASED DEV will fix it’), but I guess it's better to do so than not. Sorry again.
<muradm>nckx: no issue.. )
<muradm>literally :D
<nckx>[Somewhere, unmatched paren wakes up in a cold sweat.]
<muradm>ahaha
<nckx>I think it was here that someone tried to convince me that ‘)’ is now how the kids write ‘:)’ which is how the kids wrote ‘:-)’. I'm still not sure if they were pranking me.
<nckx>And I'm all about the fellow kids.
<nckx>KarlJoad: On the head or build node(s)?
<nckx>Because we use ‘guix deploy’ on berlin build nodes…
<muradm>nckx: hardly I can be counted as kid :D
*muradm afk.. zzz...
<nckx>o/
<Cairn>Heya Guix. If the linter says "updater 'generic-git' failed to find upstream releases", is there some way to specify that? Releases exist for this package.
<Cairn>Or am I misinterpreting that line?
<Grimpper>Hello. Not sure if this is the place to ask. Anyone knows how to install specific libraries in Guix? For example libfuse.so.2 or libz.so.1.
<Grimpper>I'm trying to use patchelf to change the rpath of some Appimages but I cannot figure out how to find which package holds which library. I found that the package "zlib" holds the libz.so.1 but cannot figure out how to get libfuse.
<nckx>Cairn: It might be possible, depends on the details. grep for release-tag-{prefix,suffix,version-delimiter}.
<Cairn>Hmm
<nckx>Grimpper: There is no way (‘yet’, but don't hold your breath) to map package contents back to package names, sorry. ‘libfuse.so.2’ is provided by the ‘fuse@2’ package.
<nckx>A very rough rule of thumb is that Guix does not add ‘lib’ to random packages like some other distributions do. If a Guix package starts with ‘lib’ it's because upstream uses that. Although there are exceptions where a spurious ‘lib’ prefix slipped through review.
<nckx>Oh and zlib is just weird :)
<Cairn>Looks like the linter throws this same upstream releases issue for Harmonist, which is already packaged. So I'm just gonna leave the issue I suppose...
<nckx>Counterpoint: it would be great if you'd fix it.
<nckx>
<Cairn>Seems like a symptom of some larger problem with generic-git. I guess I'll investigate =)
<nckx>Is there a reason you're not mentioning this package by name?
<Grimpper>Alright, really appreciate your help. How can i find the fuse@2 package? it does not seem to be on the repos? I can only see the normal "fuse" package
<Cairn>Oh, just cause I'm just starting packaging it. It's called Boohu, and it's made by the same person who made harmonist. Harmonist is already in Guix, so I thought I'd package Boohu.
<nckx>Cairn: You're not wrong, but the problem is it already throws false positives (in its defence, I've only seen it happen on crazy upstreams). Those are so annoying that any attempt to make it more clever would have to be carefully considered.
<nckx>Grimpper: How are you searching? ‘guix show fuse’ shows both here, and ‘guix search fuse’ also nicely places them both at the top of search results.
<nckx>Which is… not always the case.
*nckx TIL ‘turn-based coffee-break roguelike’ o_O
<Grimpper>"guix search fuse" only shows me the fuse package. After that one it comes the "python-llfuse" package. Am I missing a package?
<nckx>Grimpper: Which version of fuse does it show?
<nckx>I wonder if your guix is very old…
<Grimpper>2.9.9
<nckx>That's fuse@2.
<nckx>‘@’ on the Guix CLI means ‘version’.
<nckx>It's matched semi-intelligently, so fuse@2.9.9 == fuse@2.9 == fuse@2.
<nckx>And in your case == fuse, but I think your Guix is old. It won't hurt here but it's still suspicious. I have fuse@3.10.5 *and* fuse@2.9.9.
<Cairn>nckx: I see in the news file that "generic-git" is a new updater for 1.4.0... But I still have it on my system right? I ran `guix pull` this morning.
<nckx>If I type ‘guix install fuse’ it would install the higher number, fuse@3, which no longer provides libfuse.so.2, which is why I suggested fuse@2.
<nckx>Cairn: ‘1.4.0’ = ‘some future commit on master’.
<nckx>We're all running v1.4.0-pre<mystery number> :)
<Cairn>Makes sense
<nckx>So, if I parse you correctly: ‘yes’?
<nckx>Try at least adding (properties '((release-tag-prefix . "v")).
<nckx>I even see (release-tag-version-delimiter . ".") in some packages, which is… weird.
<nckx>Maybe I'm misinterpreting its meaning. I didn't read the code.
<Grimpper>nckx: Thanks for the explanation!
<nckx>I hope you manage to figure out any other libfoos yourself, but don't hesitate to ask.
<Cairn>Oh, question. Should I always leave off ".git" in a URL? In the case of this git host, it's warning about always redirecting to the ".git" URL.
<nckx>Sometimes, asking ‘hey could someone with a huge store + fast SSD run ls /gnu/store/*/foo’ really is the only way to find an obscure file.
<Cairn>But I got a warning about having ".git" on a github source. I guess the redirection isn't a problem as long as it's getting there, right?
<nckx>It redirects to .git on a GitHub URL?
<nckx>Really?
<Cairn>No, on this particular git host Boohu's using
<nckx>Oh.
<nckx>OK. That makes more sense.
<nckx>You should use the canonical URL, which is one that doesn't redirect :)
<Cairn>I see. Will do.
<nckx>So the tuxfamily server likes .git, and redirects people who forget it to it, so we use it.
<nckx>GitHub does the opposite.
<Cairn>Interesting.
<nckx>What you saw wasn't a general rule about ‘avoid .git’, but ‘follow the server’.
<nckx>I can understand how that's not obvious at all.
<Cairn>I think this is the last straw for me with Guix /s
<Cairn>Non-obvious linter warning? Unforgivable.
<nckx>Cairn: Bye, enjoy Gentoo.
<Cairn>Haha
<nckx>(Is there an FSF-endorsed Gentoo fork? This oversight in meme power is what's unforgivable.)
<nckx>Well, there is Parabola, at least.
<nckx>Cairn: If you can suggest a better warning (that isn't much longer, ideally), please do.
<Cairn>Hm, let me look at the current warning.
<acrow>vagrantc: fixes for debian-copyrighter are in ... next up would be the u-boot challenge
<vagrantc>acrow: cool!
<nckx>Oh, you remind me.
<Cairn>nckx: So the warning is "permanent redirect from [url] to [url]", and I guess my confusion comes from that not sounding like it requires action. Like, it's a warning, but it's just saying "hey look, this gets redirected".
<nckx>pashencija[m]: Vagrantc replied to the contentious thread before I did, and I was glad to see it. Most of the stuff I had drafted, Vagrant said as well, but with, like, knowledge and facts and experience behind it. So my opinion would have been redundant. All I would have added would have been: please, calm down and assume better faith on both sides, both you and Maxime.
<nckx>No more of this ‘I looked it up’ ‘no you didn't’ business please.
<pashencija[m]>Meow
<nckx>🐈
<vagrantc>nckx: :)
<Cairn>Maybe something like "suggested changing [url] to [url] due to permanent redirect". Not sure how linter verbiage is normally, let me check.
<pashencija[m]>Vagrantc, thank you for your email!
<nckx>Cairn: Hm, well, no, it is certainly intended to be actionable. A permanent redirect is the server telling you ‘this has moved forever, please update your bookmarks and post-it notes’, so we'd like the URLs in Guix to match. My concern was that you seemed to take it as a ‘always add/remove .git’ rule, which would be bad?
<vagrantc>oops, i was overly aggressive in removing the "who said what" headers. :/
<nckx>vagrantc: I'm not kidding, it was such a relief to see it land :)
<nckx>vagrantc: Maybe for the best, considering the direction it was heading.
<Cairn>nckx: Yeah, so I guess if the linter just plainly says that the url should be changed to its redirect, then it won't sound like a vague rule.
<Cairn>Reading through other wording examples in lint.scm
<nckx>Oh, I see.
<nckx>I've used unix for too long. I don't even see passive-aggression in error messages anymore. You're absolutely right.
<nckx>It should say ‘do this‘ rather than ‘uh oh, look, a thing! anyway bye’.
<Cairn>Yeah, I think so.
<nckx>Patch very welcome.
<Cairn>I mean, it already knows what the url should be changed to anyway, since it's a redirect.
<Cairn>I'll write a patch, and then I'll write a v2 of that patch since I'll have probably messed it up
<acrow>vagrantc: https://paste.debian.net/1251514/
<Cairn>How much of a change justifies adding your copyright info to the top of a file? I forgot to add my info in v1 of my hydroxide patchset.
<nckx>Well, the other side of the coin is: there are a ridiculous number of servers/webmasters who don't know what redirects are/mean, and who will *permanently* redirect https://www.mycoolsoft.com to https://www.mycoolsoft.com/wiki/Main_page. Which is wrong, semantically, but Guix doesn't know, so it tells folks to change the home-page.
<Cairn>Well, it also seems like very few of these messages are telling you to do something, but are doing what you described as unixy where they just say "this is happening"
<nckx>Cairn: All ‘N lines or more’ rules are nonsense, so there is no right answer. Just go with your own feeling of what's ‘a significant creative contribution’, which is what matters.
<nckx>Cairn: Well, the ‘other side’ above was to explain why that's a tempting strategy, unfortunately.
<Cairn>Fair enough!
<Cairn>Ah
<nckx>Otherwise, you will occasionally tell people to do something silly. But! The good news is that here it doesn't apply, I think.
<Cairn>I think the "formatting: tabulation" error was obvious enough. I was like "oh, tabs, got it". I don't think it would be improved by saying "formatting: remove tabs on this line" or something
<Cairn>I guess I'm still thinking of wording. I'll probably send boohu as a patch, then figure this out later.