Re: Remove lash

[Ludovic Courtès]

Hi,

Ricardo Wurmus  skribis:

> on a modern Guix System with Gnome we’re pulling in Python 2.  That’s
> because gtk uses lash, and lash (last commit was 14 years ago) comes
> with Python bindings — for Python 2.
>
> I’d like to propose one of the following steps:

s/steps/options/ ?

> - remove lash completely
> - build lash without Python bindings, removing python2
> - remove lash from fluidsynth, thereby removing it from the gtk closure
>
> What do you think?

I’m not familiar with Lash, but based on your description, I’d be in
favor of removing it entirely, and definitely for removing it from GTK.

Ludo’.

Re: RFC: libgit2 is slow/inefficient; switch to git command?

[Ludovic Courtès]

Hi,

Maxim Cournoyer  skribis:

> While attempting to bisect against the Linux kernel tree, the
> performance of libgit2 quickly became problematic, to the point where
> simply cloning the repo became a multiple hours affair, using upward to
> 3 GiB of RAM for the clone and indexing of the objects (!)

Did you confirm with a pure Guile-Git snippet that calls ‘clone’ that
this is the behavior observed?

> Given that:
>
> * the git CLI doesn't suffer from such poor performance;
> * This kind of performance problem has been known for years in libgit2
>   [0] with no fix in sight;

This reports talks about 5x wall-clock time, which is obviously not
great, but it doesn’t talk about memory usage, does it?

It talks about SHAttered though; that’s a key consideration to make sure
we’re doing an apples-to-apples comparison.

> * other projects such as Cargo support using the git CLI and that
>   projects are using it for that reason [1];

Should we follow Cargo’s lead for packaging as well?  :-)

> Would it make sense to switch to use the git command directly instead of
> calling into this libgit2 C library that ends up being slower?  It would
> provide a hefty speed-up when using 'guix refresh' or building new
> packages fetched from git without substitutes, or using 'git-checkout',
> etc.
>
> What do you think?

I think that’s not an option.  The level of integration we have in (guix
git), (guix channels), etc. is not achievable by shelling out to ‘git’.

"Philip McGrath"  skribis:

> Along those lines, there’s an implementation of clone/checkout in pure Racket 
> (for the package manager) that could probably be ported to Guile relatively 
> easily. I’d expect libgit2 to be faster for the things that it supports, but 
> the Racket implementation does support shallow checkout, so it might pay off 
> if that skips a lot of work.
>
> Code: 
> https://github.com/racket/racket/blob/master/racket/collects/net/git-checkout.rkt
> Docs: https://docs.racket-lang.org/net/git-checkout.html

That sounds like a worthy avenue; support for shallow clones would
already be an improvement.

> (More broadly, I haven’t investigated performance issues, but my basic 
> inclination would be toward improving libgit2 over running the git 
> executable.)

Same here.  The way I see it, we could gradually move bits of Guile-Git
to being pure Scheme.  So perhaps the first step would be to provide a
pure Scheme ‘clone’ based on the Racket code above?

Thanks,
Ludo’.

Re: RFC: libgit2 is slow/inefficient; switch to git command?

[Ludovic Courtès]

Hi,

Phil  skribis:

> In particular we were forced to make this change to our local guix build
> to ensure that guix behaved inline with git:
> https://github.com/guix-mirror/guix/commit/473954dd92bbb84693b6fa3f007752eb53c804db
>
> An explanation of why, was raised with libgit2:
> https://github.com/libgit2/libgit2/issues/6183
>
> The original guix-devel discussion here:
> https://lists.gnu.org/archive/html/guix-devel/2022-03/msg00021.html

I didn’t follow that but perhaps there’s something we should do in Guix
proper?  Maybe not exactly this change though, because it might be a
performance hit, but it’s worth discussing.

> This particular issue is somewhat niche - but it demonstrates well the
> danger of assuming the libgit2 and git behave in the same way!

Whichever implementation we use is going to behave differently from Git
in some cases (unless we use Git, that is).  But I think that’s okay, we
can smooth out issues.

Thanks,
Ludo’.

Re: Layout of ‘define-configuration’ records

[Ludovic Courtès]

Hi,

Maxim Cournoyer  skribis:

> Ludovic Courtès  writes:

[...]

 One last thing: placing ‘%location’ first can let us implement:

   (define (configuration-location config)
 (struct-ref config 0))
>>>
>>> Would this have worked?
>>>
>>> scheme@(gnu services mcron)> (define config (mcron-configuration))
>>> scheme@(gnu services mcron)> (struct-ref 0 config)
>>
>> You got the order wrong.  :-)
>
> Ah!  Thanks for pointing my silly mistake.  Then the argument would
> become... if it's good for define-configuration, it should have been
> good for define-record-type* the same (why the discrepancy?).

‘define-record-type*’ is generic; there’s no reason for it to add a
‘location’ field.

> After your new documentation in place to guide users to DTRT with
> regards to matching records, if you think %location should be the first
> field, then we should make it so in both instances, perhaps?

‘%location’ only appears in ‘define-configuration’; what did you mean by
“both instances”?

> Oops!  Another point to add to our future coding style guidelines :-).

In the end, I guess the lesson is that, indeed, not all the design
choices and rationales are properly documented.  That’ll always be the
case to a large extent though, so changes “close to the core” require
more careful review and discussion to fully understand the implications
of the change—it might look innocuous but have broader implications than
expected.

Thanks,
Ludo’.

Re: Fail ’guix time-machine’ on Nov 2021 because libgit2

[Development of GNU Guix and the GNU System distribution.]

> Well, is it specific to my machine?  Or is it reproducible?

I confirm I was able to reproduce. This is probably all I'm able to
help with here 

Wojtek


pgp19nfqwGYdf.pgp
Description: OpenPGP digital signature

Re: nss-certs@3.81: server certificate verification failed. CAfile: /gnu/store/…/ca-certificates.crt CRLfile: none

[zimoun]

Hi,

On Wed, 23 Nov 2022 at 18:18, Tobias Geerinckx-Rice  wrote:

> It's incorrectly sending an ISRG Root X1 certificate, which chains 
> to the expired DST Root CA X3.
>
> It should not send ISRG Root X1 at all.

Thanks for the explanations.  Reported upstream.

Cheers,
simon

Fail ’guix time-machine’ on Nov 2021 because libgit2

[zimoun]

Hi,

Well, I am looking for different past versions of Numpy, so I am trying
commit b9595a7659 from Nov 11, 2021,

gnu: python-numpy: Update to 1.21.3 and cleanup.

and I just run,

   guix time-machine --commit=b9595a7659 -- help

which returns an error:

--8<---cut here---start->8---
[...]

cannot build derivation 
`/gnu/store/ss0hz522h5w8bp82d4xz165318qw1yv5-profile.drv': 1 dependencies 
couldn't be built
guix time-machine: error: build of 
`/gnu/store/ss0hz522h5w8bp82d4xz165318qw1yv5-profile.drv' failed
--8<---cut here---end--->8---

and the failure is about libgit2. The log reads,

--8<---cut here---start->8---
[...]

refs::rename...
refs::revparse.F

  1) Failure:
refs::revparse::date 
[/tmp/guix-build-libgit2-1.1.0.drv-0/libgit2-1.1.0/tests/refs/revparse.c:31]
  Function call succeeded: error
  no error, expected non-zero return

error: in phase 'check': uncaught exception:
%exception #< program: "./libgit2_clar" arguments: ("-v" "-Q") 
exit-status: 1 term-signal: #f stop-signal: #f> 
phase `check' failed after 11.5 seconds
command "./libgit2_clar" "-v" "-Q" failed with status 1
--8<---cut here---end--->8---

Well, is it specific to my machine?  Or is it reproducible?


Cheers,
simon

Re: nss-certs@3.81: server certificate verification failed. CAfile: /gnu/store/…/ca-certificates.crt CRLfile: none

[Tobias Geerinckx-Rice]

Hi Simon,

zimoun 写道：

Is it a bug in Guix nss-certs side?  Or on Gitlab server side?


No Guix bug, the server is misconfigured.

It's incorrectly sending an ISRG Root X1 certificate, which chains 
to the expired DST Root CA X3.


It should not send ISRG Root X1 at all.

Kind regards,

T G-R


signature.asc
Description: PGP signature

Re: issue tracking in git

[indieterminacy]

On 23-11-2022 15:19, Giovanni Biscuolo wrote:

[...]
I saw your «L'Union Qiuy Fait La Force» presentation at Ten Years of
Guix [1] and I have to admit I still have to "digest" it, because I
still do not understand the overall architecture (see below).



As I (probably) mentioned it tha talk Qiuy is bourne from the desire to 
form a notation that sits between semantic and linguistic groups and is 
simultaneously positioned in the central position of the keyboard.


Here is a mail covering some pertinent themes
https://list.orgmode.org/a24dc6635138897d3fe978509be3a5cb@libre.brussels/

The problem is not to see the conception from the perspective of 
architectures but more in terms of a discipline or something akin to 
thermodynamics.


In any case, I have done other talks:

Classic Gemini presentation (evaluating it from the perspective of 
complexity - using Guix package details to demonstrate relative 
complexity)

https://www.youtube.com/watch?v=zyTC4QWGCQg

Impressionist talk detailing the tools and formats from the perspective 
of syntaxes

https://archive.fosdem.org/2022/schedule/event/minimalsyntaxes/

I gave multiple other talks this year but they need uploading.
I shall keep you informed.


indieterminacy  writes:

[...]


FWIW, Ive been working on Gemini and issue trackers in parrallel to
Genenetwork.

Arun did such a great job with a minimalist setup that I thought it 
more

proper to create a bigger ladder (given the reach of all the domains
which Tissue provides(.

I have two main strands:

Firstly, I have been combining Gemtext's terse syntax with that of the
Emacs-Hyperbole format, Koutliner, as well as the
"recursive-modelling-language" I have been developing Qiuy.

https://git.sr.ht/~indieterminacy/1q20hqh_oqo_parsing_qiuynonical/

As a consequence, it has grown into something different and more
complex. I need to trim this, especially as the results of some 
sprints

but once I refactor it it shall be a lot more solid.

Secondly, I have been returning to Gemtext from the perspective of Git
diffs, with the idea to generate RDF perspectives one each revision 
per

file and then use RDF calls to resolve more complex queries.


RDF representations of diffs (commits?) so we can combine this 
knowledge

with others (represented in RDF) AFAIU is great: (open) linked data for
knowledge management

IMHO RDF is still a little bit underestimated :-D



Indeed!

Qiuy should have a bright future in relation to RDF (a lot of grunt work 
however)


Im still sophomore in this domain but Im wrapping up enough of my other 
things to wade into this properly.


I have been liasing with somebody with regards to doing RDF activity 
during Guix Days 2023, Brussels (early February) - come join us!



https://git.sr.ht/~indieterminacy/1q20twt_oq_parsing-commits_txr

I shall be folding the logic of the first tool into the second
(carefully). I need a bit more time to do this to be fully satisfied.


what about gNife?

https://git.sr.ht/~indieterminacy/5q50jq_oq_configuring_emacs
--8<---cut here---start->8---

gNife, an Emacs environment for high throughput issue-tracking and
knowledge-management - utilising GemText, Koutliner and Qiuy

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


Well spotted!

Ive positioned the Icebreaker architecture to have a strong interface 
end (Qiuy originated from packaging my complex Vim infrastructure).


It is integral to the project development but optional for users.


is it still relevant or do you plan to substitute it with the tools
listed above?



Its a gestalt thing, just another viewpoint of the same discipline.

It remains untouched given some brutal family traumas.
Since switching to a modern and more secure laptop I havent had the 
chance to overcome some niggles.
I plan to develop this over time, though I would prefer to refactor it 
all within Guix Home (as well as my whole setup with regards to system 
crafting).


There are a lot of cool things which the Qiuy annotations are capable of 
doing when twinned with Emacs-Hyperbole - search for them in that repo 
for ideas.



There are some other tools floating around my forge (concerning hash
trees for different interpreters and rdf from the perspective of 
project

management), its mainly in TXR, Gawk and eLisp (though I will be doing
more with respect to Guile for these areas over time).


Looking at the Icebreaker project descriptions:

1. https://nlnet.nl/project/Icebreaker/

2. https://portal.mozz.us/gemini/icebreaker.space

I can undertand the design principles of the tools you are developing
and I'm really impressed with the completeness of this approach with
knowledge management, unfortunately I miss the overall architecture and
some important detalils that allows me to completely understand how to
use (or try to contribute to, one day) this tools: do you plan to add
some more documentation soon?


The lack of documentation has been my greatest weakness of 

nss-certs@3.81: server certificate verification failed. CAfile: /gnu/store/…/ca-certificates.crt CRLfile: none

[zimoun]

Hi,

Well, using nss-certs@3.81, I get this failure,

--8<---cut here---start->8---
$ guix time-machine --commit=785fd09af0e161906e984944ddae363c384b66dd \
   -- show nss-certs | recsel -p version
version: 3.81

$ guix time-machine --commit=785fd09af0e161906e984944ddae363c384b66dd \
   -- shell -CN git nss-certs \
   -- git clone https://gitlab.in2p3.fr/reprovip/reprovip-guix nss-3.81
Cloning into 'nss-3.81'...
fatal: unable to access 'https://gitlab.in2p3.fr/reprovip/reprovip-guix/': 
server certificate verification failed. CAfile: 
/gnu/store/h51ffnnqqkydhvgmyd77fhswwcddlan9-profile/etc/ssl/certs/ca-certificates.crt
 CRLfile: none
--8<---cut here---end--->8---

but it does not happen when running nss-certs@3.71 instead,

--8<---cut here---start->8---
$ guix time-machine --commit=65cabb010e3388d10f9b25ec560bfcfab5f810d4 \
   -- show nss-certs | recsel -p version
version: 3.71

$ guix time-machine --commit=65cabb010e3388d10f9b25ec560bfcfab5f810d4 \
   -- shell -CN git nss-certs \
   -- git clone https://gitlab.in2p3.fr/reprovip/reprovip-guix nss-3.71
Cloning into 'nss-3.71'...
warning: redirecting to https://gitlab.in2p3.fr/reprovip/reprovip-guix.git/
remote: Enumerating objects: 303, done.
remote: Counting objects: 100% (303/303), done.
remote: Compressing objects: 100% (140/140), done.
remote: Total 352 (delta 110), reused 267 (delta 89), pack-reused 49
Receiving objects: 100% (352/352), 12.23 MiB | 22.01 MiB/s, done.
Resolving deltas: 100% (117/117), done.
--8<---cut here---end--->8---

Is it a bug in Guix nss-certs side?  Or on Gitlab server side?


Cheers,
simon

Re: issue tracking in git

[Giovanni Biscuolo]

Pjotr Prins  writes:

[...]

> We also have ci and cd based on our own system containers in Guix.
>
> => https://ci.genenetwork.org/
>
> It would be good to write a Guix blog about all this.

Yes: «How to leave useless forges and live happy» :-D

>> Please Arun is there a devel mailing list dedicated to tissue so we can
>> discuss details of the project?
>
> Sounds like an idea. Though in the spirit of tissue we might as well
> set up a repo.

Maybe a mailing-list is less intimidating for users (and MUAs have nicer
interfaces for this kind of communication workflows [1]), but I'll
follow the discussion "anywhere" you'll decide to go :-)

>> I'm not a Guile developer but I would like to help with testing and (the
>> lack of) documentation, if I can.
>> 
>> I'd also like to understand and possibly discuss the overall
>> architecture design of tissue, in particular compared to git-issue
>> internals [1]
>
> I did not know of that project, but it looks similar in concept. With
> gemini support you get some other interesting features. And then Arun
> has added powerful search.

yes, the xapian index is what I like most of tissue... but I'd prefer to
discuss such things in a proper official channel

> Also, when you see Jonathan's E-mail, we are not done building on
> this.

I'm just dreaming of you and Jonatan merging your projects for world
domination in knowledge and workflow management! B-)

>> Last but not least: what about to have tissue packaged [2] in Guix? :-D
>
> It is about time - and a package and system definition exists in a
> channel.

yes, please :-)

Thanks! Gio'


[1] and notmuch/xapian rules!

-- 
Giovanni Biscuolo

Xelera IT Infrastructures


signature.asc
Description: PGP signature

Re: FOSDEM 2023 - Declarative and Minimalistic Computing - Call for Participation

[Pjotr Prins]

Note you can submit a talk for our devroom! If you are unsure whether
it is suitable, just run it by me personally. Anything Guile or Guix
is of interest. We also want talks on Racket, Lua, C and Zig.

Pj.

On Sun, Nov 13, 2022 at 10:29:48PM +0200, Manolis Ragkousis wrote:
> We are excited to announce a devroom on Declarative and Minimalistic
> Computing at FOSDEM on 4th of February, 2023!
> 
> FOSDEM is one of the most important free software conferences and is
> hosted annually at Université libre de Bruxelles in Brussels,
> Belgium. This year FOSDEM will be a physical
> conference. Talks will be done in person and we will also have virtual
> talks!
> 
> We accept talks from languages that attempt to minimize use of hardware
> and software while trying to make systems simpler, more robust and more
> secure. If you are working on improving today's systems taking
> declarative/minimalistic approaches feel free to submit a talk
> proposal. Examples include the Scheme/Lisp family of programmings languages.
> In past editions, this devroom has received presentations from a varied
> number of language communities, including Forth, Guile, Lua, Nim, Racket,
> Raku and Tcl as well as several experimental projects that push minimalism
> in new directions.
> 
> Minimalism and declarative programming are two important topics for
> this devroom. Minimalism matters. Minimalism allows for smaller
> systems that take less resources and consume less energy. More
> importantly, free and open source minimalism allows for secure systems
> that are easy to understand. Declarative programming is a programming
> paradigm that expresses the logic of a computation without describing
> its control flow. Many languages that apply this style attempt to
> minimize or eliminate side effects by describing what the program must
> accomplish in terms of the problem domain, rather than describe how to
> accomplish it as a sequence of the programming language primitives.
> 
> Finally, in this year's virtual conference we will honour the late Professor
> [https://en.wikipedia.org/wiki/Dennis_Ritchie Dennis Ritchie] the creator of
> the C programming language and the Unix operating system. C was designed as
> a minimal language that reflects the underlying CPU architecture closely,
> i.e., a high-level assembler. C is very popular today and the Linux kernel
> is almost completely written in C. In this edition we will also invite
> speakers that are working on new projects and minimalistic languages in the
> spirit of C.
> 
> We want to invite you to submit a talk on declarative and minimalistic
> computing that fits that description. We are especially happy to
> receive talk submissions from members of groups underrepresented in
> free software.
> 
> If you have something you’d like to share with your fellow developers,
> please E-mail us! Talks considered for the devroom will have to
> be entered in
> 
>   - https://penta.fosdem.org/submission/FOSDEM23
> 
> The deadline for submission is December 3rd. If you have a FOSDEM
> pentabarf account from a previous year, please use that
> account. Otherwise add one on
> https://penta.fosdem.org/user/new_account. Reach out to
> pjotr.public...@thebird.nl or manolis...@gmail.com if you run into any
> trouble.
> 
> When submitting your talk make doubly sure to select "Declarative and
> Minimalistic Computing devroom" as track (if you don't we won't find
> it), and include the following information:
> 
>   * The title and subtitle of your talk
>   * A short abstract of one paragraph
>   * A longer description if you wish to do so
>   * Links to related websites/blogs etc
> 
> To see what a final talk looks like see
> 
>   https://archive.fosdem.org/2021/schedule/event/gnumes/
> 
> Let's make this a fun day!
> 
> = Organizers =
> 
> Pjotr Prins, Manolis Ragkousis, Jonhathan McHugh, Bonface Munyoki, Arun
> Isaac, Ludovic Courtès, Amirouche Boubekki,
> Hisham Muhammad, Jan Nieuwenhuizen, Ricardo Wurmus, Alex
> Sassmannshausen, William Byrd, Oliver Propst, Efraim Flashner, Julien
> Lepiller
> 
> = Code of conduct =
> 
>   - https://fosdem.org/2023/practical/conduct/
> 
> = Original proposal =
> 
>   - https://libreplanet.org/wiki/FOSDEM2023-devroom-proposal
> 
> = Important dates: =
> 
>   - Dec 3rd 2022:  submission deadline for talk proposals
>   - Dec 15th 2022:  announcement of the final schedule
>   - Feb  4th 2023:  FOSDEM!
> 
> https://libreplanet.org/wiki/FOSDEM2023-devroom-declarative-and-minimalistic-computing-cfp

Re: issue tracking in git

[Giovanni Biscuolo]

Hello Jonathan,

nice to read you!

I saw your «L'Union Qiuy Fait La Force» presentation at Ten Years of
Guix [1] and I have to admit I still have to "digest" it, because I
still do not understand the overall architecture (see below).

indieterminacy  writes:

[...]

> FWIW, Ive been working on Gemini and issue trackers in parrallel to 
> Genenetwork.
>
> Arun did such a great job with a minimalist setup that I thought it more 
> proper to create a bigger ladder (given the reach of all the domains 
> which Tissue provides(.
>
> I have two main strands:
>
> Firstly, I have been combining Gemtext's terse syntax with that of the 
> Emacs-Hyperbole format, Koutliner, as well as the 
> "recursive-modelling-language" I have been developing Qiuy.
>
> https://git.sr.ht/~indieterminacy/1q20hqh_oqo_parsing_qiuynonical/
>
> As a consequence, it has grown into something different and more 
> complex. I need to trim this, especially as the results of some sprints 
> but once I refactor it it shall be a lot more solid.
>
> Secondly, I have been returning to Gemtext from the perspective of Git 
> diffs, with the idea to generate RDF perspectives one each revision per 
> file and then use RDF calls to resolve more complex queries.

RDF representations of diffs (commits?) so we can combine this knowledge
with others (represented in RDF) AFAIU is great: (open) linked data for
knowledge management

IMHO RDF is still a little bit underestimated :-D

> https://git.sr.ht/~indieterminacy/1q20twt_oq_parsing-commits_txr
>
> I shall be folding the logic of the first tool into the second 
> (carefully). I need a bit more time to do this to be fully satisfied.

what about gNife?

https://git.sr.ht/~indieterminacy/5q50jq_oq_configuring_emacs
--8<---cut here---start->8---

gNife, an Emacs environment for high throughput issue-tracking and
knowledge-management - utilising GemText, Koutliner and Qiuy

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

is it still relevant or do you plan to substitute it with the tools
listed above?

> There are some other tools floating around my forge (concerning hash 
> trees for different interpreters and rdf from the perspective of project 
> management), its mainly in TXR, Gawk and eLisp (though I will be doing 
> more with respect to Guile for these areas over time).

Looking at the Icebreaker project descriptions:

1. https://nlnet.nl/project/Icebreaker/

2. https://portal.mozz.us/gemini/icebreaker.space

I can undertand the design principles of the tools you are developing
and I'm really impressed with the completeness of this approach with
knowledge management, unfortunately I miss the overall architecture and
some important detalils that allows me to completely understand how to
use (or try to contribute to, one day) this tools: do you plan to add
some more documentation soon?

Happy hacking! Gio'

>
> Kind regards,
>
>
> -- 
> Jonathan McHugh
> indieterminacy@libre.brussels


[1] https://10years.guix.gnu.org/video/l-union-qiuy-fait-la-force/

-- 
Giovanni Biscuolo

Xelera IT Infrastructures


signature.asc
Description: PGP signature

Re: issue tracking in git

[Pjotr Prins]

On Wed, Nov 23, 2022 at 11:29:48AM +0100, Giovanni Biscuolo wrote:
> Homepage is https://tissue.systemreboot.net/
> 
> Wow!  Very interesting project, it deserves more visibility! (why did I
> miss its existance?!? :-O )

Ah well. We have just been using it and building it up over the last
year :). We wanted to get away from github issue trackers and that was
rather successful. All you need is a git repo and a guix package.

We also have ci and cd based on our own system containers in Guix.

=> https://ci.genenetwork.org/

It would be good to write a Guix blog about all this.

> Please Arun is there a devel mailing list dedicated to tissue so we can
> discuss details of the project?

Sounds like an idea. Though in the spirit of tissue we might as well
set up a repo.

> I'm not a Guile developer but I would like to help with testing and (the
> lack of) documentation, if I can.
> 
> I'd also like to understand and possibly discuss the overall
> architecture design of tissue, in particular compared to git-issue
> internals [1]

I did not know of that project, but it looks similar in concept. With
gemini support you get some other interesting features. And then Arun
has added powerful search. Also, when you see Jonathan's E-mail, we
are not done building on this.

> Last but not least: what about to have tissue packaged [2] in Guix? :-D

It is about time - and a package and system definition exists in a
channel.

Pj.

Re: foreign-distro?

[Development of GNU Guix and the GNU System distribution.]

Hi all,

Sorry to tell this - I don't think something like this would be even
possible to implement :/

AFAIK package definition fields like `(inputs)` don't just describe how
the package gets installed. They affect the actual build. So if we
really wanted this feature, we'd need to build 2 separate variants of a
package - one for Guix system and one for foreign distros.

In addition to looking like an overkill, such separate build variants
could also require changes to existing utilities like `guix copy`.

Besides all this, It it not that easy to determine whether Guix is
running under a foreign distro. One idea would be to check whether the
currently-running init system is Shepherd. But what if the user is
running Guix commands inside a Guix system chroot? The Shepherd process
is not going to be visible in such case

Wojtek

-- (sig_start)
website: https://koszko.org/koszko.html
PGP: https://koszko.org/key.gpg
fingerprint: E972 7060 E3C5 637C 8A4F  4B42 4BC5 221C 5A79 FD1A

Meet Kraków saints!   #18: blessed Józef Kowalski
Poznaj świętych krakowskich!  #18: błogosławiony Józef Kowalski
https://pl.wikipedia.org/wiki/Józef_Kowalski_(duchowny)
-- (sig_end)


On Wed, 23 Nov 2022 18:36:49 +0800
Zhu Zihao  wrote:

> If you want to left the choice to user. You can just don't patch it. Or
> you can always patch it because user can still use package transformer
> to specify a custom ffmpeg.
> 
> 
> jgart  writes:
> 
> > Does Guix have a declarative Guix API way of knowing if it is installing
> > a package into foreign distro versus Guix System?
> >
> > I'm thinking of a function like `foreign-distro?`:
> >
> > ```
> > (define-public peek
> >   (package
> >(name "peek")
> >...
> > (inputs 
> >   `(,@(if (foreign-distro?) `(("ffmpeg" ,ffmpeg)) '(
> > ```
> >
> > The above includes ffmpeg in the inputs only if installing peek on a
> > foreign distro. It could additionally patch the ffmpeg executable in
> > a peek package phases if foreign-distro? returns #t.
> >
> > WDYT  
> 
> 




pgp1TxjUpspMU.pgp
Description: OpenPGP digital signature

Re: issue tracking in git

[indieterminacy]

Hi Giovanni,

On 23-11-2022 11:29, Giovanni Biscuolo wrote:



please are there updates about this initiative?


Yeah, issue tracker lives here:

=> https://issues.genenetwork.org/

The actual issues are in gemini format and can be served with a gemini
server. The HTML parser+renderer is written in Guile by Arun

=> https://git.systemreboot.net/tissue


Homepage is https://tissue.systemreboot.net/

Wow!  Very interesting project, it deserves more visibility! (why did I
miss its existance?!? :-O )

Any other tissue user in this mailing list?



FWIW, Ive been working on Gemini and issue trackers in parrallel to 
Genenetwork.


Arun did such a great job with a minimalist setup that I thought it more 
proper to create a bigger ladder (given the reach of all the domains 
which Tissue provides(.


I have two main strands:

Firstly, I have been combining Gemtext's terse syntax with that of the 
Emacs-Hyperbole format, Koutliner, as well as the 
"recursive-modelling-language" I have been developing Qiuy.


https://git.sr.ht/~indieterminacy/1q20hqh_oqo_parsing_qiuynonical/

As a consequence, it has grown into something different and more 
complex. I need to trim this, especially as the results of some sprints 
but once I refactor it it shall be a lot more solid.


Secondly, I have been returning to Gemtext from the perspective of Git 
diffs, with the idea to generate RDF perspectives one each revision per 
file and then use RDF calls to resolve more complex queries.


https://git.sr.ht/~indieterminacy/1q20twt_oq_parsing-commits_txr

I shall be folding the logic of the first tool into the second 
(carefully). I need a bit more time to do this to be fully satisfied.


There are some other tools floating around my forge (concerning hash 
trees for different interpreters and rdf from the perspective of project 
management), its mainly in TXR, Gawk and eLisp (though I will be doing 
more with respect to Guile for these areas over time).


Kind regards,


--
Jonathan McHugh
indieterminacy@libre.brussels

Re: foreign-distro?

[Zhu Zihao]

If you want to left the choice to user. You can just don't patch it. Or
you can always patch it because user can still use package transformer
to specify a custom ffmpeg.


jgart  writes:

> Does Guix have a declarative Guix API way of knowing if it is installing
> a package into foreign distro versus Guix System?
>
> I'm thinking of a function like `foreign-distro?`:
>
> ```
> (define-public peek
>   (package
>(name "peek")
>...
> (inputs 
>   `(,@(if (foreign-distro?) `(("ffmpeg" ,ffmpeg)) '(
> ```
>
> The above includes ffmpeg in the inputs only if installing peek on a
> foreign distro. It could additionally patch the ffmpeg executable in
> a peek package phases if foreign-distro? returns #t.
>
> WDYT


-- 
Retrieve my PGP public key:

  gpg --recv-keys B3EBC086AB0EBC0F45E0B4D433DB374BCEE4D9DC

Zihao


signature.asc
Description: PGP signature

Re: issue tracking in git

[Giovanni Biscuolo]

Hello Pjotr and Arun, 

thanks Pjotr for the information

Pjotr Prins  writes:

> On Tue, Nov 22, 2022 at 06:57:59PM +0100, Giovanni Biscuolo wrote:

[...]

>> please are there updates about this initiative?
>
> Yeah, issue tracker lives here: 
>
> => https://issues.genenetwork.org/
>
> The actual issues are in gemini format and can be served with a gemini
> server. The HTML parser+renderer is written in Guile by Arun
>
> => https://git.systemreboot.net/tissue

Homepage is https://tissue.systemreboot.net/

Wow!  Very interesting project, it deserves more visibility! (why did I
miss its existance?!? :-O )

Any other tissue user in this mailing list?

Please Arun is there a devel mailing list dedicated to tissue so we can
discuss details of the project?

I'm not a Guile developer but I would like to help with testing and (the
lack of) documentation, if I can.

I'd also like to understand and possibly discuss the overall
architecture design of tissue, in particular compared to git-issue
internals [1]

Last but not least: what about to have tissue packaged [2] in Guix? :-D

Thanks! Gio'

[1] https://github.com/dspinellis/git-issue#internals

[2] we could/sould add skribilo-latest in Guix

-- 
Giovanni Biscuolo

Xelera IT Infrastructures


signature.asc
Description: PGP signature

Re: RFC: libgit2 is slow/inefficient; switch to git command?

[zimoun]

Hi,

On Tue, 22 Nov 2022 at 21:15, Phil  wrote:

> Just to add mine too - libgit2 behaves differently to command-line git
> in ways which can make guix do unexpected things when caching clones in
> certain cases.  This has resulted in some hard to diagnose issues with
> using guix to build PRs for example.

[...]

> An explanation of why, was raised with libgit2:
> https://github.com/libgit2/libgit2/issues/6183

To avoid people to follow various links, this issue #6183 is another
manifestation of issue #3361 (still open since Aug 6, 2015).  Quoting:

Git has recently changed the refspec matching rules to allow
refspecs such as

refs/heads/o*:refs/remotes/heads/i*

We still perform checks using the old rules by which the glob
must always match a full path element.

https://github.com/libgit2/libgit2/issues/3361

However, pleas note that only 3 issues with the tag ’git compatibility’
are currently open [1]–well three when 2 are related.

1: 

Cheers,
simon