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

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

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: 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

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

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: 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

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: 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: 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: 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: 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

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: 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_status=VERIFIED_status=ASSIGNED_status=MODIFIED_status=ON_DEV_status=ON_QA_status=RELEASE_PENDING_status=POST=hello%40anthonyrabbito.com_to1=1=1=1=exact_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: 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

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: [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

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

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

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