Re: Docker 19.x eol

[zimoun]

Hi,

On Sun, 08 May 2022 at 17:33, Pier-Hugues Pellerin  wrote:

> Is there anyone working on updating the docker packages to 20.x I
> believe Guix ships with 19.x this is EOL if I remember it’s EOL. If
> someone working on it I will be happy to help.

Indeed, Docker 19.03.15 does not seem updated [1].  Well, I do not find
any EOL mention tough.  Anyway.

Last time I have checked, the upgrade was not straightforward but I hope
you will be luckier than me. ;-)


1: 


Cheers,
simon

Re: Packaging rust crates without compiling dependencies again for every dependent (wasting build time)

[Efraim Flashner]

On Sat, Apr 30, 2022 at 11:29:25AM +0200, Maxime Devos wrote:
> Hi various distributions packaging rust things (^),
> 
> Currently, most (all?) distributions seem to package ‘source-only
> crates’, which when ‘compiled’, just copy some source code to a
> location.  This works, but the downside is that if both a package X and
> a package Y depends on rust-Z, then rust-Z will effectively be compiled
> twice: when building X, but also when building Y.
> 
> This seems a waste of compilation time to me, so I've been writing a
> build tool ‘antioxidant’ (*) for the distribution Guix that avoids
> double compilation, at
> ).
> 
> To avoid the double compilation things, antioxidant calls the
> underlying rustc by itself instead of cargo, and it reads and
> interprets Cargo.toml by itself instead of letting cargo do that.
> 
> Currently, it's rather Guix-specific, but in principle it should be
> possible to turn it in some binary 'antioxidant' that could be used on
> other distributions as well if someone is interested in that, e.g.
> something like
> 
> $ # (not implemented yet!)
> $ antioxidant configure --prefix=$HOME/extra-software -Lcrate=/usr/lib/crates 
> -L/usr/lib -Lcrate=$HOME/extra-software/lib/crates --features=x,y,z
> $ antioxidant make
> $ antioxidant make check
> $ antioxidant make install DESTDIR=... # this does not install source code, 
> only the compiled crates
> 
> (*) A ‘build system’, in Guix terminology.
> 
> Currently, it can succesfully compile 'hexyl', 'sniffglue' and all
> their dependencies.  I'm working on addressing limitations that
> prevent antioxidant from compiling other binaries (currently trying
> to make 'agate' and all its dependencies compile).
> 
> Greetings,
> Maxime.
> 
> (^) If you are reading this from guix-devel@: some of the distributions I
> intend to contact have a no-crossposting policy, so I'm first sending this to
> guix-devel@, then sending some mails to individual distributions with a link
> to this e-mail.

This is really really cool! Thanks for sharing it.

I noticed that there are a number of crates that you remove
unconditionally, would it help if we patched them out of the crates that
are in Guix?

I'm glad you found a use for (target-64bit?), it seemed too useful to
not have in Guix :)

It took me less than 3 minutes to download and build all the sources for
the three packages! It looks to be faster than building the packages
straight, and with the benefit of incremental compilation.


-- 
Efraim Flashner  אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

Re: Packaging rust crates without compiling dependencies again for every dependent (wasting build time)

[Maxime Devos]

Efraim Flashner schreef op ma 09-05-2022 om 13:02 [+0300]:
> This is really really cool! Thanks for sharing it.
> 
> I noticed that there are a number of crates that you remove
> unconditionally, would it help if we patched them out of the crates
> that
> are in Guix?

This is for rust-winapi and the like?  Unfortunately IIUC, that's
currently not yet possible in general, because Cargo requires optional
dependencies to be available, see
.  Unless the
Cargo.toml are patched appropriately as well.

(I don't know if this applies to dev-dependencies as well, or only to
'dependencies' ...)

Greetings,
Maxime.


signature.asc
Description: This is a digitally signed message part

Re: public-inbox v1.7 update (was: Updating mumi on berlin)

[zimoun]

Hi Kyle,

Thanks for the details and explanations.


On Sun, 08 May 2022 at 00:41, Kyle Meyer  wrote:

> I'd eventually like to be able to follow list with lei via piem's
> interface, but things aren't there yet.

All in all, I would like that the public-inbox format would be indexed
by Notmuch [1] :-) Instead of rely on conversion forth and back.



Cheers,
simon

1: 

Re: GNU Mes 0.24 released

[indieterminacy]

Larry Doolittle  writes:

> Ludovic and friends -
>
> On Sun, May 08, 2022 at 12:34:47AM +0200, Ludovic Courtès wrote:
>> Jan Nieuwenhuizen  skribis:
>> > Mes has now been ported to M2-Planet and can be bootstrapped using
>> > stage0-posix[0], starting from the 357-byte hex0 binary of the
>> > bootstrap-seeds[1], as was promised at FOSDEM'21[2].
>> This is amazing… congrats to you & everyone involved!  You made it!  :-)
>
> +1
>
>> The common objection is: “you’re building from source but you’re not
>> gonna audit all that source code anyway, so why bother?”  [...]
>> Supply chain security is a spectrum and I think this achievement changes
>> what we can expect and demand.
>
> I've had this conversation before, any my analogy is to the
> three legs of a stool.  Bootstrapped toolchains, reproducible builds,
> and source-code audits.  Each one is arguably useless without the others,
> but taken together, you've actually accomplished something meaningful.
> Maybe I should also include "cryptographically signed artifact distribution"
> on that list.
>
>  - Larry

With works this sturdy then even two tool domains suffice as a fine and
versatile stepladder...

Great job everybody!


- Jonathan

Re: Mumi, public-inbox and tools

[Maxime Devos]

Ludovic Courtès schreef op zo 08-05-2022 om 00:52 [+0200]:
>    (info (N_ "downloaded ~a patch for issue #~a~%"
>  "downloaded ~a patches for issue #~a~%"

For i18n, could positional arguments be used here?


Greetings,
Maxime.


signature.asc
Description: This is a digitally signed message part

Re: Packaging rust-analyzer is not necessary.

[Maxime Devos]

John Soo schreef op za 26-03-2022 om 09:33 [-0700]:
> > Indeed, e.g. it would be nice to figure out how to eliminate
> > #:skip-
> > build?, replace #:cargo-inputs by regular inputs, figure out how to
> > stop having to package multiple versions of the same package.
> 
> My gut feeling is still that the functional package managers need to
> collaborate with the rust/cargo team. Rust itself just does not lend
> itself well to the model.  It is a shame since we share many of the
> same goals (reproducibility and reliability come to the top of mind).

(responding to an old post)

FWIW, it turns out that Rust actually works well with Guix, only Cargo
doesn't, see reccent threads about antioxidant-build-system.

Greetings,
Maxime.


signature.asc
Description: This is a digitally signed message part

RE: GNU Mes 0.24 released

[Orians, Jeremiah (DTMB)]

>> The common objection is: "you're building from source but you're not 
>> gonna audit all that source code anyway, so why bother?"  I think it's 
>> akin to security by obscurity.  That we collectively can and do fiddle 
>> with all this code makes a practical difference; that this is all 
>> transparent means that backdoors become harder to hide.
Well from root binaries to Gnu Mes (along with the extras such as sha256sum, 
ungz and untar) if printed on single sided paper at size 12 font would be only 
171 pages.
So not that hard after all after that you can leverage sha256sums and chains of 
trust to do the rest

> I saw a project a while ago with an interesting approach that looks very 
> interesting for tackling this problem: crowd-sourced, social code
> review:
> https://github.com/crev-dev/crev
Looks interesting

-Jeremiah

Re: Docker 19.x eol

[Pierre Langlois]

Hi there,

zimoun  writes:

> Hi,
>
> On Sun, 08 May 2022 at 17:33, Pier-Hugues Pellerin  wrote:
>
>> Is there anyone working on updating the docker packages to 20.x I
>> believe Guix ships with 19.x this is EOL if I remember it’s EOL. If
>> someone working on it I will be happy to help.
>
> Indeed, Docker 19.03.15 does not seem updated [1].  Well, I do not find
> any EOL mention tough.  Anyway.
>
> Last time I have checked, the upgrade was not straightforward but I hope
> you will be luckier than me. ;-)

I actually sent a series to update docker here: 
https://issues.guix.gnu.org/52790#7.

I haven't felt confident enough to push it yet, I think it needs a
review, but it should be pretty straight-forward.  I only tested it with
a my simple use-case of a single casual ubuntu container.

Hope this helps! I'll check if it needs a rebase actually.

Thanks,
Pierre


signature.asc
Description: PGP signature