On 25-02-07 22:13, Neel Chauhan wrote:
Hi,
I have a package awaiting review:
https://bugzilla.redhat.com/show_bug.cgi?id=2342141
Could someone please review this in exchange for me reviewing another
package?
I want to package Retro AIM Server but need this in first.
-Neel
Hi,
I'll try
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
Hi,
I have a package awaiting review:
https://bugzilla.redhat.com/show_bug.cgi?id=2342141
Could someone please review this in exchange for me reviewing another
package?
I want to package Retro AIM Server but need this in first.
-Neel
--
___
devel
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
us quo that could benefit other languages where the usual way of
> > > dealing with dependencies is incompatible with distributions.
> > > You are aware that 1) this request is explicitly targeting Golang
> > packages only, and 2) building with vendored dependencies is *alrea
pendencies is incompatible with distributions.
> > You are aware that 1) this request is explicitly targeting Golang
> packages only, and 2) building with vendored dependencies is *already*
> allowed (regardless of language ecosystem) when not doing so would
> place an undue mainten
ware that 1) this request is explicitly targeting Golang
packages only, and 2) building with vendored dependencies is *already*
allowed (regardless of language ecosystem) when not doing so would
place an undue maintenance burden on the packager? In particular, with
zig stuff, I doubt that it'
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
language tool" needs to learn how to compile libraries.
Heck, it even needs to detect if libraries are available on the system
and do other ./configure-like tasks. And sadly, this is usually the
moment where those "language specific tools" are not nice and shiny
anymore, and the job that they
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
big hand in all the packages within the ecosystem". If the critical
threshold of packagers active in the ecosystem is met, then this works
quite well.
Consider https://kojipkgs.fedoraproject.org/mass-rebuild/f42-failures.html:
there are 7 failed rust packages there. Part of the reason is that
by
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
the development phase used for migration
and retiring packages that may no longer fit within the updated
framework.
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 underscores the urgency of a
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
quires only *one* package to be
> changed, and applications that statically link the library can be
> rebuilt against the new version without requiring any spec changes.
(That whole message is worth rereading a few times. It is very
balanced and describes the tradeoffs.)
We have at least two
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
752 packages
to be installed to build the package of which 629 are golang-*-devel
packages.
For example, doctl's go.mod file defines 3 indirect dependencies in
the containerd modules (console, containerd, and log). However, for
Fedora, at least 16 containerd modules would need to be included
(
gt;
> If this proposal gains consensus, we could aim to implement the change
> as part of Fedora 43, with the development phase used for migration
> and retiring packages that may no longer fit within the updated
> framework.
>
> On a related note, I recently highlighted how the intro
d represent a major departure
> > from our current guidelines [2].
>
> > [1] https://pagure.io/fesco/issue/3330
> > [2]
> https://docs.fedoraproject.org/en-US/packaging-guidelines/Golang/#_bundled_or_unbundled
>
> What's the benefit of vendoring over a build system
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
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
ly: Do you intend to
> discourage/disallow "not bundling", or packaging dependencies?
Packages with minimal dependencies could still be maintained, but
those with a complex dependency chain would be discouraged. For
instance, if a package relies on golang-x-* modules and pkg/errors fo
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
ps://pagure.io/fesco/issue/3330
> [2]
> https://docs.fedoraproject.org/en-US/packaging-guidelines/Golang/#_bundled_or_unbundled
What's the benefit of vendoring over a build system that supports
offline builds against un-vendored dependencies?
I expect Konflux <https://konflu
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
with the development phase used for migration
> and retiring packages that may no longer fit within the updated
> framework.
How would packages "not fit"? By not bundling, i.e. by following our
packaging guidelines so far? To put it differently: Do you intend to
discourage/
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
tiring packages that may no longer fit within the updated
framework.
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 underscores the urgency of addressing these challenges.
We invite all Fedo
Wiki - https://fedoraproject.org/wiki/Changes/golang1.24
Discussion Thread -
https://discussion.fedoraproject.org/t/f42-change-proposal-golang-1-24-system-wide/139537
This is a proposed Change for Fedora Linux.
This document represents a proposed Change. As part of the Changes
process, proposals
Hello,
I want to take ownership of /golang-github-petermattis-goid/. It got
retied, because it was orphaned for 6+ weeks. The re-review bug is
https://bugzilla.redhat.com/show_bug.cgi?id=2326926
Best wishes
Kai
--
___
devel mailing list -- devel
Thank you Mikel, indeed, for keeping helm available in Fedora.
On 7/30/24 9:02 AM, Davide Cavalca wrote:
On 2024-07-27 09:03, Davide Cavalca wrote:
Hey folks,
I have orphaned golang-helm-3. The package currently fails to build
due to broken dependencies, and in general it's been p
On 2024-07-27 09:03, Davide Cavalca wrote:
Hey folks,
I have orphaned golang-helm-3. The package currently fails to build
due to broken dependencies, and in general it's been pretty painful to
keep in working shape. While it'd be nice to continue having Helm in
Fedora, I don'
I created a vendored version with different name to replace
golang-helm-3 if approved:
https://bugzilla.redhat.com/show_bug.cgi?id=2300201
Regards,
Mikel
Hau idatzi du Davide Cavalca (dcava...@fedoraproject.org)
erabiltzaileak (2024 uzt. 27(a), lr. (18:04)):
>
> Hey folks,
>
> I h
Hey folks,
I have orphaned golang-helm-3. The package currently fails to build due
to broken dependencies, and in general it's been pretty painful to keep
in working shape. While it'd be nice to continue having Helm in Fedora,
I don't think this is maintainable in its current
Wiki - https://fedoraproject.org/wiki/Changes/golang1.23
Discussion Thread -
https://discussion.fedoraproject.org/t/f41-change-proposal-golang-1-23-system-wide/118631
This is a proposed Change for Fedora Linux.
This document represents a proposed Change. As part of the Changes
process, proposals
On Tue Apr 2, 2024 at 17:16 +0200, Dan Čermák wrote:
> Hi Maxwell & Go SIG,
Hi Dan,
Thank you for reaching out!
> we have recently started working on introducing a bundled() provides
> generator for golang in openSUSE and found a very simple solution using
> the output of `go
Hi Maxwell & Go SIG,
we have recently started working on introducing a bundled() provides
generator for golang in openSUSE and found a very simple solution using
the output of `go version -m /path/to/binary` [1]
The solution is of course only that simple, because we build more or
less al
I have decided to orphan golang-github-apache-arrow.
--
Mike
:wq
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en
In order to preserve my energy as I maintain hugo and its multitude of
Go dependencies, I have decided to deactivate Hugo's deploy feature.
This means I can drop the need for golang-gocloud, which I will also
orphan.
The golang-gocloud package has been hard to maintain for some time. It
reli
ing Committee.
== Summary ==
Update of Go (golang package) to the upcoming version 1.22 in Fedora 40.
== Owner ==
* Name: [[User:alexsaezm| Alejandro Sáez Morollón]]
* Email: a...@redhat.com
== Detailed Description ==
Update of Go (golang package) to the upcoming version 1.22 in Fedora
40. Go 1.22
m trying to update go-task for some time now and consistently getting
> a build error/failure with no clear indication of what's happened:
>
> https://download.copr.fedorainfracloud.org/results/fuller/test-builds/fedora-rawhide-x86_64/06508072-golang-github-task/builder-live.log.gz
>
Oct 11, 2023, 14:02 by ful...@fedoraproject.org:
> I am trying to update go-task for some time now and consistently getting a
> build error/failure with no clear indication of what's happened:
> https://download.copr.fedorainfracloud.org/results/fuller/test-builds/fedora-rawhide-x8
I am trying to update go-task for some time now and consistently getting
a build error/failure with no clear indication of what's happened:
https://download.copr.fedorainfracloud.org/results/fuller/test-builds/fedora-rawhide-x86_64/06508072-golang-github-task/builder-live.log.gz
Is it pos
gt; back during the golang scramble after an unresponsive maintainer.
> I don't have the time or the interest (or the technical chops) to
> maintain them.
>
> Obviously these are important packages, so at this time I am announcing
> my intention to orphan them.
> Unless I hear f
Hi Mark,
Hau idatzi du Mark E. Fuller (ful...@fedoraproject.org) erabiltzaileak
(2023 urr. 7(a), lr. (12:22)):
>
> Hi all,
>
> I picked up a number of prometheus packages (see below) a few months
> back during the golang scramble after an unresponsive maintainer.
> I don'
Hi all,
I picked up a number of prometheus packages (see below) a few months
back during the golang scramble after an unresponsive maintainer.
I don't have the time or the interest (or the technical chops) to
maintain them.
Obviously these are important packages, so at this time
I'd like to offer to swap reviews to get golang-github-nats-io-jwt-2
https://bugzilla.redhat.com/show_bug.cgi?id=2237326 into Rawhide
We already have v1 and attempting to update that package in order to
upgrade the nats stack led to some breakage and headaches a few months ago
Thank
Hi Fabio, Robert-André,
Thank you for the explanation. It makes sense.
Golang has this uniqueness about libs that removes some of the shared
objects pros but I see there are other things at play.
Thank you,
Carlos.
On Thu, Jul 20, 2023 at 1:44 PM wrote:
> On 7/20/23 8:20 PM, Carlos Rodrig
On 7/20/23 8:20 PM, Carlos Rodriguez Fernandez
wrote:
Hi all,
I am interested in packaging some golang programs for Fedora (and EPEL), and I read through
the guidelines:
https://docs.fedoraproject.org/en-US/packaging-guidelines/Golang/
<https://docs.fedoraproject.org/en-US/packag
On Thu, Jul 20, 2023 at 8:22 PM Carlos Rodriguez Fernandez
wrote:
>
> Hi all,
>
> I am interested in packaging some golang programs for Fedora (and EPEL), and
> I read through the guidelines:
> https://docs.fedoraproject.org/en-US/packaging-guidelines/Golang/
>
> My qu
Hi all,
I am interested in packaging some golang programs for Fedora (and EPEL),
and I read through the guidelines:
https://docs.fedoraproject.org/en-US/packaging-guidelines/Golang/
My question is more about the reasoning for the recommended handling of
dependencies.
Other language platforms
On Fri, Jun 09, 2023 at 01:02:20PM +0200, Mikel Olasagasti wrote:
> Hi all,
>
> TL;DR: Would it be possible to untag
> golang-github-nats-io-jwt-2.4.1-1.fc39[1] from rawhide?
Yes, but... we really try and avoid that if it's gone out in a compose.
If it's gone out, use
Hi all,
TL;DR: Would it be possible to untag
golang-github-nats-io-jwt-2.4.1-1.fc39[1] from rawhide?
Some days ago golang-github-nats-io-jwt was bumped from 1.2.2 version
to 2.4.1. The new version doesn't provide
"golang(github.com/nats-io/jwt)" and is causing a dependency chain
I'll try to push this along - there's a build error that needs resolving
(but not at 2:30 AM)
see https://bugzilla.redhat.com/show_bug.cgi?id=2112130
Anyone from the golang list want to take a look?
-fuller
On 02/05/2023 19:25, Pat Riehecky wrote:
golang-github-prometheus-node-expo
golang-github-prometheus-node-exporter seems to be unmaintained at this point.
There are a few open CVEs that have been corrected upstream in the last year
but not made it down to the fedora package.
In Feb I opened a maintainer check ticket :
https://bugzilla.redhat.com/show_bug.cgi?id
I just orphaned golang-github-exoscale-egoscale. I'm no longer
interested in maintaining it. It's up for grabs for any interested
parties. Do note that currently it fails to install in F39 [0]
because one of its dependencies was retired [1], so that will need to
be sorted out t
elease}
Requires: golist
+Requires: blocker
%ifarch %{golang_arches}
Requires: golang
Provides: compiler(golang)
Provides: compiler(go-compiler) = 2
-Obsoletes: go-compilers-golang-compiler < %{version}-%{release}
+Obsoletes: go-compilers-golang-compiler < %{?epoch:%{epoch}:}%{vers
On Fri Feb 3, 2023 at 02:00 +0100, Miro Hrončok wrote:
> On 02. 02. 23 17:06, Ben Cotton wrote:
> > # Create a blank ''blocker'' package that Conflicts with the to be
> > removed packages.
> > # Create a new Copr with the blocker package in its default buildroot.
> > This will simulate the actual r
On 02. 02. 23 17:06, Ben Cotton wrote:
# Create a blank ''blocker'' package that Conflicts with the to be
removed packages.
# Create a new Copr with the blocker package in its default buildroot.
This will simulate the actual removal of these packages.
Was this verified to actually work that way
== Definitions ==
* ''library only source package'' -- a component/source package that
only contains noarch golang ''*-devel'' subpackages.
* ''binary subpackage'' -- an arched subpackage that contains go binaries.
* ''source
1 - 100 of 345 matches
Mail list logo
