Re: Inactive packagers to be removed after the F37 release

[Kevin Fenzi]

On Thu, Sep 15, 2022 at 09:26:36AM +0300, Alexander Bokovoy wrote:
> 
> Proven packagers seem to be a fair category to address. Also packagers
> responsible for security-related bits of the distribution. Compilers?

Well, as others noted in this thread, any packager has a lot of power. 
They can add a weak dep on something everyone has installed and pull
their package in. Of course they likely only get to do that once. 

> There is probably a value in defining what functions critical to have
> strongly authenticated and identified to the distribution at large. For
> example, right now even 2FA OTP requirement is not mandatory for certain
> package groups.

As far as I know, it's not possible to enforce otp per group is it?
That would be a nice enhancement. 

Additionally, right now, packagers commit with ssh keys or oidc tokens,
in order for a 2fa setup to be effective, we would need to switch that
to kerberos or the like.

> > * I'd really prefer to avoid going back to certs. People have all kinds
> > of problems with certs. I think it would cause a lot of confusion.
> > (Unless I am misunderstanding what use is proposed for them).
> > 
> > > If Fedora contributors would have had access to Fedora's FreeIPA web UI
> > 
> > We actually do have external access to the web UI.
> > We just don't advertise it much.
> 
> Ok, that's good to hear in case we need to experiment with our accounts
> before the Fedora Accounts UI is expanded to cover other authentication
> methods.

Yep. 

> > > or IPA API directly, we wouldn't even need to have a conversation about
> > > PKINIT and certificates. We could have added instructions how to request
> > > and associate a certificate with your account. But since Fedora Accounts
> > > system is the frontend to Fedora Project's FreeIPA deployment, we cannot
> > > simply do that. However, FreeIPA-wise, smartcards are supported now for
> > > Kerberos authentication, so we as Fedora contributors could benefit from
> > > that.
> > 
> > What would this use of certificates do here?
> > Authenticate you to get a kerberos ticket?
> > Allow you to login to the account interface?
> 
> The former. I am only considering all of this to allow Kerberos
> authentication with stronger methods. Smartcards are more accessible
> these days than, say, FIDO2 tokens. A card reader cost is around 10EUR
> (Amazon.de gives me ~100 options of USB smartcard readers below 20EUR),
> a smartcard is typically your government-issued ID in many countries.
> 
> Though with Token2 FIDO2 tokens that cost 14EUR themselves we get close
> enough to a lower boundary.

Yeah, it will still be hard to require 100% of packagers, but it might
be doable.

> Anyway, using a soft-based smartcard e.g. using NSS database stored on a
> usb flash drive and accessible via PKCS11 could also be an option. The
> problem here is to attest to a server side it is protected by the client
> but this is a common problem to all different methods. Even storing a
> key-pair on your hard drive would work with Kerberos PKINIT without any
> problem.
> 
> > CentOS folks still use certs for their koji:
> > https://wiki.centos.org/Authentication#TLS_certificate
> > (and thats using the same account system/ipa servers as fedora).
> > 
> > > I hope we can plan to work together on this improvement again, similar
> > > how we did with the initial rewrite of Fedora Accounts on top of
> > > FreeIPA. Again, if this is deemed to be valuable to Fedora contributors,
> > > perhaps CPA team could consider scheduling this effort as part of the
> > > initiatives.
> > 
> > Yeah, I would like that. Perhaps we could setup a meeting soon and
> > dicuss plans? I'm open to video meeting, but we could also do IRC to
> > keep things more open...
> 
> I am open to it too, may be in couple weeks or so, to allow interested
> parties to prepare.

Sure. Can you schedule something when you are ready/available and we can
go from there. 

> > > Let me round up methods that we have supported now or plan to add in
> > > Fedora 38-39 timeframe, from FreeIPA and SSSD side. All these lead to
> > > issuance of a Kerberos ticket that can be used for communicating with
> > > the rest of Fedora services:
> > >  - basic password-based authentication
> > >  - use of 2FA HOTP/TOTP tokens implemented by FreeIPA itself  - use of an
> > > external RADIUS server for validation of a string passed as
> > >a 'password' or 'token' value
> > >  - use of a certificate stored on a supported PKCS11 token (smartcard,
> > >softtoken (SoftHSMv2, NSS) or just in plain keypair files)
> > >  - use of OAuth2 device authorization grant against some OAuth2 IdP (new
> > >in FreeIPA 4.9.10+)
> > >  - (future) use of a FIDO2/WebAuthn token
> > > 
> > > Fedora accounts system implements the management of the first two
> > > methods right now.
> > 
> > And possibly the 3rd...
> > 
> > What does 'device' mean in the 4th one? :)
> 
> It is part of OAuth 2.0 specifications, 'Device Authorization Grant
> 

Re: Inactive packagers to be removed after the F37 release

[Kevin Fenzi]

On Wed, Sep 14, 2022 at 05:47:46PM +0300, Alexander Bokovoy wrote:
> On ke, 14 syys 2022, Stephen Smoogen wrote:
> > On Wed, 14 Sept 2022 at 05:28, Alexander Bokovoy 
> > wrote:
> > 
> > > 
> > > Sadly, it cannot be just 'any' certificate, it has to be issued by a
> > > certificate authority that is trusted by the KDC as well. For example,
> > > by FreeIPA CA which is already ran by the Fedora project infrastructure
> > > team. An alternative is to set up certificate mapping and validating
> > > rules.
> > > 
> > > If someone from Fedora Accounts team wants to experiment with this, I
> > > can guide you what to do.
> > > 
> > 
> > There is no continual running Fedora Accounts 'team'. There are 2-3 system
> > administrators split between releng, operations and  continual
> > firefighting. There are also a team of developers who are split between
> > CentOS Stream initiatives and other work. Changes like this need to have
> > more than just an 'oh I have finally an afternoon free where all the other
> > crap in the build infra is actually working for once.. lets dive into IPA'
> 
> I understand all of that myself. I think what is important here is to
> plan to work together so that eventually we can implement this.

Right and while I agree with what smooge says there, I'm definitely
interested in improving things as we can. I really would prefer a
detailed plan however, not 'lets enable everything we can and see what
sticks'. :) 

> This whole thread is about agreeing or disagreeing whether Fedora as a
> project would want to have better security methods to identify and
> authenticate its contributors when performing tasks that have large
> impact.

Yep. I'm in agreement that we want to... but there's always tradeoffs. 

A few random things to mention: 

* I don't think requiring FIDO2 for all packagers is tenable. It may
well be that we could get donations or funding to get hardware for all
packagers, especially if we wait for the current inactive process to
finish, but even so, we will run into problems of people who can't get
one shipped to them or gets lost in the mail, etc. There would also be a
delay "hey, you are now a packager, look for a token in the mail in the
next few weeks before you can do anything"

* I'd really prefer to avoid going back to certs. People have all kinds
of problems with certs. I think it would cause a lot of confusion.
(Unless I am misunderstanding what use is proposed for them).

> If Fedora contributors would have had access to Fedora's FreeIPA web UI

We actually do have external access to the web UI. 
We just don't advertise it much.

> or IPA API directly, we wouldn't even need to have a conversation about
> PKINIT and certificates. We could have added instructions how to request
> and associate a certificate with your account. But since Fedora Accounts
> system is the frontend to Fedora Project's FreeIPA deployment, we cannot
> simply do that. However, FreeIPA-wise, smartcards are supported now for
> Kerberos authentication, so we as Fedora contributors could benefit from
> that.

What would this use of certificates do here? 
Authenticate you to get a kerberos ticket? 
Allow you to login to the account interface?

CentOS folks still use certs for their koji:
https://wiki.centos.org/Authentication#TLS_certificate
(and thats using the same account system/ipa servers as fedora).

> I hope we can plan to work together on this improvement again, similar
> how we did with the initial rewrite of Fedora Accounts on top of
> FreeIPA. Again, if this is deemed to be valuable to Fedora contributors,
> perhaps CPA team could consider scheduling this effort as part of the
> initiatives.

Yeah, I would like that. Perhaps we could setup a meeting soon and
dicuss plans? I'm open to video meeting, but we could also do IRC to
keep things more open... 

> Let me round up methods that we have supported now or plan to add in
> Fedora 38-39 timeframe, from FreeIPA and SSSD side. All these lead to
> issuance of a Kerberos ticket that can be used for communicating with
> the rest of Fedora services:
>  - basic password-based authentication
>  - use of 2FA HOTP/TOTP tokens implemented by FreeIPA itself  - use of an
> external RADIUS server for validation of a string passed as
>a 'password' or 'token' value
>  - use of a certificate stored on a supported PKCS11 token (smartcard,
>softtoken (SoftHSMv2, NSS) or just in plain keypair files)
>  - use of OAuth2 device authorization grant against some OAuth2 IdP (new
>in FreeIPA 4.9.10+)
>  - (future) use of a FIDO2/WebAuthn token
> 
> Fedora accounts system implements the management of the first two
> methods right now.

And possibly the 3rd... 

What does 'device' mean in the 4th one? :) 
We do have https pushes using oauth/oidc token right now. 

Also, once we upgrade src.fedoraproject.org/pkgs.fedoraproject.org from
RHEL8 to RHEL9, it will be possible to use ecdsa-sk and ed25519-sk ssh
keys and thus use FIDO2 for ssh actions if we wish.

Re: F38 proposal: Strong crypto settings: phase 3, forewarning 2/2 (System-Wide Change proposal)

[Kevin Fenzi]

On Wed, Sep 14, 2022 at 11:45:16AM +0200, Alexander Sosedkin wrote:
> On Tue, Sep 13, 2022 at 7:35 PM Kevin Fenzi  wrote:
> >
> > How about this:
> >
> > Drop the term 'jump scare' entirely. IMHO it just sounds bad.
> 
> I'm open for proposals on the wording. =)

Well, I guess it depends on if you still want to implement it and then
plan to roll it back or not... see below.
> 
> > Rework the change so it's basically planning on making this change in
> > f38.
> 
> That makes it closer than currently,
> defeating the purpose of letting people prepare.

True, it possibly makes the timeline shorter. 
If thats a concern, perhaps you would consider just targeting f39 and
for f38 just doing test days and reminders asking developers to test
instead of changing it and then changing it back?
> 
> > Before f38 beta freeze, change owners/fesco looks at the state of things
> > and decides if it can remain on in f38 and if not, it gets reverted and
> > moved to f39.
> 
> Not sure how it's better than reverting in branched f38 but not rawhide,
> unless the goal is to hasten the change.

It's better because it seems more direct and honest to me. 
It means you are landing a change and trying to get it done, not landing
it to break people and then at the last minute after people rush to fix
things, removing it again. I also suspect there will be some feet
dragging due to this: "Oh, it's broken now, but they are going to revert
it anyhow, so I won't do anything".
> 
> > In the run up to f38 beta we could:
> >
> > * run a series of test days. perhaps one before you enable it in
> > rawhide, one a month or two later and one right before f38 beta
> > freeze?
> 
> I'm for more test days.
> There was one held already and I'm open for holding more in the future.
> Plus I should attempt some side-tag mass-rebuild or equivalent,
> but I, unfortunately, won't get to it until October at the earliest.

Sure, understand time is low for everyone. ;( 

> > * see if openqa might have some way to set TEST-FEDORA39 and re-run
> > tests on a compose or updates? This might be a good thing to try and do
> > before landing it in rawhide.
> 
> Sounds great if that's a possibility, but I don't know how to approach it.

Perhaps Adam can chime in here...
 
> > * setup a tracking bug to track the issues, so we can make a more
> > informed decision before f38 beta.
> >
> > Thoughts?
> 
> If the core of your proposal is
> * make it happen in f38 and revert and push back to f39 only if necessary
> as opposed to
> * make it happen in f38 rawhide, f39 rawhide, f39 branched and released,
>   but not f38 branched (the current proposal)
> then I can't say I understand what you are trying to achieve with
> that.

I don't care for "Here's a change, adjust to it please! Hurry!" Oh, just
kidding, it will not take effect until next cycle. That just seems to be
dishonest to our users. 

> IMO it makes the switch less certain, more frantic and more abrupt,
> while I was trying to smoothen it out in time as far as possible.

I don't think it's possible to cleanly spread out a change like this
over more than 1 long fedora cycle. 

> 
> So +1 on all the accompanying activities possible,
> -1 on expediting the switch.

ok. I'm not sure where the rest of fesco is on this, but I guess we will
see. :) 

Thanks for listening. 

kevin


signature.asc
Description: PGP signature
___
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: nspawn for rawhide?

[Kevin Fenzi]

On Tue, Sep 13, 2022 at 05:01:57PM +0200, Florian Weimer wrote:
> * Kevin Fenzi:
> 
> > I just edited the f38 tag at Mon Aug 22 08:29:51 PM UTC 2022 to switch
> > to nspawn. 
> >
> > If you have detected a issue that seems like it might be related to this
> > change, please file a releng ticket and we will dig into it. 
> 
> Thanks, the glibc (nested) container tests started running during Koji
> builds, and promply result in additional test failures (all glibc test
> bugs as far as I can tell).
> 
> Just to be clear, this nested container support is really helpful.

Glad to hear it. 

We have just one issue left that I know of... ostree_installers are
failing. Thats hopefully going to be worked around in a pungi tweak, and
then we should be good (as far as I am aware).

https://bugzilla.redhat.com/show_bug.cgi?id=2123812

kevin


signature.asc
Description: PGP signature
___
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: F38 proposal: Strong crypto settings: phase 3, forewarning 2/2 (System-Wide Change proposal)

[Kevin Fenzi]

How about this:

Drop the term 'jump scare' entirely. IMHO it just sounds bad.

Rework the change so it's basically planning on making this change in
f38. 

Before f38 beta freeze, change owners/fesco looks at the state of things
and decides if it can remain on in f38 and if not, it gets reverted and
moved to f39.

In the run up to f38 beta we could: 

* run a series of test days. perhaps one before you enable it in
rawhide, one a month or two later and one right before f38 beta
freeze?

* see if openqa might have some way to set TEST-FEDORA39 and re-run
tests on a compose or updates? This might be a good thing to try and do
before landing it in rawhide.

* setup a tracking bug to track the issues, so we can make a more
informed decision before f38 beta.

Thoughts?

kevin


signature.asc
Description: PGP signature
___
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: SSL CERTIFICATE_VERIFY_FAILED?

[Kevin Fenzi]

On Sun, Sep 11, 2022 at 12:31:34PM -0500, Ron Olson wrote:
> Hey all-
> 
> When trying to do a `fedpkg update`, I got this response:
> 
> ```
> Could not execute update: Could not generate update request: {"status":
> "error", "errors": [{"location": "body", "name": "builds", "description":
> "Unable to create update.  [SSL: CERTIFICATE_VERIFY_FAILED] certificate
> verify failed: certificate has expired (_ssl.c:997)"}]}
> A copy of the filled in template is saved as bodhi.template.last
> ```
> But the update shows up on bodhi as an active update.
> 
> Is there something I can do to fix this; never seen this error before.

It's nothing on your end. It's server node certs on the rabbitmq cluster
that runs fedora-messaging. ;( 

I've renewd those certs now and I think I fixed your updates, so it should be 
fixed.

kevin


signature.asc
Description: PGP signature
___
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: Inactive packagers to be removed after the F37 release

[Kevin Fenzi]

On Tue, Sep 06, 2022 at 07:37:19PM +0200, Vitaly Zaitsev via devel wrote:
> On 06/09/2022 18:36, Kevin Fenzi wrote:
> > For an OTP generating app? I don't see why it would...
> 
> No, for FIDO2 authentication.

https://github.com/ellerh/softfido

But not sure how usable it is. ;) 

Also:

https://blog.hansenpartnership.com/webauthn-in-linux-with-a-tpm-via-the-hid-gadget/

but I am not sure where the real code is...

kevin


signature.asc
Description: PGP signature
___
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: Inactive packagers to be removed after the F37 release

[Kevin Fenzi]

On Tue, Sep 06, 2022 at 06:18:17PM +0200, Vitaly Zaitsev via devel wrote:
> On 06/09/2022 17:00, Gary Buhrmaster wrote:
> > mobile device
> 
> Requires proprietary Google services.

For an OTP generating app? I don't see why it would... 

https://search.f-droid.org/?q=otp=en

are all open source, freely available and don't need google for
anything. 

kevin


signature.asc
Description: PGP signature
___
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: Users with commit rights in src.fp.o but no more in packager group

[Kevin Fenzi]

On Mon, Sep 05, 2022 at 12:13:26PM +0200, Miro Hrončok wrote:
> On 05. 09. 22 11:07, Vít Ondruch wrote:
> > 
> > Apart from that, I don't think that the pseudo-users or group ownership
> > would work. I saw a good amount of people giving the packages to some
> > groups or pseudo-users, but in turn, that meant there is nobody who
> > would care about such package.
> 
> +100

While that can surely happen, it can and does also happen when someone
is 'main admin' of a package. :) You can't make someone care.
I think the best thing we can do is match up the people who care with
the packages they care about. Using main admin as a indicator of who
cares for the package doesn't seem right to me. You can definitely have
cases of packages where multiple people work on it, or cases where just
one person does, but they aren't the main admin. 

Anyhow, the only real reason we need main admin is that bugzilla needs 1
specific user to assign bugs to. Perhaps we could consider this when/if
we ever move off bugzilla. 

kevin


signature.asc
Description: PGP signature
___
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

[EPEL-devel] Re: Adding Package to side-tag

[Kevin Fenzi]

On Sat, Sep 03, 2022 at 08:32:47PM +1000, Frank Crawford wrote:
> 
> The document I used
> was 
> https://docs.fedoraproject.org/en-US/package-maintainers/Package_Update_Guide/#multiple_packages
> 
> It was the only place I could find that really talked about side-tags,
> and wait-repo looks only mentioned in passing.  Once you know it is
> needed it is more obvious, but not if you haven't used them much
> before.

Well, it does say: 

"The latter is important if any builds depend on previous ones in the side tag.
Use koji wait-repo --build   to ensure that the 
respective
build is available in the build root for subsequent builds.  "

But if you can see a way to be more clear there, perhaps you could put
in a PR?

kevin


signature.asc
Description: PGP signature
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Inactive packagers to be removed after the F37 release

[Kevin Fenzi]

On Sat, Sep 03, 2022 at 05:40:28PM -0700, Adam Williamson wrote:
> 
> Gadzooks, foiled by the old loophole bypass loophole defense again?!

No one expects the... :) 

> No, seriously, I'm kinda assuming 'positive intent' here. It's not
> meant to catch someone trying to 'avoid' the check. More maybe just
> someone who got PP powers years ago but now just maintains one or two
> packages, but never thought about giving them up. Maybe if there are
> folks like that they'd be happy to drop the privileges so if they do
> lose their laptop or something, the consequences are more limited.

Could be. Actually builds isn't a good test either entirely. 
You could use your provenpackager powers to fix things for others and
let them do the builds, or use them for filing bodhi updates for
packages you didn't build that someone else didn't file...

Perhaps it would be better (although more noisy) to just mail all
provenpackagers every cycle and ask if anyone would like to leave the
group?

kevin


signature.asc
Description: PGP signature
___
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

unannounced soname bump in libbpf

[Kevin Fenzi]

Greetings. 

Seems the latest rawhide build of libbpf bumps soname, breaking a number
of dependent packages. ;( 

https://koji.fedoraproject.org/koji/buildinfo?buildID=2057060

According to the rawhide updates policy: 
https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#_rawhide

"When a proposed update contains an ABI or API change: 
notify a week in advance both the devel list and maintainers directly
(using the packagename-maintain...@fedoraproject.org alias)
whose packages depend on yours to rebuild or offer to do these rebuilds for 
them."

I've untagged that build from rawhide, can you please make a sidetag
(fedpkg request-sidetag) and tag that build in there and get all the
dependent packages rebuilt with it?

Let me know if you have any questions/need any help, happy to help out. 

kevin


signature.asc
Description: PGP signature
___
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: Users with commit rights in src.fp.o but no more in packager group

[Kevin Fenzi]

On Sat, Sep 03, 2022 at 02:01:59PM +, Mattia Verga via devel wrote:
> Il 26/08/22 07:17, David Tardon ha scritto:
> > Hi,
> >
> > On Thu, 2022-08-25 at 11:04 +0300, Alexander Bokovoy wrote:
> >> On to, 25 elo 2022, Miro Hrončok wrote:
> >>> We use the python-maint pseudo-account to be the default Bugzilla
> >>> assignee for Pythons, e.g.
> >>> https://src.fedoraproject.org/rpms/python3.11
> >>>
> >>> Note that it does *not* require the account to be listed in
> >>> maintainers or to have commit rights.
> >> Same for ipa-maint account.
> > Same for systemd-maint and dracut-maint.
> >
> > D.
> 
> So... wouldn't be better to have a consistent way across all packages to
> deal with these cases?

Sure, but Fedora has been around for many years, accross a bunch of
differnt applications and these things have never been completly set. 
:(

> What's better, a pseudo-user to be the main-admin of a package, or a
> real user to be the main-admin and just add the pseudo-user as the
> default assignee of bugs?

We discussed this back when we switched from pkgdb to pagure-dist-git
some. One thought at the time was that we make every package use a
pseutouser for main-admin, but there's downsides to that too. 
On the plus side it would allow us to get rid of 'main admin'.
> 
> Who owns the credentials of those pseudo-users? Also, Fedora Accounts
> user pages links to non-existent wiki pages... it would be nice to have
> a description about them (if there's a consensus of continue listing
> them as main-admin).

Many of them the group using them has the credentials, or no one at all. 

I'm not sure it's possible to get them all sorted, but I agree at least
a wiki page with info on them would be good to have at the very least.

kevin


signature.asc
Description: PGP signature
___
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: Updating asio in rawhide (and possibly F37) to 1.24.0

[Kevin Fenzi]

On Sat, Sep 03, 2022 at 08:51:13AM +0200, Julian Sikorski wrote:
> Given the lack of response, I tried to push the update anyway given the low
> risk of breakage due to it being header-only. Unfortunately, it turns out
> that my side-tag is gone. Documentation states:
> 
> Side tags are cleaned up 30 days after creation, or 14 days if they have not
> been used at all. Make sure and use your side tag before then.
> 
> Since I used my side tag, I have expected it to still be there. Could
> someone clarify? Does 14 days apply for any consecutive 14 days? The wording
> implies that building something for the side tag at any time would make it
> stay for 30 days.

Yes, thats what the intent is...

Odd. 

I am not sure what happened here. 
We cleanup side tags with: 

/usr/sbin/koji-sidetag-cleanup --empty-delay=14 --old-delay=30

So, it should have left this one alone for 30days, but it didn't. ;( 

Perhaps it's a koji bug... :( 

kevin


signature.asc
Description: PGP signature
___
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: Inactive packagers to be removed after the F37 release

[Kevin Fenzi]

On Sat, Sep 03, 2022 at 12:24:11PM -0700, Adam Williamson wrote:
> 
> So, I have a probably-controversial idea for a follow-up on this.
> 
> Even after this sweep, we have 141 proven packagers. That's a lot of
> people who can build almost anything in Fedora.
> 
> It should be possible to check whether a provenpackager has built any
> package they don't have direct commit rights to in the last X months.
> 
> Should we construct that search, run it, and propose removing
> provenpackager status from folks who aren't using it, to cut down that
> set?

That policy was setup before this one for packagers. ;) 

https://docs.fedoraproject.org/en-US/fesco/Provenpackager_policy/

kevin


signature.asc
Description: PGP signature
___
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: Fedora rawhide compose report: 20220902.n.0 changes

[Kevin Fenzi]

On Fri, Sep 02, 2022 at 11:22:13AM +, Fedora Rawhide Report wrote:
> OLD: Fedora-Rawhide-20220901.n.0
> NEW: Fedora-Rawhide-20220902.n.0
> 
> = SUMMARY =
> Added images:0
> Dropped images:  7
> Added packages:  6
> Dropped packages:6
> Upgraded packages:   64
> Downgraded packages: 0
> 
> Size of added packages:  1.18 MiB
> Size of dropped packages:6.64 MiB
> Size of upgraded packages:   1.28 GiB
> Size of downgraded packages: 0 B
> 
> Size change of upgraded packages:   -22.62 MiB
> Size change of downgraded packages: 0 B
> 
> = ADDED IMAGES =
> 
> = DROPPED IMAGES =
> Image: Kinoite dvd-ostree x86_64
> Path: Kinoite/x86_64/iso/Fedora-Kinoite-ostree-x86_64-Rawhide-20220901.n.0.iso
> Image: Silverblue dvd-ostree ppc64le
> Path: 
> Silverblue/ppc64le/iso/Fedora-Silverblue-ostree-ppc64le-Rawhide-20220901.n.0.iso
> Image: Silverblue dvd-ostree aarch64
> Path: 
> Silverblue/aarch64/iso/Fedora-Silverblue-ostree-aarch64-Rawhide-20220901.n.0.iso
> Image: Kinoite dvd-ostree ppc64le
> Path: 
> Kinoite/ppc64le/iso/Fedora-Kinoite-ostree-ppc64le-Rawhide-20220901.n.0.iso
> Image: Kinoite dvd-ostree aarch64
> Path: 
> Kinoite/aarch64/iso/Fedora-Kinoite-ostree-aarch64-Rawhide-20220901.n.0.iso
> Image: SoaS raw-xz aarch64
> Path: Spins/aarch64/images/Fedora-SoaS-Rawhide-20220901.n.0.aarch64.raw.xz
> Image: Silverblue dvd-ostree x86_64
> Path: 
> Silverblue/x86_64/iso/Fedora-Silverblue-ostree-x86_64-Rawhide-20220901.n.0.iso

This is caused by the switch to systemd-nspawn. 

(I had enabled it, then we hit some kernel signing issues and unrelated
pesign bugs so I had set it back this last week. I re-enabled it
yesterday). 

Filed https://bugzilla.redhat.com/show_bug.cgi?id=2123812 on this. 

Hopefully we can sort this out, as it's the last thing I see off hand on
the switch to nspawn.

kevin


signature.asc
Description: PGP signature
___
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

[EPEL-devel] Re: EPEL2RHEL - New Wording? - New Workflow?

[Kevin Fenzi]

On Thu, Sep 01, 2022 at 12:12:07PM -0500, Maxwell G via epel-devel wrote:
> On Wednesday, August 31, 2022 Troy Dawson wrote:
> > EPEL2RHEL is part of the RHEL 8 and 9 new package workflow.  When a RHEL
> > maintainer wants to add a package to RHEL 8 or 9 they start a "new package
> > workflow".  There are several automations that happen when they start that
> > workflow.  One of them is checking if the package is already in epel.  If
> > it is, it creates a bugzilla against that package, and links that bug
> > against the EPEL2RHEL tracker. [1]
> > Remember, this check currently happens at the beginning of the new package
> > workflow.  Before a package has been branched, built, or put into testing
> > repos.
> 
> I think this whole process should be automated. File bugs that say "Heads up: 
> your package will be automatically retired after the release of RHEL X.X" and 
> provide some explanation. This will have multiple benefits:
> 
> 1. Saying "you'll have to do something in six months, but it'll be bad if you 
> do it now" is quite difficult to follow.
> 
> 2. We can send out one announcement to epel-announce about which packages are 
> going to be retired and when that'll happen, instead of retiring packages in 
> a 
> piecemeal manner.
> 
> 3. The maintainers won't have to remember to do it.
> 
> 4. If we find out that a package is buildroot only, then we'll close the bug 
> and exclude it from the automatic retiring.

I really like this approach... :) 

kevin


signature.asc
Description: PGP signature
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: fedpkg update - Could not execute update: Could not generate update request: Invalid request

[Kevin Fenzi]

On Tue, Aug 30, 2022 at 05:50:08PM -0400, Chris wrote:
> Guys,
> 
> I'm not sure what I'm doing wrong, but for some reason I can no longer call
> "fedpkg -- update" on any of the repositories (el8, el7, fc36, etc).
> 
> It prompts me for the password and then goes through the routine that it's
> not accepted.

What version of bodhi-client do you have?

You need at least 6.0.0. 

Bodhi chnaged in 6.0.0 to use OpenID Connect instead of openid. 
https://github.com/fedora-infra/bodhi/releases/tag/6.0.0
So, if you use the bodhi client you need at least 6.0.0. 

Hope that helps,

kevin


signature.asc
Description: PGP signature
___
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: Thoughts welcome: interface between automated test gating and the "critical path"

[Kevin Fenzi]

On Mon, Aug 29, 2022 at 03:50:02PM -0700, Adam Williamson wrote:
...snip...
> 
> I can think of I guess four options:
> 
> 1. Broaden the definition of the "critical path" somehow. We could just
> write in that it includes FreeIPA functionality, I guess, though that
> seems special purpose. We could broaden it to include any functionality
> covered by the release criteria, which would be quite a big increase
> but seems like a reasonable and concise definition. Or we could write
> in that it includes any functionality that is exercised by the gating
> openQA tests, though that seems a bit arbitrary - there's no
> particularly great organizing principle to the openQA tests we choose
> to run on updates, if I'm honest, it's a sort of grab bag I came up
> with.

I think this one is best... perhaps we could add something like 'and
such package groups as working groups decide are critical to their
edition' ?

kevin


signature.asc
Description: PGP signature
___
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

[EPEL-devel] Re: Adding Package to side-tag

[Kevin Fenzi]

On Sun, Aug 28, 2022 at 07:38:31PM +1000, Frank Crawford wrote:
> On Sat, 2022-08-27 at 14:58 -0500, Maxwell G via epel-devel wrote:
> > n 22/08/27 04:03PM, Frank Crawford wrote:
> > > While building two related new packages for EPEL9 with a
> > > chainbuild,
> > > the second one failed, however, now I am trying to work out how to
> > > specify the completed package in the build for the second package.
> > > 
> > > I have tried creating a side-tag and add the completed build to the
> > > side-tag, then building the second package in that side-tag, but it
> > > still claims that it can't find the first package, which it
> > > requires to
> > > build.
> > 
> > Can you please provide more information? What are the
> > builds/packages?
> > What commands did you run? How did you add the first package to the
> > side
> > tag? Did you wait for the side tag repo to refresh before trying to
> > build the second package?
> 
> I think you answered my issue here, I did not allow sufficient time for
> the repo to refresh before submitting the second build.
> 
> For reference, the packages were python-zipp-0.5.1-1.el9 and python-
> importlib-metadata-4.6.3-2.el9 and the commands I ran were:
> 
> fedpkg request-side-tag
> koji wait-repo 
> koji tag-pkg  python-zipp-0.5.1-1.el9
> fedpkg build --target=
> 
> It looks like I needed to do another "koji wait-repo " between the
> tag-pkg and build, but I will say that it is not obvious in any of the
> documentation I could find, that this needed.

:( Which documentation were you looking at for this?
We should try and update it...

The wait repo is needed because you added a build and now it needs to
regenerate the repodata to include it.

kevin


signature.asc
Description: PGP signature
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Users with commit rights in src.fp.o but no more in packager group

[Kevin Fenzi]

On Wed, Aug 24, 2022 at 05:30:35PM +, Mattia Verga via devel wrote:
> Following my comment in
> https://pagure.io/fesco/issue/2856#comment-812870 I wrote a simple
> script to check how many users have commit rights onto some project in
> src.fp.o, but aren't (anymore) members of the `packager` group:
> 
> ```
> Found 31 users with commit privileges but not in packager group:
> packaging-team
> stefanok
> mmcgrath
> kernel-maint
> oddshocks
> systemd-maint
> lvm-team
> abrt-team
> i18n-team
> amahdal
> jvlomax
> coremodule
> libvirt-maint
> sonkun
> fonts-sig
> narasim
> perl-sig
> dcr226
> gecko-maint
> ozamosi
> sheltren
> anaconda-maint
> java-sig
> duriantang
> dracut-maint
> ipa-maint
> kmod-maint
> mariobl
> mck182
> design-sw
> cdeccio
> ```
> 
> With the exclusion of *-team, *-sig and *-maint, I think packaging
> rights should be removed from those users.

I think these are users who manually removed themselves from the
packager group, but didn't remove all their acls first. (and legit
groups/sigs).

> Also, as per my comment linked above, I think there should be some check
> to prevent users removed from packager group to maintain commit rights.
> No idea where/how to implement that.

I don't think it happens too often. We could make a script that checks
it from time to time tho. Might be a good cadidate for a toddler (
https://pagure.io/toddlers)

In the mean time I agree we should remove the non team/sig/maint users
above. 

kevin


signature.asc
Description: PGP signature
___
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: Packages in repo not signed: fedora-cisco-openh264 repository

[Kevin Fenzi]

Everything should be back to working. Try a 'dnf --refresh...' or a 
'dnf clean all'.

It's not fully clear yet some of the events. ;(

The person who used to update this has moved to another group.
The SOP (standard operating procedure) for doing this update was 
incorrect/out of date/wrong.
Current update used the wrong process in the SOP and unsigned rpms were 
sent instead of signed ones.
Something caused a zchunk error (the first one you saw, but perhaps this 
was just out of date repodata?)
Something caused mirrormanager to not update for the new repodata.
When updated, it started seeing the new unsigned rpms and gave an error 
about that.

I've pushed repodata that just points to the older h264 version thats signed 
(in f36/f37) and empty repodata (rawhide/f38).

In my testing everything is back to working.

I've submitted a PR to update the SOP.

Sorry for the trouble.

kevin


signature.asc
Description: PGP signature
___
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: F37 side tag after branching point

[Kevin Fenzi]

Just to chime in from a releng perspective here... 

IMHO you should do builds for f38 now also (either by making a side tag
and bootstrapping them just like was done for f37, or tagging f37 builds
you need into the f38 sidetag). 

While it's technically possible to push the f37 builds into rawhide
also, it would take releng manually tagging them in, bypassing bodhi,
gating and CI completely. It's much better to build again for
f38/rawhide and let those builds get checked by gating and CI, etc. 

If you run into any problems, let me know...

kevin


signature.asc
Description: PGP signature
___
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: Fedora rawhide compose report: 20220823.n.0 changes

[Kevin Fenzi]

On Tue, Aug 23, 2022 at 11:07:26AM +, Fedora Rawhide Report wrote:
> OLD: Fedora-Rawhide-20220822.n.0
> NEW: Fedora-Rawhide-20220823.n.0

...snip...

> = DROPPED IMAGES =
> Image: Kinoite dvd-ostree aarch64
> Path: 
> Kinoite/aarch64/iso/Fedora-Kinoite-ostree-aarch64-Rawhide-20220822.n.0.iso
> Image: Silverblue dvd-ostree aarch64
> Path: 
> Silverblue/aarch64/iso/Fedora-Silverblue-ostree-aarch64-Rawhide-20220822.n.0.iso
> Image: Silverblue dvd-ostree ppc64le
> Path: 
> Silverblue/ppc64le/iso/Fedora-Silverblue-ostree-ppc64le-Rawhide-20220822.n.0.iso
> Image: Kinoite dvd-ostree ppc64le
> Path: 
> Kinoite/ppc64le/iso/Fedora-Kinoite-ostree-ppc64le-Rawhide-20220822.n.0.iso
> Image: Kinoite dvd-ostree x86_64
> Path: Kinoite/x86_64/iso/Fedora-Kinoite-ostree-x86_64-Rawhide-20220822.n.0.iso
> Image: Container_Minimal_Base docker ppc64le
> Path: 
> Container/ppc64le/images/Fedora-Container-Minimal-Base-Rawhide-20220822.n.0.ppc64le.tar.xz
> Image: Silverblue dvd-ostree x86_64
> Path: 
> Silverblue/x86_64/iso/Fedora-Silverblue-ostree-x86_64-Rawhide-20220822.n.0.iso

These appear to be related to the systemd-nspawn change. ;( 

Running the ostree post: 

DEBUG util.py:445:  error: Writing content object: Setting xattrs: 
fsetxattr(security.selinux): Invalid argument

Hopefully we can figure a solution soon. 

kevin


signature.asc
Description: PGP signature
___
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: gsl soversion bump

[Kevin Fenzi]

On Tue, Aug 23, 2022 at 09:23:51AM +0900, Mamoru TASAKA wrote:
> Elliott Sales de Andrade wrote on 2022/08/23 5:54:
> > On Thu, Aug 11, 2022 at 12:08 PM Susi Lehtola
> >  wrote:
> > > 
> > > Hello,
> > > 
> > > 
> > > gsl will be updated from version 2.6 to 2.7.1 which changes the
> > > soversion from .25 to .27 in one week. List of dependent packages
> > > 
> > > $ for rpm in $(repoquery --disablerepo=* --enablerepo=rawhide
> > > --whatrequires "libgsl.so.25()(64bit)"); do repoquery --disablerepo=*
> > > --enablerepo=rawhide --source $rpm;done|sort|uniq
> > > 
> > 
> > Did you just build directly in Rawhide after listing *61* packages
> > that would break from the update?
> > Please please use a side tag next time.
> > 
> 
> Untagging requested.
> https://pagure.io/releng/issue/10984

Untagged. You can make a side tag and tag it into there... 

kevin


signature.asc
Description: PGP signature
___
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: nspawn for rawhide?

[Kevin Fenzi]

I just edited the f38 tag at Mon Aug 22 08:29:51 PM UTC 2022 to switch
to nspawn. 

If you have detected a issue that seems like it might be related to this
change, please file a releng ticket and we will dig into it. 

Thanks, 

kevin


signature.asc
Description: PGP signature
___
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: nspawn for rawhide?

[Kevin Fenzi]

On Sat, Aug 20, 2022 at 11:18:14PM -0400, Adam Williamson wrote:
> On Fri, 2022-08-19 at 09:46 -0700, Kevin Fenzi wrote:
> > 
> > Since everyone seems postivie on this, I'll look at switching it on
> > monday and see what breaks. 
> 
> Does this apply just to package builds, or to everything? i.e. are live
> image builds also going to use it?
> 
> It's not necessarily a problem if so, I just kinda want to know so I
> can adjust openQA's live image build test (which is meant to shadow the
> official builds as closely as possible).

It would be anything use f38-build... so yes, livemedia and images too. 

kevin


signature.asc
Description: PGP signature
___
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: nspawn for rawhide?

[Kevin Fenzi]

On Fri, Aug 19, 2022 at 04:50:07PM +0200, Florian Weimer wrote:
> * Stephen Smoogen:
> 
> > On Fri, 19 Aug 2022 at 05:44, Florian Weimer  wrote:
> >
> >  * Kevin Fenzi:
> >
> >  > Greetings everyone. 
> >  >
> >  > Many years ago mock introduced and then made default it's isolation to
> >  > use systemd-nspawn instead of chroot. Shortly after the nspawn isolation
> >  > was added, it was used in fedoraproject koji builds, but there were
> >  > issues and since then the fedoraproject koji has defaulted to using
> >  > chroot isolation. 
> >  >
> >  > Releng has had a ticket open for a long time to switch
> >  > ( https://pagure.io/releng/issue/6967 )
> >  >
> >  > I think the two items listed there (kernel bind mounts and loop devices)
> >  > have long since been fixed, so I would like to propose we switch rawhide
> >  > to using nspawn and see if any other issues show up. 
> >
> >  What's the version of nspawn that will be used here?  Presumably it's
> >  not the rawhide version, but the host version?
> >
> > Currently I think all builders are Fedora 36. 
> 
> Okay, I tried to reproduce this environment with the mock in Fedora 36
> and the fedora-rawhide-x86_64 configuration.  This tester:
snip...
> 
> This looks very good, no problematic EPERM errors.  So I don't expect
> this type of system call compatibility issues from the switch.

Great! thanks for testing. I seem to dimly recall that glibc was
something that nspawn broke before, but like I said, it was only right
after it landed that it was even attempted. 

Since everyone seems postivie on this, I'll look at switching it on
monday and see what breaks. 

kevin


signature.asc
Description: PGP signature
___
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

nspawn for rawhide?

[Kevin Fenzi]

Greetings everyone. 

Many years ago mock introduced and then made default it's isolation to
use systemd-nspawn instead of chroot. Shortly after the nspawn isolation
was added, it was used in fedoraproject koji builds, but there were
issues and since then the fedoraproject koji has defaulted to using
chroot isolation. 

Releng has had a ticket open for a long time to switch
( https://pagure.io/releng/issue/6967 )

I think the two items listed there (kernel bind mounts and loop devices)
have long since been fixed, so I would like to propose we switch rawhide
to using nspawn and see if any other issues show up. 

If everyone is ok with it, I can enable it (just for rawhide) and we can
look for issues with composes or any other items. At least then we would
have a good list of things we would like to fix. If it turns out things
just work ok we can leave it enabled.

I think moving to this will:
* More closely match developers local test mock builds.
* Provide better isolation for builds
* Help with resources as systemd-nspawn is a lot more cgroup aware than
chroot
* Allow us to close a 5 year old ticket. ;) 

Thoughts?

kevin


signature.asc
Description: PGP signature
___
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: PSA: koji armv7hl builders locking up

[Kevin Fenzi]

On Tue, Aug 09, 2022 at 09:14:17AM -0400, Steve Dickson wrote:
> 
> 
> On 8/7/22 3:49 PM, Kevin Fenzi wrote:
> > Or just wait... I have been checking them a few times a day and
> > rebooting any that are locked up.
> How long do we have to wait? [1] has been stuck since
> Mon, 08 Aug 2022 14:17:44 UTC
> 
> steved.
> 
> [1] https://koji.fedoraproject.org/koji/taskinfo?taskID=90612742

Thats one I rebooted this morning after I woke up (and your build is
finished). I am not sure why I didn't see that one as stuck yesterday,
perhaps there's two failure modes here. ;( 

kevin


signature.asc
Description: PGP signature
___
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: fedora-create-review error message

[Kevin Fenzi]

On Sun, Aug 07, 2022 at 08:27:19PM -0500, Richard Shaw wrote:
> I'm working on a package review for libphidget22 (rename of libphidget),
> but after typing in my bugzilla credentials I get the following:
> 
>  The method 'Bug.get' is not supported without using API keys and the the
> authentication header. See
> https://bugzilla.redhat.com/docs/en/html/api/core/v1/general.html#authentication
> for details on using the 'Authorization' header. at
> /usr/share/perl5/vendor_perl/SOAP/Lite.pm line 2855.\n">
> 
> Haven't seen this before, but I haven't submitted a new package in a while
> either.

How are you trying to create the review request?

ie, what are you typing your bugzilla credentials into?

The web page should work: 
https://bugzilla.redhat.com/bugzilla/enter_bug.cgi?product=Fedora=fedora-review
(after logging in)

But it sounds like you might be using some script or tool?

If so, you need to get a api key and use that. scripts are no longer
allowed to login with username/password. 

Go to account -> preferences -> api keys 

create a new api key

If you are using python-bugzilla then you should be able to put that api
key in ~/.config/python-bugzilla/bugzillarc

As so:

[bugzilla.redhat.com]
api_key=THEAPIKEY

kevin


signature.asc
Description: PGP signature
___
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: PSA: koji armv7hl builders locking up

[Kevin Fenzi]

On Sun, Aug 07, 2022 at 12:10:44PM +0200, Fabio Valentini wrote:
> Hi all,
> 
> TL;DR: It seems like armv7hl koji builders are locking up, most often
> when running dnf to install the buildroot or to install dependencies.

Yeah. ;( 

> I've seen many people getting hit by this issue:
> https://pagure.io/fedora-infrastructure/issue/10833
> 
> So, if your build takes unusually long time on armv7hl, look at the
> task's logs in koji, and if they're stuck at an early stage of the
> build, you will need to cancel the task and resubmit it (or ask releng
> to run "koji free-task NNN" for the stuck armv7hl task).

Or just wait... I have been checking them a few times a day and
rebooting any that are locked up. :( 

I've been trying to isolate it, but it's not been easy. 
I've tried 5.18 and 5.17 kernels. I've tweaked the virt settings. 
Still trying to figure out a way to get them stable. 

Sorry for the hassle, and thanks for noting it.

kevin


signature.asc
Description: PGP signature
___
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

[EPEL-devel] Re: Orphaning EPEL Branches

[Kevin Fenzi]

On Sat, Aug 06, 2022 at 10:05:40PM +0200, Maxwell G via epel-devel wrote:
> Hi EPEL folks,
> 
> In the past couple EPEL SCo meetings, we have been discussing adding a
> new package retirement policy for EPEL packages.

That reads amusingly to me... to be clear 'new policy' not 'new packages'.

...snip...
> 
> Here are my thoughts:
> 
> If an entire Fedora package that has (an) EPEL branch(es) is orphaned,
> the EPEL branch(es) should probably be orphaned at the same time as the
> rawhide branch. Otherwise, we'd have to treat only orphaning an EPEL
> branch as a special case:
> 
> We could create an issue tracker for this. Packagers would have to
> submit a ticket requesting to orphan a certain package's EPEL branch(es)
> and set the EPEL Bugzilla assignee to "orphan" if they're orphaning all
> active EPEL branches. epel-devel@ could be CC'd on all issues. Then, we
> could have a provenpackager in the SIG go through and manually retire
> the packages that haven't been picked up after six weeks. The later will
> be difficult if we have a large volume, but I don't expect that. We
> could script this if necessary or just ask the submitter to do it
> themself.
> 
> This doesn't allow picking up packages in a self-service manner, but I
> don't think that's a huge deal for our case.
> 
> 
> [1]: 
> https://docs.fedoraproject.org/en-US/fesco/Policy_for_orphan_and_retired_packages/#_orphaning_and_retiring_packages

I'm not sure we want to CC epel-devel on these, perhaps we could have a
script that processes them once a week or so and sends a summary to the
list? But I am not sure how much volume we would expect here. ;( 

I wonder if we could get some cycles from developers to adjust
pagure-dist-git for this case to make it more self-service. 
(taking orphan packages over). 

kevin


signature.asc
Description: PGP signature
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: [rawhide] ICU upgrade to 71.1

[Kevin Fenzi]

On Fri, Aug 05, 2022 at 07:17:03PM +0200, Dan Horák wrote:
> 
> I see 20-30% of steal time in the VM building webkit, which should mean
> the hypervisor's capacity is at/over limit :-( It would benefit from
> having more physical CPUs.

In the past, steal time has been caused by other lpars needing resources
I think. At least in the runup to RHEL9, the steal % was very high and I
was told it was due to other lpars doing QE work on rhel9. 

I do see about 18-22% stolen time on the hypervisor, and there's some
cpus showing 100% idle. ;(  

I can try asking for more cpus, but unlikely to happen immediately. 

kevin


signature.asc
Description: PGP signature
___
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: [rawhide] ICU upgrade to 71.1

[Kevin Fenzi]

On Fri, Aug 05, 2022 at 05:30:14PM +0200, Dan Horák wrote:
> On Thu, 4 Aug 2022 16:55:15 +0200
> Dan Horák  wrote:
> 
> > On Thu, 4 Aug 2022 23:46:44 +0900
> > Mamoru TASAKA  wrote:
> > 
> > > Frantisek Zatloukal wrote on 2022/08/02 23:17:
> > > > Hmm,
> > > > 
> > > > I am really sorry for this, I'd messed up a lot somehow.
> > > > 
> > > > I'll take a deeper look tomorrow morning, but from a quick look:
> > > > - webkit is now being built against the new icu, passed on i686 of> 
> > > > architectures, it'll hopefully be done before the next compose.
> > > 
> > > So looks like the rebuild of webkit2gtk3 won't finish on s390x -
> > > even after 51 hours:
> > > 
> > > https://koji.fedoraproject.org/koji/taskinfo?taskID=90394095
> > > 
> > > The above link says there are multiple buildroots. What does it mean?
> > > s390x build is killed and repeated due to some specific issue on
> > > s390x server?
> > 
> > usually the build killed and restarted due OOM, but this is weird as
> > Michael's previous build finished in ~6 hours 
> 
> I have moved the task to another builder and it is finishing right now.
> 
> Kevin, seems the z/VM builders are now more performant than the KVM
> ones ...

I do not think thats the case. The build you moved OOMed again after
that I am pretty sure. 

So, I have rebalanced the kvm ones. 

before: 

25 builders, 2 cpus and 13GB memory

after: 

20 builders, 3 cpus and 17GB memory.

Hopefully that will make these larger builds more happy. 
If not, we can adjust more.

kevin


signature.asc
Description: PGP signature
___
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: Fedora 37 mass rebuild complete

[Kevin Fenzi]

On Tue, Aug 02, 2022 at 01:32:07PM +0200, Miro Hrončok wrote:
> > 
> > Could you please share a link to the existing script?
> > 

https://pagure.io/releng/blob/main/f/scripts/mass_rebuild_file_bugs.py

I wonder if it's hitting a limit from bugzilla now, or perhaps a paging
issue? It definitely seems like it missed some. 

kevin


signature.asc
Description: PGP signature
___
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: Fedora 37 mass rebuild complete

[Kevin Fenzi]

On Mon, Aug 01, 2022 at 03:43:39PM -0700, Kevin Fenzi wrote:
> On Mon, Aug 01, 2022 at 03:04:50PM +0200, Miro Hrončok wrote:
> > On 25. 07. 22 17:57, Kevin Fenzi wrote:
> > > 21713 builds have been tagged into f37, there is currently 1144 failed
> > > builds that need to be addressed by the package maintainers. FTBFS bugs
> > > will be filed shortly.
> > 
> > Is there any place we can track the progress for this?
> > 
> > We need to link ~70 bugzillas to https://bugzilla.redhat.com/2107826
> 
> Not really. I guess I'll go see about doing it today. 

They should now be filed. 

This is just ones that failed to build. If someone wants to take a stab
and improving the script so we can also file bugs on the ones that
didn't make a valid src.rpm, that would be great. 

kevin


signature.asc
Description: PGP signature
___
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: Fedora 37 mass rebuild complete

[Kevin Fenzi]

On Mon, Aug 01, 2022 at 03:04:50PM +0200, Miro Hrončok wrote:
> On 25. 07. 22 17:57, Kevin Fenzi wrote:
> > 21713 builds have been tagged into f37, there is currently 1144 failed
> > builds that need to be addressed by the package maintainers. FTBFS bugs
> > will be filed shortly.
> 
> Is there any place we can track the progress for this?
> 
> We need to link ~70 bugzillas to https://bugzilla.redhat.com/2107826

Not really. I guess I'll go see about doing it today. 

kevin


signature.asc
Description: PGP signature
___
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: Upstream Release Monitoring - bug report

[Kevin Fenzi]

On Mon, Jul 25, 2022 at 01:54:38PM +0200, Michal Schorm wrote:
> Ah, It's a bit more tangled than I thought:
> 
> I've somehow got an impression that the upstream release monitoring is
> not related to Fedora, but I expected the BZ bot should be.
> So I've looked for a place to report issues other than
> https://github.com/fedora-infra/anitya/issues, as I thought it is the
> upstream (not Fedora related) part of the project. Only after
> following the link I've seen it is a GitHub repo in the "fedora-infra"
> namespace.
> 
> I've actually thought that the "monitoring status" option in the
> src.fedoraproject.org does something different (pings you when
> _anyone_ do a build or scratch-build of your package in KOJI - which
> would be useful for watching who touches your pkg and how)
> 
> The Pagure documentation doesn't seem to know about that field:
> https://docs.pagure.org/pagure/search.html?q=monitoring
> 
> So the 'Monitoring' value is likely what I am looking for, thanks ! :)


Just to clairfy some: 

anitya is release-monitoring.org. It's the thing that watches upstream
releases and keeps a mapping of upstream name to downstream distro
names. It does this for a bunch of distros, not just fedora. It emits
messages on the fedora-messaging bus when mappings are made/changed and
when updates are seen. It's configured only on it's web interface
(release-monitoring.org).

the-new-hotness is a seperate, but related application that listens for
messages about new upstream releases, checks to see if that package in
fedora wants to be notified/have scratch builds done for those. It
handles filing bugzilla bugs, and doing scratch builds (if desired).
It can be configured as you note on src.fedoraproject.org. 

If you want to watch activity on a package you want The little 'watch'
pulldown under The package description. You can set there if you want to
watch bugs, commits, both, etc. If you only wanted to watch koji builds,
you would need to set that in FMN ( apps.fedoraproject.org/notifications)

kevin
--
> 
> --
> 
> On Mon, Jul 25, 2022 at 1:46 PM Fabio Valentini  wrote:
> > This sounds like it's trying to process and create patches for *the
> > same version* again and again?
> > If that is the case, you might want to file a bug with anitya /
> > the-new-hotness, as that's certainly not its intended behaviour.
> 
> Right, will report.
> 
> --
> 
> Michal Schorm
> Software Engineer
> Core Services - Databases Team
> Red Hat
> 
> --
> 
> On Mon, Jul 25, 2022 at 1:46 PM Fabio Valentini  wrote:
> >
> > On Mon, Jul 25, 2022 at 1:39 PM Michal Schorm  wrote:
> > >
> > > Hello,
> > > I don't know where to go, so I'm trying here.
> > >
> > > Package 'mariadb-connector-c' [1] I maintain has upstream release
> > > monitoring enabled [2].
> > > The bot opened a BZ [3] for me to notify about a new upstream release
> > > - as expected.
> > >
> > > It tried to come up with a patch and try to scratch-build the package
> > > with the patch.
> > > However it failed.
> > > And now it tries again and again, failing every time. Littering the BZ
> > > ticket with more and more comments with zero value. Spamming people in
> > > CC every day or two.
> > >
> > > I want it to stop.
> > >
> > > Ideally, I would like the bot to stop trying making patches and doing
> > > scratch builds on all my packages at all. It's a wasted effort (and
> > > computing time; and KOJI resources).
> > >
> > > Is that possible?
> > > How?
> > >
> > > --
> > >
> > > I logged into the https://release-monitoring.org/ , but there doesn't
> > > seem to be any setting regarding that.
> >
> > release-monitoring.org only has a mapping from upstream projects to
> > Fedora package names, but Fedora-specific settings live on
> > src.fedoraproject.org.
> > So, if you go to
> > https://src.fedoraproject.org/rpms/mariadb-connector-c (you actually
> > linked that page yourself), and are logged in:
> >
> > In the left-hand pane, there's a combobox where you can select "No
> > monitoring", "Monitoring", and "Scratch builds".
> > It's currently set to "Scratch builds", but if you know that those
> > won't work, then change the setting to "Monitoring".
> > That will at least cut down the number of notifications.
> >
> > > And now it tries again and again, failing every time.
> >
> > This sounds like it's trying to process and create patches for *the
> > same version* again and again?
> > If that is the case, you might want to file a bug with anitya /
> > the-new-hotness, as that's certainly not its intended behaviour.
> >
> > Fabio
> > ___
> > 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

Fedora 37 mass rebuild complete

[Kevin Fenzi]

Hi all,

Per the Fedora 37 schedule[1] we started a mass rebuild for Fedora
37 on 2022/07/20. We did a mass rebuild for Fedora 37 for:

https://pagure.io/releng/issues?status=Open=mass+rebuild

The mass rebuild was done in a side tag (f37-rebuild) and moved over to
f37. Failures can be seen
https://kojipkgs.fedoraproject.org/mass-rebuild/f37-failures.html Things
still needing rebuilding
https://kojipkgs.fedoraproject.org/mass-rebuild/f37-need-rebuild.html

21713 builds have been tagged into f37, there is currently 1144 failed
builds that need to be addressed by the package maintainers. FTBFS bugs
will be filed shortly. Please be sure to let releng know if you see any
bugs in the reporting. You can contact releng in #fedora-releng on
libera.chat, by dropping an email to our list[2], joining
#releng:fedoraproject.org on Matrix, or filing an issue in pagure[3]

Regards,
Fedora Release Engineering

[1] https://fedorapeople.org/groups/schedule/f-N/f-N-key-tasks.html
[2] https://lists.fedoraproject.org/admin/lists/rel-eng.lists.fedoraproject.org/
[3] https://pagure.io/releng/



signature.asc
Description: PGP signature
___
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 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

Fedora 37 mass rebuild complete

[Kevin Fenzi]

Hi all,

Per the Fedora 37 schedule[1] we started a mass rebuild for Fedora
37 on 2022/07/20. We did a mass rebuild for Fedora 37 for:

https://pagure.io/releng/issues?status=Open=mass+rebuild

The mass rebuild was done in a side tag (f37-rebuild) and moved over to
f37. Failures can be seen
https://kojipkgs.fedoraproject.org/mass-rebuild/f37-failures.html Things
still needing rebuilding
https://kojipkgs.fedoraproject.org/mass-rebuild/f37-need-rebuild.html

21713 builds have been tagged into f37, there is currently 1144 failed
builds that need to be addressed by the package maintainers. FTBFS bugs
will be filed shortly. Please be sure to let releng know if you see any
bugs in the reporting. You can contact releng in #fedora-releng on
libera.chat, by dropping an email to our list[2], joining
#releng:fedoraproject.org on Matrix, or filing an issue in pagure[3]

Regards,
Fedora Release Engineering

[1] https://fedorapeople.org/groups/schedule/f-N/f-N-key-tasks.html
[2] https://lists.fedoraproject.org/admin/lists/rel-eng.lists.fedoraproject.org/
[3] https://pagure.io/releng/



signature.asc
Description: PGP signature
___
devel-announce mailing list -- devel-announce@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-announce@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fedora 37 mass rebuild started

[Kevin Fenzi]

As a quick and dirty thing I took the f37-needs-rebuild list and the
f37-failed to build list and found things that were only on the
needs-rebuild list. 

I then filtered out the ones we don't try and mass rebuild (shim,
kernel, grub2, etc) and the silly ones we have like Fedora-Live-Xfce
(placeholder for the live image) and got a list with 191 entries. 

So these didn't fail after making a src.rpm, but might have failed then.
I also see a lot of these that are epel specific, but arent retired on
rawhide. There also may have been a very few that didn't get tried
because the fedora-messaging cluster was down. ;( 

aardvark-dns
aboot
andy-super-great-park
anthy-unicode-epel
askbot-plugin-authfas
autoconf268
aws-c-cal
bash-completion-extras
bird2
boost1.78
caribou0
Charliecloud
clang11.0
clap_generate_fig
community-mysql
compat-tidy
cube
cyrus-imapd
debootstrap
dnscrypt-proxy2
docker-swarm
double-conversion-epel
erlang-riak_ensemble
fizz
gcc-epel
gdl
generic-release
ghc8.2
ghc8.8
glibc32
gnome-commander
gnuplot44
golang-cloud-google
golang-github-apparentlymart-textseg
golang-github-bits-and-blooms-bloom
golang-github-btcsuite-btcd-btcec
golang-github-cloudflare-golz4
golang-github-datadog-sketches
golang-github-exchange-interface
golang-github-github-ssdb-gossdb
golang-github-go-stack-stack
golang-github-ipfs-bitswap
golang-github-ipfs-block-format
golang-github-ipfs-blockservice
golang-github-ipfs-blockstore
golang-github-ipfs-blocksutil
golang-github-ipfs-cmds
golang-github-ipfs-datastore
golang-github-ipfs-delay
golang-github-ipfs-ds-flatfs
golang-github-ipfs-ds-help
golang-github-ipfs-http-client
golang-github-ipfs-ipld-format
golang-github-ipfs-log-2
golang-github-ipfs-merkledag
golang-github-ipfs-peertaskqueue
golang-github-ipfs-util
golang-github-jbenet-cienv
golang-github-jbenet-goprocess
golang-github-jcmturner-aescts-2
golang-github-jcmturner-dnsutils-2
golang-github-jcmturner-goidentity-6
golang-github-jcmturner-gokrb5-8
golang-github-jcmturner-rpc-2
golang-github-logr-stdr
golang-github-stomp
golang-github-vinyldns-vinyldns
golang-gopkg-playground-validator-10
golang-grpc-go4
golang-jaytaylor.com-html2text
icecat
ignition-fuel-tools
inih-epel
iptables-epel
isis
jama
java-1.8.0-openjdk-aarch32
jd
kclock
keepassx2
kernel-headers
keysmith
libappindicator-sharp
libburn1
libgit2_0.26
LibRaw-epel
libxslxwriter
lightdm-gtk
linux-firmware
lorax-templates-rhel
lua5.1-lpeg
mesa-demos-epel
mesos
mingw-libidl
mingw-windows-default-manifest
mingw-wine-gecko
mingw-win-iconv
mingw-winpthreads
mingw-winstorecompat
mingw-wpcap
mingw-wxWidgets
minizip1.2
module-build-macros
monafont
netcdf-fortran
nodejs-async-lock
nvidia-texture-tools
openh264
openmolar
osbs-client
osmo
perl-Math-Calc-Units
perl-Math-Cartesian-Product
perl-Math-ConvexHull
perl-Math-ConvexHull-MonotoneChain
pesign-test-app
php53-simplepie
proj
proxygen
pycairo-epel
python26-msgpack
python38-coverage
python38-hvac
python38-hypothesis-epel
python38-netaddr
python38-ntlm-auth-epel
python38-pynetbox
python38-pytest-helpers-namespace
python38-requests_ntlm-epel
python38-setuptools_scm_git_archive
python3-cryptography-vectors
python3-doctutils
python3-greenlet
python3-gssapi
python3-kitchen
python3-prctl
python3-pyasn1
python3-zope-event
python-antlr4-python3-runtime
python-asana
python-charon
python-dataclasses
python-django-oauth-toolkit
python-gear
python-genshi06
python-hbmqtt
python-hudman
python-k2hr3-osnl
python-neutronclient
python-osa
python-proton-client
python-pysam
python-satyr
python-tqdm
python-webob1.4
python-yubikey-manager
qtscrob
quazip-qt5
realtime-setup
redhat-rpm-config
retrace-client
R-TH-data
rust-bat
rust-gag
rust-git-delta
rust-gitui
rust-platform-info
rust-pwd
rust-syntect4
rust-sysinfo0.19
rust-uucore
rust-wasi-cap-std-sync
rust-wasi-tokio
rust-wasmtime-wasi
sahara-image-elements
serafettin-cartoon-fonts
solo3
status-report
systemd-boot
termbox
tinygo
tnt
trace-gui
twincam
vera++
vttest
wasmedge
webkit2gtk3
xfce4-soundmenu-plugin
xsetpointer
zeek

kevin


signature.asc
Description: PGP signature
___
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: Fedora 37 mass rebuild started

[Kevin Fenzi]

On Sat, Jul 23, 2022 at 02:49:53PM -0600, Jerry James wrote:
> On Sat, Jul 23, 2022 at 2:35 PM Kevin Fenzi  wrote:
> > The packages were signed and the sidetag is through to f37.
> >
> > Also, the signing queue is all caught up.
> 
> Can you take a look at gap-4.11.1-5.fc37?  It's been in
> f37-signing-pending for over 2 days now.

Yeah, fixed. I retagged all the things in the signing pending tag. 

However, this might cause some really old updates to land...
so keep an eye out for that. 

> > The only things left for the mass rebuild are a few of the larger
> > packages (ceph, webkit, etc). Then we should be able to merge the
> > f37-rebuild tag in and be done.
> 
> No build seems to have been submitted for ocaml-ppx-inline-test.  I
> just mention this in case there are other packages that were skipped.

Yeah, this the old 'if koji can't rebuild the src.rpm, it never shows up
as a 'build'' thing. ;( 

https://koji.fedoraproject.org/koji/taskinfo?taskID=89838907

It looks like it couldn't download src. ;( 

DEBUG util.py:443:  curl: (35) OpenSSL SSL_connect: Connection reset by peer in 
connection to src.fedoraproject.org:443
DEBUG util.py:596:  Child return code was: 35

So, just do a build like normal in rawhide and it should be good. 

There's a releng ticket on this issue...

https://pagure.io/releng/issue/8601

Looks like there was some support added to koji to query these, but the
mass rebuild failures script never got updated to try and use it? ;( 

kevin


signature.asc
Description: PGP signature
___
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: Fedora 37 mass rebuild started

[Kevin Fenzi]

On Sat, Jul 23, 2022 at 10:43:38PM +0200, Fabio Valentini wrote:
> 
> Can confirm, looks all good now, thanks!
> 
> BTW, I'd like to know whatever magic you did to fedora notifications.
> Because it apparently kept chugging on right through the mass rebuild,
> and is now caught up again. :)

Yeah, I am pretty amazed by that. ;) 

Currently it's pretty heavily patched... we still want to move to the
python3 one. Hopefully next week. 

kevin


signature.asc
Description: PGP signature
___
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: Fedora 37 mass rebuild started

[Kevin Fenzi]

On Sat, Jul 23, 2022 at 10:09:50AM -0700, Kevin Fenzi wrote:
> On Sat, Jul 23, 2022 at 10:37:39AM +0200, Fabio Valentini wrote:
...snip...
> 
> So, as long as that sidetag update goes out all should be fine. 

The packages were signed and the sidetag is through to f37. 

Also, the signing queue is all caught up. 

The only things left for the mass rebuild are a few of the larger
packages (ceph, webkit, etc). Then we should be able to merge the
f37-rebuild tag in and be done. 

kevin


signature.asc
Description: PGP signature
___
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: Fedora 37 mass rebuild started

[Kevin Fenzi]

On Sat, Jul 23, 2022 at 10:37:39AM +0200, Fabio Valentini wrote:
> On Fri, Jul 22, 2022 at 10:30 PM Kevin Fenzi  wrote:
> >
> > We have had several issues in the last few days sadly.
> > I think your build ran into systemd-oomd running on some builders after
> > I had disabled it and thought I stopped it, but didn't. ;(
> >
> > Anyhow, the thing to do here if it builds is just go ahead abd build it
> > into rawhide like normal.
> 
> Looks like the package signing queue is getting really really long?

It has, but only just this morning. ;( 

https://admin.fedoraproject.org/collectd/bin/graph.cgi?hostname=rabbitmq_slash_pubsub;plugin=queues;plugin_instance=robosignatory;type=messages;begin=-86400

> I built an update for several packages and submitted it to rawhide a
> day before the mass rebuild script reached packages starting with "r".
> But it appears that the signing queue is getting so long that the
> update still hasn't been pushed to stable (almost two days since I
> submitted it to bodhi, still stuck in "pending" because of unsigned
> builds):
> https://bodhi.fedoraproject.org/updates/FEDORA-2022-a7ad4a64b5

I fear what might have happened is that you were doing this at a time
when we were having problems with our rabbitmq cluster, so the messages
might have been lost. ;( 

I retagged them into the signing pending tag, but of course signing is
backed up, so will take a while to get to them. Probibly later today.
 
> And now the mass rebuild script has pushed commits to all these
> packages and submitted them individually, which of course, failed.
> So should I just resubmit those failed builds once my bodhi update is
> finally signed and pushed to stable?

Should be no need if this update goes out. 
The script that will merge the f37-rebuild tag looks to see if there is
a build thats been tagged into f37 thats newer than the proposed one. If
there is, it just doesn't tag it, and in this case that build doesn't
exist even. ;) 

So, as long as that sidetag update goes out all should be fine. 

If it's still stuck after the signing queue is caught up, let me know
and I can look at it more to see why it's not moving. 

kevin


signature.asc
Description: PGP signature
___
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: Orphaned package dnstracer takeover

[Kevin Fenzi]

On Fri, Jul 22, 2022 at 04:26:28PM -, Jonathan Wright via devel wrote:
> Hi,
> 
> I'd like to take over the orphaned package dnstracer.  
> https://src.fedoraproject.org/rpms/dnstracer
> 
> I submitted a ticket with releng for this as there was no "take" button 
> present.
> 
> https://pagure.io/releng/issue/10915
> 
> My username is jonathanspw

The package was retired on Sun Oct 17 21:34:43 2021. 
Since thats more than 8 weeks, it needs a re-review: 

https://docs.fedoraproject.org/en-US/package-maintainers/Package_Retirement_Process/#claiming

So, submit and pass a review, then file a releng ticket to get it
unblocked. :) 

kevin


signature.asc
Description: PGP signature
___
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: Fedora 37 mass rebuild started

[Kevin Fenzi]

On Fri, Jul 22, 2022 at 02:24:21PM -0500, Maxwell G via devel wrote:
> On 22/07/22 09:08AM, Michael J Gruber wrote:
> > notmuch failed to build from source because of a strange test suite failure 
> > on ppc64le:
> > 
> > https://koji.fedoraproject.org/koji/taskinfo?taskID=89837091
> > 
> > The only failing test is a pytest run on the bindings
> > 
> > ```
> > T391-python-cffi: Testing python bindings (pytest)
> > FATAL: /builddir/build/BUILD/notmuch-0.36/test/T391-python-cffi.sh: 
> > interrupted by signal 15
> > ```
> > 
> > whereas other tests of those bindings work. What makes it even more strange 
> > is that for a scratch build all tests work on all architectures:
> > 
> > https://koji.fedoraproject.org/koji/taskinfo?taskID=89853627
> > 
> > Is there possibly a timing issue where tests on ppc64le happen to take "too 
> > long" and pytest gets killed?
> 
> It sounds like this might've been a transient issue, likely related to
> something on the builder, as it also worked fine when I scratch built
> it. The releng folks can probably tell you how to handle this and if you
> should rebuild it, just wait, or whatever. As Kevin said:
> 
> > You can contact releng in #fedora-releng channel on Libera.Chat, the
> > #releng:fedoraproject.org room on Matrix, or by dropping an email to
> > our list[2] or filing an issue in pagure[3].

Yeah. ;) 

We have had several issues in the last few days sadly. 
I think your build ran into systemd-oomd running on some builders after
I had disabled it and thought I stopped it, but didn't. ;( 

Anyhow, the thing to do here if it builds is just go ahead abd build it
into rawhide like normal. 

Hope that helps.

kevin


signature.asc
Description: PGP signature
___
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

Fedora 37 mass rebuild started

[Kevin Fenzi]

Hi all,

Per the Fedora f37 schedule[1] we have started a mass rebuild
on 2022-07-20 for Fedora f37. We are running this mass rebuild
for the changes listed in:

https://pagure.io/releng/issues?status=Open=mass+rebuild

This mass rebuild will be done in a side tag (f37-rebuild) and merged
when completed.

Failures can be seen
https://kojipkgs.fedoraproject.org/mass-rebuild/f37-failures.html


Things still needing rebuilding
https://kojipkgs.fedoraproject.org/mass-rebuild/f37-need-rebuild.html


FTBFS (Fails To Build From Source) bugs will be filed shortly after
the mass rebuild is complete.

Please be sure to let releng know if you see any bugs in the
reporting. You can contact releng in #fedora-releng channel on Libera.Chat,
the #releng:fedoraproject.org room on Matrix, or by dropping an email
to our list[2] or filing an issue in pagure[3].

This email template is also in https://pagure.io/releng if you wish to
propose improvements or changes to it.

Regards,

Fedora Release Engineering

[1] https://fedorapeople.org/groups/schedule/f-37/f-37-key-tasks.html
[2] https://lists.fedoraproject.org/admin/lists/rel-eng.lists.fedoraproject.org/
[3] https://pagure.io/releng/


signature.asc
Description: PGP signature
___
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 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

Fedora 37 mass rebuild started

[Kevin Fenzi]

Hi all,

Per the Fedora f37 schedule[1] we have started a mass rebuild
on 2022-07-20 for Fedora f37. We are running this mass rebuild
for the changes listed in:

https://pagure.io/releng/issues?status=Open=mass+rebuild

This mass rebuild will be done in a side tag (f37-rebuild) and merged
when completed.

Failures can be seen
https://kojipkgs.fedoraproject.org/mass-rebuild/f37-failures.html


Things still needing rebuilding
https://kojipkgs.fedoraproject.org/mass-rebuild/f37-need-rebuild.html


FTBFS (Fails To Build From Source) bugs will be filed shortly after
the mass rebuild is complete.

Please be sure to let releng know if you see any bugs in the
reporting. You can contact releng in #fedora-releng channel on Libera.Chat,
the #releng:fedoraproject.org room on Matrix, or by dropping an email
to our list[2] or filing an issue in pagure[3].

This email template is also in https://pagure.io/releng if you wish to
propose improvements or changes to it.

Regards,

Fedora Release Engineering

[1] https://fedorapeople.org/groups/schedule/f-37/f-37-key-tasks.html
[2] https://lists.fedoraproject.org/admin/lists/rel-eng.lists.fedoraproject.org/
[3] https://pagure.io/releng/


signature.asc
Description: PGP signature
___
devel-announce mailing list -- devel-announce@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-announce@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 proposal: Public release of the Anaconda Web UI preview image (Self-Contained Change proposal)

[Kevin Fenzi]

On Mon, Jul 18, 2022 at 01:30:14PM +0200, Jiri Konecny wrote:
> Hi Kevin,
> 
> Dne 16. 07. 22 v 21:35 Kevin Fenzi napsal(a):
> > ...snip...
> > > For this we will create a self-contained boot.iso style image with a
> > > built-in tar-payload (so that the image can work even without network
> > > access) based on the latest Anaconda upstream code.
> > What packages will be in this tar-payload?
> We are planning to use payload from F37 Workstation GA. So it will install
> fully functional Fedora 37. The side benefit will be that the payload is
> already tested.

Ah, ok. You might add this to the change page?

> > And can you use the boot.iso to do netinstalls against the network
> > respositories, or are you restricted to the tar-payload contents?
> Not yet, we are missing Software selection and Source management. This
> version is really a first usable image which enables to select disks and
> start the installation. However, it's a good base for us for future
> improvements so the ISO can be updated with new features and we can get
> feedback soon.

Makes sense. 
> > 
> > ...snip...
> > > == Scope ==
> > > * Proposal owners:
> > > The Anaconda team will setup and maintain an automated Web UI preview
> > > image creation pipeline, with the image being available via a web
> > > server on the Fedora infrastructure.
> > So, you will need space to place these images in Fedora Infrastructure
> > and nothing else right now from Infra?
> Yes, we just need a publicly accessible storage, where we can upload the
> ISO. Right now, we are thinking about
> https://fedorapeople.org/groups/anaconda/. Do you think it's a good idea
> Kevin or would you recommend us something else?

That would work ok I guess. We could also give you space in
https://dl.fedoraproject.org/alt/
Or an s3 bucket. Whatever works. 

kevin


signature.asc
Description: PGP signature
___
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: Koji ppc64le build failure

[Kevin Fenzi]

On Mon, Jul 18, 2022 at 11:59:49AM +0100, Richard W.M. Jones wrote:
> On Sun, Jul 17, 2022 at 12:50:01PM -0700, Kevin Fenzi wrote:
> > On Sun, Jul 17, 2022 at 08:34:30PM +0100, Richard W.M. Jones wrote:
> > > 
> > > https://koji.fedoraproject.org/koji/taskinfo?taskID=89618509
> > > 
> > > On ppc64le:
> > > FAIL: test-checkwrite.sh
> > > 
> > > There should be a core dump associated with this failure.  Is it
> > > possible someone with Koji access could look to see if this is still
> > > around and capture it?  (Even just a full stack trace would be useful)
> > > 
> > > We've been seeing this error occasionally (same test, only on ppc64le)
> > > for a few weeks.  I reserved a ppc64le machine at Red Hat last week
> > > and ran this test on basically exactly the same combination of
> > > software thousands of times, and it didn't fail even once in that
> > > time, so I'm out of ideas how to reproduce it for myself.
> > 
> > Core at: 
> > https://infrastructure.fedoraproject.org/infra/tmp/core.nbdkit.1000.9be14c7983c4418eb6245b3fd5719a79.2744149.165808588900.zst
> > 
> > Module libtasn1.so.6 with build-id 
> > 460fc6bd3f93e57e7d593080f58952f61cdb344a
> > Stack trace of thread 2744170:
> > #0  0x7fffa9b59b6c n/a (/usr/lib64/libc.so.6 + 0xb9b6c)
> > ELF object binary architecture: PowerPC64
> 
> Sorry, I realised that the core dump won't work without the
> executable.  Is /server/nbdkit still around?  (Note there's
> another "nbdkit" binary in the top build directory, which is _not_ the
> server.)

To circle back to the list, it sounds like you got it to happen locally?

kevin


signature.asc
Description: PGP signature
___
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: Koji ppc64le build failure

[Kevin Fenzi]

On Sun, Jul 17, 2022 at 08:34:30PM +0100, Richard W.M. Jones wrote:
> 
> https://koji.fedoraproject.org/koji/taskinfo?taskID=89618509
> 
> On ppc64le:
> FAIL: test-checkwrite.sh
> 
> There should be a core dump associated with this failure.  Is it
> possible someone with Koji access could look to see if this is still
> around and capture it?  (Even just a full stack trace would be useful)
> 
> We've been seeing this error occasionally (same test, only on ppc64le)
> for a few weeks.  I reserved a ppc64le machine at Red Hat last week
> and ran this test on basically exactly the same combination of
> software thousands of times, and it didn't fail even once in that
> time, so I'm out of ideas how to reproduce it for myself.

Core at: 
https://infrastructure.fedoraproject.org/infra/tmp/core.nbdkit.1000.9be14c7983c4418eb6245b3fd5719a79.2744149.165808588900.zst

Module libtasn1.so.6 with build-id 
460fc6bd3f93e57e7d593080f58952f61cdb344a
Stack trace of thread 2744170:
#0  0x7fffa9b59b6c n/a (/usr/lib64/libc.so.6 + 0xb9b6c)
ELF object binary architecture: PowerPC64

kevin


signature.asc
Description: PGP signature
___
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: F37 proposal: Public release of the Anaconda Web UI preview image (Self-Contained Change proposal)

[Kevin Fenzi]

...snip...
> 
> For this we will create a self-contained boot.iso style image with a
> built-in tar-payload (so that the image can work even without network
> access) based on the latest Anaconda upstream code.

What packages will be in this tar-payload?

And can you use the boot.iso to do netinstalls against the network
respositories, or are you restricted to the tar-payload contents?

...snip...
> 
> == Scope ==
> * Proposal owners:
> The Anaconda team will setup and maintain an automated Web UI preview
> image creation pipeline, with the image being available via a web
> server on the Fedora infrastructure.

So, you will need space to place these images in Fedora Infrastructure
and nothing else right now from Infra?

Looking forward to playing with it!

kevin


signature.asc
Description: PGP signature
___
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: pre-change: lower printk setting after switching to real root

[Kevin Fenzi]

On Fri, Jul 15, 2022 at 10:03:48AM -0400, Colin Walters wrote:
> We recently did https://github.com/coreos/fedora-coreos-config/pull/1840 for 
> Fedora CoreOS (more background: 
> https://github.com/coreos/fedora-coreos-tracker/issues/1244 ) and I'd like to 
> consider applying this to all Fedora editions.
> 
> There'd be no impact on desktop systems (commonly installed via Anaconda and 
> hence using `quiet`).  
> 
> The benefit is for server systems where we *do* want some kernel output at 
> boot, but once we've successfully booted we don't want to emit a message 
> every time podman/docker creates a bridge device for example.
> 
> Concretely today, I noticed that the RHEL 8.6 Cloud Guest image also does not 
> include `quiet` and so the kernel console log is full of the same spam at 
> runtime, and I think it makes sense to do this change across all Fedora 
> derivatives.

It sounds like a reasonable idea. I assume someone could override it
when/if they needed/wanted the more verbose messages?

I'd say write up a change on it. 

kevin


signature.asc
Description: PGP signature
___
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: [External] Re: F36 official respin iso for lenovo Z13 and Z16

[Kevin Fenzi]

On Wed, Jul 13, 2022 at 03:19:12PM -0400, Mark Pearson wrote:
> On 7/13/22 15:13, Kevin Fenzi wrote:
> > On Wed, Jul 13, 2022 at 02:34:12PM -0400, Mark Pearson wrote:
> >> Hi Fedora Devs,
> >>
> >> Would someone be able to help getting an official-respin done from F36
> >> latest please? Similar to what was done for the Carbons etc.
> >>
> >> We need one for the Z13 & Z16 preload. We're waiting on one FW fix but
> >> Fedora itself is in good shape (at least from my testing) so I want to
> >> get an image into the QA team so they can get started
> > 
> > Can you file a releng ticket on this?
> > 
> > https://pagure.io/releng>> 
> > Either releng can make one, or perhaps the Respins SIG has or is doing
> > one that will meet your needs. We can discuss that in the ticket. :) 
> > 
> No problem: https://pagure.io/releng/issue/10886
> 
> I did ping Mohan yesterday but thought he might be on PTO or swamped.

He's actually moved on to another group. :)

kevin


signature.asc
Description: PGP signature
___
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: F36 official respin iso for lenovo Z13 and Z16

[Kevin Fenzi]

On Wed, Jul 13, 2022 at 02:34:12PM -0400, Mark Pearson wrote:
> Hi Fedora Devs,
> 
> Would someone be able to help getting an official-respin done from F36
> latest please? Similar to what was done for the Carbons etc.
> 
> We need one for the Z13 & Z16 preload. We're waiting on one FW fix but
> Fedora itself is in good shape (at least from my testing) so I want to
> get an image into the QA team so they can get started

Can you file a releng ticket on this?

https://pagure.io/releng

Either releng can make one, or perhaps the Respins SIG has or is doing
one that will meet your needs. We can discuss that in the ticket. :) 

kevin


signature.asc
Description: PGP signature
___
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: Shall we add a limit to number of packages in a Bodhi update?

[Kevin Fenzi]

My 2 cents... we should try and get bodhi (and the rest of the pipeline)
to work with these large updates if at all possible. 

Having releng merge tags works of course, but as Adam pointed out, it
skips our CI and feedback testing area. Additionally, it's more work to
releng folks and more waiting around time for requesters. 

We also have some KDE updates that were over 300 builds. 
(like
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-NEXT-2022-a6c0f04770
)
I'm sure there have been others. 

kevin


signature.asc
Description: PGP signature
___
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: Once again, more than 8 days delayed notifications

[Kevin Fenzi]

crossposting to infra list to keep folks there in the loop...

On Tue, Jul 12, 2022 at 02:53:24PM +0100, Jonathan Wakely wrote:
> On Mon, 11 Jul 2022 at 15:06, Stephen Smoogen wrote:
> > That said, IRC is actually one of the fastest ones we can push to.
> 
> Is https://apps.fedoraproject.org/notifications/ really still sending
> notifications to freenode though?
> 
> Hasn't everybody moved to libera?

yes. It's just incorrect/out of date there. 

Let me sum up what I know and perhaps I can point people to this post
later. :) 

The current state is bad. We know it's bad. We have known for a long
time that it's bad. It's bad for all of the following reasons: 

* It's running a python2 codebase. Upstream development/PR's have long
ago moved to python3, but thats not the version we current have
deployed. 

* It's heavily tied to the old account system. Several of us spent many
hours last week trying to untangle it. I think we might be getting close
now, but it's really hard to tell.

* It's pretty heavily tied to fedmsg (not fedora-messaging). fedmsg
still works of course, but it's another layer of confusion.

* It's rules/interface lets you do all kinds of cool things, but it's
complex and confusing to most everyone that tries to use it.

* It's running on a end of life OS version. ;( 

* In order to try to scale it has a number of layers of things which
makes it hard to debug. For example it uses redis, it's own rabbitmq
instance with a bunch of queues, multiple workers talking to all those
things and multiple backends for irc and email. You might think
performance shouldn't be a big deal, but when you have thousands of
users, each with their own custom rulesets, that means you have to
potentially match a incoming message against every single ruleset of
every user and you have to do it fast enough to keep up with the
incoming flow of messages and the outgoing flow of notifications. :( 

Short term, I would like to hope that the python2/current version can
catch mostly up. (Its currently 4 days behind). Once it does, I would
very much like to try switching to the python3 version. It has a lot of
the problems the existing one does, but it should also have some
advantages, like running on a supported OS, much easier to release and
deploy new versions, etc.

Longer term, we are just now starting an iniative to re-write FMN from
the ground up. It's going to be a while until it's ready, but I really
hope it will be much better for everyone involved. Better/easier
interface, much better handling of messages, etc.

Hope that helps clarify things...

kevin


signature.asc
Description: PGP signature
___
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: Fedora SCM requests on the weekend

[Kevin Fenzi]

On Sun, Jul 10, 2022 at 06:34:11PM +0200, Simon de Vlieger wrote:
> Would you need any help regarding the automation?

Well, I'm not doing the implementation there, but we can always use
help. ;) 

I think the code is all there now, we were wanting to get staging
working to test it before rolling it out. 

It's being added as a toddler ( https://pagure.io/fedora-infra/toddlers
) which is basically a framework for things that listen to the message
bus and act on messages or run from time to time to do things. 

CCing Michal here for comment on where we can use help here. 

kevin
--
> On Sat, Jul 9, 2022, at 8:10 PM, Kevin Fenzi wrote:
> > On Fri, Jul 08, 2022 at 01:02:15PM -, Mukundan Ragavan wrote:
> >> > On Sun, Jul 03, 2022 at 12:11:40PM +0200, Fabio Valentini wrote:
> >> > 
> >> > That said, until then I can try and run things on weekends. 
> >> 
> >> Is there a formal process to volunteer to hold the keys to the kingdom?
> >
> > Yes. Basically one of the existing group members nominates someone, and
> > all the existing group members vote on adding them. 
> >
> > However, at this point we are close to automating it, so not sure it's
> > worth adding more folks. We could though if it isn't automated soon...
> >
> > kevin
> >
> > ___
> > 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
> >
> > Attachments:
> > * signature.asc
> ___
> 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


signature.asc
Description: PGP signature
___
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: Fedora SCM requests on the weekend

[Kevin Fenzi]

On Fri, Jul 08, 2022 at 01:02:15PM -, Mukundan Ragavan wrote:
> > On Sun, Jul 03, 2022 at 12:11:40PM +0200, Fabio Valentini wrote:
> > 
> > That said, until then I can try and run things on weekends. 
> 
> Is there a formal process to volunteer to hold the keys to the kingdom?

Yes. Basically one of the existing group members nominates someone, and
all the existing group members vote on adding them. 

However, at this point we are close to automating it, so not sure it's
worth adding more folks. We could though if it isn't automated soon...

kevin


signature.asc
Description: PGP signature
___
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

signing vault down (2022-07-04)

[Kevin Fenzi]

Greetings. 

We were having some issues with the management interface on our primary
signing vault. The server was power cycled, but the management is still
not functioning, and now the server isn't processing signing requests
further. 

Due to the US holidays there's no one on site right now, but we will
hopefully have someone there early tomorrow morning to troubleshoot and
bring things back up. 

Until this server is back up, builds will queue up in signing/pending
koji tags and not move forward. This means they will not land in the
buildroot or be available as updates. Once the server is processing again the
backlog should be processed, so there's no need to do anything special. 

Thank you for your patience. 

kevin


signature.asc
Description: PGP signature
___
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 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

signing vault down (2022-07-04)

[Kevin Fenzi]

Greetings. 

We were having some issues with the management interface on our primary
signing vault. The server was power cycled, but the management is still
not functioning, and now the server isn't processing signing requests
further. 

Due to the US holidays there's no one on site right now, but we will
hopefully have someone there early tomorrow morning to troubleshoot and
bring things back up. 

Until this server is back up, builds will queue up in signing/pending
koji tags and not move forward. This means they will not land in the
buildroot or be available as updates. Once the server is processing again the
backlog should be processed, so there's no need to do anything special. 

Thank you for your patience. 

kevin


signature.asc
Description: PGP signature
___
devel-announce mailing list -- devel-announce@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-announce@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fedora SCM requests on the weekend

[Kevin Fenzi]

On Sun, Jul 03, 2022 at 12:11:40PM +0200, Fabio Valentini wrote:
> On Sun, Jul 3, 2022 at 11:36 AM Ralf Corsépius  wrote:
> >
> > Am 03.07.22 um 10:46 schrieb Benson Muite:
> > > Maybe there are contributors where the working week is Sunday-Thursday?
> >
> > I feel, Fedora's leadership has forgotten, that Fedora is a
> > international community project with people being located around the
> > globe, which means there are quite a few people, who work on Fedora in
> > their spare time, i.e. on "week ends" and on "US holidays".
> 
> There's an ongoing effort to automate this process (mostly validation
> of the request ticket and the review request bugzilla), so only
> "exceptions" need to be processed by an actual person. This should
> reduce the average waiting time for a new dist-git repo by a lot, and
> it also doesn't depend on anybody sitting at their desk.

yeah, I am hoping once we get it automated we can have it trigger on
message bus messages, so maintainers would only have to wait a few
minutes after request (in the case that all checks pass/no exceptions).

That said, until then I can try and run things on weekends. 
No promises, but I will try and do so. 

kevin


signature.asc
Description: PGP signature
___
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: Bugzilla: You can't ask Lennart Poettering because that account is disabled.

[Kevin Fenzi]

On Sun, Jul 03, 2022 at 11:52:26AM +0200, Marius Schwarz wrote:
> Am 03.07.22 um 04:02 schrieb Neal Gompa:
> > On Sat, Jul 2, 2022 at 8:52 PM Kevin Kofler via devel
> >  wrote:
> > > Kevin Kofler via devel wrote:
> > > > The e-mail address reaches nowhere
> > > or actually, does it still work? Have you tried it? I assume that the fact
> > > that the Bugzilla account was disabled means he has left Red Hat and hence
> > > the @redhat.com e-mail address has also become invalid, but I might be
> > > mistaken.
> > > 
> > That is what that means.
> 
> So, someone could cross check with the account db before setting the
> assignee and skip disabled accounts? 

I'm not sure there's a easy way to get this info, but sure. 
Filed https://pagure.io/fedora-infra/toddlers/issue/106 on it. 

> If none is available, set QA as
> assignee, because it is part of QA to see, that bugreports are handled (not
> by the qa itself ofcourse).

There isn't a 'qa' asignee, nor do they have cycles to handle every bug
report (there's a lot more package maintainers than qa group folks). 

> Back to the actual problem: can someone grab that bug and handle it pls?

Possibly belegdol can, I don't know if he's active or interested in that
package anymore. 

Failing that, file upstream?

kevin


signature.asc
Description: PGP signature
___
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: Bugzilla: You can't ask Lennart Poettering because that account is disabled.

[Kevin Fenzi]

On Sat, Jul 02, 2022 at 05:31:13PM -0500, Maxwell G via devel wrote:
> On Saturday, July 2, 2022 3:11:44 PM CDT Kevin Fenzi wrote:
> > On Sat, Jul 02, 2022 at 11:54:17AM -0500, Maxwell G via devel wrote:
> > > On Saturday, July 2, 2022 10:01:18 AM CDT Michael Catanzaro wrote:
> > > > This is an extremely common problem in Fedora: the de facto maintainer
> > > > is not the main admin, and so the bugs are assigned to the wrong
> > > > person. Ideally we would automatically orphan a package if the main
> > > > admin does not have any commits to the package for a certain period of
> > > > time, e.g. three years.
> > > 
> > > It would help if other people besides the main admin could change the
> > > Bugzilla assignee. After all, if the main admin is non-responsive, it's
> > > going to be difficult to get them to do it.
> > 
> > I'm not sure the main admin matters as much as this thread indicates?
> > All the other maintainers of the package are CC'ed, in this case
> > belegdol.
> 
> Maybe the main admin isn't so important, but the Bugzilla assignee is. 
> Packages should be assigned to the person who is actually maintaining it. 
> This 

Well, what if it's 2 people and they trade off? Or 3 ? or 4?
Or some people handle bugs in one area and others in another... having
only one 'assignee' is kind of limiting. ;( 

> makes it so bugs are more likely to be addressed. Then, the bugs will also 

I'm not sure that it makes bugs more likely to be addressed. 
The only difference between assignee and someone on cc is what field
bugzilla shows. They both get email, no?

> show up in the "Open bugs assigned to me" link on the Bugzilla homepage[1] 
> for 
> the actual maintainer. This is more important for EPEL than Fedora proper. 
> For 
> packagers who don't care about EPEL, EPEL bugs should be assigned to the co-
> maintainer (or the epel-packagers-sig) who actually maintains the EPEL 
> branches; the latter should be held responsible to fix bugs and be the one 
> who 
> is NEEDINFO'd (when/if that happens), not the Fedora maintainer. It seems 
> like 
> there is at least some agreement in this area[2].

Ah, I never use that anymore. 
I tend to use command line 'bugzilla query' or 
https://packager-dashboard.fedoraproject.org/
along with emails.

But perhaps you're right as I have a lot of bugs and could probibly do
better prioritizing.

I personally don't like NEEDINFO. We don't have any common perception of
when it should be used and it can be used by anyone. :( I only use
needinfo on things that are time sensitive and some specific information
is required from the needinfo target. Like "can you fix this in time to
do a new compose before go/no-go". Others use it for an implied 'do you
plan to fix this bug', others 'it's been a while and you didn't get to
this bug so are you going to?'. Some people even set it right away when
the bug was filed, not leaving any time for 'normal' processing.

When/if we move off bugzilla we should take all these considerations
into what we end up choosing and ways to make these workflows better.

kevin


signature.asc
Description: PGP signature
___
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: Bugzilla: You can't ask Lennart Poettering because that account is disabled.

[Kevin Fenzi]

On Sat, Jul 02, 2022 at 11:54:17AM -0500, Maxwell G via devel wrote:
> On Saturday, July 2, 2022 10:01:18 AM CDT Michael Catanzaro wrote:
> 
> > This is an extremely common problem in Fedora: the de facto maintainer
> > is not the main admin, and so the bugs are assigned to the wrong
> > person. Ideally we would automatically orphan a package if the main
> > admin does not have any commits to the package for a certain period of
> > time, e.g. three years.
> 
> It would help if other people besides the main admin could change the 
> Bugzilla 
> assignee. After all, if the main admin is non-responsive, it's going to be 
> difficult to get them to do it.

I'm not sure the main admin matters as much as this thread indicates?
All the other maintainers of the package are CC'ed, in this case
belegdol.
> 
> > To avoid being removed you could simply push an
> > empty commit.
> 
> The problem with empty commits is that they cause a release bump when 
> rpmautospec is used which probably isn't desired. I guess this isn't the end 
> of the world.
> 
> There are also some packages which legitimately haven't been updated upstream 
> in three years. 

This has been discussed a number of times in the past, most recently the
discussion caused a policy to remove inactive provenpackagers. 

In any case I don't think setting needinfo on someone who is not working
on your bug will help much. Most likely they would ignore the needinfo
as well or show up and tell you they don't have cycles to work on the
bug and clear it. 

More effective would likely be refiling upstream and seeing if they
could address it. all IMHO. 

kevin


signature.asc
Description: PGP signature
___
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: side-tag including other side-tag ?

[Kevin Fenzi]

On Sat, Jun 25, 2022 at 08:53:03PM +0100, Sérgio Basto wrote:
> On Wed, 2022-06-22 at 08:52 -0700, Kevin Fenzi wrote:
> > On Tue, Jun 21, 2022 at 01:47:33PM -0500, Maxwell G via devel wrote:
> > > On Monday, June 20, 2022 10:02:00 AM CDT Sérgio Basto wrote:
> > > > Is is possible include builds of one side-tag into other side-tag
> > > > ?
> > > 
> > > It is also possible to `koji tag-build [dest side tag] [NEVR(s)
> > > from other 
> > > side tag]`, which might work for your use case. I suppose setting
> > > one side tag 
> > > to inherit builds from another one would require releng, as Vit
> > > said.
> > 
> > Yeah, I don't know that there's any good technical answer here. 
> > 
> > We need to know that a side tag is in progress and a another side tag
> > has rebuilt that in progress work and is trying to merge. 
> > 
> > Keeping side tags short lived will help this as will communicating
> > with
> > others when you see them rebuild your in progress work. 
> 
> 
> So, is not a problem ? do : 
> 
> - koji tag-build ["2nd side tag"] [NEVR(s) from "1st side tag"] 
> 
> when 2nd side tag is finished we can do:
> 
> - koji untag-build ["2nd side tag"] [NEVR(s) from "1st side tag"]
> 
> After "1st side tag" submitted to bodhi, we can submit "2nd side tag".
> 
> The question is more if it is allowed to me ? tag and untag builds in
> my own side tag 

Yes, you can. 

However, I am not sure this really helps much.

Say you have a sidetag for libfoo. 
You do a bunch of builds, but there's a few things you need to fix, so
the sidetag is still there. 

Another side tag is created for say a python mass rebuild. 
A bunch of things are rebuilt. 

Now, you could tag the new python and deps you need from it into your
side tag and rebuild things, but that only really helps if you merge
your sidetag at the same time as the python sidetag. If they merge
before yours, you still need to rebuild your packages again that have
python deps. 

Anyhow, I think the answer here is more communication... 
if you have a sidetag and a bunch of builds done in it and you notice
someone else doing rebuilds in a side tag, talk to them and coordinate
landing things so the second one isn't full of broken builds. 

kevin


signature.asc
Description: PGP signature
___
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: nfs4-acl-tools

[Kevin Fenzi]

On Thu, Jun 23, 2022 at 09:53:40AM -0400, Steve Dickson wrote:
> Hello,
> 
> I just took over the maintership of nfs4-acl-tools
> and it appears the command has not been part
> of Fedora since f32.

How do you mean 'part of fedora'? The package isn't retired or blocked,
it's available in the repos (although it failed to build in the f36 mass
rebuild). 

> Granted there has not been any upstream activity
> until now, but is there a way to get back into,
> at least, rawhide?

You should just be able to commit and get it building in rawhide and
that would go out in the next compose. 

kevin


signature.asc
Description: PGP signature
___
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: [Container-sig] About Fedora containers

[Kevin Fenzi]

On Thu, Jun 23, 2022 at 09:11:13AM -0400, Blaise Pabon wrote:
> I wonder if, rather than Github, we should consider a more "open source"
> toolchain, eg opendev.org, gitlab, etc. to be more consistent with
> Fedora's  "free" vision?

Not sure what github has to do with things here? 

quay is open source... althought quay.io is a Red Hat run instance of
that. 

kevin
--
> 
> On Wed, Jun 22, 2022 at 11:57 AM Kevin Fenzi  wrote:
> 
> > On Tue, Jun 21, 2022 at 03:41:47PM -0400, Matthew Miller wrote:
> > > On Mon, Jun 20, 2022 at 08:21:48AM +0200, Lumír Balhar wrote:
> > > > Because we had a lot of troubles with Fedora infra for container
> > > > images (I can provide more details, if you want), we have decided to
> > > > move our containers to https://quay.io/organization/fedora.
> > >
> > > I wonder if we should just... make this official? It seems like a pretty
> > > easy way to create and maintain an official library of layered images
> > which
> > > are made of Fedora packages — like, some language-base ones like golang
> > or
> > > python, plus nginx, apache, postgresql, etc.
> >
> > Yes, thats the plan... but as always it's not just "flip a switch and
> > drive on". We need to make sure all the features we use are available at
> > quay.io, that tooling has changes so we can push there, etc.
> >
> > https://pagure.io/fedora-infrastructure/issue/10386
> >
> > Note that this is just moving things in our registry over there and
> > pointing everyone to it so we can get out of the registry business, we
> > haven't looked at building the containers there or the like. We are
> > hoping osbuilder will help us here (or osbs 2.0).
> >
> > kevin
> > ___
> > 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
> >
> 
> 
> -- 
> LinkedIn <https://www.linkedin.com/in/blaisepabon/>  |  Quora
> <https://www.quora.com/profile/Blaise-Pabon>  |  Github
> <https://github.com/blaisep>
> “If you want to go fast, go alone. If you want to go far, go
> together.” --African
> proverb

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



signature.asc
Description: PGP signature
___
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: Plan / proposal: enable openQA update testing and potentially gating on Rawhide updates

[Kevin Fenzi]

On Wed, Jun 22, 2022 at 06:18:08PM -0700, Adam Williamson wrote:
> On Thu, 2022-06-09 at 12:48 -0700, Adam Williamson wrote:
> > Hi folks!
> ...
> > I think doing this could really help us keep Rawhide solid and avoid
> > introducing major compose-breaking bugs, at minimal cost. But it's a
> > significant change and I wanted to see what folks think. In particular,
> > if you find the existing gating of updates for stable/branched releases
> > to cause problems in any way, I'd love to hear about it.
> > 
> > Thanks folks!
> 
> One thing I forgot to mention in the original email, the benefit here
> isn't theoretical - I've already caught several Rawhide-breaking bugs
> early, or been able to identify the cause more easily, because we have
> the tests running in staging. Here's an example I just caught: a new
> popt version that was sent out today seems to break authselect, which
> is a critical problem and breaks all new installs:
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=2100287
> 
> if nirik catches my message in time before the next compose runs, he'll
> be able to untag the new build and the compose won't be completely
> broken. If we had this testing deployed in prod and gating turned on,
> the update would be blocked automatically.

It's been untagged from rawhide and eln. 

kevin


signature.asc
Description: PGP signature
___
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: [RFC] Build tag in RPM: from NVR to NVRB

[Kevin Fenzi]

On Wed, Jun 22, 2022 at 11:09:13AM -, Michael J Gruber wrote:
> > 
> > I also think that every package change (including rebuild) must be 
> > tracked in changelog.
> 
> I think that convolution is at the very heart of the problem:
> 
> As it is, dist-git tracks "packaging sources", i.e. spec and source hashes or 
> files, and this determines the content of the src.rpm and its version.
> 
> What you get when you build a binary rpm from that src.spm depends very much 
> on the environment. And that environment is not reflected in the version nor 
> in the built rpm (besides Build Host and Date).

Well, it's reflected in the requires/provides/contents of the rpm too
though right?

If I build foo-1.0-1 against libbar-2.0-1 and then again against
libbar-4.0-1 its going to require different libs at install/run time.

> We sometimes still are in the old "dist-cvs mindset" where cvs really was not 
> used as a vcs at all, but as as a way to drive the build infrastructure. But 
> that mindset will not serve as any longer. We see that problem with every 
> mass rebuild, such as now with pyth 3.11: Basically, one has to grep the 
> changelog, i.e. unstructured textual information, to find out which pakcage 
> has been rebuilt. If you built your package in rawhide after py3.11 was 
> merged but didn't have that changelog entry it got rebuilt again, with an 
> extra changelog entry. (If you pushed a fake changelog entry before the merge 
> then...). Merge rawhide into f36 to get clean dist-git branches and you have 
> a wrong/misleading changelog entry. (No, there is no py3.11 nor rebuild on 
> f36.)

Well, this proposal would try and inject some 'build changelog', but I'm
not sure that really tells the entire story either. ;( 

> In addition, you don't know which defines were in effect during a build. 
> (rpkg kind of solves that by having unparsed and parsed spec, at least for 
> the rpkg macros.)
> 
> I really think we need to stop abusing spec/changelog for things which are 
> purely buildroot related. Let dist-git track whatever is needed to adjust the 
> *package(ing)* to newer buildroots. Let the binary rpm track what buildroot 
> it has been built against (be it a builtroot identifier/hash, macro settings 
> used etc), or track it in koji/bodhi where the binary rpm has been built 
> resp. the update has been pushed.

I'm not convinced. 

This adds a lot to complexity... there's yet another place to look for
changes, a number to look at to see if your version is the latest one.

kevin


signature.asc
Description: PGP signature
___
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: [Container-sig] About Fedora containers

[Kevin Fenzi]

On Tue, Jun 21, 2022 at 03:41:47PM -0400, Matthew Miller wrote:
> On Mon, Jun 20, 2022 at 08:21:48AM +0200, Lumír Balhar wrote:
> > Because we had a lot of troubles with Fedora infra for container
> > images (I can provide more details, if you want), we have decided to
> > move our containers to https://quay.io/organization/fedora.
> 
> I wonder if we should just... make this official? It seems like a pretty
> easy way to create and maintain an official library of layered images which
> are made of Fedora packages — like, some language-base ones like golang or
> python, plus nginx, apache, postgresql, etc.

Yes, thats the plan... but as always it's not just "flip a switch and
drive on". We need to make sure all the features we use are available at
quay.io, that tooling has changes so we can push there, etc. 

https://pagure.io/fedora-infrastructure/issue/10386

Note that this is just moving things in our registry over there and
pointing everyone to it so we can get out of the registry business, we
haven't looked at building the containers there or the like. We are
hoping osbuilder will help us here (or osbs 2.0). 

kevin


signature.asc
Description: PGP signature
___
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: side-tag including other side-tag ?

[Kevin Fenzi]

On Tue, Jun 21, 2022 at 01:47:33PM -0500, Maxwell G via devel wrote:
> On Monday, June 20, 2022 10:02:00 AM CDT Sérgio Basto wrote:
> > Is is possible include builds of one side-tag into other side-tag ?
> 
> It is also possible to `koji tag-build [dest side tag] [NEVR(s) from other 
> side tag]`, which might work for your use case. I suppose setting one side 
> tag 
> to inherit builds from another one would require releng, as Vit said.

Yeah, I don't know that there's any good technical answer here. 

We need to know that a side tag is in progress and a another side tag
has rebuilt that in progress work and is trying to merge. 

Keeping side tags short lived will help this as will communicating with
others when you see them rebuild your in progress work. 

kevin


signature.asc
Description: PGP signature
___
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: F37 proposal: Supplement of Server distributables by a KVM VM disk image (Self-Contained Change proposal)

[Kevin Fenzi]

I'm definitely in favor, but a couple of questions... 

What format image is to be produced? qcow2? or raw.xz? or something
else?

I assume this will not be release blocking at least at first?

Thanks, 

kevin


signature.asc
Description: PGP signature
___
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: [HEADS UP] Fedora 37 Python 3.11 rebuilds to start in a side tag early next week

[Kevin Fenzi]

On Fri, Jun 17, 2022 at 02:21:39PM -0700, Adam Williamson wrote:
> On Fri, 2022-06-17 at 11:49 +0200, Miro Hrončok wrote:
...snip...
> > 
> > Kevin, Adam, do could you please do some kind of compose validation?
> 
> I can validate a compose if Kevin can build one.

I'm not sure I have any easy way to do that. 

I suppose I could hack up the rawhide compose script to pull from the
side tag and not sync out? 

I know Mohan had a minimal compose thing in ODCS, but I am not sure at
all how functional it is. ;( 

I can try hacking something up tuesday (monday is a holiday), or we
could just merge it back and fix things until it works. 

kevin


signature.asc
Description: PGP signature
___
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: Request: Airspy HF+

[Kevin Fenzi]

On Sat, Jun 18, 2022 at 01:28:10PM +0200, Vitaly Zaitsev via devel wrote:
> On 18/06/2022 12:57, Mark E. Fuller wrote:
> > Devel List: If no response from Emiliano, what's the process here for
> > taking over a package in this case (and also renaming the repo to drop
> > the version from it)?
> 
> Also releng need change their scripts to check for $version/etc. presence.
> Such malformed repositories shouldn't be created.

Yeah, although it's difficult because we have backward and forward
compat packages also. 

Anyhow, filed: 

https://pagure.io/releng/issue/10847

to try and improve this. 

kevin


signature.asc
Description: PGP signature
___
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: fedpkg request-side-tag: I don't understand "allowed_suffixes"

[Kevin Fenzi]

On Sat, Jun 18, 2022 at 02:00:03PM +0200, Vitaly Zaitsev via devel wrote:
> On 18/06/2022 13:47, Richard W.M. Jones wrote:
> > So it sounds like the suffix is used for the purpose I guessed.  Why
> > not let any packager use a descriptive suffix (without pre-approval)?
> 
> +1. I like this idea.

well, I think several reasons: 

First, I don't think that was available when we enabled side tags, so we
just never looked too closely at doing so. 

But most importantly, I'm not sure it really conveys too much useful
information. I mean you could call a tag: 

f37-side-NN-ocaml

but is that a mass rebuild? A small set of deps?
What if someone else is rebuilding some small subset of ocaml packages
and calls there tag:

f37-side-XX-ocaml

Which one is for what?

But I suppose it does give a slight bit more information and let you
know to look at a sidetag for something. 

Can you file a infrastructure ticket on it and we can look at getting it
enabled?

Thanks, 

kevin


signature.asc
Description: PGP signature
___
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: Missing dependency in Fedora 35 - bug 2097817

[Kevin Fenzi]

On Fri, Jun 17, 2022 at 04:15:35PM -0500, Michael Catanzaro wrote:
> On Fri, Jun 17 2022 at 02:00:14 PM -0700, Kevin Fenzi 
> wrote:
> > Nope, it has to stay forever. Sorry.
> 
> Hi, can you explain why? Since we do not maintain upgrade paths from one
> release to the next anymore, and instead require use of system upgrade, I
> would have assumed that epoch would only have to stay for the life of a
> particular Fedora release?

I suppose it could be feasable to do it for packages that nothing
has any dependencies on. But for packages that do, there would be a lot
of churn adjusting the deps every cycle, it would prevent merges back to
older branches and just cause confusion. IMHO. 

If we want to allow this, it should at least have a clear
checklist/guideline on how to do things because I think it would be easy
to get wrong. :( 

kevin


signature.asc
Description: PGP signature
___
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: Missing dependency in Fedora 35 - bug 2097817

[Kevin Fenzi]

On Fri, Jun 17, 2022 at 10:38:19AM +0100, José Abílio Matos wrote:
> On Thursday, 16 June 2022 17.55.45 WEST Antonio T. sagitter wrote:
> > Hi all.
> > 
> > I need to downgrade python-reportlab in Fedora 35 for a missing runtime
> > dependency. What's the most accurate way?
> > 
> > Bug ticket: https://bugzilla.redhat.com/show_bug.cgi?id=2097817
> > Update: https://bodhi.fedoraproject.org/updates/FEDORA-2022-23aefe21ad
> > 
> > Regards.
> 
> Not to be the bad news bringer but I think that the only way is to use epoch 
> in the spec file. And to rebuild with a higher epoch.
> 
> Something that I do not remember is what to do the with the other releases. 
> Are we still forced, in order to ensure an upgrade path, to keep the epoch?
> 
> Or can we assume that system-upgrade will allow to get rid of that artifact 
> (of all the things I could call to epoch I think that this is the nicest). :-)

Nope, it has to stay forever. Sorry. 

kevin


signature.asc
Description: PGP signature
___
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: Plan / proposal: enable openQA update testing and potentially gating on Rawhide updates

[Kevin Fenzi]

Big +1 from me... I think this would be great to enable. 

kevin


signature.asc
Description: PGP signature
___
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: Who checks the exception at fedora-scm-requests?

[Kevin Fenzi]

On Thu, Jun 09, 2022 at 09:09:30PM +0200, Miro Hrončok wrote:
> Hello,
> 
> I've recently seen a package that was imported into Fedora without a package
> review. I've noticed this because the packages doesn't even install and I
> wanted to check if this could have been caught in the package review but I
> couldn't find it, so I've checked the fedora-scm-requests ticket.
> 
> The ticket at fedora-scm-requests was created with exception=true. I am not
> going to link to it, because I am not here to point fingers. I am just
> genuinely curious.
> 
> According to 
> https://docs.fedoraproject.org/en-US/packaging-guidelines/ReviewGuidelines/#_package_review_process
> we have 3 kinds of exceptions:
> 
> - FPC grants an explicit exemption from the process...
> - The package is being created so that multiple versions of the same package
> can coexist in the distribution...
> - The package exists in both Fedora and RHEL, but the packager wants to ship
> it in EPEL under an alternative name...
> 
> In those cases, the packager requests the repo with --exception, makes sense.
> 
> However, who checks if the flag was used according to the rules? Because
> apparently, is seems that nobody does. Is it expected that we are all
> responsible people who would not abuse this simply to avoid package reviews?

The scm admin processing the request should check it. :( 

Perhaps this was simply missed and/or perhaps the tool could be better
about showing when a ticket is an exception. ;( 

Do note that we are working on automating most of this away. 
If/when that happens the exceptions would then be... exceptions. 
(ie, the automation would refuse to process them and ask a human to do
so, unless we can come up with a way to check these cases in an
unattended way). 

kevin


signature.asc
Description: PGP signature
___
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: Combine two Bodhi requests?

[Kevin Fenzi]

On Thu, Jun 09, 2022 at 06:47:53PM +0200, Fabio Valentini wrote:
> On Thu, Jun 9, 2022 at 11:38 AM Richard W.M. Jones  wrote:
> >
> > Pairs of Bodhi updates which probably should be combined so the
> > packages go out together:
> >
> > https://bodhi.fedoraproject.org/updates/FEDORA-2022-8f775872c9 &
> > https://bodhi.fedoraproject.org/updates/FEDORA-2022-13bc8c91b0
> >
> > https://bodhi.fedoraproject.org/updates/FEDORA-2022-8fa7e5aeaf &
> > https://bodhi.fedoraproject.org/updates/FEDORA-2022-1176b501f0
> >
> > It doesn't seem as if this is possible at the moment (ie. a button in
> > the Bodhi interface that just does it).  Could this kind of feature be
> > added?  Bodhi can already obsolete and inherit bugs when a later
> > update obsoletes an older one.
> >
> > The manual way to do it is very tedious and error-prone, especially if
> > an update has a lot of builds and/or bugs.
> 
> Would you need this to be a button in the bodhi web interface, or
> would a CLI tool work as well?
> 
> I think it should be reasonably simple to implement that in bodhi
> (Python client) or bodhi-cli (Rust client), and having it do
> everything automatically (request the old updates to be unpushed,
> create a new update from all collected builds, attach all related bugs
> and test cases, etc.) should definitely be less error-prone than doing
> it automatically, and it would also be easy to do some basic checks as
> well (i.e. check that the updates don't have overlapping builds, that
> they are for the same Fedora release, etc.).

I don't think this is possible without server side changes. 
(at least not easily).

bodhi doesn't allow you to delete updates, nor does it allow removing
all builds from an update, so you would have to add some other build,
remove the builds you care about and add them to the other update. 

Perhaps allowing updates with no builds in them would be possible on the
server side. That would make this more doable. 

kevin


signature.asc
Description: PGP signature
___
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: Planned Outage - Bodhi upgrade - 2022-06-09 09:00 UTC

[Kevin Fenzi]

On Wed, Jun 08, 2022 at 07:32:21PM +0200, Miro Hrončok wrote:
> 
> Hey Mark,
> 
> will rawhide builds in Koji automatically create Bodhi updates after the
> outage is over, or is there some manual action that will be required?

I'm not Mark, but there shouldn't be any manual action needed. When the
old version stops, the messages about tagging go into it's fedora
messaging rabbitmq queue and when the new version starts it will read
any messages in that queue and act on them. :) 

So, in theory there shouldn't be any actions needed. 

kevin


signature.asc
Description: PGP signature
___
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: Copr login not working

[Kevin Fenzi]

On Thu, Jun 02, 2022 at 08:34:51PM -0400, Chris wrote:
> Hi,
> 
> Can't seem to log into COPR; I can log into everything else, but after
> providing my correct user/pass combo and logging in, the screen just
> returns back as though I never even attempted (the log in).
> 
> I tried resetting my password, and all that accomplished is that I can
> still log into every other site that uses the Fedora Account Credentials,
> but still not Copr.
> 
> The login i'm using is lead2gold (attemping to push some new changes and
> test them out as i've done in the past to
> https://copr.fedorainfracloud.org/coprs/lead2gold/apprise/). I'm okay with
> using Koji for now.
> 
> Advice/Thoughts?

Please retry now. It should work. 

I was attempting to upgrade our idp, but it appears to have some issue
around copr logins. ;( I'm rolled back to the old os for now, and it
should be back working until we can sort it out. 

Sorry for the trouble.

kevin


signature.asc
Description: PGP signature
___
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: F37 Proposal: Strong crypto settings: phase 3, forewarning 1/2 (System-Wide Change proposal)

[Kevin Fenzi]

On Tue, May 31, 2022 at 08:59:28AM +0200, Petr Pisar wrote:
> V Tue, May 31, 2022 at 08:07:57AM +0200, Alexander Sosedkin napsal(a):
> > On Mon, May 30, 2022 at 10:34 PM Garry T. Williams  
> > wrote:
> > > On Friday, April 29, 2022 5:49:05 PM EDT Ben Cotton wrote:
> > > > Cryptographic policies will be tightened in Fedora 38-39,
> > > > SHA-1 signatures will no longer be trusted by default.
> > > > Fedora 37 specifically doesn't come with any change of defaults,
> > > > and this Fedora Change is an advance warning filed for extra visibility.
> > > > Test your setup with FUTURE today and file bugs so you won't get bit
> > > > by Fedora 38-39.
> > > >
> > > After looking in
> > > /usr/share/crypto-policies/policies/modules, I tried again with:
> > >
> > > $ sudo update-crypto-policies --set FUTURE:SHA1
> > > Setting system policy to FUTURE:SHA1
> > >
> > > But that didn't get me back.  I got the same error doing dnf upgrade.
> > >
> > > I had to do:
> > >
> > > $ sudo update-crypto-policies --set DEFAULT
> > >
> > > to get back to dnf working again.
> > >
> > > > file bug reports against the affected components if not filed already.
> > >
> > > I really don't know what "component" to use filing a bug.
> > 
> > Yeah, that seems like a case when
> > the service administrator is the one to be notified.
> 
> Reported to . The real
> cause is not SHA-1. It's a 2048-bit RSA key of an intermediate certificate.

Right. This has been reported before: 
https://bugzilla.redhat.com/show_bug.cgi?id=1832292

As far as I can tell, we can't get a digicert cert that doesn't use
2048bit CA or intermediate. I think they do offer better/different, but
those are reserved for the EV certs which require a bunch of validation
of your business (which fedoraproject isn't). 

We might be able to replace it with a letsencrypt cert, I've not looked
to see if they have moved to a higher bit CA/intermediate yet. 

But even with that, do note that lots and lots and lots of other
websites will not work at all either, so I don't think setting FUTURE
is too great a experence right now. ;(

kevin


signature.asc
Description: PGP signature
___
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: Ceph, virt packages (Re: Orphaned packages looking for new maintainers)

[Kevin Fenzi]

On Mon, May 30, 2022 at 02:05:58PM +0200, Miro Hrončok wrote:
> On 30. 05. 22 10:09, Richard W.M. Jones wrote:
> > On Mon, May 30, 2022 at 09:31:21AM +0200, Miro Hrončok wrote:
> > > The following packages are orphaned and will be retired when they
> > > are orphaned for six weeks, unless someone adopts them. If you know for 
> > > sure
> > > that the package should be retired, please do so now with a proper reason:
> > > https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life
> > > 
> > > Note: If you received this mail directly you (co)maintain one of the 
> > > affected
> > > packages or a package that depends on one. Please adopt the affected 
> > > package or
> > > retire your depending package to avoid broken dependencies, otherwise your
> > > package will fail to install and/or build when the affected package gets 
> > > retired.
> > > 
> > > Request package ownership via the *Take* button in he left column on
> > > https://src.fedoraproject.org/rpms/
> > > 
> > > Full report available at:
> > > https://churchyard.fedorapeople.org/orphans-2022-05-30.txt
> > > grep it for your FAS username and follow the dependency chain.
> > 
> > ...
> > 
> > > python-repoze-lru infra-sig, jcaratzas, orphan 0 
> > > weeks ago
> > 
> > Looks like it's this package which causes the ceph & hence virt
> > breakage.  It seems to have a co-maintainer already.
> 
> Looking at the commit log, no maintainer touched that package for almost 4 
> years.

Well, pingou updated it 3years ago. ;) 

Update to 0.7
Pierre-Yves Chibon • 3 years ago   f29

> It seems the biggest transient consumer of this is python-routes trough
> which it goes to ceph and & virt.

I'm ok to just take it myself, but I already have way too many
packages... so I would prefer if someone(s) else did. 

kevin


signature.asc
Description: PGP signature
___
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: PSA: I am not getting all email from Fedora, reach me directly if you need me

[Kevin Fenzi]

On Tue, May 24, 2022 at 07:08:00PM +0200, Miro Hrončok wrote:
> Hello Fedorans,
> 
> this is a just a heads up: If I ignored your question in a Pagure issue, or
> your pull request, possibly haven't replied to your bugzilla report or a
> devel thread... it's because my email is broken and I don't get some (many)
> Fedora emails. Other colleagues from Red Hat report the same.
> 
> https://pagure.io/fedora-infrastructure/issue/10705
> 
> Feel free to email me directly (hope that actually works) or better reach me
> out at Matrix/IRC with a link to the message that requires my attention.
> 
> Sorry about that.

Yeah, I am sorry as well. ;( 

I _think_ everything is back to working except for one path now. 
(the case of a redhat.com address mailing a fedoraproject.org alias with
gmail or some host that filters email based on SPF record. In that case
the emails are rejected currently. I have a internal ticket on that
pending)

kevin


signature.asc
Description: PGP signature
___
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: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)

[Kevin Fenzi]

On Tue, May 24, 2022 at 04:57:54PM +0200, Jiri Vanek wrote:
> 
> We are testing also upstream. note that RH is maintainer of ojdk 11 and 8,
> so we have to.  But that is much easier, as the usptream is static within
> intree libraries. And we have to run also for 17 and 18/19 as we need this
> reference run, to be sure that downstream is guilty, not vanilla jdk. Thus
> we test the (source x build) just once.  And we can test the binary on some
> known system where we always pass.

Well, I meant test the _dynamic_ build that Fedora does now...

> But in downstream, new issues usually appear due to the dynamic linking and
> nature of system where only it can be installed. Also for dowstram, each
> sources are built N times, so N times tested in thsoe N systems - usually
> each with its psecific failures.
> 
> > 
> > Could we integrate the TCK testing in our CI to save you overhead of
> > managing submitting, etc? Or where is the most time spent in this
> > workflow?
> 
> As I described in another reply, it is both human and hw. Hw to run all those 
> swarm of builds on all platforms, and humans to verify the issue and to fix 
> it.
> TCK are very complex, and you need at least three machines in distributed 
> system to run them. At least two of those slaves are not trivial (krb master 
> and system where tck are running).
> Generally saying, I have autoamtion to prepare that all, but second part is 
> reproducibility. If the "non mine" setup run will fail for some reason, can I 
> rerun it? Can I debug it? I'm finding this very hard in 3rd party hw clusters.

Would it help to have some cloud resources to do this in? 
We could definitely get you access to some ec2 instances to setup a test
cluster for testing fedora builds. 

> > I know others have suggested fewer openjdk streams to reduce workload,
> > but I didn't see any reply on that from change owners.
> > 
> 
> I replied it already in that thread, but happy to repeat:
> It will help, but less then it seems so.
> Now we can drop 8. Soem legacy applciations will be unhappy, as EOL of jdk8 
> is in some 4 years, so fedora will suffer a bit. But it will be nice 12 TCK 
> runs down.
> but we can not droop 11, as it is system jdk in f35
> Similarly, we couldn't introduce fresh jdk17 directly to f36 as system JDK. 
> It needs it time to be tuned before being proposed as system jdk.
> And we can not drop java-latest-openjdk, becasue it is necessary to boot next 
> system JDK.
> Yes, in 8 months, we would be able to drop 11. And live for 1 year only on 
> latest and 17. Which is putting load for one year to 1/2. But the cost of not 
> having 11 (and 8) will be felt by fedora users more, then having static jdk 
> from repos.
> Unluckily, with new future system jdk, we will need to boostrap it by latest, 
> keep it as secondary jdk at least for one , better two, fedora cycles, so 
> again we will be in 3  jdks x 3 systems.
> Sure, we do not need to backport newest future system jdk to older fedoras, 
> but usually the users want us to do so. tbh, I do not have strong preference 
> on it. it is like 51 for backport, and 49 for not. Even with knwoledge of TCK 
> burden.
> 
> If currently we have 4 jdks on 3 fedoras with 3 primary architectures=> 36 TCK
> With this shortage, we would have
> 2 jdks on 2 fedoras with 3 primary architectures=> 12 tck in minimum. That 
> sound like a reasonable drop, but only for very short period of time, duriong 
> which we will nee to have capcity reserved for ppreparation of next
> system jdk: 3 jdks on 3 fedoras with 3 primary architectures=>  27 avarage, 
> With much more stress about possible integration issues and with - imo(!) - 
> considerable negative imapct to fedora.

ok, sorry I missed a previous reply on this. ;) 

So, what would you then think about just:

1. having some cloud resources to setup a tck test env that you could
manage better than some ci somewhere and use to test fedora builds.
and
2. switching fedora to the static system libraries so you didn't need to
keep the dynamic ones in sync.

but then trying to see if that reduces your workload to a sustainable
level and avoid the 'build once, certify' thing that is going to end up
being a lot of trouble. 

kevin


signature.asc
Description: PGP signature
___
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: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)

[Kevin Fenzi]

So, just replying here since this is a nice monster of a thread. ;( 

First, just to clear up some previous coments, shim does build against
the oldest stable Fedora in koji and then is manually tagged into newer
ones. This is not at all a good process. It only gets a bodhi update for
the one release (and sometimes not even that), so it never gets good
testing. It requires manual intervention from releng each time there's
an update. I think the only reason this has kept going is that shim is
very small and simple and updates rarely. If we need to do this for tons
of openjdk updates, we really should revisit the process, although I am
not sure how to make it more open to testing and less a burden on
releng. ;( 

Next, My understanding of the current process for openjdks (openjdki?):

for each openjdk:

Build dyanmically linking against system libraries in all fedoras. 
Submit to TCK and wait for them all to process.
Fix any TCK failures and repeat
Once there's no failures, push the builds to updates

Is that right? And keeping the dynamic builds passing is taking more
cycles than you have to give for the number of jdks?

What about the possibility of adding CI _upstream_ to test against the
dynamic version? Then TCK failures would be caught upstream and not
downstream where it's a lot of work for you to fix?

Could we integrate the TCK testing in our CI to save you overhead of
managing submitting, etc? Or where is the most time spent in this
workflow?

I know others have suggested fewer openjdk streams to reduce workload,
but I didn't see any reply on that from change owners.

Thanks, 

kevin


signature.asc
Description: PGP signature
___
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: [CentOS-devel] [EPEL-devel] RHEL moving to issues.redhat.com only long term

[Kevin Fenzi]

On Thu, May 19, 2022 at 07:37:46AM +0200, Branislav Náter wrote:
> Hi,
> 
> On Thu, May 19, 2022 at 4:15 AM Thomas Stephen Lee 
> wrote:
> 
> > Hi,
> >
> > I am trying to request a package for RHEL 9, but I cannot find RHEL
> > under Projects at issues.redhat.com.
> > What is the correct project for RHEL 9 ?
> >
> 
> You have to file a bug for "distribution" component in Bugzilla.

Please don't file it there. :) 

Take a look at the handy doc: 

https://docs.fedoraproject.org/en-US/epel/epel-package-request/

If anything is unclear there, please do let us know. 

While RHEL may be moving to jira with RHEL10, EPEL is very likely to
stay with whatever Fedora is using (currently bugzilla). 

kevin


signature.asc
Description: PGP signature
___
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

[EPEL-devel] Re: [CentOS-devel] RHEL moving to issues.redhat.com only long term

[Kevin Fenzi]

On Thu, May 19, 2022 at 07:37:46AM +0200, Branislav Náter wrote:
> Hi,
> 
> On Thu, May 19, 2022 at 4:15 AM Thomas Stephen Lee 
> wrote:
> 
> > Hi,
> >
> > I am trying to request a package for RHEL 9, but I cannot find RHEL
> > under Projects at issues.redhat.com.
> > What is the correct project for RHEL 9 ?
> >
> 
> You have to file a bug for "distribution" component in Bugzilla.

Please don't file it there. :) 

Take a look at the handy doc: 

https://docs.fedoraproject.org/en-US/epel/epel-package-request/

If anything is unclear there, please do let us know. 

While RHEL may be moving to jira with RHEL10, EPEL is very likely to
stay with whatever Fedora is using (currently bugzilla). 

kevin


signature.asc
Description: PGP signature
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: fedpkg sources - downloading unused source files: opt-in/opt-out

[Kevin Fenzi]

On Mon, May 09, 2022 at 01:21:53PM -0400, Neal Gompa wrote:
> On Mon, May 9, 2022 at 1:13 PM Kevin Fenzi  wrote:
> >
> > On Wed, May 04, 2022 at 09:45:55PM +0300, Otto Urpelainen wrote:
> > > Ondrej Nosek kirjoitti 4.5.2022 klo 18.01:
> > > > Hi all,
> > > >
> > > > A few months ago fedpkg introduced a change which avoids downloading 
> > > > source
> > > > files (from dist-git) that are not used in the specfile and therefore
> > > > downloading them would be wasting of resources and time.
> > > > The original request was opened here [1] and implemented here [2]. The
> > > > logic is part of the command "fedpkg sources" and currently can't be
> > > > disabled manually. The logic parses specfile, but doesn't do a deep
> > > > analysis, so it is doesn't always right.
> > > >
> > > > Recently we got a request for opt-in implementation of this. It means 
> > > > you
> > > > should actively use some argument (ie. --skip-unused) to avoid 
> > > > downloading
> > > > unused sources. The requestor points out that it broke the original
> > > > functionality and it is not possible to add any extra arguments into the
> > > > complicated release process (RHEL kernel).
> > >
> > > Author of the patch under discussion here.
> > >
> > > The premise was that "specfile sources" equal "sources file sources". 
> > > Since
> > > there is a request like this, that is apparently not always the case. From
> > > that perspective, the patch is wrong and opt-in would be the correct way.
> >
> > I think opt-in will be useless and make the entire option pointless.
> > Most maintainers won't be aware it exists.
> >
> > Why would someone want to opt-out of this?
> >
> 
> I need to when working on ffmpeg updates, since it clobbers my
> regenerated tarballs when I'm working normally. I had no idea about
> this until someone pointed it out to me.

So you mean where you have modified the source, but the name is the same
as in spec and it overwrites your local changes by downloading
the lookaside one over it?

I can see that being an issue early on, but after initial packaging
wouldn't changes always also include the version and thus be different
from whats in the spec/sources?

I was pleasently surprised when it didn't uselessly download the old
source after I locally updated a spec.

kevin


signature.asc
Description: PGP signature
___
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: fedpkg sources - downloading unused source files: opt-in/opt-out

[Kevin Fenzi]

On Wed, May 04, 2022 at 09:45:55PM +0300, Otto Urpelainen wrote:
> Ondrej Nosek kirjoitti 4.5.2022 klo 18.01:
> > Hi all,
> > 
> > A few months ago fedpkg introduced a change which avoids downloading source
> > files (from dist-git) that are not used in the specfile and therefore
> > downloading them would be wasting of resources and time.
> > The original request was opened here [1] and implemented here [2]. The
> > logic is part of the command "fedpkg sources" and currently can't be
> > disabled manually. The logic parses specfile, but doesn't do a deep
> > analysis, so it is doesn't always right.
> > 
> > Recently we got a request for opt-in implementation of this. It means you
> > should actively use some argument (ie. --skip-unused) to avoid downloading
> > unused sources. The requestor points out that it broke the original
> > functionality and it is not possible to add any extra arguments into the
> > complicated release process (RHEL kernel).
> 
> Author of the patch under discussion here.
> 
> The premise was that "specfile sources" equal "sources file sources". Since
> there is a request like this, that is apparently not always the case. From
> that perspective, the patch is wrong and opt-in would be the correct way.

I think opt-in will be useless and make the entire option pointless. 
Most maintainers won't be aware it exists.

Why would someone want to opt-out of this?

> The suggestion to also allow configuring this in fedpkg.conf is good,
> because for the majority of users who do not encounter these special
> packages could avoid the effort to adding an extra parameter every time.

I suppose maintainers could set a conf option, but I suspect the vast
majority wouldn't even know it exists. 

> It is also good to keep in mind that the original reason why unused sources
> were bothering packagers was that they easily happen during package version
> updates, when test builds are done with 'fedokg mockbuild' after specfile
> has been updated to the new package version, but before lookaside cache has
> been updated with new sources. At the same time wiht #564, I also wrote
> another path #561 [1] that enabled 'fedpkg new-sources --offline'. That
> allows a package update workflow that also avoids unnecessary downloads:
> 
> $ rpm-bumpspec -n 1.2.3 *.spec
> $ spectool -g *.spec
> Downloading: https://example.com/downloads/package-1.2.3.tar.gz
> Downloaded: package-1.2.3.tar.gz
> $ fedpkg new-sources --offline package-1.2.3.tar.gz
> Uploading: package-1.2.3.tar.gz
> *Upload disabled*
> Source upload succeeded. Don't forget to commit the sources file
> $ fedpkg mockbuild
> Not downloading already downloaded package-1.2.3.tar.gz
> 
> Given availability of this method, if there are no other, major cases where
> unused sources appear, I do not think opt-in is a bad solution.

I suspect most maintainers won't use that either. 
If you are going to be doing a PR you _do_ want to upload the source (so
the tests on the PR work). But you likely want to build/test locally
first before uploading in case there's some big problem with the
source... 

Just my 2cents.

kevin


signature.asc
Description: PGP signature
___
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: The future of FMN (Fedora Messaging Notifications)

[Kevin Fenzi]

On Tue, Apr 26, 2022 at 12:26:06PM +0200, Fabio Valentini wrote:
> On Mon, Apr 25, 2022 at 9:49 PM Adam Williamson
>  wrote:
> > Replying to a reply because I can't find the original mail, sorry.
> >
> > I want to be easily able to *NOT* be notified of things I just did. In
> > fact this should probably be the default. Right now my FMN
> > notifications are floods of "adamwill did X to Y" - yes, I know, I just
> > did it!
> 
> Exactly. I want to get notifications for events that are happening to
> packages that I'm associated with
> (either by being a (co-)maintainer, being a member of a co-maintainer
> group, or by "watching" a package on dist-git)
> that were *not* triggered by myself. For example:
> 
> - somebody else pushes a commit to the package on dist-git
> - somebody else launches a koji build for the package
> - somebody else submits an update containing the package to bodhi
> - koschei notices that the package starts to be FTBFS
> - somebody or something filed a bug against the package
> - etc.

Lest it sound like everyone just wants it to behave this way, I
personally _do_ like getting emails for actions I did myself. 
I find that later when I am looking back to see what changed by who I
can (sometimes surprisingly) find out it was me. :) 

So, I would prefer this be a pref (perhaps set to not notify by
default?)

kevin


signature.asc
Description: PGP signature
___
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: Allow non-packagers to push to dist-git forks without fedpkg

[Kevin Fenzi]

On Mon, Apr 25, 2022 at 04:14:03PM -0400, Matthew Miller wrote:
> On Fri, Apr 22, 2022 at 03:44:01PM +0200, Miro Hrončok wrote:
> > If I understand correctly, SSH access is a security/legal/whatever
> > no-go for nonpackagers, but can we offer some kind of standard git
> > mechanism to authenticate? API tokens maybe?
> 
> If there is a technical thing we want to do to make Fedora easier to
> contribute to, we should figure out how to remove any legal (or "whatever")
> blockers. And mitigate any security concerns.

To my knowledge there's no legal issue around ssh access. 

It's simply that when we setup pkgs.fedoraproject.org so long ago, the
way it was done was to add packagers as local accounts so they could ssh
in. Non packagers don't have any account there, so they can't directly
ssh in. 

Ideally we would just redo this so packagers don't have real accounts
either, and just use a wrapper, but thats likely to be a bunch of work.

kevin


signature.asc
Description: PGP signature
___
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: Allow non-packagers to push to dist-git forks without fedpkg

[Kevin Fenzi]

On Fri, Apr 22, 2022 at 11:01:27AM -0400, Neal Gompa wrote:
> On Fri, Apr 22, 2022 at 9:54 AM Miro Hrončok  wrote:
> >
> > Hello folks,
> >
> > what would it take to allow non-packagers to push to dist-git forks without 
> > fedpkg?
> >
> > The instructions at
> > https://docs.fedoraproject.org/en-US/ci/pull-requests/#_you_are_not_a_packager
> > assume they run Fedora (or another distro with fedpkg), but this is 
> > extremely
> > unfriendly to contributors who run other distros.
> >
> > The alternative is external pull request which is awesome in theory but 
> > quite
> > tedious in practice. E.g. as a package maintainer, I cannot push my changes 
> > to
> > a proposed external pull request.
> >
> > If I understand correctly, SSH access is a security/legal/whatever no-go for
> > nonpackagers, but can we offer some kind of standard git mechanism to
> > authenticate? API tokens maybe?
> >
> > If not, can we at least extract the fedpkg bits that do this and release 
> > that
> > as a standalone easy-to-install software that we can offer or even package 
> > to
> > other distributions?
> >
> 
> We should just turn on Pagure's ability to let you create API tokens
> that can do HTTPS auth for git push on src.fedoraproject.org. The
> janky setup we have now predates introducing support in Pagure itself.

We have, but it's incompatible with the existing oauth setup, so we need
to figure out how we can transition that without breaking everyone or
get them both to work. :(

kevin


signature.asc
Description: PGP signature
___
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

[EPEL-devel] Re: Does EPEL 9 Koji have older c9s packages than local mock?

[Kevin Fenzi]

On Fri, Apr 22, 2022 at 07:53:10PM +0200, Miro Hrončok wrote:
> Hello,
> 
> I've been trying to debug a segfault during %check that only occurs in epel9
> Koji, but not in mock.
> 
> At the end, I compared the list of packages with:
...snip...
> 
> This seems like my local mock has newer c9s packages than the Koji build
> repo. Is that expected, or is pulling c9s packages into the build repo stuck
> on Koji side?

It's expected, because epel9 is going to be tracking RHEL9 as soon as
it's out, so we cut the sync when CentOS stream 9 started tracking 9.1
packages. Your local mock likely has 9.1 packages.

> Actually, I got an idea that EPEL 9 Koji might already be using (internal?)
> RHEL 9.0, possibly I have missed this switch... However, the
> centos-stream-release package contraditcs taht idea :/
> 
> I've checked with an EPEL 9 Next Koji scratchbuild and it got e.g.
> pyproject-rpm-macros-1.0.1-1.el9.

It's not using rhel9 (yet) just a snapshot of stream9 back when it was
tracking 9.0. 

kevin


signature.asc
Description: PGP signature
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[EPEL-devel] Re: EPEL-ANNOUNCE retirement of ansible-2.9.x

[Kevin Fenzi]

Looks like your orig message didn't get to epel-devel, perhaps you
aren't subscribed?

On Thu, Apr 21, 2022 at 04:03:20PM +0200, Michael Trip wrote:
> Hi Kevin,
> 
> What does that mean for the ansible rpm package in general? Do we have
> to remove the ansible RPM from our systems and install ansible through
> pip ? Or will ansible-core also land in EPEL 7? My apologies if i don´t
> understand it correctly.

epel7: ansible-2.9.x rpm in epel will be retired (ie, dropped, removed,
no longer appear in repos). 

So, yes, you would need to install from pip or if you are using RHEL you
could I think still install the rpm from the ansible-engine channel. 
If using pip, you would need to make sure and specify <3.0 or it will
try and install the current version and fail (because python is too old
to meet requirements). 

Also, do note that it will be EOL and getting no updates... not even
security updates. :( 

kevin
--
> 
> Kind regards,
> 
> Michael Trip
> 
> On Tue, 2022-04-19 at 13:14 -0700, Kevin Fenzi wrote:
> > Greetings. 
> > 
> > Just a reminder that ansible-core (The split out ansible 'engine')
> > will
> > be landing in RHEL8.6 (and other el builds thereafter). Also, the
> > ansible 2.9.x ('ansible classic') package is going to going end of
> > life
> > and no longer supported in that same timeframe.
> > 
> > So, at that time I will be retiring the ansible 2.9.x package in
> > epel7.
> > 
> > In epel8 I will be converting the 'ansible' epel8 package into the
> > upstream ansible-5 meta collections package (which also pulls in
> > ansible-core).
> > 
> > epel7 and epel8 ansible users are advised to plan for this
> > retirement/change. 
> > 
> > Thank you, 
> > 
> > kevin
> > ___
> > epel-announce mailing list -- epel-annou...@lists.fedoraproject.org
> > To unsubscribe send an email to
> > epel-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/epel-annou...@lists.fedoraproject.org
> > Do not reply to spam on the list, report it:
> > https://pagure.io/fedora-infrastructure
> 


signature.asc
Description: PGP signature
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[EPEL-devel] retirement of ansible-2.9.x

[Kevin Fenzi]

Greetings. 

Just a reminder that ansible-core (The split out ansible 'engine') will
be landing in RHEL8.6 (and other el builds thereafter). Also, the
ansible 2.9.x ('ansible classic') package is going to going end of life
and no longer supported in that same timeframe.

So, at that time I will be retiring the ansible 2.9.x package in epel7.

In epel8 I will be converting the 'ansible' epel8 package into the
upstream ansible-5 meta collections package (which also pulls in
ansible-core).

epel7 and epel8 ansible users are advised to plan for this
retirement/change. 

Thank you, 

kevin


signature.asc
Description: PGP signature
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure