Re: Going Inactive

[Brad Smith]

Hi Anthony

Glad to know you are still around. I am sure things will improve with
time. If you get a chance could you please move me to the admin group
in the kubernetes repo? I have a couple of clean up items to take care
of that need admin access.

Best regards

Brad

On Tue, Apr 25, 2023 at 8:17 PM Anthony Rabbito
 wrote:
>
> Hello All,
>
> While I've been inactive for a few months I wanted to get around to sending a 
> official announcement.
>
> As work continues to bear more load during these uncertain times and being a 
> full time student I'm currently biting off way more then I can chew. My goal 
> is to set aside some of my hobbies and involvement with Fedora to focus on 
> finishing school as fast as possible. I believe removing this burden will 
> improve my efficiency and mental health.
>
> I expect to be absent for about 8-12 months from today. I gave 
> https://docs.fedoraproject.org/en-US/fesco/Policy_for_inactive_packagers/ a 
> read and will try to stay somewhat active so I don't reach inactive status, 
> but in the rare case I do I'm willing to do the verification process when the 
> time comes.
>
> With all that being said my RHBZ has a few tasks that folks may be interested 
> in taking over: 
> https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&bug_status=VERIFIED&bug_status=ASSIGNED&bug_status=MODIFIED&bug_status=ON_DEV&bug_status=ON_QA&bug_status=RELEASE_PENDING&bug_status=POST&email1=hello%40anthonyrabbito.com&emailassigned_to1=1&emailcc1=1&emailreporter1=1&emailtype1=exact&list_id=13182385
>
> Since I don't post on the list often I would like to give a special shout-out 
> to the sway-sig for pushing the spin to the finish line for Fedora 38! It was 
> a great effort and I had tons of fun helping out in it's development.
>
> Thanks,
>
> --
> Anthony Rabbito
> ___
> 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-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it: 
> https://pagure.io/fedora-infrastructure/new_issue
___
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-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Going Inactive

[Brad Smith]

Thanks Anthony.  Nothing else at this time. Contribute at any time.

Brad

On Thu, Apr 27, 2023, 17:39 Anthony Rabbito 
wrote:

> Thanks Brad! I have done so. If there's any other similar issues feel free
> to reach out.
>
> Anthony
> ___
> 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-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
___
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-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Modules without modularity

[Brad Smith]

Is this thread on alternatives to alternatives also relevant:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/4AUQVBKLQBU6LIWZGVXN2CM3XTYQAKXZ/#4AUQVBKLQBU6LIWZGVXN2CM3XTYQAKXZ
?

Modules provide a mechanism for system level switches between
alternative versions as does Petr's  proposal (i.e. sudo required). As
others have remarked, there is also a need for a similar capability at
the user level (without sudo; e.g. environment modules) or even at the
shell level.

It would be nice if there were a compendium of all similar options for Fedora.

On Tue, Jun 13, 2023 at 12:21 PM Christopher  wrote:
>
> On Tue, Jun 13, 2023 at 12:33 PM Petr Pisar  wrote:
> >
> > Hello,
> >
> > as it seems that module build infrastructure isn't getting any better, as
> > modular YUM repositories are going to be deconfigured
> > ,
> > there is a time to look at different ways how to package alternative 
> > content.
> >

best regards

Brad
___
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-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Kubernetes and Fedora 36

[Brad Smith]

The upstream Kubernetes project released patch updates to all
supported versions of Kubernetes (1.23, 1.24, 1.25, 1.26).  With these
updates all supported versions are now built with go 1.19.

Fedora 36 provides go 1.18 and also provides Kubernetes 1.24. As of
Kubernetes 1.24.10, updates for Kubernetes 1.24.x can be found in COPR
at https://copr.fedorainfracloud.org/coprs/buckaroogeek/copy-k8s-1.24/.

I want to thank @alexaezm, Fedora go maintainer, for help and guidance
in getting these updates done.

Thanks

Brad
___
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-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Self Introduction: Dalton Hubble

[Brad Smith]

Welcome Dalton.  I really admire the work on Typhoon.  I still just
roll my own clusters in my home lab via ansible on top of fedora
(minimal) but am thinking about also using Fedora CoreOS. Typhoon
would be useful.  If you have any ideas or thoughts on the plain
Kubernetes rpms in Fedora please reach out.

Best Regards

Brad Smith

On Wed, Feb 22, 2023 at 9:19 PM Dalton Hubble  wrote:
>
> Hey folks,
>
> I'm an engineer working in the Go, cloud, and infrastructure space. I've been 
> a Linux user for a while, a Fedora user for the last ~8 years, and used to 
> work for CoreOS. I maintain a few open source Go libraries, maintain a 
> Kubernetes distro, and operate the AS207563 network. When I can, I enjoy 
> hiking and tinkering on my infra.
>
> I'm glad to get aquainted and help with containerd packaging.
>
> Dalton Hubble
> https://github.com/dghubble
> https://fosstodon.org/@dghubble
> ___
> 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-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it: 
> https://pagure.io/fedora-infrastructure/new_issue
___
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-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: fedpkg failed with : Signature verification failed.

[Brad Smith]

As shared bt @music on the Fedora build system matrix channel, this
happens after a new Fedora release is branched. You can install these
two packages to update your system to work correctly.

https://bodhi.fedoraproject.org/updates/FEDORA-2024-4a6de3d12d

https://bodhi.fedoraproject.org/updates/FEDORA-2024-49a775adbe

On Fri, Aug 16, 2024 at 6:12 AM Kenneth Goldman  wrote:
>
> I'm trying to build my package for Fedora 41 (an F41 VM on an F39 host if
> that matters).  Is it pulling in something from F42?
>
> The error is:
>
> fedpkg --release f41 mockbuild
> .
> [snip]
> .
> Transaction failed: Signature verification failed.
> PGP check for package "fedora-gpg-keys-42-0.1.noarch"
> (/var/lib/mock/fedora-rawhide-x86_64/root/var/cache/dnf/fedora-2d95c80a1fa0a
> 67d/packages/fedora-gpg-keys-42-0.1.noarch.rpm) from repo "fedora" has
> failed: Import of the key didn't help, wrong key?
>
> The longer log is:
>
> > fedpkg --release f41 mockbuild
> Using tss2.spec
> sources file doesn't exist. Source files download skipped.
>
> setting SOURCE_DATE_EPOCH=172368
> Wrote: /home/kgold/tssfedora/tss2-2.3.2-1.fc41.src.rpm
> INFO: mock.py version 5.6 starting (python version = 3.13.0, NVR =
> mock-5.6-3.fc41), args: /usr/libexec/mock/mock -r fedora-41-x86_64
> --resultdir /home/kgold/tssfedora/results_tss2/2.3.2/1.fc41 --rebuild
> /home/kgold/tssfedora/tss2-2.3.2-1.fc41.src.rpm
> Start(bootstrap): init plugins
> INFO: selinux enabled
> Finish(bootstrap): init plugins
> Start: init plugins
> INFO: selinux enabled
> Finish: init plugins
> INFO: Signal handler active
> Start: run
> INFO: Start(/home/kgold/tssfedora/tss2-2.3.2-1.fc41.src.rpm)
> Config(fedora-rawhide-x86_64)
> Start: clean chroot
> Finish: clean chroot
> Mock Version: 5.6
> INFO: Mock Version: 5.6
> Start(bootstrap): chroot init
> INFO: calling preinit hooks
> INFO: enabled root cache
> INFO: enabled package manager cache
> Start(bootstrap): cleaning package manager metadata
> Finish(bootstrap): cleaning package manager metadata
> INFO: Package manager dnf5 detected and used (fallback)
> Finish(bootstrap): chroot init
> Start: chroot init
> INFO: calling preinit hooks
> INFO: enabled root cache
> Start: unpacking root cache
> Finish: unpacking root cache
> INFO: enabled package manager cache
> Start: cleaning package manager metadata
> Finish: cleaning package manager metadata
> INFO: enabled HW Info plugin
> INFO: Package manager dnf5 detected and used (direct choice)
> INFO: Buildroot is handled by package management downloaded with a bootstrap
> image:
>   rpm-4.19.92-6.fc41.x86_64
>   rpm-sequoia-1.7.0-2.fc41.x86_64
>   dnf5-5.2.5.0-2.fc41.x86_64
>   dnf5-plugins-5.2.5.0-2.fc41.x86_64
> Start: dnf5 update
> Updating and loading repositories:
>  fedora 100% | 111.7 KiB/s |  24.2 KiB |
> 00m00s
> Repositories loaded.
> PackageArch   Version Repository
> Size
> Upgrading:
>  fedora-gpg-keys   noarch 42-0.1  fedora 126.4
> KiB
>replacing fedora-gpg-keys   noarch 41-0.3  fedora 126.4
> KiB
>  fedora-releasenoarch 42-0.1  fedora   0.0
> B
>replacing fedora-releasenoarch 41-0.20 fedora   0.0
> B
>  fedora-release-common noarch 42-0.1  fedora  19.4
> KiB
>replacing fedora-release-common noarch 41-0.20 fedora  19.4
> KiB
>  fedora-release-identity-basic noarch 42-0.1  fedora 694.0
> B
>replacing fedora-release-identity-basic noarch 41-0.20 fedora 694.0
> B
>  fedora-repos  noarch 42-0.1  fedora   4.9
> KiB
>replacing fedora-repos  noarch 41-0.3  fedora   4.9
> KiB
>  fedora-repos-rawhide  noarch 42-0.1  fedora   2.2
> KiB
>replacing fedora-repos-rawhide  noarch 41-0.3  fedora   2.2
> KiB
>
> Transaction Summary:
>  Upgrading: 6 packages
>  Replacing: 6 packages
>
> Total size of inbound packages is 200 KiB. Need to download 0 B.
> After this operation 0 B will be used (install 154 KiB, remove 154 KiB).
> [1/6] fedora-gpg-keys-0:42-0.1.noarch   100% |   0.0   B/s |   0.0   B |
> 00m00s
> >>> Already downloaded
> [2/6] fedora-release-0:42-0.1.noarch100% |   0.0   B/s |   0.0   B |
> 00m00s
> >>> Already downloaded
> [3/6] fedora-release-common-0:42-0.1.no 100% |   0.0   B/s |   0.0   B |
> 00m00s
> >>> Already downloaded
> [4/6] fedora-repos-0:42-0.1.noarch  100% |   0.0   B/s |   0.0   B |
> 00m00s
> >>> Already downloaded
> [5/6] fedora-release-identity-basic-0:4 100% |   0.0   B/s |   0.0   B |
> 00m00s
> >>> Already downloaded
> [6/6] fedora-repos-rawhide-0:42-0.1.noa 100% |   0.0   B/s |   0.0   B |
> 00m00s
> >>> Already downloaded
> 
> 
> [6/6] Total 100% |   0.0   B/s |   0.0   B |
> 00m00s
> Runnin

Re: fedpkg failed with : Signature verification failed.

[Brad Smith]

You should install the mock-core-config and distribution-gpg-keys rpms
for the version of Fedora that is running fedpkg. If I am reading your
first post correctly, you are using an F41 vm to run "fedpkg --release
f41 mockbuild".

distribution-gpg-keys-1.105-1.fc41 should already be in stable
according to Bohdi.
mock-core-configs-41.2 should be in stable soon according to
https://bodhi.fedoraproject.org/updates/FEDORA-2024-a27ffd7504.

best regards

Brad


>
> There was no change.  Questions:
>
> 1 - I applied this to the F39 host, not the F41 VM.  Was that right?
>
> 2 - The links are to .fc40.  Is there a similar patch for F39?
>
> 3 - Does it make sense that an F41 build would try to load 
> fedora-gpg-keys-0:42-0.1.noarch?
-- 
___
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-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: RPM packaging help

[Brad Smith]

On Sun, Aug 13, 2023 at 9:12 AM Robert-André Mauchin  wrote:
>

>
> I don't have an ETA on the K8S situation.
>

Please let me know if there is anything that can be done with the
kubernetes rpms to help.

Best regards

Brad
___
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-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: RPM packaging help

[Brad Smith]

On Sun, Aug 13, 2023 at 12:40 PM Maxwell G  wrote:
>
> > Please let me know if there is anything that can be done with the
> > kubernetes rpms to help.
>
> The kubernetes rpms are completely separate from the unbundled
> golang-k8s-* packages and use bundled dependencies as far as I know.
>

Thanks. I had assumed so but was not completely sure.

Best regards

Brad
___
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-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F40 Change Proposal: SQLAlchemy 2

[Brad Smith]

I had the same question. Then I noticed this pinned post in Fedora Discussions:

"We are experimenting 2 with using Fedora Discussion as part of the
Changes process. Change announcements (like the one you are reading
right now) will still be sent to the devel-announce mailing list, but
the conversation about each change will take place on Fedora
Discussion at Change Proposals - Fedora Discussion"

So a summary might be sufficient to attract interested readers to the
discussion?

best regards

On Mon, Aug 28, 2023 at 9:52 AM Vít Ondruch  wrote:
>
> Thank you for sharing this. However, I wonder why is just the summary
> shared?
>
>
> Vít
>
>
> Dne 24. 08. 23 v 11:46 Zbigniew Jędrzejewski-Szmek napsal(a):
> > == Summary ==
> > The python-sqlalchemy package is upgraded to major version 2. A
> > compatibility package python-sqlalchemy1.4 is added to the
> > distribution to cater for software which doesn’t yet use the new API,
> > this can be installed side-by-side. Other packages using SQLAlchemy
> > are identified and, if necessary, steps are taken to ensure they use
> > the correct major version package.
> >
> > See 
> > https://discussion.fedoraproject.org/t/f40-change-proposal-sqlalchemy-2/87805
> > for details and to reply.
> > ___
> > devel-announce mailing list -- devel-annou...@lists.fedoraproject.org
> > To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
> > Fedora Code of Conduct: 
> > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives: 
> > https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org
> > Do not reply to spam, report it: 
> > https://pagure.io/fedora-infrastructure/new_issue
> ___
> 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-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it: 
> https://pagure.io/fedora-infrastructure/new_issue
___
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-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Enabling GOPROXY and GOSUMDB in Fedora

[Brad Smith]

At a minimum, I recommend that the patch include the original values
for GOPROXY, GOSUMDB, and GOTOOLCHAIN as comments. This makes it
easier to change back to default values. At the moment, one has to
visit the relevant web pages.

I lean towards providing upstream defaults in this case with updated
content on the developer portal (and elsewhere?) with information on
why changing these values would be useful. I agree that the comments
in the thread are persuasive (for me).

best regards

Brad

On Tue, Dec 19, 2023 at 8:34 AM Alejandro Saez Morollon  wrote:
>
> Hi everyone.
>
>
> TL;DR: Remove a patch we ship in Go that disables GOPROXY and GOSUMDB and 
> follow upstream defaults, or keep it?
>
>
> Recently, I had a short conversation in a public forum about two Go features 
> that we modified in Fedora. GOPROXY and GOSUMDB. As I prepare the Fedora 40 
> and Go 1.22 proposal, it is a great time to discuss it.
>
>
> You can see the conversation here, I think they bring really good points that 
> we should consider:
>
> https://mas.to/@zekjur/111359951465906642
>
>
> So first, what are these variables?
>
> GOPROXY sets the server for fetching module-related information and 
> dependencies.
>
> GOSUMDB sets the checksum database URL to verify module downloads and ensure 
> their integrity during module resolution.
>
>
> You can read them more in detail here:
>
> https://go.dev/ref/mod#environment-variables
>
> https://go.dev/ref/mod#authenticating
>
> https://go.dev/ref/mod#module-proxy
>
>
> There are four approaches as I see this:
>
> Keep it the way it is right now.
>
> Remove the patch and follow upstream.
>
> Create a way to ensure the users know that that option can be changed and 
> leave one of the two previous options as default (by creating two packages, 
> one with the default setting and another that applies the patch).
>
> Have a GOPROXY service by Fedora.
>
>
> 1 and 2 are the easiest and most logical ones. 3rd is complex, and I'm not 
> sure it brings any value. 4th would be ideal, but that means maintaining a 
> service with all its costs and time.
>
>
> --
> ___
> 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-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it: 
> https://pagure.io/fedora-infrastructure/new_issue
--
___
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-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Enabling GOPROXY and GOSUMDB in Fedora

[Brad Smith]

Greetings -

On Wed, Dec 20, 2023 at 7:35 AM Maxwell G  wrote:
>

> Can someone clarify what they mean by this? The patch itself [1] makes
> it pretty clear what the original values are.

When I look at /usr/lib/golang/go.env I see:


[bgsmith@pico newversionprep (main *%)]$ more /usr/lib/golang/go.env
# This file contains the initial defaults for go command configuration.
# Values set by 'go env -w' and written to the user's go/env file
override these.
# The environment overrides everything else.

# Use the Go module mirror and checksum database by default.
# See https://proxy.golang.org for details.
GOPROXY=proxy.golang.org,direct
GOSUMDB=sum.golang.org

# Automatically download newer toolchains as directed by go.mod files.
# See https://go.dev/doc/toolchain for details.
GOTOOLCHAIN=auto
--

The go.env file does not, as far as I can tell, contain the original
values from upstream. Just the modified values. Unless I modified the
file and cannot recall doing so! My suggestion was to include the
original upstream settings as comments.

>  improving the user-facing documentation about why we do this and how to
> restore the original behavior. The Fedora Developer Portal (which really
> needs to be promoted more; it's a great resource!) documents [2] that we
> change GOPROXY and GOTOOLCHAIN, but it doesn't mention GOSUMDB, and it's
> lacking clear instructions about how to change the values back to
> defaults.

The updates to this developer portal page with gosumdb were made last
month but there has been a delay in publishing to production. Should
show up any day.

best regards
--
___
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-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Heads Up: Changes to Kubernetes RPM structure coming to Rawhide (F40)

[Brad Smith]

Early next week I will push Kubernetes v1.29 rpms to rawhide. There
are 2 important changes to be aware of.

First, this will replace Kubernetes v1.28 in rawhide and therefore in
Fedora 40. Future updates for Kubernetes 1.28 will be found in COPR at
https://copr.fedorainfracloud.org/coprs/buckaroogeek/copr-k8s-1.28/.
kubernetes v1.28 will not otherwise be available in Fedora
repositories. The versions of cri-o and cri-tools rpms will also be
similarly updated.

Second, the package structure for Kubernetes will change with v1.29.
The legacy packages are kubernetes-node (kubelet), kubernetes-kubeadm
(kubeadm), and kubernetes-client (kubectl), and kubernetes-master
(systemd units associated with kubernetes).

The new package structure in v1.29 includes: kubernetes (kubelet and
kubeadm), kubernetes-client (kubectl), and kubernetes-legacy-systemd
(legacy systemd units not needed in modern cluster installations).

There will be additional information forthcoming in a Community Blog
post and on the Kubernetes Quick Docs page
(https://docs.fedoraproject.org/en-US/quick-docs/using-kubernetes/).

Best regards

Brad
--
___
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-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: mock build for rawhide: Transaction failed: Signature verification failed.

[Brad Smith]

I had this problem too. There is a new version of mock and more-core-config
(not sure of name still getting first cup of coffee) in updates-testing
that has the fix.

On Tue, Feb 20, 2024, 04:32 Richard Shaw  wrote:

> For about a week I've been seeing this when trying to test build packages
> for rawhide locally:
>
> Transaction failed: Signature verification failed.
> PGP check for package "bash-5.2.26-3.fc40.x86_64"
> (/var/lib/mock/fedora-rawhide-x86_64/root/var/cache/dnf/fedora-2d95c80a1fa0a67d/packages/bash-5.2.26-3.fc40.x86_64.rpm)
> from repo "fedora" has failed: Import of the key didn't help, wrong key?
>
> I've already done a --scrub=all a few times to no avail.
>
> Anyone else seeing this?
>
> Thanks,
> Richard
> --
> ___
> 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-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
--
___
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-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: [INPUT REQUESTED] Re: F38 proposal: Node.js Repackaging (Self-Contained Change proposal)

[Brad Smith]

I have not used nodejs for development in quite a while so cannot
respond from an involved user perspective. Given that context, I
concur with Dan's reasoning and choices.

On a more meta note, Fedora has at least 3 mechanisms to provide
multiple versions of some component for a given release -
alternatives, modules, and versioned packages (ala nodejs, haskell,
etc). What is the best place to document this for a target user
community (e.g. nodejs users and developers)? We are looking at
adopting alternative versions for plain kubernetes in Fedora.

Best regards

Brad

On Tue, Oct 11, 2022 at 2:45 AM Fabio Valentini  wrote:
>

> >
> > +1. It also sounds like this option is easiest on the maintainers.
>
> I agree. I think there's at least general consensus around the idea
>
___
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-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F41 Change Proposal: Versioned Kubernetes Packages (Self-Cont

[Brad Smith]

One of the characteristics of Kubernetes is that skipping minor
versions during an upgrade is not supported. This reduces the
potential complexity in correctly setting Obsoletes/Provides in the
package for the replacing version. The unsupported version can also be
marked deprecated. These steps can help inform a user during dnf
updates.

In addition, there is a Kubernetes page in Quick Docs which contains,
in part, life cycle information for each Kubernetes release. While I
am a maintainer this page will be kept reasonably current, although I
cannot speak for subsequent maintainers. This page can be supplemented
by email to this list and posts on the Fedora community blog and
Discussions.

I will be glad to update the proposal to make this more explicit.

best regards

Brad Smith



On Sun, Apr 14, 2024 at 8:56 AM Zbigniew Jędrzejewski-Szmek
 wrote:
>

> Something that is not discussed explicitly in the proposal:
> what happens during an upgrade, when the user has a version installed
> that is not supported anymore. Do they get some notification that
> they should switch to the next one?
>
> Zbyszek
--
___
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-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Testing package version is spec file

[Brad Smith]

I help maintain a package where upstream changed the process to
generate installed documentation. In version 1.30 and newer, the spec
file needs to use process A; in versions older than 1.30 (e.g. 1.29.x,
etc) the spec file needs to use process B. I am struggling to find a
workable solution to testing the version like this.

Can someone please point me in the right direction? Or useful example?

thanks

Brad
--
___
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-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Testing package version is spec file

[Brad Smith]

Thanks Tom. A good question. Basically upstream supports 3 or 4
versions concurrently so I need to maintain a spec file that works
across this version boundary since the older versions will be
available in Fedora for another year. Also there are forthcoming
changes that make it desirable to have single "source of truth" for
any changes to the spec file.

thanks!

On Wed, May 8, 2024 at 10:46 AM Tom Hughes  wrote:
>

> Why do you need to? When you update the spec file to 1.30 you
> change it to use the new method surely.
>
> Why do you need one spec file that can do both versions?
>
> Tom
>
> --
> Tom Hughes (t...@compton.nu)
> http://compton.nu/
>
--
___
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-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Testing package version is spec file

[Brad Smith]

Thanks Adam.

Yes there is a new shell script that does the new document generation.
I experimented with using the %{exists: ...} macro but could not get
it to work. If you have an example at hand I would greatly appreciate
it.

Best regards

On Wed, May 8, 2024 at 10:46 AM Adam Williamson
 wrote:
>
> There are various strategies for parsing versions, it depends on the
> upstream version scheme. But I'd actually suggest looking if you can do
> this indirectly: instead of checking for the version, check for some
> other marker that indicates which approach you need to use. For
> instance, maybe some file or other will be present in one case but not
> the other; can you not just test for that, and choose the process to
> use based on the result?
--
___
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-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

RPM Guidance Questions

[Brad Smith]

Greetings -

I am sure this question has been asked and answered many times but I
could not find anything that specifically addressed my questions via
google search.

I have modified a spec file for a python based application (weewx
specifically although  that is not too relevant) to target Fedora
specifically. The upstream developers have a spec file that covers el8
and fedora both. The upstream version uses init.d based init scripts
to manage the application daemon.

I modified the spec file to target fedora specifically using systemd
to manage the daemon.  This is working well for me on test VMs.

I would also like to be able to install the rpm on a fedora container
image. I can do that with either the upstream or my current spec file,
of course, but I am thinking that systemd, in this particular
scenario, is overkill. The application daemon would be managed at the
container level not within the container per se.

What would be a good way to structure the spec file to cover both
scenarios? With systemd for install on a fedora VM or fedora bare
metal machine and without systemd for a fedora container install?

Would using subpackages be appropriate? One rpm for the base install
and the second to add systemd integration? Or is there another
alternative? A pointer to relevant discussions or possible solution
would be most helpful and appreciated.

Many thanks

regards

Brad
___
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-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Self Introduction: Brad Smith (aka buckaroogeek)

[Brad Smith]

Greetings

Peter Hunt (aka haircommander) asked if I might be interested in
assisting with the maintenance of the kubernetes packages for Fedora.
I have the time and interest and some of the needed skills. I am
certainly willing to learn.

I am a retired senior manager for a U.S federal agency (US Forest
Service). I have a background in software development over the past
several decades contributing PRs for a number of open source projects
but am not an active member of any specific project. I have a number
of repositories on github including several fedora specific ansible
roles (https://github.com/buckaroogeek?tab=repositories). I also
recently submitted a short note to fedora magazine about some
optimizations to DNF that are useful on low/expensive bandwidth
internet connections (see
https://fedoramagazine.org/use-the-dnf-local-plugin-to-speed-up-your-home-lab/).

Fedora is my primary OS at home for my workstation and Raspberry Pi
kubernetes cluster. The RPi4s all use Fedora 35 minimal currently with
ongoing experiments with Fedora CoreOS.  I started with Fedora 2,
switching from Red Hat desktop.

I have long been an open source advocate. During my federal career, I
was the principal open source advocate within the Forest Service IT
team. I led the adoption of collaborative source code management, and
the adoption and use of open source tools and code. I installed and
managed Enterprise SourceForge in the early 1990s for the agency and
was an active leader in moving the agency from SUSE and AIX to RHEL as
the primary OS in our data centers.

Looking forward to contributing where I can.

Best wishes

Brad
___
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-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Self Introduction: Brad Smith (aka buckaroogeek)

[Brad Smith]

Thank you Matthew.

Brad

On Mon, Jan 10, 2022 at 11:12 AM Matthew Miller
 wrote:
>
> On Mon, Jan 10, 2022 at 10:42:10AM -0800, Brad Smith wrote:
> > I am a retired senior manager for a U.S federal agency (US Forest
> > Service). I have a background in software development over the past
> > several decades contributing PRs for a number of open source projects
> > but am not an active member of any specific project. I have a number
>
> Welcome Brad! Sounds like you have a lot of interesting experience, and I'm
> glad Fedora is the place that you're jumping in further! :)
>
> --
> Matthew Miller
> 
> Fedora Project Leader
> ___
> 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-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it: 
> https://pagure.io/fedora-infrastructure
___
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-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Kubernetes 1.32 Beta 0

[Brad Smith]

There are 4 rpms:
kubernetes1.32 - contains kubelet
kubernetes1.32-kubeadm - contains kubeadm
kubernetes1.32-client - contains kubectl
kubernetes-1.32-systemd - contains systemd units and the
kube-apiserver, kube-proxy, kube-controller-manager, and
kube-scheduler binaries. This rpm is not needed if kubeadm is used to
initialize a cluster.

On Wed, Nov 6, 2024 at 11:24 AM Code Zombie  wrote:
>
> Which binaries first this package include?
>
> On Wed, Nov 6, 2024, 21:58 Brad Smith  wrote:
>>
>> The rpm for Kubernetes v1.32 (kubernetes1.32) has been pushed into
>> rawhide with the beta.0 release. This rpm will also be available in
>> F41. Rawhide and F41 also have kubernetes1.31, kubernetes1.30, and
>> kubernetes1.29 rpms.
>>
>> If you test kubernetes1.32 and are upgrading from v1.31 please see
>> this urgent upgrade note from the Kubernetes team:
>> https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.32.md#urgent-upgrade-notes
>>
>> best regards
>>
>> Brad
>> --
>> ___
>> 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-US/project/code-of-conduct/
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives: 
>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>> Do not reply to spam, report it: 
>> https://pagure.io/fedora-infrastructure/new_issue
>
> --
> ___
> 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-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it: 
> https://pagure.io/fedora-infrastructure/new_issue
-- 
___
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-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Kubernetes 1.32 Beta 0

[Brad Smith]

The rpm for Kubernetes v1.32 (kubernetes1.32) has been pushed into
rawhide with the beta.0 release. This rpm will also be available in
F41. Rawhide and F41 also have kubernetes1.31, kubernetes1.30, and
kubernetes1.29 rpms.

If you test kubernetes1.32 and are upgrading from v1.31 please see
this urgent upgrade note from the Kubernetes team:
https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.32.md#urgent-upgrade-notes

best regards

Brad
-- 
___
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-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

PSA - A change in Docker cli plugin version management (Compose, BuildKit, Buildx)

[Brad Smith]

FESCo has approved an update policy exception that encompasses these
Docker plugins: Compose, BuildKit, and Buildx
(https://pagure.io/fesco/issue/3394). The rpms for these plugins will
now track the current plugin release across all Fedora releases. The
maintainers for all three plugins only support the current release for
bug and security fixes.

In the next few days versions for these rpms will be submitted for F42
and F41. No updates for F40 are planned given the imminent EOL for F40
and the very old version of Compose present.

Please let me know if you have any questions or concerns.

best regards

Brad
-- 
___
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-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Heads Up - Kubernetes v1.29 EOL

[Brad Smith]

Kubernetes v1.29 is EOL along with CRI-O v1.29 and CRI-Tools v1.29.

Updates to the kubernetes1.29, cri-o1.29, cri-tools1.29 versioned
packages will no longer happen in Fedora (currently in F41, F42, F43).
I will mark these rpms as retired for F43 (rawhide) and possibly for
F42.

Fedora 40 and 41 also have v1.29 as the default, unversioned
kubernetes and cri-tools packages. I strongly encourage any using the
unversioned v1.29 packages to update your cluster using the versioned
packages (e.g. kubernetes1.30 - EOL in June 2025).

I am reluctant to update unversioned Kubernetes to a v1.30 release as
this could result in an unplanned and disruptive update to end-users
Kuberbetes clusters.

best regards

Brad
-- 
___
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-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

CRI-O 1.33 now available

[Brad Smith]

The initial release of CRI-O 1.33 (v1.33.0) has been pushed to Fedora
rawhide and updates-testing for F42. CRI-O 1.33 is not available in
F41 which does not supply the required go 1.24 base line for CRI-O.

Brad
-- 
___
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-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: How do you use sidetags?

[Brad Smith]

Sometime ago I asked a similar question on matrix (or IRC?) Fedora
Devel and some very kind person provided the following. I cannot
recall who it was.

My use case is simple, build Kubernetes or CRI-O using a version of
golang in updates-testing but not yet available in stable. I have used
these steps several times since F39 was a new thing.

```
fedpkg request-side-tag --base-tag f39-build
koji wait-repo f39-build-side-x
koji tag f39-build-side-x golang-1.21.3-1.fc39
koji wait-repo f39-build-side-x --build=golang-1.21.3-1.fc39
Build your package: fedpkg build --target=f39-build-side-x
koji untag f39-build-side-x golang-1.21.3-1.fc39
```
-- 
___
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-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Moby Engine/Docker CLI Updates Policy Exception

[Brad Smith]

Of potential interest to Docker users and developers on Fedora.

FESCo has approved an exception to the updates policy for the
moby-engine package in Fedora. With this exception, the current
release for the moby-engine package will be available across all
Fedora releases. The moby-engine package includes rpms for the Moby
Engine and for the Docker CLI. This change complements the recent
updates policy exception for Docker Buildkit, Buildx, and Compose.

Fedora 42 and F41 will see an update for the moby-engine package
submitted to testing shortly.

Please let the maintainers know if you have any questions or concerns.

best regards

Brad
-- 
___
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-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Empty debugsourcefiles.list

[Brad Smith]

In addition, once Go 1.25 is released (guessing mid-August) a rebuild
of Go projects will be done, if I understood the discussion on the
recent Go SIG call.

Brad

On Wed, Jul 30, 2025 at 12:16 PM Elliott Sales de Andrade
 wrote:
>
> On Wed, Jul 30, 2025 at 3:11 PM Łukasz Wojniłowicz
>  wrote:
> >
> > Hi all,
> >
> > due to the recent mass rebuild I get FTBFS as seen at
> > https://bugzilla.redhat.com/show_bug.cgi?id=2384485
> > The reason is "Empty %files file 
> > /builddir/build/BUILD/browserpass-3.1.0-build/browserpass-native-3.1.0/debugsourcefiles.list"
> > The empty debugsourcefiles.list come from the subpackages, that aren't
> > marked noarch, because they must be installed in arch specific paths.
>
> As this is a Go-based package, using the standard macros, this was
> affected by a change in Go 1.25. This was fixed in the macros, but
> only after the Mass Rebuild had reached the g's, which is long after
> your package was built. Please just try building it straight again
> without changes.
>
> > Adding "%global debug_package %{nil}" as at 
> > https://docs.fedoraproject.org/en-US/packaging-guidelines/Debuginfo/
> > helps, but as a side effect no debuginfo package is created for the main 
> > package.
> >
> > Is there a better way to handle this?
>
> --
> Elliott
> --
> ___
> 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-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it: 
> https://pagure.io/fedora-infrastructure/new_issue
-- 
___
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-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue