[OT: s/Joshua/Josiah/ in sig ;-] Re: [shepherd] several patches that i deem ready

[bokr]

On +2024-01-24 17:11:28 +, Attila Lendvai wrote:
[...]
> -- 
> • attila lendvai
> • PGP: 963F 5D5F 45C7 DFCD 0A39
> --
> “But if you wish to remain slaves of bankers and pay the cost of your own 
> slavery, let them create money.”
>   — Joshua Stamp
  ^^
  Josiah


>
Hi attila (and others who, like me, may enjoy the quotations
at the bottom of your posts :)

Should such misspellings be reported somewhere as a bug?

--
Regards,
Bengt Richter

Re: Build dependency inflation (was: Re: Core-updates merge)

[bokr]

Hi,
TL;DR:

If we have 22k sources, how about expressing dependency as a
22k x 22k matrix of weights Wij and dependency by
multiplication of 22k x 1 matrix os sources variables
ordered Sj by immediate dependency first. I guess the Sj
column matrix is transposed to do the multiplication, so the
Wij j's and Sj j's match.

Start with weights of only 1 0r 0. Later maybe measures of
compile times?

The diagonal Wjj would be all ones, and counts of ones in
vertical columns Wkj would be maximal if that Sj was
directly depended on for a lot of k's

Reordering the Wjj and Sj sort of like solving simultaneous
equations and colorizing somehow to show the clusters of Wij
dependency bits vs a backgrond of zero bits might make an
interesting display. WDYT?

Any GnuPlot whizzes out there? :-)

Regards,
Bengt Richter



On +2023-04-27 19:56:38 +0200, Simon Josefsson via Development of GNU Guix and 
the GNU System distribution. wrote:
> Andreas Enge  writes:
> 
> > - Too much in Guix depends on too much else, which makes building things
> >   needlessly entangled; in particular time zone data should not be referred
> >   to by packages, but be loaded at runtime (Leo Famulari).
> 
> This is an important open problem -- is there any way to attack this
> problem in a systematic way?  I guess it is hard to understand which
> packages ends up depending on what since it is a large graph with long
> cycles, and also to understand which build depencies are essential and
> which are superficial, and thus consequently challenging to know where
> to start working to reduce build dependencies?
> 
> I wonder if it is possible to graph all the build dependencies, and do
> something like a monte-carlo what-if simulation: randomly pick one
> build-dependency from the entire build-dependency graph and remove it,
> and recompute the graph.  If the difference between these two graphs
> leads to a significantly lower total build computational cost than
> before, we may be on to something.  My theory is that "true" build
> dependencies will show up in so many places that removing just one
> instance of it will not affect total build time.  But "needless" build
> dependencies may occur just once or few times, and this approach would
> catch low-hanging fruit to work on.  Maybe the simulation needs to be
> done on more than just removing one build-dependency, it could play
> what-if games removing two build-dependencies etc, or three random
> build-dependencies, and so on.  Maybe my idea is flawed, and this will
> only lead to a list of build-dependencies that are impossible to get rid
> off anyway.
> 
> Is there some other method to understand what build dependencies would
> be important to remove, to speed up total rebuild time?
> 
> Maybe we could analyze how much of a particular build-dependency
> actually is used by a particular build?  By looking into file-access
> patterns etc.
> 
> /Simon

Re: bug#61894: [PATCH RFC] Team approval for patches

[bokr]

Hi,
tl;dr:
If you want to expand the list of committers rapidly,
would it make sense to have a sand-box repo for new committers
which trusted committers could channel cherry-picks from?

Pick your bugaboo, but I consider plausible that some
volunteering committers are there on paid job assignment
serving some agenda which you can't easily discover.

Well, that can be good and normal with FLOSS-enlightened emplayers,
but one can imagine not-so-benevolent assignments...
(pick your concept of benevolence :)

On +2023-03-02 12:04:44 +0100, Andreas Enge wrote:
> Hello,
> 
> in the current situation I think the suggestion is putting the horse before
> the cart. In a first step before adding policy, we should make the teams
> functional. While working on core-updates, I have been realising we are
> already spread too thin: Some important languages have teams with one or
> two members, who would effectively become bottlenecks. Other software has
> no team (Qt/KDE). All in all, I also think we have too few committers.
> Adding policy might completely stall the project...
> 
> If for every trivial update of a Python package we need not only submit a
> patch to the bugtracker, wait for QA, get back to the patch, resign it,
> push it and close the bug, but additionally wait for one of the two Python
> team members to have a look at it (or let an additional week pass),
> incentives to participate will tend to zero.
> 
> Your suggested policy can help against commits of too bad quality; but I
> do not think this is our problem, our problem is rather a lack of fast
> progress.
> 
> So I think we need to add committers, add committers to teams, encourage
> teams to engage in work, and if everything works smoothly, maybe add policy.
> 
> Andreas
> 
> 
--
Regards,
Bengt Richter

Re: Question on the process of packge withdrawal

[bokr]

Hi,

On +2023-02-28 11:30:21 +0100, Simon Tournier wrote:
> 
> I proposed to remove the package because it was broken and no one was
> willing to fix it.  What is the point to keep broken packages?
>

What is the purpose of a junk-yard for broken cars?

I think there is some use :) I kept an old VW going many decades
by more than once in my youth going with tools to a junk yard
where the deal was:
  Find what you need in some wreck, detach it with your own tools,
  bring it to the office, and negotiate a price.
  (the office guy could usually point you to the likely wrecks
  if you described what you needed, and would even offer to rent you
  some tools and help, all negotiable :)

IMO, it's a matter of storing the junk where it will not be a toxic liability
and nuisance, yet easily discovered by someone looking for "parts."

Software "parts" are a little different, but the R (remove & replace)
aspect seems similar ;-)

And it should be easy to keep an inventory of junk-yard contents by bug numbers.
Maybe somone would enjoy curating "junk" :)

Disclaimer: I am a terrible pack-rat ;/
(with no time to be junk curator, though I appreciate their work, along with
any{one,thing} helping me find what I want (rather than the other way around) :)

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

Re: git-fetch without a hash

[bokr]

Hi,

On +2023-01-11 16:34:41 +0100, Simon Tournier wrote:
> Hi,
> 
> On Mon, 09 Jan 2023 at 12:16, Ludovic Courtès  wrote:
> > Simon Tournier  skribis:
> >
> >> Maybe my question is naive but what is the use case for this (sha256 #f)
> >> in the first place?  Because maybe it could just error using some
> >> ’sanitize’ for the hash record field.
> >
> > There’s a couple of uses: Chromium, IceCat, and Linux-libre (IIRC).
> >
> > I don’t like that, but I’m not sure what it would take to change these
> > to  or something like that.
> 
> Well, from (gnu packages linux)
> 
> --8<---cut here---start->8---
>  (origin
>(method computed-origin-method)
>(file-name (string-append "linux-libre-" version "-guix.tar.xz"))
>(sha256 #f)
> --8<---cut here---end--->8---
> 
> and from (gnu packages gnuzilla)
> 
> --8<---cut here---start->8---
> (origin
>   (method computed-origin-method)
>   (file-name (string-append "icecat-" %icecat-version ".tar.xz"))
>   (sha256 #f)
> --8<---cut here---end--->8---
> 
> but not from Chromium, if I read correctly.
> 
> From my understanding, we could have something like,
> 
>   (sha256 (no-hash))
> 
> where ’no-hash’ would return a string, say
> "" or whatever else
> that would satisfy this hypothetical  ’sha256’ sanitizer.
> 
> 
> Cheers,
> simon
>

For portability to any hash algorithm that returns a hex string,
how about letting them hash a zero-length string (which can never
represent a package tarball or other archive), and using the
resulting strings as no-hash flags?

These strings must be unique for whatever hash algorithm,
so a short table could be used to recognize them as
no-hash indicators.

--8<---cut here---start->8---
$ sha256sum /dev/null
e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855  /dev/null
$ sha256sum <(echo -n '')
e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855  /dev/fd/63
$ echo -n ''|sha256sum
e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855  -
$ echo -n ""|sha256sum
e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855  -
--8<---cut here---end--->8---


For other hash values on your system, probably the below will show most.
Translating from hex to various base32 and other-base alphabets
is then trivial, (and open, i.e. permitting new hash representation strings).
--8<---cut here---start->8---
$ ls -1d /usr/bin/*sum|while read hasher;do \
  echo;echo "$hasher:"; "$hasher" /dev/null;done
--8<---cut here---end--->8---

WDYT?
--
Regards,
Bengt Richter

Re: UTF-8 progress bar

[bokr]

Hi Ludo, Akib, et al,

On +2023-01-30 23:02:43 +0100, Ludovic Courtès wrote:
> 
  ^^--- interesting: I see that thumb up emoji in mutt's display,
  but not in emacs, which I have configured mutt to use as my editor.

> 
> Julien Lepiller  skribis:
> 
> > I have a patch waiting (https://issues.guix.gnu.org/59975) that will
> > change progress bars to use some unicode characters. I think they look
> > better, but I'm a bit afraid they might not look right on some config,
> > so I'd like to know if your terminal is able to show these characters:
> >
> > "▏▎▍▌▋▊▉█▏▕"
>
 ---seems fine in tilix and Emacs PureOS/Wayland/Gnom
 e
> Confirmed to work for me in xterm and Emacs on X11 (Guix System).
> 
  ^^---as above
> 
> Ludo’.
> 

I suspect those characters could be made to work in Akib's console
if his kernel supports KMS and setfont etc ..

So I guess you, Akib, mean $LANG="en_US.utf8" in your execution
context is insufficient to make your system show the utf8 charaters
in question, not that there's no fix possible? ;)

IDK, but perhaps your app could use a wrapper that sets up a font,
along with a utf8 map that will show the necessay characters?

See:
info setfont
and
info showconsolefont

HTH
--
Regards,
Bengt Richter

Re: Struggling to write Dissecting Guix, Part 2

[bokr]

Hi Simon,

On +2023-01-26 12:17:27 +0100, Simon Tournier wrote:
> Hi,
> 
> On Wed, 25 Jan 2023 at 16:54, Wojtek Kosior via "Development of GNU Guix and 
> the GNU System distribution."  wrote:
> 
> >   here[1] is
> > the paper (written by someone at Microsoft, lol) where I found this
> > approach.
> 
> > [1] https://www.cs.tufts.edu/comp/150PLD/Papers/awkward.pdf
> 
> The author of [1] is Simon Peyton Jones [2].  One of the designers of
> the Haskell programming language and one of the main implementer of the
> Haskell compiler GHC.  And a great speaker and author. :-)
> 
> 2: 
> 
> Cheers,
> simon
> 

Indeed, Simon Peyton Jones is tops.
You may be interested in this[3], if you have not seen it:

3: 

>From the introduction:
--8<---cut here---start->8---
Functional logic languages have a rich literature, but it is
tricky to give them a satisfying semantics. In this paper we
describe the Verse calculus, VC, a new core calculus for
functional logical programming. Our main contribution is to
equip VC with a small-step rewrite semantics, so that we can
reason about a VC program in the same way as one does with
lambda calculus; that is, by applying successive rewrites to
it.

This draft paper describes our current thinking about Verse.
It is very much a work in progress, not a finished product.
The broad outlines of the design are stable. However, the
details of the rewrite rules may well change; we think that
the current rules are not confluent, in tiresome ways. (If
you are knowledgeable about confluence proofs, please talk
to us!) We are eager to enagage in a dialogue with the
community. Please do write to us.
--8<---cut here---end--->8---
Some ideas to enrich guix or the guile language pagoda?

It is interesting that Epic Games has apparently funded quite a
collection of heavies to do some deep abstract thinking.
I imagine SPJ is enjoying discussions. Check the author list!

I got the link at [4] which is much snappier serving than it was
before. (It's a place to go if you are in the mood for something chewy ;)

It also has interesting programming language historical genealogy diagrams.

4: 

(I hope they get https going ;-)

--
Regards,
Bengt Richter

Re: Packages grow, no longer fit on a 

[bokr]

On +2023-01-20 23:34:53 +0600, Akib Azmain Turja wrote:
> Csepp  writes:
> 
> I have a slow machine from about 10 years ago, and I'm really happy with
> it.  (I'm writing from this machine.)  I also have a slow unstable
> internet connection, so I understand the pain of download hundreds of
> MB of data without pause and resume support.  (I couldn't download the
> latest Guix GNU/Hurd QEMU image (just around 293 MB maybe?) even trying
> 8-10 times.)
>

Could you somehow use
wget -c 
to continue an interrupted download?
Or does the source not support that?

(see wget --help |less -- and scroll down to Download: section)

> -- 
> Akib Azmain Turja, GPG key: 70018CE5819F17A3BBA666AFE74F0EFA922AE7F5
> Fediverse: akib@hostux.social
> Codeberg: akib
> emailselfdefense.fsf.org | "Nothing can be secure without encryption."

--
Regards,
Bengt Richter

Re: Should Guix support writing CLI Common Lisp scripts? (Think Roswell)

[bokr]

Hi Jgart,

On +2022-12-27 19:23:18 +, jgart wrote:
> > I'm not sure what you mean if it is something beyond what we can do already 
> > with 'guix shell.' Do
> > you mean using a particular hashbang as well? 
> 
> Yes, that is one feature that I was nodding ambiguously at. Sorry
> 
> > guix shell sbcl sbcl-cl-csv unoconv -- sbcl --load myscript.lisp 
> > ~/Downloads/*.xlsx
> 
> That command is too long. What Roswell does is create binaries and installs 
> them in your PATH for your usage like a traditional script that you can call 
> without also having to call the interpreter in your terminal invocation.
> 
> I want to type just the following and have `myscript` be an executable 
> program available in my `guix home` environment:
> 
> > myscript ~/Downloads/*.xlsx

If bash is interpreting your script, could you use alias 
myscript=YOUR_MAGIC_HERE
to get the concise invocations you want?
(which bash BTW? -- from logind, child of that, or via a guix profile, or 
minimal-something ??)
┌──┐
│  help alias  │
├──┤
│ alias: alias [-p] [name[=value] ... ]│
│ Define or display aliases.   │
│  │
│ Without arguments, `alias' prints the list of aliases in the reusable│
│ form `alias NAME=VALUE' on standard output.  │
│  │
│ Otherwise, an alias is defined for each NAME whose VALUE is given.   │
│ A trailing space in VALUE causes the next word to be checked for │
│ alias substitution when the alias is expanded.   │
│  │
│ Options: │
│   -p  print all defined aliases in a reusable format │
│  │
│ Exit Status: │
│ alias returns true unless a NAME is supplied for which no alias has been │
│ defined. │
└──┘

> 
> I want an automated way to prepare the script for that command line user 
> experience. That is the convenience that roswell provides. I agree that is is 
> sweet sugar but I'm lazy and don't want to type long CLI invocations.
>

I think it's possible, the question for me is what language
do you want to code your automation in :)

> Thanks for sharing the above though.
> 
> It's great to see how people are using `guix shell`.
> 
> Given what I said, I might just do what you're suggesting John, because I'm 
> not sure when I'll be able to implement a solution like the roswell one in 
> Guix.
> 
> Thanks for your thoughts on the topic. They are appreciated.
> 
> all best,
> 
> jgart
>
--
Regards,
Bengt Richter

Re: Dissecting Guix -- blog post series

[bokr]

Hi,

On +2022-12-09 07:33:16 +, ( wrote:
> On Fri Dec 9, 2022 at 7:31 AM GMT, 宋文武 wrote:
> > I think it's missing what "build-derivations" do, or "Part 0: Store".
> 
> Hmm, do you mean adding an example of building a derivation in Scheme with
> ``build-derivations''?  I'll definitiely add that :)
> 
> -- (

Where is a "What can I trust?" section?

I.e., when some well-meaning enthusiast says,

--8<---cut here---start->8---
"Can we package the "warm-fuzzy-floss-name" package that they have at
http://www.lesser-known-but-nice-sounding-distro.org/fantabulous/;
--8<---cut here---end--->8---

How does a gullible noob like me know what the dangers might be, (e.g. http:)
and how to avoid (most of) them by finding a guix version that has been
gone through with a fine-tooth comb by trusted guix devs and has been
re-hosted at gitlab or gnu.org, etc ... for added security?

--
Regards,
Bengt Richter

Re: Proposing commit access for 'unmatched-paren'

[bokr]

Hi,

TL;DR: IMO commit access is too dangerous to grant on the basis of
appreciating help, and/or workflow convenience.

Trusted committers are defenders of FLOSS.

There must be very strict trust requirements for commit access
or FLOSS will become vulnerable to "mistakes" with plausible denial,
like over-eagerness to help, oops, introduced by anti-FLOSS grinches.

Temporary introduced problems, even if not dangerous, work as a form
of denial-of-service attack on the development process itself.

They also promote a not-ready-for-production-use view of the whole project,
despite the great sucess and adoption stories.

No one is perfect, so there will be dumb mistakes to forgive,
but IMO recruiting committers should be thought of as recruiting
defenders of the holiest treasure of s/w.

On +2022-11-15 10:32:45 -0800, Felix Lechner wrote:
> Hi,
> 
> As a new user, I needed lots of help. I also use software that is not
> packaged in Guix.
> 
> In preparing my patches for submission I relied extensively on the
> guidance so generously offered by the IRC user 'unmatched-paren'. I
> thoroughly appreciated their advice, both on the technical as well as
> on the human level.
> 
> Now I learned that 'unmatched-paren' would like to request commit
> access to the Guix repository, but they were humbled by their own
> uncertainty on how to illustrate their value. I then offered to write
> this letter.
> 
> Please consider 'unmatched-paren' for commit access. Thank you!
> 
> Kind regards,
> Felix Lechner
> 
> P.S. Anyone who reads this and agrees with me, please chime in by
> replying to this message. Thanks!
> 
--
Regards,
Bengt Richter

Re: How long does it take to run the full rustc bootstrap chain?

[bokr]

Hi,

On +2022-10-22 09:48:50 -0400, Maxim Cournoyer wrote:
> Hi,
> 
> Félix Baylac Jacqué  writes:
> 
> > Hey Guix,
> >
> > I'd be curious to know how long it takes to run the full rustc bootstrap
> > chain on the Guix build farm. I'm sadly not sure how to approach this
> > problem.
> >
> > Is there a way to extract this information from Cuirass or the Guix data
> > service?
> >
> > Félix
> 
> It used to be 16 hours on a Ryzen 3900x machine, then it got halved to 8
> hours with the work to bootstrap from 1.39, and recently we're
> bootstrapping from 1.54, so it must have been greatly reduced again.
> 
> Looking at (gnu packages rust), the mrustc-based bootstrap starts with
> 1.54.0.  This one is expensive, probably around 1 h 30 or more on a
> Ryzen 3900x CPU (24 logical CPUs).
> 
> The intermediate builds are typically around 15-20 minutes on that
> machines, with the last one taking a bit more (30 minutes), so the
> current bootstrap on such a machine should take about:
> 
> 1.54.0: 1h30m
> 1.55.0 - 1.60.0: 6 X 20 min = 1h20m
> 1.60.0: final build with tests and extra tools: 30 min
> 
> The total should be around 3 h 20 on a fast modern x86_64 machine.  I
> suppose the time for berlin to build it takes about this.
> 
> HTH!
> 
> -- 
> Thanks,
> Maxim
> 

I'm curious what
--8<---cut here---start->8---
$ lsblk -o size,model,type,tran,vendor,name|grep -Ei 'ssd|model';echo;lspci 
|grep -i nvme
--8<---cut here---end--->8---
on your relevant machines would show.

I opted for the best SSD available for my purism librem13v4 at the time,
and was really happy with seems like 10x faster than the SATA SSD in my older
but still i7 x86_64 previous laptop. Prob really 4-5x faster.

So above combo command line now gives me
--8<---cut here---start->8---
SIZE MODEL  TYPE  TRAN   VENDOR   NAME
465.8G Samsung SSD 970 EVO Plus 500GB disk  nvmenvme0n1

01:00.0 Non-Volatile memory controller: Samsung Electronics Co Ltd NVMe SSD 
Controller SM981/PM981
$ 
--8<---cut here---end--->8---

What /is/has been/ on your machines? Could your improved times be part from 
SSD/controller changes?

There's really a huge difference  between SATA and 4-lane pci
(where both ends can handle it, which may require fw update or not be available)
Obviously 4 lanes is also going to be faster than one.

--
Regards,
Bengt Richter

Re: Capitole du Libre at Toulouse

[bokr]

Hi Andreas, Vagrant, et al

On +2022-09-25 10:37:52 -0700, Vagrant Cascadian wrote:
> On 2022-09-25, Andreas Enge wrote:
> > I am not quite sure how one presents a distribution at a booth, since
> > there is not really much to attract the eye, or is there?
> 
> I know Debian used to have an automated debian-installer running on a
> screen looping through all the supported languages of the installer.
> Would be cool to implement something similar for Guix someday, but
> probably not in a few weeks...
> 
> Maybe just a screen capture with large fonts of someone doing some guixy
> things and play it on a loop?
> 
> 
> live well,
>   vagrant

There is a nice guix web entry point at [0]
[0] https://guix.gnu.org/

┌───┐
│ NB: If your camera doesn't recognize the qr code, try │
│ reversing the video so the pattern is black on white. │
└───┘

Anyway I thought I'd grab the good words there and suggest
making a poster for a booth wall, like

--8<---cut here---start->8---
█
█
 ▄ █▄ █▄ ▀ ███ ▄ 
 █   █ █▄ ▄ ▄ ▀▀██ █   █ 
 █▄▄▄█ █▀█ █▀ ██ █ █▄▄▄█ 
▄▄▄█▄█ █ █▄█ █▄▄▄
 ▀ █▀▀▄▄█▀ ▄ ██ ▀▀▀ █▀▄▀ 
  █ █ ▄█ ▄▀███▀  ▀▄▀█ ▄█▄
▄██ ▀▄▄▄▀▀█▄ ▀▄▀ █  ███▀ 
▄▄▀█▀▄▄ █  ▀ █▀ ▀ █▀▀ ▄█▄
▄▄██▄▄▄█▀▀███ ▄▄ ▄▄▄ ██▄▀
 ▄ █▄▄█▄█▀█▀ █▄█ ██▀▄
 █   █ ██ ▀▄ ▄█▄  ▄▄ █▀▀▄
 █▄▄▄█ █▄██▀ ▄ █▀█▀  ▄█▄▄
▄▄▄█▄▄▄██▄▄██▄██▄
█
█

Liberating. Guix is an advanced distribution of the GNU
operating system developed by the GNU Project---which
respects the freedom of computer users.

Dependable. Guix supports transactional upgrades and
roll-backs, unprivileged package management, and more. When
used as a standalone distribution, Guix supports declarative
system configuration for transparent and reproducible
operating systems.

Hackable. It provides Guile Scheme APIs, including
high-level embedded domain-specific languages (EDSLs) to
define packages and whole-system configurations.

If you don't use GNU Guix as a standalone GNU/Linux
distribution, you still can use it as a package manager on
top of any GNU/Linux distribution. This way, you can benefit
from all its conveniences.

Guix won't interfere with the package manager that comes
with your distribution. They can live together. TRY IT OUT!
Blog Celebrating 10 years of Guix in Paris, 16--18
September

It's been ten years of GNU Guix ! To celebrate, and to
share knowledge and enthusiasm, a birthday event will take
place on September 16--18th, 2022 , in... 10 years of
stories behind Guix

It's been ten years today since the very first commit
to what was already called Guix---the unimaginative name
is a homage to Guile and Nix , which... Keeping
one's home tidy

How much effort to recreate your work environment when you
switch to a new machine? What would it take to roll back to
your previous environment once you've noticed... ALL
POSTS Contact IRC Channel

Join the #guix channel on the Libera Chat IRC network to
chat with the community about GNU Guix or to get help in
real-time. ... Info Mailing List

Subscribe to the info-guix low-traffic mailing list to
receive important announcements sent by the project
maintainers (in English). ... Help Mailing List

Subscribe to the Help mailing list to get support from the
GNU Guix community via email. You can post messages in
English though we also accept other languages ALL
CONTACT MEDIA Made with  <3 :-))  by humans and powered by GNU
Guile. Source code under the GNU AGPL.

--8<---cut here---end--->8---

and then trim the above down to just the qr code and
maybe the first three paragraphs of the above, and format it
to fit 2^N images on an A4 that could be cut into small handouts
and spread around at other booths that might have counter room
for a little stack or mini-poster.

Or business card size could be cool for scattering guix seeds :)

Of course, going by the guix booth with a smart-phone in hand,
all you need to do is point the camera at the qr code and save
a bookamrk.

I would have made a pdf, but pdflatex needs something to handle
utf8, so I'm way past the time I was going to spend on this :)

The text above is now ascii (after hacking some filters :)
but the qrcode is utf8.

I see contributing.texi has some utf8 characters:
--8<---cut here---start->8---
$ ord < doc/contributing.texi \
> | ord < doc/contributing.texi|tr ' ' $'\n' \
> | sort -n|uniq -c |pr -t -4; \
> 

Re: Sanitizer of record fields?

[bokr]

Hi Simon, et al

On +2022-09-08 09:59:15 +0200, zimoun wrote:
> Hi,
> 
> The website is currently failing [1] to build because a typo in some
> package declaration.  The error message is not very helpful,
> 
> srfi/srfi-1.scm:241:2: In procedure map:
> In procedure map: Wrong type argument: "https://www.qt.io/;
> building pages in '/tmp/gnu.org/software/guix'...
>

ISTM this "wrong type argument" is an infuriatingly common
and typically useless error message.

Would it be possible to have a debugging hook where the message is output
which if activated would show the call stack, so one could see where in
the user code it happened?

Activation could I imagine be by guile checking e.g.
"GUILE_THROW_DEBUG_WRONG_ARGUMENT" on invocation, to turn on the hook
in a way that would have zero performance effect if not activated.

Alternatively, could a wrapper start one's problem code using GDB
to put a break point at the hook place, pre-setting up the call
args etc and starting GDB so you could type run or step etc.?

Can geiser trace stuff? IWBN to have something analogous to bash's
shopt for printing expression sources as they are read and/or executed.
Does something like that exist?

Thoughts? :)

> and it was not straightforward to find the issue.  Using some ’pk’ in
> the website builder restricted the origin of the failure; but still.
> Thanks to Florian, they found this commit [2] introducing the package
> qtshadertools where a field is unexpected,
> 
> +(license (package-home-page qtbase
> 
> and boum!
> 
> It seems impossible to detect that typo at compile-time because fields
> do not have a specific type (except by convention).  Therefore, how can
> we detect such typo?
> 
> We could add a lint checker.  Is it a “good” idea?
> 
> Because lint is not always applied, a check should be done when running
> ’make’ or a special target.  Is it a “good” idea?
> 
> 
> 1: 
> 2: 
> 
> 
> 
> Cheers,
> simon
>
--
Regards,
Bengt Richter

Re: developing javascript with guix

[bokr]

ence for users from the various language library commons 
> > if we build language-specific landing pages with instructions, 
> > documentation, and package search that affirm they are in the right place 
> > and will find the right stuff, and don't make much assumption that the 
> > person knows what they are doing.
> 
> I agree. 
> 
> 
> Using the original design of Guix website, this information could be 
> accessible from "Home page → Guix in Your Field → Software developement". 
> Clicking on that button would take the user to a Software Development page, 
> which would link to language specific information to integrate Guix in one's 
> workflow. So there would be URLs like these:
> 
> https://guix.gnu.org/en/software-development/
> https://guix.gnu.org/en/software-development/javascript/
> https://guix.gnu.org/en/software-development/python/
> https://guix.gnu.org/en/software-development/ruby/
> 
> The "Guix in Your Field" idea seems kind of forsaken, but I think it is quite 
> important.
> 
> 
> > I'll pitch in on this effort! I have experience with Ruby, JavaScript and 
> > Python packaging and tooling and am to help build out all those areas. Our 
> > emerging teams can help lend some structure to this effort too, I imagine.
> 
> I'd say, pick one language and start :)

pub   RSA 2048/7A39C6A9 2020-07-23 luis.felipe...@protonmail.com 

> sub   RSA 2048/E8573DB1 2020-07-23
> 

I like to have stuff available off line
(and therefore also serving as distributed backup if^H^H when things disappear 
:)

So whatever you provide on the internet, I would like an easy way to clone 
what's
being served, so I can see it in the same way but locally on my laptop or lan.

I think IWBN to import web site contents via installing/updating
a guix package, maybe based on a git repo of web site (so it's also
available to users not yet having guix installed, i.e., so a simple
snippet could also put it in
http://localhost/guix/
) (with safety-sanitizing).

I notice that my laptop system (pureos derivative of debian) starts up
an instance of apache2. Maybe yours des too?
--8<---cut here---start->8---
[17:05 ~/bs]$ ps -ef|grep apache
root   791 1  0 13:53 ?00:00:00 /usr/sbin/apache2 -k start
www-data   793   791  0 13:53 ?00:00:00 /usr/sbin/apache2 -k start
www-data   794   791  0 13:53 ?00:00:00 /usr/sbin/apache2 -k start
bokr  5531  2173  0 17:05 pts/000:00:00 grep apache
--8<---cut here---end--->8---

On my laptop, the command
--8<---cut here---start->8---
firefox-esr http://localhost/
--8<---cut here---end--->8---
brought up a default test page [1], which suggests to me that
we could make a guix package to install any desired docs or files
that apache2 can serve, and make them accessible to your
preferred browser via something like

--8<---cut here---start->8---
firefox-esr http://localhost/guix/index.html
--8<---cut here---end--->8---

WDYT?

[1] -- after the default page came up, I selected and copied the text
and got the following, justifying for better reading here (or interfering
with your presenter's line wrapper, sorry if so :)

--8<---cut here---start->8---
[17:05 ~/bs]$ wl-paste |tr -d $'\r'|blockjust -left=0 -width=60
--8<---cut here---end--->8---
produced:

--8<---cut here---start->8---
This is a modified index.html

This is the default welcome page used to test the correct
operation of the Apache2 server after installation on Debian
systems. If you can read this page, it means that the Apache
HTTP server installed at this site is working properly. You
should replace this file (located at
/var/www/html/index.html) before continuing to operate your
HTTP server.

If you are a normal user of this web site and don't know
what this page is about, this probably means that the site
is currently unavailable due to maintenance. If the problem
persists, please contact the site's administrator.

By default, Debian does not allow access through the web
browser to any file apart of those located in /var/www,
public_html directories (when enabled) and /usr/share (for
web applications). If your site is using a web document root
located elsewhere (such as in /srv) you may need to
whitelist your document root directory in
/etc/apache2/apache2.conf.

The default Debian document root is /var/www/html. You can
make your own virtual hosts under /var/www. This is
different to previous releases which provides better
security out of the box. Reporting Problems

Please use the reportbug tool to report bugs in the Apache2
package with Debian. However, check existing bug reports
before reporting a new bug.

Please report bugs specific to modules (such as PHP and
others) to respective packages, not to the web server
itself.
--8<---cut here---end--->8---

--
Regards,
Bengt Richter

Re: Guix home and operating-system

[bokr]

Hi Andrew,

On +2022-07-27 11:34:14 +0300, Andrew Tropin wrote:
> On 2022-07-18 11:38, Ludovic Courtès wrote:
> 
> > Hi,
> >
> > Andrew Tropin  skribis:
> >
> >> I don't remember all the details and where I stopped, but the highlevel
> >> idea is following:
> >>
> >> - Define a system services, which contains (user . home-environment) pairs.
> >> - Build home environments on system reconfigure.
> >> - Activate home environments on boot.
> >
> > That would be a nice addition!
> 
> For future readers, the work is happenning in #56669
> (Message-ID: 63960cf762aec1ed2c4182f49cac66bc37fce2aa.ca...@rdmp.org)
> 
> -- 
> Best regards,
> Andrew Tropin

I'm guessing you have handy emacs macros or other means to turn that
message ID and/or bug number to a browsable URL, but for others it
will save them time if you post a clickable URL also :)

How much is missed by those who don't participate in IRC?
I wonder how one would make a history book section to include
all the "the work is happening" venues :)

IMO zimoun sets a great example referencing resources, along with ludo,
(not to leave out people whose posts are fine with one or two URLs :)

I use this to browse a bug by  number:
--8<---cut here---start->8---
#!/usr/bin/bash
# browse-bug

num="$(echo "$1"|tr -cs '0123456789' ' '|tr -d ' ')"

my_browser="${MY_BUG_BROWSER:-lynx}"
if [ -n "$num" ];then
$my_browser "https://debbugs.gnu.org/cgi/bugreport.cgi?bug=$num;
else
echo "\
Usage: [MY_BUG_BROWSER=] browse-bug BUG_NUMBER (not '$1' -> 
'$num')
BUG_NUMBER will be taken from \$1 word stripped of non-digits if any
If you set MY_BUG_BROWSER to firefox-esr, you can run this in the 
background like
browse-bug '#56669' & 
but lynx will want interaction from you on stdin, so no '&'
NB: if you Ctl-V the #, delete it or quote it, or bash will throw it away 
as comment.
"
exit 1
fi
--8<---cut here---end--->8---
HTH :)
--
Regards,
Bengt Richter

Re: python-pytest in references graph

[bokr]

On +2022-07-25 08:23:57 +0200, Lars-Dominik Braun wrote:
> Hi,
> 
> > It should, but sometimes there are bugs in the package definition or 
> > build system, in this case causing python-rdflib to refer to the 
> > native-input python-pytest.  Likely it's the 'add-install-to-path' phase 
> > adding too much, a known issue, which could be solved by separating 
> > inputs and native-inputs on the build side when compiling natively (and 
> > not only when cross-compiling) (currently they are merged together into 
> > 'inputs'), though non-trivial.
> the issue is indeed a known bug https://issues.guix.gnu.org/25235
> 
> Lars
> 
>
what's up^H^H down with that URL??
---cut here---start->8---
[15:03 ~/bs]$ ping -c 3 issues.guix.gnu.org
PING issues.guix.gnu.org (141.80.181.40) 56(84) bytes of data.
64 bytes from 141.80.181.40 (141.80.181.40): icmp_seq=1 ttl=46 time=88.7 ms
64 bytes from 141.80.181.40 (141.80.181.40): icmp_seq=2 ttl=46 time=81.10 ms
64 bytes from 141.80.181.40 (141.80.181.40): icmp_seq=3 ttl=46 time=81.7 ms

--- issues.guix.gnu.org ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2ms
rtt min/avg/max/mdev = 81.727/84.125/88.669/3.214 ms
[15:03 ~/bs]$ wl-paste 
https://issues.guix.gnu.org/25235
[15:04 ~/bs]$ wget https://issues.guix.gnu.org/25235 >> gxiss23235.txt
--2022-07-25 15:05:57--  https://issues.guix.gnu.org/25235
Resolving issues.guix.gnu.org (issues.guix.gnu.org)... 141.80.181.40
Connecting to issues.guix.gnu.org (issues.guix.gnu.org)|141.80.181.40|:443... 
connected.
HTTP request sent, awaiting response... 502 Bad Gateway
2022-07-25 15:05:57 ERROR 502: Bad Gateway.
---cut here---end--->8---

--
Regards,
Bengt Richter

Re: Building, packaging and updating Guix with confidence

[bokr]

Hi Josselin,
I have some naive questions below :)

On +2022-07-07 16:34:17 +0200, Josselin Poiret wrote:
> Hello,
> 
> Zhu Zihao  writes:
> 
> > If your foreign function use case is very trivial? Why not give Guile
> > dynamic FFI a try?
> 
> That could be another option, but I'd like to have autoconf be able to
> detect whether the target supports things like posix_spawn and
> getrlimit, which I use in the code.
> 
> > It's possible to use guix channel to test a local guix repo. A short
> > example here.
> 
> Right, but for the example of adding extensions it won't work since
> there's a part of `guix pull` that uses the guix package, as well as in
> the installer or system-wide Guix, as I outlined before.  The issue [1]
> I outlined in the opening mail was an issue that is specific to the guix
> package method, so there really isn't a way to uniformly test changes
> without knowing the intricacies of the different builds and where they
> end up (I do know these, having run into these issues myself before).
> 
> > This is somewhat "the bootstrap problem". It's very ideal if we can
> > describe the build graph in Guix with derivations. But we still need a
> > daemon first to process derivations. So we need to build daemon without
> > Guix.
> 
> I don't think that's the case, (guix self) relies on a working daemon
> connection before anything else, the built daemon will just be a part of
> the resulting `guix pull` profile, but won't be used to build the new
> Guix (as a matter of fact, the build daemon is built... using the build
> daemon!).
> 
> > This issue may be solved by rewriting daemon in Guile. If daemon is
> > written in Guile. We can run it without compilation.
> 
> I don't think this is directly related, although some changes that we
> could bring to it would definitely ease what I'm proposing here: having
> a way to build things directly without relying on a root-owned daemon
> running would make the bootstrapping problem easier to solve.
> 
> Best,
> -- 
> Josselin Poiret
> 

Naively:

Why does "the" guix daemon per se need root access at all?

Why not let it be an ordinary peer user? The main one already is, UIAM.
Why couldn't it protect /gnu/ storage as a user which the kernel can
keep others from writing to in the usual way?

Another option for managing storage and quickly switching access might be
if you trust the wayland daemons and their protocol for managing a single
user thread's buffers. You might be able to use its event loop to schedule
multiplexed concurrent build jobs.

A peer user daemon scenario might also open possibilities for networked
job distribution beyond a local router's connections, I imagine?
--
Regards,
Bengt Richter

Re: grafted package and CLI

[bokr]

Hi Simon,

On +2022-07-07 18:58:41 +0200, zimoun wrote:
> Hi,
> 
> On Thu, 07 Jul 2022 at 17:09, Ludovic Courtès  wrote:
> 
> > You mean hide with the ‘hidden?’ property?
> 
> I do not know what I mean. ;-)
> 
> The replacement could have an ’hidden?’ property or not being
> ’define-public’.  
> 
> > Good question.  There’s probably little point in exposing the original
> > (replaced) version, so yes, hiding it makes sense I guess.  Should we
> > just do that systematically?
> 
> Well, we should follow the same strategy independently of the version
> bump.  Systematically hide original (replaced) original version.
> 
> Bah I do not know, what other think?
> 
> 
> Cheers,
> simon
>

"Other" here, reacting to word "hidden":
(equal? hidden some-trojan-horse-contents) :-)

I like "hidden" when it de-clutters my workflow, BUT:

Only when I know it comes with a simple toggle to a view
that reveals what is hidden, to any desired detail,
e.g., with a brief summary and a menu (a la info, with
Ctl-s searchability) to inspect potentially everything reachable.

Otherwise I worry about what's hidden :)

E.g., I'd like to be able to toggle into a first level inspection view
with some default info and a command line prompt where I could type
a repl CLI command like
reveal-vulns [OPTS]...
that by default starts in the current command line parsing environment,
and with a "-all" opt would show things like OTTOMH e.g., (not all vuln spots 
here)

   * current execution context, e.g. pidparents defined as:
---cut here---start->8---
#!/usr/bin/bash
# ~/bin/pidparents
pid=${1:-$$}#this process if no pid specified as $1
while [ $(($pid)) -gt 0 ]; do
  ps h -p $pid -o comm,tt,pid,stat,args
  pid=$(ps -q $pid -o ppid=)
done
---cut here---end--->8---
   * door to "systemctl status" etc if available 
   * OS kernel info -- uname -a and doors to details
   * GPU info, other potential attack-via-DMA programmable devices
   * CPU info, fully capable of secure hypervising of VMs? etc. 
   * BIOS type, current booting mode, etc, or info how to boot grub2 or
 whatever tool on the current system to explore that.
   
   * what is not built from guix cloned repo sources (substituted binaries, etc)
   * what is trusted mirror list, with estimate of timeliness vs master sources
   * what is invocable that uses setuid or setgid or sudo or su
   * can a setgid video group invoker present me with a spoof screen?
   * will a newly plugged in USB be accepted as a keyboard just because
 it claims to be, without vetting by asking human and auth by serial?
 - will keystrokes from it be injected into the current keyboard
   input stream? (Insanely promiscuous legacy practice IMO)
   * unusual ELF files (summary: how many exist,+ doors to detailed views)
   * impure references in /gnu/... simple summaries, doors to full details
   * status w.r.t. CVE announcements, (carefully, no tipoffs re exploitables)
   * databases in use, SQL injection vulns?
   * mystery daemons running?
   * hardware error rates, trends
   * ...

In short, I'd like reveal-vulns to give me a complete inventory
of my current vulnerablilities to a selectable detail level.
I know "complete" would be magic :)

I imagine there must be many attempted versions in existence.
Is there a guix package? (I confess not having searched ;/ )
--
Regards,
Bengt Richter

Re: repl macro (metacommand?) for guix CLI (sub)commands

[bokr]

Hi Ludo',

On +2022-07-07 09:31:34 +0200, Ludovic Courtès wrote:
> Hi!
> 
> jgart  skribis:
> 
> > This is because each of those "CLI calls" end up running `(exit 0)`
> > at the end in some form or another.
> 
> Note that Guile’s ‘exit’ throws a ‘quit’ exception, which can be caught.

Any possible gotchas in throwing 'quit' re flush-close-sync?

> 
> Ludo’.
>
--
Regards,
Bengt Richter

Re: repl macro (metacommand?) for guix CLI (sub)commands

[bokr]

Hi,

On +2022-07-06 08:44:32 +0200, zimoun wrote:
> Hi,
> 
> On mar., 05 juil. 2022 at 17:27, jgart  wrote:
> 
> > That's a good question! Maybe we should make a feature table and analyze
> > what we currently have exposed to decide what we might want in the near
> > future that we don't currently have.
> 
> What is already exposed:
> 
> --8<---cut here---start->8---
> $ guix repl
> GNU Guile 3.0.8
> Copyright (C) 1995-2021 Free Software Foundation, Inc.
> 
> Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'.
> This program is free software, and you are welcome to redistribute it
> under certain conditions; type `,show c' for details.
> 
> Enter `,help' for help.
> scheme@(guix-user)> ,help guix
> Guix Commands [abbrev]:
> 
>  ,run-in-store EXP - Run EXP through the store monad.
>  ,enter-store-monad- Enter a REPL for values in the store 
> monad.
> 
> scheme@(guix-user)>
> --8<---cut here---end--->8---
> 
> And patch#56114 [1] introduce in addition:
> 
>  ,verbosity LEVEL  - Change build verbosity to LEVEL.
>  ,lower OBJECT - Lower OBJECT into a derivation and 
> return it.
>  ,build OBJECT - Lower OBJECT and build it, returning its 
> output file name(s).
> 
> 
> 1: 
> 
> 
> >> Is it possible to detect if an interactive call?  I was thinking to add
> >> a global parameter in ’(guix scripts repl) and then this new
> >> ’maybe-exit’ could check it; but I guess Guile provides a better
> >> mechanism for checking interactiveness.
> >
> > Do you know if guile provides a way of checking that? Should we ask on
> > the guile mailing list or should we read more code first to see what's
> > currently provided?
> 
> I do not know about a Guile feature allowing to check the
> interactiveness.  It seems worth to ask on Guile mailing list because,
> if such feature exists then, I have missed from the Guile manual.
> 
> 
> Cheers,
> simon
> 

I think (IANA bash expert) PS1 should be a pretty good indicator,
unless something funny is going on :)

(Note the difference between executing and sourcing):

(IDK if other shells use PS1 so it would work in such environments)
I looked in man ps to see if possibly ps -o  could make
an easy check (seems like there ought to be, but I am out of time
after almost an hour of experimenting :/ )

--8<---cut here---start->8---
[13:23 ~/bs]$ guile --no-auto-compile -c '(display (getenv "PS1"))(newline)'
[\A \w]\$ 
[13:24 ~/bs]$ ./guile-non-int-call 
PS1_val='#f'
#f
[13:24 ~/bs]$ source ./guile-non-int-call 
PS1_val='[\A \w]\$ '
[\A \w]\$ 
[13:24 ~/bs]$ cat -nA ./guile-non-int-call
 1  #!/usr/bin/bash$
 2  PS1_val="$(guile --no-auto-compile -c '(display (getenv 
"PS1"))(newline)')"$
 3  echo "PS1_val='$PS1_val'"$
 4  guile --no-auto-compile -c '(display (getenv "PS1"))(newline)'$
[13:25 ~/bs]$ 
--8<---cut here---end--->8---

HTH
--
Regards
Bengt Richter

Re: guix refresh to a specific version?

[bokr]

On +2022-07-04 17:53:42 +0200, zimoun wrote:
[ ... ]
> It is indeed a limitation of the Bioconductor importer and the issue is
> discussed here:
> 
> http://issues.guix.gnu.org/issue/39885
> http://issues.guix.gnu.org/issue/54787
>

For me, doing s/http/https/ on above, then
--8<---cut here---start->8---
firefox-esr 'https://issues.guix.gnu.org/issue/39885' &
--8<---cut here---end--->8---
seems to connect ok.

Just wondering if you are posting these as "http" links for some
hidden reason :)
--
Regards,
Bengt Richter

Re: “Building a Secure Software Supply Chain with GNU Guix”

[bokr]

On +2022-06-30 16:13:10 +0200, Ludovic Courtès wrote:
> Hello Guix!
> 
> I’m happy to announce the publication of a refereed paper in the
> Programming journal:
> 
>   https://doi.org/10.22152/programming-journal.org/2023/7/1
> 
> It talks about the “secure update” mechanism used for channels and how
> it fits together with functional deployment, reproducible builds, and
> bootstrapping.  Comments from reviewers showed that explaining the whole
> context was important to allow people not familiar with Guix or Nix to
> understand why The Update Framework (TUF) isn’t a good match, why
> Git{Hub,Lab} “verified” badges aren’t any good, and so on.
> 
> What’s presented there is not new if you’ve been following along, but
> hopefully it puts things in perspective for outsiders.
> 
> I also think that one battle here is to insist on verifiability when a
> lot of work about supply chain security goes into “attestation” (with
> in-toto, sigstore, Google’s SLSA, and the likes.)
> 
> Enjoy!
> 
> Ludo’.

Congratulations!

And thank you! I needed that assurance that guix really takes trust
seriously, and has a convincing internals story to back it up.

The "artifact" at [1] has a README.md [2] that's IMO definitely
also worth a read even if you aren't going to execute the image.

[1] 
[2] 

About this example (I like documentation that provides
things you can try):
--8<---cut here---start->8---
  5. Going back to our target revision, we can see that `gpg` can indeed
 verify signatures now: `git checkout
 20303c0b1c75bc4770cdfa8b8c6b33fd6e77c168 && git log --oneline
 --show-signature`.  `gpg` warns about expired keys but, as the
 paper notes, OpenPGP key expiration dates are ignored for our
 purposes (and the authentication code in Guix does *not* use
 `gpg`).
--8<---cut here---end--->8---

I think IWBN to have some kind of trust code come with that git output,
like gpg's 1-5 but indicating how well the committer/signer trusts
that using the code will *not* cause a problem.

I would like it if every commit had to have a code like that.

Even if it was "0," indicating that the committer judged
security to be irrelevant, I'd feel better knowing it was
part of committer workflow to be nudged into thinking
about the security aspect of the commit.

(Code alternative: an answer to the old real-opinon-extractor:
"How much money at what odds will you bet me this 
commit will not cause me problems?" ;-)


Hm, actually I think a 3-digit LTS code is required for reviewing:
with L indicating trust that the contribution is Legally ok,
and  T indicating trust in Technical competence of contributors
snd  S indicating trust in the Social aspect of the contribution crim/saint

OTTOMH encoding: digits 0-9: 0=NO Info, 1-9: subtract 5 =-> -4..+4,
with negatives meaning un-good opposites of positives. So code 191 would
be -4,+4,-4 for e.g.
  L-4: certain to have patent problems,
  T+4: contributed by a professional hacker,
  S-4: known criminal in supply chain.


--
Regards,
Bengt Richter

Re: Dealing with upstream issues

[bokr]

Hi zimoun, et al,

On +2022-06-28 18:25:05 +0200, zimoun wrote:
> Hi,
> 
> On Tue, 28 Jun 2022 at 14:31, Maxime Devos  wrote:
> 
> > You often close bugs with as rationale: ‘no response since X months,
> > hence closing’, so it seems to me that you would simply close bug
> > reports if the bug reporter is gone.
> 
> [...]
> 
> > That's the issue I wanted to highlight -- issues are closed before
> > being fixed when the the reporter disappears (and hence, cannot provide
> > "more info", or has other things to do than provide a fix by
> > theirselves), even if the bug is understood.
> 
> These claims are inaccurate.  And it appears to me unfair considering
> all the amount of time I personally spend on old bug triage; instead of
> doing other (funner?) things.
> 
> My workflow dealing with old bugs is: pick one and read the report (and
> the complete thread, if any), then,
> 
>  1. the report provides enough information for reproducing; I try to
> reproduce myself and report more info, and then I try to collaborate
> for fixing or closing.
> 
>  2. the report does not provide enough information to understand what
> the bug is about or to find a way to reproduce; then I ask more info
> – sometimes my reply is even the first one, then,
> 
> a) an answer is back so it is similar as #1.
> 
> b) no answer after 2 or more weeks, so I try to determine if the
>report is actionable and if the next action is fine-grained
>enough to be doable.  After 2 or more weeks, I ask again.
> 
>Therefore, if a bug report after 2 or 3 years is not commented,
>especially after 2 or more attempts to understand and ask for the
>next steps without an answer back by the whole community, what
>could be the action other than just close the report.
>

Nothing, except maybe special archiving, or tagging for indexing?

By bug closing time, you have typically produced the best summary
of the bug chase, with clues and tips and examples for reproducing
and links where to find more info, such as links to Ludo's
(particularly, but others too) debugging examles. ( Kudos and thanks :)

So it's a matter of making sure your valuable work is archived for
easy use in future bug chases, ISTM.

Of course, your posts /are/ archived in the mailing lists.
(I like the POP3 mbox-format archives, where it's easy
to grep the headers. I do wget -c 
to make myself copies of selected mail list months,
so I can search offline and view with mutt.

What I'd like is something in the Subject: line
to make it greppable for /both/ what the bug is about
and how it was closed, i.e. bug status.

Maybe if a post that says "closing" could have
"[closing: ]" in the Subject: line, where
 could say "fixed upstream" or "unresolved"
or whatever (bikeshed for dev ideas?).

Then you could use "[closing: unresolved]" in the closing
post Subject: line for a case that withered from inattention,
(your 2b) but still looks suspicious (if you think so).

E.g. suspicious like an fseg that went away because
new linkage for an update made the bad write
clobber something still, but without fseg:
It would be misleading to mark that "fixed" IMO.
Maybe "disappeared" :)

Anyway, the idea is to make the Subject: line greppable for both
what the bug is about and its status when it was closed.

> Ultimately, nothing is perfect and people are doing their best with
> their resource at hand; at least, I do my best with the resource at my
> hands.  I would be more than happy if more people would try to sort,
> classify or fix the old bugs.  Maybe, you will join the effort ?
> 
> I stop now the discussion in this thread since I do not see what we are
> discussing.
> 
> Cheers,
> simon
> 
--
Regards,
Bengt Richter

Re: Wiki && Re: [feature request] merge sxml->html from (haunt html) into guile?

[bokr]

On +2022-06-28 22:13:58 +0200, Maxime Devos wrote:
> Blake Shaw schreef op wo 29-06-2022 om 01:34 [+0700]:
> > Which brings up another thing I've been considering working on thats
> > been discussed in the Guix community: the need for click-to-edit
> > wiki, written in Guile. [...]
> 
> I don't think ‘written in Guile’ has been discussed?
> 
> Also, I don't see the point in writing our own wiki software in Guile
> when there's already plenty of Wiki software in existence with lots of
> tools for moderation, version control, backups, lots of testing, etc.
> Why not reuse pre-existing work instead of reinventing the wheel (likely
> poorly, at least at first)?
>

E.g.? :

https://docs.racket-lang.org/web-server/index.html

Not guile, but close in the family tree :)
(I don't know how good their server stuff is, but
I get the impression they consider it production quality)

> Greetings,
> Maxime.
--
Regards,
Bengt Richter

Re: First guix pull is too costly

[bokr]

On +2022-06-28 14:04:52 +0600, Akib Azmain Turja wrote:
> 
> Hello,
> 
> Yesterday, I created a new user in my system.  Then I tried to install a
> package, but found that it's not the latest, although I did sudo guix
> pull before sudo guix system reconfigure.  So I tried to do guix pull,
> but it seems to clone the whole repository from scratch.  But,
> unfortunately, it never succeeds due to my faulty network connection.
> It progresses somewhat like 5%, 7%, 20%, and my connection fails, and I
> have to start again from the beginning.
> 
> Is possible to reuse the guix channel from any other user to do the
> first guix pull?  Or maybe a shallow clone?
> 
> -- 
> Akib Azmain Turja
> 
> This message is signed by me with my GnuPG key.  It's fingerprint is:
> 
> 7001 8CE5 819F 17A3 BBA6  66AF E74F 0EFA 922A E7F5

I'm trying to imagine help for this situation:

Does git have a feature for an entire pull like wget does for a file? E.g.,
wget -c some_incompletely_downloaded_file

TIA to anyone who knows and tells :)
--
Regards,
Bengt Richter

Re: Teams: first draft list

[bokr]

On +2022-06-21 17:21:11 +0200, zimoun wrote:
> 
> Here below a collection of answers.  The teams are more or less.  Maybe,
> we could join some for having another structure.  WDYT?

Where is the RISC/MES team? :)

Further thoughts on Xorg "vs" Wayland etc -- was: Re: Release v1.4?

[bokr]

Hi brian, et al,

On +2022-06-17 11:37:18 -0400, Brian Cully via Development of GNU Guix and the 
GNU System distribution. wrote:
> 
> Ludovic Courtès  writes:
> 
> > So plain ‘emacs’ package doesn’t work on Wayland?  That sounds like a
> > recipe for a poor user experience, no?
> 
> The mainline Emacs is not Wayland-native, but it (along with just about
> everything else) will run fine under XWayland. It's how I've been running it
> for some time now. The user experience is almost indistinguishable from
> either the ‘pgtk’ branch or the mainline, X-only branch.
>

Yes, and NB:  Xwayland does not shut out native wayland.

It may even share more nicely than that, depending on system.
On my old Puri.sm Librem13v4 PureOS/amber-variant-of-debian system...
---cut here---start->8---
# $ uname -rv
4.19.0-19-amd64 #1 SMP Debian 4.19.232-1 (2022-03-07)
---cut here---end--->8---
...I can switch back and forth between Xwayland that does
all the stuff that needs X or Xorg (gnome and browsers, and Audacity
and all that) and my hacky experiments with bypassing X and
talking to the compositor in C.

The compositor happily places my pixel buffers on the screen together with
firefox or texworks or whatever else is running, so there is not necessarily
a Wayland "vs" Xorg conflict. YMMV I would guess, but works for me :)

This seems to me like it demonstrates an opportunity to encourage developers
to get their feet wet with X-server-indepedent apps. (That doesn't mean
giving up all the graphics and font software that paints pixels into buffers --
it "just" factors out the buffer compositing)

My system also permits switching to a framebuffer ( /dev/fb0 ) tty3 based
environemt, while leaving the gnome gui stuff running.
Ctl-Alt-F3 gets me a console login prompt. Ctl-Alt-F2 switches me back,
whether I logged out of the console shell or not.

If you are a member of the video group, you can read and write the
frame buffer as a 1920x1080x4 byte mmap whose address you can get
with an ioctl. Other geometries are of course possble. 

I wrote some C to poke character cells from the kernel sun12x22 font.
Long time ago. I have been meaning to port my pixelpoking to wayland,
and have wip stuff, which I will share at some point :)

The reason I was in frame buffer mode today was the gnome side got
total locked, so I thought I could Ctl-Alt-F3 and kill off stuck bits.
Which I did -- killed the whole GUI side, in the end. An alernative
to rescue/maintenace mode, before going there, IOW.

But since I was there in console fb mode, I wanted to check that
my old font demo worked. It did :)

BUT: Fn Prt Sc had no hook like in gnome, so I wanted to save the
display. Guess what you can do?

To make a screenshot:
xz -kzc /dev/fb0 > some_xzss_name.xz
To display such a screen-shot:
xz -dc some_xzss_name.xz > /dev/fb0

This works fast, and the compression is better than the .png files from
gnome's screenshots. Of course this doess not coordinate with anything else
that may be painting the screen, so it will get mixed with updates in sometimes
curious ways, since the compositor avoids update screen areas it thinks haven't
changed. If you poke pixels there, they'll stay until the compositor gets 
someting
new for that area,

I'll try to attach one I made. It shows all the kernel sun12x22.c characters
with bounding boxes in red and hex index numbers at the array edges.

Maybe this dual fb0 and Xwayland capabilty could help someone?
You get it all "for free" with some systems, and it doesn't demand anything.

There is tricky stuff going on though. So no warranties
from me on any of this info :)


> > (FWIW folks like me who use exwm, ratpoison, or one of these geeky
> > tiling window managers probably can’t switch.)
>

I don't know how much work, but I would guess they can be made
to work alongside wayland, if not using wayland to best advanage.

Best would be to wean emacs of X, IWT.

Otherwise they can probably play nicely on the same back end,
not sharing screen space maybe, but flipping between with some key hit.

A quick check on if you have drm-driven displays:

---cut here---start->8---
# $ head /sys/class/drm/*/status
==> /sys/class/drm/card0-DP-1/status <==
disconnected

==> /sys/class/drm/card0-eDP-1/status <==
connected

==> /sys/class/drm/card0-HDMI-A-1/status <==
disconnected
---cut here---end--->8---

BTW, if you want to hack native wayland, I recommend [0]
to start with. The examples mostly worked for me.

but so much is developing so fast that things
like using anonymous files and mmap-ing them to pass
to wayland as private buffers may show up only
while your're looking for something else on stackoverflow
or wikipedia or reddit or ... you may miss it.

[0] https://wayland-book.com/introduction.html

Sorry to interpose so much, the context for "this" (I think) was:

--8<---cut 

Re: Move switch-symlinks to (guix build utils)

[bokr]

Hi,

I am not expert on kernel link internals, but if
you need/prefer atomic change to a specific link,
does my log [1] below suggest a way?

On +2022-06-03 21:30:39 +0200, Ludovic Courtès wrote:
> Hi,
> 
> Maxime Devos  skribis:
> 
> >, Maybe replace
> >
> >(symlink target pivot)
> >
> > by (symlink/remove-old target pivot)
> >
> > where
> >
> > (define (symlink/remove-old target link)
> >   "Make a symbolic link named LINK pointing to TARGET.
> > If LINK already exists, it will be removed first.
> > This is not an atomic operation."
> >   (catch 'system-error
> > (lambda ()
> >   (symlink target link))
> > (lambda stuff
> >   (if (= (system-error-errno stuff) EEXIST)
> >   (begin
> > ;; remove old link and retry
> > (delete-file link)
> > (symlink/remove-old link target))
> >   (apply throw stuff)
> 
> Alright, SGTM (this procedure would be kept private).
> 
> So Arun, the floor is yours!  :-)
> 
> Ludo’.
>

[0]: (some "<--= note" notes edited in)
BTW: notice that Size: is number of chars in TARGET name, not the LINK name
--8<---cut here---start->8---
$ ln -sT TARGET LINK
$ stat LINK
  File: LINK -> TARGET
  Size: 6   Blocks: 0  IO Block: 4096   symbolic link
Device: fe00h/65024dInode: 19401553Links: 1   # <--= note inode number: 
mv will not change it
Access: (0777/lrwxrwxrwx)  Uid: ( 1000/bokr)   Gid: ( 1000/bokr)
Access: 2022-06-04 00:57:47.680832044 +0200
Modify: 2022-06-04 00:57:47.680832044 +0200
Change: 2022-06-04 00:57:47.680832044 +0200
 Birth: -
$ mv -v LINK WAS-LINK
renamed 'LINK' -> 'WAS-LINK'
$ stat WAS-LINK
  File: WAS-LINK -> TARGET
  Size: 6   Blocks: 0  IO Block: 4096   symbolic link # 
<--= TARGET is still 6 chars :)
Device: fe00h/65024dInode: 19401553Links: 1# <--= note inode 
number: did not change with mv
Access: (0777/lrwxrwxrwx)  Uid: ( 1000/bokr)   Gid: ( 1000/bokr)
Access: 2022-06-04 00:57:47.680832044 +0200
Modify: 2022-06-04 00:57:47.680832044 +0200
Change: 2022-06-04 00:58:33.617240104 +0200
 Birth: -
$ ln -sT NEW-TARGET LINK
$ stat LINK 
  File: LINK -> NEW-TARGET
  Size: 10  Blocks: 0  IO Block: 4096   symbolic link # 
<--= NEW-TARGET is 10 chars :)
Device: fe00h/65024dInode: 19401638Links: 1<--= note inode number: 
new for new use of LINK name
Access: (0777/lrwxrwxrwx)  Uid: ( 1000/bokr)   Gid: ( 1000/bokr)
Access: 2022-06-04 01:00:10.630121441 +0200
Modify: 2022-06-04 01:00:10.630121441 +0200
Change: 2022-06-04 01:00:10.630121441 +0200
 Birth: -
$ rm -v WAS-LINK  <--= note no OS objection to removing renamed old LINK
removed 'WAS-LINK'
$ stat *LINK*
  File: LINK -> NEW-TARGET
  Size: 10  Blocks: 0  IO Block: 4096   symbolic link
Device: fe00h/65024dInode: 19401638Links: 1
Access: (0777/lrwxrwxrwx)  Uid: ( 1000/bokr)   Gid: ( 1000/bokr)
Access: 2022-06-04 01:00:10.630121441 +0200
Modify: 2022-06-04 01:00:10.630121441 +0200
Change: 2022-06-04 01:00:10.630121441 +0200
 Birth: -
$ 
--8<---cut here---end--->8---

I'm guessing the inode rewrite involved in mv -v LINK WAS-LINK should be atomic?
Maybe some kernels have to struggle without good hardware support, but still 
atomic?

Maybe a kernel insider will chime in?
HTH some way.
--
Regards,
Bengt Richter