On Wed, Jan 24, 2024 at 11:40:20PM +, Wookey wrote:
> If it only done for security issues, rather than routinely, then that
> shouldn't be that much extra load (does anyone have any idea how much
> extra building we are talking about? Is it trivial, or huge?)
If we do those rebuilds in stable
Quoting Jeremy Bícha (2024-01-25 02:50:07)
> On Fri, Mar 3, 2023 at 5:58 PM Bastien Roucariès wrote:
> > Le vendredi 3 mars 2023, 22:35:24 UTC Jonas Smedegaard a écrit :
> > > Quoting Bastien Roucariès (2023-03-03 22:21:49)
> > > > Le lundi 27 février 2023, 12:11:27 UTC Jonas Smedegaard a écrit :
On Fri, Mar 3, 2023 at 5:58 PM Bastien Roucariès wrote:
> Le vendredi 3 mars 2023, 22:35:24 UTC Jonas Smedegaard a écrit :
> > Quoting Bastien Roucariès (2023-03-03 22:21:49)
> > > Le lundi 27 février 2023, 12:11:27 UTC Jonas Smedegaard a écrit :
> > > Hi jonas,
> > >
> > > I have just checked the
On 2024-01-24 13:29 +0100, Simon Josefsson wrote:
> Luca Boccassi writes:
>
> > There's always option B: recognize that the Rust/Go ecosystems are not
> > designed to be compatible with the Linux distributions model
Luca is quite right here. Ultimately this can only be fixed by these
ecosystems
On 2024-01-16 10:59 +0100, Simon Josefsson wrote:
> My naive approach on how to fix a security problem in package X which is
> statically embedded into other packages A, B, C, ... would be to rebuild
> the transitive closure of all packages that Build-Depends on X and
> publish a security update f
On Jan 24, Peter Pentchev wrote:
> This might be a minority, optimistic, rose-tinted-glasses kind of
> opinion, but I believe that the state of the Rust ecosystem today
> (I have no experience with the Go one) is quite similar to what Perl and
> Python modules were 25, 20, bah, even 15 years ago.
On Wed, Jan 24, 2024 at 06:30:02PM +, Alberto Garcia wrote:
> - Are packages that ship gobject-introspection files supposed to have
>in the relevant build dependencies (gir1.2-*-dev,
> gobject-introspection ?), or is the build profile handling this
> automatically?
This is not automati
[follow-ups should probably go to -project, but I'm not setting my
headers to try to force that]
At 2024-01-24T16:57:06+0100, Simon Josefsson wrote:
> One could equally well make the argument that distributors should care
> about the Go/Rust ecosystems, and make whatever changes needed in
> order
On Wed, Jan 24, 2024 at 01:01:34PM +, Luca Boccassi wrote:
> On Wed, 24 Jan 2024 at 12:26, Johannes Schauer Marin Rodrigues
> wrote:
> >
> > Hi,
> >
> > Quoting Luca Boccassi (2024-01-24 12:59:38)
> > > There's always option B: recognize that the Rust/Go ecosystems are not
> > > designed to be
As Johannes mentioned earlier in this thread, the first piece of practical
advice on nogir should be: if you don't know that you need to use it,
then perhaps you shouldn't. It's primarily aimed at breaking cycles,
and enabling buildability in lower-level packages during bootstrapping.
(Having said
On Wed, Jan 17, 2024 at 10:00:35PM +, Simon McVittie wrote:
> Here is the draft text that I added to the GObject-Introspection
> mini-policy in 1.78.1-11:
Hi, thanks for the explanation.
A couple of questions about this:
- Are packages that ship gobject-introspection files supposed to have
Package: wnpp
Severity: wishlist
Owner: Simon Josefsson
* Package name: cosign
Version : 2.2.2-1
Upstream Author : The Sigstore Authors
* URL : https://github.com/sigstore/cosign
* License : Apache-2.0
Programming Lang: Go
Description : Code signing and
Luca Boccassi writes:
> On Wed, 24 Jan 2024 at 13:34, Simon Josefsson wrote:
>>
>> Luca Boccassi writes:
>>
>> >> Having reflected a bit, and learned through my own experience and
>> >> others' insights [1] that Go Build-Depends are not transitive, I'd like
>> >> to update my proposal on how to
On Wed, 24 Jan 2024 at 13:34, Simon Josefsson wrote:
>
> Luca Boccassi writes:
>
> >> Having reflected a bit, and learned through my own experience and
> >> others' insights [1] that Go Build-Depends are not transitive, I'd like
> >> to update my proposal on how to handle a security bug in any Go
On 2024-01-24 13:26:49 +0100 (+0100), Johannes Schauer Marin Rodrigues wrote:
[...]
> how does that work for those applications that require rust, go
> and friends? Are you proposing that everything that needs them
> should be be distributed by a flatpak or similar mechanism
> instead?
>
> Just a
On 24/01/24 14:01, Luca Boccassi wrote:
how does that work for those applications that require rust, go and friends?
Are you proposing that everything that needs them should be be distributed by a
flatpak or similar mechanism instead?
Those applications are not shipped in the distribution. If s
On Wed, 24 Jan 2024 at 12:26, Johannes Schauer Marin Rodrigues
wrote:
>
> Hi,
>
> Quoting Luca Boccassi (2024-01-24 12:59:38)
> > There's always option B: recognize that the Rust/Go ecosystems are not
> > designed to be compatible with the Linux distributions model, and are
> > instead
> > design
On 24/01/24 5:59 pm, Simon Josefsson wrote:
Does anyone know of a shared library in a Debian package written in Go?
I've only encountered the vendored approach to ship Go libraries.
libgovarnam1 is shipped as a shared library
https://packages.debian.org/sid/amd64/libgovarnam1/filelist
Open
Luca Boccassi writes:
>> Having reflected a bit, and learned through my own experience and
>> others' insights [1] that Go Build-Depends are not transitive, I'd like
>> to update my proposal on how to handle a security bug in any Go/Rust/etc
>> package and the resulting package rebuilds:
>
> Ther
Hi,
Quoting Luca Boccassi (2024-01-24 12:59:38)
> There's always option B: recognize that the Rust/Go ecosystems are not
> designed to be compatible with the Linux distributions model, and are instead
> designed to be as convenient as possible for a _single_ application developer
> and its users -
On Wed, 24 Jan 2024 at 11:42, Simon Josefsson wrote:
>
> Simon Josefsson writes:
>
> >> > My naive approach on how to fix a security problem in package X
> >> > which is
> >> > statically embedded into other packages A, B, C, ... would be to
> >> > rebuild
> >> > the transitive closure of all pac
Package: wnpp
Severity: wishlist
Owner: Jonas Smedegaard
X-Debbugs-Cc: debian-devel@lists.debian.org
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
* Package name: iamb
Version : 0.0.8
Upstream Contact: Ulyssa
* URL : https://iamb.chat/
* License : Apache-2.
On 24/01/24 2:07 pm, Simon Josefsson wrote:
Yes, for a low-level Go package (e.g., golang-golang-x-net-dev), this
will mean rebuilding almost all of the Go packages in Debian and publish
them in a security advisory.
This algorithm can be optimized (i.e., reduce the number of packages to
publis
Simon Josefsson writes:
>> > My naive approach on how to fix a security problem in package X
>> > which is
>> > statically embedded into other packages A, B, C, ... would be to
>> > rebuild
>> > the transitive closure of all packages that Build-Depends on X and
>> > publish a security update for
24 matches
Mail list logo
