Re: (ice-9 base64)?
Thank you for the explanations Maxime!
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.
About Guix's unbundling (maybe that's something that should go on Guix's
mailing list), 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?
Thanks,
Aleix
On Wed, Aug 17, 2022 at 12:23 PM Maxime Devos
wrote:
>
> On 17-08-2022 18:22, Aleix Conchillo Flaqué wrote:
>
> Hi Maxime!
>
> On Tue, Aug 16, 2022 at 12:04 PM Maxime Devos
> wrote:
>
>>
>> On 16-08-2022 19:21, Aleix Conchillo Flaqué wrote:
>>
>>
>>
>> On Tue, Aug 16, 2022 at 9:59 AM Maxime Devos
>> wrote:
>>
>>>
>>> On 16-08-2022 18:10, Aleix Conchillo Flaqué wrote:
>>>
>>> Hi,
>>>
>>> In many projects I've been copying Göran Weinholt's base64
>>> implementation and I've also seen it in other projects, would it make sense
>>> to include it in Guile's standard library? [...]
>>>
>>> If we do this, we should contact the various other projects to make them
>>> use (ice-9 base64).
>>>
>>
>> I think they could switch whenever they want (i.e. whenever this was
>> added to Guile) or even not switch at all.
>>
>> Sure, but they can't switch if they don't know about it. And if they
>> don't know about it and hence don't switch, the proposal fails at its
>> purpose of unbundling base64. Besides, we need them to switch (see Guix
>> no-bundling policy and the reasons behind it) -- if upstream refuses to
>> unbundle, then in our locally modified version for Guix.
>>
>
> Forgive my ignorance, but what do you mean by unbundling? I'm not familiar
> with Guix at all, well, just conceptually and for trying a few commands
> years ago.
>
> Sometimes the source code of a package contains a copy of a dependency.
> This is called 'bundling'. 'Unbundling' is the act of undoing the
> 'bundling', this is often done by cleaning up the source code (with what we
> call a 'snippet' in Guix: (snippet #~(delete-file-recursively
> "googletest"))) and setting some configuration flags
> ("-DUSE_SYSTEM_GOOGLETEST=yes" or such).
>
> For example, in Guix we occasionally encounter a bundled "googletest" (a
> test framework).
>
> In this case, we are kind of (un)bundling the base64 module, though it's
> not _exactly_ (un)bundling because, AFAIK, there is canonical upstream
> location for the base64 module to replace things with. Still seems pretty
> close to me.
>
> Upsides of unbundling, as mentioned in '(guix)Submitting Patches':
>
> Sometimes, packages include copies of the source code of their
> dependencies as a convenience for users. However, as a
> distribution, we want to make sure that such packages end up using
> the copy we already have in the distribution, if there is one.
> This improves resource usage (the dependency is built and stored
> only once), and allows the distribution 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.
>
> Another benefit: reviewing for absence of malware is less work when
> there's only a single copy to review, though I suppose that in this case
> the module is so small the reviewing benefit is minimal.
>
> Whether we simply replace (guix base64) by (gcrypt base64) depends on how
>>> old (gcrypt base64) is compared to the earliest 'supported' Guix for
>>> pull/time-travel, but even if it is not present in the old gcrypt, we can
>>> work-around that (we have a 'fake-gcrypt-hash' in build-aux/build-self.scm,
>>> so we can easily have a (define gcrypt-base64 [some copy])). Or simply
>>> update the local guile-gcrypt in buid-aux/build-self.scm.
>>>
>> guile-gcrypt base64 is pretty new with the patch above (but no release
>> after that), I have no idea if Guix has added anything else.
>>
>> base64 is available in at least 0.3.0, which is packaged in Debian
>> bullseye (which is considered "stable"), so not too new, though we might
>> need to change build-aux/build-self.scm if 0.1.0 doesn't have base64. Guix
>> appears to have the pre-quoted-patch version, without changes of its own
>> except for a different module name.
>>
>
> One more time, forgive me, but what is build-aux/build-self.scm?
>
> It's an implementation detail of Guix, it's a file (from the new version,
> not the old) that is loaded by "guix pull" in the
Re: (ice-9 base64)?
On 17-08-2022 18:22, Aleix Conchillo Flaqué wrote:
Hi Maxime!
On Tue, Aug 16, 2022 at 12:04 PM Maxime Devos
wrote:
On 16-08-2022 19:21, Aleix Conchillo Flaqué wrote:
On Tue, Aug 16, 2022 at 9:59 AM Maxime Devos
wrote:
On 16-08-2022 18:10, Aleix Conchillo Flaqué wrote:
Hi,
In many projects I've been copying Göran Weinholt's base64
implementation and I've also seen it in other projects,
would it make sense to include it in Guile's standard
library? [...]
If we do this, we should contact the various other projects
to make them use (ice-9 base64).
I think they could switch whenever they want (i.e. whenever this
was added to Guile) or even not switch at all.
Sure, but they can't switch if they don't know about it. And if
they don't know about it and hence don't switch, the proposal
fails at its purpose of unbundling base64. Besides, we need them
to switch (see Guix no-bundling policy and the reasons behind it)
-- if upstream refuses to unbundle, then in our locally modified
version for Guix.
Forgive my ignorance, but what do you mean by unbundling? I'm not
familiar with Guix at all, well, just conceptually and for trying a
few commands years ago.
Sometimes the source code of a package contains a copy of a dependency.
This is called 'bundling'. 'Unbundling' is the act of undoing the
'bundling', this is often done by cleaning up the source code (with what
we call a 'snippet' in Guix: (snippet #~(delete-file-recursively
"googletest"))) and setting some configuration flags
("-DUSE_SYSTEM_GOOGLETEST=yes" or such).
For example, in Guix we occasionally encounter a bundled "googletest" (a
test framework).
In this case, we are kind of (un)bundling the base64 module, though it's
not _exactly_ (un)bundling because, AFAIK, there is canonical upstream
location for the base64 module to replace things with. Still seems
pretty close to me.
Upsides of unbundling, as mentioned in '(guix)Submitting Patches':
Sometimes, packages include copies of the source code of their
dependencies as a convenience for users. However, as a
distribution, we want to make sure that such packages end up using
the copy we already have in the distribution, if there is one.
This improves resource usage (the dependency is built and stored
only once), and allows the distribution 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.
Another benefit: reviewing for absence of malware is less work when
there's only a single copy to review, though I suppose that in this case
the module is so small the reviewing benefit is minimal.
Whether we simply replace (guix base64) by (gcrypt base64)
depends on how old (gcrypt base64) is compared to the
earliest 'supported' Guix for pull/time-travel, but even if
it is not present in the old gcrypt, we can work-around that
(we have a 'fake-gcrypt-hash' in build-aux/build-self.scm, so
we can easily have a (define gcrypt-base64 [some copy])). Or
simply update the local guile-gcrypt in buid-aux/build-self.scm.
guile-gcrypt base64 is pretty new with the patch above (but no
release after that), I have no idea if Guix has added anything else.
base64 is available in at least 0.3.0, which is packaged in Debian
bullseye (which is considered "stable"), so not too new, though we
might need to change build-aux/build-self.scm if 0.1.0 doesn't
have base64. Guix appears to have the pre-quoted-patch version,
without changes of its own except for a different module name.
One more time, forgive me, but what is build-aux/build-self.scm?
It's an implementation detail of Guix, it's a file (from the new
version, not the old) that is loaded by "guix pull" in the old Guix to
compile the new version of Guix.
OTOH a similar replacement can be done for (ice-9 base64),
but transitioning to (ice-9 base64) would take much longer,
at least until the various distributions are updated to a
Guile that has (ice-9 base64), whereas (gcrypt base64) could
be switched to immediately.
Maybe this could be handled by each project independently.
They wouldn't have to if the base64 module is put in (guile gcrypt).
And the last forgiveness... (guile gcrypt)?
Oops, that should have been guile-gcrypt -- it's a Guile package --
"guix show guile-gcrypt" / .
Greetings,
Maxime.
OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
Re: (ice-9 base64)?
Hi Maxime! On Tue, Aug 16, 2022 at 12:04 PM Maxime Devos wrote: > > On 16-08-2022 19:21, Aleix Conchillo Flaqué wrote: > > > > On Tue, Aug 16, 2022 at 9:59 AM Maxime Devos > wrote: > >> >> On 16-08-2022 18:10, Aleix Conchillo Flaqué wrote: >> >> Hi, >> >> In many projects I've been copying Göran Weinholt's base64 >> implementation and I've also seen it in other projects, would it make sense >> to include it in Guile's standard library? [...] >> >> If we do this, we should contact the various other projects to make them >> use (ice-9 base64). >> > > I think they could switch whenever they want (i.e. whenever this was added > to Guile) or even not switch at all. > > Sure, but they can't switch if they don't know about it. And if they don't > know about it and hence don't switch, the proposal fails at its purpose of > unbundling base64. Besides, we need them to switch (see Guix no-bundling > policy and the reasons behind it) -- if upstream refuses to unbundle, then > in our locally modified version for Guix. > Forgive my ignorance, but what do you mean by unbundling? I'm not familiar with Guix at all, well, just conceptually and for trying a few commands years ago. > > But you are right that this would cause a backward compatible problem, but > I guess that would depend on each project. Can we do conditional module > loading? I've done this in the past with Python... if we are in Python 2 > load this module, otherwise load this other one. So projects could do that. > > Yes, using resolve-module with #:ensure #f & module-ref. Or with syntax > tricks and (version), to decide things at compile-time. Still, if you do a > conditional module loading, you still need a fallback, and the fallback > would still be bundling. > Cool, thanks! Again, I need a description for unbundling :-(. > Whether we simply replace (guix base64) by (gcrypt base64) depends on how >> old (gcrypt base64) is compared to the earliest 'supported' Guix for >> pull/time-travel, but even if it is not present in the old gcrypt, we can >> work-around that (we have a 'fake-gcrypt-hash' in build-aux/build-self.scm, >> so we can easily have a (define gcrypt-base64 [some copy])). Or simply >> update the local guile-gcrypt in buid-aux/build-self.scm. >> > guile-gcrypt base64 is pretty new with the patch above (but no release > after that), I have no idea if Guix has added anything else. > > base64 is available in at least 0.3.0, which is packaged in Debian > bullseye (which is considered "stable"), so not too new, though we might > need to change build-aux/build-self.scm if 0.1.0 doesn't have base64. Guix > appears to have the pre-quoted-patch version, without changes of its own > except for a different module name. > One more time, forgive me, but what is build-aux/build-self.scm? > OTOH a similar replacement can be done for (ice-9 base64), but >> transitioning to (ice-9 base64) would take much longer, at least until the >> various distributions are updated to a Guile that has (ice-9 base64), >> whereas (gcrypt base64) could be switched to immediately. >> > Maybe this could be handled by each project independently. > > They wouldn't have to if the base64 module is put in (guile gcrypt). > > > And the last forgiveness... (guile gcrypt)? Aleix
Re: Who owns guix-mirror?
Hi Lars-Dominik, Lars-Dominik Braun 写道： you could also enable “temporary interaction limits”[1] in your org account, which applies to all of its repositories. It’s only valid up to 6 months, but maybe better than nothing…? It is! Thank you. I've set it to ‘collaborators’ and added a calendar reminder in 6 months. Kind regards, T G-R signature.asc Description: PGP signature
Re: Enabling tracing on a phase to debug?
Hi Maxim,
On Fri, 15 Jul 2022 at 15:53, Maxim Cournoyer wrote:
> I was toying with the idea to programatically enable tracing the
> execution of a single build phase to aid with debugging, and came up
> with this with the help of robin on #guix (thanks!)
Well, I am often annoyed when debugging a package and I usually use
“guix build -K” and then jump in /tmp/guix--XY. The most
annoying is to re-run all the previous phases when they are somehow
already available under /tmp/. And often, this re-run is just for
tweaking the recipe to have more context about the failure…
> --8<---cut here---start->8---
> @@ -4349,7 +4349,19 @@ (define-public vala
> (substitute* "valadoc/tests/libvaladoc\
> /tests-extra-environment.sh"
> (("export PKG_CONFIG_PATH=" m)
> -(string-append m "$PKG_CONFIG_PATH:"
> +(string-append m "$PKG_CONFIG_PATH:")
> +
> + (replace 'glib-or-gtk-wrap
> + (lambda args
> + (use-modules (system vm trace)
> + (system vm vm))
> + (call-with-vm
> + (lambda ()
> +(set-vm-engine! 'debug)
> +(call-with-trace
> + (lambda _
> +(apply (assoc-ref %standard-phases 'glib-or-gtk-wrap)
> + args))
> (native-inputs
> `(("bison" ,bison)
> ("dbus" ,dbus) ; for dbus tests
> --8<---cut here---end--->8---
…so maybe we could have something like that for a better tracing.
Maybe, we could imagine an option as “guix build --list-phases” and then
a kind of package transformation doing on-the-fly the “call-with-vm” –
available with an option as “guix build --trace=glib-or-gtk-wrap”.
> Unfortunately it doesn't cause any trace to be output. Is there
> something missing to the above incantation, perhaps?
Sadly, I do not know.
Cheers,
simon
Re: Who owns guix-mirror?
Hi, > Thanks :-) Keeps the PRs away, or at least you can't prove > otherwise. you could also enable “temporary interaction limits”[1] in your org account, which applies to all of its repositories. It’s only valid up to 6 months, but maybe better than nothing…? Cheers, Lars [1] https://github.com/settings/interaction_limits
