bug#70215: Documentation about uninstalling
On +2024-04-11 15:10:56 +0200, Rostislav Svoboda wrote: > > ./guix-install.sh --uninstall > > [...] > > That sounds dangerous > > Yeah a bit. > > > -- 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") > > Eeeh? I don't understand what you mean. > Sorry, I should have explained. I just wanted a simple way to save /exactly/ what uninstall would delete. so it wouldn't be "irrevocable," in case the uninstall is too eager about its job ;) A dry run of that size would be a scrolling blur, I think, and not much use unless captured, and then it would take a lot of boring unreliable reading before you could decide for sure that it was ok to do the uninstall. Maybe guix pack could make a tarball of exactly what uninstall would delete, e.g., guix pack --uninstall-victim-files with options of where to write it. > Nevertheless, `./guix-install.sh --dry-run --uninstall` would be nice. > However the script is over 800 lines long. In bash! :-( > IMO before increasing script complexity with a new feature, we should > rewrite it to some reasonable language, preferably Guile Scheme. Or at > least Python. > Well, guix pack is already scheme, right? Why couldn't it invoke uninstall after safely having completed packing the uninstall-victim-files ? WDYT? Simon? Ludo? Anyone? :) > Cheers Bost -- Regards, Bengt Richter
bug#62160: Guix reference manual link from guix.gnu.org?
Hi, On +2023-03-14 18:35:36 +0100, b...@bokr.com wrote: [...] > 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. > Sorry, I think it just copies whatever XXX is in the html header as XXX but some sites have weird strings in their titles, so the problem remains.. > 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? I would still like this option, but I'm not sure how to implement such an alias link in a static page. IWG no problem if the header is dynamically generated ?? -- Regards, Bengt Richter
bug#51466: bug#53355: bug#51466: bug#53355: guix shell --check: confusing error message
On +2022-06-27 13:23:15 +0200, b...@bokr.com wrote: > > > 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--- > > [...] > Actually, why fight shell stuff when guile can read it? Or are these modules not available in your context? --8<---cut here---start->8--- scheme@(guile-user)> (use-modules (ice-9 textual-ports)) scheme@(guile-user)> (define ep (open-input-file "/proc/12430/environ")) scheme@(guile-user)> (define es (get-string-all ep)) --8<---cut here---end--->8--- es from above got it all, when I tried manually as above. FWIW I also did the same with (use-modules (rnrs bytevectors)) and the nulls show up as the expected zeroes. -- Regards, Bengt Richter
bug#51466: bug#53355: bug#51466: bug#53355: guix shell --check: confusing error message
Sorry again, but I found the source:
tl;dr: These functions are defined in
/usr/share/bash-completion/bash_completion
which looks awful kludgey to me, (however clever :)
There is a reference to
http://lists.gnu.org/archive/html/bug-bash/2009-03/msg00155.html
in the header comments for
_quote_readline_by_ref ()
I also found
https://askubuntu.com/questions/571544/bash-tab-completion-bash-unexpected-eof-while-looking-for-matching-bash
My bet is there is at least one bug active now.
Completion is really nice when it works, but IMO they certainly
shouldn't use a name like unadorned ``quote'' in their implementation.
And I think it would be prettier in scheme :)
Lots could be prettier if bash could be extended with scheme.
I'm about out of time to chase this, but I expect to bump into it again ;/
HTH.
--
Regards,
Bengt Richter
On +2022-06-20 19:56:56 +0200, Bengt Richter wrote:
> Sorry to reply to myself, but forgot to illustrate.
>
> On +2022-06-20 12:12:10 +0200, b...@bokr.com wrote:
> > Hi Chris,
> [...]
> >
> > 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?
> >
>
> There are a couple functions without prefixed underscore too,
> which invoke some underscore-prefixed ones that look too trusting
> of their arguments if you ask me: can someone declare these safe?
>
> I think I can grok quote () ...
> (escape single quotes and enclose result in single quotes, trusting bash
> state)
> But what if I want to define my own function quote?? How would I know I was
> overriding this? I really don't like my programming space occupied by
> unknowns :-(
>
> --8<---cut here---start->8---
> quote ()
> {
> local quoted=${1//\'/\'\\\'\'};
> printf "'%s'" "$quoted"
> }
> --8<---cut here---end--->8---
>
> but this one below will take more time than I want to spend on code
> I'm not intentionally going to use, and which invites name clashes
> in my command name space :-(
>
> --8<---cut here---start->8---
> quote_readline ()
> {
> local quoted;
> _quote_readline_by_ref "$1" ret;
> printf %s "$ret"
> }
> --8<---cut here---end--->8---
>
> where the above calls this:
>
> --8<---cut here---start->8---
> _quote_readline_by_ref ()
> {
> if [ -z "$1" ]; then
> printf -v $2 %s "$1";
> else
> if [[ $1 == \'* ]]; then
> printf -v $2 %s "${1:1}";
> else
> if [[ $1 == ~* ]]; then
> printf -v $2 ~%q "${1:1}";
> else
> printf -v $2 %q "$1";
> fi;
> fi;
> fi;
> [[ ${!2} == \$* ]] && eval $2=${!2}
> }
> --8<---cut here---end--->8---
>
> HTH somehow.
> --
> Regards,
> Bengt Richter
>
>
>
bug#53355: bug#51466: bug#53355: guix shell --check: confusing error message
Sorry to reply to myself, but forgot to illustrate.
On +2022-06-20 12:12:10 +0200, b...@bokr.com wrote:
> Hi Chris,
[...]
>
> 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?
>
There are a couple functions without prefixed underscore too,
which invoke some underscore-prefixed ones that look too trusting
of their arguments if you ask me: can someone declare these safe?
I think I can grok quote () ...
(escape single quotes and enclose result in single quotes, trusting bash state)
But what if I want to define my own function quote?? How would I know I was
overriding this? I really don't like my programming space occupied by unknowns
:-(
--8<---cut here---start->8---
quote ()
{
local quoted=${1//\'/\'\\\'\'};
printf "'%s'" "$quoted"
}
--8<---cut here---end--->8---
but this one below will take more time than I want to spend on code
I'm not intentionally going to use, and which invites name clashes
in my command name space :-(
--8<---cut here---start->8---
quote_readline ()
{
local quoted;
_quote_readline_by_ref "$1" ret;
printf %s "$ret"
}
--8<---cut here---end--->8---
where the above calls this:
--8<---cut here---start->8---
_quote_readline_by_ref ()
{
if [ -z "$1" ]; then
printf -v $2 %s "$1";
else
if [[ $1 == \'* ]]; then
printf -v $2 %s "${1:1}";
else
if [[ $1 == ~* ]]; then
printf -v $2 ~%q "${1:1}";
else
printf -v $2 %q "$1";
fi;
fi;
fi;
[[ ${!2} == \$* ]] && eval $2=${!2}
}
--8<---cut here---end--->8---
HTH somehow.
--
Regards,
Bengt Richter
bug#54941: No such file or directory when running a binary
Hi Maxime & Haider, (This is not to accuse you Haider, who I don't know, of probing Maxime -- but consider the seemingly casual example you are setting for noobs in suggesting running an unknown (to others) binary). On +2022-04-16 15:32:44 +0200, Maxime Devos wrote: > Haider Mirza schreef op do 14-04-2022 om 16:34 [+0100]: > > Easiest way to reproduce this by unzipping the binary in this Github > > repo: > > https://github.com/FluxHarmonic/ld50-silent-syphon/releases/tag/dev > > I'm not running random binaries. Anyway, AFAICT, this is not (yet?) > free software, so I'm considering to close this? > > Greetings, > Maxime. In [0]: --8<---cut here---start->8--- The con starts off as many that target individuals do nowadays: With a text message. In this case it's not a phishing attempt, it's an attempt to ascertain whether the person receiving the message is susceptible to further manipulation. --8<---cut here---end--->8--- [0] https://www.theregister.com/2022/04/15/the_latest_scam_pay_yourself/ So, Maxime, ["I'm not running random binaries."] you are apparently not "susceptible to further manipulation." :) Good for you, but what about warning less sophisticated guix noobs more actively? -- Regards, Bengt Richter
bug#54864: GNU Cuirass reports arm64 as armhf
Hi Christopher, Tl;dr: [Meta-Reply] I think IWBN if a busy volunteer like yourself could add a cookie in an email like yours that would automatically provide a "heads-up" to readers of the documentation you intend to patch. The idea is that emails could be automatically scanned for such cookies/markup, e.g. maybe "[Pending-Patch]", next to an URL for the doc in question, which URL could then simply be appended to a log file of such urls, (maybe together with date and author from the email header). People could manually grep it if reading a document that is confusing, to check if an update is on the way, for starters. But if it's a good idea, then I would hope document reading tools would start to make automatic use of it, maybe starting with a notice like "Heads Up: [Pending-Patch]" when opening the doc or section of the doc. It could grow features as people came up with new and better ideas, but I think there are developers here that could prototype something useful in an evening :) Thus, given that you took the time to write your email, it would not have been much extra trouble adding the cookie so your text below would look like e.g., ([Pending-Patch] https://guix.gnu.org/cuirass/manual/cuirass.html#Specifications) (IIUC that's the doc you intend to patch) :) HTH in some way. Better ideas? I don't mind :) On +2022-04-11 17:55:41 -0400, Christopher Rodriguez wrote: > Reporting this from my local installs of GNU Cuirass, though a cursory glance > at > ci.guix.gnu.org (likely) shows the same issue: > > GNU Cuirass currently reports both `armhf-linux` and `arm64-linux` targets as > `armhf-linux` on the web interface. > > This is not only incorrect, but potentially confusing to newcomers: I have > spent > some free time in the last week or two (after purchasing an MNT Reform) trying > to get my home server to build packages for deployment on an ARM-based > laptop. I > only discovered that I was targeting the 32-bit version of ARM after asking on > IRC (and then looking through the logs: > https://logs.guix.gnu.org/guix/2022-04-11.log#221203 or thereabouts, where > vagrantc mentions `armhf` as suffering bitrot and goes on to mention both > `aarch64` and `arm64` in another sentence). > > This is not helped by the Documentation > (https://guix.gnu.org/cuirass/manual/cuirass.html#Specifications) not giving > any > examples of supported platforms, highly-search-engine-ranked issues and blog > posts (https://issues.guix.gnu.org/54055 and > https://guix.gnu.org/en/blog/2021/cuirass-10-released/ for instance, both > front-page google) only mentioning `armhf-linux`, and all running instances of > GNU Cuirass not even listing `arm64-linux` as an option. > > When I have time (I am out of town for the rest of the week) I will try to > submit a patch for the documentation to list the available targets. Changing > the > UI is more complex (though wider-reaching) and a bit more out of my > wheelhouse. Help there would be appreciated. > > -- > > Christopher Rodriguez -- Regards, Bengt Richter
bug#54111: guile bundles (a compiled version of) UnicodeData.txt and binaries
Hi guix, On +2022-02-27 20:52:38 +0100, Maxime Devos wrote: > Maxime Devos schreef op zo 27-02-2022 om 20:45 [+0100]: > > * Add 'perl' (or 'perl-boot0' because that perl is probably good > > enough?) to the native-inputs of guile. > > > > Actually, the second is already done in 'guile-final'. > > Maybe this being done in 'guile-final' and 'guile-3.0-latest' is > sufficient? Which package exactly verifies doesn't seem important, > as long as some package does it. > > Greetings, > Maxime. I'm wondering how many lines of perl code actually would have to be translated to guile to eliminate this perl dependency. Does the perl code upstream get changed too often to make keeping up an acceptable chore? (I guess I'm assuming the code is like one screenful with a hot loop accessing a bunch of static tables. I haven't chased it :) -- Regards, Bengt Richter
bug#54064: Packaging request: Ultimaker Cura
On +2022-02-22 18:32:12 +, Jacob Hrbek wrote: > kreyren@leonid # dmesg -w > ... > [1112144.472508] usb 2-1.4: new full-speed USB device number 52 using > ehci-pci > [1112144.581981] usb 2-1.4: New USB device found, idVendor=1a86, > idProduct=7523, bcdDevice= 2.64 > [1112144.582001] usb 2-1.4: New USB device strings: Mfr=0, Product=2, > SerialNumber=0 > [1112144.582008] usb 2-1.4: Product: USB Serial > [1112144.582624] ch341 2-1.4:1.0: ch341-uart converter detected > [1112144.584305] usb 2-1.4: ch341-uart converter now attached to ttyUSB0 > > kreyren@leonid $ ls /dev/tty[^0-9]* > /dev/ttyprintk /dev/ttyS14 /dev/ttyS20 /dev/ttyS27 /dev/ttyS5 > /dev/ttyS0 /dev/ttyS15 /dev/ttyS21 /dev/ttyS28 /dev/ttyS6 > /dev/ttyS1 /dev/ttyS16 /dev/ttyS22 /dev/ttyS29 /dev/ttyS7 > /dev/ttyS10 /dev/ttyS17 /dev/ttyS23 /dev/ttyS3 /dev/ttyS8 > /dev/ttyS11 /dev/ttyS18 /dev/ttyS24 /dev/ttyS30 /dev/ttyS9 > /dev/ttyS12 /dev/ttyS19 /dev/ttyS25 /dev/ttyS31 /dev/ttyUSB0 > /dev/ttyS13 /dev/ttyS2 /dev/ttyS26 /dev/ttyS4 > > Looking at the output it seems to be looking for ^\/dev\/ttyUSB[0-9]+ for > various baud rates on stock Creality Ender-3 > > > > I don't know anything about your context, BTW ;) -- Richter > > Elaborate? I just meant to indicate that I probably can't help you, as I just idly wondered whether my laptop had a /dev/ttyUSB0 too, as a standard thing, and it did not. So I wondered if your device might actually be available on your system under a different name than /dev/ttyUSB0, e.g. /dev/ttyS0 (which has mystery colored underscore tail as your listing appears on my display: [ /dev/ttyS0 ]. I don't know where the standard for naming is defined, or if it comes from module whose author can define custom names for software for a particular device, or anything else I might speculate about, but this email has used up the last of the time I have for this. :) Sorry not to be more helpful. > > On 2/22/22 19:23, Bengt Richter wrote: > > On +2022-02-19 14:27:42 +, Jacob Hrbek wrote: > > > Ultimaker Cura is a powerful LGPL-3.0 licensed STL-to-GCODE generator > > > (https://github.com/Ultimaker/Cura) used for 3D printing. > > > > > > Additionally it is capable of enabling printing through USB on GNU Guix > > > which is currently not possible as no guix package is able to recognize > > > and send fabricating instructions to /dev/ttyUSB0 which is provided by > > > the printers (note that the user has to be in `dialout` group in order > > > to use the device). > > > > > I get this (i.e., S1 instead of USB) > > > > --8<---cut here---start->8--- > > $ ls /dev/tty[^0-9]* > > /dev/ttyS0 /dev/ttyS1 /dev/ttyS2 /dev/ttyS3 > > --8<---cut here---end--->8--- > > > > What do you get? > > > > I don't know anything about your context, BTW ;) > > > > > -- > > > Jacob Hrbek, In support of ukraine sovereignty #supportUkraine > > > > > pub EdDSA 256/AB42FCA9 2021-01-21 krey...@rixotstudio.cz > > > > > sub ECDH 256/86142789 2021-01-21 > > > > > -- > > Regards, > > Bengt Richter > > -- > Jacob Hrbek, In support of ukraine sovereignty #supportUkraine > pub EdDSA 256/AB42FCA9 2021-01-21 krey...@rixotstudio.cz > sub ECDH 256/86142789 2021-01-21 > -- Regards, Bengt Richter
bug#54064: Packaging request: Ultimaker Cura
On +2022-02-19 14:27:42 +, Jacob Hrbek wrote: > Ultimaker Cura is a powerful LGPL-3.0 licensed STL-to-GCODE generator > (https://github.com/Ultimaker/Cura) used for 3D printing. > > Additionally it is capable of enabling printing through USB on GNU Guix > which is currently not possible as no guix package is able to recognize > and send fabricating instructions to /dev/ttyUSB0 which is provided by > the printers (note that the user has to be in `dialout` group in order > to use the device). > I get this (i.e., S1 instead of USB) --8<---cut here---start->8--- $ ls /dev/tty[^0-9]* /dev/ttyS0 /dev/ttyS1 /dev/ttyS2 /dev/ttyS3 --8<---cut here---end--->8--- What do you get? I don't know anything about your context, BTW ;) > -- > Jacob Hrbek, In support of ukraine sovereignty #supportUkraine > pub EdDSA 256/AB42FCA9 2021-01-21 krey...@rixotstudio.cz > sub ECDH 256/86142789 2021-01-21 > -- Regards, Bengt Richter
bug#53696: Integer overflow on Guix GC size calculation
Sorry for following up my own post, but maybe it wasn't clear why I printed (* 17592186042897 (expt 2 20)) in hex ? That is the value of [17592186042897 MiB] that you've been discussing. (expt 2 20) is one MiB Does that make > --8<---cut here---start->8--- > $ guile --no-auto-compile -c '(use-modules (ice-9 format))(format #t > "~20x\n~20x\n~20d\n" (* 17592186042897 (expt 2 20)) #xa110 #xa110)'; > a110 > a110 > 2702180352 > --8<---cut here---end--->8--- a little clearer? The discussion seems to be continuing, but no mention of the above. How come? Feeling ignored, and top-posting in desperation ;/ CC-ing ludo, who will instantly know where to fix it, if he hasn't already. On +2022-02-02 13:04:41 +0100, Bengt Richter wrote: > Hi Maxime, Ekaitz, et al, > > On +2022-02-02 11:05:31 +0100, Maxime Devos wrote: > > Ekaitz Zarraga schreef op di 01-02-2022 om 14:06 [+]: > > > [17592186042897 MiB] deleting > > > '/gnu/store/wbz6vkiz7cq8c531xvb31lxm28nz332i-ghc-8.10.7' > > > > For comparison, this is about 16 exbibyte. > > According to <https://en.wikipedia.org/wiki/Byte#Multiple-byte_units>, > > that's more than the global monthly Internet traffic in 2004. > > > > According to <https://what-if.xkcd.com/31/>, 16 exbibyte would be about > > 17 million solid-state disks. Even though this ignores deduplication, > > this seems rather expensive. > > > > My guess is that the size of a store item was misrecorded somewhere. > > > > Greetings, > > Maxime. > > s/misrecorded/mis-defined-in-record/ ? > Wild guessing follows: > > --8<---cut here---start->8--- > $ guile --no-auto-compile -c '(use-modules (ice-9 format))(format #t > "~20x\n~20x\n~20d\n" (* 17592186042897 (expt 2 20)) #xa110 #xa110)'; > a110 > a110 > 2702180352 > --8<---cut here---end--->8--- > > It looks to me like a 32-bit unsigned int should have been turned to 64-bit > unsigned long or bigint > but somehow got cast/interpreted as signed, becoming signed 64-bit long, > which then in turn was seen by the print as 64-bit unsigned long. > > I don't know, but if records are being used, perhaps some slot > integer-widening logic > might be involved? Or a mis-defined int slot that should have been long to > accomodate > big > 31-bit positive integers? > > Just guessing wildly -- I think I saw something about records and defining > their fields > as fixed C ints or longs. > > -- > Regards, > Bengt Richter > > >
bug#53696: Integer overflow on Guix GC size calculation
Hi Maxime, Ekaitz, et al, On +2022-02-02 11:05:31 +0100, Maxime Devos wrote: > Ekaitz Zarraga schreef op di 01-02-2022 om 14:06 [+]: > > [17592186042897 MiB] deleting > > '/gnu/store/wbz6vkiz7cq8c531xvb31lxm28nz332i-ghc-8.10.7' > > For comparison, this is about 16 exbibyte. > According to <https://en.wikipedia.org/wiki/Byte#Multiple-byte_units>, > that's more than the global monthly Internet traffic in 2004. > > According to <https://what-if.xkcd.com/31/>, 16 exbibyte would be about > 17 million solid-state disks. Even though this ignores deduplication, > this seems rather expensive. > > My guess is that the size of a store item was misrecorded somewhere. > > Greetings, > Maxime. s/misrecorded/mis-defined-in-record/ ? Wild guessing follows: --8<---cut here---start->8--- $ guile --no-auto-compile -c '(use-modules (ice-9 format))(format #t "~20x\n~20x\n~20d\n" (* 17592186042897 (expt 2 20)) #xa110 #xa110)'; a110 a110 2702180352 --8<---cut here---end--->8--- It looks to me like a 32-bit unsigned int should have been turned to 64-bit unsigned long or bigint but somehow got cast/interpreted as signed, becoming signed 64-bit long, which then in turn was seen by the print as 64-bit unsigned long. I don't know, but if records are being used, perhaps some slot integer-widening logic might be involved? Or a mis-defined int slot that should have been long to accomodate big > 31-bit positive integers? Just guessing wildly -- I think I saw something about records and defining their fields as fixed C ints or longs. -- Regards, Bengt Richter
bug#51787: Disk performance on ci.guix.gnu.org
Hi Ricardo, TL;DR: re: "Any ideas?" :) Read this [0], and consider how file systems may be interacting with with SSD wear-leveling algorithms. Are some file systems dependent on successful speculative transaction continuations, while others might slow down waiting for signs that an SSD controller has committed one of ITS transactions, e.g. in special cases where the user or kernel file system wants to be sure metadata is written/journaled for fs structural integrity, but maybe cares less about data? I guess this difference might show up in copying a large file over-writing the same target file (slower) vs copying to a series of new files (faster). What happens if you use a contiguous file as swap space? Or, if you use anonymous files as user data space buffers, passing them to wayland as file handles, per its protocol, can you do better than ignoring SSD controllers and/or storage hardware altogether? Reference [0] is from 2013, so probably much has happened since then, and the paper mentions (which has probably not gotten better), the following, referring to trade secrets giving one manufacturer ability to produce longer-lasting SSDs cheaper and better than others ... --8<---cut here---start->8--- This means that the SSD controller is dedicated to a single brand of NAND, and it means that the SSD maker can’t shop around among NAND suppliers for the best price. Furthermore, the NAND supplier won’t share this information unless it believes that there is some compelling reason to work the SSD manufacturer. Since there are hundreds of SSD makers it’s really difficult to get these companies to pay attention to you! The SSD manufacturers that have this kind of relationship with their flash suppliers are very rare and very special. --8<---cut here---end--->8--- Well, maybe you will have to parameterize your file system tuning with manufacturer ID and SSD controller firmware version ;/ Mvh, Bengt [0] https://www.snia.org/sites/default/files/SSSITECHNOTES_HowControllersMaximizeSSDLife.pdf On +2021-12-21 18:26:03 +0100, Ricardo Wurmus wrote: > Today we discovered a few more things and discussed them on IRC. Here’s > a summary. > > /var/cache sits on the same storage as /gnu. We mounted the 5TB ext4 > file system that’s hosted by the SAN at /mnt_test and started copying > over /var/cache to /mnt_test/var/cache. Transfer speed was considerably > faster (not *great*, but reasonably fast) than the copy of > /gnu/store/trash to the same target. > > This confirmed our suspicions that the problem is not with the storage > array but due to the fact that /gnu/store/trash (and also /gnu/store) > is an extremely large, flat directory. /var/cache is not. > > Here’s what we do now: continue copying /var/cache to the SAN, then > remount to serve substitutes from there. This removes some pressure > from the file system as it will only be used for /gnu. We’re > considering to dump the file system completely (i.e. reinstall the > server), thereby emptying /gnu, but leaving the stash of built > substitutes in /var/cache (hosted from the faster SAN). > > We could take this opportunity to reformat /gnu with btrfs, which > performs quite a bit more poorly than ext4 but would be immune to > defragmentation. It’s not clear that defragmentation matters here. It > could just be that the problem is exclusively caused by having these > incredibly large, flat /gnu/store, /gnu/store/.links, and > /gnu/store/trash directories. > > A possible alternative for this file system might also be XFS, which > performs well when presented with unreasonably large directories. > > It may be a good idea to come up with realistic test scenarios that we > could test with each of these three file systems at scale. > > Any ideas? > > -- > Ricardo > > > (sorry, the top-post grew) -- Regards, Bengt Richter
bug#51787: Disk performance on ci.guix.gnu.org
On +2021-12-20 17:59:33 +0100, Mathieu Othacehe wrote: > > Hey, > > > This is still pretty bad, but better than the <1M performance suggested > > by previous runs. > > Mmh interesting, I also have a x10 speed up on sdb by increasing the > block size from 4k to 512k. I'm not sure what conclusion should we draw > from this observation. > > In particular for our most urging matter, /gnu/store/trash > removal. Moving to a faster hard drive would definitely help here, but I > still don't understand if that disk performance regression comes from > Linux, the file-system fragmentation, or the disk itself. > > >READ: bw=1547MiB/s (1622MB/s), 1547MiB/s-1547MiB/s (1622MB/s-1622MB/s), > > io=3055MiB (3203MB), run=1975-1975msec > > WRITE: bw=527MiB/s (553MB/s), 527MiB/s-527MiB/s (553MB/s-553MB/s), > > io=1042MiB (1092MB), run=1975-1975msec > > Wooh that's fast! On test could be to copy the /gnu/store/trash content > to the SAN an observe how long that it takes for this operating to > complete. also might be interesting to copy to /dev/null to see read rate alone on /gnu/store? > > Thanks for your support on that complex topic :) > > Mathieu > > > -- Regards, Bengt Richter
bug#51183: lagrange: fribidi and harfbuzz dependencies?
On +2021-10-14 08:55:49 +0200, Liliana Marie Prikler wrote:
> Hi,
>
> Am Mittwoch, den 13.10.2021, 15:40 -0800 schrieb Christopher Howard:
> > Hello, the following did NOT work:
> >
> > ```
> > (use-modules (guix packages))
> > (use-modules (gnu packages web-browsers))
> > (use-modules (gnu packages gtk))
> > (use-modules (gnu packages fribidi))
> >
> > (packages->manifest
> > (list
> > (package
> >(inherit lagrange)
> >(inputs
> > `(("harfbuzz" ,harfbuzz)
> > ("fribidi" , fribidi)
> > ,@(package-inputs lagrange))
> > ```
> >
> > The package does build, but the problem remains with the script being
> > displayed in the wrong direction.
> >
> > I'm am greatly curious if there are more configure time options that
> > need to be set in relation to this. This paragraph indicates there
> > are related configure options:
> >
> > https://github.com/skyjake/lagrange#unicode-text-rendering
> By default, Lagrange should have ENABLE_FRIBIDI and ENABLE_HARFBUZZ be
> ON, whereas ENABLE_FRIBIDI_BUILD and ENABLE_HARFBUZZ_MINIMAL are set
> OFF, just as the script states. It would seem to be a bug elsewhere
> then.
>
> Try to check the build log to see whether or not harfbuzz and fribidi
> respectively get correctly detected by CMake. It ought to use pkg-
> config to do so, but I don't trust CMake on a fundamental level. If it
> does, there might be a problem with how Lagrange uses them?
>
>
>
>
Is something possibly dependent on GNU extended functionality,
that putting
#define _GNU_SOURCE 1
in a header file could enable?
Also, if there are local files in the same directory as the Makefile,
could -I. in the right rule be needed to trigger compiles?
... a couple things that caused me hiccups before, maybe too obvious for
others.
--
Regards,
Bengt Richter
bug#50981: Typo in ‘Invoking ‘guix home’’ documentation
On +2021-10-02 22:15:23 +0200, Maxime Devos wrote: > Hi guix, > > ‘there are few auxuliary actions’ > should be > ‘there are few auxilliary actions’ > should have one 'l' I think :) > in ‘11.4 Invoking ‘guix home’’. > > Greetings, > Maxime -- Regards, Bengt Richter
bug#50346: core-updates-frozen: strace 5.13 fails "make check" on AArch64
On +2021-09-03 10:00:33 -0400, Simon South wrote: > Bengt Richter writes: > > A proper configurability, ISTM, would be preferable to any other form > > of more general filtering. > > I agree with you on the need to be cautious around modifying test cases > but I'm not sure I follow you otherwise. What would "proper > configurability" look like in this case? > > The change I'm proposing here narrows the two test cases so they test > only what appears to have been intended, i.e. that strace can capture > readlink(at) system calls and that it reports them in the format > expected by the developers. It does not affect other test cases or the > test suite as a whole. > > The obvious alternative would be to modify the test cases' expected > output to match what is actually generated, but this could have the side > effect of tying the package to Linux and perhaps to specific versions of > glibc. Well, that would be the point :) I.e., to move the customizations into .conf files and out of test-suite sources. > > That said I'm still not sure why this additional syscall is being made > in the first place, only that it appears to originate from glibc's > "_dl_get_origin" function[0]. If I build strace from source "manually" > the tests complete fine without modification. I presume the extra call > has to do with the fact Guix builds strace inside a container; does > anyone know how this could be affecting the way programs are loaded? > I did not realize there were mods to strace itself affecting this. I thought it was about somehow filtering its output to fool tests, sorry. With strace variants maybe "proper configurability" should have to consider strace versions also, to tune test expectations ;/ > -- > Simon South > si...@simonsouth.net > > [0] See e.g. glibc's sysdeps/unix/sysv/linux/dl-origin.c for the x86-64 > case, as well as "_dl_non_dynamic_init" in elf/dl-support.c, which > seems to be the only place it is called. -- Regards, Bengt Richter
bug#50346: core-updates-frozen: strace 5.13 fails "make check" on AArch64
Hi,
On +2021-09-02 18:41:12 -0400, Simon South wrote:
> Patching strace to add a "--trace-path" parameter to the two tests'
> definitions as in the patch below seems to fix this issue on both
> AArch64 and x86-64, and is less drastic than disabling the tests
> altogether.
>
> The changes limit strace's output during testing to only calls affecting
> files in the test directory itself, effectively filtering out the
> 'readlink("/proc/self/exe")' call from glibc that is throwing the tests
> currently. You can see a number of other places in gen_tests.in where
> this is done, presumably for similar reasons.
>
> Does this seem reasonable?
>
I worry about disabling tests in too general a way, since it creates
a hiding place which conceivably someone really clever may be able exploit.
So I wonder whether what you are doing is making it possible to
configure tests to have (narrow) context-sensitive expectations
(e.g., in this case making the test handle the error as an expected one,
as opposed to being made ignorant of it), or building in a static and
probably too general configuration.
A proper configurability, ISTM, would be preferable to any other form
of more general filtering.
Sorry if this is just noise from a lurker with insufficient knowledge
of the issue and discussions. If so please ignore ;/
of13> definitions as in the patch below seems to fix this issue on both
> --
> Simon South
> si...@simonsouth.net
>
>
> diff --git a/tests/gen_tests.in b/tests/gen_tests.in
> index 8b4e2e9..cc3ca63 100644
> --- a/tests/gen_tests.in
> +++ b/tests/gen_tests.in
> @@ -623,8 +623,8 @@ quotactl-xfs-v-v -e trace=quotactl
> read-write -a15 -eread=0,5 -ewrite=1,4 -e trace=read,write -P
> read-write-tmpfile -P /dev/zero -P /dev/null
> readahead-a1
> readdir -a16
> -readlink -xx
> -readlinkat -xx
> +readlink -xx --trace-path=test.readlink.link
> +readlinkat -xx --trace-path=test.readlinkat.link
> reboot -s 256
> recv-MSG_TRUNC -a26 -e trace=recv
> recvfrom -a35
>
>
>
--
Regards,
Bengt Richter
bug#49985: bash-mesboot0: Inscrutable error in build phase
Just this disclaimer:
I am just a lurker interested in mes, not a mes developer or team member.
(I am trying to do some minimal stuff too, so I cloned the mes repo and pull
once
in a while to see what's going on :)
Sorry for any implication that I really know anything about mes ;/
On +2021-08-11 03:21:18 +0200, Bengt Richter wrote:
> On +2021-08-11 02:38:54 +0200, Bengt Richter wrote:
> > On +2021-08-10 15:41:25 -0400, Carl Dong wrote:
> > > Hi all,
> > >
> > > While setting up Guix for a community member of mine, we encountered this
> > > somewhat inscrutable problem (I later learned this is not the first time
> > > Guix users have run into this problem!). When building
> > > /gnu/store/2nvaxgs0rdxfkrwklh622ggaxg0wap6n-bash-mesboot0-2.05b.drv, we
> > > encountered the following build failure:
> > > https://paste.sr.ht/~dongcarl/376b19b8349c329ed5329508c7fb43a7c3aec64b#2nvaxgs0rdxfkrwklh622ggaxg0wap6n-bash-mesboot0-2.05b.log-L1299
> > >
> > > The error line is L1299: "make: stat:Makefile: sterror: unknown error”
> > >--
> >
> > To me, sterror looks like a typo for strerror
> > so grepping for sterror might find the typo, if that's what it is?
> >
> Looking at ./lib/mes/__mes_debug.c, it looks like you could set/export
> environment
> MES_DEBUG=1 and run it again to see the error number ./lib/string/strerror.c
> (in git repo) doesn't like.
>
> Then run something like my error-printing kludge that will work on your
> system:
>
> I called it errno-grep
> --8<---cut here---start->8---
> #!/usr/bin/bash
> if [ -z "$1" ];then
> echo "Usage: errno-grep [ grep switches for grepping the following files
> in order ]"
> echo "/usr/include/asm-generic/errno-base.h"
> echo "/usr/include/asm-generic/errno.h"
> exit 0
> fi
>
> if [ "${1:0:1}" == "-" ]; then
> exec grep "$@" /usr/include/asm-generic/errno-base.h
> /usr/include/asm-generic/errno.h
> else
> exec egrep -wh "$@" /usr/include/asm-generic/errno-base.h
> /usr/include/asm-generic/errno.h
> fi
> --8<---cut here---end--->8---
>
> HTH.
>
>
>
--
Regards,
Bengt Richter
bug#49985: bash-mesboot0: Inscrutable error in build phase
On +2021-08-11 02:38:54 +0200, Bengt Richter wrote:
> On +2021-08-10 15:41:25 -0400, Carl Dong wrote:
> > Hi all,
> >
> > While setting up Guix for a community member of mine, we encountered this
> > somewhat inscrutable problem (I later learned this is not the first time
> > Guix users have run into this problem!). When building
> > /gnu/store/2nvaxgs0rdxfkrwklh622ggaxg0wap6n-bash-mesboot0-2.05b.drv, we
> > encountered the following build failure:
> > https://paste.sr.ht/~dongcarl/376b19b8349c329ed5329508c7fb43a7c3aec64b#2nvaxgs0rdxfkrwklh622ggaxg0wap6n-bash-mesboot0-2.05b.log-L1299
> >
> > The error line is L1299: "make: stat:Makefile: sterror: unknown error”
> >--
>
> To me, sterror looks like a typo for strerror
> so grepping for sterror might find the typo, if that's what it is?
>
Looking at ./lib/mes/__mes_debug.c, it looks like you could set/export
environment
MES_DEBUG=1 and run it again to see the error number ./lib/string/strerror.c
(in git repo) doesn't like.
Then run something like my error-printing kludge that will work on your system:
I called it errno-grep
--8<---cut here---start->8---
#!/usr/bin/bash
if [ -z "$1" ];then
echo "Usage: errno-grep [ grep switches for grepping the following files in
order ]"
echo "/usr/include/asm-generic/errno-base.h"
echo "/usr/include/asm-generic/errno.h"
exit 0
fi
if [ "${1:0:1}" == "-" ]; then
exec grep "$@" /usr/include/asm-generic/errno-base.h
/usr/include/asm-generic/errno.h
else
exec egrep -wh "$@" /usr/include/asm-generic/errno-base.h
/usr/include/asm-generic/errno.h
fi
--8<---cut here---end--->8---
HTH.
bug#49985: bash-mesboot0: Inscrutable error in build phase
On +2021-08-10 15:41:25 -0400, Carl Dong wrote: > Hi all, > > While setting up Guix for a community member of mine, we encountered this > somewhat inscrutable problem (I later learned this is not the first time Guix > users have run into this problem!). When building > /gnu/store/2nvaxgs0rdxfkrwklh622ggaxg0wap6n-bash-mesboot0-2.05b.drv, we > encountered the following build failure: > https://paste.sr.ht/~dongcarl/376b19b8349c329ed5329508c7fb43a7c3aec64b#2nvaxgs0rdxfkrwklh622ggaxg0wap6n-bash-mesboot0-2.05b.log-L1299 > > The error line is L1299: "make: stat:Makefile: sterror: unknown error” >-- To me, sterror looks like a typo for strerror so grepping for sterror might find the typo, if that's what it is? Regards, Bengt Richter
bug#48419: Unexpected problem during install of Guix System 1.3.0
Hi, On +2021-05-14 16:50:48 +0200, Matthias Cullmann wrote: > Hi there, > > I am trying to install Guix System 1.3.0 on an Asus ZenBook UX305 using the > wizard. > > After the partitioning I get the error in the attached screen shot. > > ( mount "/dev/sda1" on "mnt/boot/ef" : No such device) > > I had Linux installed already on this computer and would not need to > re-partition. > > Any ideas how to fix this? > > Thx & regards, > > Matthias > what does this output? --8<---cut here---start->8--- $ ls /dev/disk/by-id/*|xargs file --8<---cut here---end--->8--- Maybe you have nve disk that does not get translated to /dev/sdaX ? If you have linux running, try --8<---cut here---start->8--- $ lsblk -f --8<---cut here---end--->8--- Maybe you will see something like nvme0n1 ├─nvme0n1p1 ... └─nvme0n1p2 ... which would suggest that your /dev/sda1 maybe should be /dev/nvme0n1p1 but in general, IMO device references without unique id's are bloody feet waiting to happen. I would suggest looking at uuid's for file systems, partitions, or devices, such as you can view with lsblk -- Regards, Bengt Richter
bug#48024: glib-2.62.6 build fails i686
Hi Mark, tl;dr -- would you by chance have a mhw-bootstrap.sh that could clone your set-up of a private git repo to use the way you often mention doing? I am interested in doing it your way ;) IIRC, Pjotr wrote extensive notes on how to build starting with a git clone, but ended up advising against doing it unless there was no other way. Any tips appreciated :) TIA. On +2021-05-07 13:46:07 -0400, Mark H Weaver wrote: > Hi, > > Bone Baboon writes: > > How can I use the glib I have built in a system configuration while this > > fix or a variation of it makes it's way into the Guix master branch? > > I guess that you'll need to set up a personal branch of Guix, like I do, > with a patch applied to the 'glib' package, and another patch applied to > 'inetutils' (referring to <https://bugs.gnu.org/48214#35>). > > My recommendation, for now, would be to do this: > > (1) Set up your own git repository, with a personal branch that's the > same as our official 'master' branch plus the additional patches > that you need, and to periodically rebase this branch on top of our > 'master' branch. > > (2) On all of your systems that need these customizations, pass the > "--url=URL" and "--branch=BRANCH" options to "guix pull", each time > you use that command. > > There _might_ be a nicer way to set this up using channels, but I've > never used channels and am mostly ignorant of them. Maybe someone else > can chime in on that point. > > Regards, > Mark > > -- > Disinformation flourishes because many people care deeply about injustice > but very few check the facts. Ask me about <https://stallmansupport.org>. > > > -- Regards, Bengt Richter
bug#48024: glib-2.62.6 build fails i686
Hi, On +2021-05-06 09:45:00 +0300, Efraim Flashner wrote: > On Wed, May 05, 2021 at 05:15:14PM -0400, Bone Baboon wrote: > > Efraim Flashner writes: > > > I looked closer at the bug report and I see they are timing out at 60 > > > and 180 for Bone Baboon as they currently are. > > > > > > Bone Baboon: Can you build the attached test-glib.scm file and send back > > > the build log? I want to make sure I change the timeout to something > > > long enough. > > > > > > You can build it with 'guix build -f test-glib.scm' > > > > I ran `guix build --file=test-glib.scm` and I was successful. > > That was the plan. I bumped the test timeouts to high enough numbers so > that I could see how long it took. > > > I was having trouble finding the build log. > > > > I have instead attached the output of the build command. > > It's perfect. > > It looks like the two slowest are > 83/259 glib:glib / 1bit-mutex OK 85.13 s > 84/259 glib:glib+slow / 1bit-emufutex OK 89.22 s > > I was thinking of just tripling the duration but test_timeout_slow would > likely have been missed since it was moved from 120 to 180, and > extracting the number so I could multiply it by 3 isn't really the most > readable and could leave the timeout near the edge. I've gone ahead and > multiplied it by 10, if a test would hang forever it's still killed and if > there's high load on a slow machine it should still pass. > Couldn't autoconf emit some config info that test scripts could use to run with appropriate timeouts and memory sizes etc? Maybe with access similar to pkg-config? Seems like someone must have thought of scratching that itch? > > > -- > Efraim Flashner אפרים פלשנר > GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 > Confidentiality cannot be guaranteed on emails sent or received unencrypted -- Regards, Bengt Richter
bug#48114: Disarchive occasionally fails tests
Hi Timothy, Ludo,
On +2021-05-03 00:02:09 -0400, Timothy Sample wrote:
> Timothy Sample writes:
>
> > I’m still looking into this, but I wanted to quickly post this
> > reproducer for the Guile bug:
> >
> > (use-modules (ice-9 regex))
> > (define str
> > "\U101514\U103ab0\U0f6e6e\U02e278\U01d9eb\U10b996\U1089b5\uea15\U0fa074\U101e41\U02e330\u0177\u2492")
> > (match:substring (string-match "[0-8]+" str))
> >
> > This triggers the out-of-range error when run with “LC_ALL=C”.
>
> It turns out that all that’s needed is the last code point, which is
> “Number Eleven Full Stop”, or ‘⒒’. When Guile converts this to an ASCII
> C string using ‘u32_conv_from_encoding’, it becomes “11.”. The regex
> (“[0-8]+”) matches the “11” part with start index 0 and end index 2.
> The ‘fixup_multibyte_match’ function does nothing (it only matters when
> the locale encoding is multibyte) [1]. Guile then builds the match
> vector with the original string but keeps the ASCII offsets. In other
> words, it thinks the match substring goes from 0 to 2 in a single code
> point string:
>
> ,use (ice-9 regex)
> (string-match "11" "\u2492")
> => #("\u2492" (0 . 2))
>
> I’m not sure there’s any way to solve this nicely in Guile. It would be
> clearer if the match vector included the string as libc matched it, but
> it’s still surprising that the match happens with a different string.
>
> In Disarchive, I can rewrite the generator without regex. I’ll do that
> and see what I can do about the “Gave up!” issue.
>
> [1] It works on the converted-to-ASCII C string, which means that the
> byte offsets and code point offsets are the same. Hence, it has nothing
> to do.
>
>
> -- Tim
>
>
>
What happens with these?
(code ppoints in decimal)
8554 _Ⅺ_ "ROMAN NUMERAL ELEVEN"
8570 _ⅺ_ "SMALL ROMAN NUMERAL ELEVEN"
9322 _⑪_ "CIRCLED NUMBER ELEVEN"
9342 _⑾_ "PARENTHESIZED NUMBER ELEVEN"
9362 _⒒_ "NUMBER ELEVEN FULL STOP"
9451 _⓫_ "NEGATIVE CIRCLED NUMBER ELEVEN"
13155 _㍣_ "IDEOGRAPHIC TELEGRAPH SYMBOL FOR HOUR ELEVEN"
13290 _㏪_ "IDEOGRAPHIC TELEGRAPH SYMBOL FOR DAY ELEVEN"
I would argue that none of these should be "decoded" into ascii polyglyphs
since they are atomic character glyphs. IMO It is over-eager transformation
to make them into ascii polyglyphs.
/Super/sub/-script placement metadata is another thing to consider --
"decode" to ascii art?? ;-)
Unicode characters representing mathematical values in
other languages are different. Those are subject to natural language
translation with locale-dependent semantics.
These might be candidates for that?:
(code points in decimal)
8544 _Ⅰ_ "ROMAN NUMERAL ONE"
8545 _Ⅱ_ "ROMAN NUMERAL TWO"
8546 _Ⅲ_ "ROMAN NUMERAL THREE"
8547 _Ⅳ_ "ROMAN NUMERAL FOUR"
8548 _Ⅴ_ "ROMAN NUMERAL FIVE"
8549 _Ⅵ_ "ROMAN NUMERAL SIX"
8550 _Ⅶ_ "ROMAN NUMERAL SEVEN"
8551 _Ⅷ_ "ROMAN NUMERAL EIGHT"
8552 _Ⅸ_ "ROMAN NUMERAL NINE"
8553 _Ⅹ_ "ROMAN NUMERAL TEN"
8554 _Ⅺ_ "ROMAN NUMERAL ELEVEN"
8555 _Ⅻ_ "ROMAN NUMERAL TWELVE"
8556 _Ⅼ_ "ROMAN NUMERAL FIFTY"
8557 _Ⅽ_ "ROMAN NUMERAL ONE HUNDRED"
8558 _Ⅾ_ "ROMAN NUMERAL FIVE HUNDRED"
8559 _Ⅿ_ "ROMAN NUMERAL ONE THOUSAND"
8560 _ⅰ_ "SMALL ROMAN NUMERAL ONE"
8561 _ⅱ_ "SMALL ROMAN NUMERAL TWO"
8562 _ⅲ_ "SMALL ROMAN NUMERAL THREE"
8563 _ⅳ_ "SMALL ROMAN NUMERAL FOUR"
8564 _ⅴ_ "SMALL ROMAN NUMERAL FIVE"
8565 _ⅵ_ "SMALL ROMAN NUMERAL SIX"
8566 _ⅶ_ "SMALL ROMAN NUMERAL SEVEN"
8567 _ⅷ_ "SMALL ROMAN NUMERAL EIGHT"
8568 _ⅸ_ "SMALL ROMAN NUMERAL NINE"
8569 _ⅹ_ "SMALL ROMAN NUMERAL TEN"
8570 _ⅺ_ "SMALL ROMAN NUMERAL ELEVEN"
8571 _ⅻ_ "SMALL ROMAN NUMERAL TWELVE"
8572 _ⅼ_ "SMALL ROMAN NUMERAL FIFTY"
8573 _ⅽ_ "SMALL ROMAN NUMERAL ONE HUNDRED"
8574 _ⅾ_ "SMALL ROMAN NUMERAL FIVE HUNDRED"
8575 _ⅿ_ "SMALL ROMAN NUMERAL ONE THOUSAND"
8576 _ↀ_ "ROMAN NUMERAL ONE THOUSAND C D"
8577 _ↁ_ "ROMAN NUMERAL FIVE THOUSAND"
8578 _ↂ_ "ROMAN NUMERAL TEN THOUSAND"
8579 _Ↄ_ "ROMAN NUMERAL REVERSED ONE HUNDRED"
8581 _ↅ_ "ROMAN NUMERAL SIX LATE FORM"
8582 _ↆ_ "ROMAN NUMERAL FIFTY EARLY FORM"
8583 _ↇ_ "ROMAN NUMERAL FIFTY THOUSAND"
8584 _ↈ_ "ROMAN NUMERAL ONE HUNDRED THOUSAND"
12321 _〡_ "HANGZHOU NUMERAL ONE"
12322 _〢_ "HANGZHOU NUMERAL TWO"
12323 _〣_ "HANGZHOU NUMERAL THREE"
12324 _〤_ "HANGZHOU NUMERAL FOUR"
12325 _〥_ "HANGZHOU NUMERAL FIVE"
12326 _〦_ "HANGZHOU NUMERAL SIX"
12327 _〧_ "HANGZHOU NUMERAL SEVEN"
12328 _〨_ "HANGZHOU NUMERAL EIGHT"
12329 _〩_ "HANGZHOU NUMERAL NINE"
12344 _〸_ "HANGZHOU NUMERAL TEN"
12345 _〹_ "HANGZHOU NUMERAL TWENTY"
12346 _〺_ "HANGZHOU NUMERAL THIRTY"
Just my intuitive reaction, no academic creds to back it up ;)
--
Regards,
Bengt Richter
bug#39341: Installer using 100% of a CPU core
t_size=0,
> ...}) = 0
> 259 openat(AT_FDCWD, "/tmp/kmscon-231-keymap-update",
> O_WRONLY|O_CREAT|O_TRUNC, 0666) = 19
> 259 lstat("/tmp/kmscon-231-keymap-update", {st_mode=S_IFIFO|0700,
> st_size=0, ...}) = 0
> 231 unlink("/tmp/kmscon-231-keymap-update") = 0
> 231 mknod("/tmp/kmscon-231-keymap-update", S_IFIFO|0700) = 0
> 231 openat(AT_FDCWD, "/tmp/kmscon-231-keymap-update", O_RDONLY|O_NONBLOCK)
> = 26
> 231 unlink("/tmp/kmscon-231-keymap-update") = 0
> 231 mknod("/tmp/kmscon-231-keymap-update", S_IFIFO|0700) = 0
> 231 openat(AT_FDCWD, "/tmp/kmscon-231-keymap-update", O_RDONLY|O_NONBLOCK)
> = 18
> 231 unlink("/tmp/kmscon-231-keymap-update") = 0
> 231 mknod("/tmp/kmscon-231-keymap-update", S_IFIFO|0700) = 0
> 231 openat(AT_FDCWD, "/tmp/kmscon-231-keymap-update", O_RDONLY|O_NONBLOCK)
> = 21
> 231 unlink("/tmp/kmscon-231-keymap-update") = 0
> 231 mknod("/tmp/kmscon-231-keymap-update", S_IFIFO|0700) = 0
> 231 openat(AT_FDCWD, "/tmp/kmscon-231-keymap-update", O_RDONLY|O_NONBLOCK)
> = 24
> 259 stat("/tmp/kmscon-231-keymap-update", {st_mode=S_IFIFO|0700, st_size=0,
> ...}) = 0
> 259 openat(AT_FDCWD, "/tmp/kmscon-231-keymap-update",
> O_WRONLY|O_CREAT|O_TRUNC, 0666) = 19
> 259 lstat("/tmp/kmscon-231-keymap-update", {st_mode=S_IFIFO|0700,
> st_size=0, ...}) = 0
> 231 unlink("/tmp/kmscon-231-keymap-update") = 0
> 231 mknod("/tmp/kmscon-231-keymap-update", S_IFIFO|0700) = 0
> 231 openat(AT_FDCWD, "/tmp/kmscon-231-keymap-update", O_RDONLY|O_NONBLOCK)
> = 24
>
> It has still not gone back to English layout (except when I press
> Alt+Shift).
>
> Regards,
> Florian
>
>
>
Perhaps this old bug in some form?
https://bugzilla.gnome.org/show_bug.cgi?id=776570
and solution linked from there might help?
http://unix.stackexchange.com/questions/68
--
Regards,
Bengt Richter
bug#47889: [installer image] grub-install efi fails getting canonical path to /boot/efi on dos-formatted disk
Hi Ludo, Florian, On +2021-04-23 12:39:13 +0200, Ludovic Courtès wrote: > Hi Florian, > > (Cc: Mathieu.) > > "pelzflorian (Florian Pelz)" skribis: > > > On Thu, Apr 22, 2021 at 03:28:39PM +0200, Ludovic Courtès wrote: > >> There’s no EFI (vfat) partition here. Is it an EFI machine? > >> > >> Is /boot/efi mounted when you boot the installation image? > > > > No because there is no EFI partition. If I create one and restart the > > installer, then it is *not* mounted either, only /mnt/boot/efi later > > during the install. (I believe since the installer is installed as on > > an external medium, it does not need an EFI partition.) > > > > I had booted the install image via UEFI boot and had expected auto > > partitioning and the default configuration to do the right thing. > > The installer determines whether it’s doing a UEFI installation like so: > > (define (efi-installation?) > "Return #t if an EFI installation should be performed, #f otherwise." > (file-exists? "/sys/firmware/efi")) > > It uses that to determine whether to create an EFI System Partition > (ESP) and whether to use ‘grub-efi-bootloader’. > How does that work if you want to mount an external USB disk as the target of your installation partitioning and formatting etc, but which may be intended for another laptop with a different BIOS booting in a different mode than your installer was booted into? (Maybe plug the finished USB disk into another laptop? USB C3.1 is fast enough if connected to a good SSD cassette). I.e., suppose your installer machine was booted UEFI but you want the target disk to be legacy MBR booted on a laptop that can only do that, loading grub2 as embedded in the target disk? Or vice versa? I'd like an interactive install, maybe selecting a target disk something like --8<---cut here---start->8--- $ select choice in $(lsblk -o kname,model,serial|tr -s ' ' _); do break;done 1) KNAME_MODEL_SERIAL 6) dm-0_ 2) sdb_Ultra_Fit_ 7) nvme0n1_Samsung_SSD_970_EVO_Plus_500GB_XXX 3) sdb1_ 8) nvme0n1p1_ 4) sdb2_ 9) nvme0n1p2_ 5) sr0_USB_SCSI_CD-ROM_ #? 2 $ echo "$choice" sdb_Ultra_Fit_ --8<---cut here---end--->8--- so then the installation script can continue and mount the associated disk device --8<---cut here---start->8--- $ echo "$choice"|cut -d _ -f1 sdb --8<---cut here---end--->8--- It seems like the /sys/... file system that would show whether the disk is EFI-bootable will be determined by booting the very disk image we are trying to create -- both by its content (MBR and/or GPT, and what bootloader + .cfg, etc) and the BIOS trying to boot it. Sorry for the noise if I am missing some context. > Did it create an ESP in your case? > > I’m not entirely sure how it decides between GPT and DOS, though; > Mathieu? > > We should add UEFI installation tests using OVMF. > > Thanks, > Ludo’. > > > -- Regards, Bengt Richter
bug#47496: Very slow `guix environment -l nyxt/build-scripts/guix.scm
Hi, On +2021-04-03 20:42:08 +0200, Pierre Neidhardt wrote: > I just tried the following: > > --8<---cut here---start->8--- > guix environment -l ... > --8<---cut here---end--->8--- > > was forever until I stopped it. > Then > > > --8<---cut here---start->8--- > guix environment --no-grafts -l ... > --8<---cut here---end--->8--- > > completed in a few seconds. > > After this, > > --8<---cut here---start->8--- > guix environment -l ... > --8<---cut here---end--->8--- > > again completed in just a few seconds too. > Could bash have cached a reference somwhere that made the difference? If you are running in bash, type hash to get a listing of things it has hash-table reference to see also help bash (unless your shell context is different, in which case, for convenience, the expected output is: --8<---cut here---start->8--- hash: hash [-lr] [-p pathname] [-dt] [name ...] Remember or display program locations. Determine and remember the full pathname of each command NAME. If no arguments are given, information about remembered commands is displayed. Options: -dforget the remembered location of each NAME -ldisplay in a format that may be reused as input -p pathname use PATHNAME as the full pathname of NAME -rforget all remembered locations -tprint the remembered location of each NAME, preceding each location with the corresponding NAME if multiple NAMEs are given Arguments: NAME Each NAME is searched for in $PATH and added to the list of remembered commands. Exit Status: Returns success unless NAME is not found or an invalid option is given. --8<---cut here---end--->8--- Usually this bites me by keeping on doing something old in spite of PATH changes, but if "something old" got established by your > --8<---cut here---start->8--- > guix environment --no-grafts -l ... > --8<---cut here---end--->8--- maybe it could have gotten hash-cached and remembered to make --8<---cut here---start->8--- > guix environment -l ... > --8<---cut here---end--->8--- > "work" ?? Anyway, apparently some state change is "remembered" in your sequence above, so I was reminded :) > -- > Pierre Neidhardt > https://ambrevar.xyz/ -- Regards, Bengt Richter
bug#47106: Bubblewrap hates Guix containers
Hi Leo,
One more favor? ;)
On +2021-03-14 19:05:24 +0100, Leo Prikler wrote:
> Hi again³
>
> Am Sonntag, den 14.03.2021, 18:45 +0100 schrieb Bengt Richter:
> > Hi again^2,
> >
> > Maybe
> > pstree -at
> > would show a little more?
> sh
> |-dbus-daemon --syslog-only --fork --print-pid 5 --print-address 7
> --sess
> |-dbus-launch --autolaunch=fa7a4d52637958ddd37547bb5d8bd9d2--binary-
> synt
> `-screen
> `-screen
> |-sh
> | `-.epiphany-real
> | |-WebKitNetworkPr 3 21
> | | |-{BMScavenger}
> | | |-{ReceiveQueue}
> | | |-{StorageTask}
> | | |-{Storage}
> | | |-{WebStorage}
> | | |-{background}
> | | |-{dconf worker}
> | | |-{erialBackground}
> | | |-{gdbus}
> | | `-{gmain}
> | |-bwrap --args 37 --
> /gnu/store/hqhxgw0i8xh38h6kwmyrkywcd24q5f1z-webk
> | | `-bwrap --args 37 --
> /gnu/store/hqhxgw0i8xh38h6kwmyrkywcd24q5f1z-webk
> | | `-WebKitWebProces 1277 28
> | |-{.epiphany-real}
> | |-{BMScavenger}
> | |-{HashSaltStorage}
> | |-{IconDatabase}
> | |-{PressureMonitor}
> | |-2*[{ReceiveQueue}]
> | |-{dconf worker}
> | |-{e Compile Queue}
> | |-{ebsiteDataStore}
> | |-{gdbus}
> | |-{gmain}
> | |-{re Remove Queue}
> | `-{tore Read Queue}
> `-sh
> `-pstree -at
> > Also,
> > ls -lr /sys/class/drm
> total 0
> -r--r--r-- 1 65534 overflow 4096 Mar 14 17:59 version
> lrwxrwxrwx 1 65534 overflow0 Mar 14 17:58 ttm ->
> ../../devices/virtual/drm/ttm
> lrwxrwxrwx 1 65534 overflow0 Mar 14 17:59 renderD128 ->
> ../../devices/pci:00/:00:02.0/:01:00.0/drm/renderD128
> lrwxrwxrwx 1 65534 overflow0 Mar 14 17:59 card0-VGA-1 ->
> ../../devices/pci:00/:00:02.0/:01:00.0/drm/card0/card0-VGA-
> 1
> lrwxrwxrwx 1 65534 overflow0 Mar 14 17:59 card0-HDMI-A-1 ->
> ../../devices/pci:00/:00:02.0/:01:00.0/drm/card0/card0-
> HDMI-A-1
> lrwxrwxrwx 1 65534 overflow0 Mar 14 17:58 card0-DVI-D-1 ->
> ../../devices/pci:00/:00:02.0/:01:00.0/drm/card0/card0-DVI-
> D-1
> lrwxrwxrwx 1 65534 overflow0 Mar 14 17:58 card0 ->
> ../../devices/pci:00/:00:02.0/:01:00.0/drm/card0
> > if that's accessible -- I'm wondering if the version of screen
> > in the container is built with libdrm and is bypassing X or ??
> I doubt it is being built differently than screen normally is.
>
> > Do you have a makefile or a guix something.scm defining
> > what's built/packed into your container?
> Nah, it's a rather ad-hoc definition grown from what should be an Eolie
> container from the cookbook (also refer to #47097).
>
> guix environment --preserve='^DISPLAY$' --preserve=XAUTHORITY \
> --preserve=TERM \
> --expose=$XAUTHORITY \
> --expose=/etc/machine-id \
> --expose=/etc/ssl/certs/ \
> --expose=/sys/block --expose=/sys/class --expose=/sys/bus \
> --expose=/sys/dev --expose=/sys/devices \
> --ad-hoc epiphany nss-certs dbus procps coreutils psmisc screen
>
> Given that I expose most of /sys explicitly, you should take the above
> with a grain of salt.
>
> > Sorry if my curiosity is making work for you, but I'd like to
> > try containers down the road -- tho right now I'm taking a break
> > from events IRL, so I may disappear for a while...
> I'm not personally impacted by this bug or anything, it's much rather a
> follow-up to my attempted fix of #47097. I think there might be some
> flaw in trying to run a sandbox inside a sandbox (like bubblewrap
> inside `guix container`), that doesn't actually improve security in any
> meaningful way.
>
> Regards,
> Leo
>
If you can run this inside your container, I think it will be interesting:
lsof -U|grep -i wayland
The above ought to show quickly if wayland is running.
lsof -U shows the open sockets.
If the above shows nothing, try
lsof -U|grep -i x11
or
lsof -U|grep X
finally, it is interesting to see
lsof -U|less
but on my laptop I just got
lsof -U|wc
4033760 34643
so its a lot to look at.
Hopefully less in a container ;)
--
Regards,
Bengt Richter
bug#47106: Bubblewrap hates Guix containers
Hi again^2,
On +2021-03-13 19:01:29 +0100, Leo Prikler wrote:
> Am Samstag, den 13.03.2021, 18:07 +0100 schrieb Bengt Richter:
> > I am not a Wayland developer, if that's what you mean by "Wayland
> > folk" :)
> I meant it as "folk using Wayland in their display manager".
>
> > I am curious what the commands below would show inside your
> > container.
> > "pidparents" [1] is a little script I find handy, which would have to
> > be
> > accessible in your container of course. Idk how you put local bash
> > scripts
> > in your container. I assume it's possible :)
> Far from getting a script into my container, I can't even really get
> into my container through means like `guix container exec`, so I simply
> bloated it with screen and pstree. The result:
>
> --8<---cut here---start->8---
> sh-+-dbus-daemon
>|-dbus-launch
>`-screen---screen-+-sh---.epiphany-real-+-WebKitNetworkPr---
> 11*[{WebKitNetworkPr}]
> | |-bwrap---bwrap---
> WebKitWebProces
> | `-18*[{.epiphany-real}]
> `-sh---pstree
> --8<---cut here---end--->8---
>
> I think these processes are created and die too quickly for me to
> reliably extract PIDs.
>
> Regards,
> Leo
>
Maybe
pstree -at
would show a little more?
Also,
ls -lr /sys/class/drm
if that's accessible -- I'm wondering if the version of screen
in the container is built with libdrm and is bypassing X or ??
Do you have a makefile or a guix something.scm defining
what's built/packed into your container?
Sorry if my curiosity is making work for you, but I'd like to
try containers down the road -- tho right now I'm taking a break
from events IRL, so I may disappear for a while...
--
Regards,
Bengt Richter
bug#47106: Bubblewrap hates Guix containers
Hi again, On +2021-03-13 15:43:15 +0100, Leo Prikler wrote: > Am Samstag, den 13.03.2021, 13:27 +0100 schrieb Bengt Richter: > > Hi, > > > > On +2021-03-13 12:07:51 +0100, Leo Prikler wrote: > > > Hi! > > > Am Samstag, den 13.03.2021, 11:48 +0100 schrieb Ludovic Courtès: > > > > Hi! > > > > > > > > Leo Prikler skribis: > > > > > > > > > both Epiphany and Eolie (post fixing #47097; will submit patch > > > > > shortly) > > > > > fail inside Guix containers with the suggested > > > > > incantation. After > > > > > getting the environment to no longer complain about $DISPLAY by > > > > > adding > > > > > `--preserve="XAUTHORITY" --expose=$XAUTHORITY', it repeatedly > > > > > outputsn > > > > > lines like > > > > > bwrap: Can't find source path /sys/class: No such file or > > > > > directory > > > > > before closing the process altogether. > > > > > > > > What is ‘bwrap’ looking for? /sys is mounted inside ‘guix > > > > environment -C’, > > > > but perhaps it needs something special? > > > > > > > > I suggest running these things (or ‘bwrap’ directly) in ‘strace > > > > -f -o > > > > log’ inside the container to see. > > > It seems to be > > > > openat(AT_FDCWD, "/sys/class/dmi/id/chassis_type", O_RDONLY) = -1 > > > > ENOENT (No such file or directory) > > > > openat(AT_FDCWD, "/sys/firmware/acpi/pm_profile", O_RDONLY) = -1 > > > > ENOENT (No such file or directory) > > > > > > I haven't repeated that for all warnings of similar kind, but if I > > > add > > > `--expose=/sys/block --expose=/sys/class --expose=/sys/bus -- > > > expose=/sys/dev --expose=/sys/devices` to the invocation, I instead > > > get > > > a warning, that the WebKitWebProcess can't open $DISPLAY. I'm not > > > sure > > > how to resolve that one, given that I already had to sneak DISPLAY > > > and > > > XAUTHORITY into the container, but it's a start. > > > > > > Regards, > > > Leo > > > > > Does $DISPLAY mean ":0" and does the Wayland server answer that with > > its XWayland X-interface? > In my setup $DISPLAY=:1, but obviously the exact value depends on other > circumstances (i.e. if there's already an open session belonging to > another user it'd be :2, :3, ...). I'm not sure how X vs. Wayland > plays out here, but I'm still using Gnome on X, so that should > hopefully not be an issue here. > > > I am wonderering how that is resolved inside a container. > Well, for X you'd usually preserve DISPLAY and XAUTHORITY and also > expose $XAUTHORITY or something along those lines. Not sure how you > Wayland folk do that. > I am not a Wayland developer, if that's what you mean by "Wayland folk" :) But I have been experimenting with writing my own text and graphics widget, poking 32-bit pixels into buffers for display by the Wayland compositor, so I've learned a little :) I am using the linux kernel's sun12x22 bitmap font to do text at a low level. Idk much about containers yet, but I imagine using lowlevel stuff to make images for a trivial web server running in a container could be interesting. > Regards, > Leo > I am curious what the commands below would show inside your container. "pidparents" [1] is a little script I find handy, which would have to be accessible in your container of course. Idk how you put local bash scripts in your container. I assume it's possible :) I did these commands in a debian gnome terminal window, where pidparents[1] showed (timetagged later, since I just went back to do that) this context: --8<---cut here---start->8--- [17:29 ~/bs]$ pidparents pidparents pts/1 5800 S+ /usr/bin/bash /home/bokr/bin/pidparents bashpts/1 5711 Ss /bin/bash tilix ? 2007 Sl /usr/bin/tilix --gapplication-service systemd ? 1308 Ss /lib/systemd/systemd --user systemd ?1 Ss /sbin/init splash --8<---cut here---end--->8--- First I just look for processes with X11 or way in their names, then I use pidparents to see how they are started. [17:18 ~/bs]$ ps af|egrep -i 'x11|way' 5741 pts/1S+ 0:00 \_ grep -E -i x11|way 1329 tty2 Ssl+ 0:00 /usr/lib/gdm3/gdm-wayland-session /usr/bin/gnome-session 1433 tty2 Sl+0:13 | \_ /usr/bin/Xwayland :0 -rootless -term
bug#47106: Bubblewrap hates Guix containers
Hi, On +2021-03-13 12:07:51 +0100, Leo Prikler wrote: > Hi! > Am Samstag, den 13.03.2021, 11:48 +0100 schrieb Ludovic Courtès: > > Hi! > > > > Leo Prikler skribis: > > > > > both Epiphany and Eolie (post fixing #47097; will submit patch > > > shortly) > > > fail inside Guix containers with the suggested incantation. After > > > getting the environment to no longer complain about $DISPLAY by > > > adding > > > `--preserve="XAUTHORITY" --expose=$XAUTHORITY', it repeatedly > > > outputsn > > > lines like > > > bwrap: Can't find source path /sys/class: No such file or directory > > > before closing the process altogether. > > > > What is ‘bwrap’ looking for? /sys is mounted inside ‘guix > > environment -C’, > > but perhaps it needs something special? > > > > I suggest running these things (or ‘bwrap’ directly) in ‘strace -f -o > > log’ inside the container to see. > It seems to be > > openat(AT_FDCWD, "/sys/class/dmi/id/chassis_type", O_RDONLY) = -1 > > ENOENT (No such file or directory) > > openat(AT_FDCWD, "/sys/firmware/acpi/pm_profile", O_RDONLY) = -1 > > ENOENT (No such file or directory) > > I haven't repeated that for all warnings of similar kind, but if I add > `--expose=/sys/block --expose=/sys/class --expose=/sys/bus -- > expose=/sys/dev --expose=/sys/devices` to the invocation, I instead get > a warning, that the WebKitWebProcess can't open $DISPLAY. I'm not sure > how to resolve that one, given that I already had to sneak DISPLAY and > XAUTHORITY into the container, but it's a start. > > Regards, > Leo > Does $DISPLAY mean ":0" and does the Wayland server answer that with its XWayland X-interface? I am wonderering how that is resolved inside a container. HTH with the detective work ;) -- Regards, Bengt Richter
bug#46981: Severe Emacs shell mode performance regression in recent Linux-libre
Hi Mark, et? On +2021-03-06 21:54:42 -0500, Mark H Weaver wrote: > Mark H Weaver writes: > > > FYI, for those who use Emacs shell mode (M-x shell), I wanted to give a > > heads-up about a severe performance regression in Linux-libre 5.10.20, > > and I suspect the same regression exists in 5.11.3. > > > > For details, see the bug report I submitted to the Emacs developers, > > here: <https://bugs.gnu.org/46978>. > > I've since confirmed that reverting the two upstream commits mentioned > in <https://bugs.gnu.org/46978> fixes the performance regression. I've > attached a preliminary patch for Guix that reverts those upstream > commits for linux-libre@5.10, and which I've tested on my system. > > I guess that the same fix is also needed for linux-libre@5.11, but I've > not checked. I'll leave it to others to try applying the same reverts > to 5.11.3 if they wish, and to decide what (if anything) should be done > in Guix about this issue. > > Mark > > > Is the vt infrastructure that emacs uses to do Mx shell well virtualized so that e.g. a native wayland bash repl displaying tile could be plugged in? (if not, why not? :) Seems like an html-textarea-like wayland tile could be implemented to present the bash-stdout for emacs, and also capture it in a shm-pool for access by emacs as open file or mmap, to do its mode-dependent indenting and highlighting, then sending that to another text-area vt tile. Excuse the handwaving, but I think it could be done, from what I've read about wayland clients and servers. -- Regards, Bengt Richter PS. BTW: anybody thought about defining a wayland server to act as guix daemon? It already has async threadsafe event loop and manages access-isolated pools of memory, and you can define extended protocol for access. And on a wayland-based box, this would be available early. Early enough for hurd initialization to make use of, I think. Daydream? :)
bug#46663: [Website] 404 redirection on a link in a blog article
Hi, On +2021-02-24 18:58:38 +0100, pelzflorian (Florian Pelz) wrote: > On Mon, Feb 22, 2021 at 08:20:43PM +0100, raingloom wrote: > > Is there something that scans the website for broken links? Might be > > worth setting up if not. > > You made me check for other broken links using wget on a local build > of the website. Indeed there were some more broken links. Thanks! > > However I am too lazy to try to set up automatic and continuous broken > link checking. I think me and others should just be more careful when > moving things around. > > Regards, > Florian > > > I couldn't believe this is not a stardard tool for web site maintainers, so i put web broken link lister to duckduckgo and got lots of hits. Well, tl;dr -- having other concerns at the moment, but at least I felt my hunch validated. I bet it gets re-invented a lot :-p -- Regards, Bengt Richter
bug#46482: [core-updates] u-boot source cannot be downloaded
Hi Leo et al, On +2021-02-13 14:12:13 -0500, Leo Famulari wrote: > On Sat, Feb 13, 2021 at 07:34:09PM +0100, Bengt Richter wrote: > > I would prefer something that fits in with mes-philosopy. > > ftp seems old and simple, so I would vote for push-back > > to fix the ftp client involved. > > FTP is more complicated than HTTP in that it requires the use of > multiple connections. Additionally, it's often blocked on corporate > networks, whereas HTTP/S is never going to be blocked (HTTPS anyways). > > Based on experience in Guix, we have never had bug reports from users > who could not access sources over HTTP/S, but there have been several > reports of problems using FTP. The HTTP/S ports 80 and 443 are basically > the only ports you can depend on being open on a network that is > connected to the internet. > > The creator of curl compares them here: > > https://daniel.haxx.se/docs/ftp-vs-http.html Thanks, that was interesting. He says (re download speed) "Ultimately the net outcome of course differs depending on specific details, but I would say that for single-shot static files, you won't be able to measure a difference." So in that case, what's minimal, and how vulnerable is it? Is there a minimal quic without google upstream? or X.25 -- dating myself ;-P and what about TFTP/PXE ?? What would the mes-people suggest for minimalist functionality, and minimal trust scope, and maximal monopoly-independence, I wonder? [meta-question] How does one gracefully go off-topic onto a tangential discussion? I thought my original comment re expired gpg key might have helped in some way, but my comment wanting to get the ftp fixed intead of (or in addition to) being bypassed provoked the explanation of how I was deluded (ok, no worries :), but I might want to say something about separate connections isolating meta-data and data as being a "feature" that I expect to see more of, but that would be another step along the tangent ... or osculating circle? NNTR :-D -- Regards, Bengt Richter
bug#46482: [core-updates] u-boot source cannot be downloaded
Hi, On +2021-02-13 03:37:52 +0100, Danny Milosavljevic wrote: > failed to download > "/gnu/store/1idpm6f9pcm9dajm90qgk6x1r6qywfv8-u-boot-2021.01.tar.bz2" from > "ftp://ftp.denx.de/pub/u-boot/u-boot-2021.01.tar.bz2; > builder for > `/gnu/store/5s92y4l66f8qh4p4gx79jvsjaxhl208k-u-boot-2021.01.tar.bz2.drv' > failed to produce output path > `/gnu/store/1idpm6f9pcm9dajm90qgk6x1r6qywfv8-u-boot-2021.01.tar.bz2' > build of > /gnu/store/5s92y4l66f8qh4p4gx79jvsjaxhl208k-u-boot-2021.01.tar.bz2.drv failed > View build log at > '/var/log/guix/drvs/5s/92y4l66f8qh4p4gx79jvsjaxhl208k-u-boot-2021.01.tar.bz2.drv.bz2'. > cannot build derivation > `/gnu/store/m09apasn4glhf2lvsq8bn2ci5ncjq0fz-u-boot-tools-2021.01.drv': 1 > dependencies couldn't be built > building > /gnu/store/5s4pczxlp3v8yfavmgjf93093msfaxym-ucommon-7.0.0.tar.gz.drv... > > Changing the URL to "https" instead of "ftp" would work. > Changing it to "http" instead of "ftp" would also work. > Which should we use? > > Reason is bug #46481. > > But do we maybe want to change over to http or https anyway? So long as you can check the hash of the downloaded file, IMO other considerations ought to dominate the choice. I would prefer something that fits in with mes-philosopy. ftp seems old and simple, so I would vote for push-back to fix the ftp client involved. FWIW: I clicked on the "ftp://ftp.denx.de/pub/u-boot/u-boot-2021.01.tar.bz2; URL in your "failed to download" message above, and got an open/save-as popup choice widget, and clicked save-as and successfully downloaded it, and can inspect it with tar -tjvf u-boot-2021.01.tar.bz2|less I am running pureos (debian variant): --8<---cut here---start->8--- 4.19.0-14-amd64 #1 SMP Debian 4.19.171-2 (2021-01-30) --8<---cut here---end--->8--- and was in a tilix terminal when I clicked the URL, which started Mozilla Firefox 78.7.0esr which gave me the open/save-as popup choice. IDK what firefox does with ftp://... but it worked. I guess I could strace it, but what does firefox or icecat do on your box if directed to ftp://ftp.denx.de/pub/u-boot/u-boot-2021.01.tar.bz2 ? HTH -- Regards, Bengt Richter
bug#45109: GNOME: unable to change alert "beep" sound since staging merge
Hi Mark, and who may be interested, On +2020-12-14 19:11:51 -0500, Mark H Weaver wrote: > reopen 45109 > thanks > > Earlier, I wrote: > > I initially tried Marius's idea to revert the dconf update, which > > seemed to work, but now I find that I'm unable to reproduce the > > problem, even with my original post-staging-merge system where I first > > encountered it. > > I spoke too soon. Now the problem is happening again, after another > system upgrade and reboot. I don't have time right now to investigate > further, but I'm reopening the bug. > > Thanks, >Mark The same happened again to me -- i.e., my alert sound preference got reset. This was after a pureos (debian based) update. uname -a =-> Linux LionPure 4.19.0-13-amd64 #1 SMP Debian 4.19.160-2 (2020-11-28) x86_64 GNU/Linux man 7 dconf =-> mentions that gsettings wraps unstable api gconf, so I poked a little, but no time right now. HTH someone else go further :) --8<---cut here---start->8--- $ gsettings list-recursively |egrep 'sound|beep' org.gnome.desktop.sound input-feedback-sounds false org.gnome.desktop.sound theme-name '__custom' org.gnome.desktop.sound allow-volume-above-100-percent false org.gnome.desktop.sound event-sounds true org.gnome.rhythmbox.plugins seen-plugins ['fmradio', 'mpris', 'daap', 'rb', 'artsearch', 'replaygain', 'webremote', 'lyrics', 'dbus-media-server', 'im-status', 'rblirc', 'notification', 'grilo', 'audioscrobbler', 'soundcloud', 'sendto', 'mtpdevice', 'pythonconsole', 'ipod', 'magnatune'] org.gnome.desktop.a11y.keyboard slowkeys-beep-press false org.gnome.desktop.a11y.keyboard bouncekeys-beep-reject false org.gnome.desktop.a11y.keyboard slowkeys-beep-reject false org.gnome.desktop.a11y.keyboard feature-state-change-beep false org.gnome.desktop.a11y.keyboard slowkeys-beep-accept false org.gnome.desktop.a11y.keyboard stickykeys-modifier-beep false --8<---cut here---end--->8--- As you recall from previously (here I've re-selected sonar.ogg :), --8<---cut here---start->8--- $ find ~/ -name '*__custom*' /home/bokr/.local/share/sounds/__custom $ find ~/ -name '*__custom*'|xargs ls -l total 4 lrwxrwxrwx 1 bokr bokr 48 Dec 17 08:52 bell-terminal.ogg -> /usr/share/sounds/gnome/default/alerts/sonar.ogg lrwxrwxrwx 1 bokr bokr 48 Dec 17 08:52 bell-window-system.ogg -> /usr/share/sounds/gnome/default/alerts/sonar.ogg -rw-r--r-- 1 bokr bokr 61 Dec 10 12:11 index.theme --8<---cut here---end--->8--- BTW, do you or anyone know if there is a CRUD[1]-log that can be enabled, to log *EVERY* CRUD change to any persistent storage during system (debian in this case) updates? That can't be a new idea ;) (Maybe it's hard in the context of something signed that runs privileged to do updates before rebooting to grub? ) Also, is there a standard policy somewhere for preserving/migrating content state when installing a replacement storage box for the content? If it is too much work to write migration code when storage internals or apis change, couldn't it just be policy to mark the old box as box.old_NNN instead of deleting/overwiting it, and emit (and log) a simple hint? [1] https://en.wikipedia.org/wiki/Create,_read,_update_and_delete -- Regards, Bengt Richter
bug#45109: GNOME: unable to change alert "beep" sound since staging merge
Mark You could just make all 4 files dupes of sonar.ogg ;)) I am afraid that kind of "fix" becomes more and more tempting ;/ I still don't know what the proper fix for your observed prolem is, sorry. But HTH :) -- Regards, Bengt Richter
bug#45069: Guix System: unprivileged user cannot create user namespaces?
Hi Vagrant, On +2020-12-07 09:55:31 -0800, Vagrant Cascadian wrote: > On 2020-12-07, zimoun wrote: > > On Mon, 07 Dec 2020 at 18:13, Pierre Neidhardt wrote: > > > >>> Can you try, as root on Guix System: > >>> > >>> $ echo 1 > /proc/sys/kernel/unprivileged_userns_clone > >> > >> # echo 1 > /proc/sys/kernel/unprivileged_userns_clone > >> -bash: /proc/sys/kernel/unprivileged_userns_clone: No such file or > >> directory > > > > In gnu/build/linux-container.scm, it reads: > > > > --8<---cut here---start->8--- > > (define (unprivileged-user-namespace-supported?) > > "Return #t if user namespaces can be created by unprivileged users." > > (let ((userns-file "/proc/sys/kernel/unprivileged_userns_clone")) > > (if (file-exists? userns-file) > > (eqv? #\1 (call-with-input-file userns-file read-char)) > > #t))) > > --8<---cut here---end--->8--- > > > > Does it mean that the Linux kernel on Guix System does not support > > namespaces by unprivileged users? > > > Turning #t to #f should work on Guix System and it appears to me a > > severe bug if not. What do I miss? Please could someone fill my gap? :-) > > The /proc/sys/kernel_unprivileged_userns_clone file is specific to > Debian and Ubuntu packaged linux kernel; it is a patchset not applied > upstream, as far as I am aware. I'm not sure if other distros support > disabling and enabling this feature using this mechanism. > > > https://salsa.debian.org/kernel-team/linux/-/blob/master/debian/patches/debian/add-sysctl-to-disallow-unprivileged-CLONE_NEWUSER-by-default.patch > > live well, and as virtuously as you are able ... so that spies can't help but admire and reflect :) > vagrant Another data point FYI: On my pureos system, which is based on debian upstream: uname -a =-> Linux LionPure 4.19.0-12-amd64 #1 SMP Debian 4.19.152-1 (2020-10-18) x86_64 GNU/Linux and ls -l /proc/sys/kernel/unprivileged_userns_clone -rw-r--r-- 1 root root 0 Dec 8 03:03 /proc/sys/kernel/unprivileged_userns_clone and (noticing that the items appear to be short and ascii lines, hence thereupon head :) --8<---cut here---start->8--- od -a -t x1 /proc/sys/kernel/unprivileged_userns_clone 000 0 nl 30 0a 002 head /proc/sys/kernel/unprivileged_userns_clone 0 --8<---cut here---end--->8--- Not sure this tells you anything useful, but there is also: --8<---cut here---start->8--- head /proc/sys/user/* ==> /proc/sys/user/max_cgroup_namespaces <== 128163 ==> /proc/sys/user/max_inotify_instances <== 128 ==> /proc/sys/user/max_inotify_watches <== 65536 ==> /proc/sys/user/max_ipc_namespaces <== 128163 ==> /proc/sys/user/max_mnt_namespaces <== 128163 ==> /proc/sys/user/max_net_namespaces <== 128163 ==> /proc/sys/user/max_pid_namespaces <== 128163 ==> /proc/sys/user/max_user_namespaces <== 128163 ==> /proc/sys/user/max_uts_namespaces <== 128163 --8<---cut here---end--->8--- HTH some way :) -- Regards, Bengt Richter
bug#41906: [mumi] Raw mailbox download not usable with mutt
Hi Ricardo, et al, On +2020-12-06 18:35:08 +0100, Ricardo Wurmus wrote: > > Hi Lars, > > > currently mailbox files generated by mumi’s /raw/ endpoint are not usable > > with > > mutt, because the first line contains a “Received:” header and thus does not > > start with the mandated “From …” banner. > > Does the equivalent mbox provided by the official Debbugs web interface > work? This endpoint is called “raw” because it returns the plain email > as I got it from Debbugs. It doesn’t seem right for me to manipulate it. > > -- > Ricardo > > On a guix debbugs web page I observed the following: The option to download a single bug report on a debbugs web page as mbox seems to work fine. E.g., the page with your report https://debbugs.gnu.org/cgi/bugreport.cgi?bug=38715#28 has a link https://debbugs.gnu.org/cgi/bugreport.cgi?mbox=yes;msg=28;bug=38715 which one can save-as, resulting in file bug_38715_message_28.mbox which mutt -f bug_38715_message_28.mbox will show normally. But I don't, e.g., know how to get all the debbugs guix bug reports for e.g. December the way I can for the regular mailing list archives -- does mumi do that? -- e.g. like for bug-guix at https://lists.gnu.org/archive/mbox/bug-guix/ where you can wget -c https://lists.gnu.org/archive/mbox/bug-guix/2020-12 resulting in an mbx file 2020-12 which mutt -Rf 2020-12 will open for you (I use -R for read-only) The '-c' wget option tells wget just to download the new appended emails if you already have the 2020-12 file in your current directory, so that's economical :) I follow half a dozen or so gnu mail lists that I don't subscribe to, and wget -c works fine on all of them. The -MM format seems to be generated like "$(date '+%Y-%m')" so it's easy to script urls for wget. It might be nice for debbugs to synthesize cgi-equivalents to https://lists.gnu.org/archive/mbox/bug-guix/2020-12 for lists that want it. Maybe by a debbugs name like https://lists.gnu.org/archive/mbox/debbugs-guix/2020-12 and similarly for other bug- ? Maybe it already exists, but it's not apparently listed at https://lists.gnu.org/mailman/listinfo/ (though help-debbugs is, but that is a normal mailing list I think :) Sorry if this is not on topic mumi per se, but it is about viewing bug reports using mutt on mbox files :) I don't use mumi, but if it doesn't have clean mbox as an output option, I think it ought to be fixed :) -- Regards, Bengt Richter
bug#44927: Guix reboot stops with some errors
Hi znavko, On +2020-11-28 19:05:25 +, znavko--- via Bug reports for GNU Guix wrote: > I have deleted lines with disks in config and reconfigured but the error > remains. > > I switched to generation (system and packages by root) but an issue remains. > > In Attach entire screen with trace. > > What is that? > November 28, 2020 6:47 PM, "znavko--- via Bug reports for GNU Guix" > (mailto:bug-guix@gnu.org?to=%22znavko---%20via%20Bug%20reports%20for%20GNU%20Guix%22%20)> > wrote: > Hello! > I have a trouble that I cannot solve and did not have such before. > When I reboot or power off my pc the process of shutdown stops with lines of > 'call trace' (in attach). > It happened today after hundreds of tries of update with network errors (from > guix server as I think) > https://lists.gnu.org/archive/html/help-guix/2020-11/msg00220.html > (https://lists.gnu.org/archive/html/help-guix/2020-11/msg00220.html) > > I just added another disk to my system, it works fine. > But something happened. > Please where to dig? > > Config is in attach. Just a guess, from my experience with device busy messages: Is there a process which has a current working directory on the device when you shut down? (E.g., I think it could happen if you had cd'd there to look around, and forgotten to cd back out first. Or perhaps there is a bug doing something similar?) HTH -- Regards, Bengt Richter
bug#44717: ISO grub config points to nonexistent drive UUID.
Hi again, On +2020-11-18 12:17:14 -0700, Jesse Gibbons wrote: > > > On 11/18/20 11:09 AM, Bengt Richter wrote: > > Hi Jesse, > > > > On +2020-11-17 21:56:32 -0700, Jesse Gibbons wrote: > > [...] > > > I generated the iso with the command > > > `guix system disk-image -t iso9660 --root=installer.BaNl/install-x86.iso > > > --system=i686-linux gnu/system/install.scm` > > > and flash the sd card with the command > > > `sudo bash -c "echo success" && time sudo dd if=install-x86.iso > > > of=/dev/sdc` > > > > > && sync ?? > > > > I think I have gotten corrupted results before, by assuming that DD does > > its own sync > > of its output all the way to completed writing to destination disk before > > returning. > > (not sure if of= was an ordinary file when I got hit, though ;) > I'm not sure how I can get it to sync. I would normally use the gnome disk I actually meant try adding " && sync" to your command line. Or, when it comes back after printing timing info, do the sync command separately, right then. Either way, it may seem to "hang" after seeing the sync command. Writing to SDHC cards is pretty (glacially :) slow, so if the OS has cached a lot of write buffers from DD output, it may well seem to "hang" after you type sync. If it does, it will confirm this theory :) Don't kill it, make some coffee and come back ;-) Or spawn another terminal and look with top to see what's going on. > utiltity to flash an image to an external drive, but for a while it didn't > respond when I tried to "restore disk image". Now it's working fine though. > I'll try using gnome disk utility to flash and see if that makes a > difference. > > > When I inspect the GRUB menu, I see the option > > > --root=31393730-3031-3031-3139-333534353239 > > > but in the gnome disk utility on my main laptop I do not see the above > > > UUID > > > in any of the partitions on the SD card I'm using, still with the freshly > > > built install iso flashed onto it. Instead I see the UUIDs > > > 1970-01-01-19-49-46-83 for partition 1 and 3495-32E0 for partition 2. > > > > > > Thanks, > > > -Jesse > > > > > > > > > > -- Regards, Bengt Richter
bug#44723: Latest binary tarball & Hurd qcow2 image unavailable (502)
Hi, On +2020-11-18 18:50:03 +0100, zimoun wrote: > Hi, > > On Wed, 18 Nov 2020 at 18:46, Ludovic Courtès wrote: > > > I guess it’s OK for Guix System ISO images because a fresh one gets > > built at each evaluation, roughly, but perhaps the Hurd images are not > > rebuilt frequently enough and the changes that they’re GC’d are higher. > > > > I don’t have a good solution for that, we’re consuming storage space too > > quickly with all these images currently. :-/ > Eric Blake from Red Hat is IIUC working on qemu features to share clean parts of images without duplicating [1] and LWN has an article re his work [2] (I hope posting this [2] subsriberlink here is Ok with LWN -- I would think so) Perhaps their incremental chaining technology can help consolidate "all these images" ? > Does it make sense to only keep the latest? And GC all the older one > except the stable one (pinned). > > Cheers, > simon > > > [1] https://static.sched.com/hosted_files/kvmforum2020/92/kvmforum_2020_Bitmaps_and_NBD.pdf [2] https://lwn.net/SubscriberLink/837053/06072931fc4162bf/ ([2] should be available freely to all as [3] in less than a week) [3] https://lwn.net/Articles/837053/ -- Regards, Bengt Richter
bug#44717: ISO grub config points to nonexistent drive UUID.
Hi Jesse, On +2020-11-17 21:56:32 -0700, Jesse Gibbons wrote: [...] > > I generated the iso with the command > `guix system disk-image -t iso9660 --root=installer.BaNl/install-x86.iso > --system=i686-linux gnu/system/install.scm` > and flash the sd card with the command > `sudo bash -c "echo success" && time sudo dd if=install-x86.iso of=/dev/sdc` > && sync ?? I think I have gotten corrupted results before, by assuming that DD does its own sync of its output all the way to completed writing to destination disk before returning. (not sure if of= was an ordinary file when I got hit, though ;) > When I inspect the GRUB menu, I see the option > --root=31393730-3031-3031-3139-333534353239 > but in the gnome disk utility on my main laptop I do not see the above UUID > in any of the partitions on the SD card I'm using, still with the freshly > built install iso flashed onto it. Instead I see the UUIDs > 1970-01-01-19-49-46-83 for partition 1 and 3495-32E0 for partition 2. > > Thanks, > -Jesse > > > -- Regards, Bengt Richter
bug#44612: Read standard input in `guix repl'
Hi Pierre, On +2020-11-13 10:41:38 +0100, Pierre Neidhardt wrote: > `guix repl` is a fantastic, hassle-free tool to bind Guix with > third-party languages. I've done it here: > > https://github.com/atlas-engineer/nyxt/blob/2-pre-release-4/libraries/ospama/ospama-guix.lisp > > It just works! > > The only issue is that it needs to be passed a file, so I must create a > temporary file so that I can call `guix repl` on it. > > It'd be better if we could send Guile code to the standard input of the > `guix repl -` process to bypass file generation. > > Thoughts? > Would this enable people to type something like wget -O - http:try.this.for.example.com/fun.mischief|guix repl - and if so, can you suggest some options for automatic hash or signature checking so that a paranoid could feel safe using a file pointed to by a friend? (I know one can already do silly stuff ... :) I was hoping for a concise option that would enable a standard way of doing integrity/trust checks by the stdin bufferful within guix. (Which I guess implies designing fun.mischief file syntax as some kind of container packet stream, with individually verifiable packets -- what would that mean for input to guix repl?). Maybe a --paranoid option at the level of --dry-run or -n ? (maybe configurable as default --paranoid=on :) As far as avoiding file generation, a pipeline that needs file-size chunks to do validation checks would only avoid file inode supply limits, right? I guess YMMV per platform? IPC also has supply limits, IIRC. Hm, what about an option for guix like guix --trust-manifest="file-containing-sufficient-verification-info-for-what-happens-next" repl - meaning e.g., sha256sum value for what would be passed via '-' and if that contains references to other files etc., than hashes or signatures etc for everything entailed. > -- > Pierre Neidhardt > https://ambrevar.xyz/ -- Regards, Bengt Richter
bug#44353: guix system disk-image -t raw fails with grub-efi-bootloader
Hi Mathieu, On +2020-11-07 10:08:36 +0100, Mathieu Othacehe wrote: > > Hello Maxim, > > Thanks for your patch! It's hard to provide a reliable abstraction on > top of all the exotic bootloader installation methods existing. > > Currently, each bootloader implements two methods: > > * bootloader-installer > * bootloader-disk-image-installer > > The first one is dedicated to the installation of the bootloader on a > mounted directory, while the second one is meant to work on a disk > device such as "/dev/sda" or directly on a disk-image. > > When producing a disk-image with the "raw" type, we are always creating > and populating an ESP partition (see raw-image-type), regardless of the > selected bootloader. In fact, "raw" should be renamed to "hybrid-efi". > > The produced image can work on machines with legacy mbr boot or with EFI > boot. Hence, calling "install-grub-efi" like it's done while building > the lightweight-desktop operating-system is useless and fails. The > attached patch fixes it. > > You can test it with: > > --8<---cut here---start->8--- > qemu-system-x86_64 -m 1024 -bios $(guix build > ovmf)/share/firmware/ovmf_x64.bin -hda disk.img > --8<---cut here---end--->8--- > > > + ;; Special case: most bootloaders can be > > copied > > + ;; directly at some fixed location on the > > image > > + ;; disk, but when installed to the master > > boot > > + ;; record (MBR), GRUB requires support files > > + ;; present under /boot/grub, which is > > handled by > > + ;; its 'installer' procedure. > >#:bootloader-installer > > - #+(bootloader-installer bootloader) > > + #+(if (eq? 'grub (bootloader-name > > bootloader)) > > +(bootloader-installer bootloader) > > +#f) > > That would prevent other bootloaders relying on this procedure to work, > such as extlinux. > > Thanks, > > Mathieu Given that writing to "raw" disks is something the dd command is often used for, how much trouble would it be to provide an option for bootloader-disk-image-installer to output a shell script with the necessary dd commands, instead of doing the raw writing itself? I am imagining a tarball with separate binary block-sequence file images for the GPT or MBR header blocks, the embedded boot loader or UEFI partition image, and root partition etc.. I think the block-sequence images can be sliced out of the backing file of a loopback mount that fdisk and mkfs.* can format as desired, unless I'm missing something. I would like the script to use lsblk -o model,serial to identify the raw disk to write to, so there is no shooting the wrong foot ;) This is sketchy on the details, but ISTM a tarball like this would make it easy to prepare a USB-accessible disk using any laptop that was in a state where it was trusted to do sudo dd ... right. If the laptop didn't have all the tools, perhaps a minimal static busybox could be included in the tarball to guarantee existence of the dd and lsblk tools etc. There might be some file content that needs to be written with file i/o after dd has written the content-initialized monolith file system images. This could be interactive choices of alternate hostname, passwords, or whatever. Remember, this script is not burning a bootable installer (though it could), it is burning the bootable system an installer would install. The point of this is that it happens as the script with the dd commands executes on an arbitrary laptop with a raw USB disk attached, not as initialization dialog on first boot of the system whose image is being written to the USB disk. Obviously all files should be verifiable one way or another. Hopefully it would also make it easier to share/generate system images for raspberries or RISC-V ARM, etc. I guess you could call this a shell-script derivation, meant to talk to bash/dd instead of the guix daemon. Has anyone done this kind of factoring already? TIA for comment :) -- Regards, Bengt Richter
bug#44101: Unable to use /dev/disk/by-id/ symlinks with u-boot and guix system reconfigure
Hi, On +2020-10-22 13:08:45 -0700, Vagrant Cascadian wrote: > On 2020-10-22, Mathieu Othacehe wrote: > > Hey Vagrant, > > > >> I'm writing this from memory now, but I can also boot the machines at a > >> later point and get the exact configurations, if needed. > > > > Sorry for breaking your use-case. Recently I have split up the > > bootloader installation in two distinct parts: > > Thanks for your work on it, even if it resulted in a regression. :) > > > > - Installing a bootloader directly on a mounted directory. > > - Installing a bootloader on a raw-image or device. > > > > Depending on the bootloader type, one or both of the methods are > > supported. u-boot does not really support the first method, so the > > patch you are mentioning is disabling this method. > > > > The problem is while reconfiguring, the first method only is used. The > > attached patch tries to fallback to the second method if the first one > > is not defined. > > I don't quite understand why that would be the issue here; guix system > reconfigure works fine when /dev/mmcblkN is specified target in the > system config.scm, just not when the target is /dev/disk/by-id/... > > My wild guess was something was checking for a literal block device, and > failing with a symlink pointing to a block device. > IIUC [1] implies the contents of /dev/disk/by-id is populated on udev events, so IIRC the values can be stale. Maybe that's an eliminated race by now, or a clue about old systems? [1] https://unix.stackexchange.com/questions/86764/understanding-dev-disk-by-folders > > Trying your patch gets me a backtrace, unfortunately... > > With the bootloader section... > > (bootloader (bootloader-configuration >(target "/dev/disk/by-id/mmc-SDU64_0xbaf3002e") > (bootloader u-boot-pinebook-bootloader) > )) > > And your patch applied on top of 3e09453884efa82ef97b8ec6e34470c67a1206a7... > > $ sudo -E ./pre-inst-env guix system reconfigure --keep-going > ~/pinebook-1080p-desktop.scm > ... > waiting for locks or build slots... > building > /gnu/store/n17lkvs6vhq0x16mk0rxnv4j5ifvrlyr-switch-to-system.scm.drv... > making '/gnu/store/vc3bzajlv0yxrdjmqph4sikzqkywvfq1-system' the current > system... > setting up setuid programs in '/run/setuid-programs'... > populating /etc from /gnu/store/gssnxbhwa9dygn1i6i46j81ww5gczzav-etc... > The following derivation will be built: >/gnu/store/s19y61jrdys760zccxm2qiiqjpcv1fcx-install-bootloader.scm.drv > > building > /gnu/store/s19y61jrdys760zccxm2qiiqjpcv1fcx-install-bootloader.scm.drv... > Backtrace: > In guix/scripts/system.scm: >1339:8 19 (_) > In guix/status.scm: > 776:4 18 (call-with-status-report _ _) > In guix/scripts/system.scm: >1172:4 17 (_) > In ice-9/boot-9.scm: > 1736:10 16 (with-exception-handler _ _ #:unwind? _ # _) > In guix/store.scm: >631:37 15 (thunk) >1300:8 14 (call-with-build-handler _ _) >1300:8 13 (call-with-build-handler _ _) >1300:8 12 (call-with-build-handler _ _) >1300:8 11 (call-with-build-handler _ _) >1300:8 10 (call-with-build-handler _ _) >1300:8 9 (call-with-build-handler # …) > 2042:24 8 (run-with-store # …) > In guix/scripts/system.scm: >842:13 7 (_ _) >844:15 6 (_ _) >750:13 5 (_ _) > In ice-9/boot-9.scm: > 152:2 4 (with-fluid* _ _ _) > In unknown file: >3 (primitive-load "/gnu/store/81w2h9zd6b5q0ddchc0wr6vph22…") > In ice-9/eval.scm: > 619:8 2 (_ #(#(# "//v…") #)) > In ice-9/boot-9.scm: > 1669:16 1 (raise-exception _ #:continuable? _) > 1669:16 0 (raise-exception _ #:continuable? _) > > ice-9/boot-9.scm:1669:16: In procedure raise-exception: > ERROR: > 1. /o-filename: "/dev/disk/by-id/mmc-SDU64_0xbaf3002e" > > > It also fails when target is /dev/mmcblk1. > > So, clearly this is some other issue... > > > live well, > vagrant HTH, otherwise sorry for the noise :) -- Regards, Bengt Richter
bug#44027: [PATCH] installer: Create bios_grub partition when it is needed.
LionPure 4.19.0-9-amd64 #1 SMP Debian 4.19.118-2+deb10u1 (2020-06-07) x86_64 GNU/Linux ...without guix though, sorry, I like guix :/ (though there's lots of scraps around, until I can install one with absolute minimal use of sudo :) [1] https://stackoverflow.com/questions/2432759/usb-drive-serial-number-under-linux-c HTH make things better (at least with the confirmation dialog part :) And maybe a clue to a bug. -- Regards, Bengt Richter
bug#43960:
Hi Simon, On +2020-10-15 15:56:41 +0200, zimoun wrote: > Hi Bengt, > > On Thu, 15 Oct 2020 at 15:53, Bengt Richter wrote: > > > If there is a left-over from old manual installation advice like > > --8<---cut here---start->8--- > > /usr/local/bin/guix: > > symbolic link to /var/guix/profiles/per-user/root/current-guix/bin/guix > > --8<---cut here---end--->8--- > > could it interfere in any way with the above, or subsequent operation? > > You mean the step #6 from the manual [1], right? > Yes. I didn't realize it was still there -- I may mis-remember some discussion deprecating the use of /usr/local/* to affect the namespace seen when typing guix whatever. (vs putting needed info in ~/.bash_profile or ~/.profile) I.e., even though the target is /var/guix/... it is not by way of ~/.guix-profile unless that's been put first in the path via ~/.bash_profile. But /usr/local/bin is typically on a default PATH, so could you not accidentally see the wrong guix (rather than a more informative file-not-found) if the enviroment was not straight-forwardly inherited from a normal login? (e.g. emacs subshell pts? Haven't checked ;) Also doesn't the ".../per-user/root/..." part in the link make you dependent on the result of _sudo_ guix pull, not plain guix pull? (or are they equivalent somehow?) IDK, but I really don't like typing "sudo guix ..." any better than "sudo firefox" or "sudo python" or "sudo " I hope we can get to 100%-user-mode guix. Maybe offloading to containerized guix systems could be a model for swarms of cooperating user-mode peers (modulo some protocol for synchronizing versions identified by guix describe) for distributed challenges, and normal usage would run guix with a localhost swarm providing the guix user-mode-daemons ;) > 1: <https://guix.gnu.org/devel/manual/en/guix.html#Binary-Installation> > > > All the best, > simon Sorry if this is only illustrating my noob misconceptions :) -- Regards, Bengt Richter
bug#43960:
On +2020-10-15 11:47:30 +0200, zimoun wrote: > Hi, > > On Thu, 15 Oct 2020 at 09:53, Ludovic Courtès wrote: > > > I don’t think it’s a reasonable response: it’s a fact that we naturally > > tend to read manuals sparsely, at best. > > > > Since the pastes vanished, how did ‘sudo guix pull’ lead to incompatible > > bytecode warnings? > > If I remember correctly (which is neither a reasonable response :-)), it > should highly come from the user config. And the investigation needs > more information, e.g., as Tobias asks: the output of: > > $ type guix > $ ls -l ~/.config/guix/current > $ sudo rm ~/.config/guix/current > $ /run/current-system/profile/bin/guix pull > $ hash guix > $ type guix > > All the best, > simon > If there is a left-over from old manual installation advice like --8<---cut here---start->8--- /usr/local/bin/guix: symbolic link to /var/guix/profiles/per-user/root/current-guix/bin/guix --8<---cut here---end--->8--- could it interfere in any way with the above, or subsequent operation? -- Regards, Bengt Richter
bug#43528: Download all issues so I can search?
On +2020-10-08 21:41:14 -0400, Maxim Cournoyer wrote: > Michael Rohleder writes: > > > Here's [1] an archive of the ML in mbox format. > > Maybe this helps if you want to grep for things. > > > > > > [1] https://lists.gnu.org/archive/mbox/bug-guix/ > > That is indeed a good suggestion. > > Closing. > > Thanks, > > Maxim > > > I discovered that the server supports incremental download using the '-c' option of wget (so it only downloads what was added to the archive since you last did it), e.g., wget -c https://lists.gnu.org/archive/mbox/bug-guix/2020-10 then mutt -f 2020-10 # (or gnus equivalent I guess) looks normal. Probably not news to most devs, but I thought it nice that it works. (For me anyway :) -- Regards, Bengt Richter
bug#43762: ‘guix environment -C’ containers lack /etc/hosts
Hi Ludo, On +2020-10-02 15:53:49 +0200, Ludovic Courtès wrote: > Hi! > > Look: > > --8<---cut here---start->8--- > $ guix environment -C --ad-hoc coreutils -- cat /etc/hosts > cat: /etc/hosts: No such file or directory > $ guix describe > Generacio 162 Oct 01 2020 00:23:38(nuna) > guix 7607ace > repository URL: https://git.savannah.gnu.org/git/guix.git > branch: master > commit: 7607ace5091aea0157ba5c8a508129cc5fc4f931 > --8<---cut here---end--->8--- > > I think we should add /etc/hosts with an entry for “localhost”, just > like libstore/build.cc does. > > Ludo’. > How sensitive is this data? E.g., compared to /etc/hostname and /etc/machine-id ? man machine-id says in part --8<---cut here---start->8--- This ID uniquely identifies the host. It should be considered "confidential", and must not be exposed in untrusted environments, in particular on the network. If a stable unique identifier that is tied to the machine is needed for some application, the machine ID or any part of it must not be used directly. Instead the machine ID should be hashed with a cryptographic, keyed hash function, using a fixed, application-specific key. That way the ID will be properly unique, and derived in a constant way from the machine ID but there will be no way to retrieve the original machine ID from the application-specific one. The sd_id128_get_machine_app_specific(3) API provides an implementation of such an algorithm. --8<---cut here---end--->8--- And how do you pick an appropriate hostname (which often appears in /etc/hosts) for an image that could be booted in the clouds, or like a live USB, on any compatible laptop? -- Regards, Bengt Richter
bug#43513: json-c build failure (on armhf-linux) while trying to build u-boot
Hi, On +2020-09-30 14:17:31 +0200, Andreas Enge wrote: > Hello, > > On Wed, Sep 30, 2020 at 01:27:54PM +0200, Danny Milosavljevic wrote: > > At least I don't. I don't even have a homedir on dover.guix.info, so I > > cannot > > run guix pull, guix describe, or really anything that is interesting on > > there. > > this is a problem I have now seen at least three times, so I have opened > its own bug: >https://issues.guix.gnu.org/43720 > > Andreas > At https://issues.guix.gnu.org/43720 it says --8<---cut here---start->8--- Your may also send email to 43...@debbugs.gnu.org to comment. --8<---cut here---end--->8--- (Nit: s/Your/You/ :) I am wondering what the difference is besides the browser interface, in regards to how the submission gets logged, stored, and re-distributed. -- Regards, Bengt Richter
bug#43075: Prioritize providing substitutes for security-critical packages with potentially long build times
Hi, On +2020-09-10 11:19:11 +0200, zimoun wrote: > Hi, > > On Thu, 10 Sep 2020 at 10:01, Ludovic Courtès wrote: > > chaosmonk skribis: > > > > I don't know what Guix's CI system looks like or how packages are > > > queued for building, but if there is a way to prioritize builds for > > > certain packages, I propose that substitutes for packages like > > > ungoogled-chromium should be built as soon as possible once there is a > > > new version. Other security-critical packages with potentially long > > > build times that come to mind are icecat and linux-libre. > > > Right now we’re trying to improve build throughput in general but your > > proposal makes sense, of course. > > The recent updates of ungoogled-chromium do not mention [security > updates]. Well, I do not know if they are. So the question would be: > what triggers the special security build? > > Well, the work-in-progress [1] about some metrics of Cuirass (Guix's > CI) would provide interesting answers on the concrete feasibility and > future improvements. > > [1] http://issues.guix.gnu.org/32548#1 > > > All the best, > simon > > > Given [1]https://www.theregister.com/2020/09/04/linux_kernel_flaw_detection/ I would guess that any publicly visible coding meant to trigger special prioritized security builds would feed the process described in [1]. Maybe that's insignificant compared to scraping commit notes and patches etc, idk. HTH :) -- Regards, Bengt Richter
bug#42162: Recovering source tarballs
x01 "raptor2-2.0.15/build/ltversion.m4" 690 1414908273 5958) > > where the first element provides the “type” of list to ease the reader. > > > Well, the 2 naive questions are: does it make sense to > - have the database stored under Git? > - have an human-readable format? > > > Thank you again for pushing forward this topic. :-) > > All the best, > simon > > [1] https://forge.softwareheritage.org/T2430#47522 > > > Prefixing "X-" can obviously be used with any tentative name for anything. I am suggesting it as a counter to premature (and likely clashing) bindings of valuable names, which IMO is as bad as premature optimization :) Naming is too important to be defined by first-user flag-planting, ISTM. -- Regards, Bengt Richter
bug#42983: "sudo -E guix pull" breaks ~/.config/guix/current for regular user
Hi,
On +2020-08-22 12:27:50 +0200, Danny Milosavljevic wrote:
> Hello,
>
> Paul reported on IRC that his guix behaved strangely.
> Upon
> investigation we found that the following happens (on a Guix system), when
> logged
> in as regular user (not root):
>
> $ readlink ~/.config/guix/current
> /var/guix/profiles/per-user/dannym/current-guix
> $ sudo -E guix pull
> $ readlink ~/.config/guix/current
> /var/guix/profiles/per-user/root/current-guix
>
> You can also rm -f ~/.config/guix/current after that and do everything above
> again and it will happen again. It even happens when guix pull has nothing to
> do.
>
> That doesn't seem right. We should at least try to prevent this from
> happening,
> or warn or something.
>
ISTM it looks like a bug that should be fixed[1], urgently, not just warned
about :)
[1] eliminated from the possibility of happening :)
> The guix package manager that did that is:
>
> $ sudo -E guix describe
> Generation 64 Aug 22 2020 11:41:04(current)
> guix dad963a
> repository URL: https://git.savannah.gnu.org/git/guix.git
> branch: master
> commit: dad963a4393ea51409baa63817b26b449ed58338
> heads 50b97d4
> repository URL: https://github.com/daym/heads-guix.git
> branch: wip-musl
> commit: 50b97d446ebafd0be7a0e19d87cd236882093244
>
> $ sudo -i
> # guix describe
> Generation 64 22. August 2020 11:41:04(aktuell)
> guix dad963a
> Repository-URL: https://git.savannah.gnu.org/git/guix.git
> Branch: master
> Commit: dad963a4393ea51409baa63817b26b449ed58338
> heads 50b97d4
> Repository-URL: https://github.com/daym/heads-guix.git
> Branch: wip-musl
> Commit: 50b97d446ebafd0be7a0e19d87cd236882093244
I find it peculiar that root (sudo -i) looks like it's using swedish locale
("aktuell" is swedish for "current") with the rest of the output identical.
(Hm, maybe that's also Norwegian ;-)
If describe is describing two things that are identical end values of
readlink -f thing{1..2}, I think it would be helpful to show the thing{1..2}
profile links it's using.
BTW, what would sudo guix describe without the -E (preserving user environment)
have produced?
--
Regards,
Bengt Richter
bug#42601: Guix install bug: error: Unbound variable: ~S
Hi, On +2020-07-30 00:15:56 +0200, Ricardo Wurmus wrote: > > Jan Wielkiewicz writes: > > > Dnia 2020-07-29, o godz. 22:17:01 > > Ricardo Wurmus napisał(a): > > > >> > >> “avr-toolchain” is a procedure, not a package. Use > >> “avr-toolchain-4.9” or “avr-toolchain-5”. > >> > > > > Success! > > > > What about the strange message though? > > "incorrect package definition" would be better. > > “Unbound variable: ~S” looks like a format string with a placeholder > that didn’t get replaced with an actual value. It would be marginally > better if it said “Unbound variable: avr-toolchain”. I suspect there are also bugs lurking in the exception-reporting chain between a (throw 'exception args ...) and the ultimate format statement that produces a message with "~S" in it. Perhaps one got fixed or avoided in the upgrade? It seems like something must receive a malformed (key . args) pair where the args don't match the standard(?) tuple expected for the key. I'd look for dynamic format string generation splitting arg strings and mistakenly recomposing a format string and args for it, such that "~S" got placed in the arg list instead of string-appended into the proper final format. Just a hunch. IIRC I've seen mangling the final format string and its args wind up with a mismatch in number of args and interpolation "~s" elements and if not papered over, that gets reported as a formatting error (which it is, but which hides the real error). > > We should, I think, take advantage of the fact that the type of inputs > is known: it can only be an origin or a package value. Perhaps we can > catch unbound variables in inputs and print a more valuable error > message. I think you are right. And all implicit meta-data should be seen as potential security vulnerabilities IMO :) Who do you trust to do a reinterpret-cast for you? > > -- > Ricardo > > > -- Regards, Bengt Richter
bug#42212: Guix version rendered as 0.0-git in info manual
On +2020-07-16 02:46:00 +0200, Bengt Richter wrote:
> On +2020-07-16 03:12:37 +0530, Arun Isaac wrote:
> >
> > > The “0.0-git” string comes from (guix self). As noted there, we can’t
> > > really afford to change the version string at each commit, or we’d have
> > > to rebuild the manual at each commit.
> > >
> > > We could perhaps choose a more meaningful version string, though, maybe
> > > by looking at the closest tag or something.
> >
> > That sounds good, and `git describe` could provide us with the closest
> > tag. Unfortunately, (git) doesn't seem to be available during `guix
> > pull`. I'm trying to come up with workarounds. Do you have any ideas?
>
> What does (copied from another laptop screen by hand, typos possible ;)
> --8<---cut here---start->8---
> readlink -f
> /var/guix/profiles/per-user/{$USER,root}/current-guix/manifest|xargs grep -m1
> -A1 guix
> --8<---cut here---end--->8---
> get you? Anything useful?
>
> On my other laptop, it got me (again copied/...elided from other screen)
> --8<---cut here---start->8---
> /gnu/store/.../manifest: (("guix"
> /gnu/store/.../manifest- "87850c0"
> --
> /gnu/store/.../manifest: (("guix"
> /gnu/store/.../manifest- "0.16.0"
> --8<---cut here---end--->8---
>
> You can see that's ancient, so IDK if the same command will work for you.
> "guix -V" there still shows 0.16.0 (which version should that show, BTW?)
>
> I don't know how these versions correspond to what pull creates,
> but zimoun is a whiz on that stuff, so maybe he will chime in :)
> (I Cc'd him to raise the probability :)
Sorry, I seem not to have succeeded with the Cc: to zimoun
Or it's been scrubbed out of the headers.
Ah, do I faintly remember that one needs a special incantation?
Sorry, I will look into it.
>
> HTH
> --
> Regards,
> Bengt Richter
>
>
>
--
Regards,
Bengt Richter
bug#42212: Guix version rendered as 0.0-git in info manual
On +2020-07-16 03:12:37 +0530, Arun Isaac wrote:
>
> > The “0.0-git” string comes from (guix self). As noted there, we can’t
> > really afford to change the version string at each commit, or we’d have
> > to rebuild the manual at each commit.
> >
> > We could perhaps choose a more meaningful version string, though, maybe
> > by looking at the closest tag or something.
>
> That sounds good, and `git describe` could provide us with the closest
> tag. Unfortunately, (git) doesn't seem to be available during `guix
> pull`. I'm trying to come up with workarounds. Do you have any ideas?
What does (copied from another laptop screen by hand, typos possible ;)
--8<---cut here---start->8---
readlink -f
/var/guix/profiles/per-user/{$USER,root}/current-guix/manifest|xargs grep -m1
-A1 guix
--8<---cut here---end--->8---
get you? Anything useful?
On my other laptop, it got me (again copied/...elided from other screen)
--8<---cut here---start->8---
/gnu/store/.../manifest: (("guix"
/gnu/store/.../manifest- "87850c0"
--
/gnu/store/.../manifest: (("guix"
/gnu/store/.../manifest- "0.16.0"
--8<---cut here---end--->8---
You can see that's ancient, so IDK if the same command will work for you.
"guix -V" there still shows 0.16.0 (which version should that show, BTW?)
I don't know how these versions correspond to what pull creates,
but zimoun is a whiz on that stuff, so maybe he will chime in :)
(I Cc'd him to raise the probability :)
HTH
--
Regards,
Bengt Richter
bug#42247: Channel news raise error on `guix pull`
On +2020-07-13 12:27:39 +0200, Ludovic Courtès wrote: > Hi, > > Pierre Neidhardt skribis: > > > Ludovic Courtès writes: > > > >> This suggests that the ‘news.scm’ file of your channel is being picked > >> up and evaluated as if it were a module, which it’s not. > >> > >> The solution is to rename it to, say, ‘news.txt’, or to move the actual > >> modules to a sub-directory and specify that in ‘.guix-channel’ (info > >> "(guix) Channels"). > > > > Thanks for the hint, this works indeed! > > > > 1. Is there anything we can do to catch this error and output a more > > intelligible error message? > > I don’t think so: Guile is just doing its job and picking up .scm > files. > You are not saying that a file extension is used as hard type data when "Guile is just doing its job ..." are you?? (unless the producer of the filename is contracted to guarantee the extension semantics in guile's environment at the run-time in question ... but where is such policy documented, if so? (I don't mean looking for .go files newer than corresponding .scm, etc)) > > 2. I suggest we document this pitfall in the documentation. > > Yup, makes sense; would you like to send a patch? > > Thanks, > Ludo’. > > > -- Regards, Bengt Richter
bug#42291: data service: Show list of files and allow qeuerying
Hi On +2020-07-09 11:25:05 +0200, zimoun wrote: > Dear, > > +Pierre because I am not sure he reads carefully debuugs. ;-) > > On Thu, 09 Jul 2020 at 10:13, Hartmut Goebel > wrote: > > Serverity: wishlist > > I often find myself checking the content of a package. For this I > > would like to be able to inspect the list of files in a package, or > > even query for a specific file. > > Pierre proposed "guix filesearch" some time ago. > > https://lists.gnu.org/archive/html/guix-devel/2019-03/msg00236.html > > > > This is much like Debian does in "list of files" for each package (e.g. > > <https://packages.debian.org/en/buster/amd64/ejabberd-mod-cron/filelist>) > > and with "Search the contents of packages" > > <https://www.debian.org/distrib/packages#search_contents> > > Yes, it could be nice to have that in the Data Service. > Since this is about listing files, seems like it wouldn't be that hard to provide a file globbing selection option like find dir -iname globexpr (pass through to find itself?) (hm, also -newerct timespec can be a handy find opt) and/or output control like "stat -c 'formatstring'" (likewise pass through to stat) ? Also, ls-borrowed options like -B -1 -d -A might be nice. If you want to consider the general problem of inspecting arbitrary object component details, lsblk -o,selected,fields,listed,here might be a good model (including -n option). I think it would be nice if all object detail listing functions would converge in design to a few consistent ways of specifying source and output options, so we wouldn't have to re-invent "$(foo -dumpalot|sed -E ad_hoc_hack)" so much. Are there any system design guidelines for converging? BTW, please preserve cli and info retrieval independence from GUI systems, (except when GUI preferences and parameters are the objects being inspected, of course, but even then, minimize entanglements :) > > All the best, > simon > > > -- Regards, Bengt Richter
bug#42252: Not possible to reliably port forward with "guix system vm" anymore
Hi On +2020-07-07 16:40:21 -0400, Christopher Lemmer Webber wrote: > In commit 5379392731b52eef22b4936637eb592b93e04318, the following change > was introduced: > > modified gnu/system/vm.scm > @@ -941,6 +941,7 @@ with '-virtfs' options for the host file systems listed > in SHARED-FS." >'()) > > "-no-reboot" > + "-nic" "user,model=virtio-net-pci" > "-object" "rng-random,filename=/dev/urandom,id=guixsd-vm-rng" > "-device" "virtio-rng-pci,rng=guixsd-vm-rng" > > Unfortunately, this means that in our docs where we suggest doing the > following: > > `guix system vm config.scm` -nic > user,model=virtio-net-pci,hostfwd=tcp::10022-:22 > > Since we now provide our own similar "-nic" field this creates a > *second* network interface at the same address and there is a race as in > terms of which handles connections. Depending on the race result, > connections to the forwarded port may hang indefinitely. > > Ironically, this regression was introduced to solve another regression! > From the commit message: > > This fixes a regression introduced in > 8e53fe2b91d2776bc1529e7b34967c8f1d9edc32 > where 'guix system vm' would no longer be using virtio. > This reminds a bit of doctors prescribing powerful medicine with side-effect so bad that they have to prescribe a medicine for that, which in turn has side-effects, in what I think is called prescription cascading, and people wind up on 25 pills a day. "First, do no harm." :) I wouldn't say anything, except ISTM your fix on top of a fix is not the first to remind me of cascading :) > What's the right solution? One could be that "guix system vm" itself > could take an argument that sets up port forwarding in the generated > shell script. Eg: > > guix system vm config.scm --hostfwd=tcp::10022-:22 --hostfwd=tcp::-:80 > > kind of ugly, but it could work. WDYT? > > - Chris > > > I'm not saying your solution is bad, I'm just saying cascading fixes may be a symptom to diagnose, in case it indicates something like bad mutations involving bad genes that will compromise the health of the guix ecology. How is a "fix" judged with respect to the big picture? Is there a higher level layered[1] design for the use of guix, like e.g. [2] which a proposed fix might violate and therefore should be rejected, even though it makes something "work"? Well, it's probably in an old paper by Ludo in some form, but I wonder what concepts of layering guix developers are consciously using when putting stuff between the declarations at the top and the images at the bottom. [1] https://en.wikipedia.org/wiki/Abstraction_layer [2] https://en.wikipedia.org/wiki/OSI_model -- Regards, Bengt Richter
bug#42047: [PATCH 3/3] guix: gc: Support for the Hurd.
On +2020-06-25 22:48:43 +0200, Ludovic Courtès wrote: > "Jan (janneke) Nieuwenhuizen" skribis: > > > * guix/store/roots.scm (proc-environ-roots): Handle EIO, for the Hurd. > > * gnu/build/hurd-boot.scm (set-hurd-device-translators): Mount /proc. Add > > symlink to /etc/mtab. Remove duplicate calls to 'scope'. > > Nitpick: I see 3 mostly unrelated patches: (1) fix duplicate called to > ‘scope’, (2) mount /proc, and (3) handle EIO. I think it’s clearer to > view them separately. > > (1) and (2) LGTM! > > > - (mkdir* (scope "dev/vcs/1")) > > - (mkdir* (scope "dev/vcs/2")) > > - (mkdir* (scope "dev/vcs/2")) > > Was it creating like /some/root/some/root/dev/vcs/1? > > >(append-map rhs-file-names > > - (split-on-nul > > - (call-with-input-file environ > > - get-string-all > > + (catch 'system-error > > +(lambda _ > > + (split-on-nul > > + (call-with-input-file environ > > + get-string-all))) > > +(lambda args > > + (if (= EIO (system-error-errno args)) > > + '() > > + (apply throw args)) > > This may be papering over a real problem. Before doing that, I think I fear paperings-over ;) Would this idea be worth implementing?: To make sure a "papering over" does not remain un-noticed in an executable, create a catch-wrapping macro that would generate code acting like catch but before entering catch, start emitting complaint messages on and after a calendar date, e.g. checked with (> (car (gettimeofday)) *macro-produced-date-constant*) E.g., something to use in place of catch, like (borrowing above for example) (catch-with-sunset "date-string" "complaint-message" 'system-error (lambda _ (split-on-nul ...etc... (apply throw args "complaint-message" could obviously contain bug#number, commit id, or plea for report, etc. (gettimeofday) on my machine is about 50ns (i.e., often get 20 equal values within the microsecond resolution), so there shouldn't be a performance hit ;) > “we” :-) should investigate why procfs returns EIO in some cases and > look into fixing it. > > Then maybe we can still have the ‘catch’ above, but this time as a > temporary measure and with a reference to the upstream issue/commit. > > WDYT? > > Thank you! > > Ludo’. > > > -- Regards, Bengt Richter
bug#42002: Bug: Signal kill during build
Hi all, On +2020-06-23 08:57:52 +0300, Efraim Flashner wrote: > On Tue, Jun 23, 2020 at 03:38:39AM +0300, Bonface M. K. wrote: > > Léon Lain Delysid writes: > > > > > Oh! Yes, of course, I see! > > > Yes, those little credit card sized one-chip computers are very low on > > > resources. > > > So I think it shouldn't build the programs itself but rather download the > > > binaries everytime I "guix pull". What command line > > > option should I use to only download the binaries instead of building > > > everything myself? Could you please give me the command? > > > > > You could try: `guix pull --substitute-urls="https://berlin.guixsd.org > > https://ci.guix.gnu.org https://mirror.hydra.gnu.org"`. Since you are on > > Debian, you should authorize the servers. More of the authorization > > here: > > https://guix.gnu.org/manual/en/html_node/Substitute-Server-Authorization.html. > > You could always dry-run your commands to see if the substitutes work. > > Actually, berlin.guixsd.org and ci.guix.gnu.org are the same server, and > mirror.hydra.gnu.org was decommissioned a while ago. The second server > for substitutes is https://bayfront.guix.gnu.org. > If one has a powerful-enough pc or laptop on local ethernet, is there a package that would set up a local user as simple builder-server that the pi could download binary substitutes from? Such a local server might have other uses as well, if browser-friendly :) I'm sure you don't need help imagining that :) > I think the best option would be to make sure you run 'guix pull' > targeting a derivation which has substitutes. If you check here¹ you can > see if there's a substitute already available for armhf-linux and run > 'guix pull --commit=the-commit-listed-in-the-link'. Right now, that > would be 42a2ee1f9294614bd85892f2cc7318afb80b174c, which is actually the > latest commit. > > ¹ https://ci.guix.gnu.org/jobset/guix-modular-master > > > > > > On Mon, Jun 22, 2020, 14:47 Efraim Flashner wrote: > > > > > > On Mon, Jun 22, 2020 at 02:28:33PM +0200, Léon Lain Delysid wrote: > > > > Hello! I'm having a problem on a Banana Pi M3 that runs Debian 10 > > > Buster > > > > (ARM like instruction set). > > > > "guix pull" always results in failure with this message: > > > > [...] > > > > > > > > What can I do? Some help would be much appreciated. Thanks! > > > > > > > > Best regards, > > > > Léon > > > > > > The signal 9 (killed) makes me think a C++ program killed. I checked > > > wikipedia and it says the Banana Pi M3 has 2GB of RAM. Was there > > > anything else running at the time? 'guix pull' can be resource > > > intensive, especially on lower powered machines. > > > > > > -- > > > Efraim Flashner אפרים פלשנר > > > GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 > > > Confidentiality cannot be guaranteed on emails sent or received > > > unencrypted > > > > -- > > Bonface M. K. (https://www.bonfacemunyoki.com) > > One Divine Emacs To Rule Them All > > GPG key = D4F09EB110177E03C28E2FE1F5BBAE1E0392253F > Above sig reminds me: BTW: if your Divine Emacs, like mine on debian-based distro , has recently been disrupted by Alt-Shift, (probably because you have two kbd languages and emacs Alt '<' is Alt-Shift-comma on your en kbd) stack-overflow had the recipe that worked for me. tl;dr in snip: disabling alt-shift toggling of us/sv .. read old value, write new value, read new value to check: --8<---cut here---start->8--- dconf read /org/gnome/desktop/input-sources/xkb-options ['grp:alt_shift_toggle', 'grp_led:scroll'] dconf write /org/gnome/desktop/input-sources/xkb-options "['grp_led:scroll']" dconf read /org/gnome/desktop/input-sources/xkb-options ['grp_led:scroll'] --8<---cut here---end--->8--- Please excuse the off-topic BTW, but that bug cost me a lot of time, so I hope that's useful to someone. Meta-question: how should one offer hints like this so we can find them easily? Seems like we need browsable open-gis/open-streetmap to map the ux territory and its potholes ;) > -- > Efraim Flashner אפרים פלשנר > GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 > Confidentiality cannot be guaranteed on emails sent or received unencrypted -- Regards, Bengt Richter
bug#41878: Handshake Error
Hi, On +2020-06-16 10:07:51 +0200, Ludovic Courtès wrote: > Hi, > > Quinten Gruenthal skribis: > > > Sure; though, as I mentioned before I did try again and it did work. Doing > > a pull once more I failed with: > > > > guix substitute: error: TLS error in procedure 'handshake': Error in the > > pull function. > > substitution of > > /gnu/store/k1da7bv579d8gvwdrakd9l4hxswknff2-guix-module-union failed > > guix pull: error: some substitutes for the outputs of derivation > > `/gnu/store/k2gdq7ahjaqmdgjr9xwywqpxvzazn467-guix-e07573432.drv' failed > > (usually happens due to networking issues); try `--fallback' to build > > derivation from source > > Could it be that you’re on a flaky network connection? > > > As with before, I was also able to succeed on a subsequent pull; but this > > error seemed to be handled better as it suggested both the cause of the > > problem and a possible solution. > > If the connection is dropped, there’s little we can do, but maybe you’re > suggesting better error reporting? Hm, are gexp's checkpointable? Some ftp can reconnect and continue, IUUC. Idk how that works with https. Can one adjust timeouts? Continue on an alternate mirror? E.g. for downloading substitutes? In general, I hate it when I get 1.0GB through a 1.1GB ISO and lose it all, esp when I pay by GBs. Can guix help? :) BTW, I think I have heard of security risks in restarting, but perhaps with end-to-end integrity checks it is not an issue despite poss MM trying? > > Thanks, > Ludo’. > > PS: Please keep the bug Cc’d. > > > -- Regards, Bengt Richter
bug#41669: Cross-compiled powerpc64-linux bootstrap-tarballs not reproducible
Hi Chris, et al, On +2020-06-09 23:15:01 -0700, Chris Marusich wrote: > Hi Vincent and everyone, > > Vincent Legoll writes: > > > Is that showing the same (or a similar) problem : > > > > https://data.guix-patches.cbaines.net/gnu/store/0lcbxpw1vrca02dzpzw2rxhad7pn4zw7-gcc-objc-5.5.0 > > > > ? > > Can you clarify what you mean? I'm not sure what you're referring to. > > Chris Marusich writes: > > > At present, it seems possible that within the context of a single > > machine, gcc-stripped-tarball-5.5.0.drv builds reproducibly, but on a > > different machine, it may (reproducibly) build a different output. > > I'm a bit paranoid about making mistakes, so I'll perform another full > > GC and then try yet again to build gcc-stripped-tarball-5.5.0.drv in > > order to verify whether it truly produces the same output when all (or > > nearly all) of its inputs are rebuilt from scratch. > > I repeated the experiment on the same machine (it took a day or two to > build), and the result was the same: on my machine, > gcc-stripped-tarball-5.5.0.drv builds identical output to what it built > before. To be clear, using Guix 8159ce1970d91567468cf1bacac313099a009d2a > on an x86_64-linux machine, I tried (yet again) the following steps: > [...] > Efraim's diff looks a little different in statx.h, even though he used > the same Guix commit as me. Maybe this is because he cross-compiled on > an aarch64-linux machine, while I cross-compiled on an x86_64-linux > machine. In the other cases, it looks like the binary files differ in > basically the same ways. I will share some examples below. > > Here is some diffoscope output between my c++ and Efraim's (many other > sections also differed in similarly cryptic ways): > [...] > > If I'm reading this correctly, one problem seems to be that our GCC > toolchains are putting symbols at different locations. This issue (and > maybe others) could be trickling down, causing other aspects of the > binaries to differ (e.g., in length). Nothing really stands out, but > when we discussed this on IRC, we thought perhaps factors like the > following might contribute to the non-reproducibility: > > - Perhaps we are all running different Linux kernel versions? In some > cases, the kernel version can unfortunately influence the build > output, so this might be worth testing. > > - Perhaps the GCC Makefiles etc. are doing something non-deterministic? > Questions triggered in my mind: Where are respective machines getting their rules for packing and aligning structs and unions? Is any struct or rule/flags source dynamically generated, where different rules could come from different defaults, or .configs, or even invalid memoizations jumping domains? Could pointer arithmetic get done in one domain and the offset be misused in another? Wrong C preprocessor? Difference in sort key comparisons for canonicalization of ordering? Hope that's not all red herrings :) Sorry for the noise otherwise. > - Something else? Hm, some race condition between processes that should be order-independent but are not. Then if different hardware components on different systems -- disks, memory, processors -- cause different but repeatable patterns of waits (convoying?) you could get repeatable but different builds. I guess you'd have to figure out which order was really right, and force the order of processing explicitly to that order, so all systems would do it that way. > > Avenues of investigation: > > - If anything obvious stands out from the diffoscope output, please > leave a comment. > > - Try building with different kernel versions on the same machine, to > see if they differ. > > - If somebody else could please confirm that running the following > command reports no difference on their own machine (i.e., exit code > 0), that would be good to know, since it would help further solidify > the theory that on a single machine, the build of gcc-static-5.5.0.drv > is reproducible, even if it is not reproducible across machines: > > guix build --no-substitutes --check --target=powerpc64-linux-gnu \ >-e '(@@ (gnu packages make-bootstrap) %gcc-static)' > > - Try building two different versions of gcc-7.5.0 (maybe by hand?), and > then use them to build a simple reproduction case and compare results. > If we're lucky, maybe this will help us understand the problem better. > > We'll get there! > > -- > Chris -- Regards, Bengt Richter
bug#41780: UEFI bios not supported out of the box when burning to usb stick
On +2020-06-10 03:47:20 +0200, Tobias Geerinckx-Rice via Bug reports for GNU Guix wrote: > Welcome, Romulasry, > > romulasry via Bug reports for GNU Guix 写道： > > This would be a nice feature to have in the future when all there will maybe not all [1][2] :) -- though GPT improves on MBR IMO, but you don't absolutely need UEFI BIOS code to parse that. The part, well one part :), I'm not clear on is format compatibility for data stored in BIOS nvram -- e.g. efibootmgr/UEFI vs coreboot fs (CBFS) > > be is UEFI (bioses). > > UEFI is already supported. > Wondering, is coreboot[1] on anyone's radar in guix-land? [1] https://www.coreboot.org/ [2] https://puri.sm/coreboot/ > Is this the latest Guix version (1.1.0)? What kind of machine did you try > it on, and which error (if any) did you get? Does the same installer boot > and run fine when booted in CSM (‘legacy’) mode? Could you try a different > model of USB drive (this once ‘solved’ it for me)? > > Kind regards, > > T G-R -- Regards, Bengt Richter
bug#41760: ganv-1.5.4 fails at configure
Hi Marius, On +2020-06-09 20:51:27 +0200, Marius Bakke wrote: > Thorsten Wilms writes: > > > On Mon, 08 Jun 2020 20:12:54 +0200 > > Marius Bakke wrote: > > > >> ganv was updated to 1.6.0 a while back. Do you get the same failure > >> after a 'guix pull'? > > > > That was after ‘guix pull’. ‘ganv’ is pulled in via ‘ingen’ here. > > > > ``` > > build of > > /gnu/store/bxz04gap29dxsmjvb3z4hjdid9l1fil7-ganv-1.5.4-1.12f7d6b04.drv > > failed > > View build log at > > '/var/log/guix/drvs/bx/z04gap29dxsmjvb3z4hjdid9l1fil7-ganv-1.5.4-1.12f7d6b04.drv.bz2'. > > substituting /gnu/store/8vgp4lv6k16ffq5zhfsjdqb2mpxa5642-aubio-0.4.9... > > |guix package: error: build of > > `/gnu/store/ahx77sfl5zxgs37vx1g445czp7scrqp1-ingen-0.0.0-2.cc4a4db33.drv' > > failed > > ``` > > Oh, I see. Probably the special 'ganv-devel' input of 'ingen' is > obsolete with the recent 'ganv' update. Difficult to tell because there > are no comments about it, but I went ahead and removed it in The name 'ingen' is perhaps a kind of comment? (in Swedish[1] :) (Svenska) ingen pronomen, (Engelska) no one, none, nobody, nothing, noone [1] http://folkets-lexikon.csc.kth.se/folkets/folkets.html > c178d5fa5a2cfc07f4a9ab9cadeb6218d6c6483. Let's see if anyone complains! > > Forgot to mention the bug report in the commit message though :-/ > > Thanks, > Marius -- Regards, Bengt Richter
bug#41602: texlive-texmf is actually subtitutable
On +2020-05-29 17:15:40 +0200, Ludovic Courtès wrote:
> Strangely, ‘texlive-texmf’ (the big one) is substitutable:
>
> --8<---cut here---start->8---
> $ guix describe
> Generacio 145 May 25 2020 00:37:58(nuna)
> guix 9744cc7
> repository URL: https://git.savannah.gnu.org/git/guix.git
> branch: master
> commit: 9744cc7b4636fafb772c94adb8f05961b5b39f16
> $ guix environment --ad-hoc texlive -- texdoc biblatex
> 2.6 MB will be downloaded:
>/gnu/store/7ji4l3szj68b0r5w10bvvdx1vy6nhz5p-subversion-1.10.6
> downloading from
> https://ci.guix.gnu.org/nar/lzip/7ji4l3szj68b0r5w10bvvdx1vy6nhz5p-subversion-1.10.6
> ...
> subversion-1.10.6 2.5MiB
>
> 7.2MiB/s 00:00 [##] 100.0%
>
> La jena derivo estos konstruata:
>/gnu/store/55yx02hr0dz47px1aj0j14xll3bsrmml-texlive-texmf-20190410.drv
> 2,845.8 MB will be downloaded:
>/gnu/store/nm6w84c9zj3yiylal3dk1sqzxq11sjzw-texlive-20190410-texmf.tar.xz
>/gnu/store/xpkl70g3bls935h1zdlq7sn2j6rccp3k-texlive-20190410
> downloading from
> https://ci.guix.gnu.org/nar/lzip/z4xvgiliw5baf1pr4z03c7n2hw3bm5x5-texlive-texmf-20190410
> ...
> texlive-texmf-20190410 2.61GiB
> --8<---cut here---end--->8---
>
> The info suggests it won’t be substituted, but it’s eventually
> substituted. I wonder why, because the .drv has:
>
> ("allowSubstitutes","0")
>
> and the daemon has:
>
> bool substitutesAllowed(const Derivation & drv)
> {
> return get(drv.env, "allowSubstitutes", "1") == "1";
> }
>
> and:
>
> if (settings.useSubstitutes && substitutesAllowed(drv))
> foreach (PathSet::iterator, i, invalidOutputs)
> addWaitee(worker.makeSubstitutionGoal(*i, buildMode == bmRepair));
>
> Thoughts?
This is the kind of "wonder why" that makes me wonder about trojan horse bug
fixes
as described in [1], which is a really interesting and scary read, especially
since [1]
could very conceivably be an example of what it itself is talking about (though
they
don't sound malicious, so I can hope trusting okular to display it was not
giving
them a pdf or image parser to exploit with malice).
Anyway, please note that the "pdf" file starts with these lines:
--8<---cut here---start->8---
# I'm a shell script :-) so please make me executable!
# No shebang but I work equally well with Bash, Dash and Zsh
# The script embeds link-grammar, a x86-64 ELF so it requires to be run on a
x86-64 linux system
--8<---cut here---end--->8---
What looks like the beginning of a normal pdf file starts at line 30 counting
from 1 as first line.
okular will display the original as if it were pdf (bug??) though "file" just
sees it as "data."
Trim off the first 29 lines and file sees it as pdf, and pdfinfo will find its
way too.
Idk, you might want at least to cut out the first 29 lines before looking at it
with e.g. okular,
(which I trustingly used to open the file): note that okular got past the
29-line script part, (which
is a bit promiscuous for my taste), and displayed the pdf.
It was really interesting, esp the sections around
--8<---cut here---start->8---
3
Deniable Backdoors Using Compiler Bugs
by Scott Bauer, Pascal Cuoq, and John Regehr
--8<---cut here---end------->8---
Maybe you can view it in a sandbox :) But don't blame me if you don't.
YOU WERE WARNED.
So read it -- and wonder what might come with a mysterious substitute ;-P
[1] https://www.alchemistowl.org/pocorgtfo/pocorgtfo08.pdf
>
> Ludo’.
>
>
>
--
Regards,
Bengt Richter
bug#41387: "Building from Git" on foreign distro starting with NO guix?
Hi Julien, On +2020-05-19 08:03:37 -0400, Julien Lepiller wrote: > Le 18 mai 2020 23:07:42 GMT-04:00, Bengt Richter a écrit : > >Hi, > > > >[~/wb/guix110git/guix]$ ./configure --prefix=$(realpath ./mybuild) > >checking for a BSD-compatible install... /usr/bin/install -c > >checking whether build environment is sane... yes > >... > >... > >checking pkg-config is at least version 0.9.0... yes > >configure: checking for guile 3.0 > >configure: checking for guile 2.2 > >configure: found guile 2.2 > >checking for guile-2.2... /usr/bin/guile-2.2 > >checking for Guile version >= 2.2... 2.2.4 > >checking for guild-2.2... /usr/bin/guild-2.2 > >checking for guile-config-2.2... /usr/bin/guile-config-2.2 > >checking for GUILE... yes > >checking if (gnutls) is available... no > >configure: error: The Guile bindings of GnuTLS are missing; please > >install them. > >--8<---cut here---end--->8--- > > > >Well, it was looking for guile 3.0 and my foreign distro only has 2.2.4 > >--8<---cut here---start->8--- > >guile (GNU Guile) 2.2.4 > >Packaged by Debian (2.2.4-deb+1-2) > >Copyright (C) 2018 Free Software Foundation, Inc. > >--8<---cut here---end--->8--- > >which it seemed ok with, but I don't seem to be able get my distro's > >GnuTLS > >hooked up with this installation procedure, and suspect a GnuTLS/Guile > >version > >mismatch problem or such, but then I ran out of enthusiasm :) > > As you can see, configure looks for guile 3.0, fails and falls back to guile > 2.2, which it finds as /usr/bin/guile-2.2. > > Gnutls provides guile bindings, but they are not necessarily built by your > distribution. From my experiments with debian/hurd, the bindings were not > present, so probably the same with debian/linux? You'll probably have to > checkout gnutls and build the bindings. > > The configure script only checks that the guile it found (your 2.2) can load > the (gnutls) module, so there cannot be a version mismatch, unless debian > built the gnutls module with guile 3.0. Check with your distribution what > files are installed with the gnutls package. There should be some in > /usr/lib/guile/. > > You'll need to look at the dependencies, some of them are probably not > provided by debian yet. I remember some discussions about creating a debian > package of guix. If this was accepted, then the dependencies must be > available at least in unstable. You might want to check. > Thanks for your tips! I also went on to read Pjotr Prins' extensive notes on installing [1]. Looks like he can say "Been there, done that" re most install travails, and IIUC he recommends against "Building from Git" as step 1, advising to use a binary install first, and then use guix tools to hack further in a full repo. BTW, he suggests a recursive clone, but I didn't see what that really does or entails. Not sure I want to download the entire history of all development branches of guix, if that's what it means :) (re that: it would be nice to see an approximate download size when advice to download appears in docs, for those who pay for GBs ;-) Perhaps 14.1 in the docs should be updated with a reference to [1] and to suggest (emphatically?) there in 14.1 (as it does elsewhere) that the easier path will be to do a binary install first? And also un-mix directions for the two kinds of install activities! Leading people into frustrating experiences can't be good PR for guix. Cui bono? Anyway, I think I'll give up on Building from Git for now, and go back to monkeying with guix-install.sh (making it incrementally restartable to avoid re-downloading etc. and seeing how far I can factor out root both in the script and the resulting guix daemonium) :) [1] https://gitlab.com/pjotrp/guix-notes/-/blob/master/INSTALL.org Thanks again. -- Regards, Bengt Richter
bug#41387: "Building from Git" on foreign distro starting with NO guix?
>8--- Then, run ./configure as usual. Make sure to pass --localstatedir=directory where directory is the localstatedir value used by your current installation (see The Store, for information about this). We recommend to use the value /var. --8<---cut here---end--->8--- My "current installation" ?? I don't have one yet ;-( Ok, run ./configure in any case: I decided to make a test directory for --prefix Fumbled the absolute directory, but then it ran ... --8<---cut here---start->8--- [~/wb/guix110git/guix]$ mkdir -p mybuild/var [~/wb/guix110git/guix]$ ./configure --prefix=./mybuild configure: error: expected an absolute directory name for --prefix: ./mybuild [~/wb/guix110git/guix]$ ./configure --prefix=$(realpath ./mybuild) checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes ... ... checking pkg-config is at least version 0.9.0... yes configure: checking for guile 3.0 configure: checking for guile 2.2 configure: found guile 2.2 checking for guile-2.2... /usr/bin/guile-2.2 checking for Guile version >= 2.2... 2.2.4 checking for guild-2.2... /usr/bin/guild-2.2 checking for guile-config-2.2... /usr/bin/guile-config-2.2 checking for GUILE... yes checking if (gnutls) is available... no configure: error: The Guile bindings of GnuTLS are missing; please install them. --8<---cut here---end--->8--- Well, it was looking for guile 3.0 and my foreign distro only has 2.2.4 --8<---cut here---start->8--- guile (GNU Guile) 2.2.4 Packaged by Debian (2.2.4-deb+1-2) Copyright (C) 2018 Free Software Foundation, Inc. --8<---cut here---end--->8--- which it seemed ok with, but I don't seem to be able get my distro's GnuTLS hooked up with this installation procedure, and suspect a GnuTLS/Guile version mismatch problem or such, but then I ran out of enthusiasm :) Debian's packages on my system matching tls are: [~/bs]$ dpkg -l '*tls*' --8<---cut here---start->8--- Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ NameVersion Architecture Description +++-===---= un exim-tls (no description available) ii gnutls-bin 3.6.7-4+deb10u3 amd64GNU TLS library - commandline utilities ii gnutls-doc 3.6.7-4+deb10u3 all GNU TLS library - documentation and examples ii libcurl3-gnutls:amd64 7.64.0-4+deb10u1 amd64easy-to-use client-side URL transfer library (GnuTLS flavour) un libcurl4-gnutls-dev (no description available) ii libgnutls-dane0:amd64 3.6.7-4+deb10u3 amd64GNU TLS library - DANE security support ii libgnutls30:amd64 3.6.7-4+deb10u3 amd64GNU TLS library - main runtime library ii libneon27-gnutls:amd64 0.30.2-3 amd64HTTP and WebDAV client library (GnuTLS enabled) ii libxmlsec1-gnutls:amd64 1.2.27-2 amd64Gnutls engine for the XML security library un rsyslog-gnutls(no description available) --8<---cut here---end--->8--- I thought maybe I could cheat and find a path into the cloned repo, since all the magic has to be there somehow, but that way seems pretty kludgey. Any help past this GnuTLS obstacle is welcome! BTW, could I check out at a commit prior to the guile3 introduction so that my distro might have a matching GnuTLS for that? If so, which commit would be best? In the meanwhile, back to hacking guix-install.sh :) Thanks for reading. -- Regards, Bengt Richter
bug#41266: Suggested command to import key does not work on debian
Hi, On +2020-05-17 21:25:54 +0200, Julien Lepiller wrote: > Le Thu, 14 May 2020 12:28:11 -0400, > Julien Lepiller a écrit : > > > Hi, > > > > I just installed a debian VM to test changes in the install script > > and found this issue when running the installer script: > > > > First it fails because it cannot find the public key and suggests > > running: > > > > wget … -q0 - | gpg --import > > > > -q0 does not work with debian's wget, but -O works. > > > > Aftcr importing the key, the script still complains it cannot find > > it. Re-running the same command with "sudo" in front of the gpg > > import command re-imports the key and the script is then able to find > > it. > > > > My guess is that the first import imported the key in my user's > > keyring, but the script looks in root's keyring. The second attempt > > added the key to root's keyring. > > > > Forget the wget thing, it's my fault for not reading it properly. The > gpg command still needs to be run with sudo on at least fedora and > debian. > > > If the problem is actually expired keys vs nonexistent, gpg --refresh-keys might be worth trying. -- Regards, Bengt Richter
bug#41132: [core-updates]: Fonts not working on foreign distro (Debian)
Hi Leo, On +2020-05-08 18:52:41 -0400, Leo Famulari wrote: > On Sat, May 09, 2020 at 12:18:46AM +0200, Bengt Richter wrote: > > Didn't I just see a permissions-related bug reminiscent of this go by a > > short while ago? > > Could it be related? Do the dir/file perms look normal? > > Upthread, Tobias pointed out that fc-cache didn't have permissions for > /var/cache/fontconfig, but deleting that didn't seem to make a > difference. Could that be what you were thinking about? No, I think it was about a deferred build action created as root and bits needed for later phase or context, as non-root, were inaccessible. Sorry for the noise. -- Regards, Bengt Richter
bug#41132: [core-updates]: Fonts not working on foreign distro (Debian)
Hi Leo, et al, On +2020-05-08 14:08:51 -0400, Leo Famulari wrote: > On Fri, May 08, 2020 at 10:59:46AM +0200, Marius Bakke wrote: > > Just to be clear, these programs are able to find fonts you have > > installed through Guix, right? > > They can find the font packages I install with Guix, but not the > hard-coded PostScript fonts. > > > > The specific fonts in question are the URW fonts, aka the "PostScript > > > fonts", provided by Debian's gsfonts and gsfonts-x11 packages. > > > > Are those the only affected fonts? > > I looked more closely, and Guix applications can no longer see *any* > fonts from Debian. > > > > $ fc-cache -rv > > > > [...] > > > > > /home/leo/.local/share/fonts: caching, new cache contents: 0 fonts, 0 dirs > > > /home/leo/.local/share/fonts: failed to write cache > > > > [...] > > > > > /home/leo/.fonts: caching, new cache contents: 0 fonts, 0 dirs > > > /home/leo/.fonts: failed to write cache > > > > [...] > > > > > fc-cache: failed > > > > FWIW the new fc-cache fails for me on Guix System too if I create these > > empty directories. > > Confirmed. fc-cache exited successfully when I removed those directories. > > > Can you inspect 'fc-list ' with the new and old fontconfig? Are there > > differences? > > The only differences, after running `fc-cache -rfv`, are the differing > store paths of the hard-coded gs-fonts package. > > Another thing I noticed is that I can do `fc-cache -rfv /usr/share/fonts > && fc-list`, and the hundreds of fonts found in that directory are *not > shown* in fc-list, but that's the same as on the master branch. > > So, I'm still not sure what the difference is. Didn't I just see a permissions-related bug reminiscent of this go by a short while ago? Could it be related? Do the dir/file perms look normal? -- Regards, Bengt Richter
bug#40790: OOM error in graphical installer tests.
Hi Ludo, et al, On +2020-04-30 23:10:05 +0200, Ludovic Courtès wrote: [...] rc1: best-practice: commit logs: message syntax --8<---cut here---start->8--- > Nitpick: please include the canonical bug URL in commit logs rather > than a link to the mailing list, like so: > > Fixes <https://bugs.gnu.org/40790>. > > That makes it easier to grep for fixed bugs. --8<---cut here---end--->8--- ISTM your "nit-pick" is a good example of an embedded mail-list nugget. Here's my wish: If you and other developers notice (without false modesty ;-) that you are posting a good example of something, then if you would enclose it in guix snippet-delimiters as above, with a single prefixed line starting with "primary-focus-subject:" and optionally followed by other greppable (or list-matchable) sub-categories or ad-hoc words or names or tags, then these nuggets would be easy to extract automatically, to create a treasure-trove of searchable useful goodies. I would hope to see useful one-liners and examples of package definition, system configs, debugging methods, small scripts, and good info-URLs etc. delimited and prefixed. (The "primary-focus-subject:" of "rc1:" would permit us to invent improved syntaxes and evolve them as "rc2" etc until we settle on a canonical set for primary foci, (and PEG grammar for the rest, if we want to get fancy). Perhaps the servers could have a gem-and-nugget-bot authoring an html blog of these things, with automatic attibutions etc from email headers? -- Regards, Bengt Richter
bug#40977: --load-path does not honor ~
On +2020-04-30 22:54:47 +0200, zimoun wrote: > Hi Tobias, > > On Thu, 30 Apr 2020 at 21:20, Tobias Geerinckx-Rice wrote: > > > > Hartmut, Zimoun, > > > > Hartmut Goebel 写道： > > > After processing options, guix need to "expanduser()" (as it is > > > called > > > in Python) on all arguments which are paths. > > > > If any Python (or other) software does this, it's broken. File a > > bug there. > > > > This is the wrong thing to do and makes the GNU system an > > inconsistent mess. …OK, *more* of an inconsistent, loveable, mess > > ;-) > > > > It also makes > > > > $ sudo guix system --load-path=~/path/tp/my/project … > > > > and > > > > $ sudo guix system -L ~/path/to/my/project -A mypackage … > > > > suddenly result in different file names. > > Sorry to be slow. Naive questions. > > Do you mean the issue comes from who expand '~' (user vs sudo)? > Or do you mean refer to subfolder named '~, i.e., $HOME/foo/~/bar? > > I should miss a point... about what is less or more inconsistent. :-) > Because it seems more based on conventions than on consistent inconsistencies. > > About expansion, is it not the same question with > '--load-path=$HOME/path/to/' vs '-L $HOME/path/to/'? > About naming, is it possible to create a folder named '~' directly in $HOME? > > Well, I am surely not enough skilled to have an opinion but I have > learnt something. :-) > FYA:(Amusement): man bash to see what more ~ can lead to ;-) (scroll down or search for the "Tilde Expansion" section) > > > Please don't do it. > > The fact that Guile does not have a built-in ``expand-tilde`` is a > strong indication to not do it. ;-) > > > Cheers, > simon > > > -- Regards, Bengt Richter
bug#40744: guile-2.2.4 (integer-length 0) erroneously returns 0, not 1
Apologies for my faux pas ;-/ This was not a guix bug, and you have rightly ignored my report. (now submitted to bug-guile, with hopes of nz human acks :) (I guess it will get a new number, so 40744 can be closed?) (BTW, no offense intended in addressing you as "guix/guile bug-squashers" ;-/) On +2020-04-21 15:03:44 +0200, Bengt Richter wrote: > Hello guix/guile bug-squashers, > > The tl;dr is: > (integer-length 0) should agree with: > (string-length (number->string 0 2)) =-> 1 > -- and not: (integer-length 0) =-> 0 -- Regards, Bengt Richter
bug#40744: guile-2.2.4 (integer-length 0) erroneously returns 0, not 1
(format #t " ^--(note that 0 and ~s (radix~a -1) are sign digits for 0 and -1 coefficient values in the polynomial)\n" (number->string (- radix 1) radix) radix)) (format #t "~a ~s\n" (if verbose " Number as glyphs representing coefficient values of radix polynomial for number value:\n" "") coeffs) (format #t " ~s~a\n" coeffv (if verbose " -- corresponding coefficient values" "")) (format #t "~a ~s\n" (if verbose " Number as polynomial expression:\n" "") terms) (format #t " ~s~a\n" termv (if verbose " -- corresponding term values" "")) (format #t " ~s~a\n" polyv (if verbose " -- sum of term values" "")) (if verbose (if (and (= radix 2) (string=? sgnstr "")) (format #t " The following should be equal to guile's (integer-length ~s):\n" absnum) (format #t " Tip: for guile integer-length, enter unsigned value with output radix 2\n"))) (format #t " ~s integer-digit~a (radix ~a)\n" ncoeff (if (> ncoeff 1) "s" "") radix)) ))) --8<---cut here---end--->8--- -- Regards, Bengt Richter
bug#35574: bcm5974 touchpad is not recognized as touchpad
Hi Fllorian, On +2020-04-20 17:59:08 +0200, pelzflorian (Florian Pelz) wrote: > On Mon, Apr 20, 2020 at 04:47:18PM +0200, pelzflorian (Florian Pelz) wrote: > > However I also cannot find the reason why this usbmouse loadable > > kernel module gets loaded at all. How can I debug what loads this Could the module be needed "just in case" in an initrd but should be unloaded before pivoting in a normal case? > > kernel module? Debian does not show usbmouse in lsmod, and I think > > usbmouse should not get loaded in Guix either. usbmouse is not > > required for my external USB mouse to work. > > Debian 10’s /boot/config-4.19.0-6-amd64 has > > # USB HID Boot Protocol drivers > # > # CONFIG_USB_KBD is not set > # CONFIG_USB_MOUSE is not set > > while Guix has in > /tmp/guix-build-linux-libre-5.4.32.drv-0/linux-5.4.32/.config > > CONFIG_USB_MOUSE=m > > I will write and test a patch to disable the module in > %default-extra-linux-options, like the description in linux-5.4.11 > source file drivers/hid/usbhid/Kconfig recommends: > > config USB_MOUSE > tristate "USB HIDBP Mouse (simple Boot) support" > depends on USB && INPUT > ---help--- > Say Y here only if you are absolutely sure that you don't want > to use the generic HID driver for your USB mouse and prefer > to use the mouse in its limited Boot Protocol mode instead. > > This is almost certainly not what you want. This is mostly > useful for embedded applications or simple mice. > > To compile this driver as a module, choose M here: the > module will be called usbmouse. > > If even remotely unsure, say N. > > Regards, > Florian > > > -- Regards, Bengt Richter
bug#40572: installer networking: Connman detects no technologies on Acer Aspire
Hi Ludo, Florian, On +2020-04-14 16:36:12 +0200, Ludovic Courtès wrote: [...] > Woow, the first dbus-daemon process needs 20s from exec to PID file: [...] > 13:46:26 openat(AT_FDCWD, "/var/run/dbus/pid", O_WRONLY|O_CREAT|O_EXCL, 0644) > = 5 ^^^ I usually only see "pid" as a name when I've forgotten to prefix a '$' -- but you do mean "pid" ? [...] -- Regards, Bengt Richter
bug#40542: wip-hurm-vm build failure
Hi Janneke, On +2020-04-14 07:46:48 +0200, Jan Nieuwenhuizen wrote: > Christopher Howard writes: > > > I'm having some trouble playing around with the VM, because a lot of > > weird things are happening with keyboard input into the qemu > > window. It seems like the meta keys (shift, ctrl, alt, super) are > > behaving in strange ways, or that terminal state is getting corrupted > > somehow. E.g., sometimes shift key stops working, or the cursors jumps > > up to the middle of the screen, or text gets garbled. > > Since yesterday I've been seeing that too. I'm pretty sure that if you > build a VM from core-uupdates, the console is fine. > > I haven't looked into the details of the console/tty setup, so I must > have messed-up something. Sorry! Could it be a sensitive touch-pad? (are there configs to adjust triggering on motion?) (I have to disable mouse/touchpad input to edit unless I'm super careful not to brush it with my sleeve or palm) > > Meanwhile we do have ssh login :-) > > The startup now goes like this > > startup -> runsystem -> init -> runsystem.hurd -> rc -> shepherd > > and; i would like to move towards > > -startup -> rc -> shepherd > > if that's possible. > > Greetings, > janneke > > -- > Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org > Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com > > > -- Regards, Bengt Richter
bug#40538: installer: Support uvesafb to install on machines without KMS.
Hi Florian, On +2020-04-12 20:11:01 +0200, pelzflorian (Florian Pelz) wrote: > On Sun, Apr 12, 2020 at 07:48:19PM +0200, Bengt Richter wrote: > > Could it be segfaulting trying to access a missing v86d ? > > The code for loading the uvesafb module looks like this: > > (invoke #+(file-append kmod "/bin/modprobe") > "uvesafb" > (string-append "v86d=" #$v86d "/sbin/v86d") > "mode_option=1024x768" > > So it should call > > modprobe uvesafb v86d=/gnu/store/…-v86d-…/sbin/v86d mode_option=1024x768 > Thanks for explaining. I hope others benefit too :) > and it should be impossible for v86d to be missing. On x86_64 and Hm, could it be there in /gnu/store and have been built so it's a wrong version somehow for the running kernel? That's the only bug possibility I can think of now ;-) > i686 at least, and on other architectures uvesafb will not be loaded. > > Then again, if the GUI works because of other drivers already, we need > not fix it, I think. Also I still believe the error comes because > other drivers already reserve needed memory -- passing nomodeset > should make sure they don’t. Except if vesafb or xf86-video-vesa is > loaded, which is not the case in the installer. sudo dmesg|grep -i fb in that context doesn't show anything weird? Oh, well. Sorry I don't seem to be able to accept a mystery sigsev ;-) Could it be wrapped and caught in a catch? > > Regards, > Florian -- Regards, Bengt Richter
bug#40538: installer: Support uvesafb to install on machines without KMS.
Hi Florian, On +2020-04-12 17:30:52 +0200, pelzflorian (Florian Pelz) wrote: > On Sun, Apr 12, 2020 at 04:48:36PM +0200, Mathieu Othacehe wrote: > > Thanks for your patch. I tried briefly 1.1.0-rc2 on some hardware of > > mine. On three somehow recent laptops, everything still works fine but > > v86d segfaults without giving much information. > > > > The 'dmesg' output looks like: > > > > --8<---cut here---start->8--- > > v86d[371]: segfault at x. > > uvesafb: Getting VBE info block failed (eax=0x4f00, err=1) > > uvesafb: vbe_init() failed with -22 > > uvesafb: probe of uvesafb.0 failed with error -22 > > --8<---cut here---end--->8--- > > > > Even though I do not remember a segfault, I believe these errors come > when another driver has already reserved the memory that uvesafb > wants. If the other driver already works fine and that is the only > error, maybe we can just ignore the uvesafb error. > > Could it be segfaulting trying to access a missing v86d ? (if so maybe you could detect its absence before it segfaults and issue a hint?) Looking at https://www.kernel.org/doc/html/latest/fb/uvesafb.html I see (hand-wrapped, and boxing what I thought might be extra interesting): --8<---cut here---start->8--- Unlike other drivers, uvesafb makes use of a userspace helper called v86d. v86d is used to run the x86 Video BIOS code in a simulated and controlled environment. This allows uvesafb to function on arches other than x86. Check the v86d documentation for a list of currently supported arches. v86d source code can be downloaded from the following website: https://github.com/mjanusz/v86d Please refer to the v86d documentation for detailed configuration and installation instructions. ┌───┐ │ Note that the v86d userspace helper has to be available │ │ at all times in order for uvesafb to work properly. │ │ If you want to use uvesafb during early boot, │ │ you will have to include v86d into an initramfs image,│ │ and either compile it into the kernel or use it as an initrd. │ └───┘ --8<---cut here---end--->8--- Also there are various options for compiling in vs modprobe vs kernel params etc mentioned in https://www.kernel.org/doc/html/latest/fb/uvesafb.html so I imagine v86d could be missing for various reasons in a particular run-time context? > > > On a really old Intel machine, I have a complete black screen on all TTY > > but that was maybe the case on older Guix System revisions and I would > > need to do more investigations. > > > > Mathieu > > Please try adding nomodeset to the kernel parameters. I hope this > makes the Intel machine work fine. > > Thank you for your feedback and all your work! > > Regards, > Florian > -- Regards, Bengt Richter
bug#40538: installer: Support uvesafb to install on machines without KMS.
On +2020-04-12 08:37:02 +0200, Bengt Richter wrote: > Hi Ludo, Florian, > > On +2020-04-10 16:58:58 +0200, pelzflorian (Florian Pelz) wrote: > > On Fri, Apr 10, 2020 at 04:38:37PM +0200, Ludovic Courtès wrote: > > > AIUI, uvesafb is needed for ksmcon (or presumably X11) to work, but it’s > > > not necessary to get the standard Linux framebuffer/console running > > > (indeed, you were able to ctrl-alt-f3 to get a terminal). Is this > > > correct? > > > > Yes, all correct. > > Did you mean s/ksmcon/kmscon/ ? If that is a descendant of David Herrmann's > work, > I wonder if it wouldn't just look for /sys/class/drm/card0 and, if found, > ignore /dev/fb0 and the uvesafb (along with the latter's user stuff > requirements). > > > > > > > > If that’s the case, then I think it’s acceptable for now to install a > > > system that lacks uvesafb. Of course X11 won’t work (right?), > > > > Yes, right. > > > > Is that as absolutely right as it sounds? > I had thought that some version of Wayland/weston had a back end that > could run on plain /dev/fb0, and if so could provide Xwayland for X11 clients. > > Of course, if /sys/class/drm/card0 is available, Wayland will prefer that, > and you're home free for all kinds of GUIs. > Sorry, forgot to add this in context: This "hello world" might suggest what you could do at a direct-to-wayland level, without involving major GUI libs at run time: https://gitlab.com/hdante/hello_wayland (it compiled and ran fine on my PureOS debian-based system, sharing display with gnome as just another wayland client, since all the GUI runs on wayland) I'm sure someone with more guile-fu than me could provide a guile wrapper to vary text and cursor etc. faster than I can. I've been meaning to do it, but time flies :) It looks to me like a way to produce a fancy UI for a small runtime by using guix to define build-time use of major graphics and font resources etc. for the run-time wayland client. > > > which is > > > not great, but people can hopefully address it at the console until we > > > have a better fix, possibly using ‘kernel-module-configuration-service’ > > > as you write. > > > > > > WDYT? > > > > I agree. > > > > I will try making a patch including your suggestions in a few hours. > > > > > > > > 2. Does "modprobe.d/uvesafb.conf" work? I thought there was nothing > > > taking care of creating “modprobe.d” automatically. > > > > I think I tested this version of the patch and it worked. One can > > test on QEMU by passing nomodeset (without uvesafb the installer stays > > black, I think). It also matches the description of > > kernel-module-loader-service-type that was recently added to the > > manual. > > > > Regards, > > Florian > > > > > > > -- Regards, Bengt Richter
bug#40538: installer: Support uvesafb to install on machines without KMS.
Hi Ludo, Florian, On +2020-04-10 16:58:58 +0200, pelzflorian (Florian Pelz) wrote: > On Fri, Apr 10, 2020 at 04:38:37PM +0200, Ludovic Courtès wrote: > > AIUI, uvesafb is needed for ksmcon (or presumably X11) to work, but it’s > > not necessary to get the standard Linux framebuffer/console running > > (indeed, you were able to ctrl-alt-f3 to get a terminal). Is this > > correct? > > Yes, all correct. Did you mean s/ksmcon/kmscon/ ? If that is a descendant of David Herrmann's work, I wonder if it wouldn't just look for /sys/class/drm/card0 and, if found, ignore /dev/fb0 and the uvesafb (along with the latter's user stuff requirements). > > > > If that’s the case, then I think it’s acceptable for now to install a > > system that lacks uvesafb. Of course X11 won’t work (right?), > > Yes, right. > Is that as absolutely right as it sounds? I had thought that some version of Wayland/weston had a back end that could run on plain /dev/fb0, and if so could provide Xwayland for X11 clients. Of course, if /sys/class/drm/card0 is available, Wayland will prefer that, and you're home free for all kinds of GUIs. > > which is > > not great, but people can hopefully address it at the console until we > > have a better fix, possibly using ‘kernel-module-configuration-service’ > > as you write. > > > > WDYT? > > I agree. > > I will try making a patch including your suggestions in a few hours. > > > > > 2. Does "modprobe.d/uvesafb.conf" work? I thought there was nothing > > taking care of creating “modprobe.d” automatically. > > I think I tested this version of the patch and it worked. One can > test on QEMU by passing nomodeset (without uvesafb the installer stays > black, I think). It also matches the description of > kernel-module-loader-service-type that was recently added to the > manual. > > Regards, > Florian > > > -- Regards, Bengt Richter
bug#26302: Deploying the i18n’d web site
Hi Florian, On +2020-04-09 19:31:02 +0200, pelzflorian (Florian Pelz) wrote: > On Thu, Apr 09, 2020 at 05:27:05PM +0200, Ludovic Courtès wrote: > > Hi Florian, > > > > "pelzflorian (Florian Pelz)" skribis: > > > > > + (redirect "/news/porting-guix-and-guixsd.html" > > > "/$lang/blog/2015/porting-guix-and-guixsd") > > > > Does that mean that /blog/2015/porting-guix-and-guixsd (without /LANG) > > will _not_ redirect to /LANG/blog/2015/porting-guix-and-guixsd? > > > > It’s important that all the current URL, without /LANG, remain valid. > > With the new test VM, not all is working. > > /news/porting-guix-and-guixsd.html fails (code 404). > > /blog/2015/porting-guix-and-guixsd fails (code 404). > > /blog/2015/porting-guix-and-guixsd fails (404). > > But /blog/2015/porting-guix-and-guixsd/ works fine. > > Well this is difficult to figure out. > Wondering, could dnsmasq help? > Regards, > Florian > > > -- Regards, Bengt Richter
bug#40273: installer: No way to input Latin characters with non-Latin keyboard layouts
Hi Ludo, On +2020-04-08 11:42:41 +0200, Ludovic Courtès wrote: > Hi Bengt, > > Bengt Richter skribis: > > > I'm really against pursuing any new design dependencies on X, > > so even "or similar" sounds iffy to me. Just IMO ;-) > > The XKB database and associated tools is the de facto standard for > handling keyboard layouts; it does a great job! It originated in X11 > but that’s about the only relation it has with X11. > I'm more than ok with declarative data representing a legacy of valuable info. I didn't mean to deprecate that part, sorry. > Anyway, please let’s try to keep issues at Debbugs and development > discussions focused otherwise it’s easy to all get lost in open-ended > discussions while making very little actual progress. :-) > Understood. Sincere apologies for disrupting and/or distracting. I understand the problem. (After all, I'm doing it to myself: It takes me much longer to write than it does to read ;-p ) So, off-topic replies being a problem. naturally I am triggered to think about this problem, and I am tempted to post ideas about automatically diverting off-topic reply posts to guix-offto...@gnu.org and and automatically only posting references thereto to recipients who would otherwise get the whole thing. But beyond the above, I will restrain myself ;-) Sorry about this off-original-topic post. I guess it is like social distancing to avoid infecting people with distractions ;-/ I will try to practice better hygiene :) -- Regards, Bengt Richter
bug#40273: installer: No way to input Latin characters with non-Latin keyboard layouts
Hi Florian, On +2020-04-04 01:17:50 +0200, pelzflorian (Florian Pelz) wrote: > On Fri, Apr 03, 2020 at 01:27:43AM +0200, Bengt Richter wrote: > > I think I saw that PureOS was able to handle > > different-layout keyboards in different concurrent sessions -- different > > keyboards and displays > > can be attached to different "seats" -- or something like that, I obviously > > don't know much yet ;-) > > > > Anyway, to the point: even if I'm wrong about PureOS handling concurrent > > different-layout keyboards, I think that would be a good goal > > for GuixOS/Hurd/Shepherd to implement. > > From what I understand from > <https://github.com/xkbcommon/libxkbcommon/blob/master/doc/quick-guide.md>, > there can be per-device keyboard layouts, but they are not handled by > XKB options. If a device specifier were added to the keyboard-layout > constructor, the device specifier would need to be turned into > appropriate xorg.conf MatchUSBID or similar. > > Regards, > Florian Sorry for the delay in replying. Thanks for the informative link! I'm really against pursuing any new design dependencies on X, so even "or similar" sounds iffy to me. Just IMO ;-) I recognize it will be a while before we can ignore X-based apps, but we can stop using it as GUI infrastructure, if Wayland can provide GUI foundation with Xwayland giving X apps a path to the screen via Wayland. Of course Wayland has dependencies on what the kernel can provide, like libdrm stuff. Wayland seems a likely X successor, and represents an opportunity to do GUI without X dependencies, for a cleaner Guix. I can report that tilix as implemented in PureOS on a Librem13v4 provides a workable GUI solution for multiple keyboards, even if it's not what I had in mind ;-) Here is an overview: PureOS is debian-based Purism variant with gnome for desktop etc and I think all composited and displayed by their Wayland, providing xwayland only as a service for apps needing the X interface, but not itself depending on X. tilix is, I think, a pure wayland client implementation, and can provide multiple simultaneous terminal tiles on the screen, overlapping or not. These window tiles are created by typing "tilix" with optional args. Without args it creates a new tile space according to a Default "profile" which you can do a LOT with, but don't need to to demo the keyboard mappings. The first tilix command will normally be typed into a widget that comes up on pressing the super key (some keyboards will have a windows flag on that key :). Subsequent tilix commands can be typed in any tilix terminal, and will produce another terminal tile accordin to parameters in the profile (of which you can create different versions). Choosing a keyboard language (separate dropdown widget at top of screen) in any of these terminal tiles that has focus will set the keyboard mapping for that terminal tile only. Switching focus to another tile will use the the kb mapping chosen for it. Persistence is attached to the terminal tile. So you could have two different language keyboards plugged in and use one to type into one tile terminal and the other for the other. You just have to switch focus to where you want the typing to appear. But this is also a kind of illusion, because both keyboards' untranslated keycodes are apparently merged into the same stream and fed where the focus is. So you can't mix languages on one terminal tile by just typing on the alternate keyboard (as I had wanted)-- you have to go to the language choice widget and temporarily switch there, no matter which keyboard you are typing on. Some keys are obviously the same, so it doesn't matter which keyboard you type those on. It goes to the focused tile and gets translated, but the mapping for those keys is the same. Right now I am in GUI emacs called as editor for mutt, and the language selection has no effect even though when I exit all the way back to the bash where I typed mutt, it will (or should ;). pidparents ?18587 Ss /usr/bin/bash /home/bokr/bin/pidparents emacs pts/018069 Sl+ emacs /home/bokr/.mutt/temp/mutt-LionPure-1000-17715-4020479191039126306 sh pts/018068 S+ sh -c emacs '/home/bokr/.mutt/temp/mutt-LionPure-1000-17715-4020479191039126306' muttpts/017715 S+ mutt bashpts/013623 Ss /bin/bash tilix ?13618 Sl /usr/bin/tilix --gapplication-service systemd ? 1644 Ss /lib/systemd/systemd --user systemd ?1 Ss /sbin/init splash And if I were at the tty initial console, the widget for language change wouldn't be there, since no gnome GUI. I would have to use loadkeys. And back in grub, another world. And back in the BIOS, another. And all considerations repeated for booting from external disks, ne
bug#40405: System log files are world readable
Hi Ludo, On +2020-04-07 00:07:14 +0200, Ludovic Courtès wrote: > Hi, > > Ludovic Courtès skribis: > > > In the meantime, the patch below fixes the syslogd problem. Also > > attached is a patch for the accounting database, though that one is > > questionable. > > I pushed the syslog bits along with a test as commit > d7113bb655ff80a868a9e624c913f9d23e6c63ad. (I think already > world-readable files will remain world-readable though?) > Could build daemons do some kind of maintenance rebuild to chmod them? And maybe be scheduled to monitor new files for other mistakes as well? Meanwhile, could a superuser chmod them without affecting hashes? (curious as to whether permission bits escape hashing). > The main remaining issue here is log files created by > ‘fork+exec-command’. We’ll have to address that in the Shepherd proper, > I think. > > Ludo’. > > > -- Regards, Bengt Richter
bug#40273: installer: No way to input Latin characters with non-Latin keyboard layouts
Hi all, On +2020-04-02 12:25:37 +0200, Ludovic Courtès wrote: > Hi, > > Mathieu Othacehe skribis: > > >> That’s exactly what it does, see (shepherd comm). > >> > >> Perhaps we just need to have the installer service depend on ‘syslogd’, > >> at which point nothing goes to /dev/console? > > > > Heh, I read it too fast, sorry :) The issue was in fact that we are > > calling `start-service' and `stop-service' from `apply-locale' in (gnu > > installer), and printing shepherd messages to shepherd-message-port > > which is stderr by default. > > > > Fixed on wip-installer-help. > > Awesome. > > Do you think that branch is ready for a merge? Or did you want to > further discuss some of the changes? Florian seemed to agree that it’s > a good thing. > I am wondering about hot-plugged keyboards, whether plugged in before power-up or late, after login and GUI terminal activation. I see/imagine several issues. 1) Legacy unices seem just to have accepted any usb device identifying itself as key event generator and merged the events indiscriminately into existing key-event streams, with security issues ignored, and alternate layouts ignored :-/ What I'm writing on now [1] has a US keyboard (which is annoying if I am trying to write swedish, or embarrass myself with my French :), so I am recharging the batteries for an old swedish Logitech kb that has a wireless connection to a USB receiver. (I'll return to report how that worked out -- I think I saw that PureOS was able to handle different-layout keyboards in different concurrent sessions -- different keyboards and displays can be attached to different "seats" -- or something like that, I obviously don't know much yet ;-) Anyway, to the point: even if I'm wrong about PureOS handling concurrent different-layout keyboards, I think that would be a good goal for GuixOS/Hurd/Shepherd to implement. So WDYT about a little kb experimenting to expose potential issues before final decisions? 2) Another issue is that with hot-plugging and booting from external media, keyboard layouts are unknowable ahead of time (except by humans deciding they will only boot from media they know carry KB layout info matching the booting host's KB). So who/what is the first user of keyboard layout info? I think probably the OEM who decided which key should interrupt booting to go into BIOS setup, since the BIOS has to continue with some assumption of keyboard layout. Probably matches the BIOS-developer's kb, hard coded ;-) But consider a "NUC" box, with no predetermined peripherals, just sockets. Plug in the right keyboard or keep rebooting and hitting Esc or Del or F11 and hope you don't trigger anything disastrous. Or get online with another machine and search for how someone succeeded. Filter bad advice. How many times have you gone through that ? ;-) Ok, next user after BIOS, probably some boot loader. Its image can not contain knowledge of what keyboard is the source of key-codes, so it must either receive converted key codes or be able to get the right layout info to do the conversion itself -- or punt, using a US layout for anything and everything. ... Let's see, '-' is '/' and '+' is '-' and ... argh. (recognize install iso experience? setfont sun12x22 helps :) So anyway, eliding, the boot loader gets the root file system loaded and pivots to it and the kernel can figure out keyboards again for itself, maybe. Is this really a good design for gnu guix systems? All that Mach stuff I read April 1st sounded really neat ;-) (I regret having pointed out the date and not letting it run. I apologize for interrupting the fun "joke" ;-/ ) Logitech KB batteries still charging, will have to try that later ... HTH make multiple concurrent different-layout keyboards be part of the future :) > Ludo’. > > > [1] Purism Librem13v4 laptop: an emergency-prompted purchase when my swedish laptop died in US) -- Regards, Bengt Richter
bug#40273: installer: No way to input Latin characters with non-Latin keyboard layouts
Hi Florian,
On +2020-03-31 18:55:59 +0200, pelzflorian (Florian Pelz) wrote:
> On Tue, Mar 31, 2020 at 05:35:41PM +0200, Ludovic Courtès wrote:
> > I think we can have both Alt-Shift and what Mathieu implemented, no?
> >
>
> Yes, both would be best, what Mathieu implemented is more
> discoverable.
>
> > However, note that the installed system won’t have Alt-Shift support,
> > and perhaps that is a bigger concern.
>
> Yes.
>
> guix build -S console-setup
> sudo mkdir -p /usr/share/X11
> cd /usr/share/X11
> sudo ln -s
> /gnu/store/fabcbhjh4g5fmm39fmkjjhiplqwrg0n8-console-setup-1.194-checkout/Keyboard/ckb
> xkb
> ckbcomp ar,fr -variant azerty, -option grp:alt_shift_toggle > ~/test
> sudo loadkeys ~/test
>
> works, but I have no idea how to turn that into a keyboard-layout.
> I tried setting in /etc/config.scm
>
> (keyboard-layout
> (keyboard-layout "ar,fr" "azerty" #:options '("grp:alt_shift_toggle")))
>
> but it threw an error.
>
> > OTOH, we’re just using the standard XKB layouts, so if they don’t
> > provide Alt-Shift, well, perhaps that’s because this is the way it’s got
> > to be?
>
> I did not know back then, but it does work. In dconf-editor, I can
> set org.gnome.desktop.input-sources to ['grp:alt_shift_toggle']. It
> switches between all configured layouts in GNOME.
>
> > Is “grp:alt_shift_toggle” guaranteed to be available, no what what
> > ‘layout’ is?
> >
> > Also, that means Alt-Shift is enabled for all layouts, not just the
> > non-Latin layouts, right?
>
> Yes, with the patch I can toggle any layout to US layout and back.
>
Have you looked at man vconsole.conf
http://man7.org/linux/man-pages/man5/vconsole.conf.5.html
Could this be helpful?
https://unix.stackexchange.com/q/57085
Also this has more extensive info on creating/modifying keymaps and
getting systemd to get them going:
https://wiki.archlinux.org/index.php/Linux_console/Keyboard_configuration
I don't know if this is useful, but seems like you can affect things
early in the boot sequence (from the man page):
--8<---cut here---start->8---
Note that the kernel command line options vconsole.keymap=,
vconsole.keymap_toggle=, vconsole.font=, vconsole.font_map=,
console.font_unimap= may be used to override the console settings at
boot.
--8<---cut here---end--->8---
> I believe we would need a map from each layout to whether it should be
> QWERTY, AZERTY, QWERTZ … Or we would just use QWERTY.
>
> What do you think is the right path forward?
Do the right thing :)
>
> Thank you.
>
> Regards,
> Florian
>
--
Regards,
Bengt Richter
bug#39949: [core-updates] rust@1.20 fails tests
Hi Marius, On +2020-03-31 16:04:03 +0200, Marius Bakke wrote: > Marius Bakke writes: > > > Rust 1.20 fails a test on core-updates, possibly because of the new > > version of GNU Make (4.3). > > > > I suppose we can disable that test for the bootstrap builds as long as > > it works for the latest version of Rust. > > Fixed by giving Rust an earlier version of GNU Make in commit > 47cd0febe957b698cc2ae28978bdc3bc89e787f9. ISTM this kind of "fixed" is not the same as e.g. an upstream upgrade that "fixes" "the problem" -- so I'm wondering if work-flow-wise you have a way to tell some upgrade-watching robot to notify you (or your s/w[1]) when the inevitable revision to your "fix" should be done. Are there any general standards for subscribing interest in being notified when a particular package or file gets upgraded/revised/etc in any "distro" your package may be dependent on? [1] Is there such a thing as a derivation/service that sits and waits for such a notification, and maybe sends you a patch when it does get notified? Just curious how the world works :) -- Regards, Bengt Richter
bug#39575: guix time-machine fails when a tarball was modified in-place
On +2020-02-15 21:01:36 +0100, Tobias Geerinckx-Rice via Bug reports for GNU Guix wrote: > Jan, Simon, > > Janneke 写道： > > https://snapshot.debian.org/archive/debian/20190406T212022Z/pool/main/h/harfbuzz/harfbuzz_2.4.0.orig.tar.bz2 > > This is a wonderful resource! Thank you, Janneke (and Debian)! > > zimoun 写道： > > Cool! > > But how do you determine the "date", i.e., this reference > > '20190406T212022Z' ? > > You'd take the timestamp immediately preceding your desired (Guix) commit's > date, or something like that. The fact that git commit dates aren't linear > shouldn't hurt here. > > > Could it be automated? > > Not without parsing HTML to get the valid timestamps: > <https://snapshot.debian.org/archive/debian/?year=2020=2>. > You may not need to parse the html fully if the part you need is isolatable into delimited scopes that you can successively narrow. For example, I while back I wanted a command I could type to get the url of the latest linux kernel at kernel.org: stable-kernel.scm -h --8<---cut here---start->8--- Usage: stable-kernel-scm [ -h ] -h for this message (without args): go to https://www.kernel.org/ to wget page, extract URL of latest stable release tarball and write that URL to stdout. --8<---cut here---end--->8--- (oops, I see I din't use $0 in the usage text -- should be .scm, not -scm) I offer it below [1], with the thought that you could probably modify (not to mention improve :-) it to get the timestamps you want. Especially if you could get them to make the narrow context unique enough that it's delimiters can delimit it in one shot. The page at kernel.org is apparently stable enough that this still works, but YMMV until the snapshot page is similarly stable. (You could ask them to make it easy :) > Also, this doesn't seem to be a supported service yet[0]: > > “This is an implementation for a possible snapshot.debian.org service. > It's not yet finished, it's more a prototype/proof of concept to show > and learn what we want and can provide. So far it seems to actually > work.” > > Still really cool, > > T G-R > > [0]: https://salsa.debian.org/snapshot-team/snapshot HTH or is useful some way. -- Regards, Bengt Richter [1] --8<---cut here---start->8--- #!/usr/bin/bash exec guile -e main -s "$0" "$@" !# stable-kernel.scm goes to https://www.kernel.org/ to wget page, then extracts name of latest stable release tarball to stdout (define (usage) (format (current-error-port) (string-join '( "Usage: stable-kernel-scm [ -h ]" " -h for this message" " (without args):" " go to https://www.kernel.org/ to wget page," " extract URL of latest stable release tarball" " and write that URL to stdout." "") "\n"))) (use-modules (ice-9 format)) (use-modules (ice-9 rdelim)) (use-modules (ice-9 popen)) (use-modules (ice-9 textual-ports)) (use-modules (ice-9 and-let-star)) (use-modules (ice-9 regex)) (define (extract-delimited str s-beg s-end) (and-let* ((ix-beg (string-contains str s-beg)) (ix-post-beg (+ ix-beg (string-length s-beg))) (ix-end (string-contains str s-end ix-post-beg))) (substring str ix-post-beg ix-end))) (define kernel-url "https://www.kernel.org/;) (define (get-kern-name) (let*((cmd-kern (string-append "wget -q -O - " kernel-url)) (p-inp (open-input-pipe cmd-kern)) (wgot-pinp-str (get-string-all p-inp)) (extracted-table-releases (extract-delimited wgot-pinp-str "" "")) (extracted-stable-tarball-anchor (extract-delimited extracted-table-releases "stable:" ">tarball<")) (extracted-stable-href (extract-delimited extracted-stable-tarball-anchor "8---
bug#38422: Bug status? '.png' files with executable permissions
Hi zimoun, On +2020-01-22 01:22:45 +0100, zimoun wrote: > Dear Bengt, > > The bug report [1] points out files with unexpected permission; based > on extension filename. > > [1] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=38422 > > > It is not an security issue or the Guix packager did not carefully > check the validity of these files. > > If you are security paranoid, you *have to* check by yourself all the > files using "guix build -S" because in paranoid mode you cannot trust > Guix packagers (and Guix committers neither). > > > In normal mode, 2 options: > > a- propose a patch to change the permission for each offending package > b- report upstream > > Well, at least these 3 packages docbook-xsl, faba-icon-theme, and > moka-icon-theme comes with unexpected .png file permission. > > > On the long term, I am not convinced that adding automatic check and > permission change based on filename extension would really add Quality > Assurance. Because we are speaking about quality, not security. > > > I am inclined to close this bug. What do you think? > > All the best, > simon Ok with me to close, thanks. -- Regards, Bengt Richter
bug#39194: help for non-root users to start using
inux [1579528427.116]: [ INFO ] Downloading Guix release archive guix-binary-1.0.1.x86_64-linux.tar.xz 100%[==>] 59.66M 7.05MB/s in 9.2s guix-binary-1.0.1.x86_64-linux.tar.xz.s 100%[==>] 833 --.-KB/s in 0s [1579528436.864]: [ PASS ] download completed. [1579528437.426]: [ PASS ] Signature is valid. [1579528437.427]: [ INFO ] sha1sum digest of guix-binary-1.0.1.x86_64-linux.tar.xz: 8288422fde6a6d4ee257355c21ab9447ae9736cf guix-binary-1.0.1.x86_64-linux.tar.xz [1579528437.580]: [ INFO ] Downloading Guix install script 'guix-install.sh' guix-install.sh 100%[==>] 13.68K --.-KB/s in 0s [1579528438.299]: [ PASS ] download completed. [1579528438.304]: [ INFO ] sha1sum digest of guix-install.sh 4402af0b8c130b1cabf7fb5e68ec3183a02633b0 guix-install.sh [1579528438.308]: [ INFO ] sha1sum digest of /home/bokr/BS/bs20200119_2359/get-guix-ver.sh 6926ea98230514b731c4ebe9edae8c9a5e01c0a9 /home/bokr/BS/bs20200119_2359/get-guix-ver.sh [1579528438.311]: [ INFO ] This is last command in modified guix-install.sh script. [05:53 ~/bs]$ --8<---cut here---end--->8--- Well, I hacked in some extra stuff, but I think it would be nice to give the script a -n --dry-run option, and print the tarball dates along with a last-commit date, etc. to show automatically what I did manually above. Also, it the script [1] under git version control? Perhaps as a verbatim texi node in guix info? WDYT? BTW I think guix use via binary installs on "foreign distros" will grow to a majority. Especially if those who want to try it can pre-check with a dry run that can be run as plain user and which outputs good warnings as appropriate. I am now on PureOS on a Librem13v4, which is based on Debian apt packaging, limited IIUC to their vetted repo based on Debian upstream. So I wonder what I have done to my trust tree by running the binary install script. I hate to think. There sure are a lot of committers who I don't know from Adam ;-/ > Here’s my understanding of what happened: > > 1. You’re running guix-daemon 1.0.1, which lacks the fix for > <https://bugs.gnu.org/37744> (aka. CVE-2019-18192). > > 2. As “mwette”, you ran ‘guix pull’ and obtained a new ‘guix’, which > you then used in ‘guix install hello’ above. > > 3. That new Guix contains the new profile locking mechanism that threw > the exception we see above. That exception is because it failed to > create the lock file (“No such file or directory”), and that in > turn is because /var/guix/profiles/per-user/mwette didn’t exist > yet. > > /…/per-user/mwette didn’t exist because it was the first time you > ran ‘guix install’ as “mwette”, and because guix-daemon lacks the > fix mentioned above that would create upon first connection. > > QED ■ :-) > > Thanks for your report! > > Ludo’. > -- Regards, Bengt Richter
bug#39095: GRUB EFI should have a 'chainloader' option
Hi symphonia, On +2020-01-12 12:08:08 +, sympho...@disroot.org wrote: > To dual boot with NixOS and other operating systems it would be nice to have > 'chainloader' so that this configuration would work: > (bootloader > (bootloader-configuration > (bootloader grub-efi-bootloader) > (target "/boot/efi") > (menu-entries >(menu-entry > (label "systemd-boot") > (chainloader "/EFI/Boot/bootx64.efi"))) > > > I just got a librem13v4 with PureOS installed booting via Coreboot amd grub, and found that it will boot legacy mbr usbs, but would not boot a UEFI-bootable USB or system on external USB SSD, though it shows up in a list of bootables. (I've seen a reference to some kind of tool that converts a GPT partition to MBR style, but I don't want to do that). Does anyone know if efibootmgr and coreboot see bios nvram compatibly? Or a workaround? I saw your post and am hoping to find a possibly similar 'chainloader' solution, but worry that the second loader may mess incompatibly with bios nvram. -- Regards, Bengt Richter
bug#38857: X.509 certificate of 'crates.io' could not be verified during a recursive import from crates.io
V1.08 11/22/2017 │ │ MOUNTPOINT KNAMELABELSIZE FSAVAIL FSUSE% │ │ /boot sda1 Evo25c2EFI11G 461.9M55% │ │ / sda4 Evo25c2ArchGx4 167.9G 73.5G50% │ │ Kernel: 5.4.6-arch3-1 #1 SMP PREEMPT Tue, 24 Dec 2019 04:36:53 + │ │CPU: Intel(R) Pentium(R) CPU N4200 @ 1.10GHz │ └─┘ Whereas on tty4 I logged in with a config value that my ~/.bash_profile uses to set MY_GUIX_MODE=enabled at the top and do further enabled/disabled specializations after that, so e.g. guix is found in $PATH and currently that makes (captured on tty4 and and retrieved here on tty1) guix describe: --8<---cut here---start->8--- Generation 27 Dec 29 2019 18:49:23(current) guix 996182a repository URL: https://git.savannah.gnu.org/git/guix.git branch: master commit: 996182a84bafb4c4982dcb36c2c54b350c16629a --8<---cut here---end--->8--- Editing context in emacs here and now: --8<---cut here---start->8--- pidparents ? 8747 Ss /usr/bin/bash /home/bokr/bin/pidparents emacs tty12420 Sl+ emacs /home/bokr/.mutt/temp/mutt-Evo25c2ArchGx4-1000-861-11810734661506241046 mutttty1 861 Smutt bashtty1 461 Ss -bash login ?447 Ss login -- bokr systemd ? 1 Ss /sbin/init \EFI\Evo25c2ArchGx4\vmlinuz-linux --8<---cut here---end--->8--- Regards, Bengt Richter
bug#38529: Make --ad-hoc the default for guix environment proposed deprecation mechanism
Forgot to add: ┌──┐ │ guile -c '(use-modules (ice-9 session))(apropos "env") │ ├──┤ │ (guile): getenv # │ │ (guile): environ # │ │ (guile): setenv # │ │ (guile): interaction-environment # │ │ (guile): putenv # │ │ (guile): unsetenv # │ └──┘ BTW, it would be really handy to be able to type guile -apropos rest of line as regex for the effect of ,a rest of line as regex in the guile repl -- Regards, Bengt Richter
bug#38529: Make --ad-hoc the default for guix environment proposed deprecation mechanism
Hi Gábor, Konrad, et al On +2019-12-17 10:14:12 +0100, Gábor Boskovits wrote: > Hello Konrad, > > Konrad Hinsen ezt írta (időpont: 2019. dec. > 17., Ke 7:52): > > > On 16/12/2019 23:09, Ludovic Courtès wrote: > > > So in a more algorithmic manner: > > >> 1. if ad-hoc and inputs-of is present at the same invocation: fail > > >> hard. (With an error like incompatible options present) > > >> 2. if only ad-hoc is present, then print a deprecation warning (yes, > > >> we could make this suspendable with an environment variable, like you > > >> described) > > >> 3. if only inputs-of present, then do the new behaviour. > > >> 4. if neither ad-hoc nor inputs-of present then > > >>a. if GUIX_ENVIRONMENT_DEPRECATED is 1: do the current behaviour, > > >>b. if GUIX_ENVIRONMENT_DEPRECATED is undefined, or is not 1: do the > > >> new behaviour. > > > That sounds like a good plan to me. > > > > > > #4 is the trickiest, and I think it’d be good to give users a bit of > > > time so they can start adjusting before deprecation is in effect. > > > > #4 is trickiest for another reason: there is no future-proof use of > > "guix environment" that works right now and will continue to work. Nor > > is there any way to see, when looking at a command line, whether it's > > old-style or new-style, if neither --ad-hoc nor --inputs-of are present. > > This means that all existing documentation (tutorials etc.) will become > > misleading in the future. Worse, even documentation written today, in > > full awareness of a coming change, can't do better than saying "watch > > out, this will do something else in the future". > > > > The first rule of backwards-compatibility is: never change the meaning > > of an existing valid command/API. Add new valid syntax, deprecate old > > valid syntax, but don't change the meaning of something that was and > > will be valid. > > I think it is important to consider context when talking about meaning. 1. the level and the interpreter of the command: The first level is usually the shell (typicallly bash) from logind, but there is systemd and/or shepherd before that, and there is bootloader and UEFI and before that also accepting and/or passing commands through to the kernel via the kernel command line (cf. cat /proc/cmdline ). The general pattern I mostly see for a given interpreter is verb -adverb* (-adjective-for: object-name)* sub-command? implicit-or-object-for-verb* Consider whether your new name reinforces a good convention or forks it. Consider whether proposed usage translates easily to a natural language explanation. Does guix have a cli design best practices doc, BTW? right now we are talking about the use case where verb=guix and subcommand=environment 2. project community conventions Specialized areas often have their own jargon and abbreviated refrences so an unfortunate choice of name can cause distracting disambiguation searches. Before settling on a new name xxx, even for a sub-command, I would say at least first do the following at the command line: which xxx xxx --version xxx --help info xxx man xxx apropos xxx #check for same prefix, case-insensitively, # e.g. env might be tempting, as seen in this thread :) --8<---cut here---start->8--- echo $PATH|tr : $'\n'|while read pdir;do (find "$pdir" -maxdepth 1 -iname "env*" 2>/dev/null);done --8<---cut here---end--->8--- # -name "*xxx*" may also be a good idea, but the prefix is most important # env* produces /usr/bin/env /usr/bin/envsubst guix search xxx guix package -A xxx wikipedia search on xxx, e.g. lynx -dump -force_html -nolist https://en.wikipedia.org/w/index.php?search=xxx |less You get the idea, I'm sure ;-) > > How about a more drastic measure: deprecate "guix environment" and > > introduce a new subcommand with the desired new behaviour? > > SGTM, with some caveats Good, since calling different things by the same name is always going to be problematic. Iffy, since calling the same thing by different names may reduce future naming options, and may muddy the peer-name namespace, so maybe consider using sub-commands or -adverb. > That is also the other option I was thinking about. Do you have any good > idea in mind as how to call it? Of course the classic guix environment2 > comes to my mind, but it does not look very appealing to me. > Me neither :) > > > > Cheers, > > > >Konrad. > > > Best regard, > g_bor > HTH in some way :) -- Regards, Bengt Richter
bug#38498: Fontconfig does not find fonts in non-default profiles
adi9jymglnfryj0l9fcg1z7wd5sw8210a-sun12x22.psfu.gz
│
│
GxFont12x22-0ylkkdlwhzfw3dadsqhhh021xafz97zajc3qcgrbv6vmdlk3chpn-LatGrkCyr-12x22.psfu.gz
│
│
GxFont12x22-0awqnypd4np6zpjy12wd2fq5ri9ifamapadfmn1h9k2vjjnndwpd-iso01-12x22.psfu.gz
│
│
GxFont12x22-1hy97l5n7363q5w5x19f7c8klabbprrpx5r1ki4swbn372326jgl-iso02-12x22.psfu.gz
│
│ GxFont12x22-1zrlk9zvpkmhcl0cyxy5pnm6mqy7qranx40gz5gy3wvf0cnpm6dp-README.12x22
│
└──┘
Potentially, the store could contain vbr names naming links to the foreign
versions
in /usr and which could be verified any time desired for integrity and
identity, and
presence: if absent, it would be optional to go to a substitutes repo or
anywhere on
the web to refresh a local cache. If you find the name you can verify that the
referenced
blob is identical to any other with the same name and dereferencing. More
discussion below.
The names are made so that the hash part is dependent on both the file bytes
and the name itself as axplained below.
Following is an example poc vbr session. Pretty simple so far, but bigger
dreams afoot ;-)
The commands are (others are wip, not shown :)
vbr prefix- filepath # prefix includes single trailing - for now
vbr -ck [ vbr-link | vbr-file-name ]
The rest made this a monster post, so if vbr and potential uses is
of interest, perhaps someone could copy this as the seed of a new thread
in a more appropriate list for discussing guix architectural evolution
and factoring out of minimalist components for use separately and/or
in minimal environments?
Also the guile language tower interests me :)
The following is an example of a possible format for sharing embedded snippets
simply and bitwise unambiguously. Lots of other possibilities exist ;-)
┌─┐
│ v1Snippet-1mzfvrqhllz92siajm2rq7h7a67hg486wnyjwxznhc0zmzxg9n2v-xxx│
├─┤
│ Among other things, I discuss using vbr's as verifiable blob references │
│ for what UEFI bios reads from /boot and so for what a boot loader sees, │
│ and so forth. Also the role of vbr's in casual but unambigous sharing │
│ of snippets within emails and docs, for automatic search and validated │
│ extraction. │
└─┘
The above could be cleanly automated but was done ad hoc by selecting the
five lines of box content before boxing it, and then executing
--8<---cut here---start->8---
cat > /tmp/xxx;cat /tmp/xxx|boxit -title "$(vbr v1Snippet- /tmp/xxx)"
--8<---cut here---end--->8---
as a shell filter command on the region. The part after -title
put the vbr in title above the boxed content. So a search on v1Snippet-...
in e.g. this email lists archives in mbox format would allow automated
extraction of the box content and checking that the vbr was correct.
Of course you could do a vbr for a base64 part of an email too,
before or after decoding.
I think vbr is simple enough to integrate easily into the guix architeture.
Or WDYT, Ludo ;-)
Ok, this is getting long again ;-/
Can't resist including the /boot use:
Here is a use case re booting images.
for f in /boot/*{x,g};do vbr v1Boot- "$f";done
┌──┐
│ veebers for what UEFI sees, which it could keep as whitelist
│
├──┤
│ v1Boot-0c9w9bjwbhn8hn7w427qar8wgdbyic7xv88pjs4yji79n9f2433v-vmlinuz-linux
│
│
v1Boot-1dp21vvpx99nqjy2z8s239f8bgiqh43lzxm91j7a3n2867ngadj0-initramfs-linux-fallback.img
│
│
v1Boot-1bxpkf7i3w7q3c4ziasp2vgg17xq5j3vdqp9y633l5212ddypj8d-initramfs-linux.img
│
│ v1Boot-02yla7mv6qg16j0zw0dyy339zdn827xlv964hbinx7hnhi5ax3kk-intel-ucode.img
│
└──┘
This would enable safe booting via TFPT, without signatures, assuming you
checked and
trusted the vbr when you efibootmgr'd it. The UEFI could load speculatively and
display
a computed vbr for an image it loaded and didn't recognize. The user could then
check
the the web for a trusted opinion and bail or proceed (given UEFI password) to
accept
the new image and white-list it with one-shot trial boot if desired.
This would also be a nice way to validate a boot-to-guile image ;-)
--
Regards,
Bengt Richter
