Re: (ice-9 base64)?

[Aleix Conchillo Flaqué]

On Thu, Aug 18, 2022 at 12:56 AM Maxime Devos 
wrote:

> Then, if I understood correctly, IMO I would say Guile should not really
> care about Guix's bundling/unbundling. That is, adding (ice-9 base64) (or
> however we want to call it... maybe (encoding base64) following Golang and
> Guile's (web ) module) should be totally independent of Guix. So, if we
> add (ice-9 base64) to Guile then Guix should figure out what to do with it,
> but it's Guix's concern not Guile's.
>
> It's not some Guix-specific quirk. It's the same for at least Debian. It
> benefits not only Guix itself but all users of the software:
>
Thanks, I understand the benefit now.

> [...] allows [...] to make transverse changes
> such as applying security updates for a given software package in a
> single place and have them affect the whole system—something that
> bundled copies prevent.
>
> ... that was written with Guix in mind, but it applies to every
> distribution and everyone.
>
> Besides, your goal appears to be to unbundle the base64 into a single
> location (as a module of Guile), if we do that I think we should go all the
> way -- just adding it to Guile increases bundling instead of decreasing
> bundling, only if the various upstreams are modified to unbundle and use
> the new location then the unbundling is completed.
>
I see... In my mind, initially, I was thinking the opposite. By adding it
to Guile, new projects will use the new base64 module and existing projects
will update whenever they want.

On 18-08-2022 02:09, Aleix Conchillo Flaqué wrote:
>
> About Guix's unbundling (maybe that's something that should go on Guix's
> mailing list),
>
> I don't see why, there's nothing to write about except "oops some packages
> are bundling base64, let's unbundle those", and for unbundling those, it
> seems more practical to write about that here on guile-devel. Also I
> noticed I sent some messages to guix-devel instead of guile-devel,
> correcting now.
>
> I don't think currently there's any unbundling for base64 modules or at
> least not in a package I maintain guile-jwt (guile-jwt bundles base64). And
> probably there's no unbundling because there's no canonical implementation?
> Even if there was a canonical implementation, how would that look like in
> Guix's guile-jwt package? What would the snippet actually do?
>
> Currently, it's not done yet, presumably for that reason and maybe also
> due to nobody having noticed it yet?
>
> How it would look like, for upstreams that refuse to unbundle or are
> unresponsive:
>
> #~(begin
> (delete-file "local/copy/of/base64.scm")
> [also remove it from the Makefile.am]
> (substitute* (find-files "." "\\.scm$")
>   (("(\\local base64 module\\)") "(gcrypt base64)")))
>
OK, I was imagining something like that. In this case do we assume (gcrypt
base64) is installed? Because some projects don't have a dependency on
guile-gcrypt.

> For responsive upstreams that do not mind these kind of improvements,
> there is a preference for submitting a patch upstream -- that way, everyone
> benefits, not only Guix.
>
So, what do you think would be the way to proceed in order to include a
base64 implementation in Guile itself?

For example:

1. Add (ice-9 base64) (or (encoding base64)) to Guile and let new projects
and existing projects to update with conditional module loading to support
old versions of Guile.
2. Do unbundling in Guix packages both for projects that have not updated
upstream and for projects in (1). The unbundling would be done by pointing
to Guix's (or guile-gcrypt) base64 implementation, or is there a way they
could point to Guile's implementation?

Does that make sense or am I still missing something (I'm about to catch a
cold so my brain is not working quite well this week)? Originally, I was
thinking only in (1).

Thanks!

Aleix

Re: Packaging DOS Games

[Liliana Marie Prikler]

Am Donnerstag, dem 18.08.2022 um 17:33 +0200 schrieb Tobias Platen:
> I recently found dosdefender-ld31, a public domain DOS game, designed
> to run in dosbox. To build you only need gnu make and a version of
> gcc that targets i386-gnu or i386-gnu-linux. 
In that case building a Guix package ought to be relatively simple. 
Just use gnu-build-system, delete 'bootstrap and 'configure as needed
and use #:system "i686-linux" – alternatively, you can match (%current-
system) to get the right one, see wine for an example.

Cheers

Packaging DOS Games

[Tobias Platen]

I recently found dosdefender-ld31, a public domain DOS game, designed
to run in dosbox. To build you only need gnu make and a version of gcc
that targets i386-gnu or i386-gnu-linux. 

Re: Building, packaging and updating Guix with confidence

[zimoun]

Hi Bengt,

On mar., 26 juil. 2022 at 03:09, Bengt Richter  wrote:

> I naively don't buy the rationale against a non-root guix daemon :)

For sure, we can imagine many other designs than the current implemented
one.  However, at one point or the other, “something with privileges” is
required, no?

I mean, consider that the user named Alice installs the package ’foo’
and the user named Bob installs the package ’foo’ too, then, to have a
shared store, “something” needs to know that ’foo’ is installed by Alice
*and* Bob.  I mean, the paths contained by the binaries need to be
hard-coded (for reproducibility), so a common location is required and
this common location requires special privileges to be manipulated.
Moreover, this “something” also requires some privileges to run isolated
environments (build, etc.),

Well, at the end, this “something” needs the same privileges as ’root’,
no?  I mean, it appears to me the simplest; especially to configure on
various foreign distros.

Pjotr wrote, some time ago, some explanations [1] for running Guix with
non-root daemon.

1: 


Cheers,
simon

Re: Building, packaging and updating Guix with confidence

[zimoun]

Hi Josselin,

Thank you for the clear explanations.

On mer., 06 juil. 2022 at 22:01, Josselin Poiret  wrote:

[...]

> What I personally think, is that we should rationalize the way we
> interact with Guix source: a running Guix should always be able to hold
> a reference to its source.  The guix package or future equivalent
> (ie. good for internal consumption) should always refer to that same
> source, but that will also require factoring the daemon (and extensions)
> out of the repository, so that the C code doesn't get compiled again on
> every unrelated commit.  Finally, and I think this is the most
> challenging one, we should try to keep the differences between a) and c)
> to the minimum, meaning that one way of building has to go.  This is a
> big change, conceptually and technically, and I understand that this
> might be way more complicated that we'd like, but I think this needs to
> be done at some point.

Now #53210 [1] is closed, it improves the situation, right?  Is it
enough for the C extension you are working on?

1: 


Cheers,
simon

Re: debbugs irritation Was: [WIP Patch] Adding an FHS container to guix shell

[zimoun]

Hi,

On Thu, 21 Jul 2022 at 22:22, Csepp  wrote:

> Mumi and Debbugs have different search interfaces and seem to use
> different ordering.

Hum, I am confused because from my understanding, there is one Debbugs
instance – which is quickly said some Perl scripts managing mailing
lists and thus implementing a bug tracker database.  This database is
then manipulated via SOAP-interface.

This Debbugs instance is out of the control of the Guix project, AFAIK.

On the top of this instance, various front-ends are implemented:

 + historical one running at: https://debbugs.gnu.org 
 + Mumi running at: https://issues.guix.gnu.org/
 + emacs-debbugs running locally

And even Debian folks provide many others, as python3-debianbts or
reportbug coming with the CLI tool bts, mailscripts, etc.

https://git.spwhitton.name/mailscripts/tree/

 
> IMHO these papercuts add up.  Browsing and cross-referencing issues and
> patches is way harder than it is with other forges.

Well, harder depends on the point of view. :-)

Indeed, you need more than just type bug#12345 to cross-link.  Using a
descent mailreader, it appears to me easy to have helper.  For instance,
using Emacs, I have a custom function [1] “M-x my/guix-issues“ which
adds to the kill-ring an URL.  Recently, Ricardo added Message-ID to
Mumi which helps too; using emacs-notmuch, just "ci” for stashing and
then pasting elsewhere.

1: 



About browsing, Mumi needs more love. :-)


> Not saying we need to switch, maybe it's easier to just add the missing
> functionality.  Or maybe it doesn't matter to anyone else.

Well, the GNU instance of Debbugs has many flaws.  But the project will
not switch from it, IMHO.  That’s why Mumi as front-end tries to improve
the situation by adding the missing functionalities.


Cheers,
simon

Re: (ice-9 base64)?

[Maxime Devos]

Then, if I understood correctly, IMO I would say Guile should not 
really care about Guix's bundling/unbundling. That is, adding (ice-9 
base64) (or however we want to call it... maybe (encoding base64) 
following Golang and Guile's (web ) module) should be totally 
independent of Guix. So, if we add (ice-9 base64) to Guile then Guix 
should figure out what to do with it, but it's Guix's concern not Guile's.


It's not some Guix-specific quirk. It's the same for at least Debian. It 
benefits not only Guix itself but all users of the software:



[...] allows [...] to make transverse changes
such as applying security updates for a given software package in a
single place and have them affect the whole system—something that
bundled copies prevent.
... that was written with Guix in mind, but it applies to every 
distribution and everyone.


Besides, your goal appears to be to unbundle the base64 into a single 
location (as a module of Guile), if we do that I think we should go all 
the way -- just adding it to Guile increases bundling instead of 
decreasing bundling, only if the various upstreams are modified to 
unbundle and use the new location then the unbundling is completed.


On 18-08-2022 02:09, Aleix Conchillo Flaqué wrote:
About Guix's unbundling (maybe that's something that should go on 
Guix's mailing list),
I don't see why, there's nothing to write about except "oops some 
packages are bundling base64, let's unbundle those", and for unbundling 
those, it seems more practical to write about that here on guile-devel. 
Also I noticed I sent some messages to guix-devel instead of 
guile-devel, correcting now.
I don't think currently there's any unbundling for base64 modules or 
at least not in a package I maintain guile-jwt (guile-jwt bundles 
base64). And probably there's no unbundling because there's no 
canonical implementation? Even if there was a canonical 
implementation, how would that look like in Guix's guile-jwt package? 
What would the snippet actually do?
Currently, it's not done yet, presumably for that reason and maybe also 
due to nobody having noticed it yet?


How it would look like, for upstreams that refuse to unbundle or are 
unresponsive:


#~(begin
    (delete-file "local/copy/of/base64.scm")
    [also remove it from the Makefile.am]
    (substitute* (find-files "." "\\.scm$")
  (("(\\local base64 module\\)") "(gcrypt base64)")))

For responsive upstreams that do not mind these kind of improvements, 
there is a preference for submitting a patch upstream -- that way, 
everyone benefits, not only Guix.


Greetings,
Maxime.



OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature