Re: On raw strings in commit field

Hi simon, Am Dienstag, dem 04.01.2022 um 00:00 +0100 schrieb zimoun: > [...] > > You are saying what I predicted you will say :-) ; here I quote > myself: > >     The statement «Git commit hashes do not just depend on the >     content» is wrong.  [...] > > Sorry, I used meta-content

Re: guix fails to build on aarch64

Ricardo Wurmus writes: > > test-name: file-needed/recursive > > location: > > /tmp/guix-build-guix-1.3.0-14.2a621f1.drv-0/source/tests/gremlin.scm:70 > > source: > … > > + (and (zero? (close-pipe pipe)) > > + (lset= string=? > > + (pk 'truth ground-truth) > > +

Alternative solution to stat storm problem

Hi! I was very inspired by the blog post on a per-application ld.so.conf.cache to solve the stat-storm problem[1]. I wanted to share here another approach I am pursuing and seek to eventually try to merge into NixOS however I thought starting a discussion here on Guix would be fruitful since it

Re: On raw strings in commit field

Hi Liliana, Liliana Marie Prikler writes: > Am Sonntag, dem 02.01.2022 um 17:57 -0500 schrieb Mark H Weaver: >> Hi Liliana, >> >> Liliana Marie Prikler writes: >> >> > Am Samstag, dem 01.01.2022 um 15:37 -0500 schrieb Mark H Weaver: >> > > Liliana Marie Prikler writes: >> > > > > Where is

Re: On raw strings in commit field

Hi Liliana, On Mon, 03 Jan 2022 at 21:19, Liliana Marie Prikler wrote: > That's not the case I'm making here. The case I'm making is that Git > considers some content content, which Guix does not consider content. > If I push the same file to two branches, once with the commit message >

Re: On raw strings in commit field

Am Sonntag, dem 02.01.2022 um 17:57 -0500 schrieb Mark H Weaver: > Hi Liliana, > > Liliana Marie Prikler writes: > > > Am Samstag, dem 01.01.2022 um 15:37 -0500 schrieb Mark H Weaver: > > > Liliana Marie Prikler writes: > > > > > Where is the Cantor-style diagonalization argument that you > >

Re: On raw strings in commit field

Am Montag, dem 03.01.2022 um 20:07 +0100 schrieb zimoun: > This is somehow intrinsic* because public-inbox uses Message-ID as URL. > Therefore, using emacs-notmuch, you just have to search for > id:86y243kdoo@gmail.com for instance. > > *intrinsic: no it is not intrinsic but self-contained.

Re: Convention for new “guix style“?

Hi Leo, On Mon, 03 Jan 2022 at 14:51, Leo Famulari wrote: >> Can you summarize Walder's law? I don't have time to watch that video. > > Never mind, I see that it's Wadler's law: > > -- > In any language design, the total time spent discussing > a feature in this list is proportional to two

Outreachy

Hello guix, Outreachy mentor applications for the nextr round opened on 1st January. I have two quetions regarding that. Q1: Are there any project proposals? Prospective mentors please feel free to propose your projects, so that we can discuss. Q2: Have the situation regarding the funding of

Re: EXWM

calcium writes: > I was totally at lost when I started my emacs/exwm session and tried to > `find-file' only to be redirected to an 'ido-find-file` with whom I don't > know how to navigate. > > In the moment, it felt very intrusive for me and I was very afraid to be > unable to control my

Re: Convention for new “guix style“?

On Mon, Jan 03, 2022 at 05:23:22PM +0100, zimoun wrote: > Well, I disagree. But yeah, as you said elsewhere 1) the proposal had > been done more than 6 months ago so I had time to wake up and raise and > 2) let avoid to fall into the Walder’s law; as exposed by the excellent > food for thought

Re: Convention for new “guix style“?

On Mon, Jan 03, 2022 at 02:48:27PM -0500, Leo Famulari wrote: > On Mon, Jan 03, 2022 at 05:23:22PM +0100, zimoun wrote: > > Well, I disagree. But yeah, as you said elsewhere 1) the proposal had > > been done more than 6 months ago so I had time to wake up and raise and > > 2) let avoid to fall

Re: On raw strings in commit field

Hi Liliana, On Mon, 03 Jan 2022 at 19:13, Liliana Marie Prikler wrote: > Am Montag, dem 03.01.2022 um 10:22 +0100 schrieb zimoun: >> On Sun, 02 Jan 2022 at 22:35, Liliana Marie Prikler >> wrote: >> >> > > The statement still appears to me wrong because Git commit hash >> > > only depends on

Re: On raw strings in commit field

Am Montag, dem 03.01.2022 um 10:22 +0100 schrieb zimoun: > Hi Liliana, > > On Sun, 02 Jan 2022 at 22:35, Liliana Marie Prikler > wrote: > > > > The statement still appears to me wrong because Git commit hash > > > only depends on the content itself. > > > > If you define content through the

Re: Convention for new “guix style“?

Hi Ludo, On Mon, 03 Jan 2022 at 16:02, Ludovic Courtès wrote: > When doing the first iterations of ‘guix style’¹, I found it more > pleasant to the eye to have small lists on a single line, the prime > example being: > > (native-inputs > (list autoconf automake libtool pkg-config)) > >

Re: Release v1.4 (or 2.0): process and schedule ?

On 2022-01-03, Ludovic Courtès wrote: > Vagrant Cascadian skribis: >> On 2021-12-21, Vagrant Cascadian wrote: > > [...] > >>> Would it be appropriate to fix the ~700 low-hanbging fruit issues that >>> are identified by: >>> >>> guix lint --checkers=description,synopsis > > [...] > >> Could guix

Re: On raw strings in commit field

On 2022-01-03, Ludovic Courtès wrote: > Vagrant Cascadian skribis: > >> How about using the output of git describe, which can unambigously >> include the most relevent tag, the number of commits since that tag, and >> the commit hash: >> >> $ git describe --long --abbrev=41 >>

Re: Guix Package Search API Server

Hi! Sai Karthik skribis: > Nice! I didn't knew about this earlier. Does hpc.guix.info exposes API ? It runs hpcguix-web¹, which exposes a big (but gzipped) JSON file at . Everything else happens in client-side JavaScript code. Ludo’. ¹

Re: Formalizing teams

Ludovic Courtès writes: >> Having some topic-specific streams I could tap into would allow me to be >> a little more proactive. > > This brings a related but slightly different topic: how to let people > filter incoming patches and bug reports in general. On issues.guix.gnu.org we could offer

Re: On raw strings in commit field

Hello, Vagrant Cascadian skribis: > How about using the output of git describe, which can unambigously > include the most relevent tag, the number of commits since that tag, and > the commit hash: > > $ git describe --long --abbrev=41 > v1.3.0-13278-g60661adfb8ffa28e1acfcfea27c6cc2fc70f88fe

Re: On raw strings in commit field

Hello! Timothy Sample skribis: > If you want a concrete example to think through, there’s ‘eclib’. Our > package says it’s version “20190909”, but that’s not what upstream calls > version “20190909”. It looks like when we packaged ‘eclib’, that tag > pointed to commit

Re: search-input-file vs (assoc-ref inputs)

Hi! Leo Famulari skribis: > I noticed that, as part of the transition to the new inputs style [0], > we are sometimes replacing code like (assoc-ref inputs "foo") with > (search-input-file inputs "/bin/foo"). > > I think that we should instead replace the old style with gexps that > specify

Re: Formalizing teams

Hi! ⛄ Ricardo Wurmus skribis: > Maxim Cournoyer writes: [...] >> We'd have to include every language/system of importance to that list >> (Python, Ruby, Emacs, LaTeX, Perl, etc.), no? > > No, only those where we already have the people who could form a team. > There is no need for any of

Re: Formalizing teams

Hello, Filip Łajszczak skribis: > Great idea. As a newcomer who created his first patch in May > https://issues.guix.gnu.org/issue/48289/ that got a review, was fixed > and submitted again, and then disappeared into oblivion, I would be > very happy to be able to ask some "Python packaging"

Re: Convention for new “guix style“?

Hello from 2022! I missed the bikeshedding discussion last year. :-) I think we can tweak style as we go, and it’s okay to have variants around the same style IMO, but I’m against the idea of rewriting the whole repo every time we have a new idea of what things should look like. This one was

Re: importers and input package lookup

Ludovic Courtès writes: > Hi! > > Attila Lendvai skribis: > >> there are two, independent namespaces: >> 1) the scheme one, and >> 2) the guix package repository. >> >> when i work on an importer (golang), it skips the packages that are already >> available in 2), but then it has no clue under

Re: importers and input package lookup

Hi! Attila Lendvai skribis: > there are two, independent namespaces: > 1) the scheme one, and > 2) the guix package repository. > > when i work on an importer (golang), it skips the packages that are already > available in 2), but then it has no clue under what variable name they are > stored

Re: bootstrapping scenario for a package

Hi! Andy Tai skribis: > Hi, I was trying to update mono to the current release version. The > build step as documented actually says to download a minimal C# > compiler from the mono site which is then used to compile the rest of > the source to build the full system. I looked and did not

Re: Release v1.4 (or 2.0): process and schedule ?

Hello! Maxim Cournoyer skribis: > About the current status, I'm nearing on pushing a version-1.4.0 branch > which is based on master with a few more (core-ish) updates. There's > still a few days ahead of that, so if you manage to get many of this > kind of problems fixed & merged in master

Re: Release v1.4 (or 2.0): process and schedule ?

Hello! Vagrant Cascadian skribis: > On 2021-12-21, Vagrant Cascadian wrote: [...] >> Would it be appropriate to fix the ~700 low-hanbging fruit issues that >> are identified by: >> >> guix lint --checkers=description,synopsis [...] > Could guix style be adapted to apply some of these

Re: On raw strings in commit field

Hi Liliana, On Sun, 02 Jan 2022 at 22:35, Liliana Marie Prikler wrote: >> The statement still appears to me wrong because Git commit hash only >> depends on the content itself. > > If you define content through the NAR hash used by Guix, I'm pretty > sure vanity commits invalidate that