Re: Question on the process of packge withdrawal
On +2023-02-28 18:16:18 +0100, Simon Tournier wrote: > Hi, > > On Tue, 28 Feb 2023 at 17:26, wrote: > > > 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." > > Well, I will not call that "junk". :-) > Me neither. That's what I meant to say with my wrecked-cars-as-broken-packages anecdotal metaphor: broken ≠ worthless :) > IMHO, this is discoverable since it is part of the Git history of > Guix. The Git history of Guix also acts as an inventory. > I agree, the git history probably has everything in it, but for me discovery is not so easy. I think I need a map like openstreetmap, that on a high level could show a map of software component boundaries instead of city plots, and alternate views showing e.g. dependencies as roads between warehouses/packages. Obviously, related collections of things would cluster on map representations, and interaction could pop up synopses and descriptions and urls etc -- like what happens finding your way to the right bar in Brussels ;-) How about a street-view drive along thread executions from power on to login? Zoom in for detail data from dmesg or sytemctl -b or straces? How about a drive into gnome-control-center? With trip-planning how to get there and back from various contexts, showing zoomable detail from high level widget thumbnails or down to the lowest gdb run step. Well QGIS is free/libre UIAM, but it is BIG. And BIG means a LOT to trust, and that worries me. Maybe good software maps could make reviewing and verifying easier, until it's all automated. But how can we verify the automation? (isn't there an old Latin saying about guarding guard dogs :) I am not sure how the database of software maps would have to be represented. What would be analogous to satellite photography and automatic vectorization of roads and river boundaries etc.? Actually, maybe a game engine would be better than GIS. Super Bughunter Tomb Raider avatars ;-) Yeah, that sounds like more fun. VRML? Well, that's a big fantasy about "discovery" :) Hm, how to get that running as native RISC-V code on open silicon? ;-) > Cheers, > simon -- Regards, Bengt Richter
Re: Dissecting Guix -- blog post series
Hi, On +2022-12-09 17:25:35 +, ( wrote: > Heya, > > On Fri Dec 9, 2022 at 9:32 AM GMT, wrote: > > 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? > > Sorry, I don't really understand; how is this relevant to derivations? :) > > -- ( Maybe I mis-imagine your assumptions about your audience. For myself, I would like an emacs M-x idiot-mode so I could run a boot-bricker-test.sh script someone has posted, without worrying that in plain cli context, it will /actually/ brick my machine :) I am assuming if your lowlevel examples are really good, they will be used as bases for cut/paste variants that people will then post and implicitly prompt each other to try.. I don't trust that everything thus posted will be both benevolent and competently avoiding security vulns. I can't even trust my own stuff. I make too many mistakes :) So, narrowly focusing on derivations, maybe trust is not technically relevant, but in the larger social context gullible noobs like me need all the help we can get about recognizing potentially dangerous code. And I think derivations can potentially contain or generate or activate code one should not trust. So that's how I see asking for trust info being relevant to derivations :) -- Regards, Bengt Richter
Re: How long does it take to run the full rustc bootstrap chain?
Hi again, thanks for your reply... On +2022-10-27 10:35:02 -0400, Maxim Cournoyer wrote: > Hi, > (Oops, pasting back alternative I thought would be 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--- [...] --8<---cut here---start->8--- > $ lsblk -o size,model,type,tran,vendor,name|grep -Ei 'ssd|model';echo;lspci > |grep -i nvme > SIZE MODEL TYPE TRAN VENDOR NAME > 465.8G Samsung SSD 860 EVO 500GB disk sata ATA sda > 931.5G Samsung SSD 840 EVO 1TBdisk sata ATA sdc > --8<---cut here---end--->8--- > > Building Rust is mostly CPU dependent; I think fast single thread > performance is key as not that much happen in parallel, IIRC. The 3900X > is a 12 cores (24 logical) beast. > Hm, just TRAN sata, no nvme, so it's going to be slow, but what is the effect on what you timed? Is there an easy way to get a measure of how many GB went through those SATA channels during what you timed? That would give an idea of what faster phusical disk memory access would do for you. If many people are waiting longer that they like, maybe they would chip in to fund an upgrade, to feed that 12(24)-core "beast" :-) I'd bet it is waiting a lot, if not more than computing :) -- Regards, Bengt Richter
Re: Building, packaging and updating Guix with confidence
Hi Josselin,
tl;dr:
I naively don't buy the rationale against a non-root guix daemon :)
Skip to [2] if tl ;)
On +2022-07-21 18:10:53 +0200, Josselin Poiret wrote:
> Hello,
>
> b...@bokr.com writes:
> > Naively:
> >
> > Why does "the" guix daemon per se need root access at all?
>
> The main thing is that all files in the store end up being written by
> the guix daemon user.
IIUC, that would be guixrootd per se, not the homeless guixbuilder{0-10}
users created by the default install, right? (IIUC the latter are
meant to allow guixrootd to shed its root write privilege by spawning
a user mode continuation, so to speak?)
> ... So if we want the files to be easily
> substitutable, they'd need to have a fixed uid/gid,
Why? "Easily" in what way? untarring tarballs?
Even if tar sets bogus external file system metadata,
UIAM the only privilege you need is ownership, and neither
guix nor the installer need to run as root themselves
to get ownership. That can be done by a tiny helper
whose source you can see on one page, and whose execution
you can limit to a user such as the single-writer guixstored,
which UIAM can then chmod and chown at will to share or not.
I don't believe in blanket permissions to accomplish
a tiny important priviliged action. I want to see it
factored out for auditability and comprehensibility.
(Here I did s/guixrootd/guixstored/ as a name for a non-root
user which has exclusive control over gnu/store because
it creates /home/guixstored/gnu/store thus in its home directory
and no other user has write access to it except by talking to guixstored via
message or sharing read-only files if mounted and reachable and permitted
by guixstored setting perissions on files it owns.
> ... and the only one we
> can guarantee is root.
But why would you have to? ISTM not necessary.
> ... Other than that, it needs to use a bunch of
> Linux namespaces to isolate the builds from the rest of the system,
You mean like -G from
--8<---cut here---start->8---
useradd -g guixbuild -G guixbuild${KVMGROUP} \
-d /var/empty -s "$(which nologin)" \
-c "Guix build user $i" --system\
"guixbuilder${i}";
_msg "${PAS}user added "
fi
--8<---cut here---end--->8---
YOW! running as root AND being able to do KVM stuff?
My naive paranoia button has been pushed, and I don't want to
do the searching for info to calm myself ;/
BTW, above snip was from guix clone repo pull as of
┌──┐
│ # $ git log --pretty=medium --grep 'install\.sh'|head -3 │
├──┤
│ commit 3348e485b7229e062e563945ed7e6ac216f25125 │
│ Author: Philip McGrath │
│ Date: Sun Jul 3 22:35:03 2022 -0400│
└──┘
> which depending on the kernel build-time configuration might not be
> possible when unprivileged.
>
IWT think that goes away if you run a single-writer daemon
on the local OS, and let the kernel use its namespaces to
keep the users from trampling on each other (any more than
they already maybe can with the current setup).
If the OS can't separate users, ISTM everbody is kind-of root in effect,
but then maybe we can run a single user thread as if root, if you have
an environment where that's useful -- maybe cloud virtual pcs?
Communicating would be an adapter problem, but virtual pcs
can boot fully fledged linux these days, I think, and it seems
doubtful that you would run a big guix build ON a raspberry pi
even though TARGETING an rpi makes lots of sense.
Whew, I've got to stop re-editing this :/
[2]:
So, do you see any real obstacles to making guixrootd an ordinary user
(in the sense of /home/ordinary_user/ ) and calling it
guixstored instead, with an ordinary /home/guixstored/ home directory
(where it has natural protection as guixstored:guixstored on useradd
creation, with added group guixbuilder for helper r/o sharing, which
as owner it can control)?
However many guixbuilder0{1..9}:guixbuilder0{1..9} helper users are created,
(plus guixbuilder10:guixbuilder10 in the default naming :)
they would also belong to the guixbuilder extra group
(no suffixed number) but they only would have read access to parts of
/home/guixstored/gnu/store/... unless guixstored as
owner sets other permissions for the guixbuilder group.
I'm not seeing why there needs to be any guix daemon running as root :)
But this means you can't just uncompress files, metadata and all,
for substitution purposes, which I guess you were alluding to with
"...can't easily...", right?
But IWT that guixstored could use a tiny helper to get ownership, as above.
Becoming owner by using a factored-out-tiny-helper to chown untarred stuff
should be safer than running bigstuff as root IWT).
It can then create and exclusively
Re: repl macro (metacommand?) for guix CLI (sub)commands
)(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--- WDYT? I need to go back to square 1 default .bash_login and .bashrc to debug this I guess :-( (so .profile and my mods down the .profile sequence will be ignored). Gaah :-/ -- Regards, Bengt Richter
Re: “Building a Secure Software Supply Chain with GNU Guix”
Hi zimoun, On +2022-07-04 10:21:13 +0200, zimoun wrote: > Hi, > > On Sun, 03 Jul 2022 at 12:38, Bengt Richter wrote: > >> I do not think committers are pushing code about #1, #2 or #3 that they > >> know beforehand it will cause a problem. > > > > Hm, -- unless ... ? :) > > > > I do not understand what you mean? > I just meant I think I have seen partial fixes committed, noting that it will only work given some required context, like run time must be x86_64 (or else "" and problem can be expected :) Sorry for the noise. NNTR :/ -- Regards, Bengt Richter
Re: “Building a Secure Software Supply Chain with GNU Guix”
Hi Simon, and all, On +2022-07-01 11:21:43 +0200, zimoun wrote: > Hi Bengt, > > On jeu., 30 juin 2022 at 23:37, b...@bokr.com wrote: > > > 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. > > Well, from my understanding, Guix is dealing with 4 sort of code: > > 1. Guix recipe of a package > 2. Guix service > 3. Guix itself > 4. Upstream > > I do not think committers are pushing code about #1, #2 or #3 that they > know beforehand it will cause a problem. > Hm, -- unless ... ? :) > Therefore, I do not see how it could be implemented without being rooted > in committer feelings, opinion or self-confidence, i.e., highly variable > from one committer to the other. > > The GPG trust level works because it is based on the web of trust. > Here, there is no web, IMHO. > Well, guix developers who know each other well "in real life" have a pretty good web, if not formal, no? :) It's just not accessible to newcoming outsiders, who can't see the trust codes in the insiders' heads :) > Most of the security issues are from #4. Considering how hard it is to > find and tackle the security issues, there is only two strategies, IMHO: > do not trust which implies deep audit of distributed source code and so > restrict the set of available packages (it is somehow an OpenBSD > approach); or accept more packages which means somehow trust upstream, > to some extent. > Agreed, #4 is usually the source of security issues. I'm just looking for some greppable coded hint of the difference between a package that consists of e.g. a reverse polish calculator homework assignemnt that a nerdy friend showed how to submit as a package, vs. e.g. a package where the comments say over 10K subscribers have now been running this hundreds of times daily for 2 months of beta testing with no reported problems. Vs. This is alpha stuff, but seems harmless enough if you run it in a container. I'm not asking any guarantees, just a professional's quick judgement. Like a chef's quick opinion on the cantaloupes at the open market. This is separate from the issue of whether to include a package under guix. No blocker if the cantaloupe is not ripe, but helpful to have a sticker saying so, for those who (for lack of time perhaps) want to order on line and use grep instead of their nose :) > > However, all in all, it asks what is expected by the reviewing process, > as discussed [1]. :-) > > 1: <https://yhetil.org/guix/87r13aifi3.fsf...@gnu.org> > > > Cheers, > simon I am not forgetting that I should be thankful for anything I am provided freely. So thank you all! -- Regards, Bengt Richter
Re: Missing tags in Debbugs?
On +2022-06-29 09:29:20 +0200, zimoun wrote: > Hi, > > Thanks for the feed back > > On Wed, 29 Jun 2022 at 08:07, b...@bokr.com wrote: > > > Anyway, the idea is to make the Subject: line greppable for both > > what the bug is about and its status when it was closed. > > I agree that it is hard to work with the Debbugs archive. What you are > asking seems possible with Debbugs but the GNU instance is not > supporting many tags [1]. Using the ’Subject:’ line as tagging system > could be a workaround but I am not convinced the ratio effort / > usefulness is worth because it is too error-prone, IMHO. > > Arun has presented nice ideas about improving Mumi and it appears to me > the direction to go. > > > 1: <https://debbugs.gnu.org/Developer.html#tags> Thanks, that LGTM: Looks like easy-to-parse html :) This looks interesting too, that I just found: 2: <https://debbugs.gnu.org/server-request.html#introduction> Will have to try it. Maybe emacs already has a mode for that? (I need to refresh my emacs-fu ;/ ) > > > Cheers, > simon -- Regards, Bengt Richter
Re: New review checklist
Hi Liliana, Maxime, et al, On +2022-04-01 20:25:37 +0200, Liliana Marie Prikler wrote: > Hi Maxime, > > Am Freitag, dem 01.04.2022 um 19:46 +0200 schrieb Maxime Devos: > > [...] > > I know there have been some discussions in the past about whether > > git-version should be used when a commit is explicitly chosen, > > whether > > tags should be used instead of commits, how high a risk there a is that > > version->commit can become multi-valued, ‘tricking peer review’ ... > > > > However, my question isn't about any of that. It is only about the > > let-binding itself, in situations where the bound variable is only Here ISTM important to understand exactly what you mean by "let-binding" so I would really like it if I could type --8<---cut here---start->8--- info guile let-binding --8<---cut here---end--->8--- into my command line interpreter, and get right to the details as I often can for other things, e.g. --8<---cut here---start->8--- info guile define-macro --8<---cut here---end--->8--- This suggests to me something like a translation project, except not bewween local natural languages, but between expert guile/guix implementer's terminology and detailed explanations that various level programmers can go into as deeply as they want (following suggested reading if not included in the info doc itself). I am also imagining info could be instrumented to emit a minimal email to a server that could accumulate statistics on no-hit lookups, and that this could be visible in some tool when someone feels like contributing to make --8<---cut here---start->8--- info guile what-does-this-mean --8<---cut here---end--->8--- produce a result that we can all refer to when we want/need to say "that's what I am talking about." After getting past foot-binding and other bindings, wikipedia got me to [0], which might be a nice read-further hint, but what did Maxime mean, out of all those possibilities? [0]https://en.wikipedia.org/wiki/Scope_(computer_science) To be really precise, if he could point to a formal definition in some style from [1] [1]https://en.wikipedia.org/wiki/Denotational_semantics that could really nail it when such detail was necessary. Of course, --8<---cut here---start->8--- info guile define-language --8<---cut here---end--->8--- leads to wonder-land. But if you just want a quick check that you have the right concept for something you read, well, good luck in RL -- in fact I just missed a local library music event because I was reading guile info docs to make examples for this post -- i.e. got drawn into reading about define-language and not watching the time ;-/ I think for best effect, there should be no dependencies to prevent usage anywhere "info guile" answers usefully at the command line. Anyone else want to know exactly what Maxime meant by "let-binding" ? :) > > used in a single place. What is the reason for doing > > > > (let ((commit "cabba9e...")) > > (package > > (name "foobar") > > (version "0.1.2") > > (source (origin ... > > ;; this is the only use of the 'commit' variable bound > > in > > ;; the above 'commit' > > (commit commit))) > > ...)) > > > > when it can be simplified to > > > > (packaeg > > (name "foobar") > > (version "0.1.2") > > (source (origin ... (commit "cabba9e..."? > > > > I mean, we don't do this for, say, 'name', 'version' and 'uri': > > > > ;; these three variables are only used in a single location > > (let ((name "foobar") > > (version "0.1.2") > > (uri "https://foo.bar;)) > > (package > > (name name) > > (version version) > > (source (origin (uri uri) (commit ) [...])) > > ...)) > > > > Why would things be different for 'commit' here? How does putting > > the value of 'commit' in a let-form reduce surprises? > The main goal of let-binding commit and revision is to allow for easier > change. Suppose you need to reference some half-release for some > obscure reason, then this style makes it easier to switch to what is > already established praxis. > > In general, consider the poor soul who may have to read and maintain > your code after you get hit by a car because neither busses nor trams > run in your region. > -- Regards, Bengt Richter
Re: Assisting reviewing & committing with tags?
tl;dr: Sleep deprivation ;-/ SFTN On +2022-02-15 17:23:23 +0100, Maxime Devos wrote: > Bengt Richter schreef op di 15-02-2022 om 13:23 [+0100]: > > Hi guix, > > > > It sounds like a good idea, but ISTM we don't need yet another markup syntax > > if emacs org mode already defines a useful standard that can be adopted. > > > > The advantage to org mode style [0] -- in commit commentary as well as tags > > would be its scrapability -- i.e., ease of writing an extractor/formatter > > for handy report snippets/pages and web stuff etc., whether implemented > > using foreign shell or within guix. > > FYI, I think you responded to the wrong thread. This thread was about > additional usertags in debbugs for reviewing in Guix, not about markup > languages or org mode. > > Greetings, > Maxime. -- Regards, Bengt Richter
Re: Excessively energy-consuming software considered malware?
On +2022-02-25 14:04:34 +0100, Tobias Geerinckx-Rice wrote: > On 2022-02-25 13:41, Bengt Richter wrote: > > And maybe also a mailing list called "guix-grownups" -- > > where casual adult language is accepted without triggering > > endless complaints. > > This is guix-grownups, although we accept grown-ups of all ages. > Glad to hear it :) But the serious part of my post was --8<---cut here---start->8--- WDYT of starting a list called "guix-off-list" to provide a place for those who enjoy this kind of discussion? I do enjoy such discussions sometimes, but not on the same plate as debug tracebacks or beautiful code examples from the virtuosos. I don't mind single-line BTW or FYI or IMO: footnote references to out-of-thread content if the rest of the post contributes something and isn't just one line in a full quote. Having a "guix-offlist" would enable a reference like "IMO:guix-offlist: bitcoin explained by me ;)" --8<---cut here---end--->8--- The idea being to help factor off-topic discussion out of threads without interfering with people's desire to follow up with interesting ideas. Or not-so-interesting ideas :) Thoughts? > Kind regards, > > T G-R > > Sent from a Web browser. Excuse or enjoy my brevity. -- Regards, Bengt Richter
Re: Excessively energy-consuming software considered malware?
On +2022-02-24 19:27:37 -0500, Christine Lemmer-Webber wrote: > I am all for these conversations; they are good to have as a society, to > examine our social foundations in earnest dialogue. But I think they've > approached a point on here where they're no longer about Guix > development, in particular, so probably should be moved off-list. > WDYT of starting a list called "guix-off-list" to provide a place for those who enjoy this kind of discussion? I do enjoy such discussions sometimes, but not on the same plate as debug tracebacks or beautiful code examples from the virtuosos. I don't mind single-line BTW or FYI or IMO: footnote references to out-of-thread content if the rest of the post contributes something and isn't just one line in a full quote. Having a "guix-offlist" would enable a reference like "IMO:guix-offlist: bitcoin explained by me ;)" And maybe also a mailing list called "guix-grownups" -- where casual adult language is accepted without triggering endless complaints. Coming to some mailing lists these days I sometimes feel like I've entered a restaurant where the menu is dominated by allergy and spice concerns. (I have nothing againt special venues catering to sensitive minorities, don't get me wrong. What do I mean "minorities" eh? :) Wonder what George Carlin (R.I.P) would say about all this :) -- Regards, Bengt Richter
Re: Investigating a reproducibility failure
Hi, On +2022-02-05 15:12:28 +0100, Ludovic Courtès wrote: > Konrad Hinsen skribis: > > > There is obviously a trade-off between reproducibility and performance > > here. > I suspect what you really want to reproduce is not verbatim code, but the abstract computation that it implements, typically a digitally simulated experiment? Thus far, "show me the code" is the usual way to ask someone what they did, and guix makes is possible to answer in great detail. But what is really relevant if you are helping a colleague reproduce e.g. a monte-carlo simulation experiment computing pi by throwing random darts at a square, to draw a graph showing convergence of statistically-computed pi on y-axis vs number of darts thrown on x-axis? (IIRC pi should be hits within inscribed circle / hits in 1x1 square) Well, ISTM you can reproduce this experiment in any language and method that does the abtract job. The details of Fortran version or Julia/Clang or guile pedigree only really come into play for forensics looking for where the abstract was implemented differently. E.g., if results were different, were the x and y random numbers displacing the darts within the square really uniform and independent, and seeded with constants to ensure bit-for-bit equivalent computations? How fast the computations happened is not relevant, though of course nice for getting work done :) > I tried hard to dispel that belief: you do not have to trade one for the > other. > > Yes, in some cases scientific software might lack the engineering work > that allows for portable performance; but in those cases, there’s > ‘--tune’. > > > https://hpc.guix.info/blog/2022/01/tuning-packages-for-a-cpu-micro-architecture/ > > We should keep repeating that message: reproducibility and performance > are not antithetic. And I really mean it, otherwise fellow HPC > practitioners will keep producing unverifiable results on the grounds > that they cannot possibly compromise on performance! > Maybe the above pi computation could be a start on some kind of abstract model validation test? It's simple, but it pulls on a lot of simulation tool chains. WDYT? > Thanks, > Ludo’. > -- Regards, Bengt Richter
Re: Assisting reviewing & committing with tags?
Hi guix, It sounds like a good idea, but ISTM we don't need yet another markup syntax if emacs org mode already defines a useful standard that can be adopted. The advantage to org mode style [0] -- in commit commentary as well as tags would be its scrapability -- i.e., ease of writing an extractor/formatter for handy report snippets/pages and web stuff etc., whether implemented using foreign shell or within guix. [0] http://xahlee.info/emacs/emacs/emacs_org_markup.html On +2022-02-02 08:58:18 -0500, Maxim Cournoyer wrote: > Hi, > > Leo Famulari writes: > > > On Sun, Jan 09, 2022 at 11:54:25AM +0100, Maxime Devos wrote: > >> Hi guix reviewers and committers, > >> > >> WDYT of tagging reviewed patches that look good with a usertag, > >> e.g. 'reviewed-looks-good': > >> > >> https://debbugs.gnu.org/cgi/pkgreport.cgi?tag=reviewed-looks-good=guix > >> > >> then if a committer doesn't have much time to review and hence doesn't > >> subscribe to guix-patches@, but they do trust the reviewer, they can visit > >> that URL to look for reviewed patches that can be applied. > >> > >> There could also be a tag 'reviewed-looks-good2' if the patch appears ok > >> to two reviewers, or a 'reviewed-needs-work', etc. > > > > This is a great idea. I guess we will need to adjust the software that > > runs issues.guix.gnu.org to make use of it, but in the meantime you > > should keep using this tag. Thanks! > > I like it as well. > > Maxim > -- Regards, Bengt Richter
Re: The way to promote GUIX package manager
On +2022-01-27 22:43:06 -0300, David Pirotte wrote: > > > ... > > What does "apt search guix" produce? > > (Nothing, on the puri.sm variant of debian. They maintain a custom > > pool based on debian minus what they want to exclude AIUI) > > fwiw, > > > https://packages.debian.org/search?keywords=guix=names=all=all Yeah, forgot to mention: they don't _prevent_ you from doing anything you want -- in fact that's what they're about: to ensure that you (having the necesssary expertise or funds to hire it) _can_ control as near as possible everything your computer does, including (not quite all) IME firmware, bios, bootloaders and the whole chain onwards. OTOH they may not want to spend a lot of time helping you undo what you did to yourself by bypassing their packages and safeguards. They may instead suggest you install QubesOS and run iffy stuff (like guix, whose reproducibility unfortunately does not exclude reproducing bugs and vulnerabilities :) in a dom for untrusted sfw. Personally, I like simplicity best, so I am watching MES and RISC-V and hoping for a "stateless" laptop which will bootload _anything_ into memory from _anywhere_ -- and ask me (via trustable interface) if I like the sha256 it computed for the image just loaded. Bonus for asking me if I want it to check or add to white-list via secure protocol to USB goodie. With only hot-pluggable high speed disks, I can just with keep my precious stuff fully separate and unconnected while I take internet advice like "just run everything as root, it makes it so much easier for a newbie." ;-) I think SeaBIOS and a doctored kernel-independent grub can get close, but I want stateless with _all_ hot-pluggable hard disks, even if two (for raid or cloning) of them have convenience slots to hold them as cartridges. Dreaming on ... -- Regards, Bengt Richter
Re: The way to promote GUIX package manager
On +2022-01-26 23:42:05 +0100, Ricardo Wurmus wrote: > > Yasuaki Kudo writes: > > > Does Guix really run out of the box in Debian? > > > > I have never tried it but my friend Debian expert friend keeps telling me > > that: > > > > * Just apt-get installing Guix doesn't work > > How does “apt install guix” not work? There’s an older version of Guix > in Debian. After installing it “guix pull” should get the latest > version and it all works. > What does "apt search guix" produce? (Nothing, on the puri.sm variant of debian. They maintain a custom pool based on debian minus what they want to exclude AIUI) > There’s also an installer script at https://guix.gnu.org/install.sh > which skips the detour through apt and gets you the latest release > directly. > > > * and his really big complaint is evidently he creates "virtual > > environments" (short of full-on VMware, I imagine it is an assortment > > of Linux native tricks that are wrapped by tools like Docker) for > > every OS he tries but > > * Evidently the same tricks don't work with Guix > > Is this not *exactly* what “guix shell” (formerly “guix enviromnent”) > does? “guix shell -C” enters a container, even, using the same Linux > namespace mechanism that Docker wraps. > > > * He does not want to try full blown Guix OS without first testing it in > > above ways > > Guix can comfortably be used outside of Guix System. And you can > *still* use most “guix system” commands, e.g. to build containers or > virtual machines. > > -- > Ricardo > -- Regards, Bengt Richter
Re: On raw strings in commit field
[0] https://cdn.quotesgram.com/img/31/40/532049644-676813c5150a0168ad089c40202f742e.jpg On +2022-01-01 12:12:33 +0100, Liliana Marie Prikler wrote: > Am Freitag, dem 31.12.2021 um 20:41 -0500 schrieb Mark H Weaver: > > I disagree with the last line above. What makes you think that I'm > > presupposing that the tag does change? > > > > There's a difference between "presupposing that the tag does change" > > and "not assuming that the tag will not change". Do you see the > > difference? > I'm pretty sure ¬assume(¬X) = assume(¬¬X) in this concept. You have to > start with some assumptions and while ideally we'd like to encode "I > don't care", we do not have a system that allows us to do so. > > > > However, if we are always talking about more than one possible > > > "1.2.3" (with the included future tag that we have yet to witness), > > > we lose the basis by which we currently assign "1.2.3" as the > > > version > > > > I see what you're getting at here, but still I disagree. Our basis > > for associating version "1.2.3" with commit XYZ is simply that > > upstream had indicated that version "1.2.3" was commit XYZ. That > > historical fact is immutable. > History is a social construct, it's not immutable. > --8<---cut here---start->8--- “When I use a word,” Humpty Dumpty said in rather a scornful tone, “it means just what I choose it to mean — neither more nor less.” “The question is,” said Alice, “whether you can make words mean so many different things.” “The question is,” said Humpty Dumpty, “which is to be master – – that’s all.” --8<---cut here---end--->8--- -- Regards, Bengt Richter
Re: Release v1.4 (or 2.0): process and schedule ?
Hi all, On +2021-12-19 21:12:36 -0500, Maxim Cournoyer wrote: > Hi Simon, > > zimoun writes: > > > Hi, > > > > Now core-updates-frozen is merged. Now The Big Change [1 ]is done. Do > > we go for v1.4 or v2.0? > > As I've mentioned previously, I'd go for a 1.4.0 release, since overall > we've refined and improved (greatly!) what we already had rather than > introduced something revolutionary. I'd keep a 2.0.0 for when we have > p2p distributed substitutes, a custom graphical tool and/or integration > with the 'Software' application in GNOME, this kind of big user-facing > changes. But that's just my personal opinion :-). If the majority > feels a 2.0.0 is more suitable, I won't mind. > > > In both case, what is the target for a release date? I propose January > > 31rst. WDYT? > > I'd like to fix #52051 before issuing the first release candidate (RC). > Assuming this can be made before the end of January with the first RC > coming out around New Year, and that the kind of collaboration I've seen > in the last weeks continues at the same intensity, this seems > achievable. > > [...] > > >> The lesson of v1.0.1 [#,@] is: please help in testing the > >> installer. :-) > > Yes, I also feel we should give the installer a lot of testing; it seems > many people have had issues with it, especially when dealing with newer > EFI machines. Unfortunately I don't have such a machine available for > testing myself... > This seems, IIUC, like a FLOSS way to deliver multiple versions of guix in the form of a collection of bootable ISOs in a single bootable image for easy trial on various systems. WDYT? [0] https://www.theregister.com/2021/12/10/friday_foss_fest/?td=keepreading-btm [1] git clone 'https://github.com/ventoy/Ventoy.git' > >> How does it sound? > >> > >> Last, Guix is a “rolling-release“, so what does it mean ‘release’? :-) > >> The main argument for releasing, IMHO, is communication and so attract > >> potential new users. :-) > > To me, it's a milestone that can be communicated and provides a more > thoroughly tested (in theory) Guix installation image. > > Thanks for helping shape the release plan, > > Maxim > -- Regards, Bengt Richter
Re: "Trojan Source" (CVE-2021-42574 and CVE-2021-42694): can 'guix lint' help someway?
Hi, On +2021-11-01 09:38:28 -0400, Leo Famulari wrote: > On Mon, Nov 01, 2021 at 12:30:38PM +0100, Giovanni Biscuolo wrote: > > as probably many of you have discovered, today was announced two new > > vulnerabilities that exploits the "bidirectional override" Unicode > > codepoints feature, making it possible to hide malicious source code in > > comments and literal strings /if/ the code review tool (e.g. editor) > > does not show this. > > We need to check our own Git repository history for the tricky > codepoints. > > > Is there a way for "guix lint" to check for the listed (other?) > > "dangerous" codepoints and warn code reviewers? > > Yeah, we could implement this. It might be expensive but one has to > unpack the source code anyways. > > However, I think that this attack is, in general, not within the scope > of Guix's security model, because: > > 1) Guix implicitly trusts the source code that it fetches from upstream. > > 2) Guix explicitly fetches the source code from upstream — Guix > committers do not provide a copy of the upstream code (of unprovable > provenance) as they do in other distros. > > If an attacker can make malicious modifications to the code distributed > by an upstream project, it's not relevant to Guix if they use homoglyphs > or a buffer overflow. Guix developers do not inspect upstream source ^^ > code for vulnerabilities. > ... but: they do become aware of such vulnerabilities, and could e.g. manually append a line to a blacklist, hash-identifying upstream files to avoid their further use by guix, directly or in dependencies. IOW, ISTM the trusting of upstream should not be unconditional, and trust policy implementation should make possible instantly effective (i.e., on blacklist update) firewalling of guix users from further downloading of the tainted files, and hopefully automatic identification of past potentially corrupting uses. I imagine some developers might want to allow downloading blacklisted files e.g. to test workarounds etc, so some --allow-blacklisted=foofile,barfile,... option might be needed, but the casual client installing a guix package should be protected. In the latter case, maybe an automatic substitute for the backlisted file could be provided that would generate informative hints when used in a build instead of aborting the whole thing. A flag in the blacklist line might be a way to select alternative automated actions? > What do others think? > -- Regards, Bengt Richter
Re: Time for a request-for-comments process?
nstead of Asus or Lenovo, and similarly to narrow or widen context for OS or achitecture etc. (I am obviously suggesting something broader than just "shopping" for RFC info :) The shopping interface could be used to select what info to subscribe for, to get notifications about different info "products" or categories. > Maybe info-guix could be used. But it would mean that everybody would > be allowed to this list, when currently the messages landing there are > somehow “highly filtered”. However, an announce there pointing where > and how to comment could be something helping to get more attention. > Adding a section under Contributing about the process too. > > Last, the core question is formalization. Formalize the process (min, > max duration, expectations of evaluation, mechanism to accept or > withdraw, i.e., how to revolve different points of views, etc.) strongly > depends on what “major changes” means and how often that happens. Could > you provide examples of such “major changes”? It would help for drawing > a sketch of such formalization grounded on concrete examples. > > > Cheers, > simon > > 5: <https://yhetil.org/guix/20210716155009.32118-1-l...@gnu.org/> > > > *remember discussion: Personally, I receive all emails to all lists. All > in my Inbox. Thus, the channel does not mind for my workflow. :-) > However, dealing with Guix traffic is a daily task – if I am off for a > couple of days or holidays or busy by day job, then I skip some based on > dates or interest. My trick to deal with such traffic is “just” to > quickly be able to determine if it is worth, for my interests, to jump > into the details. If it requires less than 10min to answer, then I do > it (obviously, it always take more time than expected :-)), else if I am > interested in, I mark the email to revisit it later – coupled with > Org-capture and scheduled TODO tasks. On the top of that, I use a > “structured procrastination” approach: do what I am interested in at the > moment, not what it is important or urgent. > -- Regards, Bengt Richter
Re: Guix Jargon File (WAS: Rethinking propagated inputs?)
Hi Jonathan, Thanks for the TXR reference, I will have to look into it. Just on the basis of the author name "Kaz Kylheku" I would check it out. I have encountered his posts 'way in the past, and they were always intelligent and interesting. (If he is older than me, I'd like to know more about his diet and habits ;-) Anyway, if you are interested in PEGs in any guix connection, I think you should look at Guile's PEG implementation and syntaxes (scheme and string/regex styles). Type "info guile" (not guix), and then "Ctrl-s Peg Parsing" which will take you to an index, and either use that link (hit Return) or hit Ctrl-s again and you should be at the beginning of some interesting reading ;-) Note that guix is built on top of guile and its infrastructure of libaries (mostly C still where they aren't scheme, UIAM, but that may be changing to include more, I'm not sure -- I am not insider enough to follow ;-) Maybe you can make a guile-txr.scm package for a txr wrapper module using foreign function or your own C extension loadable by guile scheme. Have fun! Maybe my best strategy is to see what you come up with before re-inventing things you may already be way ahead in :) Oh, if you haven't already, also check into guile's regular expressions, e.g. "info guile Ret Ctrl-s regular expressions Ret Ret" And also try guile's repl by just typing "guile Ret" and then ",help" Mvh, Bengt Richter On +2021-09-05 15:53:34 +, Jonathan McHugh wrote: > Hi Bengt, > > I believe that a collection of regular expressions for recognising starting > block and closing block for differing formats. It would for instance become > political making a choice between (say): > * -a-dangerous-pair-of-scissors--8<--ouch- ; > * an Orgmode output; a GemText block; > * somebody who uses '£' as a delimiter, > * et al. > > That way people can maintain their workflows while still having a better idea > of where other peoples blocks/citations are. > > FYI, I am looking into parsing manpages and 'cheat' style command tools to > generate Parsing Expression Grammars - so as to permit people to identify > coding, if not perform actions. Hopefully one can then identify inline > content, as well as inferences regarding when coding blocks start and stop > (let alone additional knowledge) > > I was planning on using the Lisp TXR to do so - if somebody thinks this is a > mistake please say so! If somebody would like to propose what a Guile PEG > environment should look like I can make an additional grammar. If I get > enough positive feedback I can prioritise it more for a project Im working on. > > Kind regards, > > > Jonathan McHugh > indieterminacy@libre.brussels > > September 5, 2021 4:54 PM, "Bengt Richter" wrote: > > > Hi Liliana, > > > > Thank you for starting this renamed thread (as I should have done). > > > > I think a people who are just looking at _maybe_ installing guix > > should have an easy way to look up terms they haven't seen before. > > > > But really I am more interested in promoting the idea of a snippet-quoting > > convention modeled on a subset of mime email standards. > > > > Very simple, but capable of containing and transferring anything > > unambiguously > > (if not always with efficient transmission encodings). > > > > We can of course already do that with signed and attached files, and we can > > archive them and retrieve them, but I am interested in retrieving little > > pieces > > and making it easy to mark things in arbitratry contexts (like this email or > > a cannibal-friendly program source) so that simple snarfing utilities will > > be > > able to extract snippet-quote info based on tags and identifiers or anything > > in the headers or content per search options much like for any search > > engine. > > > > This is to create a simple contribution mechanism as well as a format > > for retrieval. > > > > I have seen many code snippets from developers that are tutorial material > > as well as practical how-tos for debugging and browsing guix. > > > > Wouldn't it be nice if they were snip-quoted so that we could extract them > > from mail archives in a better way than searching the raw archives, or > > having > > to browse though treads and extract nuggets by hand? > > > > simply: > > --8<---cut here---start->8--- > > header part, ending with blank line > > > > optional content part, encoded and delimited or referenced per header info > > --8<---cut here---end--->8--- > > &g
Re: Guix Jargon File (WAS: Rethinking propagated inputs?)
Hi Liliana, Thank you for starting this renamed thread (as I should have done). I think a people who are just looking at _maybe_ installing guix should have an easy way to look up terms they haven't seen before. But really I am more interested in promoting the idea of a snippet-quoting convention modeled on a subset of mime email standards. Very simple, but capable of containing and transferring anything unambiguously (if not always with efficient transmission encodings). We can of course already do that with signed and attached files, and we can archive them and retrieve them, but I am interested in retrieving little pieces and making it easy to mark things in arbitratry contexts (like this email or a cannibal-friendly program source) so that simple snarfing utilities will be able to extract snippet-quote info based on tags and identifiers or anything in the headers or content per search options much like for any search engine. This is to create a simple contribution mechanism as well as a format for retrieval. I have seen many code snippets from developers that are tutorial material as well as practical how-tos for debugging and browsing guix. Wouldn't it be nice if they were snip-quoted so that we could extract them from mail archives in a better way than searching the raw archives, or having to browse though treads and extract nuggets by hand? simply: --8<---cut here---start->8--- header part, ending with blank line optional content part, encoded and delimited or referenced per header info --8<---cut here---end--->8--- The header part could start with just prefixing GX- like the optional custom header X- prefix described in mime rfcs, and we could borrow whatever was useful. Tbc.. So called "real life" demands I postpone making a decent real example 'til later, sorry ;/ Please excuse the big top-post. I had intended to comment and edit in line ;/ BTW, I know "info guix|grep -i whatever" often gives clues about whatever, for pursuing "C-s whatever" once inside "info guix whatever", but though concept and api indices are great, they are not a Jargon File, and not as handy for an outsider :) On +2021-09-05 12:50:56 +0200, Liliana Marie Prikler wrote: > Hi, > > Am Sonntag, den 05.09.2021, 11:50 +0200 schrieb Bengt Richter: > > > We don't call things build-inputs here in Guix land, that's a no-no > > > :P > > > > Is there an official guix jargon file or glossary file or texi file > > or wikimedia/wiktionary/wikipedia clone on gnu.org that non- > > cognoscenti could use to get a clue? > AFAIK no, you more or less have to go by what the manual tells you. As > for why we have native-inputs and not build-inputs like other distros, > it's because people often misclassify "build" inputs, so the definition > actually does more harm than good. Guix knows which files are actually > "just used for build" by what ends up in the store, with some > exceptions like UTF-32 encoded strings. > > > Is there a thread that on that topic making any progress on making it > > happen? > AFAIK no. > > > when someone in a thread like this offers a candidate official > > definition, (off-topic sort of, but meta-on-topic for relevant > > documentation) could it be snip-quoted for easy search and > > aggregation for maintainers of official definitions and translations? > > E.g. > > (or actually borrow some rfc0842 or descendant so an attached file > > generates a usuable section in mail archives that can be snarfed > > automatically?) > > > > --8<---cut here---start->8--- > > X-Content-type: Cadidate-guix-jargon-definition > > Ad lib comment and metacomment ended by blank line ... > > "> We don't call things build-inputs here in Guix land, that's a no- > > no :P" > > > > build-propagated-inputs: > > > > --8<---cut here---end--->8--- > When you quote someone like that out-of-context, you run a risk of > misrepresenting what is actually stated. What I mean, is that a > package field called something along the lines of "build-inputs" is > likely to confuse Guix veterans and newcomers alike, as evidenced by > the following reply: > > Am Sonntag, den 05.09.2021, 10:06 + schrieb Attila Lendvai: > > potentially worthless two cents from a newcomer's perspective: > > 'build-time' and 'run-time' are well established concepts in the > > wider community. > And one, that is well misunderstood. > > > if i were reading 'linked-inputs' in a package definition, i wouldn't > > associate it to being the set of buil
Re: Rethinking propagated inputs?
Hi, On +2021-09-05 09:36:30 +0200, Liliana Marie Prikler wrote: > Am Samstag, den 04.09.2021, 17:50 -0700 schrieb Sarah Morgensen: > > Hi Liliana, > > > > (Efraim, I've Cc'd you since you're working on re-doing Rust inputs.) > > > > Liliana Marie Prikler writes: > > > > > Does anyone have an idea how we should handle propagations for the > > > sake of pkg-config? Perhaps we could add "linked-inputs", which > > > are added when building packages and environments when not using -- > > > ad-hoc, but not when union-building profiles. WDYT? > > > > I know nothing about pkg-config, but such an input would help > > simplify things for Go (and I think for Rust) since many inputs need > > to be propagated only at build-time. > To be fair, I wasn't not thinking about Go and Rust, which at least on > the surface appear to have similar propagation semantics. I do however > not know whether all currently propagated inputs from those two could > be reclassified as linked-inputs. FWIW I don't think (most) Emacs, > Python or Guile packages work that way, but I do know of at least one > that would profit from having linked-inputs. > > > What do you think of "build-propagated-inputs"? > We don't call things build-inputs here in Guix land, that's a no-no :P > Is there an official guix jargon file or glossary file or texi file or wikimedia/wiktionary/wikipedia clone on gnu.org that non-cognoscenti could use to get a clue? Is there a thread that on that topic making any progress on making it happen? when someone in a thread like this offers a candidate official definition, (off-topic sort of, but meta-on-topic for relevant documentation) could it be snip-quoted for easy search and aggregation for maintainers of official definitions and translations? E.g. (or actually borrow some rfc0842 or descendant so an attached file generates a usuable section in mail archives that can be snarfed automatically?) --8<---cut here---start->8--- X-Content-type: Cadidate-guix-jargon-definition Ad lib comment and metacomment ended by blank line ... "> We don't call things build-inputs here in Guix land, that's a no-no :P" build-propagated-inputs: --8<---cut here---end--->8--- > > (A quick search of the ML turned up one previous discussion [0]; does > > anyone know of others?) > > > > [0] > > https://lists.gnu.org/archive/html/guix-devel/2017-02/msg00362.html > W.r.t. native-inputs, I think native-inputs should propagate > propagated-inputs, but not linked-inputs. Makes sense, doesn't it? > > -- Regards, Bengt Richter
Re: packaging go-ethereum, and ultimately bee (of ethswarm.org)
tream. > > > > > > Another problem is: if a go package has many (transitive) dependencies, > > > > how do > > > > we check that it doesn't contain any malware or non-free components? > > > > That needs > > > > > > go-ethereum is a software that handles ethereum wallets with several > > > zeroes. they are probably equally worried about this if not more. > > > > I'm sure the go-ethereum peope wouldn't mind if we double-check that no > > malware > > slipt through their review process. > > [...] > > > > for projects like go-ethereum, it's not an option for the packager to > > > make decisions about the version of any of its dependencies. > > > > Why isn't this an option? Choosing different versions from upstream is > > already > > done in guix, see e.g. https://issues.guix.gnu.org/50217 (ok that's not > > merged > > yet, not the best example --- note, editing the version requirement was > > on my advice, see https://logs.guix.gnu.org/guix/2021-08-26.log). > > > extra auditing on top of the official release is certainly welcome by > each player. but, realisticly, i doubt that the hundreds of guix go > packages will get comparable amount of security-auditing-attention any > time soon. let alone -- and this is of key importance here -- auditing > any possible cross-interactions of altered versions of the > dependencies! who else is qualified to do that better than the > developers themselves? > > for a program like the ethereum client, any such semantic surprises > may be disasterous. (losing money in various ways. e.g. their client > forking off of the consensus of the ethereum network, and if e.g. they > are paricipating in staking, then they will suffer penalties for not > adhering to the rules of the network, etc.) > > this is why i would prefer to have a solution that somehow reproduces, > compares, and runs the same binary as the officially released one. > > in the follwig days i'll play with reproducing the geth release binary > on my guix, and also planning to mock up a binary downloader package, > and see how it goes. i'll report back with anything worth mentioning. > > > > I see a third viable option (3): treat the "go.sum" as a mere > > ‘friendly suggestion’, and just use the latest version when feasible. > > Again, I don't see much difference with, say, haskell, python, ruby, > > guile, java ... packages. > > > my point here is not that all go projects should be packaged like this > (i.e. with exacly pinned dependencies), but that applications like > geth should be, regardless of the language they are written in. > > in case of a random image viewer written in go, i'm all in for a > relaxed handling of dependencies. > > > > Have there been any problems in practice with just using the latest > > version (updating the version currently in guix where applicable)? > > > not that i'm aware of, but the first such identified issue could turn > out to be very expensive. > > - attila > > -- Regards, Bengt Richter
Re: Use of %texlive-revision and %texlive-tag in tex.scm
On +2021-07-06 15:28:43 -0300, Nathan Benedetto Proença wrote: > Bengt Richter writes: > > > Hi Nathan, > > Nice writeup! > > Thank you! > > > On +2021-07-05 11:03:46 -0300, Nathan Benedetto Proença wrote: > >> Hello! > >> > >> I am trying to upgrade the package texlive, first for me, but hopefully > >> for a patch, and I have a question regarding Guix policies. > >> > >> As you can see on > >> > >> > >> https://git.savannah.gnu.org/cgit/guix.git/tree/guix/build-system/texlive.scm?id=f7692617b624a01615cf412773c4dad9a2deeb68 > >> > >> the file guix/build-system/texlive.scm exposes two variables: > >> > >> (define %texlive-tag "texlive-2019.3") > >> (define %texlive-revision 51265) > >> > >> These variables are used throughout gnu/packages/tex.scm, as you can see > >> on > >> > >> > >> https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/tex.scm?id=f7692617b624a01615cf412773c4dad9a2deeb68 > >> > >> An example is the following code: > >> > >> (define hyph-utf8-scripts > >> (origin > >> (method svn-fetch) > >> (uri (texlive-ref "generic" "hyph-utf8")) > >> (file-name (string-append "hyph-utf8-scripts-" > >> (number->string %texlive-revision) > >> "-checkout")) > >> (sha256 > >>(base32 > >> "0lk7shx768sxvgr85y8bnmmnj8x4bbkgpxrz3z8jp8avi33prw83" > >> > >> Grep tells me there are 290+ occurrences of `%texlive-revision`. > >> What is the purpose of these variables? > >> > >> You see, they give me the impression that Guix is really concerned about > >> upgrading *all* of texlive at once. > >> These variables tell me I should go to the file texlive.scm and bump the > >> tag and revision, and then handle all the broken hashes. > >> > >> Hence, it seems to me that any attempt to upgrade the texlive package > >> would have to be done in a separate branch, which would only be merged > >> into master when all the packages are upgraded. > >> > >> Is this the case? > >> And if so, why? > >> > >> I have the impression that if such "monolithic" upgrade is not a goal, > >> and "partial" our "per-package" upgrades are desirable, there may be > >> better solutions. > >> > >> For example, we could add keyword arguments to texlive-ref and > >> texlive-origin, so the code above becomes something like this > >> > >> (define hyph-utf8-scripts > >> (origin > >> (method svn-fetch) > >> (uri (texlive-ref "generic" "hyph-utf8" > >> #:texlive-tag "texlive-2019.3" > >> #:texlive-revision 51265)) > >> (file-name "hyph-utf8-scripts-51625-checkout") > >> (sha256 > >>(base32 > >> "0lk7shx768sxvgr85y8bnmmnj8x4bbkgpxrz3z8jp8avi33prw83" > >> > >> This would work right now, and we could eventually remove every use of > >> %texlive-revision and %texlive-tag, so they become implementation > >> details of the build-system texlive.scm; a fallback version. > >> And further down the road we may even decide to remove this fallback, > >> and make developers be explicit about their tags and revisions; this > >> could amount to a refactor which makes the keyword arguments into > >> required arguments, for example. > >> > >> I also like the second version of the code because the hash already > >> pinpoints the tag and revision: both texlive-ref and texlive-origin use > >> these variables to find the correct files to download. > >> This just makes this dependency explicit. > >> > >> In any case, as this may be a choice between shipping stable and > >> up-to-date packages, and as I am new to contributing to Guix, I found > >> fitting to ask. > >> > >> Thanks in advance! > >> Nathan > >> > > > > I am wondering about guaranteeing generic behaviour by > > guaranteeing program source and toolchain source hash > > equivalences vs ignoring sources and guaranteeing end > > results by testing results. > > It seems to me that you a
Re: Use of %texlive-revision and %texlive-tag in tex.scm
Hi Nathan, Nice writeup! On +2021-07-05 11:03:46 -0300, Nathan Benedetto Proença wrote: > Hello! > > I am trying to upgrade the package texlive, first for me, but hopefully > for a patch, and I have a question regarding Guix policies. > > As you can see on > > > https://git.savannah.gnu.org/cgit/guix.git/tree/guix/build-system/texlive.scm?id=f7692617b624a01615cf412773c4dad9a2deeb68 > > the file guix/build-system/texlive.scm exposes two variables: > > (define %texlive-tag "texlive-2019.3") > (define %texlive-revision 51265) > > These variables are used throughout gnu/packages/tex.scm, as you can see > on > > > https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/tex.scm?id=f7692617b624a01615cf412773c4dad9a2deeb68 > > An example is the following code: > > (define hyph-utf8-scripts > (origin > (method svn-fetch) > (uri (texlive-ref "generic" "hyph-utf8")) > (file-name (string-append "hyph-utf8-scripts-" > (number->string %texlive-revision) > "-checkout")) > (sha256 >(base32 > "0lk7shx768sxvgr85y8bnmmnj8x4bbkgpxrz3z8jp8avi33prw83" > > Grep tells me there are 290+ occurrences of `%texlive-revision`. > What is the purpose of these variables? > > You see, they give me the impression that Guix is really concerned about > upgrading *all* of texlive at once. > These variables tell me I should go to the file texlive.scm and bump the > tag and revision, and then handle all the broken hashes. > > Hence, it seems to me that any attempt to upgrade the texlive package > would have to be done in a separate branch, which would only be merged > into master when all the packages are upgraded. > > Is this the case? > And if so, why? > > I have the impression that if such "monolithic" upgrade is not a goal, > and "partial" our "per-package" upgrades are desirable, there may be > better solutions. > > For example, we could add keyword arguments to texlive-ref and > texlive-origin, so the code above becomes something like this > > (define hyph-utf8-scripts > (origin > (method svn-fetch) > (uri (texlive-ref "generic" "hyph-utf8" > #:texlive-tag "texlive-2019.3" > #:texlive-revision 51265)) > (file-name "hyph-utf8-scripts-51625-checkout") > (sha256 >(base32 > "0lk7shx768sxvgr85y8bnmmnj8x4bbkgpxrz3z8jp8avi33prw83" > > This would work right now, and we could eventually remove every use of > %texlive-revision and %texlive-tag, so they become implementation > details of the build-system texlive.scm; a fallback version. > And further down the road we may even decide to remove this fallback, > and make developers be explicit about their tags and revisions; this > could amount to a refactor which makes the keyword arguments into > required arguments, for example. > > I also like the second version of the code because the hash already > pinpoints the tag and revision: both texlive-ref and texlive-origin use > these variables to find the correct files to download. > This just makes this dependency explicit. > > In any case, as this may be a choice between shipping stable and > up-to-date packages, and as I am new to contributing to Guix, I found > fitting to ask. > > Thanks in advance! > Nathan > I am wondering about guaranteeing generic behaviour by guaranteeing program source and toolchain source hash equivalences vs ignoring sources and guaranteeing end results by testing results. I.e., if you want to print the sum of x and y passed as strings to a program, output as a string to stdout, it doesn't matter (other than optimization and debuggability) what language the program was written in, so long as it was compiled into a form that execve and co can launch and the end result is the same. As part of testing, maybe strace could be used to generate some kind of canonical kernel transaction trace that could be used to compare behaviours for equivalency of executing different-language programs? This would be a radical change in the approach to reproducibility, maybe dynamically selecting from a whitelist of trusted/tested substitutable executables with hash names in /gnu but not necessarily (though not excluding) binaries produced with guix source guarantees. Seems like guix is turing-complete enough to provide this kind of substitutable foreign functions already, so might this be a way to avoid mass recompilations? Or is this already available, but not so much used? I am not sure where to contibute thoughts like these, where they would be of interest rather than distracting. (Pls excuse the noise, if that's what this is to you). -- Regards, Bengt Richter
Re: Supporting *multiple* bootloaders for arm64 on a single install?
unrecognized image and ask authorized operator for ok + hash nickname for inclusion in the whitelist or reject? If ok, jump into boot image as normal. If a developer I trust says (in a securely communicated way) that I can safely load something with a hash of whatever, I think that is more trustworthy than pretty much anything else I can think of. And on a forum, someone else can say, "Don't trust that thing with hash xxx...zzz, it blew up for me," and I can hold off until there's a consensus. WDYT? BTW, why not build multiple installer ISOs targeted for different architectures, and specialized needs? (for smaller ISOs and other benefits). I assume one could already do this with guix, but why not leave the whole ball-of-wax to git clone, and let people with common architectures have less to download and less irrelevant-to-them choices? > > Bye > > Stefan > > > ¹ <https://documentation-service.arm.com/static/5fb7e415d77dd807b9a80c80> -- Regards, Bengt Richter
Re: GNU Guix 1.4.0 in September? (was: Re: GNU Guix 1.3.0 released)
Hi all, On +2021-05-17 10:43:36 -0400, Leo Famulari wrote: > On Mon, May 17, 2021 at 02:55:39PM +0200, zimoun wrote: > > I remember a plot sent to guix-maintaainers about the number of grafts, > > the core-updates merges and the release dates. I am not sure it is > > really interesting and it is worth to resend it, or maybe dumping the > > Cuirass database to investigate a bit more. Well, my point is the > > core-updates merges and the release dates should be synchronized; say > > target the core-updates for end of September, then the release for > > November. To me, this synchronisation makes senses because it > > constraints the ~6months core-updates cycle and in the same time, the 2 > > releases per year. > > I like this idea. > This sounds like planning activity. Gnome has an app called planner ;-) Would it make sense to discuss a way to put these rc- and other related goals on a gantt chart? Maybe even automate import from mailing list emails marked with e.g. [release-planning] in the subject and one delimited markup region like --8<---cut here---start->8--- planner-importable xml here --8<---cut here---end--->8--- Discussion without triggering automated import would just leave "[release-plannng]" out of the Subject: line, or have e.g. [release-discussion] in the Subject: line. Anyway, I thought a nice gantt chart .svg or .png or .pdf might be nice :) Thoughts? -- Regards, Bengt Richter
Re: Free software telemetry and the Guix System
Hi all, On +2021-05-14 16:52:25 -0400, Leo Famulari wrote: > On Fri, May 14, 2021 at 06:55:34PM +, Cook, Malcolm wrote: > > > If these claims are true, then I think this is quite satisfactory for > > > our purposes. I wouldn't even object to enabling the telemetry code via > > > the CMake build-time option, as long as it's "opt-in", i.e. that each > > > user must explicitly enable it, and only after being made aware of the > > > consequences of doing so. > > > > > > What do you think? > > > > My 2 cents: I think the Audacity model is exemplary and your > > interpretation is spot on. I personally want the option of enabling such > > telemetry, as it may well serve my needs and may also give the developer > > valuable usage and/or crash info which is the least I can provide in return > > for such a great FOSS app as Audacity. > > +1 > My 2 cents: :) I like options, but I would feel more secure if it were implemented in a separate, dynamically linked when opted-in, some-implementation.so which I could get the kernel to prevent access to, e.g. by # chmod 400 some-implementation.so -- Regards, Bengt Richter
Re: Interesting reading for minimalists, esp mes folks? :)
On +2021-05-08 12:56:36 +0200, Bengt Richter wrote: > Hi minimalists :) > Forgot the main project link [6] ;/ > In case you hadn't yet come across this (LWN did a piece [5] about a year ago, > which was the first I heard of it. (Chasing a dream led me to check > more current status) Enjoy :) > > [1] > https://drops.dagstuhl.de/opus/volltexte/2020/11779/pdf/OASIcs-NG-RES-2020-3.pdf > [2] https://github.com/bao-project/bao-demos > [3] https://github.com/bao-project/bao-hypervisor > [4] https://github.com/bao-project/bao-hypervisor#readme > [5] https://lwn.net/Articles/820830/ [6] http://www.bao-project.org/ > > To whet your appetite (from the README at [4]): > > --8<---cut here---start->8--- > Bao has no external dependencies, such as on privileged VMs running > untrustable, > large monolithic general-purpose operating systems (e.g., Linux), and, as > such, > encompasses a much smaller TCB. > > Bao originally targets the Armv8-A architecture, but there is experimental > support > for the RISC-V architecture. The full list of supported (and work in > progress) > platforms is presented below: > > - [x] Xilinx Zynq UltraScale+ MPSoC ZCU102 (Armv8-A) > - [x] Xilinx Zynq UltraScale+ MPSoC ZCU104 (Armv8-A) > - [x] Ultra96 Zynq UltraScale+ ZU3EG (Armv8-A) > - [x] 96Boards HiKey 960 (Armv8-A) > - [ ] NXP MCIMX8M-EVK (Armv8-A) - wip > - [ ] NXP MCIMX8QM-CPU (Armv8-A) - wip > - [ ] 96Boards ROCK960 (Armv8-A) - wip > - [ ] QEMU virt (Armv8-A) - wip > - [ ] QEMU virt (RISC-V rv64) - wip > > **NOTE**: This is work in progress! Don't expect things to be complete. > Use at your own risk. > --8<---cut here---end--->8--- > > -- > Regards, > Bengt Richter > -- Regards, Bengt Richter
Interesting reading for minimalists, esp mes folks? :)
Hi minimalists :) In case you hadn't yet come across this (LWN did a piece [5] about a year ago, which was the first I heard of it. (Chasing a dream led me to check more current status) Enjoy :) [1] https://drops.dagstuhl.de/opus/volltexte/2020/11779/pdf/OASIcs-NG-RES-2020-3.pdf [2] https://github.com/bao-project/bao-demos [3] https://github.com/bao-project/bao-hypervisor [4] https://github.com/bao-project/bao-hypervisor#readme [5] https://lwn.net/Articles/820830/ To whet your appetite (from the README at [4]): --8<---cut here---start->8--- Bao has no external dependencies, such as on privileged VMs running untrustable, large monolithic general-purpose operating systems (e.g., Linux), and, as such, encompasses a much smaller TCB. Bao originally targets the Armv8-A architecture, but there is experimental support for the RISC-V architecture. The full list of supported (and work in progress) platforms is presented below: - [x] Xilinx Zynq UltraScale+ MPSoC ZCU102 (Armv8-A) - [x] Xilinx Zynq UltraScale+ MPSoC ZCU104 (Armv8-A) - [x] Ultra96 Zynq UltraScale+ ZU3EG (Armv8-A) - [x] 96Boards HiKey 960 (Armv8-A) - [ ] NXP MCIMX8M-EVK (Armv8-A) - wip - [ ] NXP MCIMX8QM-CPU (Armv8-A) - wip - [ ] 96Boards ROCK960 (Armv8-A) - wip - [ ] QEMU virt (Armv8-A) - wip - [ ] QEMU virt (RISC-V rv64) - wip **NOTE**: This is work in progress! Don't expect things to be complete. Use at your own risk. --8<---cut here---end--->8--- -- Regards, Bengt Richter
Re: A "cosmetic changes" commit that removes security fixes
Hi Pierre, On +2021-05-03 09:25:21 +0200, Pierre Neidhardt wrote: > Hi Giovanni, > > > Guix is a GNU project and AFAIU GNU project management is well > > documented: > > > > https://www.gnu.org/gnu/gnu-structure.html > > This applies to GNU at the top level, but it does not specify how > sub-projects (referred to as "packages" in the aforementioned document) > are governed locally. This question is mostly left unanswered as I > understand it. > You may find some clues here: https://www.gnu.org/help/evaluation.html#whatmeans And links to more :) > Cheers! > > -- > Pierre Neidhardt > https://ambrevar.xyz/ -- Regards, Bengt Richter
Re: RISC-V is giving away developer boards
Hi all, On +2021-04-30 21:35:22 +0200, Pjotr Prins wrote: > It is probably a good idea to apply from an academic institution to > increase chances of getting a free board. I am happy to help with the > application. > > We already have the 2GB RAM polarfire which we mostly use for toy > stuff right now: > > https://www.cnx-software.com/2020/07/20/polarfire-soc-icicle-64-bit-risc-v-and-fpga-development-board-runs-linux-or-freebsd/ > > If anyone is serious about a GNU Mes and/or GNU Guix port I can help > find a RISC-V board one way or another. Sounds like time and money > well spent to me. > > Pj. Could some riscv-model-version.scm be written to use qemu to create an exact virtual metal RISC-V board (of the kind being sampled, for starters) for use on our laptops and PCs? I think that might get more people involved, and would ideally produce images that would "just work" on the bare metal boards. Maybe guix could become a preferred RISC-V development environment :) Thoughts? > > On Fri, Apr 30, 2021 at 01:15:49PM -0400, Leo Famulari wrote: > > On Fri, Apr 30, 2021 at 06:36:29PM +0200, Ludovic Courtès wrote: > > > Could interested developers raise their hands? :-) > > > > I previously applied for early access to the BeagleV: > > > > https://beagleboard.org/beaglev > > > > I wasn't selected and I decided to focus on aarch64 for now. > > > > Hopefully some other people can step up and apply via this new program! > > > -- Regards, Bengt Richter
Re: Security related tooling project
Hi, tl;dr: Given that crims monitor developer discussions to discover unfixed vulnerabilities and clues re exploiting them, what are your ideas to avoid building a tool that can be abused? E.g., How will your tool avoid leaking info during an embargo window while trusted developers are secretly/privately fixing critical vulns? (pls excuse the top-post) -- On +2021-04-17 17:20:13 +0200, Ludovic Courtès wrote: > Hello Chris! > > Christopher Baines skribis: > > > In May last year (2020), I submitted an application to NLNet. The work I > > set out wasn't something I was doing at the time, but something I hadn't > > yet found time to work on, tooling specifically around security issues. > > > > The application got a bit lost, probably somewhat down to email issues > > on my end. Anyway, things picked up again in February of this year > > (2021), and this is now something I'm looking to do roughly over the > > next 8 months. > > I’m late to the party, but I think this is excellent news! Well done! > > > 1: https://git.cbaines.net/guix/tooling-to-improve-security-and-trust/about/ > > [...] > > > In terms of looking at security from a project perspective, I'm thinking > > about these kinds of needs/questions: > > > > - What security issues affect this revision of Guix? (latest or otherwise) > > > > - How do Guix contributors find out about new security issues that > >affect Guix revisions they're interested in? > > > > From the user perspective, I want to look at things like: > > > > - How do I find out what (if any) security issues affect the software > >I'm currently running (through Guix)? > > > > - How can I get notified when a new security issue affects the software > >I'm currently running (through Guix)? > > That sounds like a great plan! > > I see several “intermediate” issues that would be super helpful for the > overall project, such as better CPE matching as Léo suggested and/or > providing CPE suggestions: <https://issues.guix.gnu.org/42299>. > > I think the Data Service is in a great position to help out > wrt. monitoring. I think it’d be nice to architect things in a way that > services enhance monitoring, but are not required for get proper > monitoring. For instance, the proposed ‘guix health’¹ can be > implemented without relying on intermediate services at all (it still > needs to rely on the NIST server, of course, but we don’t need extra > services.) > > Anyhow, it’s awesome to see you work in this area. Like Chris Marusich > wrote, Guix is in a good position to address security issues, and you’re > obviously in a very good position to know what and how to improve the > state of things in Guix, so all hail! > > Ludo’. > > ¹ https://issues.guix.gnu.org/31442 > -- Regards, Bengt Richter
Re: Why ban underscores?
Hi, On +2021-04-04 17:05:57 -0400, Mark H Weaver wrote: > Tobias Geerinckx-Rice writes: > > > Indeed, underscores were explicitly banned in 2014 (commit > > 25083588). Why? > > > > Where's the advantage in renaming the following packages from > > their canonical names? > > While I was not involved in this decision, I think it's desirable to > standardize on a single hyphen-like character. Otherwise, it is likely > that people who prefer "_" over "-" will start using "_" in newly added > package names, which could lead to a proliferation of undesirable > diversity in our choices of hyphen-like characters. Then, we'd all have > to remember when typing a package name: "is this one of those packages > that uses underscores instead of hyphens?" > >Mark > I note that underscore is not one of the safe 73 characters mentioned in rfc2049. Maybe related? -- Regards, Bengt Richter
Re: Deep vs Shallow trace: Removing the tradeoff?
> again before sending my previous email, I read it quite a long time ago.. The > property I was trying to recover in the nix-style build systems is this idea > of an early cutoff. The strategy for achieving that is to use constructive > traces with depth 1 (what I was calling "shallow traces") and then recursive > succinct arguments of knowledge for retaining the shallow build property that > you get from the "infinitely deep traces". > > > I don't really understand why it must be zero-knowledge. My understanding > > is that to have a zero-knowledge proof, you first need a proof of the > > claim, then find a clever way to proove you have the proof, without > > disclosing it. Not sure it's helpful here. If you have a proof that you > > don't need to rebuild, why not share that proof to everyone in the first > > place? > > Sure, you only need the succinctness property. I should have been more > precise, what I am mainly after is resolving the tradeoff between shallow and > deep traces. > > I hope that this discussion can at least be helpful for people that are not > familiar with these ideas, even if - as it seems from your response - the > idea does not have merit. > > Kind regards, > - ilmu -- Regards, Bengt Richter
Security-czar needed? WAS: Re: Release 1.2.1: zstd 1.4.4 -> 1.4.9: grafting or core-updates?
Hi all, On +2021-03-16 15:29:43 -0400, Leo Famulari wrote: > On Tue, Mar 16, 2021 at 08:25:50PM +0100, zimoun wrote: > > Hi, > > > > On Tue, 16 Mar 2021 at 20:18, Leo Famulari wrote: > > > On Tue, Mar 16, 2021 at 07:19:53PM +0100, zimoun wrote: > > > > I guess that it will not build for i686. Does it? > > > > > > I don't know. Either we will find out when building on CI, or people can > > > test it manually now. > > > > Please try out the patch from: > > > > <https://lists.gnu.org/archive/html/guix-devel/2021-03/msg00295.html> > > > > and if it works for you, please apply it. > > No, sorry :) Someone else (maybe an i686 user?) will have to find the > time to test it. > I would feel better about running guix on my laptop if I knew all you developers had gotten together and elected a "security czar" who is the most competent of you to monitor security and also cares the most, and had the power to prevent applying unreviewed patches, and making sure all CVEs are taken care of, and kitchen doors not left open the way we did in the '50s. Sorry if it sounds like I think guix security is lax. Please convince me it's not so ;) Thanks, nevertheless, for all the great technical work! Just wish I could type guix --what-and-who-am-I-trusting-q --full-report and get a complete list, with batting averages of the developers (regressions vs fixes), packages (estimated number of times executed without problem, dangerous bugs in development history, etc). -- Regards, Bengt Richter
Heads-up from Linus -- potential bisection trainwreck: "A note on the 5.12-rc1 tag"
Hi, Not so usual to be switching rc kernels for guix I suppose, but this looked worth mentioning anyway: LWN archive link [1] [1]https://lwn.net/ml/linux-kernel/CAHk-=wjnzdlsp3odxhf9emtyo7gf-qjanlbuh1zk3c4a7x7...@mail.gmail.com/ In case of link problem, a couple of extractions: --8<---cut here---start->8--- From: Linus Torvalds To: Linux Kernel Mailing List Subject:A note on the 5.12-rc1 tag Date: Wed, 03 Mar 2021 12:53:18 -0800 Message-ID: Hey peeps - some of you may have already noticed that in my public git tree, the "v5.12-rc1" tag has magically been renamed to "v5.12-rc1-dontuse". It's still the same object, it still says "v5.12-rc1" internally, and it is still is signed by me, but the user-visible name of the tag has changed. The reason is fairly straightforward: this merge window, we had a very innocuous code cleanup and simplification that raised no red flags at all, but had a subtle and very nasty bug in it: swap files stopped working right. And they stopped working in a particularly bad way: the offset of the start of the swap file was lost. Swapping still happened, but it happened to the wrong part of the filesystem, with the obvious catastrophic end results. [ -- snip discussion why all will not be hit -- ] But I want everybody to be aware of because _if_ it bites you, it bites you hard, and you can end up with a filesystem that is essentially overwritten by random swap data. This is what we in the industry call "double ungood". --8<---cut here---end--->8--- -- Regards, Bengt Richter
Installing via iso.xz, really best idea? -- was Re: Gnome Boxes
ht wget and dd commands and sha256 verifications, while providing safe interactive choice of target disk(s) at the start of running it. Such a script, built to run on a specific but non-guile/guix-dependent "foreign" platform like Linux x86_64 would be a nice way to share a "my-neat-system" ... or a Guix release. So it seems to me, anyway :) (I know you can do all kinds of things with laptops already running guix. A main point here is to be able to use a (borrowed even) foreign, non-guile/guix laptop to install something onto raw USB-attached storage without transferring anything from the state of the laptop doing the work (i.e., xfr only, no synthesis). I.e., the system or data being transferred could be for a totally different architecture or purpose. For the paranoid, a first-boot (assuming new thing is bootable) hook could re-check all the hashes on the new system. (Please excuse all the handwaving :) > On Thu, Feb 18, 2021 at 4:23 PM Julien Lepiller wrote: > > > Sorry, a compressed .iso is probably common, a .iso.xz is very uncommon > > :). We even have had some reports of people trying to copy that directly to > > an installation media. > > > > Le 18 février 2021 14:56:44 GMT-05:00, Tobias Geerinckx-Rice > > > > a écrit : > >> > >> Julien Lepiller 写道： > >> > >>> Usually compression is provided by the webserver, but maybe ours > >>> is not configured to do that. I think we're the only distro to > >>> provide compressed isos. > >>> > >> > >> Really? Most distribution ISOs use squashfs or similar with > >> XZ/LZMA compression. It doesn't make sense to compress that over > >> the wire. > >> > >> That said: XZ compression currently saves 27% (559M -> 405M). > >> Transparently serving pre-compressed ISOs with nginx (gzip level > >> 9) would save about 25% (559M -> 415M), which is surprisingly > >> similar. > >> > >> Kind regards, > >> > >> T G-R > >> > >> > > -- > - EJR Hm, I wonder how large a tarball "guix pack" as it works now would create to create something runnable with the my-neat-system-bootstrap.sh functionality described above, vs depending on the foreign system's bash, wget, dd, etc. -- Regards, Bengt Richter
Re: TOCTTOU race (was: Potential security weakness in Guix services)
Hi, On +2021-02-14 13:29:29 +0100, Maxime Devos wrote: > On Sat, 2021-02-06 at 22:26 +0100, Ludovic Courtès wrote: > > > > [...] > > I understand the TOCTTOU race. However, activation code runs in two > > situations: when booting the system (before shepherd takes over), and > > upon ‘guix system reconfigure’ completion. > > Until we have a guix jargon file and a guix gloss SEARCHARGS ... convenience command, it is nice towards noobs to spell out an abbreviation or acronym on first use ;-) --8<---cut here---start->8--- Time-of-check to time-of-use From Wikipedia, the free encyclopedia (Redirected from TOCTTOU) Jump to navigation Jump to search In software development, time-of-check to time-of-use (TOCTOU, TOCTTOU or TOC/TOU) is a class of software bugs caused by a race condition involving the checking of the state of a part of a system (such as a security credential) and the use of the results of that check. TOCTOU race conditions are common in Unix between operations on the file system,^[1] but can occur in other contexts, including local sockets and improper use of database transactions. In the early 1990s, the mail utility of BSD 4.3 UNIX had an exploitable race condition for temporary files because it used the mktemp()^[2] function.^[3] Early versions of OpenSSH had an exploitable race condition for Unix domain sockets.^[4] They remain a problem in modern systems; as of 2019, a TOCTOU race condition in Docker allows root access to the filesystem of the host platform.^[5] [ ] --8<---cut here---end------->8--- [...snip...] -- Regards, Bengt Richter
Re: GWL 0.3.0 released
On +2021-02-11 21:37:56 +0100, Ricardo Wurmus wrote: > > Bengt Richter writes: > > > gpg --verify gwl-0.3.0.tar.gz.sig > > gpg: assuming signed data in 'gwl-0.3.0.tar.gz' > > gpg: Signature made Sat 06 Feb 2021 09:28:59 PM CET > > gpg:using RSA key BCA689B636553801C3C62150197A5888235FACAC > > gpg: Good signature from "Ricardo Wurmus (Work) > > " [expired] > > gpg: aka "rekado " [expired] > > ┌──┐ > > │ gpg: Note: This key has expired! │ > > └──┘ > > You should get a fresh key from keys.openpgp.org > Its expiry is regularly extended. > Thanks for all your Fosdem/guix work first of all, but I expected --8<---cut here---start->8--- [17:29 ~/bs]$ gpg --keyserver keys.gnupg.net --recv-keys BCA689B636553801C3C62150197A5888235FACAC gpg: key 197A5888235FACAC: 16 signatures not checked due to missing keys ┌───┐ │ gpg: key 197A5888235FACAC: "Ricardo Wurmus (Work) " not changed │ └───┘ gpg: Total number processed: 1 gpg: unchanged: 1 --8<---cut here---end--->8--- to give me an updated key, and am left wondering why it didn't :) It seems I have a wrong default for keyserver: --8<---cut here---start->8--- [22:21 ~/bs]$ gpg --refresh-keys gpg: refreshing 6 keys from hkp://hkps.pool.sks-keyservers.net gpg: key 197A5888235FACAC: 14 signatures not checked due to missing keys ┌───┐ │ gpg: key 197A5888235FACAC: "Ricardo Wurmus (Work) " not changed │ └───┘ --8<---cut here---end--->8--- Maybe the original advice for getting a key should be extended with the fresh key advice above (preferably the literal gpg command line, my guess re that boxed below). This seems to do it: ┌───┐ │ gpg --recv-keys BCA689B636553801C3C62150197A5888235FACAC --keyserver keys.openpgp.org │ └───┘ (though my first try was "gpg --refresh-keys --keyserver keys.openpgp.org" which only found you for the keys I have). --8<---cut here---start->8--- [22:44 ~/bs]$ gpg --recv-keys BCA689B636553801C3C62150197A5888235FACAC --keyserver keys.openpgp.org gpg: Note: '--keyserver' is not considered an option gpg: "--keyserver" not a key ID: skipping gpg: "keys.openpgp.org" not a key ID: skipping gpg: key 197A5888235FACAC: 16 signatures not checked due to missing keys gpg: key 197A5888235FACAC: "Ricardo Wurmus (Work) " not changed gpg: Total number processed: 1 gpg: unchanged: 1 --8<---cut here---end--->8--- Now gpg --verify works \o/ :) > > Ricardo -- Regards, Bengt Richter
Re: GWL 0.3.0 released
On +2021-02-10 22:05:45 +0100, Ludovic Courtès wrote: > Heya, > > Ricardo Wurmus skribis: > > > The Guix Workflow Language 0.3.0 has been released. > > > > I forgot to Cc y’all in the release announcement: > > > >https://lists.gnu.org/archive/html/gwl-devel/2021-02/msg0.html > > Congrats on all the hard work! > > If you didn’t follow FOSDEM, don’t miss Ricardo’s talk: > > https://fosdem.org/2021/schedule/event/guix_workflow/ > > Ludo’. > --8<---cut here---start->8--- gpg --verify gwl-0.3.0.tar.gz.sig gpg: assuming signed data in 'gwl-0.3.0.tar.gz' gpg: Signature made Sat 06 Feb 2021 09:28:59 PM CET gpg:using RSA key BCA689B636553801C3C62150197A5888235FACAC gpg: Good signature from "Ricardo Wurmus (Work) " [expired] gpg: aka "rekado " [expired] ┌──┐ │ gpg: Note: This key has expired! │ └──┘ Primary key fingerprint: BCA6 89B6 3655 3801 C3C6 2150 197A 5888 235F ACAC [17:26 ~/bs]$ wl-paste gpg --keyserver keys.gnupg.net --recv-keys BCA689B636553801C3C62150197A5888235FACAC [17:29 ~/bs]$ echo $(wl-paste ) gpg --keyserver keys.gnupg.net --recv-keys BCA689B636553801C3C62150197A5888235FACAC [17:29 ~/bs]$ gpg --keyserver keys.gnupg.net --recv-keys BCA689B636553801C3C62150197A5888235FACAC gpg: key 197A5888235FACAC: 16 signatures not checked due to missing keys ┌───┐ │ gpg: key 197A5888235FACAC: "Ricardo Wurmus (Work) " not changed │ └───┘ gpg: Total number processed: 1 gpg: unchanged: 1 [17:30 ~/bs]$ gpg --verify gwl-0.3.0.tar.gz.sig gpg: assuming signed data in 'gwl-0.3.0.tar.gz' gpg: Signature made Sat 06 Feb 2021 09:28:59 PM CET gpg:using RSA key BCA689B636553801C3C62150197A5888235FACAC gpg: Good signature from "Ricardo Wurmus (Work) " [expired] gpg: aka "rekado " [expired] ┌──┐ │ gpg: Note: This key has expired! │ └──┘ Primary key fingerprint: BCA6 89B6 3655 3801 C3C6 2150 197A 5888 235F ACAC [17:30 ~/bs]$ --8<---cut here---end--->8--- Thought someone might want to know. -- Regards, Bengt Richter
Re: Would a Guix QA page be helpful?
Hi Christopher, tl;dr: +1 :) On +2021-02-06 20:20:04 +, Christopher Baines wrote: > Hey, > > The Guix Data Service has been getting better at finding problems, but > getting that data requires knowing it exists, and where to find it, and > clicking all the relevant links. > > I've been wondering if it would be good to have a QA page that just > summarises and links to this information, things like: > > - Broken packages > - Broken system tests > - Broken fixed output package derivations > - Lint warnings > - ... > > While I'd really like to get to a place where less packages and system > tests are unintentionally broken, and less lint warnings are > unintentionally introduced, at the moment, there are plenty of these > problems. There's also things like the broken package sources, where > there will probably always be new breakages being introduced. > > Given the Guix Data Service can look at what's changed within a time > period on a branch, recent breakages could also be displayed. > > This could potentially sit at qa.guix.gnu.org. > > Any thoughts? > Mainly, please represent the info so that a person can get it with wget and extract items with grep or simple tool and inspect with any editor. I.e., some form of structured text. Someone will make a shiny browser interface, but don't please don't make that a dependency for access to the data. And please use '+%F %T ' date format for time stamps, UTC, so one doesn't have to wonder what year it was when looking at an old copy/paste or screen capture ;-) That'd be enough to please me, anyway :) Good tags for searching are helpful, of course. > Thanks, > > Chris -- Regards, Bengt Richter
Re: Emacs and URLs in Git commit messages
Hi Chris, On +2021-02-04 00:38:18 -0800, Chris Marusich wrote: > Hi, > > Many Guix commits look like this: > > commit f9978346e73359ac1d8b88c9ed874edc7225582b > Author: Ludovic Courtès > Date: Fri Dec 18 18:10:04 2020 +0100 > > avahi: Remove poll timeout when possible. > > Fixes <https://issues.guix.gnu.org/45314>. > > * guix/avahi.scm (avahi-browse-service-thread): Change timeout default > value > to false when no "stop-loop?" procedure is passed. Adapt > "iterate-simple-poll" > call accordingly. > > Signed-off-by: Mathieu Othacehe > > Regarding the URL, do people just type it all out, including the opening > and closing brackets (<>)? Or is there an Emacs command that does it > for you? I've briefly looked on the Internet, but this is the kind of > thing that seems difficult to search for. > I am not sure I understand your context or goal in searching ;/ I.e., what did you briefly look for on the internet? Did you search for an instance of "<https://issues.guix.gnu.org/45314>" hoping to find discussion of it elsehere than at the URL itself? What were you referring to with the "this" in "...this is the kind of thing that seems difficult to search for." ? If you were looking for alternate site discussion of bug#45314, duckduckgo seems to respond better without the '#' and narrowed by a last search term specifying the year, like duckduckgo "bug 45314" 2020 (don't leave out the quotes, and don't put the year inside them) NB: there are lots of bug trackers out there, so you will probably want to Ctl-f to ask your browser to walk through all the 45314's just by hitting Enter after that (firefox example). Not so many hits for 2021 yet, so I can show the result: (2 irrelevant hits :) --8<---cut here---start->8--- DuckDuckGo [...] FreeNAS - Bug #45314 [Search domain redmine.ixsystems.com/issues/45314.pdf] https://redmine.ixsystems.com/issues/45314.pdf FreeNAS - Bug #45314 Add the ability to set the password on first login if user left password blank during installation 09/07/2018 07:54 AM - Bonnie Follweiler Possible IPad/1.7 bug - Unity Forum [Search domain forum.unity.com/threads/possible-ipad-1-7-bug.45314/] https://forum.unity.com/threads/possible-ipad-1-7-bug.45314/ Unity ID. A Unity ID allows you to buy and/or subscribe to Unity products and services, shop in the Asset Store and participate in the Unity community. No more results found for "bug 45314" 2021. [...] --8<---cut here---end--->8--- If your context is in emacs editing a git commit, and you just want an easy command to insert a line like Fixes <https://issues.guix.gnu.org/45314>. ... I'm sure you can handle that yourself if you want to, hence my confusion about what you were up to ;) But maybe you are lazy like me, and wanted to see what was available. For me, that brings up the question of what form of solution would be most helpful to the most people if I offered one. E.g., I could 1. point you to the others' elisp solutions, 2. offer a bash script that formats the line based on clipboard-captured number (e.g., using xclip or wl-paste) which you can easily invoke from emacs by "Esc 1 Esc ! bash-script" 3. offer a guile script to do the same 4. offer a bash script that will compile and link a C program (source and commands all in script) that will do the same, assuming you have a usual x86_64 tool chain at hand, or 5. write it in some other interesting language (rash? :) I am not sure having the solution be dependent on emacs' (or any limiting entity's) internals is the most generally useful, but it's something I think about. I'd be interested in what you all think, though maybe it ought to be a new thread ;) > -- > Chris -- Regards, Bengt Richter
Re: PowerShell core?
Hi, On +2021-02-03 02:28:26 +0100, zimoun wrote: > Hi, > > Well, speaking about an > > >attempt to pull command > > interpreters out of the 70s > > ads: <https://fosdem.org/2021/schedule/event/lisprepl/> :-) > > (I previewed the talk and it is worth watching! Even, I previewed all > the talks of the «room» and they are all inspired and inspiring, see you > on Sunday. :-)) > > Cheers, > simon > [1]https://docs.racket-lang.org/rash/index.html If you have racket or raco at your command line, rash is only one or two commands from interaction with you :) I.e., racket -l rash/repl and/or to install rash raco pkg install rash A repo is at [2] [2] https://github.com/willghatch/racket-rash/blob/master/README.md Seems interesting, though I'm more into wayland innards right now, so I haven't done anything rash :) -- Regards, Bengt Richter
Re: PowerShell core?
Hi Yasu, On +2021-02-02 18:29:25 +0900, Yasuaki Kudo wrote: > Hi, > > Just curious, is there any interest in making PowerShell core available for > Guix? > > I have become quite fond of Powershell over the years (I say Powershell is > almost synonymous with IT worker rights - gives poor workers in sorry corners > of corporate world [those who are abandoned without adequate tools to get the > job done - because Windows is always there and Powershell comes with it!] a > huge productivity lift ) > > https://devblogs.microsoft.com/powershell/powershell-core-6-0-generally-available-ga-and-supported/ > > Cheers, > Yasu "Just curious", what do you hope will be the effect of your post? What functionality in PowerShell provides you with "a huge productivity lift" that you think is missing in the linux world? Who do you think is "...abandoned without adequate tools to get the job done..." ? If the "huge productivity lift" exists, are you proposing an independent implementation, or a guix package with microsoft-maintained sources as an upstream dependency ;/ (I didn't go to the powershell URL, sorry :) "I have become quite fond of Powershell over the years ..." Um, sounds like years of compromise (I don't mean technical, idk Powershell) :-p (Ok, sometimes a job you need for subsistence (or luxury/addiction) requires compromise, or no job). "Windows is always there and Powershell comes with it!" Is that a sales pitch ?? For what? Caveat emptor! "I say Powershell is almost synonymous with IT worker rights..." Sounds political -- something lost in translation? Sorry if I totally misread your post. -- Regards, Bengt Richter
Re: [bug#45919] [PATCH 0/8] Exporting a manifest and channels from a profile
e one honking great idea -- let's do more of those!
> >>> import numpy as np
> >>> A = np.array([[1,0,1],[0,1,0],[0,0,1]])
> >>> _, s, _ = np.linalg.svd(A); s; abs(s[0] - 1./s[2])
> array([1.61803399, 1., 0.61803399])
> 0.0
> >>>
> --8<---cut here---end--->8---
>
> Neat!
>
> So far, so good. Well, let extract the ’manifest’ from this Docker
> blob.
>
> --8<---cut here---start->8---
> $ docker export -o /tmp/img/re-pack.tar $(docker ps -a --format "{{.ID}}" |
> head -n1)
> $ tar -xf /tmp/img/re-pack.tar $(tar -tf /tmp/img/re-pack.tar | grep
> 'profile/manifest')
> $ cat gnu/store/7frdchgf5sqw8b83azsml3lw0h52gfbk-profile/manifest | grep -E
> "(\(\"python|cb68ae)" | head -n5
> (("python"
> "cb68ae668af2ade4b0777d82f227e5462768e9e5")
> ("python-ipython"
> (("python-backcall"
> ("python-pyzmq"
> --8<---cut here---end--->8---
>
> Now, a trick to get the channels and specifications:
>
> --8<---cut here---start->8---
> $ ./pre-inst-env guix package -p
> /tmp/img/gnu/store/7frdchgf5sqw8b83azsml3lw0h52gfbk-profile --export-channels
> ;; This channel file can be passed to 'guix pull -C' or to
> ;; 'guix time-machine -C' to obtain the Guix revision that was
> ;; used to populate this profile.
>
> (list
> (channel
>(name 'guix)
>(url "https://git.savannah.gnu.org/git/guix.git;)
>(commit
> "cb68ae668af2ade4b0777d82f227e5462768e9e5")
>(introduction
> (make-channel-introduction
>"9edb3f66fd807b096b48283debdcddccfea34bad"
>(openpgp-fingerprint
> "BBB0 2DDF 2CEA F6A8 0D1D E643 A2A0 6DF2 A33A 54FA"
> )
>
> $ ./pre-inst-env guix package -p
> /tmp/img/gnu/store/7frdchgf5sqw8b83azsml3lw0h52gfbk-profile --export-manifest
> $ ./pre-inst-env guix package -p
> /tmp/img/gnu/store/7frdchgf5sqw8b83azsml3lw0h52gfbk-profile --export-manifest
> ;; This "manifest" file can be passed to 'guix package -m' to reproduce
> ;; the content of your profile. This is "symbolic": it only specifies
> ;; package names. To reproduce the exact same profile, you also need to
> ;; capture the channels being used, as returned by "guix describe".
> ;; See the "Replicating Guix" section in the manual.
>
> (specifications->manifest
> (list "python"
> "python-ipython"
> "python-numpy"
> "python-matplotlib"
> "python-scipy"
> "python-biopython"))
> --8<---cut here---end--->8---
>
> Awesome!
>
>
> The unexpected is this channels and manifests files do not reproduce the
> same Docker pack tarball:
>
> --8<---cut here---start->8---
> $ guix describe
> Generation 99 Jan 05 2021 16:56:39(current)
> guix-past 829923f
> repository URL: https://gitlab.inria.fr/guix-hpc/guix-past
> branch: master
> commit: 829923f01f894f1e687735627025ada26230832f
> guix-bimsb a8b539d
> repository URL: https://github.com/BIMSBbioinfo/guix-bimsb
> branch: master
> commit: a8b539d61a359060c35f3cb34c7edd1d9d14241d
> bimsb-nonfree 4084e63
> repository URL: https://github.com/BIMSBbioinfo/guix-bimsb-nonfree.git
> branch: master
> commit: 4084e63c9c0d662780870aded9f5a6ca1b063780
> guix-science cf87b05
> repository URL: https://github.com/guix-science/guix-science.git
> branch: master
> commit: cf87b0501c4a38b96edf41025a27bf1cb91f521a
> guix 957f0c4
> repository URL: https://git.savannah.gnu.org/git/guix.git
> branch: master
> commit: 957f0c40327ce00f53db22737e3775ce616ac258
>
> $ guix time-machine -C /tmp/img/channels.scm -- pack -f docker
> --save-provenance -m /tmp/img/manifest.scm
> Updating channel 'guix' from Git repository at
> 'https://git.savannah.gnu.org/git/guix.git'...
> /gnu/store/xzk604g8gysv4azn7sf9nylr6iah97gl-docker-pack.tar.gz
> --8<---cut here---end--->8---
>
> To compare with
> /gnu/store/wxymmnxdvdvf08ifsfy39xjaxilhrigk-docker-pack.tar.gz.
>
> On a third machine, I get:
> /gnu/store/wxymmnxdvdvf08ifsfy39xjaxilhrigk-docker-pack.tar.gz
>
> Well, that’s another story and I have not inspected yet the
> derivations and what could be wrong on the machine B.
>
>
> Cheers,
> simon
>
KUTGW ;-)
--
Regards,
Bengt Richter
Re: How would packaging Steam-proton games be received?
O Ye of little Faith, please read: https://puri.sm/posts/the-future-of-software-supply-chain-security/ (It really is worth a read ;) On +2020-12-31 14:53:24 -0500, Leo Famulari wrote: > Hi Josh, > > I'm replying off-list, because this subject has been discussed s > many times without reaching a different conclusion, and because I worry > about starting a flamewar on the mailing list. > > On Thu, Dec 31, 2020 at 02:12:16PM -0500, Josh Marshall wrote: > > So a separate channel would work for non-free software? I know the stuff > > is fundamentally gross. I'd still like to have a better way to get out of > > an ecosystem that is basically entirely all non-free software and a > > transition to fully free becomes possible. > > If we think about free software in terms of the "4 freedoms" [0], > channels are a fully-supported way to help people take advantage of the > "zero-eth freedom", which is the freedom to use the software (Guix) as > one sees fit. > > Personally, I think that ensuring an operating system is 100% free > software (and with no DRM support) hampers the success of the free > software movement by driving away users. > > If we lived in a world with free software support for common hardware > (ahem, WiFi, Bluetooth, LTE) and for popular software use cases (popular > games and apps, commercial and educational software), then offering a > totally free system would be a viable approach. > > But, that world doesn't exist. Even though some people who are happy to > use 10+ year old computers for very limited use cases might think it > does... many of them don't even use mobile phones... they don't > understand contemporary computing at all, from a practical perspective. > > Nevertheless, the GNU Guix project has made a commitment to working > within the FSDG, and we are basically stuck with it barring some > cataclysmic change. > > I think that maintaining a harmonious atmosphere within Guix will help > it continue to grow, and channels can satisfy the need for things that > don't fit the FSDG. If Guix becomes large enough, it could be > transformative for the free software movement. > > [0] > https://www.gnu.org/philosophy/free-sw.en.html -- Regards, Bengt Richter
Re: Linux-Libre-LTS
er for any relevant comments/documentation to > state that the recommended practice when using LTS kernels is to use a > variable like "linux-libre-5.10", and to explain the reasons why. > I would like a .guix-ask-first profile with append-only installation default for itself, and the rest defaulting to avoidance of breakage. Another thing I would like is for .guix-ask-first to have access to some kind of package score for trustability, reliability, and hackability. I'm not sure how to define a scoring system, but I want it to tell me the difference between enthusiastic hobby-hacking and professional quality. But also about trusting motivations: there are pro saboteurs, and genius amateurs :) I like the stackoverflow scoring of answers. I'd like something similar for packages. > This is based on my expectation that Guix users who can tolerate > unscheduled breakage from kernel updates will probably just use our > default "linux-libre" kernel, and that users who would choose > "linux-libre-lts" are probably doing so because they wish to avoid being > caught off guard by unscheduled breakage. Does that make sense? > > What do you think? > See above :) > Thanks, > Mark > -- Regards, Bengt Richter
Re: 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
Re: Questionable "cosmetic changes" commits
Hi Christopher and Raghav, On +2020-12-05 21:54:36 +, Christopher Baines wrote: > > Raghav Gururajan writes: > > > Hi Mark! > > > >> Meanwhile, you've only provided a rationale for 1 out of 3 of the kinds > >> of changes made in these commits. > >> > >> Do you have an explanation for why you are removing comments in your > >> "cosmetic changes" commits? For example, the following two commits > >> remove comments that explain why 'propagated-inputs' are needed: > >> > >> https://git.sv.gnu.org/cgit/guix.git/commit/?id=c3264f9e100ad6aefe5216002b68f3bfdcf6be95 > >> https://git.sv.gnu.org/cgit/guix.git/commit/?id=416b1b9f56b514677660b56992cea1c78e00f519 > >> > >> What's your rationale for doing this? Am I the only one here who finds > >> this practice objectionable? It's not even mentioned in the commit logs. > > > > I think the comments are useful for non-trivial cases. In these > > definitions, the inputs were propagated because they were mentioned in > > .pc files. Propagation because of pkg-config is trivial. So I removed > > the comments. > ┌──┐ │ "So I removed the comments." │ └──┘ Raghav, I think you may not grok the social signalling of a statement like that :) It sounds like you are overlooking the _social_ need for consensus in modifying a shared environment. Taking a picture off the wall of a shared living room is different from taking the same picture off the wall in your private room. A git commit in a jointly developed FLOSS project is modifying a shared living room. (But do what you like in your own git repo ;-) The social aspect is not about the technical merits of of your changes, it's about the difference between joint ownership and private ownership, and the differences in exercising owner rights. > In the context of writing Guix packages, propagating the necessary > inputs to support other packages finding the library via pkg-config is a > serious thing, not trivial. If it breaks, dependent packages will likely > change in behaviour or stop building entirely. > > As for the comments, personally, I think the reasons behind propagated > inputs are individual enough and important enough to each package that > it's useful to write them down, even if that comment is "these things > are referenced by the .pc file". That way others looking at the package > definition don't have to wonder or try and dig through the Git history > to find information about what's going on. > > Anyway, I think the most useful output from this discussion is amending > or adding to the packaging guilelines to cover this: > > https://guix.gnu.org/manual/en/html_node/Packaging-Guidelines.html -- Regards, Bengt Richter
Re: Questionable "cosmetic changes" commits
Hi Ryan, Mark, et al, On +2020-12-02 20:13:56 +, Ryan Prior wrote: > Hi Mark! > > On December 2, 2020, Mark H Weaver wrote: > > We all have our own personal preferences of how best to indent scheme > > code, but if more of us adopted the habit of needlessly reordering > > fields and reindenting code of every package we touch, as one of us > > seems to have done, it could get out of hand quickly. > > I don't particularly hold any opinion about stylistic commits except > that I prefer tools like gofmt, Python's Black and standard.js which > enforce uniform code style, and would use such a tool for my Guile code > if it exists. Agree. As Tobias points out, it exists inside emacs. But I like small independent tools for specific things. Especially if they compose well. > > I do think it's important to acknowledge that the commits written by > Raghav were part of his internship and advised by his mentors who signed > off on the commits, so it's not like these changes were unsolicited and > materialized out of nowhere. I find myself with schizophrenic sympathies here :) On the one hand: 1. Don't make unnecessary work for me. 2. If it ain't broke, don't fix it. 3. Mother appreciates help in the kitchen, but don't touch the fine crystal! (Mother: "That's precious, from your great grandmother, only for special occasions. You know what cut glass crystal like that is worth?" Smarty Kid: "Buying or selling?" :) 4: At work, sign for janitorial services: DO NOT MOVE ANYTHING ON MY DESK!! (arrangement of untidy mess encodes part of my workflow state). On the other hand: 1. I habitually use emacs scheme-mode indenting as well as shell-script-mode, and find it a useful lens to reveal the meaning of the code, and my errors. 2. I prefer to read pretty-printed code, and wouldn't mind if all submitted code automatically were canonicalized in a well-defined way. I use emacs indenting because it is right there when I am editing. 3. NOT to canonicalize can obscure dumb errors, and that can be a smokescreen for worse. 4. For code, it is the abstract syntax tree that matters (in telling the machine what to do), not cosmetics, but cosmetics matter in making info human-sensible. In conclusion: 1. I want the best of all worlds, so I always like to pick a la carte, unless the Chef is three-flowers-plus, or I am budget-constrained. 2. I lean towards wanting a standard pretty-print canonicalization, if it doesn't make work for me ;) 3. diff has options to ignore white-space differences, etc., so I wonder what tools need what options to ease Mark's pain, (until everything is canonicalized, when that pain should disappear anyway). 4. Canonicalization should actually help make reviewing easier, and more effective, IWT. 5. I would like better factoring of functionality, so that e.g. I wouldn't have to start emacs (I know, some never leave :) to canonicalize a file the way scheme-mode does. Unix philosophy? (E.g., don't give cat a new built-in option like -nA, but realize how easily it could compose with a factored-out scheme-source canonicalizer. Some of you could probably write a bash script to use emacs as a filter, but is that a sensible way to go? Probably, if you are a fluent hacker and you need a tool in a hurry, but not for deciding separate and separable distribution components. (I think I got my nostalgic ideas of components from Meccano kit from the '40s ;) tl;DR: 1. I vote for running all code to be submitted through a standard pretty-printing canonicalizer. It could even inject TODO stubs for missing synopses, and doc strings (as an option :) -- Regards, Bengt Richter
Re: Releasing guix binary in Docker format too?
Hi, On +2020-11-17 17:38:09 +0100, Danny Milosavljevic wrote: > Hi, > > On Sun, 15 Nov 2020 19:30:44 +0100 > zimoun wrote: > > > $ docker exec guix guix pack hello > > user with UID 0 not found > > Docker needs to generate a /etc/passwd with uid 0 and the guix build user > accounts, and a /etc/group with the guixbuild group; and whatever other users > the things that are composed together using docker compose[1] require. How > does this work in Docker-land ? > How much would change if the guix daemon were implemented a little differently? E.g., (quoted from [1]), does the following mean that the guix daemon potentially could run "projects" instead of guixbuilder* to create "Multiple isolated environments on a single host" ? Is it suggestive to anyone else? --8<---cut here---start->8--- The features of Compose that make it effective are: Multiple isolated environments on a single host Preserve volume data when containers are created Only recreate containers that have changed Variables and moving a composition between environments Multiple isolated environments on a single host Compose uses a project name to isolate environments from each other. You can make use of this project name in several different contexts: on a dev host, to create multiple copies of a single environment, such as when you want to run a stable copy for each feature branch of a project on a CI server, to keep builds from interfering with each other, you can set the project name to a unique build number on a shared host or dev host, to prevent different projects, which may use the same service names, from interfering with each other The default project name is the basename of the project directory. You can set a custom project name by using the -p command line option or the COMPOSE_PROJECT_NAME environment variable. --8<---cut here---end--->8--- [...] > > The question is: since Docker supports composition[1], how do they handle > this standard case ? How can we get Docker to generate /etc/services, > /etc/passwd and /etc/group for the composed docker image ? > I guess this question would morph if guixbuilder* became "projects", where "you can set the project name to a unique build number". [...] > > [1] https://docs.docker.com/compose/ -- Regards, Bengt Richter
Re: Discoverability at the REPL level
Hi Simon, On +2020-11-15 14:02:04 +0100, zimoun wrote: > Dear, > > Preparing the online Guix Days, maybe this discussion is worth. It > echoes first with the talks “Guix compared to Nix” then with the recent > discussion about Emacs-Guix [1]. > > > The topic is discoverability at the REPL level. > > > Well, I have a proposal draft «“guix repl” and beyond» that I never > sent, where the ideas was to discuss ’~/.guile’ and how to extend Guix > ending with these questions: > > 1. Does Guix want a system of aliases? For example, let the script > “~/.config/guix/scripts/foo.scm“ and then ‘guix foo’. > > 2. How could the API be more discoverable? > I find this bash script useful: --8<---cut here---start->8--- #!/usr/bin/bash echo "from apropos:" guile <8--- Just name it, e.g., guap (for GU.ile AP.ropos :) chmod 755 guap then try e.g. guap string= --8<---cut here---start->8--- from apropos: (guile): string=# (guile): string=? # describe: - Scheme Procedure: string= s1 s2 [start1 [end1 [start2 [end2 Return `#f' if S1 and S2 are not equal, a true value otherwise. --8<---cut here---end--->8--- Have fun tailoring to suit yourself. Maybe some variations on restricting the apropos output better than my grep :) Or add some other ,xxx stuff or guile code to taste. Note that you can of course invoke guap from emacs like inserting the output of any bash command, as I did for the above snip (writing this in emacs as mutt's editor choice). > 3. Is the experimental ‘guix repl --gui’ reasonable? > > > The #1 popup’ed up in #38529 [2,3] and it is not related to > discoverablity but not orthogonal either. > > The #3 means open Guile-Studio or any other front-end and echoes the > recent discussion about GUI front-end [4]. > > > Therefore, here materials about the point #2. :-) > > > (The attentive reader is waiting for parametrized package PoC :-) and a > first discussion and arguments are this long thread [5].) > > > Feed back and ideas welcome. Especially about: > > There are probably several ways to address it, including the > unbound-variable hints and documentation. > > > All the best, > simon > > > 1: https://yhetil.org/guix-devel/87tuttci4z.fsf...@gnu.org > 2: https://yhetil.org/guix-bugs/87y2jie1aj@gmail.com/ > 3: http://issues.guix.gnu.org/issue/38529#60 > 4: > https://yhetil.org/guix-devel/caf-xjgsynm3kszum__f9dspuc0epj2qkdfwdftilhttumfa...@mail.gmail.com > 5: https://yhetil.org/guix-devel/87woitz1xx@gnu.org/ > [...] -- Regards, Bengt Richter
Re: Latest Nyxt features a GUI for Guix :)
Hi Pierre, On +2020-11-11 15:42:42 +0100, Pierre Neidhardt wrote: > Screenshots here: > > https://nyxt.atlas.engineer/article/release-2-pre-release-4.org > > -- > Pierre Neidhardt > https://ambrevar.xyz/ https://nyxt.atlas.engineer/article/release-2-pre-release-4.org --8<---cut here---start->8--- 502 Bad Gateway nginx/1.14.0 --8<---cut here---end--->8--- using --8<---cut here---start->8--- Mozilla Firefox 78.4.1esr --8<---cut here---end--->8--- on pureos, debian-based --8<---cut here---start->8--- 4.19.0-12-amd64 #1 SMP Debian 4.19.152-1 (2020-10-18) --8<---cut here---end--->8--- NBD, just thought you might like to know :) -- Regards, Bengt Richter
Re: RFC: subcommand to pause/resume builds
Hi all,
On +2020-11-03 14:53:07 +0100, Ludovic Courtès wrote:
> Hi,
>
> John Soo skribis:
>
> > I was looking to pause a long build today and asked on IRC how to
> > accomplish pause/resume. It seems this is possible already with the
> > following:
> >
> > kill --signal SIGSTOP|SIGCONT {pids-of-build-process-tree}
> >
> > There is already a command to list the processes associated to guix
> > commands: guix processes. Perhaps pause/resume can be a subcommand or
> > set of flags to guix processes. The following is the first thing that
> > comes to mind:
> >
> > guix processes --pause package-name ... --resume package-name ...
> >
> > What do you think?
>
> First, note that the daemon is unaware of “packages”, it only knows
> about “derivations”.
>
What if you turned the problem inside out, and made the derivation
volunteer to be paused (at sensible places in its progress)?
I.e., if you defined part of a given derivation
"hash-prefixed-derivation-file-name-in-question.drv"
to do a check for the existence of
/var/guix/daemon-ctl/hash-prefixed-derivation-file-name-in-question.drv.sfx
(.sfx appended to signify special effects :)
ISTM that could open the door for some easy hacks, (and probably some dangers
to watch for :)
E.g. a proof of concept might be just to sleep 6 seconds (say) and repeat
sleep/check
until the file disappears.
IWG this should not change anything for non-volunteering derivations other than
the load-relief
of not running the sleeping process(es).
Then the person wanting to pause the derivation
"hash-prefixed-derivation-file-name-in-question.drv"
could do so simply by
touch
/var/guix/daemon-ctl/hash-prefixed-derivation-file-name-in-question.drv.sfx
and deleting it when wanting to allow it to continue.
Later, if that works, .sfx files could have content, for as yet unimagined
purposes ;)
[...]
>
> Conclusion: I don’t think we can implement this reliably.
>
IDK from the outside, but inside-out, WDYT?
> HTH!
>
> Ludo’.
>
--
Regards,
Bengt Richter
Re: Hunspell dictionaries
2:REMOTE 2:RENEWED 2:RR 2:SA 2:SATA 2:SCHEME 2:SCM 2:SDL 2:SELECT 2:SGML 2:SLURM 2:SOCKS 2:SVN 2:SXML 2:TERMINAL 2:THANKS 2:TO 2:TYPE 2:UA 2:UMCUG 2:VIR 2: 3:AA 3:C 3:AMD 3:AR 3:CD 3:COMMIT 3:CRL 3:DC 3:DICT 3:DIR 3:EBB 3:EEC 3:ESP 3:EXPUNGE 3:GMP 3:GUILE 3:HTTPD 3:IDLE 3:IDMAP 3:INFOPATH 3:ISO 3:JP 3:LEVEL 3:LIST 3:LSH 3:LVM 3:MD 3:MIN 3:MPC 3:MPFR 3:NET 3:NIS 3:NIX 3:NTPD 3:OF 3:ON 3:OPTIONS 3:PDF 3:PM 3:RUNPATH 3:RYF 3:SOA 3:SSID 3:TOKEN 3:UD 3:UP 3:VT 3:XDG 3:XKB 3: 4:ASCII 4:ASDF 4:AUTHORS 4:CABB 4:CERTBOT 4:CFB 4:CPAN 4:DRBD 4:ECDSA 4:ELPA 4:EXAMPLE 4:FF 4:FTP 4:GB 4:GIT 4:GSSAPI 4:GUI 4:HDPI 4:HEAD 4:INFO 4:LMTP 4:LOAD 4:LOG 4:LTS 4:MANPATH 4:MUA 4:NNN 4:NS 4:OWNER 4:PACKAGES 4:PC 4:PHP 4:PREFIX 4:RET 4:RSA 4:SMTPD 4:SOURCE 4:TAB 4:TAP 4:TMPDIR 4:TUN 4:USE 4:VCL 4:VPS 4:XXX 4:ZSK 5: 5:ABCD 5:ALL 5:BUILD 5:CHECK 5:CN 5:COM 5:CTAN 5:DAEMON 5:DEBUG 5:ELF 5:ERROR 5:FILE 5:GPM 5:INBOX 5:KDE 5:KEY 5:MTA 5:NG 5:OOM 5:OPENPGP 5:OUTPUT 5:PR 5:RC 5:README 5:SC 5:SIGNING 5:SIGUSR 5:SOCKET 5:SRFI 5:SYSTEM 5:TESTS 5:TTY 5:VCS 5:XML 5:XMPP 6:ABI 6:BASE 6:CERT 6:CRAN 6:ENVIRONMENT 6:GID 6:IN 6:IPP 6:KSK 6:LUKS 6:OK 6:PCI 6:POP 6:RFC 6:TODO 6:USER 6:XYZ 7:FS 7:GPG 7:GSS 7:TRANSLATORS 7:VIRTIO 7:WM 7:WPA 8:ACCEPT 8:CHECKOUT 8:FIXME 8:GTK 8:KVM 8:PEM 8:PG 8:PL 8:SD 8:UDP 9:ALSA 9:CC 9:HTML 9:INPUT 9:MMC 9:SMTP 9:UEFI 9:UTF 9:WARNING 10:BIOS 10:DB 10:MATE 10:MB 10:MPD 10:NGINX 10:OC 10:SL 10:TLP 11:ARM 11:CGI 11:SDDM 11:TTL 11:UID 12:AC 12:ACL 12:GDB 12:IRC 12:RAID 13:US 14:DAG 14:DHCP 14:DVD 14:JSON 14:NTP 14:UNIX 15:EFI 15:GL 15:LOCPATH 15:PROFILE 15:PROFILES 15:RPC 16:SASL 17:PACKAGE 18:GDM 18:IMAP 18:SHA 19:CA 19:CONFIG 19:CVE 19:EXTRA 19:GC 19:SEL 20:VERSION 23:BAT 23:NSS 24:CUPS 26:PAM 27:CPU 27:RAM 27:SQL 27:UUID 28:OS 29:PGP 29:REPL 31:PID 31:TFTP 32:URI 33:GNOME 33:TCP 34:USB 34:VPN 35:API 35:LDAP 36:HTTPS 36:ID 36:QEMU 37:NFS 38:HOME 38:SERVER 40:VM 41:GCC 43:SSL 45:DNS 46:SUBSTITUTE 48:PATH 54:GRUB 61:HTTP 70:TLS 82:IP 90:GUIX 103:SSH 119:URL 454:GNU --8<---cut here---end--->8--- The numbers are the occurrence counts. GNU is the most popular :) HTH in some way. -- Regards, Bengt Richter
Re: A better way to access records.
Hi Brendan, On +2020-10-30 21:28:38 +1100, Brendan Tildesley wrote: > From the little bit of SICP that I've done, I recall watching the lectures > where > they put a mage hat on and talk about the power of names. One could perhaps > say > the most powerful tool in a programming language is the ability to give > something a name and then refer to those names. > > In guix/guile, record types are list of names given to some data. > For example: > > (define foo > (package > (name "bar") > (version "1.0") > ...) > > Here we the names foo, name, version, that refer to things of interest. We > can > call foo easily enough to get the record, but we cannot refer to name or > version so easily. We instead have to use accessors like (package-name > foo), > which requires us to write foo each time explicitly and have repeat package- > for each accessor. > In the guix codebase, on many occasions there appear things like this: > > (match-lambda > (($ agetty tty term baud-rate auto-login > login-program login-pause? eight-bits? no-reset? remote? > flow-control? > host no-issue? init-string no-clear? local-line extract-baud? > skip-login? no-newline? login-options chroot hangup? keep-baud? > timeout > detect-case? wait-cr? no-hints? no-hostname? long-hostname? > erase-characters kill-characters chdir delay nice extra-options) > (list > > > Here we have given some names to things, abandoned those names, and once > again > gone to the trouble of naming them again, in order, just for one local > environment. We'd have to do it again to make use of it elsewhere, and I > assume > they would have to change if the record type it self needed to be updated. > > Wouldn't be nice if we could just step inside a record type whenever we > pleased? > The above would be like this perhaps: > > (let-from-record-type > (list ...)) > > "let-from-record-type" i just made up since i dont know what it should be > called. Anyhow, it seems like we're stepping back a few centuries in > computer > science by needing to jump through these hoops. > > The list of symbols can be retreived with (record-type-fields > ), but I can't think of how one would write the above > syntax. > > Opinions? > > > info guile record may be useful :) -- Regards, Bengt Richter
Re: Using #true and #false everywhere?
Hi, On +2020-10-17 21:36:06 -0400, Maxim Cournoyer wrote: > Hello Tobias, > > Tobias Geerinckx-Rice writes: > > > Maxim, > > > > Maxim Cournoyer 写道： > >> I'd only agree to such a change if it's already been standardized in > >> the > >> RnRS as such > > > > Sure, I think that's implied. #true and #false are part of the > > R7RS-small standard. > > Thanks, I couldn't find where that was defined. Now that you've pointed > it to me, it's defined in section 6.3 Booleans: > >The standard boolean objects for true and false are written as #t and >#f. Alternatively, they can be written #true and #false, >respectively. > > > I don't know what Guile ‘is’, but it supports that part of the > > standard. I don't think it implements any of the RnRS completely? > > I've heard it said that Guile targets R5RS, but that was ages ago. > > info '(guile) Guile and Scheme' suggests it supports all of the R5RS, > R6RS or R7RS standards, plus a bunch of srfi modules. > > With this cleared, I don't have an objection to the proposal, other than > the other points I've mentioned earlier (to recall those points: I don't > perceive much value in it and it'll make the 'git blame' output noisy). > > Thanks, > > Maxim > I am against editing legacy code to s/#t/#true/ and s/#f/#false/ For those who need it, why not an emacs mode to view whatever beautification they like? Or a separate canonicalizer/prettyprinter filter that you could invoke by command line or from any editor that can pipe thhrough filters? ISTM any any editing of signed-off sources creates quality/security-control work for developers who are too valuable to waste their time on non-fun. Delegating such simple changes to newbie contributors doesn't avoid the oversight work and potential security risk: a "whoops, that better be reverted" may open a door just long enough for some exploitation -- or at least require the conscientious to think about whether the whoops really could have been exploitable somehow. I see a waste of developer time, that can be much better used. My 2¢ :) -- Regards, Bengt Richter
Re: emacs-lucid (was Re: Emacs closure at ~900MB?)
Hi Simon, On +2020-09-28 10:56:55 +0200, zimoun wrote: > Hi Pierre, > > On Sun, 27 Sep 2020 at 12:54, Pierre Neidhardt wrote: > > > Just tested, EXWM works with emacs-no-x-toolkit! > > Cool! > > > > So I suggest we add the following packages: > > > > --8<---cut here---start->8--- > > (define-public emacs-no-x-toolkit-xelb > >(package > > (inherit emacs-xelb) > > (name "emacs-no-x-toolkit-xelb") > > [...] > > > (define-public emacs-no-x-toolkit-exwm > >(package > > (inherit emacs-exwm) > > (name "emacs-no-x-toolkit-exwm") > > It appears to me more logical to name it: emacs-xelb-no-x-toolkit; > appending the variation last. > > > All the best, > simon > I am wondering if there is a pure-wayland-client version of emacs, as discussed here[1] A debian emacs-nox appears to exist [2] On my system, apt show emacs-nox tells me --8<---cut here---start->8--- Description: GNU Emacs editor (without GUI support) GNU Emacs is the extensible self-documenting text editor. This package contains a version of Emacs compiled without support for X, and provides only a text terminal interface. --8<---cut here---end--->8--- IIUC, wayland gets input events like keystrokes from the kernel and sends them by registered call-backs to the programs that thus registered interest. But I wonder how this connects with emacs and its use of pts/ptmx, readline, etc ... Is there a legacy layer of vt encoding/decoding that could be eliminated by a more direct use of wayland protocol? Perhaps such an emacs package could have a smaller closure, by depending as simply as possible on wayland (sans Xwayland)? If the low level stuff were wrapped nicely in some guile extension modules, I suspect other uses than emacs would be found. [1] https://emacs.stackexchange.com/questions/48561/is-there-an-x11-free-build-of-emacs-that-can-run-on-wayland-not-going-through-x [2] https://packages.debian.org/sid/emacs-nox -- Regards, Bengt Richter
Re: NixCon 2020
Hi Pancake, from your link, I get an html page, with a centered message: "File not found or corrupt" which firefox inspect-element says comes from --8<---cut here---start->8--- File not found or corrupt --8<---cut here---end--->8--- I'm not sure it was you but I saw a NixCon thing, maybe 2019?, where the presenter did not mention the role of guix substitutes provided by trusted servers, and in the Q/A time after did not appear to know fully how the guix derivation chains of events work in that regard. I think the audience may have been left with a less favorable impression of guix than it could have gotten. Hopefully you can improve on that :) On +2020-09-21 15:19:04 +, Buttery Pancake wrote: > I am planning to do a presentation for NixCon 2020, which will be on 16 and > 17 October. This will be a contrast between Guix and Nix. > > I have prepared a self-shot of my presentation, > https://share.riseup.net/#N9ggM6bRWviQCTro3_qerQ > > Please leave your feed-back. -- Regards, Bengt Richter
Re: File search progress: database review and question on triggers
Hi Hartmut, et al On +2020-08-15 14:47:12 +0200, Hartmut Goebel wrote: > Am 13.08.20 um 12:04 schrieb Pierre Neidhardt: > > SQLite pattern search queries are extremely fast (<0.1s) and cover all > > examples named so far: > > > > - exact basename match > > - partial path match > > - pattern match (e.g. "/include/%foo%") > > > For comparison: These are the options Debian Package search > <https://www.debian.org/distrib/packages.en#search_packages> supports: > > * paths ending with the keyword -> e.g. file-extensions > * packages that contain files named like this -> basename > * packages that contain files whose names contain the keyword -> > LIKE %% > If you are on debian, have you tried dpkg -l '*your*globbed*name*here*' or dpkg -l '*'|egrep your-regex-here or the former, preserving header and excluding non-installed, e.g.,? dpkg -l '*your*globbed*name*here*'|grep -v ^un > -- > Regards > Hartmut Goebel > > | Hartmut Goebel | h.goe...@crazy-compilers.com | > | www.crazy-compilers.com | compilers which you thought are impossible | > > -- Regards, Bengt Richter
Re: Linux-libre 5.8 and beyond
On +2020-08-09 18:17:48 -0400, Mark H Weaver wrote: > > Note that although base32 encodes 5 bits per character, the first > character of a base32-encoded sha256 hash can only be 0 or 1, since > there's only 1 bit remaining to encode after the other 255 bits have > been encoded in the last 51 characters. > UIAM, that's only true for the nix flavor (which is default for guix hash, I think) of base32. Again UIAM, the nix view of a 256-bit sha256sum hash is little-endian, and shifts 5 bits out the bottom, as if with euclidean/ 32, and so winds up with the 1 or 0 last, at the top. I think all the others base32's shift 5 bits at a time from the big end, and could have the full range 0-31 for the top digit, however translated to glyphs. Which also means the last value on the right is a 1 or 0 in the top bit, valued 16 or 0. Of course, different length digests may produce other remainder end values. BTW, how did nix get such a weird alphabet for 0-31 ? Watermarking themselves? :) -- Regards, Bengt Richter
Re: MPFR and MPC
Hi, On +2020-07-23 15:36:21 +0200, Andreas Enge wrote: > Hello, > > mpfr just had a new release 4.1.0: >https://ftp.gnu.org/pub/gnu/mpfr/ > and I am planning to make one for mpc as well. > > Should I follow some procedure for an update in Guix, or could I just push > two commits to core-updates? > > Andreas > > It would seem easy to forget that all readers may not know what MPFR and MPC (and other acronyms) mean, yet be curious enough to want to look them up ;-) To help such people, I think it would be great if "info guix acronyms" searched for and found a glossary section (e.g. 14.9 Acronyms ?) with an easy index that would also mostly succeed with e.g., "info guix|grep -iwC5 mpfr" (which BTW does find something to go on right now, but not a definition) >From info guix: --8<---cut here---start->8--- 14.4.4 Synopses and Descriptions [...] Descriptions should take between five and ten lines. Use full sentences, and avoid using acronyms without first introducing them. --8<---cut here---end--->8--- ISTM using this advice would be good for posting to the mailing list when meanings are not obvious from thread context. Otherwise acronyms come across a little like identity challenges, saying "if you don't know what that means, you don't belong in this meeting." (well, that might be true sometimes for meetings of specialists with urgent work to do, but not for inclusive public mailing lists :) -- Regards, Bengt Richter
Re: How to package inputrc
On +2020-07-13 00:01:32 +0200, Jonathan Brielmaier wrote: > Hi folks, > > an annoying thing for me in a default Guix installation is the lack of > an inputrc definition[0]. So while using the shell I miss going through > my bash history via "page up"/"page down" keys. > > To tackle this issue I created a simple inputrc and copied to > `/etc/inputrc`: > ``` What hat are you wearing? Admin or user as logged in, or user as user of a particular app, or? Of course, as owner of your machine, you may do as you please, if you can ;-) But IMO user preferences should stay out of the root directory, like /etc/... so I would put your mods in $HOME/.inputrc, as your ArchLinux referece [0] discusses, or maybe under ~/.emacs.d/ if it's just emacs you want to tweak. As you say, other distros provide defaults, but unless you want to modify everyone's experience who logs in on the machine, I would say stick to $HOME/.something, where something IMO should not be more global in effect than need be. Think twice about anything you need sudo to accomplish :) I think it is a kind of namespace hygiene problem, when it is not clear who gets to define names and what they do under what circumstances. My 2¢ ;-) > # alternate mappings for "page up" and "page down" to search the history > "\e[5~": history-search-backward > "\e[6~": history-search-forward > ``` > > In order to achieve this more elegant I could write a simple service to > copy the file to /etc. Another option would be a small package. > > I think other distros provide one in the default, basic installation: > ArchLinux[1], Debian[2] and openSUSE has even a longer one. > > Are others missing that too? What do you think? > > Good night > Jonathan > > [0] https://wiki.archlinux.org/index.php/Readline > [1] > https://git.archlinux.org/svntogit/packages.git/plain/trunk/inputrc?h=packages/readline > [2] https://packages.debian.org/buster/all/readline-common/filelist > -- Regards, Bengt Richter
Re: [Guix Website] A Search Page for Packages
Hi Daniela, On +2020-07-08 20:49:35 +0200, Daniela Lura wrote: > Hello everyone, > > This is Danjela, the Outreachy intern at the Guix Data Service. > > Taking into consideration the suggestion made in this thread: > https://lists.gnu.org/archive/html/guix-devel/2020-05/msg00096.html, my > mentor, Christopher Baines suggested me to write a script that serves a > search page for packages using the search functionality within the Guix > Data Service, > https://data.guix.gnu.org/repository/1/branch/master/latest-processed-revision/packages?search_query=git=version=synopsis_name=_results=100 > . > > The prototype page can be accessed through a test version of the Guix > website that Chris deployed: > http://guix-website-test.cbaines.net/packages/search > This looks useful :) I did notice that clicking firefox-esr's[1] reader-view button (or equivalently hitting Ctl-Alt-r [yes, lower case]) niether shows the latest search result (I searched for -"sha" (BTW, my convention: prefixed '-' on double-quoted string means without the quotes, ok?)). [1] Mozilla Firefox 68.10.0esr per -"firefox --version" It seemed to go back to a locked-in one-time-memoized value that persists through other searches and even exiting the browser and restarting it, and even after hitting its reload button. All it keeps showing in reader mode is --8<---cut here---start->8--- guix-website-test.cbaines.net Packages 1 minute ghc-cryptohash-sha1 0.11.100.1 This Haskell package provides an incremental and one-pass, pure API to the SHA-1 hash algorithm (https://en.wikipedia.org/wiki/SHA-1), including HMAC support (https://en.wikipedia.org/wiki/HMAC), with performance close to the fastest implementations available in other languages. The implementation is made… ghc-cryptohash-sha256 0.11.101.0 This Haskell package provides an incremental and one-pass, pure API to the SHA-256 cryptographic hash algorithm (https://en.wikipedia.org/wiki/SHA-2), with performance close to the fastest implementations available in other languages. The implementation is made in C… --8<---cut here---end--->8--- which I think is the result of my first search of all -- which was for -"sha256" (sans quotes again, no more explaining that :). Actually, on the reader page, there is visually a blank line above the -"ghc-cryptohash-sha256 0.11.101.0" line in the snip above, though I don't think that's relevant to not seeing a refreshed reader view of new search results -- unless it's actually a wl-copy/paste bug somehow. The latter has a man page, but no --version option, though debian's -"dpgk -l 'wl-*'" found it [Version: 1.0.0-1], in case it plays any role. On debian, -"apt show wl-clipboard" should tell the package details for you if needed. In my case it's re-packaged for pureos, so it'd be good to test reader view on other browsers and distributions. Anyway, raingloom got me thinking more about reader mode, and I think he would appreciate attention to that. I'll try to Cc: him :) > I'd like to know if you find the page useful so that I can hopefully start > working on incorporating the search functionality into this page: > https://guix.gnu.org/packages/. > > Best Regards, > Danjela HTH -- Regards, Bengt Richter
Re: GNU Shepherd 0.8.1 released
Hi Ludo, et al, Would there be a benefit from NOT using .sig's from mirrors while getting corresponding .tgz's from mirrors to help with traffic? On +2020-06-03 14:48:23 +0200, Ludovic Courtès wrote: > We are pleased to announce the GNU Shepherd version 0.8.1. This release > represents 16 commits by 4 people, bringing an important bug fix and > improvements to the code. [...] > • Download > > Here are the compressed sources and a GPG detached signature[*]: > https://ftp.gnu.org/gnu/shepherd/shepherd-0.8.1.tar.gz > https://ftp.gnu.org/gnu/shepherd/shepherd-0.8.1.tar.gz.sig > > Use a mirror for higher download bandwidth: > https://ftpmirror.gnu.org/shepherd/shepherd-0.8.1.tar.gz > https://ftpmirror.gnu.org/shepherd/shepherd-0.8.1.tar.gz.sig > > Here are the SHA1 and SHA256 checksums: > > 2964502388aa74207e6761c2ff77df69369738b0 shepherd-0.8.1.tar.gz > d32fe58694bb5350b5fc7285cf0ca0d9c7d24221aa5969d6c464ee3e3ac83f75 > shepherd-0.8.1.tar.gz > > [*] Use a .sig file to verify that the corresponding file (without the > .sig suffix) is intact. First, be sure to download both the .sig file > and the corresponding tarball. Then, run a command like this: > > gpg --verify shepherd-0.8.1.tar.gz.sig [...] I am wondering if downloading the .sig file from > https://ftp.gnu.org/gnu/shepherd/shepherd-0.8.1.tar.gz.sig (to make sure it is the latest official sig, even if mirrors haven't caught up) and the big file from a mirror: (to avoid overloading the official non-mirror server) > https://ftpmirror.gnu.org/shepherd/shepherd-0.8.1.tar.gz would be a good thing to do for server traffic, while ensuring that I would detect a stale tar.gz if it didn't correspond to the official .sig. Of course one would discover it if one used the sha256sums in the announcement, but could one be fooled by gpg's accepting a valid-as-pair tgz/sig pair where both were actually out of date? If so, could a class of errors and potential vulns be eliminated by not servings .sig's at all from mirrors? (it would be inconvenient when official server was down, but not a showstopper inconvenience, since the tgz would be be mirrored and could be validated with published sha256sum's). -- Regards, Bengt Richter
Re: Propose to distribute a user-only install script, not admin required
One thing I'd like to do is make this new guixurootd-install.sh stateful -- I'm thinking by logging passed and failed milestones to a source-able file like a bash_history with dates in comments so that re-tries don't waste my time (or internet budget). Lines like autoconf=1 # 2020-05-17 01:56:55 +0200 with the file initialized from a template with all steps =0 and including the template version and where to find it, with self-referential hash :) Still wip ;-) I'm wondering whether to make guixurootd support login or not. Or just rely on sudo -u (Maybe some special setuid helper will have to be created for privilege lowering? I haven't got that far yet. Maybe it could be done without any changing of privileges at all, with the guixurootd daemon and builderXX processes cooperating by message passing using that new extent-swapping kernel api that atomically (IIUC) swaps page-sequemces between files of cooperating users. That should be fast, since it's just like mmap table manipulation IIUC. So there's my 2 cents worth of bike shed paint :) Well, a little more, I hope. I'll be poking at it, but now will hope for ideas and prior art revelations here ;-) BTW, might encapsulating all of guix in the guixurootd $HOME file space serendipitously work with that systemd home encapsulator/migration- facilitator that I don't even know the right name of, possibly? -- Regards, Bengt Richter
Re: “guix --help” should point to https://guix.gnu.org/help/
Hi zimoun, et al, On +2020-05-15 13:00:58 +0200, zimoun wrote: > Hi Ricardo, > > On Fri, 15 May 2020 at 12:20, Ricardo Wurmus wrote: > > > annoyed by the fact that people turn to Reddit for help with Guix — a > > venue only very few of us frequent — I wondered if our help channels are > > visible enough. > > Maybe it is "cultural" or/and "generational" thing and we cannot do > really better. Maybe some people prefer channels as Reddit because > they are a bit "afraid" by email and/or IRC, especially maybe on > official channels. Maybe because when someone has a problem, the > first thing they does is a query to popular search engines and then Habits are habits, but I don't think people specifically needing guix info would go to popular search engines if they had an obvious better alternative. I suspect people e.g. go to https://duckduckgo.com/ and type "site:gnu.org some clues 2020" in the slot because it can be faster that way to get a good selection of URLS to choose from. I.e., faster than navigating from the top of http://www.gnu.org/gethelp/ (BTW wondering why the link is not https://www.gnu.org/software/gethelp.html which works fine). So, shame at having been outperformed in a search? Or an opportunity to extend the cooperative FLOSS ethos, and maybe contact duckduckgo.com so as to help them suceed well in helping us, and creating a mesh benefiting all? Likewise with Arch and Debian and other wikis or forums that can have useful search capability that it would be helpful for guix.gnu.org to point to. You may say that users usually know about their own distros' help sites, but sometimes it can help to know e.g. that a sibling debian descendant does not have the problem you are experiencing. > browse some Reddit-kind of channels, so maybe they feels like it is a > good entry point. Maybe some people appreciate the voting system > (upvote, Discourse, etc.) to be "rewarded". Etc.. > Good point, I definitely think some kind of rating system would help. Especially if tied into the search data base so that you can easily sift out information authored by people who typically post the final authoritative and correct "fixes" with nice succinct rationale :) > Well, I am not convinced it is an issue about visibility. :-( > Well, I am :) At least visible things are easier to find when you need them. Of course, in the dark, audible things may be easier to find, which may be very important to some. Of course, in a familiar room, touch may be sufficient to keep your mental model of the room in sync with reality, and to navigate through it. Touch is easy to overlook, but really important, whether typing, reading braille, playing an instrument, or just playing around :) So an accessible site map, to build that mental model that makes it a familiar room, is probably a good thing. > > > “guix --help” prints this: > > > > Report bugs to: bug-g...@gnu.org. > > GNU Guix home page: <https://guix.gnu.org> > > General help using GNU software: <http://www.gnu.org/gethelp/> Some people might not like to click on http[^s] and wonder why gnu is not practicing what it preaches, or suspect that their isp is playing surveillance middle man^H^H^Hperson^H^H^H^H^H^Hagent for some reason? I'll repeat from above: (BTW wondering why the link is not https://www.gnu.org/software/gethelp.html which works fine). > > > > I think it should explicitly point to https://guix.gnu.org/help/, maybe > > right before “General help using GNU software”. > +1 :) Also, I think it would be nice if there were a link from https://guix.gnu.org/help/ to a search page with some category checkboxes and radio buttons, so that you could get rapidly to the _kind_ of search you need or want. E.g., "[x] Troubleshooting" ought to be one check-box IMO, for me the most important :) I think with that checked searches should lead to info re recent regressions and "popular" troubleshooting topics, and notices of security issues and realease news. NOT 2017 bikeshed threads or fixes for problems of long-gone generations :) (unless of course they sadly are still dead-on relevant ;-/ ) Also, ISTM guix.gnu.org should not try to be the only source of information, but rather help people to get to other GNU-friendly sources of info that may have extra relevant info for their particular distribution and use case. Links for pursuing that would help. Sometimes going to duckduckgo.com and typing "site:gnu.org what you want" in the slot can get you useful urls faster than navigating down from https://guix.gnu.org/help/ I don't think there's any shame in suggesting that :) > Yes, it cost nothing and could improve. I think that's way too unassertive :) > > > All the best, > simon > -- Regards, Bengt Richter
Re: hide more output
Hi, On +2020-05-06 16:25:19 +0200, Ludovic Courtès wrote: > Hi, > > Ricardo Wurmus skribis: > > > While I’m sure many of us have gotten used to this I think we don’t need > > to show quite as much information. My proposal is to hide the > > “downloading from ” by default, because the URLs don’t > > really matter to users. We can unhide that bit of info when slightly > > higher verbosity is requested. > > I think it’s nice to see the URLs, or rather the host part thereof, when > using multiple substitute servers. But perhaps we can still make that > less verbose? > > Thoughts? > > Ludo’. > Just so I don't have to re-run something very timeconsuming to see the verbose version. IOW, if there isn't one, I think there ought to be a default detailed log produced (while teeing through optional verbosity/brevity filters or the user's grep. It might be nice to have an option to menumonic-tag-name the log for easier later access and review. -- Regards, Bengt Richter
Re: Guix System video review on YouTube
On +2020-04-28 02:32:39 +0200, raingloom wrote: > On Mon, 27 Apr 2020 12:11:05 +0200 > Jonathan Brielmaier wrote: > > > $ echo "hello" > > hello > > $ guix install emacs > > > > Then while installing emacs, try to reach the hello. It will be tricky > > as every new output line from `guix install emacs` will reset you to > > the bottom of your terminal. That's annoying. > > > > This is not related to the distribution, it's a terminal emulator > default. The behavior is the same in every other distribution I've used. > If they think this is a bad default, they should write on the > terminal emulator's bug tracker. > > But then again, you usually want new (possibly quite important) > messages to catch the user's attention, so I'd say it's a good default. > > Anyways, the option is trivial to change in the settings. You don't > even have to look too hard. > > > So I would propose an interface like: > > $ guix search vim > > | Name | Synopsis | Version | Outputs > > | > > +---++--+-+ > > | vim | Text editor based on vi| 8.2.0411 | out > > | | vim-airline | ... [...] > > Please don't, ASCII formatting always messes things up. Use the > terminal for text. If you want a more visual package manager, don't use To me it looks like he *is* using a terminal to get the above :) (or faking it from some re-purposed console cli sql output snippet?) > a CLI tool. A proper GUI will be more accessible. > By "proper" you mean browser-presented html/javascript ? ;-) > As one example, ASCII formatting makes screen readers a lot harder to > use. I don't think that has to be so :) > -- Regards, Bengt Richter
Re: 02/02: image: Disable compression for ISO images.
On +2020-04-27 18:00:05 +0200, Mathieu Othacehe wrote: > > Hey Tobias, > > > guix-comm...@gnu.org 写道： > >> + ;; XXX: Temporarily disable compression to speed-up the tests. > >> + (compression? #f))) > > > > Interesting! What kind of improvement do you see, roughly? > > I posted some figures here: > https://lists.gnu.org/archive/html/guix-devel/2020-04/msg00374.html. > > Here's a more complete summary: > > --8<---cut here---start->8--- > || Host (wip-disk-image) | VM (master) | > |+---+-| > | No compression | 4min | 12min | > | Compression| 8min | 19min | > --8<---cut here---end--->8--- > > > When I added zlib compression I was surprised to learn that here it made no > > significant difference in wall clock time (less than a minute; 5% or so) or > > CPU time. The disks they spin and CPU she is fast, but still I would have > > noticed a spike. > > Strange we have different results, those benches are not very accurate > though. Might it throw some light to see your different results for --8<---cut here---start->8--- $ lscpu|grep -i bogo $ top -n1|grep ^MiB --8<---cut here---end--->8--- At least I'm curious :) > > Thanks, > > Mathieu > -- Regards, Bengt Richter
Re: Guix System video review on YouTube
ss there's some FLOSS code in lsblk that could be re-used by guix. > It should be also used by "guix show" and we could even imagine by > "guix package -A". > > Well, as one said: patches welcome. :-) > > > > > $ zypper search vim | wc -l > > 84 > > $ guix package -A vim | wc -l > > 22 > > $ guix search vim | less > > 828 lines and you have to search again in less because you are overwhelmed > > I do not know 'zypper', only 'aptitude' of Debian. :-) > > And there is a big difference between "guix search" and such tools: > the relevance scoring. > Well, "guix search" does not sort alphanumerically by name but sort by > relevance depending on the query. > > The order is not predictable. Sometimes we want to order by relevance > (for discoverability), sometimes not. Therefore, it should be possible > to order by any keys than the relevance (using alphanumerical > ordering) > > > > So I would propose an interface like: > > $ guix search vim > > | Name | Synopsis | Version | Outputs | > > +---++--+-+ > > | vim | Text editor based on vi| 8.2.0411 | out | > > | vim-airline | ... > > [...] > > This is rather similar to debian dpkg -l '*vim*' output: (that's an ls '*vim*' kind of glob expr, BTW.) --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) ||/ Name Version Architecture Description +++-==---== un vim (no description available) un vim-athena (no description available) ii vim-common 2:8.1.0875-5 all Vi IMproved - Common files un vim-gnome(no description available) un vim-gtk (no description available) un vim-gtk3 (no description available) un vim-nox (no description available) ii vim-tiny 2:8.1.0875-5 amd64Vi IMproved - enhanced vi editor - compact version --8<---cut here---end--->8--- you can obviously grep ^ii to see what's installed only, or grep -v ^un to keep the headers with the ii's > > The the search command would fulfill it's function by giving you an > > overview about the available options. > > I agree as explained above. :-) > Room of improvements for "guix search". :-) > > > > >> * Multi user package concept not clear (root as different packages then > > >> normal user). > > > > > > This is related to expectation about "installed", IMHO. > > > > Yes. But can be confusing for all the people coming from traditional > > package managers where root and user share the same packages. > > Yes shifting is always difficult. :-) > > > Cheers, > simon > -- Regards, Bengt Richter
Re: hint: Run `guix search ... | less' to view all the results
q $pid -o ppid=) done --8<---cut here---end--->8--- [2] --8<---cut here---start->8--- pidparents ? 6727 Ss /usr/bin/bash /home/bokr/bin/pidparents emacs pts/0 6556 Sl+ emacs /home/bokr/.mutt/temp/mutt-LionPure-1000-4379-382192783617502847 sh pts/0 6555 S+ sh -c emacs '/home/bokr/.mutt/temp/mutt-LionPure-1000-4379-382192783617502847' muttpts/0 4379 S+ mutt bashpts/0 2822 Ss /bin/bash tilix ? 2817 Sl /usr/bin/tilix --gapplication-service systemd ? 1441 Ss /lib/systemd/systemd --user systemd ?1 Ss /sbin/init splash --8<---cut here---end--->8--- > > Thank you for your feedback. > > All the best, > simon > -- Regards, Bengt Richter
Re: 1.1.0 for HPC & reproducible research
On +2020-04-16 14:28:33 +0200, Ludovic Courtès wrote: > Hello! > > For the scientists & HPC folks among us, I’ve compiled a list of > relevant changes in 1.1.0: > > https://hpc.guix.info/blog/2020/04/hpc-reproducible-research-in-guix-1.1.0/ > > Ludo’. > Impressive! (Not to mention your personal productivity -- are you part 'bot? ;-) -- Regards, Bengt Richter
Re: GNU Guix 1.1.0 released
Hi Konrad, On +2020-04-16 14:27:39 +0200, Konrad Hinsen wrote: > On 15/04/2020 15:17, Ludovic Courtès wrote: > > We are pleased to announce the release of GNU Guix 1.1.0. > > The news has made it to a widely read IT news site in Germany (which I > didn't expect): > > > https://www.heise.de/developer/meldung/Linux-GNU-Guix-1-1-ist-auf-dem-Weg-zu-minimalistischem-Bootstrapping-4703451.html > That's a really nice site, but I couldn't find an english version. (IIRC, there used to be one that I would read a lot, but that was quite some time ago). The article was detailed and illustrated with many links -- kudos to the author. In contrast, my favorite place for linux news just did a quote with a link: https://lwn.net/Articles/817597/ (But it's early yet, we'll see). > > Thanks to all who made this happen! > Indeed! However, the significance of what's happening isn't registering with some readers (not limited to heise.de readers, or German), judging from these comments to the article: --8<---cut here---start->8--- GNU Guix ist ein funktionaler Paketmanager OK, mich würde jetzt mal ein Paketmanager interessieren, der nichtfunktional ist?! Kann der Artikelautor ein konkretes Beispiel nennen? --8<---cut here---end--->8--- If by "nichtfunktional" he really means concrete programming source syntax, I will confess to some sympathy, as when trying to grok a really gnarly gexp :) But then to syntax preferences no end there is ;) --8<---cut here---start->8--- Ich setze das Original ein: NixOS NixOS hat das Konzept der funktionalen Beschreibung eines (Linux-)Systems meines Wissens das erste Mal praktisch einsetzbar umgesetzt. Guix SD ist aus meiner Sicht einfach nur ein Klon. Mir ist das Original lieber. --8<---cut here---end--->8--- I am not familiar with NixOS, but I have the impression (CMIAW) that guix goes *much* further beyond any NixOS origins than that commenter believes. Anyway, guix is cool :) https://dict.tu-chemnitz.de/de-en/ (Nice dictionary to help my creaky German ;-) > > Cheers, > > Konrad > > -- Regards, Bengt Richter
Re: Hyperlinks!
Hi Ludo, On +2020-04-13 12:58:42 +0200, Ludovic Courtès wrote: > Hello Guix! > > Scheme code snippets in the on-line manual now have hyperlinks for all > the symbols documented in the manual: > > > https://guix.gnu.org/manual/devel/en/html_node/Using-the-Configuration-System.html > https://guix.gnu.org/manual/devel/en/html_node/Defining-Packages.html > > Hyperlinks are such an amazing invention! > > (If anyone knows how to get ‘a.syntax-symbol’ CSS different from just > ‘a’, I’m all ears!) > > This is happening in ‘doc/build.scm’ as a post-processing step on the > makeinfo-generated HTML (along with the syntax-highlighting > post-processing step). It works well but there can be false positives > because it matches on identifiers, without taking scope etc. into > account—e.g., anytime “service” appears, it’ll link to the ‘service’ > procedure. > > I’d like to extend it to include references to the Guile manual, so that > one could click on, say, ‘append’, but there might be too many false > positives at that point. And then we would need DrRacket fanciness to > be able to determine what an identifier really refers to… > > Feedback welcome! > > Ludo’. > I think it important to have a very up-to-date version of docs that can be downloaded like the single-page html doc alternatives usually offered on gnu.org, for off-line use, and not have it too dependent on secondary external links. (Or people might be tempted to wget [options intentionally absent ;-] to get more to read off-line ;-). Is https://guix.gnu.org/manual/en/guix.html in really good sync with https://git.savannah.gnu.org/gitweb/?p=guix.git;a=blob;f=doc/guix.texi;h=891e2693f66672fc309b510ee2a5a4d5dd737db0;hb=8c04471f2403f05bcbea740e3722030e2b8311ec (what's the easiest way to check? firefox page-info for https://guix.gnu.org/manual/en/guix.html says Modified: January 1, 1970, 1:00:01 AM GMT+1 ;-) I like being able to do a git pull to get an updated version of a project so I can trust it represents the latest official output from there. But I like to read about a new project before I download the whole thing. I prefer what I can believe is the latest official docs, not years-old web search results. So I'll look for a git repo that I can browse for docs, preferring nicely hyperlinked ones. I apppreciate not having to work to get tex or texi converted (as mostly happens with package installs), but what if I (or a non-guix-user) just want to have the latest docs without downloading the rest (or disturbing a current state), to read offline? I think for that, pre-built single-page html should be available, please :) If the latest is not easily available, people are likely to encounter guix on old review pages or by following links from old stuff to old stuff, and may conclude that guix is not even near ready for prime-time. I think up-to-date wikipedia links are important, as people may go there out of interest sparked elsewhere, to get up-to-date info on guix. Is updating wikipedia part of guix documentation work-flow? My 2¢ ;-) -- Regards, Bengt Richter
Re: good practices in science
Hi Konrad, > > So what makes you hopeful about guix? :) > > It's so technical that politics-minded people won't even look at it. LOL :)) -- Regards, Bengt Richter
Re: good practices in science
Hi Konrad, On +2020-04-06 17:09:14 +0200, Konrad Hinsen wrote: > Hi Pierre, > > > I had never heard about this project, looks like it's a most critical > > venture these days! :) > > > > https://underlay.mit.edu/ > > > > Any idea if there is a public project page? > > My understanding is that the project just started and hasn't much to > show for now. It's on my "have-a-look-every-three-months" list. > > The real question with this type of infrastructure project is if it will > produce something convincing enough for many players to adhere to. It's > as much politics as technology. That sounds sad. Maybe I got overexcited ;-/ (I guess I get excited reading prose that shows attention to the distinction between abstractions and their representations. Sort of like reading quotes from Plato, and thinking, "Hey, wow, I've had some of those thoughts." :) I hope they are not just preparing themselves for spinning off and becoming rich as a monopolist takeover target ;-/ Or that they're looking forward to being raided by offers of signing bonuses and a playground with expensive toys, just to keep their competition out of the market. Or that they'll be disrupted by metoo accusations. So what makes you hopeful about guix? :) > > Cheers, > Konrad > -- Regards, Bengt Richter
Re: good practices in science
On +2020-04-06 10:18:33 +0200, Pierre Neidhardt wrote: > Bijan writes: > > > I look forward to when the existing infrastuctures are further > > strained when we hopefully get open access papers (and other > > knowledge) distributed in a decentralised way eg on IPFS, if this were > > feasable, [I saw some ideas about this coming from the MIT 'underlay' > > project (basically a knowledge graph on ipfs)]. > > I had never heard about this project, looks like it's a most critical > venture these days! :) > I hadn't heard either, thanks! > https://underlay.mit.edu/ > > Any idea if there is a public project page? > > -- > Pierre Neidhardt > https://ambrevar.xyz/ Just chase the links, Luke ;-) (I used lynx -l to get the links for this) (from the above URL: --8<---cut here---start->8--- References in https://underlay.mit.edu/ 1. in Underlay - fn1 2. in Underlay - fn2 3. in Underlay - fn3 4. in Underlay - fn4 5. mailto:under...@media.mit.edu 6. in Underlay - fn5 7. http://kfg.mit.edu/ 8. mailto:under...@mit.edu 9. in Underlay - sup1 10. in Underlay - sup2 11. https://unstats.un.org/unsd/demographic-social/products/vitstats/sets/Series_A_2011.pdf 12. in Underlay - sup3 13. https://www.news24.com/World/News/Discontent-over-Sudan-census-20090521 14. in Underlay - sup4 15. in Underlay - sup5 16. https://www.cisco.com/ --8<---cut here---end--->8--- # 7. is http and forwards to https://www.knowledgefutures.org/ https://www.knowledgefutures.org/ gets you lots of goodness: --8<---cut here---start->8--- References in https://www.knowledgefutures.org/ 1. in Knowledge Futures Group 2. https://www.knowledgefutures.org/about 3. https://www.knowledgefutures.org/jobs 4. https://www.pubpub.org/ 5. https://www.underlay.org/ 6. https://commonplace.knowledgefutures.org/ 7. https://2019.knowledgefutures.org/ 8. https://twitter.com/kfutures 9. https://eepurl.com/gJzIjD 10. https://www.knowledgefutures.org/jobs --8<---cut here---end--->8--- ...of which #5 gets you --8<---cut here---start->8--- References in https://www.underlay.org/ Visible links: 1. in Underlay RSS Feed 2. in Underlay 3. in Underlay - main-content 4. https://www.underlay.org/search 5. https://www.underlay.org/login?redirect=/ 6. https://www.underlay.org/pub/tdefqg1q 7. https://eepurl.com/gJL39b 8. https://www.underlay.org/pub/tdefqg1q 9. https://www.underlay.org/pub/le752275 10. https://www.underlay.org/pub/future 11. mailto:consort...@underlay.org 12. https://www.knowledgefutures.org/ 13. in Underlay 14. in Underlay RSS Feed 15. https://www.underlay.org/legal 16. https://www.pubpub.org/ Hidden links: 17. https://www.underlay.org/project 18. https://www.underlay.org/protocol 19. https://www.underlay.org/underlay.org 20. mailto:consort...@underlay.org --8<---cut here---end--->8--- Don't miss the white paper! (link 10) ;-) Byline: by Danny Hillis, Samuel Klein, and Travis Rich The philosophy of the Underlay. (is that the Connection Machine Hillis?) Nor miss 12 and 16 Really exciting: Maybe idealism will go viral :) Though I'm pretty sure I'm not comfortable with script-kiddies [1] getting too easy access to knowledge they are not mature enough to handle ;-/ Amateur Jurassic Parks, anyone? Oops, that became a virus, not a tame T-Rex we can ride, what shall we do? [1] Not to mention Scrooge amd Dr.Strangelove ;-/ -- Regards, Bengt Richter
Re: 01/02: services: Allow modprobe to use "/etc/modprobe.d".
Hi Brice, Ludo,
On +2020-04-06 07:54:47 +, Brice Waegeneire wrote:
> Hello Ludo',
>
> On 2020-04-05 21:15, Ludovic Courtès wrote:
> > guix-comm...@gnu.org skribis:
> > >#~(begin
> > >(setenv "LINUX_MODULE_DIRECTORY"
> > > "/run/booted-system/kernel/lib/modules")
> > > + ;; FIXME: Remove this crutch when the patch
> > > #40422,
> > > + ;; updating to kmod 27 is merged.
> > > + (setenv "MODPROBE_OPTIONS"
> > > + "-C /etc/modprobe.d")
> >
> > [...]
> >
> > > + (services (cons* (service kernel-module-loader-service-type
> > > +'("ddcci" "ddcci_backlight"))
> > > + (simple-service 'ddcci-config etc-service-type
> > > + (list `("modprobe.d/ddcci.conf"
> > > + ,ddcci-config)))
> > > + %base-services))
> >
> > Looking at this, I was wondering if it would be possible to not use
> > /etc/modprobe.d and instead have a way to tell the modprobe wrapper to
> > pass “-C /gnu/store/…-modprobe.d”, which would contain the right thing.
> >
> > Thoughts?
>
> What's the issue with using /etc/modrpobe.d?
>
I would think the fundamental issue is pure vs impure dependencies:
i.e., /gnu/... vs /var/guix vs /elsewhere/...
IIUC, the consequence of using /etc/... or ~/... or other non-/gnu/...
is that if you want to run something in a container with chrooted root,
you have to cow-fake /etc and all the rest of non-/gnu/... environment,
so your executable is not as generally usable as possible if
nuisance adjustments were not necessary.
People who might want to use it anyway have to think about a bunch
of stuff not relevant to what they actually want to do -- they
will wind up debugging functionally-irrelevant implementation stuff.
Maybe I misunderstand, but are you and Ludo on the same page
re the fundamental concept of guix and how it plays in various contexts?
(allowing for "practicality beats purity"[1] when absolutely necessary ;-)
> As noted in the comments I thought setting MODPROBE_OPTIONS was kinda of a
> hack; #40422[0] was there to fix it. But if you think it's appropriate to
> use this environment variable it can be done in a future
> “kernel-module-configuration-service-type” we discussed with Danny[1].
> Instead of extending “etc-service-type” we would use
> “activation-service-type”, as “%modprobe-wrapper” is currently put
> in place by a simple activation service.
>
> [0]: https://issues.guix.info/issue/40422
> [1]: https://issues.guix.info/issue/40274#29
>
> - Brice
>
[1] python -c 'import this'
--
Regards,
Bengt Richter
Re: [BLOG] On migration to the Hurd
On +2020-04-01 23:39:29 +0200, Jan Nieuwenhuizen wrote: ^--[1] > Hello Guix! > > We are thrilled to have published a post about migrating to the Hurd: > > https://guix.gnu.org/blog/2020/deprecating-support-for-the-linux-kernel/ > > Thanks to the merge of ‘wip-hurd’ a few days ago and the awesome joint > work today of the Guix maintainers... read more > > Enjoy! [1] No April-fooling? ;-) > janneke, ludo, rekado, mbakke > > -- > Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org > Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com > -- Regards, Bengt Richter
Re: kmscon not working on MacBook
Hi,
On +2020-03-26 00:00:18 +0100, pelzflorian (Florian Pelz) wrote:
> On Fri, Mar 20, 2020 at 09:48:50AM +0100, pelzflorian (Florian Pelz) wrote:
> > I would
> > like something similar to be included in the next release. Maybe
> > kmscon works everywhere then.
>
> Of course the machines that need uvesafb to show the installer also
> later have problems showing Xorg. Maybe until Xorg on installed
> systems without Kernel Mode Setting works fine without manually
> fiddling with uvesafb or nonfree drivers, there is no use making the
> installer work.
>
> Perhaps uvesafb could somehow be made to work automatically, however
> on one of my computers uvesafb can only be used after „chmmod o+rw
> /dev/fb0“ which is a security issue, I suppose.
>
Are you a member of the video group?
What do you see typing
stat /dev/fb0
? Maybe something to try?
Or not relevant to your context?
>
> > ('nomodeset' is not needed; I leave it
> > in only for testing on computers where the graphical installer works
> > anyway when not passing 'nomodeset'.)
>
> In fact nomodeset was needed on a friend’s AMD GPU system. Probably
> one could blacklist yet another AMD graphics module instead of passing
> nomodeset. But then the installer on AMD systems where the module is
> working fine would be limited to uvesafb.
>
> Regards,
> Florian
>
--
Regards,
Bengt Richter
Re: February update on data.guix.gnu.org and the Guix Data Service
Hi Chris, On +2020-03-12 19:58:54 +, Christopher Baines wrote: ... > > 2. Are the http [sans 's'] links necessary? > > Do you mean why is HTTP being used and not HTTPS, or are you talking > about the links on the page themselves? Sorry, I meant "why is HTTP being used and not HTTPS". I've gotten the impression that it's a compromise having to do with making load balancing easier somehow, but that's my ignorant speculation, which any real factoid could improve on :) -- Regards, Bengt Richter
Re: February update on data.guix.gnu.org and the Guix Data Service
Hi, On +2020-03-12 14:21:51 +0100, Ludovic Courtès wrote: > Hi! > > Christopher Baines skribis: > > > Another update on the Guix Data Service, I sent out the last update on > > the 5th of January [1]. > > > > 1: https://lists.gnu.org/archive/html/guix-devel/2020-01/msg00073.html > > I hadn’t yet got around to reading this message. We really need > Guix Weekly News. :-) > +1 ;-) Quick comments: 1. Looks really nice :) 1a. I notice that inputs in http://data.guix.gnu.org/gnu/store/0hpz4039vs2n514kbd3psh5dwl0dnqwg-guix-1.0.1-11.f38eabe.drv/formatted seem to be sorted by leading hash. Might it be nice to have a button to sort starting past the hash? 1b. Q: other than for making list diffs show equality reliably, is the input ordering significant in terms of dependencies or process scheduling? 2. Are the http [sans 's'] links necessary? [...] > > Thanks for the great update, as always! > > Ludo’. > -- Regards, Bengt Richter
Re: should auto updaters be disabled?
Hi Leo, On +2020-02-28 14:47:27 -0500, Leo Famulari wrote: > On Fri, Feb 28, 2020 at 10:14:19PM +0530, Arun Isaac wrote: > > I agree that auto updaters should be disabled where applicable. But, > > ideally, like you said, this should be implemented upstream as a > > configuration option we can set at build time. > > I also agree we should make an effort to disable these features, because > they can confuse users about how to update software from Guix and also > don't offer the "binary -> source" transparency that makes Guix so > amazing. > > And I agree that it would be great if it was configurable in the > upstream source, but we could also patch it out ourselves if upstream is > not interested. > > For example, we build Syncthing with the '-no-upgrade' option which > disables auto-upgrade functionality at build time. OTTOMH reaction, offering a metaphor: IMO auto-update is like buying an appliance and giving the install crew a permanent key to the kitchen door. Would you do that in "real life" ?? (ok, who wouldn't like to live in a community where one can? :) (hm, perhaps you do, in the guix commit-privileged developer community at least :) Auto-update is handing binary patch commit privilege to an agent you chose to trust _one time_ to command your kitchen staff to do as told. No thanks, you tell me what you want them to do, and I will tell my staff/bash/readelf/etc to do it, iff I think it's ok (or my trusted security staff does). (my metaphorical "staff" of software servants -- nothing "real" ;-) I'd say an update's becoming available is an event. Maybe it could be queued for udev for configurable handling? But how to trap the event if it is arriving in an app's "ordinary" operating communications, e.g. as special packets in the streams used by an online game? BPF? Has someone developed a proposed standard/rfc for update notifications that differentiates between "you might enjoy our latest game enhancement" and a screaming "CVE-XXX: IMMEDIATELY DENY ALL, ALLOW ONLY ..." (with all the DOS threats and nuisances taken into account? Dreaming on .. but we have to dream things up before we can make them ;-) -- Regards, Bengt Richter
Re: 01/02: build: gnu-build-system: Don't run configure during bootstrap.
Hi Marius, On +2020-02-16 17:34:13 +0100, Marius Bakke wrote: > Bengt Richter writes: > > > Hi Efraim, > > > > On +2020-02-16 16:55:17 +0200, Efraim Flashner wrote: > >> On Sun, Feb 16, 2020 at 03:27:36PM +0100, Marius Bakke wrote: > >> > guix-comm...@gnu.org writes: > >> > > >> > > commit 481a0f1a7ceac666a011b28324220584ead07698 > >> > > Author: Efraim Flashner > >> > > AuthorDate: Thu Feb 13 10:54:29 2020 +0200 > >> > > > >> > > build: gnu-build-system: Don't run configure during bootstrap. > >> > > > >> > > * guix/build/gnu-build-system.scm (bootstrap): Add NOCONFIGURE > >> > > environment variable before running bootstrap scripts. > >> > > >> > [...] > >> > > >> > > @@ -190,6 +190,7 @@ working directory." > >> > >(if (executable-file? script) > >> > >(begin > >> > > (patch-shebang script) > >> > > +(setenv "NOCONFIGURE" "true") > >> > > (invoke script)) > >> > >(invoke "sh" script))) > >> > > (if (or (file-exists? "configure.ac") > >> > > >> > Should we unset NOCONFIGURE afterwards? Probably at least one package > >> > uses this variable for something completely different... > >> > >> It probably wouldn't hurt to unset it. I've never come across a package > >> where that's been a problem but best not invite trouble. > >> > > With all due respect, I am not comfortable with this kind of rationale :) > > > > If it's never been a problem, unsetting might hide a case where it _would_ > > cause a problem -- which IMO it would be better to find out about than not. > > I'm not sure I follow. The variable in question has only been used in a > handful of packages[0]. Now we are adding it in nearly 10k packages. > Yow, I sure didn't mean to suggest that! > Why would we want to know whether a package build process has a problem > with that particular variable? Debugging unexpected results? I was reacting to ┌───┐ │ > >> > Should we unset NOCONFIGURE afterwards? Probably at least one package │ │ > >> > uses this variable for something completely different... │ │ > >> │ │ > >> It probably wouldn't hurt to unset it. I've never come across a package │ │ > >> where that's been a problem but best not invite trouble. │ └───────┘ and wondering what kind of problem was anticipated if NOCONFIGURE were left set. So I thought, if you unset it, you will never discover that problem. Then I doubled down with the rest, to suggest forcing the ghost problem to show itself ;-) My motivation was to make any problem more easily debuggable rather than less, but it was about debugging, not standard operating procedure. > > [0] > https://git.savannah.gnu.org/cgit/guix.git/commit/?h=core-updates=778d6b522ae361767d3cf984a3b182bac7361b7a -- Regards, Bengt Richter
Re: 01/02: build: gnu-build-system: Don't run configure during bootstrap.
Hi Efraim, On +2020-02-16 16:55:17 +0200, Efraim Flashner wrote: > On Sun, Feb 16, 2020 at 03:27:36PM +0100, Marius Bakke wrote: > > guix-comm...@gnu.org writes: > > > > > commit 481a0f1a7ceac666a011b28324220584ead07698 > > > Author: Efraim Flashner > > > AuthorDate: Thu Feb 13 10:54:29 2020 +0200 > > > > > > build: gnu-build-system: Don't run configure during bootstrap. > > > > > > * guix/build/gnu-build-system.scm (bootstrap): Add NOCONFIGURE > > > environment variable before running bootstrap scripts. > > > > [...] > > > > > @@ -190,6 +190,7 @@ working directory." > > >(if (executable-file? script) > > >(begin > > > (patch-shebang script) > > > +(setenv "NOCONFIGURE" "true") > > > (invoke script)) > > >(invoke "sh" script))) > > > (if (or (file-exists? "configure.ac") > > > > Should we unset NOCONFIGURE afterwards? Probably at least one package > > uses this variable for something completely different... > > It probably wouldn't hurt to unset it. I've never come across a package > where that's been a problem but best not invite trouble. > With all due respect, I am not comfortable with this kind of rationale :) If it's never been a problem, unsetting might hide a case where it _would_ cause a problem -- which IMO it would be better to find out about than not. Is there an official policy regarding garbage/dangling environment variables? (Or is that just to be expected in the sargasso sea of "undefined behaviour"? ;-) So, if in doubt, instead of unsetting, perhaps set it something like "IF_YOU_SEE_THIS_PLEASE_REPORT_HOW_IT_HAPPENED_TO_efraim_AT_flashner.co.il" ;-P or make it throw an exception somehow, if following processing uses NOCONFIGURE any way at all before being replaced with a proper meaningful new value. > Also, looking at the snippet, I should move it higher up. If it's not > executable then NOCONFIGURE doesn't get set. > > > -- > Efraim Flashner אפרים פלשנר > GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 > Confidentiality cannot be guaranteed on emails sent or received unencrypted Hope I didn't offend anyone :) -- Regards, Bengt Richter
Re: [Proposal] The Formal Methods in GNU Guix Working Group
Hi Guix, On +2020-02-12 15:16:47 +0100, zimoun wrote: > Dear, > > On Wed, 12 Feb 2020 at 13:03, Orians, Jeremiah (DTMB) > wrote: > > > We also have a scheme bootstrappable from nothing written in C > > https://github.com/oriansj/mes-m2 > > https://github.com/oriansj/mescc-tools-seed > > The term "nothing" is mitigated; i.e. "nothing" means: a booted system > running a (linux) kernel. Right? > ISTR someone made an initrd with guile in it, and "booted to guile." If that is so, does that not suggest that "from nothing" could be independent of a running kernel? Wouldn't that be cool? !! ;-) > > Thank you for all your contributions! > e.g., hex0 is amazing! :-) > > All the best, > simon > -- Regards, Bengt Richter
Re: Testing the installer
Hello Gábor, On +2020-01-23 12:21:27 +0100, Gábor Boskovits wrote: [...] > This is a bit off topic, but I am about to create an automatic > installer, that is > a candidate for a new backend. It currently works by providing a configuration > record, and then executes a few things from the installer. > > (It does a lookup for a candidate installation target disk, autopartitions it, > then injects the bootloader and file-system fields into an operating-system > template, and finally does a system installation.) > Will your installer be able to create /boot and / images that will work with Coreboot/SeaBios/grub legacy-only (not UEFI) bootable systems (like PureOS)? IOW, what kind of BIOS systems is it dependent on? > I will have a look at the new protocol soon, to see if this project > can benefit from that. [...] > > Best regards, > g_bor > -- > OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21 > -- Regards, Bengt Richter
Re: Guix minor version update?
Hi, On +2020-01-21 12:43:26 -0500, Julien Lepiller wrote: > Le 21 janvier 2020 08:32:00 GMT-05:00, zimoun a > écrit : > >Dear, > > > >Currently, the proposed Guix to install is v1.0.1. This very version > >has some "bugs" [1] fixed since then [2]. But it is not convenient > >when using with Docker [3]. > > > >Why not update the minor version to v1.1? > > > >Then, I propose to update this minor version: > > - each time core-updates or staging is merged > > - each time the bootstrapping toolchain is updated > > - each time major archives (Bioconductor) is updated > > - each time CLI is improved (time-machine, etc.) > > > > > >Ludo "disagrees" [4], kind of. ;-) > ><< > >I guess semver doesn’t apply to Guix taken as a whole, so version > >numbers should be chosen to suggest how “different” the new release is. > >That’s pretty subjective, though. > >>> > > > >Let collect some ideas. :-) > > > > > >Even if version is not really meaningful when speaking about Guix > >because rolling etc. I find useful to bump the minor version more > >often, IMHO, for 3 reasons: > > > >1. Changing the (minor) version attracts interest and increases > >visibility. > > 2. It helps people --mainly HPC sysadmins-- to better trust "Guix > >rocks!" because jumping from version to version fits more what they > >know. > >3. It eases to navigate through all the packages and their version > >update. > > > > > >What people think? > > > >All the best, > >simon > > > > > >[1] https://lists.gnu.org/archive/html/guix-devel/2019-11/msg00540.html > >[2] > >https://git.savannah.gnu.org/cgit/guix.git/commit/?id=c20ba18304ee63f01895f092bb51bc2a9ce3303b > >[3] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=39195 > >[4] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=39195#25 > > I agree releases are too far apart, when we have all of these new things to > show off to newcomers :) > > Your proposed release cycle seems too short for me, especially since a > release is a huge drain on our resources (we try to freeze the distro, fix > packages, make sure we retain substitutes for that version "forever", …). > > We should definitely keep releases far from core-updates merges and co. That > would ensure we have time to fix the aftermath. > BF: How about generating a minimal "guix-maint" release as a binary-installable guix (guix-maint-install.sh ?) which would install a minimal /gnu/store like guix-install.sh if no existing /gnu/store, _but either way_ would install guix-maint as a new generation of guix-maint in its own profile. The idea is to be able to load a safe minimal and quality-controlled-up-to-date seed environment (mes-derived?) which can be invoked as a base for first-time install or later for maintenance or experimentation. Maybe it could be a safe-mode boot option from grub, to run as something selected from minimal profile alternatives? HTH trigger some useful ideas, even if this is ignorant newbie rambling :) -- Regards, Bengt Richter
Re: Inverted index to accelerate guix package search
t;guix show" the packages > "youtube-dl-gui" and "youtube-dl", you will see that the term > "youtube" (case-insentive) appears 5 times for youtube-dl-gui against > only 3 times for youtube-dl. Does the difference (5 vs 3) provide more > information? I do not think so... The issue is: 1. the description is > not well-written (for the current scoring system) and 2. the scoring > function is too simple. > > I have tried to described such issues/views here [3] [4] and since I > have not read so much about recommender systems: state-of-the-art, NLP > tools in Guile, etc. > > [3] https://lists.gnu.org/archive/html/guix-devel/2019-07/msg00252.html >From [3]: ┌┐ │ From my opinion, text mining or search engine strategies seem a better │ │ approach to improve the `guix search` than rigidify the filename tree. │ │ And some data mining to see how the packages cluster (depending on the │ │ metric) should be helpful to first understand how to improve `guix │ │ search`. │ │ I do not know if my words make sense. │ └┘ They make sense to me :) > [4] https://lists.gnu.org/archive/html/guix-devel/2019-12/msg00160.html More stuff, skimmed, but mostly LGTM. I would note that librarians have been helping people find relevant information for centuries, so IWT there is something to learn from them? Maybe not a Dewey Decimal System book classification for guix, but I am not sure it's good to exclude tagging ideas altogether. Another aspect of search is _who_ is doing the searching. A guix developer wanting to find implementation examples for bytecode jit is different from a newbie struggling to form an overview of what makes his app stutter. I note that papers and dissertations etc often contain prefatory paragraphs indicating intended audience, and noting parts that are only for specialists vs no-previous-knowledge-required. If synopses and such contained an audience hint in a standard syntax, might that serve as a basis for on-the-fly derivation of a search filter, maybe with a --audience guix-dev,specialist:guile:cps option? For object-oriented oops goops stuff, where you might like to find a collection of methods that might serve as mixin methods for an object of your own, how could you search for that? (think provides/ensures/requires or other type contraints ??) > > Last, I have not read the 2 links you pointed but I think you have a > bug in your code. The retrieval "game" using the index returns the > package "r-mgcv" which does not contain the term "game" in its > description. Well, the query "game" using the brute force does not > return this very package. > > Then, in the function > "guix/scripts/package.scm(find-packages-by-description)", you could > try to replace the `fold-packages' by something using the inverted > index. (Note that the name `find-packages-by-descripton' is odd > because it uses synopsis, name, etc. too.). > > > Hope that helps. > > Chhers, > simon > HTH in some way :) -- Regards, Bengt Richter
Re: Commit log for reverts
On +2020-01-04 23:19:52 +0100, Ludovic Courtès wrote: > Hola! > > guix-comm...@gnu.org skribis: > > > commit a06a4f918243dc784f9089d60690559b72a4e308 > > Author: Brett Gilio > > Date: Fri Jan 3 20:15:44 2020 -0600 > > > > Revert "gnu: Add swi-prolog." > > > > This reverts commit 3f37f3909712eb7269b6e8184c0d61bfc61b67f9. > > When reverting changes, I think we should always add a sentence possibly > with a link explaining the revert, to make it easier to those of us > reading guix-commits and to our future selves looking at the commit log > and wondering what was going on back then. :-) > > Thoughts? Wondering what log syntax might support writing a graph tool[1] that would produce a chart of commits and reversions with boxes of synopses connected by arrows. [1] With output options for utf8 console output as well as pdf, png, etc (via tex?) -- Regards, Bengt Richter
Re: FOSDEM + Guix Days approaching!
Hi Pjotr, (who kindly added me to the list of 40), This is to announce publically that my slot will be available, as I sadly will be unable to attend. I hope this is early enough that it will not go to waste. On +2020-01-03 12:10:54 +0100, Ludovic Courtès wrote: > Hello Guix! > > The Guix Days and FOSDEM are approaching! For FOSDEM, these are the > Guix talks I know of: > > • “Sharing Reproducible Results in a Container” (Efraim), > <https://fosdem.org/2020/schedule/event/reprod_container/> > > • “Towards reproducible Jupyter notebooks” (myself), > <https://fosdem.org/2020/schedule/event/reprod_jupyter_guix/> > > • “GNU Guix as an alternative to the Yocto Project” (Mathieu), > <https://fosdem.org/2020/schedule/event/ggaaattyp/> > > • “Universal package & service discovery with Guix” (Pierre), > <https://fosdem.org/2020/schedule/event/gnuguixpackagemanager/> > > • “Introduction to G-Expressions” (Chris Marusich), > <https://fosdem.org/2020/schedule/event/gexpressionsguile/> > > • “Lisp everywhere!” (Pjotr), > <https://fosdem.org/2020/schedule/event/lispeverywhere/> > > • “GNU Mes, Scheme-only bootstrap and beyond” (janneke), > <https://fosdem.org/2020/schedule/event/gnumes/> > > • “Guix: Unifying provisioning, deployment, and package management in > the age of containers” (myself): > <https://fosdem.org/2020/schedule/event/guix/> > > • “Celebrating Guile 2020” (Andy; not strictly Guix but noteworthy!), > <https://fosdem.org/2020/schedule/event/guile2020/> > > Woow, exciting program! Are there others I’m missing? > > Pjotr, Manolis: would you like to prepare a post similar to > <https://guix.gnu.org/blog/2019/meet-guix-at-fosdem-2019/> as Markdown > like > <https://git.savannah.gnu.org/cgit/guix/guix-artwork.git/tree/website/posts/meet-guix-at-fosdem-2019.md>? > If we publish it soon, that may give an opportunity to those who haven’t > made plans yet to join the Guix Days. See my top-post (sorry) snippet: my slot of the 40 is now available! > > Cheers, > Ludo’. This looks like such a great program, and I am really sorry to miss out ;-/ My main laptop is dying, effectively only runnable until the fan starts (noisily still, after a horrendous vibration while a powerful fan went like a stump chipper grinding at something. The internet says I am not alone). Plus it's showing signs (again) of battery swelling, and no warrany fix this time. So I have ordered a Purism librem13v4 which will come next week ;-) I hope to run guix on it, so if anyone else is running PureOS on a librem, I would appreciate any tips getting a robust setup going. Have fun a Guix-Days! -- Regards, Bengt Richter
Re: extending the documentation of the Scheme API
Hi Ricardo, Guix On +2019-12-20 23:17:41 +0100, Ricardo Wurmus wrote: > Hi Guix, > > we have lots of nice macros and procedures in Guix that aren’t > documented beyond their docstrings. > > Should we snarf the docstrings and add them to the manual? > > -- > Ricardo > > My 2 cents, if I may: I would _much_ rather be able to "snarf" dynamically from the command line to stdout or -o file using appropriate parameters and options. Even something dead simple like gx-apropos: --8<---cut here---start->8--- #!/usr/bin/bash guile -c '(use-modules (ice-9 session))(apropos '"\"$*\""')' --8<---cut here---end--->8--- quickly gets me syntax essentials for default modules. (I have to do another variant to get this apropos to see rnrs bytevectors or other non-default modules). Yet another variant uses oop goops describe. I can view a manual and search it in emacs, but even so, sometimes I'd rather insert the result of a command line invocation from within emacs. It only takes a few seconds to grep the whole guix git repo, a bit longer for /gnu. Speaking of the latter, here is an alpha kludge to do approximately what ArchLinux's pacman -Qo does (find what package a given executable belongs to). pacman -Qo $(which pacman) --8<---cut here---start->8--- /usr/bin/pacman is owned by pacman 5.2.1-1 --8<---cut here---end--->8--- my gx-Qo version (takes multiple args and shows pure vs not): gx-Qo g++ as readelf emacs lsblk less weston wayland gxQo --8<---cut here---start->8--- g++:gcc-9.1.0 as: binutils-2.32 readelf:binutils-2.32 emacs: emacs-26.3 lsblk: util-linux-2.34 less: less-530 weston: weston-6.0.1 wayland:(which: did not find) gx-Qo: (impure: '/home/bokr/bin/gx-Qo') --8<---cut here---end--->8--- When I get around to it I'll add a -a option to do which -a to report on all found. Also a -L option to report each link (possibly a chain) leading to to the executables. When/if I do, it will be an example of upgrading a single simple dynamic "documentation" producer vs upgrading a document per se. I much prefer dynamically on-the-fly-produced documentation of the state of my system -- like /proc stuff -- it's always up to date :) And emacs will let me escape with C-z to get to the command line when that is convenient (or necessary if pts doesn't do some tty thing). IMHO composing _independent_ functionalities ad-lib and powerfully is the best gift of the bash command line. ...|guix hash -|... allows me to use guix's internal default composition of sha256sum and base32, but bash can already get at the former and IMHO it would enhance general composability if guix's base32 were packaged as external to guix hash, so that bash could make use of the nix encoding also, that would be a plus for me e.g. maybe like ...|sha256sum|cut -d ' ' -f1|gx-base32|... It's a matter of what options you have to compose functionality. IMHO it would be good policy externalize hidden nuggets of shell-composable functionality whenever the nuggets don't need the package they come in to function. I think this should be viewed at the system architecture level so that the natural Chauvinism of an exciting project does not in effect create a walled garden that prohibits[1] cloning a simple (with simple system abi dependencies) internal wheel barrow for use at home. [1]I know "prohibits" does not apply to extracting nuggets from FOSS, but the effort can be prohibitive, where the original developers of the nugget could have made it easy in many cases :-/ HTH in some way :) -- Regards, Bengt Richter
Re: 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
Re: 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
Re: The Guix Days! (FOSDEM 2020)
Hi Pjotr, On +2019-12-10 06:43:51 -0600, Pjotr Prins wrote: > Dear all, > > FOSDEM is coming early February and not only are we organizing the GNU > Guix days, we also have a devroom with exciting talks on Guile, Guix, > and Mes! See > > https://libreplanet.org/wiki/Group:Guix/FOSDEM2020 > > and > > > https://fosdem.org/2020/schedule/track/minimalistic_experimental_and_emerging_languages/ > > FOSDEM is the greatest free software conference on earth (in my opinion) > and almost everyone who goes once keeps coming because there is > something for everyone. > > See last years amazing program for Saturday: > > https://archive.fosdem.org/2019/schedule/day/saturday/ > > Both FOSDEM and Guix days are free to attend! The evening program is > great too - you can find hacker nirvana. > > We can only receive up to 40 people for the Guix days (last year we > had 35) and we need to reserve the catering. So, please sign up on the > libreplanet link above, if you intend to come. If we happen to have > too many people to attend the meeting the 40 who signed up have a > guaranteed entry. If you don't want to subscribe to the wiki you can > send us a request to add. > > Pjotr & Manolis. > Thanks for the links! Looks super interesting, so I hope the minimalistic stuff especially is recorded for later streaming. I am going to try to come for the fringe plus FOSDEM, though logistics may be tight for me (what if I am forced to be no-show?) But if there is room for me in the 40, I would appreciate being added :) > n Fri, Feb 22, 2019 at 05:20:41PM +0100, Ricardo Wurmus wrote: > > Hi Guix, > > > > Chris Marusich kindly took the time to write a detailed report about a > > session from the Guix Days, and it’s now up on the Guix blog: > > > > https://www.gnu.org/software/guix/blog/2019/guix-days-bootstrapping-arm/ > > > > I don’t want to spoil it for you, so I encourage you to take a peek at > > it yourselves to read about challenges of the past, the present, and the > > future when it comes to bootstrapping ARM systems. > > > > Not only does the blog post explain the problems and technical fixes, > > but Chris takes a few steps back to look at the bigger picture and > > invites you to think big. > > > > Enjoy! > > > > -- > > Ricardo > > > > > -- Regards, Bengt Richter
Re: Feedback from JRES in Dijon
Hi Tim, Konrad, On +2019-12-07 23:11:19 -0500, Timothy Sample wrote: > Hi Bengt, > > I omitted a lot of your message, but I hope I have the easy explanation > you’re looking for. :) > > Bengt Richter writes: > > > On +2019-12-07 11:35:02 -0500, Timothy Sample wrote: > >> > >> [...] > >> > >> Unfortunately, I got certificate errors, but VLC lets you temporarily > >> ignore those. > > > > [...] > > > > Anyone see an easy explanation? > > After a little more digging, it seems that the certificate sent for > “ccwebcast.in2p3.fr” is signed with an intermediate certificate from > “TERENA”. This is in turn signed with a DigiCert root certificate. > Unfortunately it looks like “ccwebcast.in2p3.fr” doesn’t send the whole > certificate chain, and the TERENA cert is not part of our “nss-certs” > package, so tools using certs from that package (basically everything on > a normal Guix install) will be unwilling to trust “ccwebcast.in2p3.fr”. > IceCat is okay with it, but it uses its own certificates (it must know > about the TERENA cert, so it doesn’t need the whole chain). > > Fortunately, for exceptional situations like this, you can tell most > tools to skip certificate validation (like I mentioned with VLC). For > youtube-dl, you can use the “--no-check-certificate” option. Note > however that this is rather dangerous in general, since you are telling > youtube-dl allow anyone to pretend to be anyone else! In this case, > since it’s just a video and IceCat is okay with the certificate it’s > probably fine. Just be careful. :) > > > -- Tim Thank you very much for digging and providing the dangerous solution :) (I suppressed my paranoia this once, and it did work BTW :) BTW2, I have icecat installed, so I wonder if, given that it "uses its own certificates" (and knows about TEREMA) is there a cert-PATH that could be extended so other apps see icecat's cert info in addition to their own? BTW3, Konrad, That was a nice presentation -- are the tools you used to prepare it and present it available as libre packages? (I'm not insisting you answer ;-) -- Regards, Bengt Richter
Re: Feedback from JRES in Dijon
emss with /etc/hosts ... Will try that, just to add a data point :) Nope, doesn't seem to change anything ;-/ --8<---cut here---start->8--- $ wget $(stack) --2019-12-07 18:21:22-- https://ccwebcast.in2p3.fr/vod/_definst_/mp4:media/5c/e6/5ce6537209640/5ce6537209640.mp4/manifest.mpd Loaded CA certificate '/etc/ssl/certs/ca-certificates.crt' Resolving ccwebcast.in2p3.fr (ccwebcast.in2p3.fr)... 134.158.69.183 Connecting to ccwebcast.in2p3.fr (ccwebcast.in2p3.fr)|134.158.69.183|:443... connected. ERROR: The certificate of ?ccwebcast.in2p3.fr? is not trusted. ERROR: The certificate of ?ccwebcast.in2p3.fr? doesn't have a known issuer. $ echo wget $(stack) wget https://ccwebcast.in2p3.fr/vod/_definst_/mp4:media/5c/e6/5ce6537209640/5ce6537209640.mp4/manifest.mpd --8<---cut here---end--->8--- --8<---cut here---start->8--- $ youtube-dl $(stack) [generic] manifest: Requesting header WARNING: Could not send HEAD request to https://ccwebcast.in2p3.fr/vod/_definst_/mp4:media/5c/e6/5ce6537209640/5ce6537209640.mp4/manifest.mpd: [generic] manifest: Downloading webpage ERROR: Unable to download webpage: (caused by URLError(SSLCertVerificationError(1, '[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c: 1108)'))) --8<---cut here---end--->8--- Anyone see an easy explanation? TIA -- Regards, Bengt Richter
