Mikel Olasagasti wrote:
> Go-SIG has raised a ticket with FESCo [1] to propose a significant
> shift in Fedora's packaging approach for Go dependencies: moving to
> vendoring/bundling by default. This would represent a major departure
> from our current guidelines [2].
I am opposed to this. Bundli
On Fri, Jan 31, 2025 at 11:58 AM Matthew Miller
wrote:
>
> On Fri, Jan 31, 2025 at 12:04:33AM +0100, Neal Gompa wrote:
> > Right, we need a way for the build system to count the number of times
> > a commit was built and export that as an rpm macro that we can use to
> > make the NVR unique.
>
> h
On Fri, Jan 31, 2025 at 12:04:33AM +0100, Neal Gompa wrote:
> Right, we need a way for the build system to count the number of times
> a commit was built and export that as an rpm macro that we can use to
> make the NVR unique.
https://discussion.fedoraproject.org/t/rfc-build-tag-in-rpms-nvr-nvrb/
On Thu, Jan 30, 2025 at 11:51 PM Kevin Fenzi wrote:
>
> On Thu, Jan 30, 2025 at 11:13:24PM +0100, Neal Gompa wrote:
> > On Thu, Jan 30, 2025 at 11:05 PM Kevin Fenzi wrote:
> > >
> > > On Wed, Jan 29, 2025 at 07:18:23AM -0500, Matthew Miller wrote:
> > > > On Tue, Jan 21, 2025 at 08:21:26AM -0500,
On Thu, Jan 30, 2025 at 11:13:24PM +0100, Neal Gompa wrote:
> On Thu, Jan 30, 2025 at 11:05 PM Kevin Fenzi wrote:
> >
> > On Wed, Jan 29, 2025 at 07:18:23AM -0500, Matthew Miller wrote:
> > > On Tue, Jan 21, 2025 at 08:21:26AM -0500, Neal Gompa wrote:
> > > > If Koschei could trigger non-scratch r
On Thu, Jan 30, 2025 at 11:05 PM Kevin Fenzi wrote:
>
> On Wed, Jan 29, 2025 at 07:18:23AM -0500, Matthew Miller wrote:
> > On Tue, Jan 21, 2025 at 08:21:26AM -0500, Neal Gompa wrote:
> > > If Koschei could trigger non-scratch rebuilds, that would go a long
> > > way toward this.
>
> Note that kos
On Wed, Jan 29, 2025 at 07:18:23AM -0500, Matthew Miller wrote:
> On Tue, Jan 21, 2025 at 08:21:26AM -0500, Neal Gompa wrote:
> > If Koschei could trigger non-scratch rebuilds, that would go a long
> > way toward this.
Note that koschei just rebuilds existing src.rpms in scratch builds.
Getting it
On Thu, Jan 30, 2025 at 11:31:33AM +0300, Benson Muite wrote:
> On Wed, Jan 29, 2025, at 3:56 PM, Matthew Miller wrote:
> > On Wed, Jan 22, 2025 at 09:51:28AM +, Daniel P. Berrangé wrote:
> > What do we gain from building, say, Inkscape ourselves — other than allowing
> > us to check the boxes
On Wed, Jan 29, 2025, at 3:56 PM, Matthew Miller wrote:
> On Wed, Jan 22, 2025 at 09:51:28AM +, Daniel P. Berrangé wrote:
>> While the ring idea as presented there didn't come to exist inside
>> Fedora as a community, I think we can see that concept has indeed
>> grown up outside Fedora.
>
> Ye
On Wed, Jan 22, 2025 at 09:51:28AM +, Daniel P. Berrangé wrote:
> While the ring idea as presented there didn't come to exist inside
> Fedora as a community, I think we can see that concept has indeed
> grown up outside Fedora.
Yes, 100%. This was already happening when I made the Rings propos
On Tue, Jan 21, 2025 at 02:13:02PM +, Zbigniew Jędrzejewski-Szmek wrote:
> At the fundamental level, such automation would effectively do two
> steps:
> 1. create a no-change commit like we do now,
> 2. push the commit and fire off a build.
>
> (I think we want to keep 1. unchanged. We need to
On Tue, Jan 21, 2025 at 08:21:26AM -0500, Neal Gompa wrote:
> If Koschei could trigger non-scratch rebuilds, that would go a long
> way toward this.
This is what draft builds are for, isn't it?
https://docs.pagure.org/koji/release_notes/release_notes_1.34/#draft-builds
--
Matthew Miller
Fedo
On Sun, Jan 26, 2025 at 1:03 AM Jan Drögehoff wrote:
>
> Fabio Valentini wrote:
> > On Fri, Jan 24, 2025 at 10:23 PM Jan Drögehoff sentrycraft...@gmail.com
> > wrote:
> > > I'm generally in favor of this, especially since it would establish a
> > > status quo that could benefit other languages w
Fabio Valentini wrote:
> On Fri, Jan 24, 2025 at 10:23 PM Jan Drögehoff sentrycraft...@gmail.com wrote:
> > I'm generally in favor of this, especially since it would establish a
> > status quo that could benefit other languages where the usual way of
> > dealing with dependencies is incompatible
On Fri, Jan 24, 2025 at 10:23 PM Jan Drögehoff wrote:
>
> I'm generally in favor of this, especially since it would establish a status
> quo that could benefit other languages where the usual way of dealing with
> dependencies is incompatible with distributions.
You are aware that 1) this reque
On Thu, Jan 23, 2025 at 12:32 AM Richard W.M. Jones wrote:
>
> I don't think supply chain security was really mentioned in the thread
> yet (apologies if it was - I only scanned it).
>
> There's a real danger that if we forgo responsibility for reviewing
> packages to another project, then someone
I don't think supply chain security was really mentioned in the thread
yet (apologies if it was - I only scanned it).
There's a real danger that if we forgo responsibility for reviewing
packages to another project, then someone can add a bad package to
that other project and it becomes a problem f
On Wed, Jan 22, 2025 at 01:32:55PM +, Daniel P. Berrangé wrote:
> On Wed, Jan 22, 2025 at 01:27:09PM +0100, Fabio Valentini wrote:
> > On Wed, Jan 22, 2025 at 10:52 AM Daniel P. Berrangé
> > wrote:
> > >
> > > An increasingly large part of the ecosystem is working and deploying
> > > a way th
On Wed, Jan 22, 2025 at 3:08 PM Jan Drögehoff wrote:
>
> Fabio Valentini wrote:
> > On Wed, Jan 22, 2025 at 10:52 AM Daniel P. Berrangé berra...@redhat.com
> > wrote:
> > > An increasingly large part of the ecosystem is working and deploying
> > > a way that Fedora (and derivative distros) are re
Fabio Valentini wrote:
> On Wed, Jan 22, 2025 at 10:52 AM Daniel P. Berrangé berra...@redhat.com wrote:
> > An increasingly large part of the ecosystem is working and deploying
> > a way that Fedora (and derivative distros) are relegated to only
> > delivering what's illustrated as Ring 1. This is
On Wed, Jan 22, 2025 at 01:27:09PM +0100, Fabio Valentini wrote:
> On Wed, Jan 22, 2025 at 10:52 AM Daniel P. Berrangé
> wrote:
> >
> > An increasingly large part of the ecosystem is working and deploying
> > a way that Fedora (and derivative distros) are relegated to only
> > delivering what's i
On Wed, Jan 22, 2025 at 10:52 AM Daniel P. Berrangé wrote:
>
> An increasingly large part of the ecosystem is working and deploying
> a way that Fedora (and derivative distros) are relegated to only
> delivering what's illustrated as Ring 1. This is especially the case
> in the CoreOS/SilverBlue s
On Wed, Jan 22, 2025 at 09:51:28AM +, Daniel P. Berrangé wrote:
> An increasingly large part of the ecosystem is working and deploying
> a way that Fedora (and derivative distros) are relegated to only
> delivering what's illustrated as Ring 1. This is especially the case
> in the CoreOS/Silver
On Tue, Jan 21, 2025 at 12:49:17PM +, Zbigniew Jędrzejewski-Szmek wrote:
> On Mon, Jan 20, 2025 at 04:24:28PM +0100, Miroslav Suchý wrote:
> > Dne 20. 01. 25 v 11:29 dop. Michael J Gruber napsal(a):
> > > There is a second point to that, and that is Fedora as a development
> > > platform (not j
On Tue, Jan 21, 2025 at 9:07 PM Zbigniew Jędrzejewski-Szmek
wrote:
>
> Consider https://kojipkgs.fedoraproject.org/mass-rebuild/f42-failures.html:
> there are 7 failed rust packages there. Part of the reason is that
> by not bundling we don't have a long tail of old versions stashed
> in other pro
On Tue, Jan 21, 2025 at 06:24:26PM -, Jan Drögehoff wrote:
> Fabio Valentini wrote:
> > On Tue, Jan 21, 2025 at 5:13 PM Jan Drögehoff sentrycraft...@gmail.com
> > wrote:
> > > What is a "reasonable" language ecosystem here?
> > > Rust sure isn't, I can see at least 6 (0.9, 0.11, 0.12, 0.13, 0.
On Tue, Jan 21, 2025 at 09:22:37AM -0500, Neal Gompa wrote:
> On Tue, Jan 21, 2025 at 9:14 AM Zbigniew Jędrzejewski-Szmek
> wrote:
> >
> > On Tue, Jan 21, 2025 at 02:09:51PM +0100, Fabio Valentini wrote:
> > > Workflow with non-vendored dependencies:
> > > - update library or backport fix
> > > -
On Tue, Jan 21, 2025 at 03:42:22PM +0100, Miroslav Suchý wrote:
> Dne 21. 01. 25 v 3:13 odp. Zbigniew Jędrzejewski-Szmek napsal(a):
> > At the fundamental level, such automation would effectively do two
> > steps:
> > 1. create a no-change commit like we do now,
> > 2. push the commit and fire off
Fabio Valentini wrote:
> On Tue, Jan 21, 2025 at 5:13 PM Jan Drögehoff sentrycraft...@gmail.com wrote:
> > What is a "reasonable" language ecosystem here?
> > Rust sure isn't, I can see at least 6 (0.9, 0.11, 0.12, 0.13, 0.14, 0.15)
> > versions of the rust-hashbrown package in Fedora 41 which all
On Tue, Jan 21, 2025 at 5:13 PM Jan Drögehoff wrote:
>
> What is a "reasonable" language ecosystem here?
> Rust sure isn't, I can see at least 6 (0.9, 0.11, 0.12, 0.13, 0.14, 0.15)
> versions of the rust-hashbrown package in Fedora 41 which all need to be
> maintained separately and if someone w
On 1/21/25 8:00 AM, Zbigniew Jędrzejewski-Szmek wrote:
On Mon, Jan 20, 2025 at 11:20:50AM +, Daniel P. Berrangé wrote:
I understand that these are challenges, and they are increasing because
there are so many upcoming ecosystems which build their own distribution
channels and tools, be it Go
Zbigniew Jędrzejewski-Szmek wrote:
> we should allow bundling for consistency, and I also disagree with the
> reasoning raised by other people that we must _not_ allow bundling because
> that'll create a slippery slope to use it everywhere.
Bundling has been done very conservatively up to this poi
On Tue, Jan 21, 2025 at 4:45 PM Maxwell G wrote:
>
> On 1/21/25 7:09 AM, Fabio Valentini wrote:
> >> But rebuilds can be automated. Generating patches for vendored
> >> dependencies may be possible to some extent (but of course the vendored
> >> package variants could have diverging versions). A
On 1/21/25 7:09 AM, Fabio Valentini wrote:
But rebuilds can be automated. Generating patches for vendored
dependencies may be possible to some extent (but of course the vendored
package variants could have diverging versions). And then you have to
integrate the patch somehow so that it is appli
On 1/20/25 1:02 AM, Mikel Olasagasti wrote:
Hi,
Go-SIG has raised a ticket with FESCo [1] to propose a significant
shift in Fedora's packaging approach for Go dependencies: moving to
vendoring/bundling by default. This would represent a major departure
from our current guidelines [2].
Given the
Dne 21. 01. 25 v 3:13 odp. Zbigniew Jędrzejewski-Szmek napsal(a):
At the fundamental level, such automation would effectively do two
steps:
1. create a no-change commit like we do now,
2. push the commit and fire off a build.
Packit team want to do this for some time. Unfortunately, it did not
On Tue, Jan 21, 2025 at 9:14 AM Zbigniew Jędrzejewski-Szmek
wrote:
>
> On Tue, Jan 21, 2025 at 02:09:51PM +0100, Fabio Valentini wrote:
> > Workflow with non-vendored dependencies:
> > - update library or backport fix
> > - submit rebuilds of dependent applications (with rpmautospec, those
> > are
On Tue, Jan 21, 2025 at 02:09:51PM +0100, Fabio Valentini wrote:
> Workflow with non-vendored dependencies:
> - update library or backport fix
> - submit rebuilds of dependent applications (with rpmautospec, those
> are no-change commits)
>
> Workflow with vendored dependencies:
> - check out appl
On Mon, Jan 20, 2025 at 11:20:50AM +, Daniel P. Berrangé wrote:
> > I understand that these are challenges, and they are increasing because
> > there are so many upcoming ecosystems which build their own distribution
> > channels and tools, be it Go, Rust, Julia, even Python to some degree
> >
On Tue, Jan 21, 2025 at 02:30:48PM +0100, Miroslav Suchý wrote:
> Dne 21. 01. 25 v 1:49 odp. Zbigniew Jędrzejewski-Szmek napsal(a):
> > Let's not try to revive this. The ring idea is very very dead. Nobody
> > ever provided any coherent specification of how it could work.
>
> And in the mean time,
On Tue, Jan 21, 2025 at 2:30 PM Stephen Smoogen wrote:
>
> 1. Koschei is under resourced and turning it on for every package would
> pretty much make it a 'why is nothing working in Fedora' like every other
> good idea we add to the build system.
> 2. Getting it resourced would require planning
Dne 21. 01. 25 v 1:49 odp. Zbigniew Jędrzejewski-Szmek napsal(a):
Let's not try to revive this. The ring idea is very very dead. Nobody
ever provided any coherent specification of how it could work.
And in the mean time, Copr grew up in outer ring of Fedora. :)
--
Miroslav Suchy, RHCA
Red Hat,
On Tue, 21 Jan 2025 at 08:16, Michael Catanzaro
wrote:
> On Tue, Jan 21 2025 at 05:13:07 AM -05:00:00, Neal Gompa
> wrote:
> > We know it's possible because this is how openSUSE works today. They
> > never schedule mass builds because they always happen automatically
> > with the right condition
On Tue, Jan 21, 2025 at 2:23 PM Michael Catanzaro wrote:
>
> On Tue, Jan 21 2025 at 05:13:07 AM -05:00:00, Neal Gompa
> wrote:
> > We know it's possible because this is how openSUSE works today. They
> > never schedule mass builds because they always happen automatically
> > with the right condit
On Tue, Jan 21, 2025 at 8:16 AM Michael Catanzaro wrote:
>
> On Tue, Jan 21 2025 at 05:13:07 AM -05:00:00, Neal Gompa
> wrote:
> > We know it's possible because this is how openSUSE works today. They
> > never schedule mass builds because they always happen automatically
> > with the right condit
On Tue, Jan 21 2025 at 05:13:07 AM -05:00:00, Neal Gompa
wrote:
We know it's possible because this is how openSUSE works today. They
never schedule mass builds because they always happen automatically
with the right conditions, so it's a non-event. This is the direction
we should be going, but b
On Tue, Jan 21, 2025 at 05:13:07AM -0500, Neal Gompa wrote:
> On Tue, Jan 21, 2025 at 4:58 AM Florian Weimer wrote:
> > * Gerd Hoffmann:
> > > Note that in the go/rust world the unbundling does *not* make security
> > > updates much easier. Due to the static linkling it is not enough to
> > > upd
On Tue, Jan 21, 2025 at 11:08 AM Florian Weimer wrote:
>
> * Gerd Hoffmann:
>
> >> We would also need to consider what our committement is to security
> >> updates when apps are bundling stuff, as the same reasons that make
> >> unbundling huard, also make fixing security issues hard.
> >
> > Note
On Mon, Jan 20, 2025 at 04:24:28PM +0100, Miroslav Suchý wrote:
> Dne 20. 01. 25 v 11:29 dop. Michael J Gruber napsal(a):
> > There is a second point to that, and that is Fedora as a development
> > platform (not just as an "app" platform). If we expect developers to
> > install dependencies of the
On Tue, Jan 21, 2025 at 4:58 AM Florian Weimer wrote:
>
> * Gerd Hoffmann:
>
> >> We would also need to consider what our committement is to security
> >> updates when apps are bundling stuff, as the same reasons that make
> >> unbundling huard, also make fixing security issues hard.
> >
> > Note
* Gerd Hoffmann:
>> We would also need to consider what our committement is to security
>> updates when apps are bundling stuff, as the same reasons that make
>> unbundling huard, also make fixing security issues hard.
>
> Note that in the go/rust world the unbundling does *not* make security
> up
Hi,
> We would also need to consider what our committement is to security
> updates when apps are bundling stuff, as the same reasons that make
> unbundling huard, also make fixing security issues hard.
Note that in the go/rust world the unbundling does *not* make security
updates much easier.
On Mon, Jan 20, 2025, at 21:27, Fabio Valentini wrote:
> That said, reading other posts in this thread, I just don't think this
> is a good model for *all* "non-ELF" languages, and it shouldn't serve
> as a precedent.
> The Go ecosystem is a little bit special, in that there is no package
> manager
Hau idatzi du Fabio Valentini (decatho...@gmail.com) erabiltzaileak
(2025 urt. 20(a), al. (21:27)):
>
> I also don't understand the argument of "bundling would let us solve
> 200 broken packages caused by Go compiler changes faster". If the
> libraries fail to compile in standalone packages, then t
On Mon, Jan 20, 2025 at 8:02 AM Mikel Olasagasti wrote:
>
> Hi,
>
> Go-SIG has raised a ticket with FESCo [1] to propose a significant
> shift in Fedora's packaging approach for Go dependencies: moving to
> vendoring/bundling by default. This would represent a major departure
> from our current gu
On Mon, 20 Jan 2025 at 07:31, Florian Weimer wrote:
> * Mikel Olasagasti:
>
> > Go-SIG has raised a ticket with FESCo [1] to propose a significant
> > shift in Fedora's packaging approach for Go dependencies: moving to
> > vendoring/bundling by default. This would represent a major departure
> >
Mikel Olasagasti wrote:
> Hau idatzi du Michael J Gruber (m...@fedoraproject.org) erabiltzaileak
> (2025 urt. 20(a), al. (11:29)):
> > > On a related note, I recently highlighted how the introduction of
> > > Golang 1.24 has caused significant breakage in over 200 packages [3],
> > > an issue that
On Mon, Jan 20, 2025, at 6:24 PM, Miroslav Suchý wrote:
> Dne 20. 01. 25 v 11:29 dop. Michael J Gruber napsal(a):
>> There is a second point to that, and that is Fedora as a development
>> platform (not just as an "app" platform). If we expect developers to
>> install dependencies of their projec
Dne 20. 01. 25 v 11:29 dop. Michael J Gruber napsal(a):
There is a second point to that, and that is Fedora as a development
platform (not just as an "app" platform). If we expect developers to
install dependencies of their project via the ecosystem tools (pip, ...)
locally (envs, containers) and
Hau idatzi du Michael J Gruber (m...@fedoraproject.org) erabiltzaileak
(2025 urt. 20(a), al. (11:29)):
>
> Following the Go-SIG proposal would be the can-opener to deviate from
> our distribution model in general. I mean, if I can pull in a myriad of
> Go or Rust modules for my package to build (wi
These are all great points. I also second the Golang change. However,
just to clarify, Go and Rust both generate ELF binaries as well, but
Golang is not comparable to the some of the other examples mentioned. If
you have a vulnerability in a package in Python, for example, you can
deliver one s
* Mikel Olasagasti:
> Go-SIG has raised a ticket with FESCo [1] to propose a significant
> shift in Fedora's packaging approach for Go dependencies: moving to
> vendoring/bundling by default. This would represent a major departure
> from our current guidelines [2].
> [1] https://pagure.io/fesco/i
On Mon, Jan 20, 2025 at 11:29:55AM +0100, Michael J Gruber wrote:
> Mikel Olasagasti venit, vidit, dixit 2025-01-20 08:02:18:
> > Hi,
> >
> > Go-SIG has raised a ticket with FESCo [1] to propose a significant
> > shift in Fedora's packaging approach for Go dependencies: moving to
> > vendoring/bun
Mikel Olasagasti venit, vidit, dixit 2025-01-20 08:02:18:
> Hi,
>
> Go-SIG has raised a ticket with FESCo [1] to propose a significant
> shift in Fedora's packaging approach for Go dependencies: moving to
> vendoring/bundling by default. This would represent a major departure
> from our current gu
I'm generally in favor of this, especially since it would establish a status
quo that could benefit other languages where the usual way of dealing with
dependencies is incompatible with distributions.
--
___
devel mailing list -- devel@lists.fedoraproj
Hi,
Go-SIG has raised a ticket with FESCo [1] to propose a significant
shift in Fedora's packaging approach for Go dependencies: moving to
vendoring/bundling by default. This would represent a major departure
from our current guidelines [2].
Given the potential impact, it was suggested that we br
66 matches
Mail list logo
