Re: Autotools-generated 'configure' & 'Makefile.in' considered binaries?
Hi Ludo, April 1, 2022 11:01 AM, "Ludovic Courtès" wrote: > > This is conceptually the “right thing”, but it raises a significant > bootstrapping problem. Our bootstrap path currently focuses on being > able to run shell scripts, in particular ‘configure’ scripts, before we > can even build Bash, thanks to Gash and Gash-Utils. If we were to build > the autotools machinery systematically, we’d need Gash-Utils to provide > a Perl and an M4 implementation. (Now, Timothy has written an Awk > interpreter, so a Perl interpreter can’t be so hard, right? :-)) > The other option is to write an Autoconf and Automake implementation… > A huge Awk fan, have you got a reference for Timothy's interpreter? > As a first milestone, maybe we could start running ‘autoreconf’ more > often, for packages higher in the graph. We could change the > ‘bootstrap’ build phase to do that unless it’s explicitly turned off. > It may turn out to be a Sisyphean task though… > > Thoughts? > > Ludo’. Jonathan McHugh indieterminacy@libre.brussels
Re: New review checklist
There is no reference to XML. Nor does it provide any interopabilietie with SOAP. Please stop wasting the mailinglists time with this non XML based hokum, this is Guxi.FFSaek. :) Jonathan McHugh indieterminacy@libre.brussels April 1, 2022 6:15 AM, "Liliana Marie Prikler" wrote: > Dear reviewer, > > in the sequel find the new review checklist, effective immediately. > Failure to apply it will result in the confiscation of your machine for > the purpose of making it usable for continuous integration. > > Happy April Fools > > - > > So you want to package a > [ ] C [ ] C++ [ ] C# [ ] Common Lisp [ ] Emacs Lisp [ ] Fortran > [ ] Guile [ ] Haskell [ ] Java [ ] Javascript [ ] Julia [ ] Nim > [ ] OCaml [ ] Python [ ] R [ ] Rust [ ] V [ ] Zig [ ] > application/library/. > It won't be added to Guix. Here's why it won't. > > You appear to believe that > [ ] linter warnings can easily be ignored > [ ] `make check' does not need to succeed > [ ] nobody will ever want to build your package on > [ ] x86_64 [ ] i686 [ ] aarch64 [ ] armhf [ ] mips > [ ] powerpc [ ] riscv__ [ ] __-mingw32 [ ] the Hurd > [ ] commit hashes make for good version numbers > [ ] hard-coding the commit field is a good idea > [ ] using trivial-build system is a good idea > [ ] we hard-code > [ ] invocations of command line tools > [ ] shared libraries > [ ] _ > for fun > [ ] updating __ to add your package does not cause a world rebuild > [ ] committers have nothing better to do than trailing a branch that > receives _ commits per day. > > Sadly your patch has/lacks > [ ] copyright headers > [ ] changes in other parts of the file > [ ] indentation > [ ] speling misstakes > [ ] new-style inputs > [ ] propagated inputs > [ ] a useful synopsis > [ ] a meaningful description > [ ] a valid home-page > [ ] correct licensing information > [ ] significant improvements over the three other patches adding this > package, which themselves are stuck in review hell > > The following technophilosophical objections also apply: > [ ] the GNU FSDG prohibit _ > [ ] your package bundles a meaningless copy of > [ ] ffmpeg > [ ] v8 > [ ] font-awesome > [ ] bundler > [ ] rustc > [ ] > [ ] your package bootstraps itself using a sparse autoencoder trained > on /dev/urandom > [ ] your package is not reproducible thanks to > [ ] embedded timestamps > [ ] CPU feature detection during configure/compile time > [ ] a flaky test suite > [ ] an evil hack to call rand() inside a constexpr context > [ ] Guix should not have to carry every fork of suckmore tools > > In conclusion, this is what I think of you: > [ ] Your patch looks good, but I'm not going to push it. > [ ] Your patch would need some work, and I'm not going to invest that > time on your behalf. > [ ] Your patch is bad and you should feel bad for submitting it. > [ ] Maintaining this package in your own channel is an adequate > punishment for writing it.
Re: Profiling of man-db database generation with zlib vs zstd
Hi Maxim, Out of interest, will a zstd dictionary be (eventually) utilised as a strategy for further reducing compression and decompression speeds? ``` The compression library Zstandard (also known as "Zstd") has the ability to create an external "dictionary" from a set of training files which can be used to more efficiently (in terms of compression and decompression speed and also in terms of compression ratio) compress files of the same type as the training files. For example, if a dictionary is "trained" on an example set of email messages, anyone with access to the dictionary will be able to more efficiently compress another email file. The trick is that the commonalities are kept in the dictionary file, and, therefore, anyone wishing to decompress the email must have already had that same dictionary sent to them.[2] ``` http://fileformats.archiveteam.org/wiki/Zstandard_dictionary I appreciate it may confuse your piecemeal benchmarking (certainly at this stage) but I would assume that creating a dictionary (or dictionaries, say covering each Guix package category for linguistic overlaps) for manpages would further improve zstd speeds. HTH, ==== Jonathan McHugh indieterminacy@libre.brussels March 30, 2022 4:49 PM, "Maxim Cournoyer" wrote: > Hi Ludovic, > > Ludovic Courtès writes: > > [...] > >> To isolate the problem, you could allocate the 4 MiB buffer outside of >> the loop and use ‘get-bytevector-n!’, and also remove code that writes >> to ‘output’. > > I've adjusted the benchmark like so: > > --8<---cut here---start->8--- > (use-modules (ice-9 binary-ports) > (ice-9 match) > (rnrs bytevectors) > (zstd)) > > (define MiB (expt 2 20)) > (define block-size (* 4 MiB)) > (define bv (make-bytevector block-size)) > (define input-file "/tmp/chromium-98.0.4758.102.tar.zst") > > (define (run) > (call-with-input-file input-file > (lambda (port) > (call-with-zstd-input-port port > (lambda (input) > (while (not (eof-object? > (get-bytevector-n! input bv 0 block-size) > > (run) > --8<---cut here---end--->8--- > > It now runs much faster: > > --8<---cut here---start->8--- > $ time+ zstd -cdk /tmp/chromium-98.0.4758.102.tar.zst > /dev/null > cpu: 98%, mem: 10560 KiB, wall: 0:09.56, sys: 0.37, usr: 9.06 > --8<---cut here---end--->8--- > > --8<---cut here---start->8--- > $ time+ guile ~/src/guile-zstd/benchmark.scm > cpu: 100%, mem: 25152 KiB, wall: 0:11.69, sys: 0.38, usr: 11.30 > --8<---cut here---end--->8--- > > So guile-zstd was about 20% slower, not too far. > > For completeness, here's the same benchmark adjusted for guile-zlib: > > --8<---cut here---start->8--- > (use-modules (ice-9 binary-ports) > (ice-9 match) > (rnrs bytevectors) > (zlib)) > > (define MiB (expt 2 20)) > (define block-size (* 4 MiB)) > (define bv (make-bytevector block-size)) > (define input-file "/tmp/chromium-98.0.4758.102.tar.gz") > > (define (run) > (call-with-input-file input-file > (lambda (port) > (call-with-gzip-input-port port > (lambda (input) > (while (not (eof-object? > (get-bytevector-n! input bv 0 block-size) > > (run) > --8<---cut here---end--->8--- > > --8<---cut here---start->8--- > $ time+ guile ~/src/guile-zstd/benchmark-zlib.scm > cpu: 86%, mem: 14552 KiB, wall: 0:23.50, sys: 1.09, usr: 19.15 > --8<---cut here---end--->8--- > > --8<---cut here---start->8--- > $ time+ gunzip -ck /tmp/chromium-98.0.4758.102.tar.gz > /dev/null > cpu: 98%, mem: 2304 KiB, wall: 0:35.99, sys: 0.60, usr: 34.99 > --8<---cut here---end--->8--- > > Surprisingly, here guile-zlib appears to be faster than the 'gunzip' > command; guile-zstd is about twice as fast to decompress this 4 GiB > something archive (compressed with zstd at level 19). > > So, it seems the foundation we're building on is sane after all. This > suggests that compression is not the bottleneck when generating the man > pages database, probably because it only needs to read the first few > bytes of each compressed manpage to gather the information it needs, and > that the rest is more expensive compared to that (such as > string-tokenize'ing the lines read to parse the data). > > To be continued... > > Thanks! > > Maxim
Re: Fetching sources using Guix (re: Building a software toolchain that works)
Hi Ryan, March 19, 2022 1:08 AM, "Ryan Prior" wrote: > One of the side-threads in "Building a software toolchain that works" was > essentially this: > > If I fetch sources for a package using Guix, with the intention to make > changes and then build and > test the software myself, what should we do with any patches & snippets that > are part of the Guix > package? > > There does not seem to be an obvious right answer. One reason is that patches > and snippets fall > into at least a few use cases: > > * The upstream package won't build at all as-is using the environment Guix > creates, so we apply a > patch to enable a successful build. > * Upstream vendors some sources into their package, which we prefer to excise > using a snippet so > that we can do our own dependency management > * Upstream includes non-free components, which we remove to build a fully > free package > * Upstream includes binaries in their package, which we prefer to snippet out > so we can build them > ourselves > > At present we don't include any semantic information with each patch or > snippet to explain why it > is needed. Many have helpful comments; some don't. > > Would it be feasible or desirable to create a set of "reason" symbols, > similar to our "licenses," > and attach a reason (or unknown?) to each snippet and patch? Then we can > expose meaningful data to > the end-user about patches & snippets that are available, enabling an > informed choice about whether > to apply them when fetching sources. > I suspect the use of 'reason' symbols huge and potentially with large governance ramifications (such as aligning definitions or enforcing behaviour). FWIW, Ive expermimented heavily with symbols extensively for years - with Qiuy (what I refer to as a recursive-modelling-language). For example, here is a list of tokens that exist within HOME folder directories: https://git.sr.ht/~indieterminacy/2q60mqm_qiuy/tree/main/item/ueu-nen/iwi_2022-03-09 These tokens appear everywhere and Im using them as elemental forces to fascilitate knowledge-management at my end. Of course, Guix is welcome to come up with its own symbols to highlight desire and state. It probably needs some deep reflection about needs to be effective. > This could also be useful in our own record-keeping, so that we can track the > usage of patches and > snippets for different reasons. It would be nice, for example, to see a > downward trend in the > number of patches for build systems that won't work at all without them, > either because we improve > the logic in our build steps or because we contribute changes upstream to > make software easier to > build. Jonathan McHugh indieterminacy@libre.brussels
Re: Guix as a system vs as an end-user dev tool (re: Building a software toolchain that works)
Hi Ryan, Perhaps Im being cynical but opening the doorway to lots of plug-and-play users atm could overwhelm the people heroically stabilising and smoothing out the OS. Jonathan March 19, 2022 1:21 AM, "Ryan Prior" mailto:rpr...@protonmail.com?to=%22Ryan%20Prior%22%20)> wrote: One side-thread in "Building a software toolchain that works" notes that Guix faces challenges for adoption because it's not readily available to users of proprietary operating systems like macOS and Windows.I've witnessed over the past decade that GNU/Linux development on other platforms has become widespread, in large part due to the availability of the Docker for Desktop application which packages a lightweight, automagically managed GNU/Linux virtual machine running the Docker daemon with Docker client software built for the target platform.A user of Docker for Desktop on a proprietary OS can run "docker" commands which transparently execute commands inside a GNU/Linux container, making building and testing software quite convenient and reproducible without needing to set up cross-compile toolchains or spend time managing VM software.It makes absolute sense to me that Guix is not interested in building a native distribution for the Windows or macOS toolchains. One of Guix System's unique strengths is its adherence to the GNU FSDG and I don't think that's incompatible with making the Guix tools more generally available to end-user devs hacking on software using a proprietary OS.Technically, I think we could use a similar approach to the Docker for Desktop system: a "Guix for Desktop" installs software to create and manage a minimal Guix System virtual machine which automatically updates and reconfigures itself, requiring no manual administration by the end-user. And it would install a Guix client that connects to the Guix daemon running in the VM using a shared socket, enabling users to incorporate Guix transparently into their workflows.I think this would be a compromise for certain, the same way it is for Emacs and other GNU flagship projects that run on non-free systems. On the one hand, it serves to make those systems more valuable, which undermines our cause. But on the other hand it provides a major on-ramp to free software and superior build tooling, positively impacting the practical freedoms available to the end-users who adopt Guix.wdyt?
Re: Update CoC adapted from upstream 2.1 (instead of 1.4)
February 25, 2022 8:48 AM, "Tissevert" wrote: > Are dickpics going to be necessary to sign commits from now on ? Well, we cant be mandating binary commits now can we?!? This is Guix FFS. Cmon, if I wanted to be perusing dicks and commits Id be on other mailing lists. Lets move on. Please. Jonathan
Re: [minor patch] Amend CoC
Hi Liliana, [dropping ML CC for this reply as its offtopic re Guix] Thanks for the clarification. Living in Belgium, this advert for bars/cafes always wrankles me: ``` cherche serveuse ``` It may be that Im missing some linguistic touches but I dont know why such gender inference is legal. The francophone language doesnt fit in my head very well - my brain cant handle all these gender registers for every (effing) noun: * Pencil - probably a male? * Coffee - definately a male? * large coffee - probably the same as a regular coffee? * Tablecloth - male? * Spacestation - ...female? Its farcical, and weird that we tollerate gender specific nouns to be codified writ large across society. Personally, Im getting better at using gender neutral nouns in English given this growing frustration. It takes time to undo such legacy habits but I consider that people should actively control language and alter it with greater autonomy. Also, Im happy that Belgian laws allow for giving children both parents' surnames (which I did for mine), as well as establishing that wives should not have to lose their surname (almost wrote maidenname, g). Dont get me started on weeklong knights and princesses themes at my childrens' school. My son picked up a lot of chauvanism very quickly from the 'institution'. Thanks all for an interesting thread, I appreciate your perspectives re trying to make people feel more confident in their own skin. Jonathan February 20, 2022 10:12 PM, "Liliana Marie Prikler" wrote: > Salut Jonathan, > > Am Sonntag, dem 20.02.2022 um 20:56 +0000 schrieb Jonathan McHugh: > >> Hi Liliana, >> >> February 20, 2022 8:37 PM, "Liliana Marie Prikler" >> wrote: >> Am Sonntag, dem 20.02.2022 um 19:45 +0100 schrieb Maxime Devos: >> >>> >>> To me, this seems a rather contrived scenario though ... >> >> In this "contrived" scenario Harold would still (intentionally or >> otherwise) be discriminating Victor·ia over their gender by >> publicly pointing out the disconnect between the two. In the daily >> experience of trans people, such remarks typically serve to >> invalidate their identities. >> >> I notice the use of an an interpunct with your typing for Victor·ia. >> >> Ive never noticed such a puncuation previously. >> >> Is it a common typographic device for such instances of >> identification? >> It seems a beautiful technique for providing subtle signalling for >> what can (unfortunately) be a sensitive area for communication. > > Wikipedia has the following to say: "In modern French, the interpunct > is sometimes used for gender-neutral writing, as in « les salarié·e·s » > for « les salariés et les salariées » [1]." I personally picked it up > after someone mentioned it in the IRC. > > More generally speaking, there are few conventions that are really > widely agreed upon. In my own country, there's at least three > competing standards, so obviously borrowing from the French and > introducing a fourth is the only right solution. > > Bisous > > [1] https://en.wikipedia.org/wiki/Interpunct#French
Re: [minor patch] Amend CoC
Hi Liliana, February 20, 2022 8:37 PM, "Liliana Marie Prikler" wrote: > Am Sonntag, dem 20.02.2022 um 19:45 +0100 schrieb Maxime Devos: >> >> To me, this seems a rather contrived scenario though ... > > In this "contrived" scenario Harold would still (intentionally or > otherwise) be discriminating Victor·ia over their gender by publicly > pointing out the disconnect between the two. In the daily experience > of trans people, such remarks typically serve to invalidate their > identities. I notice the use of an an interpunct with your typing for Victor·ia. Ive never noticed such a puncuation previously. Is it a common typographic device for such instances of identification? It seems a beautiful technique for providing subtle signalling for what can (unfortunately) be a sensitive area for communication. Jonathan McHugh indieterminacy@libre.brussels
Re: Excessively energy-consuming software considered malware?
Hello Maxime, February 20, 2022 1:37 PM, "Maxime Devos" wrote: > > More concretely, the p2pool description is: > > ‘Monero P2Pool is a peer-to-peer Monero mining pool. P2Pool > combines the advantages of pool and solo mining; you still fully > control your Monero node and what it mines, but *you get frequent > payouts like on a regular pool.*’ > The Monero description is evidently written by a marketer - thats enough justification for caution. For example, the use of the word "like" in the description appears to remove rather than add clarification I know which of the following statements is more reassuring: * You will be paid Saturday * You will be paid like Saturday Similarly, the repeating use of terms (P2P, mining, pool) and the name Monero feels like a cynical approach at inbibing rather than educating. FWIW, Ive noticed that many toolset descriptions are turning into hyperbole on the homepages. Ive found that visiting forges READMEs tends to provide clearer and more concise descriptions of what a tool is and its functions. If a concise and normative technical definition of the tool exists then maybe it can be considered (inspite of all the moral hazards and negative externalities). Until then, let such hazardous pools mine their chains *all solo like* on other OSes. Jonathan McHugh indieterminacy@libre.brussels
Re: Celebrating ten years of Guix
Hello Ludo, If it helps, feel free to use HSBXL in Belgium as a node. => hsbxl.be/ While not a spacious or plush as the Guix Days location, it has ClubMate and better ICT support. I can be onsite 24/7 whenever you need access. ==== Jonathan McHugh indieterminacy@libre.brussels January 12, 2022 4:11 PM, "Ludovic Courtès" wrote: > Hello Guix! > > This year marks the tenth anniversary of Guix; what if we used that as a > pretext to join forces and organize “special events” throughout the > year? Obviously the Guix Days are already a great start! > > Things that come to mind: > > • Install parties. After the upcoming release, interested folks could > team up with their local GNU/Linux user groups, or with colleagues, > friends, enthusiasts to organize install parties. We could collect > those events on a web page. That’s a great way to connect people, > to debunk fears and myths, and also to get invaluable feedback that > will allow us to improve the installation process. > > • Talks. Presenting Guix to an audience who doesn’t know about it: > could be again your local GNU/Linux user group, colleagues, sysadmin > or techie conferences, scientific conferences, etc. There are many > people here who could do a great job at introducing Guix and sharing > their own experience! > > • Articles. Get an introductory article in your local GNU/Linux or > sysadmin magazine or in some on-line magazine or specialized > journal! > > • Hackathons. Organizing hackathons focused on specific topics: again > it could be local hackathons focused on getting software your > organization or friends need packaged for Guix, it could be on-line > hackathon focused on core features, Software Heritage and Disarchive > integration, scientific workflows, documentation (like the recent > meetups jgart & Julien organized!), translation, etc. > > • Sharing enthusiasm, freedom, and collective work! :-) > > Icing on the cake if Luis, Ricardo, and other artists among us come up > with some sort of a birthday logo, music, and whatnot! > > What do people think? > > Ludo’.
Re: Guix wiki
Hi Matt, Thanks for an interesting and thoughtful thread. FYI, I am developing an interpreting application that will be mixing Emacs-Hyperboles tree orientated format with Gemini protocol's GemText format (as well as some classification approaches). Potentially it can (eventually) make a good fit for a wiki. I will be presenting some aspects around it for Fosdem => https://fosdem.org/2022/schedule/event/minimalsyntaxes/ Kind regards, ==== Jonathan McHugh indieterminacy@libre.brussels January 11, 2022 3:24 PM, "Matt" wrote: >> There are definitely wikis which use fairly simple markup > >> (e.g. markdown) and can usefully be read and updated online via a web >> interface and git offline or online. The one I'm most familiar with is >> ikiwiki (available in guix), though don't have a lot of experience >> updating it via the web interface. > > It looks like the web interface is simple yet sufficient, basically a text > box and then the buttons > you'd expect: submit, preview, add/remove attachment. It uses the usual > markdown syntax and can > support others using plugins. > > https://ikiwiki.info/ikiwiki/formatting > > The default style is pretty bare bones, but I imagine it could be made to > match the Guix theme. > > Great suggestion!
Re: Formalizing teams
December 23, 2021 4:13 PM, "Blake Shaw" wrote: > Ludovic Courtès writes: > >> One idea that I like is to bring structure to the group, or rather to >> make structure visible, so that newcomers know who they can talk to to >> get started on a topic, know who to ping for reviews, and so that each >> one of us can see where they fit. Rust has well-defined teams: >> >> https://www.rust-lang.org/governance > > Definitely! Perhaps this an aesthetic matter, but keeping-with the > community spirit of Guix, and the existing nomenclature where the > 'core' maintainers are called a "collective", perhaps we should avoid > some of the more corporate "team" language of Rust/Mozilla and stick to > "collectives"? > I reckon 'coterie' is more elegant a term: ``` : an intimate and often exclusive group of persons with a unifying common interest or purpose ``` Jonathan McHugh indieterminacy@libre.brussels
Re: public-inbox/elfeed -> Maildir bridge (was: Incentives for review)
Hi Kyle,
Lei and B4 look like very cool tools, thanks for the reference!
Jonathan McHugh
indieterminacy@libre.brussels
October 23, 2021 6:19 PM, "Kyle Meyer" wrote:
> zimoun writes:
>
>> On Fri, 22 Oct 2021 at 21:43, Kyle Meyer wrote:
>
> [...]
>
>>> https://yhetil.org/guix-patches/?q=dfn:docker=A
>>
>> Oh, that’s really cool!
>>
>> Do you know a bridge from Elfeed to Message-mode?
>>
>> I mean, using the feed you are referring, Alice gets:
>>
>> --8<---cut here---start->8---
>> Title: [bug#50227] [PATCH] build-system/go: Trim store references using the
>> native compiler option.
>> Author: Marius Bakke
>> Date: Fri, 27 Aug 2021 18:45:37 CEST
>> Feed: dfn:docker - search results
>> Link: https://yhetil.org/guix-patches/20210827164423.17109-1-mar...@gnu.org
>>
>> * guix/build/go-build-system.scm (build): Add '-trimpath' to the 'go install'
>> invocation.
>> […]
>> --8<---cut here---end--->8---
>>
>> This is really nice for filtering and only reading what is of interest
>> (for Alice).
>>
>> However, it is not handy for commenting. It could be cool to have a way
>> to turn what I showed (above) into a reply message. Does a bridge exist
>> somewhere?
>
> Good question. It does :)
>
> With the link in the Elfeed buffer, we can grab the mbox for a message
> or entire thread from a public-inbox instance. So, for those that use a
> Maildir locally, the steps are to
>
> 1) download the message (or thread)
> 2) convert the mbox into Maildir messages
> 3) visit the message in your regular mail client
> 4) proceed as usual
>
> piem can take care of 1 and 2 (as well as 3, with some user
> configuration) via its piem-inject-thread-into-maildir command:
>
> https://docs.kyleam.com/piem/Injecting-messages-into-a-Maildir-directory.html
>
> This command isn't specific to Elfeed buffers. It just needs to be in a
> buffer where piem knows how to grab the public-inbox link:
>
> https://docs.kyleam.com/piem/Enabling-integration-libraries.html
>
> The other supported modes that are interesting in this context are EWW
> and Gnus.
>
> Elfeed -> Notmuch
> =
>
> zimoun, I know you're a Notmuch user, so here's how you could configure
> things so that calling piem-inject-thread-into-maildir from the Elfeed
> buffer above throws you into a Notmuch show buffer for the message.
>
> * add a guix-patches entry to piem-inboxes
>
> (add-to-list 'piem-inboxes
> '("guix-patches" :url "https://yhetil.org/guix-patches;))
>
> * point piem to your Maildir
>
> (setq piem-maildir-directory "/path/to/maildir/")
>
> Alternatively, messages for different projects can be sent to
> different Maildir directories using the :maildir keyword in the
> piem-inboxes entry. (This feature was added by Xinglu Chen :>)
>
> * enable Elfeed integration
>
> (piem-elfeed-mode 1)
>
> * tell piem to visit the message in Notmuch after injecting
>
> (add-hook 'piem-after-mail-injection-functions
> (lambda (mid)
> (require 'notmuch-lib)
> (message "Running notmuch new")
> (call-process notmuch-command nil nil nil "new")
> (notmuch-show (concat "id:" mid
>
> You actually asked about ending up in a (Notmuch) message mode buffer
> rather than a Notmuch show buffer. Perhaps tossing a
> notmuch-show-reply in there after notmuch-show will work as expected,
> though I haven't tested it.
>
> lei
> ===
>
> This email is already too long, but I should briefly mention that Eric
> Wong (public-inbox's creator) has been working on a local command-client
> client for public-inbox called lei (local email interface).
>
> To continue with the original dfn example, you could do something like
> this with lei to dump those results to a Maildir and then view those in
> mutt:
>
> $ lei q -o /tmp/mdir --mua mutt \
> -I https://yhetil.org/guix-patches dfn:docker d:4.months.ago..
> # later: update with new results and visit in mutt
> $ lei up --mua mutt /tmp/mdir
>
> Anyway, that's just a small piece of what lei can do, and IMO it's
> really impressive and exciting. It will be a part of the next
> public-inbox release, v1.7. (How this all ends up integrating with piem
> is very much up in the air.)
>
> For a high-level picture that includes public-inbox, lei, and b4:
> Konstantin Ryabitsev, b4's creator, recently talked at the Linux
> Plumbers Conference:
>
> https://linuxplumbersconf.org/event/11/contributions/983/attachments/759/1421/Doing
> more with lore
> and b4.pdf
>
> The lei part starts on page 24. I believe there's a video out there,
> but I haven't watched it and don't have a link on hand.
Re: Incentives for review
Hi Arun, I wasnt thinking of that. Ill update you if I find a reference among my notes. Jonathan October 22, 2021 12:44 PM, "Arun Isaac" wrote: > Hi Jonathan, > >> If I recall, you can request Debbugs content if you email them. > > I think you are referring to https://debbugs.gnu.org/server-request.html > I haven't tried it myself, and I'm not sure, but it probably doesn't > give you access to the raw emails. I'm guessing it's just an email > interface to the usual SOAP API. > > Regards, > Arun
Re: Incentives for review
October 22, 2021 12:48 PM, "Arun Isaac" wrote: > Hi Ricardo, > >> These are all excellent ideas, and seeing you articulate them >> makes me happy, because in my experience there’s always good code >> around the corner whenever you have good ideas :) > > He he, thanks! :-) > >> So to hack on mumi I’d suggest downloading a copy of the raw debbugs >> data from issues.guix.gnu.org. I could put an archive somewhere where >> you can fetch it. > > Yes, please! Some minimal archive along with a few lines of instructions > on how to import it into mumi would be great. It might also be more > generally useful to people who want to hack on mumi. > > Thanks, > Arun Seconded
Re: Incentives for review
Hi Simon, October 22, 2021 11:22 AM, "zimoun" wrote: > Hi Jonathan, > > On Fri, 22 Oct 2021 at 08:37, "Jonathan McHugh" > wrote: > >> Its also worth citing some of the suggestions in this devel-guix thread >> concerning tooling or >> options: >> https://lists.nongnu.org/archive/html/guix-devel/2021-08/msg00042.html > > Thanks. > >> Suggestions included: >> Bugs Everywhere https://bugs-everywhere.readthedocs.io/en/latest >> Git-Issue https://github.com/dspinellis/git-issue >> Fossil https://fossil-scm.org/home/doc/trunk/www/bugtheory.wiki >> >> IMHO, I though Bugs Everywhere was the most interesting, though it may have >> experienced some >> bitrot. > > Git based, it is possible to use public-inbox with: > > <https://yhetil.org/guix-bugs> > Yes, Arun has recommended public-inbox before, Im enthused by anything he uses or packages. >> More recently I have been deliberating on the idea of using a MUD type >> tool as an interface for issue and bugtracking. > > Yeah, maybe gamify the review could help. Maybe Libreadventure could > help. > > 1: <https://vcs.fsf.org/?p=libreadventure.git;a=tree> > 2: <https://lists.gnu.org/archive/html/guix-devel/2021-09/msg00208.html> > Thanks for the catch, I had forgotten that one (and your appeal for someebody to package it!). The fact its been trialed with FSF and could be Guix Days compatible is a big plus. TBH, having mastered lua/jit I would feel a bit dirty packaging NPN to satisfy something that Lua would be better suited for. What are the (technical/usability) advantages of choosing LibreAdventure? I will reflect on this, though Im (personally) more interested in building worlds from GemText than JSON. # One more suggestion Has anybody ever considered or used psyc - Protocol for Synchronous Conferencing? (its how I discovered Powwow) https://psyc.eu/ ``` description Imagine smartly multicasted chat and conferencing, non-proprietary instant messaging, distributed social networking and data sharing. And now imagine all of this rolled into one. PSYC is an open source protocol and technology, bringing the useful and amazing aspects of several technologies, some of which have been proprietary too long, together. It has a curious mixture of bit ambition and long history but I cant (yet) tell how modern and functional it is. Pscyc utilities seem interesting https://perl.psyc.eu/ ``` git2psyc- report changes to a git repository into a developer chatroom psycauth- authenticate something with your PSYC identity psyccat - dump a file to a PSYC recipient psyccmd - remote control psycamp and whatever wants to be controlled psycfilemonitor*- notify changes to the file system in realtime psycion - amazing console psyc client! psyclisten - receive messages and notify the user about them psycmail- report incoming emails to the recipient psycamp*- media player with PSYC notification and remote control psycmsg - send a message to a PSYC recipient psycnotify - send presence notification from the command line psycsyncd - interfaces PSYC SYNC protocol to DBI (SQL databases etc) syslog2psyc - daemon that receives events from syslog and forwards to PSYC remotor - control console for Tor routers that can notify into PSYC ``` For my purposes, the PSYC Syntax Specification could potentially serve orthogonal aspects for complementing the design principles of the Gemini protocol https://about.psyc.eu/Spec:Syntax https://gemini.circumlunar.space/docs/specification.html Jonathan
Re: Incentives for review
Hi Simon, I had noticed Woof and it does seem interesting and worthy of analysis. I should point out that the Ogmode community have the same problems and complaints regarding the governance and efficacy of issue/bug tracking. This is a socio-technological problem, which hopefully has solutions which can cut across communities. Its also worth citing some of the suggestions in this devel-guix thread concerning tooling or options: https://lists.nongnu.org/archive/html/guix-devel/2021-08/msg00042.html Suggestions included: Bugs Everywhere https://bugs-everywhere.readthedocs.io/en/latest/ Git-Issue https://github.com/dspinellis/git-issue Fossil https://fossil-scm.org/home/doc/trunk/www/bugtheory.wiki IMHO, I though Bugs Everywhere was the most interesting, though it may have experienced some bitrot. More recently I have been deliberating on the idea of using a MUD type tool as an interface for issue and bugtracking. It seems that Powwow would be capable of using scripts in an interesting way. https://www.hoopajoo.net/static/powwow-mirror/powwow/index.html This interests me: ``` Powwow also implements the MUME remote editing protocol, which enables you to edit texts on the MUD using your own favourite editor, several texts at once if you have a windowing terminal. ``` Im also investigating Tintin++ https://tintin.mudhalla.net/ I personally would find it interesting to create 'conversational models' for issue/bug tracking in such an environment, backed by: * interoperability with computing environments * interpreting infrastructure * projectile style configurations * supplementary protocols * light writing formats * configs and bindings to provide workflow A MUD type inferface is perhaps only a speculative concern but Id be interested in hearing -/+ opinions and interest levels, if not practical suggestions. As some may be aware, I have been considering the issue/bug tracking topic from the perspective of the Gemini protocol (though now with a wider scale than just comsidering Debbugs). That is proceeding, though I was impeeded by some physical setbacks (status:resolved) and completing wider responsibilities. Now back in the flow, I will provide updates once my projects start perculating. @Arun please mail me privately regarding your plans, Id like to hear about where they may be intersections. @Christine I look forward to replying to your (private) mail in due course - apoligies for radio silence. If you have suggestions regarding how Guix can go MUD Im sure we'd all be interested! Kind regards, Jonathan McHugh indieterminacy@libre.brussels October 22, 2021 9:44 AM, "zimoun" wrote: > Hi Arun, > > On Thu, 21 Oct 2021 at 23:51, Arun Isaac wrote: > >> The way I see it, we are outgrowing general purpose bug trackers like >> debbugs. We need a special purpose bug tracker specifically for Guix >> with its special requirements. We are a big enough community for this to >> be important. > > For an example of such «special purpose bug tracker», give a look at > what Org-mode people do: > > <https://updates.orgmode.org> > > Well, it is currently down. It looks like that: > > <https://web.archive.org/web/20210228064154/https://updates.orgmode.org> > > The code running it is Woof (lisp based): > > <https://github.com/bzg/woof> > > Maybe there are some ideas to borrow. :-) > > Cheers, > simon
Re: Public guix offload server
I have utmost confidence in the Guix project, it has lots of smart and inquisitive people to suppliment its accountable structures - a very useful bulwark against exploitative behaviour! Jonathan McHugh indieterminacy@libre.brussels October 22, 2021 12:59 AM, "Tobias Geerinckx-Rice" wrote: > All, > > zimoun 写道： > >> Do you mean that trusted users would try WM-escape exploits? >>> The world has been formed by warewolves inside communities >>> purposely >>> causing harm. Looking further back, Oliver the Spy is a classic >>> examplar of trust networks being hollowed out. > > So… > >> I cannot assume that on one hand one trusted person pushes to >> the main >> Git repo in good faith and on other hand this very same trusted >> person >> behaves as a warewolves using a shared resource. > > …li'l' sleepy here, bewarned, but before this gets out of hand: I > never implied direct abuse of trust by committers. I don't > consider it the main threat[0]. > > There are the people you meet at FOSDEM and the users who log into > machines. Both can be compromised, but the latter are much easier > and more likely to be. > > Such compromise is not laughable or hypothetical: it happens > *constantly*. It's how kernel.org was utterly owned[1]. > > Trusting people not to be evil is not the same as having to trust > the opsec habits of every single one of them. Trust isn't > transitive. Personally, I don't think a rogue zimoun will > suddenly decide to abuse us. I think rogues will abuse zimoun the > very first chance they get. > > That's not a matter of degree: it's a whole different threat > model, as is injecting arbitrary binaries vs. pushing malicious > code commits. Both are bad news, but there's an order of > magnitude difference between the two. > >> For sure, one can always abuse the trust. Based on this >> principle, we >> could stop any collaborative work right now. The real question >> is the >> evaluation of the risk of such abuse by trusted people after >> long period >> of collaboration (that’s what committer usually means). > > Isn't that the kind of hands-up-in-the-air why-bother > nothing's-perfect fatalism I thought your Python quote (thanks!) > was trying to warn me about? ;-) > > Zzz, > > T G-R > > [0]: That's probably no more than an optimistic human flaw on my > part and ‘disgruntled ex-whatevers’ are probably more of a threat > that most orgs dare to admit. > > [1]: I know, ancient history, but I'm working from memory here. > I'm sure it would be trivial to find a more topical example.
Re: Public guix offload server
October 21, 2021 8:10 PM, "zimoun" wrote: > >> Now, we could spin up a separate VM for each user, and just take >> the efficiency hit… Users would be safe from anything but >> VM-escape exploits (which exist but are rare). > > Do you mean that trusted users would try WM-escape exploits? > The world has been formed by warewolves inside communities purposely causing harm. Looking further back, Oliver the Spy is a classic examplar of trust networks being hollowed out. Jonathan
Re: Incentives for review
If I recall, you can request Debbugs content if you email them. Jonathan McHugh indieterminacy@libre.brussels October 21, 2021 8:22 PM, "Arun Isaac" wrote: > Hi, > >> Thiago’s idea to allow people to subscribe to certain *kinds* of >> issues when they are reported is also good. > > I agree this is a great idea. Recently, I unsubscribed from > guix-patches. It's just too high volume. These days, I prefer to just > search for issues using emacs-debbugs and mumi. > > Here's another idea for mumi: mumi should have a JSON API. Debbugs' SOAP > API is quite terrible, and doesn't even expose such things as the number > of emails in an issue. Mumi can offer its own API which does these > things properly. That way, we can write new clients (say, a CLI client) > for mumi, that can filter more intelligently. If we had a good CLI > client, our contributors wouldn't have to set up an email client or > emacs just to participate. > > The way I see it, we are outgrowing general purpose bug trackers like > debbugs. We need a special purpose bug tracker specifically for Guix > with its special requirements. We are a big enough community for this to > be important. > > I might be able to find some time to implement a simple JSON API for > mumi. Would there be interest in such a contribution? > > Regarding, hacking on mumi, I understand that issues.guix.gnu.org is on > an IP whitelist with the GNU debbugs server. How do I hack on mumi if > simply running it on my local machine, and pulling data from GNU debbugs > would alarm the debbugs admins? > > Regards, > Arun
[off-topic]
Hello, I noticed an interesting report^1 on the holistic approach from Emacs and how its 'additive solutions' assist problem solving for researchers. Given Guix's emphasis on reproducible research I felt it worth sharing given overlapping concerns. https://www.ingentaconnect.com/content/matthey/jmtr/pre-prints/content-jm_jmtr_johnsapr22 ``` It is human nature to prefer additive problem solving even if removal may be the more efficient solution. This heuristic has wide ranging implications when dealing with science, innovation and complex problem solving. This is compounded when dealing with these issues at an institutional level. Additive solutions to workflows with extra software tools and proprietary digital solutions can impede work without offering any advantages in terms of FAIR data principles or productivity. The below Viewpoint highlights one possible workflow and the mentality underpinning it with an aim to incorporate FAIR data, improved productivity and longevity of written documents while improving workloads within industrial R ``` ^1 via the blog Irreal Jonathan McHugh indieterminacy@libre.brussels
Re: IT jobs in Switzerland OFF TOPIC JOKE
(I got this mail from other channels, bleurgh...). Zig, Switzerland would be more cool. CVs are only accepted in APL format. Jonathan McHugh indieterminacy@libre.brussels September 24, 2021 5:22 PM, "Joshua Branson" wrote: > Gábor Boskovits writes: > >> Hello guix, >> >> The firm where I am working now is hiring. >> >> Location: Zug, Switzerland. People willing to work in office will be >> preferred. The firm helps with >> relocation if needed. >> >> Profile: HFT crypto startup >> >> Codebase: c++, python >> Tooling: k8s, gitlab > > I'm an expert ping pong player, and master mattress tester. You may > have heard of me. I should warn you...I am expensive to hire. :) > >> Positions: quantitative trader, quantitative researcher, c++ developer, >> devops >> >> Experience with AWS is a plus. >> >> If someone is willing to give this a try, please come back to me and I can >> provide more details. >> >> Regards, >> g_bor > > P.S. I'm just kidding this job description is a little beyong me, but > best of luck recruiting talented people! > > -- > Joshua Branson (jab in #guix) > Sent from Emacs and Gnus > https://gnucode.me > https://video.hardlimit.com/accounts/joshua_branson/video-channels > https://propernaming.org > "You can have whatever you want, as long as you help > enough other people get what they want." - Zig Ziglar
Re: [Spam:]Re: “What’s in a package”
Hi Konrad, Similarly I found the post excellent. Your focus regarding a transition from exploratory to robust is important (though may have equal significance in the other direction?). Would security experts have (understandable) criteria to prioritise choices for 'robust corridors' within an ecosystem of sourcefiles and encapsulated blobs? Jonathan McHugh indieterminacy@libre.brussels September 22, 2021 3:32 PM, "Konrad Hinsen" wrote: > Hi Katherine and Ludo, > >> I appreciate this post very much. Setting aside questions of freedom, > > +1 > >> This is perhaps a rehash of the "worse is better"[2] conversation, but >> I often struggle with deciding whether to do things the "fast" way, or >> the "correct" way. I think when your path is clear, the correct way >> will get you farther, faster. But when you're doing experiments, or >> exploratory programming, being bogged down with the "correct" way of >> doing things (i.e. Guix packages) might take a lot of time for no > > Exactly. Most software engineering tools situate themselves somewhere on > the "fast" vs. "robust" scale, and defend their position as the one and > only Good Thing. Guix is at the "robust" end of the scale in the > software management category. And that's what I want for most of the > software I use, i.e. everything I don't hack on myself. Which is why I > like Guix :-) > > What is so far insufficiently supported by computing technology is the > necessary transition from "fast" to "robust". There are a few > exceptions, such as programming language with gradual typing. In most > situations, moving software from exploratory to robust involves a lot of > rewriting, often manually, with no tooling support. > >> Bringing this back to Guix, and maybe the GNU philosophy, it has been >> very helpful for me to be able to leverage the flexibility of Guix to >> occasionally do things the "fast" way, perhaps by packaging a >> binary. Paradoxically, it has allowed me to stay within the Guix and >> free software ecosystem. In my opinion, flexibility is key to growing >> the ecosystem and community, and I would encourage Guix as a project >> to take every opportunity to give the user options. > > +100 :-) > > There is a lot we can improve here. Tutorials would be a good start. > Example: How do you package a binary in Guix? In particular, how do you > deal with binaries that have binary dependencies that they expect in > /lib etc.? A next step would be tool support: Grab whatever PyPI offers, > even if it's only binary wheels, and turn that into a Guix package. > > Another aspect would be supporting software development moving from fast > to robust. Suppose I have software I compile by hand, or via a simple > Makefile, somewhere in my home directory. How do I go from there to (1) > a quick-and-dirty Guix package, then (2) a very basic publishable Guix > package and finally (3) a Guix package with tests and documentation? > The path should be supported by various tools, from automatic rewriting > to debugging. As an example, something I have wished for more than once > is the possibility to run the individual build steps of a Guix package > under my own account in my home directory, for debugging purposes. > > Konrad > -- > - > Konrad Hinsen > Centre de Biophysique Moléculaire, CNRS Orléans > Synchrotron Soleil - Division Expériences > Saint Aubin - BP 48 > 91192 Gif sur Yvette Cedex, France > Tel. +33-1 69 35 97 15 > E-Mail: konrad DOT hinsen AT cnrs DOT fr > http://dirac.cnrs-orleans.fr/~hinsen > ORCID: https://orcid.org/-0003-0330-9428 > Twitter: @khinsen > -
Re: Can we find a better idiom for unversioned packages?
Hi Ludo, Just checking: Is Diffstatic a real tool? It wasnt quite clear to me (and I fancy finding a new diff tool). Jonathan McHugh indieterminacy@libre.brussels September 8, 2021 11:31 PM, "Ludovic Courtès" wrote: > Hello! > > Sarah Morgensen skribis: > >> Currently, there are about 1500 packages defined like this: >> >> (define-public sbcl-feeder >> (let ((commit "b05f517d7729564575cc809e086c262646a94d34") >> (revision "1")) >> (package >> [...]))) >> >> I feel like there are some issues with this idiom (in no particular >> order): > > I’m late to the party but I’ll complement previous answers. :-) > >> 1. When converting between this idiom and regularly versioned packages, >> the git diff shows the whole package changing because of the indentation >> change. > > One can use ‘git diff -w’ to work around that (or the newfangled > Diffstatic tool.) > >> 3. Packages inheriting from it lose the definitions. For actual fields, >> we have e.g. `(package-version this-package)`, but we have no equivalent >> for these. > > Right, these pieces of information are not “first-class”, except in the > ‘git-reference’ record (or similar) for the commit ID. Do you have > examples in mind where it’s insufficient? > > [...] > >> 5. The closest thing we have to a standardized way of generating >> versions for these packages is `(version (git-version "0.0.0" revision >> commit))`. We can do better than that boilerplate. > > I can sympathize with the feeling, but I’m not sure what to do. A > ‘vcs-version’ record as Maxime proposes seems a bit overkill to me (and > it would probably have an impact on performance, build times, and > whatnot.) > >> 6. Not a direct complaint, but I feel like the overall package interface >> was designed before straight-from-vcs unversioned packages were so >> common, and so this idiom developed organically to work around that. > > Sure, though “straight-from-vcs” and “unversioned” are two different > things: I’m fine with the former, but the latter equates to upstream > telling its users “go find a revision that works for you”. I think > releases still make sense for any non-trivial piece of software. > > As noted in the manual (info "(guix) Version Numbers"), packages built > from arbitrary commits were supposed to be exceptional. Perhaps the > reason we’re having this conversation now is that development practices > are evolving towards what looks like chaos. :-) > > Thanks, > Ludo’.
Re: Guix Jargon File (WAS: Rethinking propagated inputs?)
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--- > > 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 >> document
Re: Can we find a better idiom for unversioned packages?
Hi Liliana, Given your examples I expect improving upstream CHANGELOG (or third party) files would be too much of a burden in order to solve the aforementioned problems. Jonathan September 1, 2021 11:47 PM, "Liliana Marie Prikler" wrote: > Am Mittwoch, den 01.09.2021, 19:48 + schrieb Jonathan McHugh: > >> September 1, 2021 8:35 PM, "Liliana Marie Prikler" < >> leo.prik...@student.tugraz.at> wrote >> >> Making our rando commit git versions look like such other distro >> versions does come at a disadvantage though, particularly when we >> look >> at it through the lense of someone not used to Guix' versioning >> scheme. >> Instead of telling us "yeah, this is the Nth time we picked a rando >> commit since the last release and this time it's de4db3ef", users >> coming from such distros would assume "oh well, this is still good >> ol' >> 1.0 with some more patches applied". So while the commit itself >> does >> not give us any particularly useful information (unless you're that >> person who uses this part of the version string to look the commit >> up >> on hubbucket), especially not when thinking in the context of >> versioning scheme, it does provide the existential information of >> "hold >> on, this is not a release commit, it's something else" and might >> thus >> direct users to be a little more attentive when they'd otherwise go >> "yep, upstream considers this solid and Guix considers it even more >> solid, so it's the solidest". Note, that this can be overcome both >> by >> teaching/learning about it and by using a special sigil as >> mentioned >> above. >> >> Perhaps a function revealing metadata based upon the version string >> would allow more people get an overview without visiting hubbucket^1? > > I don't think that information is actually encoded anywhere nor > immediately obvious unless you're vaguely familiar with said software, > but it's still important e.g. if reading the documentation. Does this > feature mentioned in the frobnicatorinator 1.44 docs apply to 1.36 or > not? Do the examples from some book written in the early 70s work if I > compile them with GCC 12? And so on and so forth.
Re: Can we find a better idiom for unversioned packages?
September 1, 2021 8:35 PM, "Liliana Marie Prikler" wrote > Making our rando commit git versions look like such other distro > versions does come at a disadvantage though, particularly when we look > at it through the lense of someone not used to Guix' versioning scheme. > Instead of telling us "yeah, this is the Nth time we picked a rando > commit since the last release and this time it's de4db3ef", users > coming from such distros would assume "oh well, this is still good ol' > 1.0 with some more patches applied". So while the commit itself does > not give us any particularly useful information (unless you're that > person who uses this part of the version string to look the commit up > on hubbucket), especially not when thinking in the context of > versioning scheme, it does provide the existential information of "hold > on, this is not a release commit, it's something else" and might thus > direct users to be a little more attentive when they'd otherwise go > "yep, upstream considers this solid and Guix considers it even more > solid, so it's the solidest". Note, that this can be overcome both by > teaching/learning about it and by using a special sigil as mentioned > above. Perhaps a function revealing metadata based upon the version string would allow more people get an overview without visiting hubbucket^1? Would that be any weirder and awkward for workflows than the command `guix download'? => https://guix.gnu.org/manual/en/html_node/Invoking-guix-download.html Even better, highlighting the part of the string and launching an appropriate context in Emacs-Hyperbole > My personal answer to this might be a disappointing one, as in that > case I believe we wouldn't even need procedures like git-version to > form them, but could instead use - as > a mere convention like many more popular distros already do. If the > dash is overused for that, we could also use a different symbol, though > perhaps there's not that many on a typical US keyboard to reserve one > as a revision delimiter. # Apologies for being off topic The inclusion of that character '£' on keyboards bothers me - Ive never seen anybody use it (though maybe I have some fuzzy memory with regards to the Commodore 64). If it unfortunately is on an international band of keyboard classes consider it as a delimiter. Otherwise Im ripping out that button and never interfacing the number 3 again. ^1 Is that pronounced bouquet? => https://keepingupappearances.fandom.com/wiki/Hyacinth_Bucket Jonathan McHugh indieterminacy@libre.brussels > Am Mittwoch, den 01.09.2021, 18:39 +0200 schrieb Maxime Devos: > >> Liliana Marie Prikler schreef op wo 01-09-2021 om 15:33 [+0200]: >> Hi >> >> Am Dienstag, den 31.08.2021, 23:20 +0200 schrieb Maxime Devos: >>> Sarah Morgensen schreef op di 31-08-2021 om 12:57 [-0700]: >>>> Hello Guix, >>>> >>>> Currently, there are about 1500 packages defined like this: >>>> >>>> --8<---cut here---start->8- >>>> -- >>>> (define-public sbcl-feeder >>>> (let ((commit "b05f517d7729564575cc809e086c262646a94d34") >>>> (revision "1")) >>>> (package >>>> [...]))) >>>> --8<---cut here---end--->8- >>>> -- >>>> >>>> I feel like there are some issues with this idiom (in no >>>> particular >>>> order): >>>> >>>> 1. When converting between this idiom and regularly versioned >>>> packages, the git diff shows the whole package changing because >>>> of >>>> the indentation change. >> If you are worried about that in a frequently changing package, you >> could set both to *unspecified* or #f instead, which would cause >> any >> reference to them in a string manipulation context to fail. I >> don't >> think that such transitions are too frequent, though, as the point >> is >> rather to discourage them where not absolutely necessary and to use >> upstream releases instead. >> >>>> 2. We cannot get at the source location for the definition of >>>> 'commit' or 'revision'. This would be useful for updating >>>> these >>>> packages with `guix refresh -u`. There is a proposed patch [0] >>>> to >>>> work around this, but it *is* a workaround. >> Other versioning idioms would also be workarounds, wouldn't they? >> >>>> 3. Packages inheriting from it lose the definitions. For >>>> actual >>>> fie
