bug#71567: python tkinter library not found in guix shell

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

Hi Timothee,

On 15 June 2024 10:22:32 UTC, timotheemathieu--- via Bug reports for GNU Guix 
 wrote:
>According to https://issues.guix.gnu.org/20889 I believed that tkinter should 
>be automatically included into python

Not quite.  Quoting Ludo' in that thread:

  "I think we should move tkinter*.so to a separate output of the Python 
packages"

And indeed:

  ~ λ guix show python
  name: python
  version: 3.10.7
  outputs:
  + tk: [description missing]
  + idle: [description missing]
  + out: everything else
  [...]

So there's no bug, you just never included tkinter in your environment when you 
thought you had.

Iinstead of

>guix shell -CN  python tk tcl -- python3 -m tkinter

try

  ~ λ guix shell -CN python{,:tk} -- python3 -m tkinter

'python{,:tk}' is bash shorthand that expands to 'python python:tk'.

I get a $DISPLAY error because this machine doesn't run X, but that implies 
success, right?



Kind regards,

T G-R

Sent on the go.  Excuse or enjoy my brevity.

bug#36069: "cirrus" added to VM initrd modules

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

I pushed a version of Ludo's suggestion earlier today.  And yes, cirrus is what 
we want here.

Kind regards,

T G-R

Sent on the go.  Excuse or enjoy my brevity.

bug#66746: LUKS password prompt invisible, prompts twice

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

I’m also getting this bug (the second decrypt screen not showing up) 
with
Linux kernel versions 6.5.8 and 6.5.9 (the latest version as of 
writing);

6.5.7 does not have the bug for me.


Oh, this might be interesting…  At least it's something.

Could you diff a working 6.5.7 and broken 6.5.8 configuration?  The 
configuration is stored as /gnu/store/…-linux-libre-6.5.x/.config; 
there's no need to boot the kernel just to load the config.gz module.


If you use Coreboot or a derivative: do your broken kernels include 
?


And if they do, have you tried booting with

  (initrd-modules (cons "framebuffer-coreboot" %base-initrd-modules))

by any chance?

Kind regards,

T G-R

Sent from a Web browser.  Excuse or enjoy my brevity.

bug#65720: [PATCH] git: Shell out to ‘git gc’ when necessary.

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

>Why not trigger it by “guix gc”?

Unless there's a new option I missed, guix gc doesn't handle this.

>Well, I expect “guix gc” to take some time and I choose when.  However,
>I want “guix pull” or “guix time-machine” to be as fast as possible

I don't think that things should be pushed into guix gc merely because they are 
slow.

This is not a great post (I'd look at the git code if I were at a computer) but 
I remember git printing something like 'optimising repository in the 
background'.  Maybe something similar would be appropriate here, to better hide 
such housekeeping from the user.


Kind regards,

T G-R

Sent on the go.  Excuse or enjoy my brevity.

bug#66651:

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

On 2023-10-20 21:39, Hugo Buddelmeijer wrote:

This issue can be closed as far as I'm concerned, but I don't know how
to do that. Let's try this:

/close


Add ‘-done’ or ‘-close’ to the bug address, as I've done here.

Kind regards,

T G-R

Sent from a Web browser.  Excuse or enjoy my brevity.

bug#66653: Should 'guix pack', 'install', ... accept '-f'?

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

Hi all,

I feel like that everything that could build a package should accept the 
'standard build options' like -f.

Does anyone have arguments against it?

Kind regards,

T G-R

Sent on the go.  Excuse or enjoy my brevity.

bug#66358: Some options are really subcommands + ignore arguments

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

retitle 66358 Some options are really subcommands + ignore arguments
thanks

Today, we learn that ‘ and ’ are non-free:


Processing commands for cont...@debbugs.gnu.org:

retitle 66358 ‘guix archive --{authorize,import,…}’ are really
Failed to set the title of 66358: Non-printable characters are not 
allowed in bug titles.


All are bugs, bugs are all.

Kind regards,

T G-R

Sent from a Web browser.  Excuse or enjoy my brevity.

bug#66358: Can't import package using archive command

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

retitle 66358 ‘guix archive --{authorize,import,…}’ are really 
subcommands + ignore some arguments

thanks

Hi Daniel,

The error is correct, so I sure hope it's reproducible!

Later options cancel out previous ones, so your ‘--authorize’ action 
takes precedence over ‘--import’.  You're passing it a binary .nar 
archive as a private key (which is an s-expression).


Boom.

Instead:

  1.  guix archive --export hello > hello.nar
  2.  guix archive --authorize < export-host.private-key
  3.  guix archive --import < hello.nar

Note that you had an extra ‘hello’ in your --import command as well.  
Please note that it does nothing.  Option parsing in Guix is 
surprisingly lax.


I started thinking about a nice way to make ‘--action’ options mutually 
exclusive, but reconsidered.  I think it would violate POLA if not 
POSIX.


I think it would be less surprising if these ‘single, mutually exclusive 
actions’ should always be (sub)subcommands, e.g., ‘guix archive import’, 
‘guix archive authorize’, …


I don't know if that change is still worth making here.

Kind regards,

T G-R

Sent from a Web browser.  Excuse or enjoy my brevity.

bug#66222: Fail to build guix documentation

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

Hi!

You're using an old Guix that predates the fix for this old bug, here: 
https://git.savannah.gnu.org/cgit/guix.git/commit/?id=352c49e1a5c48eb76389ee384eb95fc2e4a6ab32


Is there a reason you can't upgrade Guix with ‘guix pull’?

Kind regards,

T G-R

Sent from a Web browser.  Excuse or enjoy my brevity.

bug#65881: FSDG violation in alex4

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

Thanks.  Removed in commit 15fdeaeb2d4df755811db92cc7c3c7cb19155dec.

Kind regards,

T G-R

Sent from a Web browser.  Excuse or enjoy my brevity.

bug#66072: Duplicate/conflicting definitions for ocl-icd

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

Hi Lars, Guillaume,

Thanks for catching the duplicate!  I removed the ‘deprecated’ one in 
commit 71ec12d8bacd3901e8c7853d3c9403f3d09dfb31.


On 2023-09-18 16:23, Lars-Dominik Braun wrote:

Which is the good one?


according to commit 4d1157fca7627c11672df0cd80fae4f4d27e2185 ocl-icd
was dead, which is why I replaced it.


It's not clear to me how opencl-icd-loader is related to ocl-icd, so I 
can't partake in that discussion.  They look like totally different 
packages to me.


My only motivation was to fix beignet, which was broken by the 
ocl-icd(.h) removal.


Kind regards,

T G-R

Sent from a Web browser.  Excuse or enjoy my brevity.

bug#34828: [PATCH] Update psmisc to 23.6.

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

Hi mikadoZero & Bruno,

I pushed #62348 patches 1 & 2 to master as 
32b4f59433df620ab8f4b9a6c523f8ef9500d75d et al.  I fixed a minor typo 
(‘file-system’) and added a full stop.


The update patch (3/3) went to core-updates as 
725b2528a65edf7425762b99330ab1c9bd33bc86.


Thanks!

T G-R

Sent from a Web browser.  Excuse or enjoy my brevity.

bug#65056: https://issues.guix.gnu.org/ cannot be accessed through Tor

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

On 13 August 2023 00:25:51 UTC, "Ludovic Courtès"  wrote:
>I think it’s worse than this.  I noticed that ci.guix.gnu.org (same
>machine) would occasionally time out on my side, without Tor, starting
>from this week (I was on vacation before, so I don’t know exactly when
>it started).  From a browser, I get this “DoS attack” HTML page:

Oh, wow.  This is new to me.

It's frustrating that $IT keeps adding new significant hurdles with apparently 
0 communications, and that our only option is often 'ask rekado, again, to ask 
things, again'.  That's not right.

Ricardo, do you think there's a chance this trend will improve (without you 
burning out)?

Otherwise, I'd like to suggest wireguarding berlin's impressive hardware 
resources to bayfront or to a new head node not hosted at the MDC, or something 
similarly provocative.  Just give up on hosting public services there, like we 
already migrated the home page.  This isn't meaningful redundancy.


Kind regards,

T G-R

Sent on the go.  Excuse or enjoy my brevity.

bug#65225: ‘guix shell --system=ALIEN’ builds for both systems

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

Oh OK.

the code that's injecting a spurious extra ‘(system . 
(%current-system))’ that's causing these double builds


is not actually the problem.  Instead, the profile hooks are 
unconditionally built for the host's (%current-system).  Forcing them to 
match ‘--system=’ does the trick.  Simple™!


Kind regards,

T G-R

Sent from a Web browser.  Excuse or enjoy my brevity.

bug#65225: [PATCH] environment: Build the profile for the requested system.

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

Previously, ‘--system=’ did not affect profile hooks, meaning that all
packages would be built for both the host and requested systems.

* guix/scripts/environment.scm (guix-environment*): Parameterize
%current-system to match the requested ‘--system=’.

Reported by ekaitz in #guix.
---
 guix/scripts/environment.scm | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/guix/scripts/environment.scm b/guix/scripts/environment.scm
index 9712389842..27f7e53549 100644
--- a/guix/scripts/environment.scm
+++ b/guix/scripts/environment.scm
@@ -1146,7 +1146,8 @@ (define (guix-environment* opts)
   (warning (G_ "no packages specified; creating an empty 
environment~%")))
 
 ;; Use the bootstrap Guile when requested.
-(parameterize ((%graft? (assoc-ref opts 'graft?))
+(parameterize ((%current-system system)
+   (%graft? (assoc-ref opts 'graft?))
(%guile-for-build
 (and store-needed?
  (package-derivation

base-commit: 9e71d4fd6b3893ae87cb079b57d7a8fe6e9e7914
-- 
2.41.0

bug#65225: ‘guix shell --system=ALIEN’ builds for both systems

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

Oh, OK.

Parts of scripts/shell.scm (and perhaps environment.scm) assume that

$ guix build --system={x86_64,riscv64}-linux foo

is equivalent to

$ guix build --system=riscv64-linux foo

It's not.  This includes and causes things like commit 
9c513303156b418567b9d2cde9f8df66190051ac.  There's a lot of fast & loose 
assoc-reffing going on here that makes me nervous.


Anyway, I'll get me to a PC and then fix the code that's injecting a 
spurious extra ‘(system . (%current-system))’ that's causing these 
double builds.  Simple™.


Kind regards,

T G-R

Sent from a Web browser.  Excuse or enjoy my brevity.

bug#65225: ‘guix shell --system=ALIEN’ builds for both systems

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

Hi,

ekaitz noticed this when building a mes-derived package that fails on 
x86_64.  Here's a reproducer that uses upstream Guix:


$ guix shell --system=riscv64-linux drawterm --no-grafts --rebuild-cache 
--dry-run | grep drv$

  /gnu/store/4c02fgswkbldys93w4vgj0gwax2ly4bh-profile.drv

$ guix build --dry-run 
/gnu/store/4c02fgswkbldys93w4vgj0gwax2ly4bh-profile.drv | grep drawterm
  
/gnu/store/mkxyhjq117wdalc0gbz4468blqxih1kn-drawterm-20210628-1.c97fe46
  
/gnu/store/h8dk35aw2n8rj1hki6dkdrknfly26vq8-drawterm-20210628-1.c97fe46


/gnu/store/fl4iimlcdnlkarjm8m6z3392wss6b8yr-drawterm-20210628-1.c97fe46.drv
→ 
/gnu/store/mkxyhjq117wdalc0gbz4468blqxih1kn-drawterm-20210628-1.c97fe46

is riscv64-linux.

/gnu/store/9a1pji59hzacrmpb65nk3pp3m01niqf3-drawterm-20210628-1.c97fe46.drv
→ 
/gnu/store/h8dk35aw2n8rj1hki6dkdrknfly26vq8-drawterm-20210628-1.c97fe46

is x86_64-linux.

Eventually the ‘correct’ riscv64 drawterm ends up in the shell, but Guix 
should never have built the x86_64 version.


Kind regards,

T G-R

Sent from a Web browser.  Excuse or enjoy my brevity.

bug#65184: (modify-services … (delete …)) should delete all matching service types

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

TODO: the snippet

  (modify-services %base-services
(delete mingetty-service-type))

deletes only the first (tty1) instance of the mingetty service.  I can't 
think of a scenario where this is likely to reflect the user's 
intention.  It should delete all matching services.


A delete-first variant could be added iff there's demand.

Kind regards,

T G-R

Sent from a Web browser.  Excuse or enjoy my brevity.

bug#64976: guix build: error: invalid character `~' in name

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

Certain characters are not allowed in store item[0] names.  This 
restriction was inherited verbatim[1] from Nix.


As such there's no bug here, although you could start a separate 
discussion about relaxing these restrictions if you like.


So what to do?  url-fetch defaults to the URL's basename as file name, 
but you can specify a different one.  For example:


  (source
(method …)
(uri …)
(file-name (string-append name "-" version ".tar.gz"))
(sha256 …))

Kind regards,

T G-R

Sent from a Web browser.  Excuse or enjoy my brevity.

[0]: Top-level file names under /gnu/store.
[1]: 
https://git.savannah.gnu.org/cgit/guix.git/tree/nix/libstore/store-api.cc#n58

bug#65056: https://issues.guix.gnu.org/ cannot be accessed through Tor

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

On 2023-08-04 21:21, Tobias Geerinckx-Rice via Bug reports for GNU Guix 
wrote:

The Guix project does not block Tor.  If the datacentre has decided to
block Tor like it blocked most of Russia, there is little we can do
but ask them to reconsider.


Didn't mean to sound quite so fatalistic.  We could always migrate 
issues. to a different machine, like guix.gnu.org was, but it's not very 
satisfying.


Kind regards,

T G-R

Sent from a Web browser.  Excuse or enjoy my brevity.

bug#65056: https://issues.guix.gnu.org/ cannot be accessed through Tor

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

Hi Altadil,

On 2023-08-04 18:57, Altadil via Bug reports for GNU Guix wrote:

it is no longer possible to get to the bug database at
https://issues.guix.gnu.org/ when using Tor Browser.


I forgot to mention this on IRC, but issues. is ‘simply’ a nicer unified 
frontend to the venerable GNU Debbugs instance.  You can use its own[1] 
interface[2] as a work-around.



The result is an error message saying: "The connection has timed out".
It looks like a general block of Tor rather than a block of specific
IPs, since attempting with different Tor circuits does not change the


The Guix project does not block Tor.  If the datacentre has decided to 
block Tor like it blocked most of Russia, there is little we can do but 
ask them to reconsider.


Kind regards,

T G-R

Sent from a Web browser.  Excuse or enjoy my brevity.

[1]: https://debbugs.gnu.org/cgi/pkgreport.cgi?package=guix
[2]: https://debbugs.gnu.org/cgi/pkgreport.cgi?package=guix-patches

bug#65001: ‘guix locate’ method is silently ignored when a cache exists

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

Quick niggle I noticed:

~/guix master ↑2 λ guix locate libstdc++.so.
guix locate: indexing files from /gnu/store...
guix locate: traversing local profile manifests...
indexing 735 packages
…
~/guix master ↑29 ↓26 λ guix locate --method=store libstdc++.so.6
…
~/guix master ↑29 ↓26 λ guix locate --method=store --update 
libstdc++.so.6

guix locate: indexing files from /gnu/store...
indexing 24,455 packages
…

Either:
- the second invocation should imply --update, so Guix should store the 
currently cache method(s),
- or Guix should use separate databases for each method.  That's 
probably too ugly.


Kind regards,

T G-R

Sent from a Web browser.  Excuse or enjoy my brevity.

bug#64271: libasr is unmaintained upstream

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

Tobias Geerinckx-Rice via Bug reports for GNU Guix 写道：

OpenSMTPd temporarily(…) builds with openssl with commit
023ff651462f70004c7a92b19fd072ee3138e5a2, so the comment is 
gone.


Heh.  I see you released -p1 literally while I was typing that :-)

Thanks!

T G-R


signature.asc
Description: PGP signature

bug#64271: libasr is unmaintained upstream

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

Omar Polo 写道：
I'm not a guix user so can't send patches, hope this is the 
correct

way to report issues however.


Yep.

The upstream libasr-portable repository was archived, as the 
project
was unmaintained (and unmaintenable in some sense) for some 
time:


https://github.com/OpenSMTPD/libasr/

OpenSMTPD (its only consumer I guess) doesn't depend on it 
anymore, it

should be built with the bundled version that was updated.


Removed libasr in commit 902a48e0d3ce4a1983a6d3f71472639a8e59c48f.


P.S.: looking at the recipe for OpenSMTPD I noticed the comment
  "reccomended, and supports e.g. ECDSA".  While it's true 
  that
  it's reccomended to build with LibreSSL, ec keys should 
  work
  just as fine with OpenSSL.  The only issue is the combo 
  OpenSSL
  3.x + LibreTLS 3.7.0 due to a known regression that will 
  be
  fixed in a upcoming release (I hope) since LibreSSL' tls 
  did it:

  https://github.com/libressl/openbsd/commit/318ad8e73e


OpenSMTPd temporarily(…) builds with openssl with commit 
023ff651462f70004c7a92b19fd072ee3138e5a2, so the comment is gone.


Thanks!

T G-R


signature.asc
Description: PGP signature

bug#63255: Firefox crashes when triggering file dialog open

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

See the To: field of this message.  Done!  :-)

Kind regards,

T G-R

Sent on the go.  Excuse or enjoy my brevity.

bug#61965: Commands like "guix system search KEYWORD" don't work with locale it_IT.utf8

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

> I believe Tobias (Cc’d) fixed this and related issues
> a couple of days ago

Yep.  I also fixed a worrying number of @comando, @opzione, etc. on Weblate 
(both in the 'guix' and 'packages' sets).

Weblate is pretty unfriendly, so this was tedious and I'm positive there are 
some I missed.  There's a comment warning translators not to do this, but it's 
sadly useless since it's tied to *one* package—the odds of seeing it are 
vanishing.

Julien, is there a way to make this warning more prominent/ubiquitous?

(Also, is there a translation workflow that avoids relying on Weblate or other 
clunky tools?)

Run-time errors appear to be the only QA available for these strings, but this 
failure mode is extreme.  How about explicitly reporting the error & continuing 
in English?

From what I remember, the code won't be elegant (we append to the translation, 
then convert Texi, so falling back must be done by the caller or a new combo 
procedure) but the result would be better.

Kind regards,

T G-R

Sent on the go.  Excuse or enjoy my brevity.

bug#61961: ‘guix system search’ refuses to speak Italian

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

Tobias Geerinckx-Rice 写道：
I could on a different machine, which probably had different 
locales,

which is why I'm leaving it here until tomorrow.


Oh, never mind: it happens only *without* ./pre-inst-env, of 
course.  Fun.


Kind regards,

T G-R


signature.asc
Description: PGP signature

bug#61961: ‘guix system search’ refuses to speak Italian

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

Hi all,

tux_life reported this in #guix:

[anonymous@guix ~]$ guix system search cups

Backtrace:
In ice-9/boot-9.scm:
 1752:10 19 (with-exception-handler _ _ #:unwind? _ # _)
In guix/status.scm:
   851:3 18 (_)
   831:4 17 (call-with-status-report _ _)
In ice-9/boot-9.scm:
 1752:10 16 (with-exception-handler _ _ #:unwind? _ # _)
In guix/scripts/system/search.scm:
  188:20 15 (_)
  164:18 14 (find-service-types _)
In guix/discovery.scm:
   189:3 13 (fold-module-public-variables _ _ _)
In guix/combinators.scm:
   48:26 12 (fold2 #   guix/discovery.scm:…> …)
   48:26 11 (fold2 #   guix/discovery.scm:…> …)

In guix/discovery.scm:
  192:33 10 (_ # () #  7fb…>)

In guix/scripts/system/search.scm:
  166:28  9 (_ # ())
In guix/ui.scm:
  1670:6  8 (relevance # _ (# 
  …))

In srfi/srfi-1.scm:
  460:18  7 (fold #  …> …)

In guix/ui.scm:
 1673:17  6 (_ _ 0)
 1473:24  5 (texi->plain-text _)
In texinfo.scm:
 1132:22  4 (parse _)
  967:36  3 (loop # (*fragment*) 
  # …)

92:2  2 (command-spec _)
In ice-9/boot-9.scm:
 1685:16  1 (raise-exception _ #:continuable? _)
 1685:16  0 (raise-exception _ #:continuable? _)

ice-9/boot-9.scm:1685:16: In procedure raise-exception:
Throw to key `parser-error' with args `(#f "Unknown command" 
dnf)'.


Seems like an obvious bogus (Texinfo?) translation, but I can't 
manage to reproduce it anymore.


I could on a different machine, which probably had different 
locales, which is why I'm leaving it here until tomorrow.


Kind regards,

T G-R


signature.asc
Description: PGP signature

bug#61885: [PATCH] gnu: go-github-com-robfig-cron-1.2: Move to (gnu packages golang)

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

Hi Winter,

Simon Tournier 写道：
Becaus (gnu packages golang) and (gnu packages check) use each 
other, this

  -^
   Typo

s/Becaus/Because I guess


Pushed as 997b93cc4a6deff54ebd854a716cca94095114bf with this fix. 
Thanks!


I'll close this bug now; the more general problem (and more 
work-arounds to it) are tracked in others.


Kind regards,

T G-R


signature.asc
Description: PGP signature

bug#58813: [PATCH] doc: Document how to use Patman for patches submission.

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

Hi,

> teams.scm

I closed the bug-that-didn't-fix, but that still leaves a git-specific command 
that doesn't actually facilitate git.¹

I guess salvaging 'teams.scm cc' into a generic 'Cc:' header generator makes 
some sense?  Without the $() use case.

Otherwise: shall we simply remove it?

Kind regards,

T G-R

Sent on the go.  Excuse or enjoy my brevity.

1: Code golfing bash snippets that make it 'work' doesn't count, but it's fun.

bug#58428: [PATCH 1/2] gnu: ddcutil: Update to 1.3.2.

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

Closing this stale bug which was accidentally filed against ‘debbugs’ 
itself, not ‘guix’!


Kind regards,

T G-R

Sent from a Web browser.  Excuse or enjoy my brevity.

bug#61557: vdirsyncer fails to verify certificates

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

reassign 61557 guix
thanks

Hi,

I had missed the Package: pseudo-header because I shouldn't be alive at 
this point.


All Guix bugs should be filed against the ‘guix’ package, no matter what 
the package—confusing, I know.  Luckily, sending mail to bug-guix@ does 
this for you, so you don't usually need to think about it.


Thanks again!

Kind regards,

T G-R

Sent from a Web browser.  Excuse or enjoy my brevity.

bug#32026: [PATCH v3 10/11] gnu: nss-next: Update to 3.88.1 [fixes CVE-2023-0767].

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

Maxim Cournoyer 写道：
It's already been pushed for nss-next, and Tobias has taken care 
of
grafting our main 'nss' package, which has many dependents.  See 
commits

246a3d90eac82966b691bdca4660ab9c5d802631 and
b04ee227a47419291391a2b6e857e41ed1c32155, respectively.


Grafting such a big version jump made me nervous.

I did so anyway, partially on Mozilla's assurance (FWIW) that it's 
ABI-compatible, but mainly because I dare not vouch for a single 
cherry-pick to 3.81 actually keeping users safe.


I'd much rather deal with ABI bug reports than the alternative :-)

Kind regards,

T G-R


signature.asc
Description: PGP signature

bug#61606: julia 1.8.3 installation failed

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

Hi francis,

francismb 写道：

while trying to install package julia the installation fails:


Sorry that you wasted so much (computing) time on this.  It should 
be fixed on master[0] now.


Thanks for the detailed bug report!

Kind regards,

T G-R

[0]: 
https://git.savannah.gnu.org/cgit/guix.git/commit/?id=0fbff222c49b1807fae2089b1462fa6e9aefb79f


signature.asc
Description: PGP signature

bug#61158: Add grub-efi to the installer

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

Tobias Geerinckx-Rice 写道：

grub-efi


Or -hybrid, if fully equivalent.

Kind regards,

T G-R


signature.asc
Description: PGP signature

bug#61158: Add grub-efi to the installer

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

A reminder to myself:

grub-efi appears to be missing from the installer image, reducing 
its value as an (off-line) rescue system.  Inspect the size 
increase and add it if at all reasonable.


Kind regards,

T G-R


signature.asc
Description: PGP signature

bug#61116: [bayfront] logs.guix FTS database is stale

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

Hi all,

The search box on logs.guix.gnu.org works fine but is forever stuck in 2021.  I 
realised that I've never properly reported this.  Sorry.

Kind regards,

T G-R

Sent on the go.  Excuse or enjoy my brevity.

bug#61106: spam

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

Fermé.  Ceci n'est pas un bogue, mais une fonctionnalité.

T G-R


signature.asc
Description: PGP signature

bug#59987: Guix build of guix package fails due to some graph tests failing

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

Andrew Patterson 写道：

I'm also in favor of closing.


Done!

You can close any bug yourself by editing the reply address in the 
CC header, as I did here.


Kind regards,

T G-R


signature.asc
Description: PGP signature

bug#60927: gPodder database version field different when built using --with-latest

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

Hullo,

On 2023-01-18 9:13, Csepp wrote:

Haven't completely debugged this, but the symptoms are:
* running the packaged version doesn't work, blank scree, failed assert
on console about differing database schema version


I can't reproduce this, in either direction.  However, I didn't have an 
existing GPodder configuration or database, and I'm not even sure where 
those are kept.


If you do, could you grep for one of the hashes?

Kind regards,

T G-R

Sent from a Web browser.  Excuse or enjoy my brevity.

bug#60494: git-reference does not support file:// uri scheme

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

retitle 60494 Document git-checkout
thanks

Hi!

That itself is not a bug: git-fetch is the wrong tool for this job.  It should 
not have access to your files.

You can clone a local repository by directly calling git-checkout and passing 
it as the package source:

  (source
(git-checkout (url "/home/mirai/foo")))

No need for a hash, either!  \o/





Kind regards,

T G-R

Sent on the go.  Excuse or enjoy my brevity.

bug#60290: Manual: Is guix-patc...@debbugs.gnu.org valid?

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

Nope.

Fixed.

Thanks!

T G-R

Sent from a Web browser.  Excuse or enjoy my brevity.

bug#60246: Inability to add pseudo-filesystem fstab entries

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

mirai 写道：
This way there's at least a way to "start" these mounts rather 
than

them ending up in the /dev/null abyss.


A non-standard and hard to discover way, sure.

I liked the (unless mount? (add-to-fstab)) suggestion better.

(I'm taking the comment at face value—I'd have suggested adding 
them all to fstab otherwise.)


Kind regards,

T G-R


signature.asc
Description: PGP signature

bug#60246: Inability to add pseudo-filesystem fstab entries

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

Hi Bruno,

mirai 写道：
Does not result in a fstab entry line, which makes it impossible 
to mount. According to Guix docs, this shouldn't be the case:


Hm, yes, strictly speaking that is so.

It feels a bit weird to add or omit fstab entries based on MOUNT? 
being true or false, but… it seems like a good proxy for what the 
user *means* in both cases?


If the following is really true, we have little other choice:

;; In particular, things like GIO (part of GLib) use it to 
determine the set
;; of mounts, which is then used by graphical file managers and 
desktop
;; environments to display "volume" icons.  Thus, we really need 
to exclude

;; those pseudo file systems from the list.


so I wouldn't be opposed to it.


%pseudo-file-system-types)


I disagree that overlayfs is a ‘pseudo-file-system’, any more than 
NFS would be.  It should not be in that list to begin with.


And this is where it gets fun: apparently… it was added at my 
request‽ :-)


Or at least Ludo's interpretation of that requests, in commit 
df1eaffc3:


   file-systems: Expound '%pseudo-file-system-types'.
   
   Reported by Tobias Geerinckx-Rice .
   
   * gnu/system/file-systems.scm (%pseudo-file-system-types): Add
   "debugfs", "efivarfs", "hugetlbfs", "overlay", and 
   "securityfs".


Even in this list, ‘overlayfs’ has huge 
one-of-these-is-not-like-the-others energy, so I wonder what the 
reason was.  I don't remember.


I'd happily revert it if I didn't suspect that it was to work 
around some real (installer?) bug…


Kind regards,

T G-R


signature.asc
Description: PGP signature

bug#59466: Kernel panic when installing with Ventoy

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

Hi Panos,

Panos Alevropoulos 写道：

Please close this issue,


Done!


it was fixed when I tried Ventoy with the latest image!


Very glad to hear that.  Thanks for the prompt response!

Kind regards,

T G-R


signature.asc
Description: PGP signature

bug#59466: Kernel panic when installing with Ventoy

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

Tobias Geerinckx-Rice 写道：

- What is the sha256sum of the 1.3.0 ISO image you used?
- Could you try the ‘latest’[0] ISO and report the result?


Poing!  If there's still some latent bug with Ventoy on your 
hardware, now's our last chance to debug it before the release.


[0]: But now with the 1.4.0rc2 image[1] and signature[2].

Kind regards,

T G-R

[1]: 
https://alpha.gnu.org/gnu/guix/guix-system-install-1.4.0rc2.x86_64-linux.iso
[2]: 
https://alpha.gnu.org/gnu/guix/guix-system-install-1.4.0rc2.x86_64-linux.iso.sig


signature.asc
Description: PGP signature

bug#59850: ecryptfs-utils has a dependency on gettext

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

Hi Steven,

I've wrapped the scripts with a whole bunch of extra references in 
commit 0335499876d08b12c63057f386535695f1b65597.


Could you pull, upgrade e-u, and test if it still works at all? 
That would be nice.


Kind regards,

T G-R


signature.asc
Description: PGP signature

bug#59781: bug#50892: [PATCH] guix-install.sh: Authorize all project build farms at once.

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

Ludovic Courtès 写道：

If there are no objections I’d like to push to ‘master’ and
‘version-1.4.0’ this modified version of your patch.


No objections, thanks!

(Ugh, this patch is so ugly, all to work around that triplication 
in ~/.config/guix/current/share/guix/*.pub…  Would it be OK for 
‘guix archive --authorize’ to silently ignore duplicate keys?)


Kind regards,

T G-R


signature.asc
Description: PGP signature

bug#59830: guix system reconfigure don't work after 1.4_rc1 fresh installation

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

merge 59830 59780
thanks

Kind regards,

T G-R

Sent on the go.  Excuse or enjoy my brevity.

bug#59466: Kernel panic when installing with Ventoy

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

Hi Josselin,

Josselin Poiret via Bug reports for GNU Guix 写道：
Ventoy is not supported currently. It is up to them to add 
support for
Guix, not the other way around: we have some peculiarities with 
the boot

process that Ventoy completely ignores.


Ah.  This is true of most dime-a-dozen ‘universal’ ISO booters, 
which merely source a GRUB .cfg and expect distributions to do all 
the work.  I'd shame them by name if they were memorable.  Guix 
indeed doesn't ‘support’ that!


Ventoy actually put some thought & effort into the process.  Like 
all clever hacks, there's some dependence on moon phase and luck, 
but it's not snake oil.


It injects some code into the boot process to expose the ISO file 
as a block device through Linux's device mapper.  Any distribution 
with dm-mod support, including Guix[0] (through dm-crypt), will 
see a ‘real’ block device straight from the kernel.  No distro 
cooperation is required beyond ‘please don't be too clever and 
peek behind the curtain’.  IME, Guix does not do so, and just 
works.


(So why does it fail here…?)

Kind regards,

T G-R

[0]: https://www.ventoy.net/en/distro_iso/gnu_guix.html but do 
note who submitted it ;-)


signature.asc
Description: PGP signature

bug#59466: Kernel panic when installing with Ventoy

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

Hi Panos,

Guix and Ventoy should work out of the box.

Panos Alevropoulos via Bug reports for GNU Guix 写道：
It seems that I can't install Guix 1.3.0 with Ventoy. After 
starting installation from Guix GRUB, I get kernel panic.


Thanks for including the exact panic message.  That's very 
helpful.


It's odd: Guix is trying to compile /ventoy/init as a SCM file.

- What is the sha256sum of the 1.3.0 ISO image you used?
- Could you try the ‘latest’[0] ISO and report the result?

Kind regards,

T G-R

[0]: https://guix.gnu.org/en/download/latest/


signature.asc
Description: PGP signature

bug#59780: [version 1.4.0rc1] reconfigure fails

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

Tobias Geerinckx-Rice 写道：

Is the actual release commit always on master


Yes.


Actually, that is what's known as ‘complete nonsense’ and the 
correct answer is, of course, ‘no’.


Hmm.  I'll have to actually test the RC to see what you mean. 
Sorry for the noise.


Kind regs,

T G-R


signature.asc
Description: PGP signature

bug#59780: [version 1.4.0rc1] reconfigure fails

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

Hi'gain,

pelzflorian (Florian Pelz) 写道：
Huh I don’t understand. :)  Had this been the 1.4.0 release, 
reconfigure

would be impossible, unless --allow-downgrades.


I don't follow.  Could you explain?


Is the actual release commit always on master


Yes.  Does this cancel out the previous question?  If so, I'll let 
you close the bug to avoid misunderstandings.


(But it's worth noting in future calls for testing, absolutely! 
Thanks for noticing.)


Kind regards,

T G-R


signature.asc
Description: PGP signature

bug#59780: [version 1.4.0rc1] reconfigure fails

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

pelzflorian (Florian Pelz) 写道：
Having installed the 1.4.0rc1 installer image: After guix pull, 
it

failed to reconfigure, because master is an unrelated commit.


Hah.  This should indeed be mentioned in calls for -RC testing, 
but probably doesn't deserve a bug report, since there's no bug. 
WDYT?


Kind regards,

T G-R


signature.asc
Description: PGP signature

bug#59781: [version 1.4.0rc1] install.sh script should authorize bordeaux

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

pelzflorian (Florian Pelz) 写道：

Could you make install.sh add bordeaux to /etc/guix/acl?  It is
important especially on ARM.


If you mean guix-install.sh: I did so ages ago, but something 
(valid) stopped me from pushing it.


Now I can't for the life of me remember what it was…

Kind regards,

T G-R


signature.asc
Description: PGP signature

bug#59771: Conda 22.9.0 needs "sudo" as dependency

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

Hi Hugo,

Hugo Buddelmeijer 写道：
As for why sudo is needed, I don't know. (Not sure I want to 
know.)


Indeed, this sounds like something to report and fix upstream.


$ guix shell -C conda sudo


Won't work, because sudo needs to be setuid — that is, provided by 
the OS.


On Guix Systems, that means /run/setuid-programs/sudo.  It cannot 
be run from the store, where setuid programmes are not allowed.


I tried --expose'ing /run/setuid-programs, but then sudo fails to 
find libsudo_util.so.0.  I didn't test further but don't expect 
that to suffice: sudo simply makes too many assumptions about the 
system, because of the special job it needs to do.


While it would be nice to figure out how to provide 
setuid-programs to a containers, Conda's pointless use of sudo is 
the bug here.


Kind regards,

T G-R


signature.asc
Description: PGP signature

bug#59663: Cannot install lf-27, outdated commit

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

Hi Tyler,

Thanks for the report!  Commit b0801110cc729173a38a159d4a0c2094e5784ef4 
fixes lf.



Changing to a newer commit should be able to fix this error.


Probably (I didn't check), but Guix avoids packaging random commits 
without good reason.  I've kept lf at the latest 27 release.


Kind regards,

T G-R

Sent from a Web browser.  Excuse or enjoy my brevity.

bug#59519: LibreOffice 7.3.5.2 fails to build on i686-linux

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

Hi Kaelyn,

Kaelyn via Bug reports for GNU Guix 写道：

Here is a revised diff with comments added for the flags.


Thanks again!  Pushed as 536adbd7cca1f257261645d9cfd7910a0055a60e, 
also with a commit message added.


+ ;; Enable building with LTO to avoid linker errors 
about

+ ;; non-virtual thunks on i686-linux.
+ "--enable-lto"
+ ;; Disable galleries to avoid errors rebuilding the 
Gtk icon

+ ;; cache, at least on i686-linux.
+ "--without-galleries"


The importance of comments is to document the ‘why’.  The ‘what’ 
is obvious from the flags themselves, so I removed the first few 
words of each comment to make them fit nicely on 1 line.


Kind regards,

T G-R


signature.asc
Description: PGP signature

bug#58031: LibreOffice 7.3.5.2 is not reproducible

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

Hi Kaelyn,

Kaelyn via Bug reports for GNU Guix 写道：
diff --git a/gnu/packages/libreoffice.scm 
b/gnu/packages/libreoffice.scm


Thanks!  Pushed as 68925b5ee7e0d96b0c84ae98a633eea5097bf511.

This patch was missing a commit message (in fact it was just a 
diff).  I added one:


   gnu: libreoffice: Build reproducibly.
   
   * gnu/packages/libreoffice.scm (libreoffice)[arguments]: 
   Include ‘.otp’

   files in the 'reset-zip-timestamps phase.

In future, please use ‘git send-email’ if possible, or ‘git 
format-patch’ otherwise, and read the Guix manual section on 
submitting patches if you haven't yet.  


Kind regards,

T G-R


signature.asc
Description: PGP signature

bug#59615: Intro video refers to Freenode

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

I remember doing so.  I don't remember if I committed it but I do remember 
make'ing the videos on berlin...

Yes, the audio would be out of sync.

Will check, thanks for bringing it up.

Kind regards,

T G-R

Sent on the go.  Excuse or enjoy my brevity.

bug#59160: Acknowledgement (Fritzing parts are missing)

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

Gabriel,

Thanks for the patch!

Gabriel Wicki 写道：
I've come up with the following patch.  It is not optimal 
(there's still
some warnings and it makes use of an ugly hack to get rid of a 
certain
"Unable to find parts git repository" message) but with that 
patch

Fritzing is in a usable state.


[…]


+ (substitute* "src/version/partschecker.cpp"
+   ((".*git_libgit2_init.*")
+"return 
\"083nz7vj7a334575smjry6257535h68gglh8a381xxa36dw96aqs\";"))


It doesn't really matter *what* this returns, right?  At least I 
can't find any observable difference.  And as noted on IRC, this 
‘base32’ format is unique to Guix and Nix.


Could you explain the mechanism behind this, er, mechanism?

Kind regards,

T G-R


signature.asc
Description: PGP signature

bug#59363: Fw: [PATCH] flatpak: Adjustments to make --with-commit work

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

On 20 November 2022 12:11:28 UTC, Tobias Geerinckx-Rice  wrote:
>[Off list]

...or not!  :-D. Phones are a cruel joke.

Anyway, that's the dealio.

bug#59363: Fw: [PATCH] flatpak: Adjustments to make --with-commit work

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

[Off list]

Hi Chris,

You didn't receive their mails because their address is banned from all lists 
that support doing so.

Unfortunately, there are loopholes.

Kind regards,

T G-R

Sent on the go.  Excuse or enjoy my brevity.

bug#59279: MPV does not work on X11

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

Hi,

Could someone test the patch at 
?


Kind regards,

T G-R


signature.asc
Description: PGP signature

bug#59339: mpv: possible misconfiguration

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

retitle 59279 MPV does not work on X11
merge 59279 59339
thanks

Kristian Lein-Mathisen 写道：

Is it possible that mpv's default configuration has changed


Yes, that seems to be the case.  Thanks for the report!

Kind regards,

T G-R


signature.asc
Description: PGP signature

bug#58988: How Can I restore a file inside /gnu/store/ ?

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

Heyo,

Adding some notable info that user_ shared on IRC:

user2@host ~$ sudo guix build --repair 
/gnu/store/yjllxib1fm3zqkwmr5j4lpxhz3zqsjjz-guix-e3280ae
Senha: 
substitute: atualizando substitutos de 
"https://ci.guix.gnu.org;... 100.0%
substituindo 
/gnu/store/yjllxib1fm3zqkwmr5j4lpxhz3zqsjjz-guix-e3280ae...
baixando de 
https://ci.guix.gnu.org/nar/lzip/yjllxib1fm3zqkwmr5j4lpxhz3zqsjjz-guix-e3280ae 
...


guix-e3280ae   792KiB/s 00:21 | 16.1MiB transferred


guixu...@airmail.cc 写道：

I need to fix this file but
/gnu/store/ is read only, How can I restore this file?


Well, ‘sudo guix gc --verify=contents,repair’, or ‘guix build 
--repair’.


Since neither worked: if you've ‘guix pull’ed before, you should 
have some previous profiles as


 /var/guix/profiles/per-user/$USER/current-guix-*

If so: see if pulling any of those works, e.g.,

 $ /var/guix/profiles/per-user/$USER/current-guix-1-link/bin/guix 
 pull


Kind regards,

T G-R


signature.asc
Description: PGP signature

bug#58760: Guix System iso too big for cdrom again

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

Heyo,

pelzflorian (Florian Pelz) 写道：

From what Tobias (Cc) wrote, he used the highest
compression settings.

So it seems nothing can be done to make the install iso smaller


Well…  I used the highest compression setting *for zisofs*.

Zisofs is an ancient (and non-standard :-) little hack that Linux 
supports, and it just happened to be enabled on our kernels 
already.  Plus it's fully transparent to the operating system. 
That's why I wrote that quick little patch: it was an amusing—to 
me—way to shrink our ISO basically for free.


We're the only distro that I've ever seen use it.

But we can go deeper if we choose to, by dropping zisofs and going 
for something like squashfs, which achieves higher compression 
through higher block sizes and better algorithms like XZ.


This is what other distributions with a compressed root file 
system do.


However, it's marginally more work as you have to loop-mount the 
image early during boot, and it doesn't involve obscure kernel 
arcana (boo), and CDs are even more obsolete than they were when I 
wrote that patch (yay), so don't wait for me to do it.


Kind regards,

T G-R


signature.asc
Description: PGP signature

bug#39571: evolution and bogofilter

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

Hi Christopher,

Thanks for the swift response!

Christopher Howard 写道：

If you wish to close this old bug I will not be affected.


Will do.

Why let zimoun have all the fun,

T G-R


signature.asc
Description: PGP signature

bug#39571: evolution and bogofilter

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

zimoun 写道：
For the record, the message I received back.  Therefore, I will 
close

if no objection.


Let's try this one first.

Christopher, assuming you have a clue what this is about: are you 
still affected by ?


Kind regards,

T G-R


signature.asc
Description: PGP signature

bug#58591: Java packages do not appear to keep a reference to their inputs

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

Tobias Geerinckx-Rice via Bug reports for GNU Guix 写道：

Groan.  Which package(s) compress .jars?


OK, found one: openjdk@16.0.1's /lib/jrt-fs.jar.

Kind regards,

T G-R


signature.asc
Description: PGP signature

bug#58591: Java packages do not appear to keep a reference to their inputs

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

Hi Maxim,

Maxim Cournoyer 写道：

not obfuscated due to zip compression


Groan.  Which package(s) compress .jars?

(I found a few in -checkouts, which is its own potential thing, 
but that aside.)


Kind regards,

T G-R


signature.asc
Description: PGP signature

bug#58561: Source hash mismatch with aggregator + possible guix bug with hashes.

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

Hi Brendan,

Oh!  This is a fun one!

Brendan Tildesley 写道：
However what concerned me more is that when I look in the source 
code

it looks like this:

(sha256
    (base32 
"9yy5c29zxpli4cddknmdvjkgii3j7pvw6lhwqfrqjc8jh83gm8f8"))



Notice how at the start its a '9', not a '1'?

[…]

Is there a bug with how guix is reading/writing sha256 hashes?


It's… not a bug.  It's the opposite, kind of, although maybe 
(probably) Guix could (should) reject clearly bogus input like 
this.


What's happening is this:

In what can be described only as a bizarre coincidence, sha256 
produces hashes that are 256 bits long.


Base32¹ encodes 5 bits per character.  Our ‘hash’ strings are 
currently 52 characters long, meaning they encode 260 bits.


If you poke around Guix, you'll notice that every valid base32 
‘sha256’ hash starts with a 0 or a 1, because those 4 leftmost 
bits are never used, and hence set to zero.


In the case of this "9…" ‘hash’ (which was random data, I guess?), 
Guix still reads only 256 bits of the 260, and ignores those 4 
‘extra’ leftmost bits.


When it later prints the hash, it converts those 256 bits back to 
base32, now padded with zeroes, and you see a ‘hash’ starting with 
1.


What Guix could do is refuse to continue when it detects set 
higher bits, as they always indicate programmer error.


Kind regards,

T G-R

1: Guix uses ‘nix-base32’ which uses a slightly different alphabet 
from the more common base32 variant, but is otherwise identical in 
operation.


signature.asc
Description: PGP signature

bug#37955: warning: '.desktop' file refers to '', which cannot be found

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

I moved the informational background above the changelog and 
pushed this to c-u as 685110045c04a60bf18163aab1c230f944c871c9.


Thanks!

T G-R


signature.asc
Description: PGP signature

bug#58239: Installer ISO ‘missing’ mkfs.ext4

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

Tobias Geerinckx-Rice via Bug reports for GNU Guix 写道：

Should be an easy fix, feel free to beat me to it.


…well you didn't have to do it that fast.  Patch in bug #58238. 
Closing.


Kind regards,

T G-R


signature.asc
Description: PGP signature

bug#58239: Installer ISO ‘missing’ mkfs.ext4

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

Hi Guix,

I was going to open this tomorrow, but odds are good that I'd 
forget overnight, so very sleepy bug report time:


Commit 45eac6cdf5c8d9d7b0c564b105c790d2d2007799 removes mkfs.ext* 
(and possibly others, didn't check) from $PATH unless the system 
happens to have a  of that type.


The installer ISO still assumes the old behaviour of having 
(again, at least) e2fsprogs in the system packages.  One can no 
longer ‘sudo mkfs.ext4’, although e2fsprogs is still present in 
the store and can be manually invoked by a savvy user.


Should be an easy fix, feel free to beat me to it.  I intend to 
sleep in.


Kind regards,

T G-R


signature.asc
Description: PGP signature

bug#58221: nautilus: Crashes loading KgxNautilus plugin twice (problems with NAUTILUS_EXTENSION_PATH)

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

Hi Tobias,

On 1 October 2022 14:40:58 UTC, Tobias Kortkamp  
wrote:
>** (org.gnome.Nautilus:11879): WARNING **: 16:07:20.550: Tracker 2 migration: 
>Failed to parse key file data: Key file contains line “usage: tracker3 
>[--version] [--help]” which is not a key-value pair, group, or comment

There we go.  There it is.

>Same crash as before otherwise.

So it *still* fails to find tracker3 before segfaulting?  Possible.  Could be a 
missing substitution, or it falling back to some other (search) path...

>If I run that command manually I just get the usage screen. In fact
>none of the tracker3 subcommands actually seem to work like they do on
>Fedora. Not even "help".

This sounds exactly like hypothesis #2 (mis-wrapping).  I thought that was a 
thing of the past, but maybe the fix is still floating up to master, or 
incomplete...

Will be easy enough to confirm when I'm back at K.



Thanks!

T G-R

Sent on the go.  Excuse or enjoy my brevity.

bug#58221: nautilus: Crashes loading KgxNautilus plugin twice (problems with NAUTILUS_EXTENSION_PATH)

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

Hi… Tobias,

Tobias Kortkamp 写道：
** (org.gnome.Nautilus:3664): WARNING **: 13:25:09.882: Tracker 
2
migration: Couldn't run `tracker3`: Failed to execute child 
process

“tracker3” (No such file or directory)


Could you install ‘tracker@3’ into the same profile, and try 
again?  This part might be a relatively simple input fix.


Please note whether it crashes for the *same* reason, as I fully 
expect it to still crash!  See this log[0] posted by nashdidan[m] 
on IRC[1].


Aside from the vague version mismatch hypothesis, another possible 
culprit is wrapping.  G-stuff needs a lot of wrapping to work 
properly & we might be introducing a bogus (argv[0]?) argument 
somewhere.  I didn't investigate.


Kind regards,

T G-R

[0]: 
https://libera.ems.host/_matrix/media/r0/download/libera.chat/b5ff1e283706b1ed86b1396ce7f8d3474405c698

[1]: https://logs.guix.gnu.org/guix/2022-09-30.log#090340


signature.asc
Description: PGP signature

bug#57990: Add package: python-mat2 (remove metadata from images to improve privacy)

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

> can I express "any version of ffmpeg"?

No, this would go against the goals of Guix: packages can't depend on 
properties of the environment they'll end up in (if any).

They must be self-contained, or use standard features like $PATH et al to find 
optional dependencies at run time, but these will have to be provided by the 
user/manifest/whatever.

Sorry,

T G-R

Sent on the go.  Excuse or enjoy my brevity.

bug#57583: Guix cannot resume after hibernation

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

Jack, Yusuf, Ludo',

Yusuf: you could try pulling, reconfiguring, hibernating, and 
resuming, if you're brave-ish.


Ludovic Courtès 写道：

I believe this is fixed by this: […] The patch in question fell
through the cracks


It should and it had, sorry.

I *dislike* the fact that this makes the resume path no longer 
trivially obviously correct — because we now actually do something 
potentially useful (and hence, dangerous) during it — but that's 
unavoidable I suppose.  It's certainly not the fault of this 
patch.


Pushed as ec16f88522041dc285a35705ff9ee95672b78143, thanks Jack!

Kind regards,

T G-R


signature.asc
Description: PGP signature

bug#57583: Guix cannot resume after hibernation

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

Hi again,

Josselin Poiret via Bug reports for GNU Guix 写道：
   (and testing these kinds of features is 
   dangerous,

you could make a wrong move and incur heavy data loss)


I couldn't agree moEXT4-fs ext4_get_branch:171: inode #8: block 
30343695: comm jbd2/sdb7-8: invalid block

Aborting journal on device sdb7-8.

…ya know, I actually wrote a patch that I thought I'd submitted, 
but apparently not?  Or I'm failing to use Mumi again.


We should scan all swap areas for the S1SUSPEND signature, and do 
a much better thing than the current behaviour if we find one.


I'll see if I can find it in a backup somewhEXT4-fs (sdb7): 
Remounting filesystem read-only


Kind regards,

T G-R


signature.asc
Description: PGP signature

bug#57583: Guix cannot resume after hibernation

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

Hi Yusuf, Ludo',

Josselin is right that resuming from encrypted swap isn't 
supported.


Yusuf Talha via Bug reports for GNU Guix 写道：
Hibernation wasn't working 
while I

was using Guix without encryption a few months ago either.


To have any hope of debugging this one, we'll need information.

For example, what *exactly* did you specify as resume partition? 
IIRC we try parsing it as /dev/name, UUID, or file system label 
(almost certainly not in that order, obviously).


In #guix, Ludovic recently noted the same in passing, but so far 
has managed to dodge my pleas for moreinfo :-)


Kind regards,

T G-R


signature.asc
Description: PGP signature

bug#57467: [EXT] Re: [EXT] Re: bug#57467: 'guix shell' does not honor default behavior when given a specific command to run

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

Hi David,

Thompson, David 写道：
The hostility here and in the other issue where you are applying 
stop energy to my work is less than appreciated.


Some healthy ‘stop energy’ was needed here, and in bug #56444.

Please spend that energy on fleshing out requirements and 
improving the patches if needed.  Maxime's review is a good start.


Shopping around for a ‘core dev’ to fast-track these patches 
disrespects the work Maxime has already put in, and is not how 
things are done.  It won't happen.


Kind regards,

T G-R


signature.asc
Description: PGP signature

bug#57269: [rtl8812au-aircrack-ng-linux-module] Missing Source for hal/rtl8812a/hal8812a_fw.c (and probably other files ending in fw.c)

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

Hi Jacob,

Jacob K via Bug reports for GNU Guix 写道：
Files such as hal8812a_fw.c [1] have large arrays that seem to 
be binary
firmware encoded in text. My understanding is that source code 
is not

available, so I believe the files are nonfree software,


Even if free source code exists, we should still remove the blobs 
and build our own.  (Yes, we actually do this for other firmware 
:-)


the short-term at least, be removed from Guix. Long term it 
would be
good to get the source code (via reverse engineering or asking 
Realtek),
but I imagine that would take a significant amount of time and 
effort (I
do have a Realtek USB Wi-Fi card, maybe not with this exact 
firmware

though.).


Unfortunately all correct.  Another blow to wireless networking 
with Guix.  Attached is a patch removing the 
rtl8821ce-linux-module and rtl8812au-aircrack-ng-linux-module 
packages.


I didn't apply it yet.  Since this case, unlike some others, 
appears to be straightforward, I don't intend to wait long.


Kind regards,

T G-R

From a4650f7dbad4458d3bc907a96a45a334d1d2a086 Mon Sep 17 00:00:00 2001
From: Tobias Geerinckx-Rice 
Date: Sun, 14 Aug 2022 02:00:00 +0200
Subject: [PATCH 01/12] gnu: Remove Realtek WiFi drivers with firmware blobs.

rtl8821ce-linux-module contains, e.g., halhwimg8821c_fw.c and
hal8821c_fw.c.  rtl8812au-aircrack-ng-linux-module has, e.g.,
hal8814a_fw.c, hal8812a_fw.c, and hal8821a_fw.c.  Each of these
examples contains non-free firmware blobs disguised as C arrays.

* gnu/packages/linux.scm (rtl8821ce-linux-module)
(rtl8812au-aircrack-ng-linux-module): Remove variables.

Reported by Jacob K 
---
 gnu/packages/linux.scm  | 75 -
 gnu/system/examples/bare-bones.tmpl |  1 +
 2 files changed, 1 insertion(+), 75 deletions(-)

diff --git a/gnu/packages/linux.scm b/gnu/packages/linux.scm
index fb8b4fa5a8..2c1a38b5c4 100644
--- a/gnu/packages/linux.scm
+++ b/gnu/packages/linux.scm
@@ -1373,81 +1373,6 @@ (define-public lkrg
 detection of security vulnerability exploits against the kernel.")
 (license license:gpl2)))
 
-(define-public rtl8821ce-linux-module
-  (let ((commit "be733dc86781c68571650b395dd0fa6b53c0a039")
-(revision "6"))
-(package
-  (name "rtl8821ce-linux-module")
-  (version (git-version "0.0.0" revision commit))
-  (source
-   (origin
- (method git-fetch)
- (uri (git-reference
-   (url "https://github.com/tomaspinho/rtl8821ce;)
-   (commit commit)))
- (file-name (git-file-name name version))
- (sha256
-  (base32
-   "00sd7s0582b9jcpfgy0fw6418dwg700mfyizkfr22jf2x140iy70"
-  (build-system linux-module-build-system)
-  (arguments
-   (list #:make-flags
- #~(list (string-append "CC=" #$(cc-for-target))
- (string-append "KSRC="
-(assoc-ref %build-inputs
-   "linux-module-builder")
-"/lib/modules/build"))
- #:phases
- #~(modify-phases %standard-phases
- (replace 'build
-   (lambda* (#:key (make-flags '()) (parallel-build? #t)
-   #:allow-other-keys)
- (apply invoke "make"
-`(,@(if parallel-build?
-`("-j" ,(number->string (parallel-job-count)))
-'())
-  ,@make-flags)
- #:tests? #f))  ; no test suite
-  (home-page "https://github.com/tomaspinho/rtl8821ce;)
-  (synopsis "Linux driver for Realtek RTL8821CE wireless network adapters")
-  (description "This is Realtek's RTL8821CE Linux driver for wireless
-network adapters.")
-  (license license:gpl2
-
-(define-public rtl8812au-aircrack-ng-linux-module
-  (let ((commit "6d0d9fb56d4d918012a5c7a030b9233cad039cdd")
-(revision "8"))
-(package
-  (inherit rtl8821ce-linux-module)
-  (name "rtl8812au-aircrack-ng-linux-module")
-  (version (git-version "5.6.4.2" revision commit))
-  (source
-   (origin
- (method git-fetch)
- (uri (git-reference
-   (url "https://github.com/aircrack-ng/rtl8812au;)
-   (commit commit)))
- (file-name (git-file-name name version))
- (sha256
-  (base32 "012asiy43ik13kl9p97sscdsqq5jihq73s4ws3g5wqqczqcgrsvc"))
- (modules '((guix build utils)))
- (snippet
-  #~(begin
-  ;; Remove bundled tarballs, APKs, word lists, speadsheets,
-  ;; and other unnecessary unlicenced things.
-  (for-each delete-fi

bug#57232: [installer] ENTER in guided partitioner destroys partition table

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

Hi Mathieu,

Mathieu Othacehe 写道：
Er, I was… expecting that to mean it would pop up a pretty 
window or

something.  Is this really a feature?  Should it be?


I'm not sure what's the point here.


I'm not sure whose point you're referring to, so I'll clarify 
mine.


Currently, pressing ENTER on a whole disc device wipes its 
partition table, or at  least did so for me (MBR).  That's an 
unexpected way ‘to change a disk's partition table’ even if it's 
technically true.


It wasn't clear to me whether it was intentional, or a bug, or 
perhaps a bit of both.  Hence my question.  I agree that we should 
warn before writing anything, but that's somewhat orthogonal.


I had rewritten the dialogue before encountering this issue, but 
it doesn't seem like I understand the intention behind the design 
very well.  I'll drop the UI-related patches and leave that effort 
to someone who does.



we would be glad to get your support.


That wasn't the impression I got in response to some mild 
criticism, but thanks.  I'll keep working on it when I get that 
spare machine :-)


(I do consider the installer important to the project, even if I 
never claimed to be its target audience.)


Kind regards,

T G-R


signature.asc
Description: PGP signature

bug#57232: [installer] ENTER in guided partitioner destroys partition table

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

Hi Mathieu!

Mathieu Othacehe 写道：
What that does is immediately and without confirmation wipe the 
on-disc

partition table.  And its back-up.


Oops, glad you were able to recover, I was also bitten in the 
past.


My mistake for insisting on a bare metal test without a throwaway 
machine handy :-)



The attached patch adds an extra confirmation page before wiping
everything, WDYT?


Code looks all right.  I'll try it out.  Thanks!

The help text for users reads, in part:

 “You can change a disk's partition table by selecting it and 
 pressing ENTER.”


Er, I was… expecting that to mean it would pop up a pretty window 
or something.  Is this really a feature?  Should it be?


I have to be honest: I was extremely let down by the installer UX, 
*because* I read a lot of the code and can see how much effort 
went into it.  I hate pointing out that the partitioner is at once 
less useful and more dangerous than (system "fdisk").


:-/,

T G-R


signature.asc
Description: PGP signature

bug#57232: [installer] ENTER in guided partitioner destroys partition table

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

Hi all,

Whilst testing the graphical installer, I selected ‘guided 
partitioning’ and pressed ENTER on the main drive (sda) to see 
what that does.


What that does is immediately and without confirmation wipe the 
on-disc partition table.  And its back-up.


Testdisk is great,

T G-R


signature.asc
Description: PGP signature

bug#57229: ‘guix system image’ forces commit authentication?

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

Hi all,

There doesn't seem to be a way to opt out of commit authentication 
with ‘./pre-inst-env guix system image’.  Am I missing (a 
reasonable!) one?


I'd expect all commands that authenticate commits to honour 
‘--disable-authentication’.


--8<---cut here---start->8---
λ ./pre-inst-env guix system image -t iso9660 
gnu/system/install.scm
Updating channel 'guix' from Git repository at 
'/home/nckx/guix/'...

Backtrace:
In guix/gexp.scm:
  898:13 19 (_ _)
In guix/store.scm:
  1996:8 18 (_ _)
In guix/gexp.scm:
  300:22 17 (_ _)
In guix/store.scm:
  1996:8 16 (_ _)
In guix/gexp.scm:
  300:22 15 (_ _)
In guix/store.scm:
  1996:8 14 (_ _)
In guix/packages.scm:
 1876:11 13 (_ _)
In guix/build-system/channel.scm:
42:2 12 (_ _)
In guix/store.scm:
 2040:38 11 (_ #)
In guix/channels.scm:
   523:7 10 (loop _ _)
In guix/combinators.scm:
   48:26  9 (fold2 #   guix/channels.scm:523:13 (channel previous-channels 
   instances)> () () (#< …>))

In guix/channels.scm:
  533:29  8 (_ #< name: guix url: "/home/nckx/guix/" 
  branch: "master" commit: 
  "43513c4e93740e2a9dc4ca138f8b34434f66e170" …> …)
  421:12  7 (latest-channel-instance #  7bdb3437a460> _ #:patches _ #:starting-commit _ #:authenticate? 
  _ # _)

In guix/git.scm:
   299:7  6 (call-with-repository _ #   guix/channels.scm:384:2 (repository)>)

In guix/git-authenticate.scm:
   404:4  5 (authenticate-repository # _ 
   #vu8(187 176 45 223 44 234 246 168 13 29 230 67 162 160 109 
   242 # …) …)
  263:20  4 (load-keyring-from-reference # 
  _)

In git/branch.scm:
   101:8  3 (_ _ _ _)
In git/bindings.scm:
77:2  2 (raise-git-error _)
In ice-9/boot-9.scm:
 1685:16  1 (raise-exception _ #:continuable? _)
 1685:16  0 (raise-exception _ #:continuable? _)

ice-9/boot-9.scm:1685:16: In procedure raise-exception:
Git error: cannot locate remote-tracking branch 'origin/keyring'

λ ./pre-inst-env guix system image -t iso9660 
gnu/system/install.scm --disable-authentication

guix system: error: disable-authentication: unrecognized option
--8<---cut here---end--->8---

Kind regards,

T G-R


signature.asc
Description: PGP signature

bug#57222: Guix Tor service needs a little more authority

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

Hi all,

I recently found my Tor nodes dead, unable to bind to their port 
with a confusing ‘permission denied’ error.


This was caused by a regression in Guix's Tor service: it now uses 
‘least-authority-wrapper’, meaning that it… well, hasn't the 
authority to bind to all ports.  Oops.


Even today, (some, well-known) low ports are firewalled/flagged 
noticeably less than higher ones.  Thankfully, DPI isn't the norm 
yet.


Reverting commit fb868cd7794f15e21298e5bdea996fbf0dad17ca fixes 
this.


Our service wasn't insecure before: Tor expects to be started as 
root and drop privileges through the torrc ‘User’ directive, not 
the way Guix now does it through namespaces.


Still, I'll take a stab at relaxing the service's POLA parameters 
to allow this, hoping to get the best of both worlds, but this is 
new territory to me.  Maybe that's not possible.


Kind regards,

T G-R


signature.asc
Description: PGP signature

bug#57091: Git authentication reports subkey fingerprints

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

Hi Maxime,

Quick reply mainly to say thanks for replying :-)

On 2022-08-11 17:07, Maxime Devos wrote:

On 11-08-2022 13:17, Tobias Geerinckx-Rice wrote:


Apologies if I'm wildly off the mark here.  But then I'd like to
hear some plausible threat models.  Maxime?


Here's a problem with allowing subkeys, if that's what you mean:


(Well, you snipped my previous paragraph where I mention what you seem 
to describe below, so yes.)



* Expiration times and GPG-level revocation must be ignored (for
time-travel, and pulling from an old Guix), similarly to why it must
be ignored for when no subkeys are used
* Someone used to GPG-style subkeys generates a new subkey to
replace old expired subkey or revokes old subkey, without keeping in
mind that Guix doesn't take that in account.
* An attacker uses a compromised-but-revoked-or-expired subkey to
compromise the channel.


Why does none of this apply to primary keys?


Expiration times might be solvable by taking the commit time of the
previous commit as 'current time' (not the commit that was signed,
otherwise an attacker could just lie). I don't know a solution for
GPG-level revocation of old subkeys but I haven't looked either.


Git commit dates aren't reliable.  Requiring that they be accurate going 
forward would be imposing yet another 'artificial'/idiosyncratic 
limitation.  I think we should be very hesitant to build a verification 
system on assumptions stacked just so.



Another problem:

* When replacing the key in the 'keyring' branch with an 'updated'
key that contains the new subkey, we have to be careful to never
remove old subkeys, to avoid breaking time travel or pulling from old
versions.


Sure.  We always need to be careful when updating the keyring branch.

Kind regards,

T G-R

Sent from a Web browser.  Excuse or enjoy my brevity.

bug#57091: Git authentication reports subkey fingerprints

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

Of all the stupid typos...

>Ludo', are you worried that, since we already handle revocations like GPG would

...DON'T handle, of course, by design.

Kind regards,

T G-R

Sent on the go.  Excuse or enjoy my brevity.

bug#57091: Git authentication reports subkey fingerprints

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

This is not a mere UI issue.  Basic verification is currently broke^Wdifferent, 
too, or the latest incident wouldn't have happened.

Hmm.  I wonder...

Ludo', are you worried that, since we already handle revocations like GPG 
would, the 'proper' OpenPGPmodel could somehow break?  That we are in effect 
unable to safely fix this (yes, I maintain it is a) bug?

Apologies if I'm wildly off the mark here.  But then I'd like to hear some 
plausible threat models.  Maxime?

In their absence, nasty surprises like what happened last week are argument 
enough to (try to! :-) implement normal OpenPGP behaviour.



Kind regards,

T G-R

Sent on the go.  Excuse above-average rambliness.

bug#57127: unzip fails to cross-compile

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

(Now home:) fixed in 45db0ca5e9.

Can you confirm that it works for you?

Closing,

T G-R

Sent on the go.  Excuse or enjoy my brevity.

bug#57127: unzip fails to cross-compile

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

Hi Andrew,

This is a bug in Guix, not really related to cross-compiling (hence you can 
stop cross-testing and reporting different architectures, although the effort 
is appreciated!).

%output is practically deprecated, but is still present in a good number of 
packages.  Sometimes it happens to work, because a specific build system 
explicitly kept support for it.  Some build systems don't, making support for 
it feel unreliable.  It is.  %output is obsolete for new code.

What also happens is that build systems still support it in the well-tested 
native build path, but not when cross-compiling.  That seems to be the case 
here.

> Interestingly, it gives the same errors when explicitly building for x86_64 
> on an x86_64 machine, even though I would expect doing so to compile as 
> normal.

You don't define what you mean by 'explicitly building'.

If you mean --target=x86_64-linux-gnu, why would it not fail?  You're 
cross-compiling.  Guix doesn't silently fall back to a non-cross build when the 
architectures match, no should it IMO.

The fix should be simple: rewrite unzip to use gexps and hence #$output.  Why 
didn't I simply do so yet?  Because too many packages depend on unzip to simply 
do so on master.  There's probably a way around that, but I'll try it when I'm 
back at a computer.

Kind regards,

T G-R

Sent on the go.  Excuse or enjoy my brevity.

bug#57046: Spanish documentation uses exclusive language

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

Hi all,

On 2022-08-09 22:02, pelzflorian (Florian Pelz) wrote:

There has been plenty of debate elsewhere; no need to bother; I guess
there won’t be consensus. […] Could the bug be closed soon?


I'm torn.  I added & removed ‘-close’ a few times just now.

The initial post was doomed to be flame bate because of the subject 
matter, but was probably in good faith, apart from the title.


If it wasn't, it can be reinterpreted that way, and since when does 
authorial intent matter… :-)


But then, as deterministic dominoes in motion, we follow the unavoidable 
and predictable path downward.  Guix should follow my arbitrary grammar 
rules! — no it shouldn't.  Guix must listen only to my chosen 
demographic! — no it shouldn't.  Gender-neutral language is offensive to 
sexists! — good.


Notably scarce are arguments that actually stand on their own, that can 
help build a (new) consensus if you disagree with the current 
translation.


I don't speak much Spanish, but Ludo's suggestions sound great to me.  
How about we turn them into guidelines and add them to Contributing?


Kind regards,

T G-R

Sent from a Web browser.  Excuse or enjoy my brevity.

bug#57052: elogind-service specifies a variable that's ignored by defualt

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

>For the record, this was noticed and discussed more than a year ago, see
>Message-ID: <871rens9a2.fsf@nckx>.  It had fallen into the cracks

LOL.  I'm the one who asked Cairn to report this.  I didn't remember publicly 
reporting it, I only remembered noticing it and not fixing it, and didn't want 
it to get forgotten 'again'.  Sorry for the noise!

Strongly disagree that the current Guix behaviour makes any sense, let alone 
better!  That sounds like posthockholm rationalisation to me.  If people want 
opinionated variants, those can be written on top of a service that properly 
exposes upstream behaviour.


Kind regards,

T G-R

Sent on the go.  Excuse or enjoy my brevity.

bug#52029: wterm fails to start on core-updates-frozen

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

This sounds like the right thing to do.

Either of you feel like practicing a 'simple deprecation'?  ;-)

Kind regards,

T G-R

Sent on the go.  Excuse or enjoy my brevity.

bug#54691: fortune-mod propagates various non-nice things

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

Hi Liliana,

Liliana Marie Prikler 写道：

I'm not saying either option is worse than the other


I see; thanks for the clarification.

Then I *will* say that transparently upgrading to a package that 
does nothing is worse than simple removal.


In fact, all of the proposed hacks are…

Kind regards,

T G-R


signature.asc
Description: PGP signature

bug#54691: fortune-mod propagates various non-nice things

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

>To me use of ‘deprecated-package’ in this case is just to ensure that
>users who run ‘guix upgrade’ will transparently get
>‘fortune-jkirchartz’.  I don’t have a strong opinion though.

I believe what Liliana meant is that it's worse to 'transparently' upgrade to a 
data package that doesn't provide the 'fortune' command at all (or conversely, 
an implementation of the command that doesn't propagate the actual fortune 
data), than it is to signal to users through an error message that something's 
up and they need to stop and think.

(Er, that's a lot more words to put in someone's mouth than I intended to, 
sorry :-)

I'd suggest a news item but I really don't think this warrants it.

Kind regards,

T G-R

Sent on the go.  Excuse or enjoy my brevity.

bug#56847: [CI] ‘Build output’ artefact download links are broken

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

After the server migration, the ‘Build outputs’ links on pages 
like [0] return 502.


Kind regards,

T G-R

[0]: https://ci.guix.gnu.org/build/1123838/details


signature.asc
Description: PGP signature

bug#56799: (gnu services configuration) usage of *unspecified* is problematic

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

Hi Maxim,

Maxim Cournoyer 写道：

For some background reading, see [0].


Thanks for the well-thought-out reply, and sharing this 
interesting link!


Now, it's just the musings of one person, but now I think I do 
agree with (what I think is) the underlying vision: to hush up 
*unspecified* and sneakily replace it with true nothingness.  OK, 
I can live with that.  :-)


I think the semantic of the language is that it is to be used as 
the

lack of a return value from a procedure or syntax, e.g.:

(unspecified? (if #f 'one-arm-if)) -> #t


Well… in the above context I'd hesitate to even imply ‘semantics’. 
It's like undefined behaviour in C.  Ascribe it meaning at your 
peril.  Otherwise, point taken.


Having 'unspecified?' even defined in Guile seems to go against 
that

idea; perhaps because Wingo themselves seems to disagree in [0].


Agreed.  *This* was one of my reasons for supporting (field 
*unspecified*), so it's nice to have it validated, even if it is 
rejected.


I'm also thinking 'unspecified being too close to *unspecified* 
is
probably going to cause confusion down the line.  Reverting to 
the

originally used 'disabled may be the lesser evil.


Ah, here I can concentrate all my previous disagreement: hell no 
:-)


It is the worstest evil; literally anything is better than 
(enable-foo? 'disabled) defaulting to #t.


Bikeshed this all y'all want, but 'default or 'unset or 'whatever 
are miles better.


Kind regards,

T G-R


signature.asc
Description: PGP signature