bug#70689: guix search doesn't weigh word matches higher than subword matches

[bokr]

On +2024-04-30 22:18:03 -0400, Richard Sent wrote:
> Hi Guix!
> 
> When running guix search, relevance in synopsis and description fields
> are computed strictly by the number of matches, both as a word and as a
> subword. Ideally, if a search string matches an isolated word in a
> search, that result should be considered more relevant than simply
> matching a subword, even multiple times.
> 
> To illustrate, imagine trying to find what package provides the `rsh`
> binary and running running `$ guix search rsh`. This binary is part of
> `inetutils` and the description field contains:
> 
> > Inetutils is a collection of common network programs, such as an ftp
> > client and server, a telnet client and server, an rsh client and
> > server, and hostname.
> 
> Most likely, this is what the user is interested in. However, inetutils
> does not show up until roughly the ~75th result with a relevance of 2
> (the lowest possible relevance).
> 
> Almost every search result beforehand contains the string "rsh" as a
> component of another word, such as "marshaling", "powershell", and
> "hershey". However, these match multiple times and are weighted
> significantly higher.
> 
> Ideally, guix search should rate inetutils higher because the string
> "rsh" occurs as its own word, not as a component of another, unrelated
> word. (Very, very people would search "rsh" looking for matches with
> "hershey", even if "hershey" occurs multiple times.)
> 
> Another example of where this can happen is with "dig", part of the bind
> package. Searching for "dig" returns garbage because "dig" is a common
> subword. Bind is scored with a relevance of 2, even though bind's
> description emphasises that dig is part of it.
> 
> This would improve the experience when searching with strings that
> commonly occur as subwords.
> 
> Since this change can't occur in a vacuum, care should be taken not to
> reduce the effectiveness of other reasonably forseeable search queries.
> 
> -- 
> Take it easy,
> Richard Sent
> Making my computer weirder one commit at a time.
> 
> 
> 

I like your proposal :)

I'm wondering how [1] compares in what it does for your use(ful) case.
(I am not familiar with Hyper Estraier beyond being prompted for gnu.org 
searching)

[1] 

--
Regards,
Bengt Richter

bug#70215: Documentation about uninstalling

[bokr]

On +2024-04-11 02:08:35 +0200, Rostislav Svoboda wrote:
> Do you mean the guix-install.sh script? If so then what about the
> https://guix.gnu.org/manual/devel/en/guix.html#index-uninstallation_002c-of-Guix
> ?
> 
> 
> 
It says (a bit reformatted):
┌┐
│ Should you eventually want to uninstall Guix, run the same │
│ script with the --uninstall flag:  │
││
│ ./guix-install.sh --uninstall  │
││
│ With --uninstall, the script irreversibly deletes all the  │
│ Guix files, configuration, and services.   │
└┘

My 2 cents' worth:

That sounds dangerous -- what about putting all the deletions
in a TAR_DICT/TAR_FILE_NAME.tgz as a default, with suitable
default alternative commands for various capitalized names
in a (bash) select menu -- which could also include
"Just do it, I know what --uninstall does")

--
Regards,
Bengt Richter

bug#65924: git searches coreutils and util-linux commands in PATH

[bokr]

Hi,

On +2023-10-09 20:33:38 +0200, Liliana Marie Prikler wrote:
> Am Montag, dem 09.10.2023 um 14:21 -0400 schrieb Maxim Cournoyer:
> > Hello,
> > 
> > Liliana Marie Prikler  writes:
> > 
> > > [...]
> > > If you need me to reduce it to four letters, yes, LGTM.
> > 
> > Explicit is better than implicit.  I've been thinking to document
> > this in our contributing section; e.g. a reviewed commit must have
> > the 'LGTM' from the reviewer.  If a series is LGTM, it needs to be
> > implicitly mentioned with 'this series LGTM'.  That may sound silly,
> > but I think it'd simplify reviewer/submitters interactions.
> s/implicitly/explicitly/?
> 
> I don't necessarily agree, but it's not a hard disagree either.  I'll
> try to keep that in mind at least when reviewing your patches to not
> cause confusion.
> 
> Cheers
>

TL;DR: Would it make sense to anticipate that LLM-bots will be used
to automate gathering of info for reviewers?

If so, what would a style guide for english in posts (like
a coding style guide, but for LLM-bot consumption) look like?
Some kind of literate programming for LLM-bot and human use?

(I assume experiments have been going on by now, though perhaps
not yet for guile or guix)
--
Regards,
Bengt Richter

bug#62160: Guix reference manual link from guix.gnu.org?

[bokr]

On +2023-03-14 12:29:11 +0100, Simon Tournier wrote:
> Hi Simon,
> 
> On Mon, 13 Mar 2023 at 13:11, Simon Josefsson via Bug reports for GNU Guix 
>  wrote:
> 
> > I often go to guix.gnu.org to read the (excellent!) Guix manual.  This
> > leads to this click pattern: guix.gnu.org -> Help -> GNU Guix Manual
> > 1.4.0 which leads me to a page (written in english) to chose language
> > of the manual -- https://guix.gnu.org/en/manual/ -- and when I chose
> > English I get a page to chose format of manual --
> > https://guix.gnu.org/en/manual/en/ -- and that choice takes a split
> > second cognitive load.
> 
> Well, personally I never read en/manual/ but always en/manual/devel/. :-)
> 
> And I have a short-cut (or bookmark) for opening
> .
>
[...]

> Well, I do not have an opinion since I barely read released manual but
> only the more accurate devel manual.
> 
> However, my preference is about ’entirely on one page’ an not ’with a
> separate page per node’ because ’entirely on one page’ eases Control-f
> for searching. :-)
> 

I like that too :)

To work off-line, I like to do save-as to some-name.html
with which firefox creates a directory "some-name_files"
for images and css style stuff etc.

BUT: A nit: 

In firefox-esr, if you do "save-as ...", it will prompt with a file name
seemingly pretty directly copying the URL characters, in this case
"GNU Guix Reference Manual.html" -- which has spaces in it.

So my nuisance work flow is:
   - copy url from browser line into clipboard,
   - switch to a terminal,
   - touch $(sanitize-clipboard-url), ;; hack also puts clean name-string back 
in clipboard
   - switch to browser
   - delete undesired file name string from prompt by pasting in the clean name 
string
   - click save-as

I would really like Mozilla to solve this with configurable sanitization options
for the file name. Especially if I am looking at a page with an URL that has
weird non-ascii/utf-8 characters besides spaces.

But until Mozilla offers that, could GNU web pages have some kind of alias link 
on them
with a sanitized name to do save-link-as (not plain save-as) with,
so as to get a clean name?

[...]
> 
> Well, in addition, I would like to have a page proposition the manual
> for all the languages, as we have now.  For example, these two webpages:
> 
> https://guix.gnu.org/en/manual/devel/
> https://guix.gnu.org/fr/manual/devel/
>
+1 :)
--
Regards,
Bengt Richter

bug#61882: emacs-next-pgtk does not find emacs-org-roam, other path issues

[bokr]

Hi,

On +2023-03-01 12:16:56 +0100, Csepp wrote:
[...]
> How the hell would my paths affect what's in the bin folder?  Like, the
> flatpak binary is literally not present in the profile, that's why it's
> not showing up in $PATH.

Could something in one of your path directories
accidentally have gotten a name starting with '-' ?
(or full name '-')?

Surprising things can happen depending on how an
app rejects an unexpected option, or tries to use it :)

BTW: If you can't delete a file named '-'
 try emacs dirmode. IIRC emacs seems to see
 anything and be able to delete it.

Do you have any scripts that are both sourced and executed?
If so, are they doing return or exit respectively or
something trickier as intended?

--
Regards,
Bengt Richter

bug#46782: guix environment --expose options cannot be layered onto $PWD

[bokr]

Hi,

On +2023-02-06 16:54:20 -0500, Maxim Cournoyer wrote:
> Hi,
> 
> Simon Tournier  writes:
> 
> > Hi Maxim,
> >
> > A naive question since it works when using the --no-cwd option.
> >
> > On ven., 27 janv. 2023 at 11:19, Maxim Cournoyer 
> >  wrote:
> >
> >> --8<---cut here---start->8---
> >> guix environment -C --expose=/tmp=$PWD/tmp --ad-hoc bash coreutils \
> >>  -- bash -c 'stat $PWD/tmp'
> >> --8<---cut here---end--->8---
> >
> > Is $PWD referring to the same thing?  Because one is outside and the
> > other is inside.
> 
> Yes!  See:
> 
> --8<---cut here---start->8---
> maxim@hurd ~$ echo $PWD/tmp && guix environment \
>  -C --expose=/tmp=$PWD/tmp --ad-hoc bash coreutils -- bash -c 'echo $PWD/tmp'
> /home/maxim/tmp
> /home/maxim/tmp
> --8<---cut here---end--->8---
> 
> -- 
> Thanks,
> Maxim
>

I imagine the created environment is COW[1]
[1] 

Then your output above,
--8<---cut here---start->8---
> /home/maxim/tmp
> /home/maxim/tmp
--8<---cut here---end--->8---
looks the same, but IIUC they have different '/' root dirs, the one
in the container being like an initrd separate file system.

Or is --expose meant to be a shared rw reference to the caller's memory
(directory content or regular file etc) from the start?
That would seem hard to keep safe, so I doubt that's the design.

How do the two tmp's stat? (Before and after writing content
like $PWD/tmp/foo ?

And foo doesn't appear in the caller $PWD/tmp/* right?

What is your use case goal for --expose=/tmp=$PWD/tmp ?

SFTN if this is useless distraction.
--
Regards,
Bengt Richter

bug#58880: Patch impacting translation (was Re: bug#58880: 'guix gc' does not round the amount of disk space freed)

[bokr]

On +2023-01-23 08:51:16 +0100, zimoun wrote:
[ ... ]
> 
> Julien, the patch is here:
> 
> http://issues.guix.gnu.org/msgid/20221125203328.21379-1-re...@remworks.net

https://... works too, for me.
Any reason to prefer http://... ?

[ ... ]
> 
> Cheers,
> simo
> 
--
Regards,
Bengt Richter

bug#60816: guix pull ("computing Guix derivation") is not reproducible

[bokr]

Hi,

On +2023-01-15 15:35:31 +0100, Josselin Poiret via Bug reports for GNU Guix 
wrote:
> Hi again Julien,
> 
> Julien Lepiller  writes:
> 
> > it seems that on one machine, my .cache/guix/checkouts got polluted by
> > uncommited files. I have no idea why they're there, but cleaning them
> > should solve my issue, thanks!
> 
> It's not the first time we've seen this, we could probably consider
> adding a git clean after the reset in switch-to-ref.
> 
> Best,
> -- 
> Josselin Poiret

Could wrong timestamps on pushed files cause problems?

E.g., if you were working offline on a laptop where
cat /proc/driver/rtc
was significantly wrong at boot time, perhaps due to flaky CMOS battery,
or error in init specs? If you didn't connect to the internet and get
synced, couldn't you wind up with files with bad time stamps?

(I think I can dig up evidence of that, when I didn't connect,
though I don't show it here).

Could some Makefile action or some date-sensitive find or
if [[ file1 -nt file2 ]] then  
be wrongly triggered and leave mystery files around?

IWT synchronizing distributed monotonic time has to have been solved
a long ago, but old unnoticed errors do seem to wake up sometimes
in new circumstances.

I have been having mystery problems with time, which I have yet to
diagnose properly. One theory that matches some symptoms is if there
is a virtualized /proc/driver/rtc which gets a bogus value temporarily,
which gets accessed and stored by whatever stores time as boot time for
who -b to see forever (until shutdown) --
but date and other time functions see the virtual /proc/driver/rtc every
time, not a cached value, so they get corrected shortly after internet
is connected.

But what happens to file time stamps if you don't connect
to the internet for a long time?

BTW,I see the bad time at the top of the screen right after boot
but before reaching login, and IIRC it will currect to local without
logging in if I plug in the internet dongle.

Shown below I just booted from cold power-off, with 99% main battery,
about 17:20, so how to explain bogus who -b system boot time of 07:53
this morning? From that timee uptime at 17:20:06
would be: 9hrs 27min 6sec, not "1:14" (1hr 14min))

Well, I guess the 9 hours could be explained by root having a different
idea of locale at pre-internet boot time, but the 27min 6 sec?  

--8<---cut here---start->8---
who -b; uptime;date -Ins;grep rtc /proc/driver/rtc
 system boot  2023-01-15 07:53
 17:20:06 up  1:14,  1 user,  load average: 0.00, 0.08, 0.15
2023-01-15T17:20:06,768027575+01:00
rtc_time: 16:20:06
rtc_date: 2023-01-15
--8<---cut here---end--->8---

Also some anomalies in dmesg and journalctl -b, but inconclusive for me ;/

I noticed the bad "who -b" times because whenever my ~/.bash_profile
sees a change as I log in, it uses the date to create a new scratch
"boot-session" directory and updates a symbolic link to it at ~/bs
like stat -c %N ~/bs shows:
'/home/bokr/bs' -> '/home/bokr/BS/bs20230115_0753'
which is annoyingly wrong. It also makes a link to the previous ~/bs
in the new, like
'/home/bokr/bs/pbs' -> '../bs20230113_0427'
(showing some insomnia ;/ )

but if I cd ~/bs PS1 will display a nice short prompt :)
--8<---cut here---start->8---
[01:53 ~/bs]$ cd ~/bs
[01:53 ~/bs]$ realpath .
/home/bokr/BS/bs20230115_0753
[01:53 ~/bs]$ realpath ~/bs
/home/bokr/BS/bs20230115_0753
[01:54 ~/bs]$ 
--8<---cut here---end--->8---

HTH & SFTN if this is not useful or relevant.
--
Regards,
Bengt Richter

bug#59598: "Unsupported manifest format" error

[bokr]

Hi zimoun,

On +2022-11-27 13:22:22 +0100, zimoun wrote:
[...]
> 
> This file lives in the store.  Hum, I am surprised that a power shutdown
> removed this file.
>

Are all the conditions for a clean sync
of the file system where /gnu/store is mounted guaranteed?

What is the difference between power shutdown when you let
the battery run down and the OS shuts everything down
vs if you log out and click power down?

Is it not possible that when you have recharged the battery
and boot up that a journaling file system will discover traces
of an incomplete transaction (i.e. the one that was supposed
to record and  atomically commit the missing file) and discards
it to reestabllish coherent file system state?

And what about continuations that were possibly waiting for
availability of that file?

Hopefully the OS will recover a good state, but what can
userland innocents expect to be guaranteed, in terms of
work flow they can understand?

(those with the grok-fu to understand internals won't need
much to imagine failure scenarios, but will presumably
appreciate /design/rationale/implementation/ documentation tips)

> Well, I do not know if you can recover this empty file.  At least, you
> can the previous generation; e.g., guix package --roll-back.
>

Assuming the file system recovered -- a pretty good bet, but ... :)

> Or you can extract a previous manifest with,
> 
>   guix package -p 
> /var/guix/profiles/per-user//guix-profile--link \
>--export-manifest > /tmp/manifest-.scm
> 
> where  and  depends on.  Then,
> 
>   guix package -m /tmp/manifest-scm
> 
> will reinstall the same list of packages but at their current version
> (the ones of current Guix revision; guix describe).
>

> 
> Cheers,
> simon
> 
--
Regards,
Bengt Richter

bug#56398: (guix git) fails to check out repos with nested submodules

[bokr]

Hi,

On +2022-11-24 12:17:01 -0300, André Batista wrote:
> Hi!
> 
> qui 04 ago 2022 às 13:59:20 (1659632360), ludovic.cour...@inria.fr enviou:
> > I think we should instead report it upstream.  Do you feel like doing
> > it?  I guess we’d need to give them the C version of the three-line
> > snippet I gave earlier.
> 
> Upstream issue #6433[1]
> 
> Apparently, GIT_SUBMODULE_STATUS_WD_UNINITIALIZED isn't actually set
> in this scenario, only GIT_SUBMODULE_STATUS_IN_CONFIG.
> 
> 1. https://github.com/libgit2/libgit2/issues/6433
> 
> 
>

Wondering if this[1] is all history in gnu/guix-land:

[1] 

Wherein it says

--8<---cut here---start->8---
The problem has been patched in the versions published on
April 14th, 2020, going back to v2.17.x. Anyone wishing to
backport the change further can do so by applying commit
9a6bbee (the full release includes extra checks for git
fsck, but that commit is sufficient to protect clients
against the vulnerability). The patched versions are:
2.17.4, 2.18.3, 2.19.4, 2.20.3, 2.21.2, 2.22.3, 2.23.2,
2.24.2, 2.25.3, 2.26.1.
--8<---cut here---end--->8---

Is there an automated tool to answer the question,
"What executables (command line directly, or indirectly (including
config-directed interpretation)) does my system contain
that have known vulnerabilities?"

BTW: Newsflash: :)
 RMS paranoia now dernier-cri[3] as cited in [2]
[2] 
[3] 

Something[3] to get (more) serious about for gnu/guix?
--
Regards,
Bengt Richter

bug#58606: Emacs next pgtk crashes when pasting to other app

[bokr]

Hi Joshua,

On +2022-10-25 10:27:48 -0400, Joshua Branson via Bug reports for GNU Guix 
wrote:
> Andrew Tropin  writes:
> 
> > On 2022-10-18 10:52, Andrew Tropin wrote:
> >
> >> Recently discovered a problem, which reproduces this way:
> >> - Open a new emacs instance.
> >> - Yank anything with M-w or select with mouse.
> >> - Paste yanked text to chromium/icecat.
> >>
> 
> I sometimes run two instances of Emacs.  I discovered today, that Emacs
> cannot yank from one and paste to another.  When I try to paste I get this
> mysterious warning message in Emacs:
> 
> "waiting for reply from selection owner."
> 
> 
> 

Disclaimer: Sharing newbie discovery, inviting risk commentary, no warranty :)

A hack to get around clipboarding hangs (which I won't go into here :)
is (if you are safely by yourself on your laptop) this:

Select what you want to copy-paste as usual
(Ctl-Space and move point to end of region)
but then don't copy it with  Mx w --
instead do shell-op on region like
--8<---cut here---start->8---
Esc |
tee /tmp/foo
--8<---cut here---end--->8---
that should write your region into /tmp/foo

Then switch to your other emacs instance and insert
foo contents at point using

--8<---cut here---start->8---
Ctl-x i
/tmp/foo
--8<---cut here---end--->8---

tee should not have added any newline unless you had it in
your selected region, and Ctl-x i should insert verbatim.
(well, probably modulo different encodings in various buffers. Idk :)

If you want to hop between gui and emacs -nw it should work
fine there too. I've tried that.

If you want to do like append-string, adding to the end of foo, use
...|tee -a /tmp/foo
or use separate files ad lib, of course: whatever|tee /tmp/bar

If you want to be a bit safer, it'd probably be good to make
a restricted temp dir like

--8<---cut here---start->8---
$ mktemp -d /tmp/joshclips.XX.d
/tmp/joshclips.rinY4L.d
$ ls -ltra /tmp/joshclips.rinY4L.d/
total 8
drwxrwxrwt 16 root root 4096 Oct 26 12:59 ..
drwx--  2 bokr bokr 4096 Oct 26 12:59 .
--8<---cut here---end--->8---
(note the restricted write perm just to user, not group)

and then tee to
/tmp/joshclips.rinY4L.d/foo

Of course, if you want to preserve your cutting room detritus,
you can use other directories than /tmp :)

BTW, you could of course plain write foo with Crl-x w
but then you'd get interaction that using tee and insert avoids.

Also you could use cat > or cat >> in place of tee and tee -a
respectively, but then your selected region would disappear
because redirected cat effectively returns '' as the filtered region,
unlike tee which makes no mod, just sneaks a copy.

Using cat you'd have to undo with Crl-underscore.
No big deal, but tee avoids it :)

Please excuse that this wasn't on the fseg topic. SFTN.
--
Regards,
Bengt Richter

bug#58149: guix pull error

[bokr]

Hi Ludo, Simon, et interested ..

On +2022-10-04 12:11:52 +0200, Ludovic Courtès wrote:
> Hi,
> 
> Matthieu Haefele  skribis:
> 
> > Le 03/10/2022 à 16:03, Ludovic Courtès a écrit :
> 
> [...]
> 
> >> You should be able to get around it by first building things locally:
> >>
> >>guix build --no-substitutes \
> >>  $(guix gc --derivers 
> >> /gnu/store/r658y3cgpnf99nxjxqgjiaizx20ac4k0-guile-2.2.4)
> >>
> >> This is going to take a while though…
> >>
> >> I’m sorry this upgrade turns out to be so painful.  We know what to work
> >> on next.
> >>
> > Problems at fetching the kernel sources apparently...
> >
> > (base) mhaefele@mdlspc113:m2-mms-hpc (master)*$ guix build --no-substitutes 
> > \
> >> $(guix gc --derivers 
> >>/gnu/store/r658y3cgpnf99nxjxqgjiaizx20ac4k0-guile-2.2.4)
> > The following derivations will be built:
> >   /gnu/store/16c8c8hm1qdn6xz8014939mirc7c4d4j-guile-2.2.4.drv
> >   /gnu/store/06pscnfdljxnyb673pqyhnvz1x5rjl1l-libgc-7.6.6.drv
> > /gnu/store/4k028mc8dnnx478dirgx90rpby465jqr-ld-wrapper-boot3-0.drv
> >   /gnu/store/agrwc0hhkxjb96z66nb6hakimb4a2vg3-module-import.drv
> 
> [...]
> 
> > Starting download of 
> > /gnu/store/f2j6pi0d18pbz35ypflp61wzhbfcr8dp-linux-libre-4.14.67-gnu.tar.xz
> > From 
> > https://linux-libre.fsfla.org/pub/linux-libre/releases/4.14.67-gnu/linux-libre-4.14.67-gnu.tar.xz...
> > download failed 
> > "https://linux-libre.fsfla.org/pub/linux-libre/releases/4.14.67-gnu/linux-libre-4.14.67-gnu.tar.xz;
> >  404 "Not Found"
> 
> [...]
> 
> > Starting download of 
> > /gnu/store/f2j6pi0d18pbz35ypflp61wzhbfcr8dp-linux-libre-4.14.67-gnu.tar.xz
> > From 
> > https://mirror.hydra.gnu.org/file/linux-libre-4.14.67-gnu.tar.xz/sha256/050zvdxjy6sc64q75pr1gxsmh49chwav2pwxz8xlif39bvahnrpg...
> > In procedure connect: Network is unreachable
> 
> You can fetch it with:
> 
>   wget -O linux-libre-4.14.67-gnu.tar.xz \
>
> https://ci.guix.gnu.org/file/linux-libre-4.14.67-gnu.tar.xz/sha256/050zvdxjy6sc64q75pr1gxsmh49chwav2pwxz8xlif39bvahnrpg
>   guix download file://$PWD/linux-libre-4.14.67-gnu.tar.xz
> 
> Let’s see if you can proceed from there.
> 
> At any rate, it’s a good lesson for us developers, so thanks for
> persevering.
> 
> Ludo’.
> 

As you know, particular upstream kernels can be found like
--8<---cut here---start->8---
$ lynx -dump -listonly https://kernel.org/pub/linux/kernel/v4.x/ | egrep 
4.14.67\|sha256 
 558. https://mirrors.edge.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.14.67
3155. https://mirrors.edge.kernel.org/pub/linux/kernel/v4.x/linux-4.14.67.tar.gz
3156. 
https://mirrors.edge.kernel.org/pub/linux/kernel/v4.x/linux-4.14.67.tar.sign
3157. https://mirrors.edge.kernel.org/pub/linux/kernel/v4.x/linux-4.14.67.tar.xz
7177. https://mirrors.edge.kernel.org/pub/linux/kernel/v4.x/patch-4.14.67.xz
9018. https://mirrors.edge.kernel.org/pub/linux/kernel/v4.x/sha256sums.asc
--8<---cut here---end--->8---

Well, you noticed the extra pattern in the search, I'm sure. :)

What's interesting about sha256sums.asc is that you can do this:
--8<---cut here---start->8---
$ wget -q -O- 
https://mirrors.edge.kernel.org/pub/linux/kernel/v4.x/sha256sums.asc|egrep 
4\\.14\\.67
93b4ea4816a8a73e4ba2d9c26dc622035b1b504010f1048c0455a190a653166e  
ChangeLog-4.14.67
a53d3a3b5877e1847fb34ecb75aabce2a1bf3cc0ee7236cf2aef02f0ecf83433  
linux-4.14.67.tar.gz
3f4b056dc27233a78f7a4a35ed6fdcfd0a9680ec40b611a898bb6c8b905070ba  
linux-4.14.67.tar.xz
42c7ff27d7cefbf0b4e313c757db1f2cfa2d65fa22cbe908c24aafafc995bd5f  
patch-4.14.67.xz
--8<---cut here---end--->8---

Which provides a little menu of relevant things.
E.g, we can choose to download the .xz tarball and verify it like
--8<---cut here---start->8---
$ time wget -q 
https://mirrors.edge.kernel.org/pub/linux/kernel/v4.x/linux-4.14.67.tar.xz

real0m47.015s
user0m2.381s
sys 0m3.720s
$ sha256sum linux-4.14.67.tar.xz 
3f4b056dc27233a78f7a4a35ed6fdcfd0a9680ec40b611a898bb6c8b905070ba  
linux-4.14.67.tar.xz
--8<---cut here---end--->8---

IMO it would significantly enhance the security and trust assurances
provided by guile and guix repos to adopt this practice from kernel.org.

It is cheap and easy to implement, and provides an integrity check
which can coexist with others provided in various distro VCSs and
package management systems.

UIAM it would also provide another option in writing a package definition
in the part that defines how to get the source and check hashes.
(who wants to show how it would look for the hello pachage? :)

WDYT?

For me, a really trusted well known figure like GkH or Linus as signer
is reassuring, but I think whoever the person is is less important
than providing a verifiable public coherent snapshot (if race-careful)
listing of hash names for the set of files.

People can then discuss 

bug#44944: Unable to log into X session via gdm

[bokr]

wxr-xr-x 1 nixbld04 opendht96 Dec  8  2021 .
> drwxr-xr-x 1 nixbld04 opendht72 Dec  7  2021 ..
> -rw-r--r-- 1 nixbld04 opendht 52932 Dec  8  2021 Xorg.0.log
> -rw-r--r-- 1 nixbld04 opendht 53878 Dec  8  2021 Xorg.0.log.old
> -rw-r--r-- 1 nixbld04 opendht 10481 Dec  8  2021 Xorg.1.log
> -rw-r--r-- 1 nixbld04 opendht 10481 Dec  8  2021 Xorg.1.log.old
> --8<---cut here---end--->8---
> 
> We have some logic in %gdm-activation that was supposed to fix that, but
> it doesn't kick in, because it has some optimization to not recurse if
> the top dir has the correct permissions, and since d429878daf3 the top
> directory permissions are always controlled at system activation time
> (and this must happen before the gdm activation script runs).
> 
> I'll follow-up with a patch that puts /var/lib/gdm on a tmpfs.  This
> should avoid many pitfalls people have had.
> 
> Thanks,
> 
> Maxim
> 
> 
>

PS. WDYT..
(If there isn't a tool already available that'd make it easy to use
the one-liners pro devs can concoct off the top of their heads :)
..of having a package that would install a script
to output a reminder of stale-cache-items-in-general?

It could e.g. be triggered on login by a user
more than  since last login,
with output similar to guile's.

As a model I notice guile seems to notice stale cached .go files,
as demoed by:
--8<---cut here---start->8---
$ cat is-this-stale_q
#!/usr/bin/env -S guile -s
!#
(display "Test 1: is this stale??\n")
--8<---cut here---end--->8---

--8<---cut here---start->8---
$ ./is-this-stale_q
;;; note: auto-compilation is enabled, set GUILE_AUTO_COMPILE=0
;;;   or pass the --no-auto-compile argument to disable.
;;; compiling /home/bokr/BS/bs20220919_2206/./is-this-stale_q
;;; compiled 
/home/bokr/.cache/guile/ccache/2.2-LE-8-3.A/home/bokr/BS/bs20220919_2206/is-this-stale_q.go
Test 1: is this stale??
--8<---cut here---end--->8---

--8<---cut here---start->8---
$ ./is-this-stale_q
Test 1: is this stale??
--8<---cut here---end--->8---

$ fg # back to emacs for mod:  s/Test 1/Test 2/ 
emacs -nw is-this-stale_q

--8<---cut here---start->8---
$ ./is-this-stale_q
;;; note: source file /home/bokr/BS/bs20220919_2206/./is-this-stale_q
;;;   newer than compiled 
/home/bokr/.cache/guile/ccache/2.2-LE-8-3.A/home/bokr/BS/bs20220919_2206/is-this-stale_q.go
;;; note: auto-compilation is enabled, set GUILE_AUTO_COMPILE=0
;;;   or pass the --no-auto-compile argument to disable.
;;; compiling /home/bokr/BS/bs20220919_2206/./is-this-stale_q
;;; compiled 
/home/bokr/.cache/guile/ccache/2.2-LE-8-3.A/home/bokr/BS/bs20220919_2206/is-this-stale_q.go
Test 2: is this stale??
--8<---cut here---end--->8---

--8<---cut here---start->8---
$ ./is-this-stale_q
Test 2: is this stale??
--8<---cut here---end--->8---

bug#57046: Spanish documentation uses exclusive language

[bokr]

Hi,

tl;dr:

IMO this whole language neutering project, whose goal UIAM is
purportedly to exclude exclusion, is self-contradictory.

I.e., it excludes those who are used to natural language as they
have learned it (including words to charm or insult or play with),
and are not distracted by gender inflections in documentation.
If they opine about sex, they'll likely say "Vive la différence!"

If some people really need a neutered documentation language, fine:
Invent a sexlessperanto DSL and make that a translation target
which the sensitive can opt to read.

IMO it's a waste of time to contort normal natural language expressions
and idioms into eunuch grotesqueries. Besides, those annoyed by the nonsense
will be tempted to game the wording to tease the teasable anyway.

If you find yourself allergic to Mediterranean diets (word or food)
I feel sorry for you. But that doesn't give you a right to control
the menu anywhere other than in your kitchen.

Statistically Mediterranean diets are healthy, and healthy people can
digest sometimes spicy food, or words, and know how to spit out
the occasional chicken bone splinter. That's why we chew.
Didn't your mother teach you not to swallow things whole?
Chew words from an iffy dish well :)

My 2¢, sorry :)

On +2022-08-09 15:46:17 +0200, Ludovic Courtès wrote:
> Hola,
> 
> "pelzflorian (Florian Pelz)"  skribis:
> 
> > * the main Spanish translation po/guix/es.po uses usuario
> >
> > * the French translation switches between “utilisateur·rices”,
> >   “utilisatrices et utilisateurs” and more often masculine “utilisateurs”
> >
> > * the Portuguese, Russian, German translation use masculine (although at
> >   least for German I use feminine in some examples)
> >
> > * German word for users is masculine Benutzer and feminine is
> >   Benutzerinnen; there is a psychology study that Benutzer*innen is
> >   perceived feminine while listing both masculine and feminine Benutzer
> >   und Benutzerinnen is perceived as including men and women (a different
> >   language and I might give too much weight to one scientific study)
> >   
> > 
> 
> Just like for French, my suggestion would be to use a mixture of several
> techniques to achieve gender neutrality, probably in this order:
> 
>   • Using gender-neutral words—e.g., “personas” or “quién” rather than
> “usuarios”.
> 
>   • Talking to the user: “puedes hacer …” rather than “usuarios pueden
> hacer …”.
> 
>   • Using the -e suffix, which has the advantage of being concise and
> readable, but potentially off-putting (at least today).
> 
>   • Using repetitions, “usuarias y usuarios”.
> 
> Latin languages (among others) are problematic but techniques like these
> can get us a long way, and by mixing them we can avoid making the text
> hard to read.
> 
> Ludo’.
> 
--
Regards,
Bengt  Richter

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

[bokr]

Hi Liliana,

On +2022-08-08 12:45:10 +0200, Liliana Marie Prikler wrote:
> Am Sonntag, dem 07.08.2022 um 23:29 + schrieb Cairn:
> > "HandleLidSwitchExternalPower= is completely ignored by default (for
> > backwards compatibility)"[1]
> > 
> > I noticed (with help in IRC) that my laptop wasn't suspending on lid
> > close when plugged in and charging, which I hadn't seen happen on
> > other systems. I now know that I can set this by configuring the
> > `elogind-service` parameter `handle-lid-switch-external-power`.
> > Regardless, it seems like it should default to being unset rather
> > than set/ignored, since that would heed the line I quoted above.
> I think you're misreading that line.  What it states is not that
> "HandleLidSwitchExternalPower" is ignored by default, but
> "HandleLidSwitchExternalPower=" is ignored by default, i.e. there will
> be no value unless one was provided (whichever semantics "no value" has
> later on) is only confusingly explained later on.
> 
> IMHO the Guix behaviour of always setting a value is the right one
> (explicit is better than implicit after all).  As for the default
> values, one might disagree as to which fits, but I don't think ignoring
> lid switches while powered is harmful.
>

What would you advise if there's no battery power,
or for some reason one is running on plug power only,
for worriers that the bulding power might fail?

I'd guess a power brick would power for some milliseconds 
and wonder if this is detectable, i.e., to do something
at least to leave a goodbye world message somewhere if the machine
was not suspended with sufficient state to resume after power restore?

Buy a UPS, and don't go away long enough for that to run out? :)

> Cheers
> 
--
Regards,
Bengt Richter

bug#56030: rfc2822 permits that left paren, but why do it? -- was Re: bug#56030: The guix pull profile is too big

[bokr]

Hi "(" aka paren :)

On +2022-07-21 16:03:19 +0100, paren--- via Bug reports for GNU Guix wrote:
[ ... ]
> 
> -- (
> 
Are you hoping for some effect on a pre-rfc2822 parser??

Just curious :)
--
Regards,
Bengt Richter

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

[bokr]

Hi,

On +2022-08-04 21:58:16 +0200, Tobias Geerinckx-Rice via Bug reports for GNU 
Guix wrote:
> 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

I hope the original is preserved somewhere for history's sake.
So where can I get a copy to see what all the fuss is about? :)
--
Regards,
Bengt Richter
It ain't what they call you, it's what you answer to.
 -- W. C. Fields
Start every day off with a smile and get it over with.
 -- W. C. Fields

bug#56965: wterm does not work on sway

[bokr]

Hi Joshua,

On +2022-08-03 21:54:12 -0400, Joshua Branson via Bug reports for GNU Guix 
wrote:
> 
> wterm is said to be a simple terminal for wayland:
> 
> #+BEGIN_SRC shell  :results: raw
> guix show wterm | recsel -p synopsis
> #+END_SRC
> 
> #+RESULTS:
> : synopsis: Terminal emulator for Wayland
> 
> Well, when I try to use it, I get the following error on sway.  wterm
> does not start.
> 
> joshua@crazyhorse ~ (master)> wterm 
> wl_drm@11: error 0: authenticate failed
> # wayland_create_context: DRM authentication failed
> # wayland_create_context: No wl_shm global
> # wld_wayland_create_context: Could not initialize any of the specified 
> implementations
> Can't create wayland context
> 
> 
> Thanks,
> 
> Joshua
> 

Might you need to add video and maybe audio groups to your set of groups?

What do you get from
id $USER
or
groups
or, to see who else you share groups with
grep $USER /etc/groups
for adding groups to those you already have, I think check the -aG option
info usermod
I don't dare suggest the actual command for your system, so
you're on your own. If you have the sudo group, id $USER should show it,
and that's probably easier. If you go into root, you don't want
to add video,audio to root, so IIRC the options are a little different
to make sure you as $USER get the added groups, not root.
(BTW, try typing "id root" ;)

HTH
--
Regards,
Bengt Richter

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

[bokr]

Hi,

On +2022-08-02 09:31:14 +0200, Ludovic Courtès wrote:
> Hi,
> 
> Maxim Cournoyer  skribis:
> 
> > Ludovic Courtès  writes:
> >
> >> Hi!
> >>
> >> Maxim Cournoyer  skribis:
> >>
> >>> Since commit 8cb1a49a3998c39f315a4199b7d4a121a6d66449, the
> >>> define-configuration machinery in (gnu services configuration) uses
> >>> *unspecified* instead of 'disabled for an unspecified field value.
> >>
> >> As Attila wrote, the rationale as discussed in
> >>  was to specifically use a “special”
> >> value without a read syntax in lieu of a symbol like 'disabled.
> >>
> >>> While this is indeed an improvement in readability, it introduces an
> >>> extra complication: because this new value is not self-quoting, it
> >>> cannot be used as is in G-Exps, and values using it must be carefully
> >>> expanded outside the gexp context, which is error prone.
> >>
> >> Could you give a simple example of how this can happen?
> >>
> >> In my experience, one would use ‘define-maybe’ and appropriate field
> >> serializers such that *unspecified* never goes through.  Previously
> >> you’d check for (eq? x 'disabled) and now you just check for
> >> (unspecified? x).
> >
> > Yes, I understand that.  What changed is that previously you could have
> > the configuration serialized and used on the service side, which is what
> > using *unspecified* made impossible.
> 
> Do you have an example?  Even on the service side, I imagine one could
> check for ‘unspecified?’ just like one would check for 'disabled, no?
> 
> > Granted, few services outside of Jami probably made use of this, but it
> > was nevertheless a useful property.
> 
> I don’t know of any.
> 
> Having spent time reviewing the original change that Attila proposed and
> then chiming in on this issue, I would have hoped for a longer
> discussion before enacting the change in
> a2b89a3319dc1d621c546855f578acae5baaf6da.
> 
> In addition to these issues around the process, I think we should strive
> for more stability.  One of the reasons it took time to review
>  is that interface changes are a
> commitment.  Now commit a2b89a3319dc1d621c546855f578acae5baaf6da
> introduces a second interface change for reasons that are unclear to me
> (if the conclusion had been to revert, I’d have favored an actual revert
> rather than introducing 'unset).
> 
> How should we move forward?
>

My 2¢ :

Maybe separate commmit churn more formally into a
release candidate series like Linus does for linux kernel,
and have a long term stable guix only get what is agreed
with solid consensus?

AND, importantly: where issues involve subtleties
of abstract entities vs their concrete representations,
make sure this is clearly documented in the commit rationale,
e.g., maybe using denottional semantics[1] like r5rs ?

[1]:  

:)

> Thanks,
> Ludo’.
>
--
Regards,
Bengt Richter
OT PS: Has Boot-to-guile been updated by anyone?
Kudos for the original! :) A RISCV qemu image? :)

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

[bokr]

Hi Tobias,

On +2022-07-31 01:46:07 +0200, Tobias Geerinckx-Rice via Bug reports for GNU 
Guix wrote:
> 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

Works for me now, (2022-07-31T11:56:53+02:00)  BUT:

If you take a screen shot of [0] and look at it a year from now,
you will not have a clue as to what year the dates refer to, and
even looking with stat at the screen shot file is not going to
be 100% unless you were careful not to copy it somewhere without cp -a.

So, I would really like to see that date style deprecated,
in favor of date '+%F %T' or date -Is or date -Ins depending
on need to avoid spaces.

At a minimum, put the base year someplace on the page, so
the other dates can be interpreted unambigously.

2¢ ;-)
--
Regards,
Bengt Richter

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

[bokr]

Hi,

On +2022-07-27 14:31:32 -0400, Maxim Cournoyer wrote:
> Hi,
> 
> Tobias Geerinckx-Rice  writes:
> 
> > Hi Maxim,
> >
> > Maxim Cournoyer 写道：
> >> I'd suggest we revisit 8cb1a49a3998c39f315a4199b7d4a121a6d66449 to
> >> use
> >> 'unspecified (the symbol) instead of *unspecified*, which *can* be
> >> serialized without any fuss in gexps.
> >
> > Bah.  Could we provide our own reader?
> >
> > I'd much rather this be addressed in Guile (or failing that,
> > transparently by Guix) than have to deal with some magical
> > symbol. IIRC that was the argument for using *unspecified* in the
> > first place, and I think it makes sense.
> >
> > This looks more like an unexplored oversight than a well-reasoned
> > restriction to me.
> 
> This was my original impression, but thinking more about it, it became
> apparent that *unspecified* is well, unspecified and shouldn't be relied
> on by people to be something well defined.  For some background reading,
> see [0].  So it seems wrong in Scheme to actively set things to
> *unspecified*, and give a specific meaning to 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
> 
> Having 'unspecified?' even defined in Guile seems to go against that
> idea; perhaps because Wingo themselves seems to disagree in [0].
> 
> 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.
> 
> Other thoughts?
> 
> Thanks,
> 
> Maxim
> 
> [0]  
> https://scheme-reports.scheme-reports.narkive.com/QSQtJSAh/unspecified-values
> 
> 
>

Lots of systems are dealing with this issue, it seems, judging from
[1] https://en.wikipedia.org/wiki/Bottom_type

I think the problem is you really need a tuple to return both data and metadata
unambiguously from anything that produces a result (or not, which is a result).
Something like read-delimited with the 'split option, or using catch.

Personally, if I were designing a language :), my goal would be to have
nothing unspecified, and no undefined behaviour outside of physical failures ;-)

*unspecified* seems me like an ok word for the unasserted/high-impedance
state of tri-state memory address bus electronic logic,
but IMO the example above
--8<---cut here---start->8---
> (unspecified? (if #f 'one-arm-if)) -> #t
--8<---cut here---end--->8---

is not nice. (A nit, but For one thing "specified?" ought to be the question 
IMO,
if you are ging to have that concept, not "unspecified?" :)

What about using characters from some private upper unicode section
to represent various kinds of unspecified things? E.g.,
as guile named chars,

#\unspecified_function_retval
#\unspecified_function_error
#\unspecified_macro_err
#\unspecified_exception

#\nil or #\not_an_object -- or #\nao -- can't use #\n :)
#\paradox  -- e.g., (eval-nl-string "this sentence is lying")
#\nonsense -- e.g. when a question is based on false premises
 (eval-nl-string "Bob is bareheaded: Bob, is your hat too tight?")  
 

 Hm, one could argue that (+ "ab" "cd") could be based on the false
 premise that + was overloaded like
--8<---cut here---start->8---
scheme@(guile-user) [1]> (let*( (+ string-append) (sum (+ "ab" "cd"))) sum)
$8 = "abcd"
--8<---cut here---end--->8---
 and if it wasn't, should return #\nonsense :)
 (though maybe as part of the exception, which is practical for 
debugging etc :)
#\
#\guix_bottom -- a private unicode rather than U+22A5 which could be
 returned as a valid character value by some functon.
--8<---cut here---start->8---
$ echo -en "\u22a5"|unicode-info
"⊥":
glyph  codepoint .int  name...
_⊥_ +U0022a5 8869  UP TACK  
--8<---cut here---end--->8---

Well, hope you can extract something useful from the above :)

BTW, I didn't get far via the link [0] :(
--8<---cut here---start->8---
烙 Hungry for data? 烙

   As you guessed, this page is to confirm your affiliation to the human race.

   about - legalese

   Loading...
--8<---cut here---end--->8---
Ok machine, you identified me as human, and kept me out. Happy?
No, I know, machines can only fake that.
--
Regards,
Bengt Richter

bug#54691: [PATCH 2/5] gnu: Add fortunes-jkirchartz.

[bokr]

Hi,

On +2022-07-23 22:53:59 +0200, Liliana Marie Prikler wrote:
> Am Samstag, dem 23.07.2022 um 21:56 +0200 schrieb Maxime Devos:
> > On 23-07-2022 17:11, Liliana Marie Prikler wrote:
> > 
> > > +     (revision "2022.05.23"))    ; Use a date rather than a
> > > number
> > 
> > This is a technically a possibility, but currently the convention is
> > to use numbers and the number convention is expected by (guix
> > upstream) and the (not yet merged, needs some finishing touches IIRC)
> > latest-git updater, and AFAIK there hasn't been any discussion on
> > switching to dates.
> In this case I am departing from the usual convention because I think
> calendar versioning is more useful for this type of content.  Given the
> issue that lead to this patch at all, I'm not sure if support for
> automatic updates would be a good idea with this package.  IMHO, it's a
> feature rather than a bug that you can't accidentally pull a third of
> BSD's offensive database, were it to ever land in this repo.
> 
> Should I explain this thought more clearly in the package or do
> automatic updates trump ethical concerns?
> 
> 
> 

I like the .MM.DD format to tag data with a version
cookie, but I sometimes (not often) wind up with more than
one version in a day, so I like to allow at least an optional
single lower case [a-z] suffix, e.g., (revision "2022.05.23b")

just 2¢ :)
--
Regards,
Bengt Richter

bug#20255: [bug#56382] [PATCH] gnu: gajim: Use hicolor-icon-theme to avoid crashing on startup

[bokr]

Hi Ludo,

On +2022-07-18 11:29:55 +0200, Ludovic Courtès wrote:
> Hi,
> 
> Maxim Cournoyer  skribis:
> 
> > Hi Ludovic,
> >
> > Ludovic Courtès  writes:
> >
> >> Hi,
> >>
> >> "Raghav Gururajan"  skribis:
> >>
>  Does simply adding ‘hicolor-icon-theme’ to ‘inputs’ fix the issue?
> >>>
> >>> Most gtk-based apps expect hicolor-icon-theme and adwaita-icon-theme to 
> >>> be in the profile. Adding these in either system or user profile would 
> >>> prevent this error from occurring.
> >>
> >> Right, so the proposed patch (adding ‘hicolor-icon-theme’ to ‘inputs’,
> >> not ‘propagated-inputs’) shouldn’t make any difference I guess?
> >
> > I think it works as inputs because of our wrappers (perhaps
> > XDG_DATA_DIRS)?  But it's kind at odds with our policy which is to let
> > users manage icons themselves.
> 
> Yeah.
> 
> > Probably because of #20255 that wouldn't help currently (system and user
> > profiles are not merged), but if we fixed that bug we could make the
> > situation better by adding 'hicolor-icon-theme' to the default packages
> > of our desktop system templates.
> 
> Right.
> 
> BTW, the reason the solution at 
> was rejected could be revisited.  Since that time, search paths made it
> into the manifest itself, which brings a speed up:
> 
> --8<---cut here---start->8---
> $ sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches '
> $ time guix package -p ~/.guix-home/profile -p /run/current-system/profile 
> --search-paths > /dev/null
> 
> real0m0.540s
> user0m0.131s
> sys 0m0.063s
> $ time guix package -p ~/.guix-home/profile -p /run/current-system/profile 
> --search-paths > /dev/null
> 
> real0m0.135s
> user0m0.130s
> sys 0m0.024s
> --8<---cut here---end--->8---
> 
> Thoughts?
> 
> Ludo’.

I'm sure you were just after a quick indication and know what can affect timing,
but I'm curious:

What would the above results be if you did the second timing
first, after a power down and cold start?

I'm guessing the kernel file systems are pretty clever about
caching stuff, especially if you have lots of ram :)

I.e., what cached state could the first timing have left for the second to 
profit from?

(I've been fooled maany times, benchmarking and timing :)

--
Regards,
Bengt Richter

bug#56398: (guix git) fails to check out repos with nested submodules

[bokr]

Hi,

On +2022-07-07 23:45:35 -0300, André Batista wrote:
> qui 07 jul 2022 às 18:35:42 (1657229742), nan...@riseup.net enviou:
> > I think this may be actually a bug upstream. (...)
> 
> I mean, we could change the submodule-update fetch-options to allow
> for repository initialization when it's absent, but does it make
> sense considering we would just remove it when building the package
> and use package inputs' version instead?
>

Have you seen this[1] re nested git tricks? 

[1]:

i.e., are you sure not to be used by some such attack?
(article was over a year ago, so there must be more on
related git problems by now?)

--
Regards,
Bengt Richter

bug#56353: sbcl-2.2.6 build fail

[bokr]

Hi,

On +2022-07-02 20:26:40 +0100, Christopher Baines wrote:
> 
> Guillaume Le Vaillant  writes:
> 
> > [[PGP Signed Part:Undecided]]
> > Christopher Baines  skribis:
> >
> >> Tobias Geerinckx-Rice via Bug reports for GNU Guix  
> >> writes:
> >>
> >>> On 2 July 2022 09:29:22 UTC, Wensheng Xie  wrote:
> Das Erstellungsprotokoll kann unter 
> „/var/log/guix/drvs/6l/q7dfdfzrlp24lmhj95fcnvkr2mrqfz-sbcl-2.2.6.drv.bz2“ 
> eingesehen werden.
> >>>
> >>>
> >>> This log file is always a good idea to include.
> >>
> >> I think this is the equivalent non-grafted derivation:
> >>
> >>   
> >> https://data.guix.gnu.org/gnu/store/m7xw777v5agldb76gbqkqdvrrlj5d7zy-sbcl-2.2.6.drv
> >>
> >> There are plenty of failed builds on bordeaux.guix.gnu.org. I managed to
> >> get it to build successfully once though on my laptop.
> >>
> >> Guillaume, any ideas if sbcl@2.2.6 is just really unlikely to build
> >> successfully, or if there's particular conditions for it to build?
> >>
> >> Thanks,
> >>
> >> Chris
> >
> > According to the logs, the 'build-doc' phase fails to compile the
> > documentation for SIMD related functions. There's a patch disabling this
> > part of the doc unless we compile on x86_64, but maybe not all x86_64
> > CPUs have the required instructions...
> >
> > Would it be possible to get the result of "lscpu" on some machines where
> > it fails?
> 
> Sure, here is the lscpu output from the bayfront and harbourfront
> machines.
> 
[...]

I wonder what running this at the time builds failed would have shown:

--8<---cut here---start->8---
#/usr/bin/bash
# ~/bin/top-1-sans-hilights -- single snap of top without highlight escapes (no 
top opt for that??)
top -n 1 | \
sed -e 's:[\r][^\r]*[\r]\+::g' -e 's:[\x07\r]::g' -e 's:.\x08::g' \
-e 's:\x1B\[[^a-zA-Z]*[a-zA-Z]\x0f*::g' \
-e 's:\xe2\x80\x98:":g' -e 's:\xe2\x80\x99:":g'
--8<---cut here---end--->8---
(no guarantees on my hack to get rid of the highlighting escapes
and utf8->ascii quote subst :)
(top seems to assume even -n 1 output is always going to interactive dest)

Anyway, wondering: Could memory and CPU loading at the time
have triggered the build failure?
--
Regards,
Bengt Richter

bug#51466: bug#53355: guix shell --check: confusing error message

[bokr]

On +2022-06-27 12:17:08 +0200, Ludovic Courtès wrote:
> Hi Chris,
> 
> Chris Marusich  skribis:
> 
> > It turns out that it is probably not OK to rely on shell redirection in
> > this case, after all.  For example, "dash does not support multi-digit
> > file descriptors":
> >
> > https://bugs.launchpad.net/ubuntu/+source/dash/+bug/249620
> 
> Bah.  :-/
> 
> [...]
> 
> > To resolve this, I changed the code so that it just writes to a
> > temporary file.  This is simple and more robust.  With the attached
> > patch, I was able to use a command like the one above to verify that
> > "guix environment --check" works correctly for Guix-built bash, dash,
> > ksh, fish, zsh, and ash.  I also verified that it works for Fedora's
> > /bin/sh and /bin/bash.
> >
> > What do you think of this file-based approach?  Supporting many
> > different shells is pretty tricky, but I think this patch does a good
> > enough job.
> 
> Like Maxime, I’d rather not create a temporary file.
> 
> I agree that Dash should be fixed, but in the meantime, we still want
> our stuff to work with the broken Dash (it’s the default on
> Debian/Ubuntu, isn’t it?).
> 
> I don’t have a better idea to offer though…
> 
> Ludo’.
> 
> 
>
If this is all about capturing an environment as text,
how about

--8<---cut here---start->8---
xargs -0 < /proc/$$/environ
--8<---cut here---end--->8---

(not limited to $$ I would think)
--
Regards,
Bengt Richter

bug#51466: bug#53355: guix shell --check: confusing error message

[bokr]

On +2022-06-25 19:40:48 +0200, Maxime Devos wrote:
> Chris Marusich schreef op za 25-06-2022 om 09:52 [-0700]:
> > Yes, I agree those are good reasons to avoid a temporary file if we
> > can.
> > To that end, do you know if we can somehow force Guile to use a
> > specific
> > file descriptor for the pipe?  In the patch I wrote earlier, which
> > uses
> > redirection, the problem was that I could not control Guile's choice
> > of
> > file descriptors.  Guile chose file descriptor 19 for one end of the
> > pipe, and I don't know how to make it use anything else.  If we can
> > arrange for Guile to consistently use file descriptor 7, for example,
> > then probably it would work in all the shell I've tested.
> > 
> > I wonder if maybe I can just duplicate the file descriptor?  I don't
> > know; if for example Guile reserves all the file descriptors below 10
> > for other uses, it might be hard.
> > 
> 
> Have a look at ‘(guile)Ports and File Descriptors’.  It has lots of
> procedures for duplicating and renumbering.  That's fragile though, you
> might accidentally overwrite an fd that's being used for something
> else.
> 
> (Normally move->fdes would prevent overwriting things by moving pre-
> existing fds out of the way, adjusting ports automatically, but move-
> >fdes doesn't know (yet) about the pipe that Guile uses for
> finalisation, see maybe:
> )
> 
> I think it would be best to patch the dash appropriately (though fixing
> move->fdes would be nice too).
> 
> Greetings,
> Maximee.

Could this help?:

(from man 2 openat (scroll down a fair bit):
-8<---cut here---start->8---
  There are two main use cases for O_TMPFILE:

  *  Improved tmpfile(3) functionality: race-free creation of temporary files 
that (1) are automatically
 deleted  when closed; (2) can never be reached via any pathname; (3) are 
not subject to symlink at‐
 tacks; and (4) do not require the caller to devise unique names.

  *  Creating a file that is initially invisible, which is then populated with 
data and adjusted to have
 appropriate  filesystem  attributes (fchown(2), fchmod(2), fsetxattr(2), 
etc.)  before being atomi‐
 cally linked into the filesystem in a fully formed state (using linkat(2) 
as described above).

  O_TMPFILE requires support by the underlying filesystem; only a subset of  
Linux  filesystems  provide
  that  support.   In  the  initial  implementation,  support was provided in 
the ext2, ext3, ext4, UDF,
  Minix, and shmem filesystems.  Support for other filesystems has subsequently 
been added  as  follows:
  XFS (Linux 3.15); Btrfs (Linux 3.16); F2FS (Linux 3.16); and ubifs (Linux 4.9)
--8<---cut here---end--->8---

BTW, IIRC, this can be used to create an invisible file that
can be mmap-ed, and the mmap will persist when you delete
the file. Which then can be used as an anonymous buffer
passed to wayland, along with metadate saying what the buffer
contains, e.g. different kinds of rgb or rgba permutations
and encodings, (or anything, which you can tell wayland just
to keep track of for you.

You need a directory for openat, so probably
XDG_RUNTIME_DIR=/run/user/1000
is suitable if it exists. Worked in my case.

HTH
--
Regards,
Bengt Richter

bug#53355: bug#51466: bug#53355: guix shell --check: confusing error message

[bokr]

Hi Chris,

Did you observe this behaviour inside a git repo directory?
I wonder if this git security thing could be relevant:
https://lwn.net/Articles/892755/
It makes also me wonder about readline completion stuff
possibly interacting. Isn't that implemented with readline?

I have had some mystery bash parsing errors, and I noticed
set|less
shows a heck of a lot of functions defined that I don't
remember seeing in the past. 
Anyway, shouldn't stuff like that have better hygiene than just prefixed
_underscore ? Or maybe set|less doesn't show all that on your system?

Disclaimer: I played a lot of games trying to make stuff conditional
at login, where I  renamed .bash_profile and .bashrc (e.g. .my_bashrc)
which brought .profile into play, and I messed with the downstream
of that to source some .my_'s conditionally, so I've go a fragile mess right 
now ;/

Anyway, did you determine why things changed in the first place?
Or will this be a whack-a-mole game with future weirdnesses? :)

Semms like IWBN to have interfaces governed by contracts :)

Best,
Bengt Richter

On +2022-06-19 13:40:50 -0700, Chris Marusich wrote:
> Hi Ludo,
> 
> Thank you for the review!
> 
> Ludovic Courtès  writes:
> 
> > LGTM, please push!
> 
> Before pushing, I did some more tests to make sure it was still working.
> When I did this, I noticed that read-line was no longer returning
> strings that end in "\r".  This prevents child-shell-environment from
> behaving correctly, since it incorrectly assumes that all the lines end
> in "\r", stripping it off unconditionally.  In the past, I'm sure
> read-line was returning strings that end in "\r".  I don't know what
> changed, but I've attached a second patch that fixes this issue, also.
> 
> Unless you have more feedback, I'll go ahead and push both patches to
> master in a few days.
> 
> -- 
> Chris
> 
> PGP: https://savannah.gnu.org/people/viewgpg.php?user_id=106836

> From c4fee9e63f8cb694de86ae46bd1e2e4c692eb6f6 Mon Sep 17 00:00:00 2001
> From: Chris Marusich 
> Date: Sun, 19 Jun 2022 13:16:04 -0700
> Subject: [PATCH] environment: Don't assume that lines have a trailing "\r".
> 
> I've noticed that the child-shell-environment procedure is misbehaving on my
> computer because the lines returned by read-line do not have a trailing "\r".
> In the past, I recall that such lines did in fact have a trailing "\r".  I'm
> not sure why it changed, but it seems prudent to just rewrite this code to
> tolerate both cases, since it seems that both cases can happen.
> 
> * guix/scripts/environment.scm (child-shell-environment) [lines]: Instead of
> checking if the line exactly matches "GUIX_CHECK_DONE\r"; check if the line
> begins with "GUIX_CHECK_DONE".  Instead of always stripping the trailing
> character from the line, only do it if the line has a trailing "\r".
> ---
>  guix/scripts/environment.scm | 13 +
>  1 file changed, 9 insertions(+), 4 deletions(-)
> 
> diff --git a/guix/scripts/environment.scm b/guix/scripts/environment.scm
> index f0cb341aab..1fb4f5b7c6 100644
> --- a/guix/scripts/environment.scm
> +++ b/guix/scripts/environment.scm
> @@ -462,13 +462,18 @@ (define lines
>;; prompt from getting mixed into what we read.
>(match (read-line shell-pipe-in)
>  ((? eof-object?) (reverse lines))
> -("GUIX-CHECK-DONE\r"
> +((? (lambda (line)
> +  ;; The line might or might not have a 
> trailing \r.
> +  (string-prefix? "GUIX-CHECK-DONE" line)))
>   (display "done\n" port)
>   (reverse lines))
>  (line
> - ;; Drop the '\r' from LINE.
> - (loop (cons (string-drop-right line 1)
> - lines
> + ;; Strip the trailing '\r' from LINE if present.
> + (let ((stripped-line
> +(if (string-suffix? "\r" line)
> +(string-drop-right line 1)
> +line)))
> +   (loop (cons stripped-line lines)
>   (close-port port)
>   (close-port shell-pipe-in)
>   (waitpid pid)
> -- 
> 2.34.0
> 

bug#54786: Installation tests are failing

[bokr]

Hi,

tl;dr: I hope there will be a security team discussing
   whether/how this kind of privileged execution interval
   could be exploited, and how to prevent such.
   
   E.g., could something that stealthily gets put in a finalizer
   for some innocent object be waiting to notice that it is running
   privileged, and do the next step in a dirty-work chain that
   sets things up nicely for e.g. remote DDOS control?

   Or is the independent FLOSS development process
   and its quality control being sabotaged stealthily
   with injections of "innocent mistakes" and
   (ultimately) trivial time-wasting bugs, making FLOSS projects
   look "not ready for production use" ?
   (despite the increasing evidence to the contrary)
  
   BTW, I think a minimalist/MES/RISCV team would be interesting!

   Regards,
   Bengt Richter
   
On +2022-06-07 16:00:54 +0200, Ludovic Courtès wrote:gets\
> Hi!
> 
> Maxim Cournoyer  skribis:
> 
> > Ludovic Courtès  writes:
> 
> [...]
> 
> >>> I reviewed how that works, and it'd be easy; I just didn't see the
> >>> incentive yet (there's no composition needed for the service, and it'd
> >>> make the definition slightly less readable).  If you tell me
> >>> mark+forkexec-constructor/container is going the way of the Dodo though,
> >>> that's a good enough incentive :-).
> >
> > That turns out to be bit problematic; dbus-daemon must not run in its
> > own user namespace (CLONE_NEWUSER) as it wants to validate user/group
> > IDs.  That's probably the reason it was working with
> > 'make-forkexec-constructor/container', as this was dropping the user and
> > net namespaces, contrary to least-authority, which uses them all.
> >
> > The problem then seems to be that since we need CAP_SYS_ADMIN when
> > dropping the user namespace, as CLONE_NEWUSER is what gives us
> > superpowers.  Per 'man user_namespaces':
> >
> >   The child process created by clone(2) with the CLONE_NEWUSER flag starts
> >   out with a complete set of capabilities in the new user namespace.
> >
> > Which means that if we combine something like (untested):
> >
> > (make-forkexec-constructor
> >   (least-authority
> > (list (file-append coreutils "/bin/true"))
> > (mappings (delq 'user %namespaces))
> >   #:user  "nobody"
> >   #:group "nobody"))
> >
> > the make-forkexec-constructor will switch to the non-privileged user
> > before the clone call is made, and it will fail with EPERM.
> >
> > When using 'make-forkexec-constructor/container', the clone(2) call
> > happens before switching user, thus as 'root' in Shepherd, which
> > explains why it works.
> 
> Damnit, that’s right.  For example the result of:
> 
>(lower-object (least-authority-wrapper (file-append coreutils "/bin/uname")
>   #:namespaces (delq 'user 
> %namespaces)))
> 
> won’t run as an unprivileged user:
> 
> --8<---cut here---start->8---
> $ $(guix build /gnu/store/hy8rd8p8pid67ac27dwm63svl5bqn0a1-pola-wrapper.drv)
> substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
> substitute: updating substitutes from 'https://bordeaux.guix.gnu.org'... 
> 100.0%
> substitute: updating substitutes from 'https://guix.bordeaux.inria.fr'... 
> 100.0%
> The following derivations will be built:
>   /gnu/store/hy8rd8p8pid67ac27dwm63svl5bqn0a1-pola-wrapper.drv
>   /gnu/store/bd63i07rvvsw7xgsig0cbdsw7fpznd1k-references.drv
> building /gnu/store/bd63i07rvvsw7xgsig0cbdsw7fpznd1k-references.drv...
> successfully built /gnu/store/bd63i07rvvsw7xgsig0cbdsw7fpznd1k-references.drv
> building /gnu/store/hy8rd8p8pid67ac27dwm63svl5bqn0a1-pola-wrapper.drv...
> successfully built 
> /gnu/store/hy8rd8p8pid67ac27dwm63svl5bqn0a1-pola-wrapper.drv
> Backtrace:
>5 (primitive-load 
> "/gnu/store/ifsh87aifh2k8pqzhkjxncq3vskpwx3l-pola-wrapper")
> In ice-9/eval.scm:
>191:35  4 (_ #f)
> In gnu/build/linux-container.scm:
> 300:8  3 (call-with-temporary-directory # gnu/build/linux-container.scm:396:3 (root)>)
>397:16  2 (_ "/tmp/guix-directory.K9gBNH")
> 239:7  1 (run-container "/tmp/guix-directory.K9gBNH" (#< 
> device: "/gnu/store/jkjs0inmzhj4vsvclbf08nmh0shm7lrf-attr-2.5…> …) …)
> In guix/build/syscalls.scm:
>   1099:12  0 (_ 1845624849)
> 
> guix/build/syscalls.scm:1099:12: In procedure clone: 1845624849: Operation 
> not permitted
> --8<---cut here---end--->8---
> 
> > I'm not sure how it could be fixed; it seems the user changing business
> > would need to be handled by the least-authority-wrapper code?  And the
> > make-forkexec-constructor would probably need to detect that command is
> > a pola wrapper and then avoid changing the user/group itself to not
> > interfere.
> 
> I think we would add #:user and #:group to ‘least-authority-wrapper’ and
> have it call setuid/setgid.  ‘make-forkexec-constructor’ doesn’t need to
> be modified, but 

bug#55361: [Installer] Extra unprivileged “root” account added

[bokr]

Hello,

On +2022-05-21 00:19:06 +0200, Ludovic Courtès wrote:
> Ludovic Courtès  skribis:
> 
> > The installer built from:
> >
> > Generation 214  May 02 2022 21:44:14(current)
> >   guix 6b588da
> > repository URL: https://git.savannah.gnu.org/git/guix.git
> > branch: master
> > commit: 6b588da368c77cde82ea2f22ca315116228777ad
> >
> > … adds an unprivileged “root” account to the ‘users’ section of the OS
> > config.
> 
> Fixed in 48c748226e2a94d2dec9bfdf84601455f00d6f5e, which reverts
> c2125e59d0774cda3e559adeb056459a5f23586b.
> 
> Ludo’.
> 
> 
>
--8<---cut here---start->8---
commit c2125e59d0774cda3e559adeb056459a5f23586b
Author: Mathieu Othacehe 
Date:   Mon Apr 4 16:38:09 2022 +0200

installer: user: Remove useless filtering.
--8<---cut here---end--->8---


--8<---cut here---start->8---
commit 48c748226e2a94d2dec9bfdf84601455f00d6f5e
Author: Ludovic Courtès 
Date:   Fri May 20 20:41:02 2022 +0200

Revert "installer: user: Remove useless filtering."

This reverts commit c2125e59d0774cda3e559adeb056459a5f23586b.

Fixes .
--8<---cut here---end--->8---

Assuming my date-diff hack worked:
--8<---cut here---start->8---
~/wb/guix]$ date-diff '2022-04-04 16:38:09' '2022-05-20 20:41:02'
46days 4hrs 2min 53sec
--8<---cut here---end--->8---

Is this like coming home from 46day vacation and noticing
that, oops, someone left the kitchen door open,
and hoping no ++ungoodniks noticed? Or meh?

Is. or should there be, a required signoff on an
exploitability assessment in the commit, when it
has that scent? (e.g. anything possibly opening
a door to root privilges).

Personally, I am happy to see "fixed," but I would be happier
seeing a signed exploitability assessment, esp if by someone
concentrating on that aspect of things.

Thoughts?

--
Regards,
Bengt Richter

bug#43986: core-updates' grep and coreutils fail strerror_r and perror2 tests in gnulib-tests on armhf-on-aarch64

[bokr]

Hi Danny,

On +2020-10-17 12:20:11 +0200, Danny Milosavljevic wrote:
> How do I debug this?
> 
> $ guix-core-updates/guix/pre-inst-env guix environment -s armhf-linux --pure 
> grep
> 
> needs grep (it's in the implicit native inputs), and that grep has a test 
> failure.

What if the test failure tested a grep feature that you don't actually need 
from the implicit native input grep?

Is there no way to use a fully valid subset of a tool's functionality (that 
excludes irrelevant test failures
of unused broken functionality) if there's a test failure in testing everything?

If one could express a dependency on a limited subset by passing also a 
required-features list, à la ACL?,
maybe dependencies could trigger less builds, and the feature lists might 
reveal opportunities
for optimizing out some dependencies, e.g. where a bash shell's one or two grep 
invocations might
depend on grep only for a regex match that might easily be rewritten with 
bash's own built-in '=~'

One could imagine builds producing ELFs with bitvectors flagging features built 
and tested,
for efficient dynamic safe-capability determination re usage by dependents, but 
I better stop rambling.

So, monolith dependencies vs factoring, how to balance?

> 
> So I can't actually enter the environment for building grep and running
> 
>make check
> 
> .
> 
> What now?

HTWNEU -- Hope This Was Not Entirely Useless :)
-- 
Regards,
Bengt Richter