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.

Fedora 37 Beta Freeze now over

[Kevin Fenzi]

Hi All,

With the successful release of Fedora 37 beta yesterday we are now out of
freeze.

Our next planned freeze is 2022-10-04 for Fedora 37 Final Release.
(In about 3 weeks).

kevin


signature.asc
Description: PGP signature
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-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/infrastructure@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]

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: Best Gaming Laptop of 2022 for Hardcore Gamers

[Kevin Fenzi]

On Wed, Sep 14, 2022 at 10:21:09AM +0930, Tim via users wrote:
> On Tue, 2022-09-13 at 07:47 -0700, Kevin Fenzi wrote:
> > Every post has a 
> > Archived-At:
> > header that provides a link to that exact message in the archives. 
> > That can be provided to identify the message.
> 
> Though headers aren't so easily viewed on some systems.  You typically
> get your choice of about four (to/from/date/subject) or all of them
> (and that can be a lot).  If people read on mobile devices, they may
> not get any choice about it.
> 
> If I click on that header in Evolution (as you'd expect to be able to
> with a HTTP address) I get a 503 error from a web server.  I still get
> a 503 error if I strip it back to: https://lists.fedoraproject.org/

Thats because it was down. ;) 

Please try again now. The vpn cert on the mail server had expired, been
renewed, but not yet pushed out to it. 

> The point me and Patrick were commenting on was making it easier to
> report spam.  Not a different way of difficulty.  With the current
> system, the issue reporting link at the bottom of an email, I have to
> create a Fedora account before I even know what procedure I'm going to
> have to go through.  At that stage I abort with a "not yet another
> account I have to create, I'm already drowning in passwords".

Sure, I can see that, but... if you can't easily report it, just ignore
it? Either I or some other admin will see it and take care of it, or
someone else will report it. I don't think we have a problem of
unreported spam. At least not currently.

kevin


signature.asc
Description: PGP signature
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-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/users@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: Best Gaming Laptop of 2022 for Hardcore Gamers

[Kevin Fenzi]

On Tue, Sep 13, 2022 at 12:52:45PM +0100, Patrick O'Callaghan wrote:
> On Tue, 2022-09-13 at 20:59 +0930, Tim via users wrote:
> > On Tue, 2022-09-13 at 11:54 +0100, Patrick O'Callaghan wrote:
> > > Could this not be automated in the footer link, e.g. by including
> > > the Message-ID?
> > 
> > Technically you could automate it in a variety of ways.  e.g. Each
> > message through the list gets a "report me" link added to it with a
> > their unique ID in the link.  Or, you forward an entire message
> > (headers and all) to an automatic assessor.
> > 
> > However, you would need some double-checks to stop miscreants
> > deliberately abusing the system by falsely reporting normal messages.
> > The simplest one being that a certain number of people would have to
> > report the same post to get past a threshold.
> 
> Yes, that would make sense. And presumably some sort of check against
> list membership.

Every post has a 
Archived-At:
header that provides a link to that exact message in the archives. 
That can be provided to identify the message. 

kevin


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

Re: Release criteria proposal: require GNOME Shell extension install/remove to work

[Kevin Fenzi]

On Mon, Sep 12, 2022 at 03:11:43PM -0700, Scott Beamer wrote:
> 
> One thing I should mention, I checked and  only 14 of the 37 extensions that
> can be installed from the Fedora repos are compatible with GNOME 43.  So if
> Fedora 37 shipped today, I know of 23 packages that would be broken from the
> get-go.
> 
> Also that API issue has been around for *weeks* in Fedora 36 and has been a
> source of frustration for me.  It's not major, but it is frustrating.

Just as a side note there's a "disable-extension-version-validation"
setting which you can set to true and it will not do the extension
version checks: 

gsettings set org.gnome.shell disable-extension-version-validation true

You can then see if an extension actually does work fine and just needs
it's version check updated, or if it really needs actual porting work to
the new version. 

Also, as an even more aside note here, the
gnome-shell-extension-openweather extension is one of the broken ones.
It needs porting to new libsoup. Turns out the upstream maintainer
ported it a while back, but because ubuntu hadn't moved to the new
libsoup, they just reverted it. :( Now that debian is moving to it also
perhaps they can re-land the port or have some kind of runtime check and
work with either.

kevin


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

Re: I made a new Fedora Apps page, do you want it?

[Kevin Fenzi]

On Sun, Sep 11, 2022 at 10:05:22PM +0200, Jakub Kadlcik wrote:
> Hello Kevin,
> 
> > I'd be open to that. Not sure about others.
> 
> Maybe I can create an infrastructure ticket, keep it up for some time,
> and if there aren't -1s, we can talk about some next TODO steps?

I suppose. I prefer mailing lists for discussions/planning and then use
tickets for specific actions that need doing. :) 

So, I would say if you don't hear -1's here, keep on going...

> > We probibly need to sit down and update the data there sometime.
> 
> Sure. We can also do this independently on the proposed
> re-implementation. I am using the data file from the original project
> https://github.com/fedora-infra/apps.fp.o/blob/develop/data/apps.yaml

Yeah. 

 https://github.com/fedora-infra/apps.fp.o/pull/82

is a first pass at some updates. ;)

kevin


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

Re: Best Gaming Laptop of 2022 for Hardcore Gamers

[Kevin Fenzi]

On Mon, Sep 12, 2022 at 09:02:25AM -0700, Samuel Sieb wrote:
> On 9/12/22 03:42, Patrick O'Callaghan wrote:
> > On Mon, 2022-09-12 at 07:40 +, David Lex wrote:
> > > Best Gaming Laptop:
> > [...]
> > 
> > What does this have to do with Fedora?
> 
> It's spam.
> 
> > Do not reply to spam, report it: 
> > https://pagure.io/fedora-infrastructure/new_issue
> 
> ^^^

Yep. 

It's already been removed from archives and the user banned. 

kevin


signature.asc
Description: PGP signature
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-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/users@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: I made a new Fedora Apps page, do you want it?

[Kevin Fenzi]

On Thu, Sep 08, 2022 at 02:23:22AM +0200, Jakub Kadlcik wrote:
> Hello,
> 
> I am reimplementing the current https://apps.fedoraproject.org
> page. It is not finished yet, but I wanted to share a demo with you:
> https://fedora-apps.netlify.app
> 
> The upstream is here: https://github.com/frostyx/fedora-apps/
> 
> Do you have any interest to eventually switch to this implementation
> and sunset the original one?

I'd be open to that. Not sure about others. 

We probibly need to sit down and update the data there sometime. 

> PS: Please don't judge me too harshly for the code quality, I am
> learning the language. I will refactor once the basic features are
> done (I know everybody is saying that :D)

:)

kevin


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

Re: FBR: DNS update

[Kevin Fenzi]

On Thu, Sep 08, 2022 at 11:27:16AM -0400, Stephen Smoogen wrote:
> Currently the ipv6for osuosl.org is not functioning and I would like to
> take them out of DNS. When looking at it, I found that the getfedora.org
> was in this state:
> ```
> disable proxy09.fedoraproject.org
> disable proxy11.fedoraproject.org
> enable proxy11.fedoraproject.org
> disable proxy02.fedoraproject.org
> enable proxy02.fedoraproject.org
> disable proxy04.fedoraproject.org
> disable proxy06.fedoraproject.org
> enable proxy06.fedoraproject.org
> disable proxy13.fedoraproject.org
> enable proxy13.fedoraproject.org
> disable proxy03.fedoraproject.org
> enable proxy03.fedoraproject.org
> disable proxy12.fedoraproject.org
> enable proxy12.fedoraproject.org
> disable proxy01.iad2.fedoraproject.org
> disable proxy101.iad2.fedoraproject.org
> disable proxy101.iad2.fedoraproject.org
> ```
> 
> My change to the cmds files is to add proxy06.fedoraproject.org and proxy09
> to the disable list and remove all others from getfedora.org. Then execute
> a change and cleanup.

It's too bad we can't just disable them for ipv6, but leave them in for
ipv4. ;( 

Oh well, Hopefully it will be fixed soo. +1

kevin


signature.asc
Description: PGP signature
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-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/infrastructure@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: The state of mailing lists/mailman (not great)

[Kevin Fenzi]

On Tue, Sep 06, 2022 at 09:45:11AM -0400, Stephen Smoogen wrote:
snip...
> 
> I am wondering if some of these lists would be better using something like
> public inbox https://lwn.net/Articles/748184/ like sourceware is using
> https://inbox.sourceware.org/. Various announcement lists and things like
> scm-commits do not need to have interactive webpages like mailman3
> hyperkitty give since they are limited to few people.

I've often pondered setting up public-inbox, but then we have another
thing to maintain, and it's got some...limitations... like expecting
everything to be plain text.

But it's a thought...

kevin


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

Freeze break request - eln signing

[Kevin Fenzi]

I messed up and didn't update eln signing at branching. ;( 

This PR: 
https://pagure.io/fedora-infra/ansible/pull-request/1185

should enable that and also allow me to re-sign existing builds. 

+1s?

kevin


signature.asc
Description: PGP signature
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-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/infrastructure@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

Freeze break request: kernel builders

[Kevin Fenzi]

So, last week I managed to break bkernel01 kernel builder (and we have
been using just 02 since then). There were 2 issues:

1. I switched rawhide to use systemd-nspawn for isolation instead of
chroot and this broke kernel builds due to (
https://github.com/rpm-software-management/mock/issues/140 )

2. pesign in f36 had some issues with unlocking the smart cards. 
( https://bugzilla.redhat.com/show_bug.cgi?id=2122777 )

The pesign maintainers fixed issue 2 this morning and I tested the
workaround I have for issue 1 in mock on bkernel01. 

So, what I would like to do now is: 

* upgrade bkernel02 to the same pesign version as on 01 along with
moving it to f36 (like 01 is).
* Push a commit in ansible to adjust mock config for the workaround for
issue 1 above.

+1s or further questions?

kevin


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

Re: Freeze Break Request: Increase mailman to 8 CPU

[Kevin Fenzi]

On Thu, Sep 01, 2022 at 02:16:03PM -0400, Stephen Smoogen wrote:
> I am trying to deal with some crashing issues with the mailman. It is
> currently at 100% CPU usage with 4 cpus and about 12-16 waiting services at
> all times. I would like to increase the number of CPUs to 8. There does not
> look to be memory problems at this time so no increase is needed there.
> 
> Actions:
> update ansible
> update vm system via virsh
> reboot vm

+1 here. 

kevin


signature.asc
Description: PGP signature
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-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/infrastructure@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
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-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/test@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: planet

[Kevin Fenzi]

On Tue, Aug 23, 2022 at 12:46:04AM -, Pedro Moura wrote:
> Hi everyone,
> 
> We have been migrating those templates to erb files and was noticed some 
> differences.
> people02.fedoraproject.org has templates for each sub-planet of fedora 
> planet, but some of them are not being used in prod. Summer-coding and 
> Security are examples of sub-planets that have different templates that are 
> not used in prod, css is different too.
> 
> Should we apply the same templates for all the planets? If yes, the repo 
> https://gitlab.com/fedora/websites-apps/themes/fedora-planet-theme has the 
> templates for "people" planet, which are the templates that seems to be in 
> prod. Should we be pushing in that repo instead?

Well, we did at one point have those 'sub planets' defined for various
teams. If you go to: http://fedoraplanet.org/ and look at the top
there's a drop down for 'sub planets'. I am not sure they are really
used, but they also all seem to have the same templates/apperance?
(At least from what I can tell). 

So, I would say, get it working with the base one and we can adjust the
other ones later. 

We could reuse that repo I guess... it looks like almost all the work
there was done by Ryan Lerch, we could ask him...

kevin


signature.asc
Description: PGP signature
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-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/infrastructure@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: Freeze Break Request: add distro.builders to nameservers zones.conf

[Kevin Fenzi]

On Wed, Aug 24, 2022 at 10:02:21AM -, Patrick  マルタインアンドレアス  Uiterwijk wrote:
> Hi all,
> 
> Could I get +1s for the following Ansible patch?
> This adds the domain distro.builders (used for tiny.distro.builders for the 
> Fedora Minimization Content Resolver) to the nameserver zones configuration.
> This domain is being transferred to Red Hat/Fedora control.

+1 here. 

kevin


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

Fedora 37 Beta Freeze now in effect

[Kevin Fenzi]

Greetings.

We are now in the infrastructure freeze leading up to the Fedora 37
Beta release. This is a pre release freeze.

We do this to ensure that our infrastructure is stable and ready to
release the Fedora 37 Beta when it's available.

You can see a list of hosts that do not freeze by checking out the
ansible repo and running the freezelist script:

git clone
https://infrastructure.fedoraproject.org/infra/ansible.git
ansible/scripts/freezelist -i inventory

Any hosts listed as freezes is frozen until 2022-09-13 (or later if
release slips). Frozen hosts should have no changes made to them without
a sign-off on the change from at least 2 sysadmin-main or rel-eng
members, along with (in most cases) a patch of the exact change to be
made to this list or a pull request for review.

Thanks,

Kevin


signature.asc
Description: PGP signature
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-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/infrastructure@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: PACKAGE SOURCES site: Can't add a user as admin.

[Kevin Fenzi]

On Mon, Aug 22, 2022 at 12:06:38PM +0200, Jun Aruga (he / him) wrote:
> Hi,
> I tried to add a user [1] to the rpms/htslib [2] project as "admin" on
> the PACKAGE SOURCES (src.fedoraproject.org). But clicking the "Add"
> button on the "Add user" page, I got the error message below, even
> when the user has the role "member" of the "packager"[1].
> 
> "This user must be in one of the following groups to be allowed to be
> added to this project: packager".
> 
> Do you know how to add the user?

The user needs to logout and back on to src.fedoraproject.org. 

Group memberships are refreshed on login. So until they login again it
will not know they have been added to a new group. 

Hope that helps, 

kevin


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

Re: Cannot Login to Fedora Forums Issue

[Kevin Fenzi]

On Fri, Aug 19, 2022 at 07:59:59PM -, Robert Weir wrote:
> I am having issues with knowing what exact URLs to use and also cannot get my 
> SSO working for Fedora. 

Hey Robert. Sorry to hear it. 

Your subject mentions Fedora Forums... If you mean 
https://forums.fedoraforum.org/forum.php
thats actually run by it's own community and does not use the same
accounts as fedora proper. If you mean https://ask.fedoraproject.org
that does use the same accounts/passwords as fedoraproject does.

>  https://lists.fedoraproject.org  <--- is one address I have in my password 
> manager. This does not work.

Can you expand on how it doesn't work?

>  https://id.fedoraproject.org/login/fas  < is what I thought was a 
> 'single sign on' SSO for all things Fedora .  This no longer works.

Most auth indeed goes through id.fedoraproject.org, but you can't just
go directly there, you need to use the login button on the site or app
and it will redirect you to there if it needs do. 

>  https://lists.fedoraproject.org  <--- is the current website.
> How can I sort this out.  

You can login to lists at: 

https://lists.fedoraproject.org/accounts/login/

Press the 'fedora' button to login with your fedoraproject.org
account/password. 

Hope that helps. 

kevin


signature.asc
Description: PGP signature
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-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/users@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: Debugging Datanommer performance issues

[Kevin Fenzi]

On Thu, Aug 11, 2022 at 09:51:06AM +0200, Aurelien Bompard wrote:
> Hey folks!
> 
> There's been a report of queries long enough to cause a timeout in
> datagrepper:
> https://github.com/fedora-infra/datagrepper/issues/467
> I don't think those queries should take so much time, and I'd like to debug
> this performance issue, possibly try a couple new indexes on the tables,
> etc. However, I can't reproduce the issue on staging, probably because the
> datanommer database there is much smaller.
> So I was wondering what is the best course of action. I see the following
> options:
> 
>  1. Sync the prod DB to staging. This looks like an obvious first choice,
> but the messages in the staging DB actually come from the staging
> environment and are used by other contributors to check that their service
> is behaving properly on staging. Also, the topic prefix of the messages is
> different on staging and on prod, so syncing the DB with prod messages and
> then adding staging ones may cause a mess.

I think it might work, but not sure we have anyplace off hand with
enough disk space. We might. I can look more if this is the way we want
to go. 

> 2. Having a second datanommer DB in prod, and syncing them. The problem
> here is of course the disk space required. I don't know if that's even
> possible with the hardware we have.

It might be possible, but it's not a good way to go I don't think.

> 3. Something else?

Perhaps a aws instance? Just restore the db snapshot from prod and then
spin up a small datagrepper instance to talk to it?

kevin


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

Re: planet

[Kevin Fenzi]

On Wed, Aug 10, 2022 at 08:39:18PM -, Pedro Moura wrote:
> > The name of the blog/site? That's given by `item.feed.title`, see here:
> >
> > https://github.com/neurofedora/planet-neuroscientists/blob/master/neurosc...
> >
> > I remember we'd also looked into OpenSUSE's planet instance, which is a
> > more complex deployment (uses Jekyll etc. IIRC). That may be a better
> > starting point?
> >
> > https://github.com/openSUSE/planet-o-o
> > https://planet.opensuse.org/
> 
> Thanks! This tip and openSUSE repo really helped. I was able to get the 
> author, picture and do a work around to get the fas name.
> It seems we can keep the templates as they are in Fedora Planet and just 
> change it so pluto can build them.
> 
> Sharing what I've done so far:
> - Fedora Planet didnt had a repo, so I created one here 
> https://github.com/fedora-infra/planet
> - Everything was pushed on dev branch for now
> - Put Fedora Planet in a container
> - Changed only the index template of people's planet. Fedora Planet has about 
> 7 "planets", each "planet" has about 7 distinct html templates, they're 
> slightly similar tho. So the mission now would be changing those html 
> templates to erb templates so pluto can build them.

I don't think it has to be 100% exactly the same... just close... 

> I'd like to keep working on this, but also would like to hear from you all:
> - What do you think how this is going so far?
> - Any suggestions or anything I should have done?
> - Can I keep working on this?

I think you're doing great. ;) 

Once you have it generating pages, might be good to publish those
somewhere and everyone can look and see how it looks?

kevin


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

Re: Self-introduction

[Kevin Fenzi]

On Sun, Aug 14, 2022 at 08:07:52AM +, Mark E. Fuller wrote:
> Hi all,
> 
> I'm Mark Fuller (FAS: fuller) a long-time (since 16/Verne) Fedora-user and 
> packager.
> I recently made the move from being an engineering researcher who managed the 
> group IT on the side to being a full-time devops engineer.
> As such, I'm looking to start getting involved with Fedora Infrastructure to 
> apply what I'm doing and learning in my day job to contribute to the 
> community and also to get more exposure to systems outside of work to develop 
> a wider skill-set.
> 
> I'm open to suggestions as to where to start - I saw in the latest CPE 
> announcement about the FMN replacement (but not links). Since I'm tinkering 
> around the edges with RabbitMQ a bit, this is particularly interesting to me 
> if it's an AMQP-based system.
> Other than that, I'm competent in BASH and Python scripting and have some 
> experience with Go as well. I primarily do Kubernetes deployments and 
> monitoring and would also be particularly interested in working on CI/CD and 
> authentication.

Hi Mark, and welcome!

Hopefully you can drop on by #admin:fedoraproject.org (matrix) or
#fedora-admin (libre.chat) (bridged to the same thing). 

And/or join us at our next meeting on thursday... :) 

kevin


signature.asc
Description: PGP signature
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-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/infrastructure@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

congrats to our new sysadmin-mainers

[Kevin Fenzi]

I'm happy to announce that We have approved several folks into the
sysadmin-main group:

nphilipp - Nils Philippsen
zlopez - Michal Konečný
ryanlerch - Ryan Lerch

This is the core group of trusted folks that high level access to most
everything in fedora infrastructure.

Nils is a long time contributor who has worked on a bunch of things,
including our ipa sudo/ssh permissions setup. 

Michal has worked on many of our applications and is also serving to
help keep us on plan for planned work over the quarters. 

Ryan has been around for a long time working on many things, including
our revamped status application, FMN, gitlab permissions and more. 

They have both proved their dedication, trustworthiness, and ability.

Congrats to them all!

Use your powers for good! :)

kevin


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

Re: marketoblog

[Kevin Fenzi]

On Tue, Aug 02, 2022 at 08:27:11AM -0400, Ben Cotton wrote:
> On Tue, Aug 2, 2022 at 4:51 AM Tim via users
>  wrote:
> >
> > This doesn't appear to lead anywhere useful
> 
> There's an "Issues" tab across the top. I opened a request to update
> the link in the footer to be more direct:
> https://pagure.io/fedora-infrastructure/issue/10838

It should now have a link to the new_issue page... 

Hope that helps, 

(oh and I banned the spammer and deleted their spam from the archives)

kevin


signature.asc
Description: PGP signature
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-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/users@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: hackmd doc for nest infra mini barcamp

[Kevin Fenzi]

On Mon, Aug 01, 2022 at 05:36:03PM -0400, Stephen Smoogen wrote:
> On Mon, 1 Aug 2022 at 17:25, Jonathan Steffan 
> wrote:
> 
> > Kevin & Team,
> >
> > Will there be an option to join virtually or review meeting notes?
> >
> >
> It's all virtual for Nest. You just need to register for Nest.

Yeah, also it should be recorded (the video/audio/chat part of things)
and we will hopefully have notes in the hackmd doc from all the things
we discussed. ;) 

kevin


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

hackmd doc for nest infra mini barcamp

[Kevin Fenzi]

On Tue, Jul 12, 2022 at 06:07:54PM -0700, Kevin Fenzi wrote:
> I put in for a 1/2 day mini hackfest for infra and releng at nest.
> 
> See: 
> 
> https://pagure.io/flock/issue/393
> 
> My thought was to collect ideas for cool things we could work on or do,
> vote on them before the event and do them in most popular order. 
> (bar camp style).
> 
> Please do chime in here or in the flock issue if you have ideas or would
> rather do something else. :) 

I've looked around at various tools, but decided to try and keep things
simple, so I made a hackmd document for us to use. 

https://hackmd.io/MiWdaZXCRDi4LEO1jmyLDg

Please add topics you would like to see discussed and also vote on how
long we should discuss each (we have 90min, so we could do 3 30min, 6
15min, 9 10min). I already added a topic myself. Ideally also each topic
would have a 'note taker' who can record notes about the discussion into
the hackmd while it's ongoing.

The first 15min I want to use for introductions and last minute voting /
topics, then we can dive on in. ;) 

I also left a 30min block at the end for wrapping up, and also
revisiting things we ran out of time for or new things we wanted to get
to. 

If there's not enough topics, I will add more. I am sure we can find
things for me to bloviate on for the entire time. ;) 

Looking forward to seeing everyone and having some great discussions!

kevin


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

Re: Where should mirroring docs live?

[Kevin Fenzi]

On Fri, Jul 29, 2022 at 11:21:13AM -0400, Ben Cotton wrote:
> Hi folks,
> 
> adamw noticed that we have two pages that claim to give information
> about setting up a public mirror: a wiki page[1] and a Quick Docs
> page[2] which is actually blank. This is one more than we need, so the
> question is how to fix it.
> 
> We can either leave the wiki page as-is and remove the Quick Docs
> page. Or we can port the wiki to Docs and set up a redirect. If we do
> that, I think it's probably better suited for the infra docs than the
> Quick Docs.

yeah, I think it would be good to move the wiki page over to a infra
docs page. 

But there's no hurry I don't think?

kevin


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

Re: planet

[Kevin Fenzi]

On Thu, Jul 21, 2022 at 11:45:31AM -, Pedro Moura wrote:
> Hi everyone. I was taking a look at this and trying to migrate Fedora Planet 
> to pluto and have some questions. 
> 
> Some things in pluto are not done yet, for example getting the author is 
> something marked as "to be done" in the documentation  
> https://feedreader.github.io/#planet-planet--pluto---template-cheatsheet-1 
> and even some pluto standard templates are still a WIP 
> (https://github.com/orgs/planet-templates/repositories).
> Even with those limitations, I searched if there was a way to get the same 
> info we have using venus, but nothing seems to work.
> Fedora Planet and its sub planets have their own distinct template, but not 
> being able to "translate" every variable to pluto or changing to any standard 
> pluto template, would make a lot of changes in the website.

I think we are open to changes here as long as they are reasonable ones. 
Not having author is pretty major sounding though. ;( 

Can any of the neuro folks provide some help here? 

> The Neuro SIG used a standard pluto template called forty and did some 
> customization. Should we do the same with Fedora Planet? 

Yeah, thats fine as long as we can still have things like author and
such. Perhaps it would be worth trying to get it to do a few feeds and
we can all look at it?

> Could we keep Fedora Planet with venus for now and just work to put it in 
> openshift?

I don't think we want to do that. We should wait for pluto before moving
to openshift.

> Or should we follow any other path Kevin proposed?

I'd say perhaps try and get pluto working with just a few feeds and we
can see how it looks like? Then, we can work on the part where it pulls
the feeds from the account system, then after that, we can look at
putting it in openshift. 

Just my thoughts... 

kevin


signature.asc
Description: PGP signature
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-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/infrastructure@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: Email replies to src.fpo notifications

[Kevin Fenzi]

On Wed, Jul 13, 2022 at 08:13:23PM -, Frank R Dana Jr. wrote:
> Recently, after receiving an email notification regarding a pull request at 
> src.fedoraproject.org, I attempted[1] to update the discussion via email 
> reply to the notification email.
> 
> That attempt was not successful. Moreover, I was only made AWARE that the 
> attempt was  unsuccessful 24 hours later, when Google's MTA responded with an 
> undeliverable notification saying that it couldn't contact the recipient 
> email, pag...@pkgs.fedoraproject.org.
> 
> If email reply to src.fpo notifications is supposed to be working, it's not. 
> If it's INTENDED  not to be working, then perhaps the reply address for 
> notifications could be set to something that bounces immediately 
> (donotre...@fedoraproject.org or similar, perhaps?), rather than an address 
> at a non-responsive hostname that's subject to lengthy timeouts before the 
> status of the attempted reply is updated?

So, I am not sure what was intended long ago, but to my understanding
it's never worked, nor was it setup to work. 

We could do either thing here now however, we could make it work or as
you say send it to a no reply address. 

I'm inclined to do the second one. In order to make it work we would
have to allow unrestricted smtp into the pkgs machine, which seems like
a poor idea for one of our most secure machines. ;( 

I'll wait and see what other opinions folks have, but I am leaning
toward just making sure it's not working and it's more obvious that it's
not. 

kevin


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

Re: SATA optical drives

[Kevin Fenzi]

On Fri, Jul 15, 2022 at 02:16:51AM +0930, Tim via users wrote:
> On Thu, 2022-07-14 at 11:29 +, Allhdd Coumputer wrote:
> > Hi You can do a couple of things to solve that issue. You can check
> > the optical device cable. it may be a driver issue you can upgrade
> > your optical device's driver. or you can buy a new cable.
> > Or you can also try to change your optical device or buy a new one.
> 
> This post (without it quoting what it was replying to) is actually a
> reply to a message from 2007 on hyperkitty:
> 
> https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org/thread/MSXW5F4SWQQ7I62CEWQDXMPHTAIQTZFH/
> 
> Ye gads!  Yet another thing I don't like about web forums.  Perhaps it
> ought to automatically limit responses to ancient posts?  Or, at least,
> display a huge warning to someone who tries to respond to one.
> 
> However, I consider it's also a spam.  It's a link to a sales page for
> an optical fibre cable, which has nothing to do with SATA vs PATA
> connections for optical drives as the original thread discussed.

Yeah, I agree. I moderated the user and removed the post from archives. 

kevin


signature.asc
Description: PGP signature
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-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/users@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

nest infra mini barcamp

[Kevin Fenzi]

I put in for a 1/2 day mini hackfest for infra and releng at nest.

See: 

https://pagure.io/flock/issue/393

My thought was to collect ideas for cool things we could work on or do,
vote on them before the event and do them in most popular order. 
(bar camp style).

Please do chime in here or in the flock issue if you have ideas or would
rather do something else. :) 

kevin


signature.asc
Description: PGP signature
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-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/infrastructure@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
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-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/infrastructure@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: Software Bill of Materials for Fedora

[Kevin Fenzi]

On Mon, Jul 11, 2022 at 09:22:48AM -0400, Frank Ch. Eigler wrote:
> Hi -
> 
> > [...] Let me know your thoughts. I didn't provide a link to the code
> > repository as it's currently private to Red Hat associates. But we
> > expect to opensource the project in the coming weeks. At that time
> > we'll be able to provide the source code. [...]
> 
> I suspect your message is hard to answer substantively without any
> information about the scale and composition of this infrastructure,
> its needed inputs, resources, usefulness (in terms of client tooling),
> and so on.

Yeah. Once the open sourcing happens, perhaps we could get a overview of
how it works, what it needs, etc.

kevin


signature.asc
Description: PGP signature
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-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/infrastructure@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

Bon-voyage to our openshift3 cluster

[Kevin Fenzi]

Now that everything is moved off it as far as I can tell, I am going to
take down the openshift3 cluster tomorrow. If there's something you need
it for still, please let me know asap. 

It's served long and well... we installed it back in Aug of 2017, almost
5 years ago now. It's run countless applications and gone through
countless upgrades. It helped us move from phx2 to iad2. It gave us a
nice way to deploy and manage applications. 

The openshift 4 cluster has now taken over things and we look forward to
as many years or more with it. :) 

kevin


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

Re: infra-sig packaging group packages

[Kevin Fenzi]

Sorry, just realized I didn't reply to this... 

On Sun, Jul 03, 2022 at 07:25:04AM +, Mattia Verga wrote:
> Il 02/07/22 21:51, Kevin Fenzi ha scritto:
> > * Are you a packager already (ie, in the packager group) and would like
> > to help us out by maintaining infra-sig packages? Let me know if so!
> I can help with that. In fact, I already maintain a few packages. I'm a
> provenpackager, but I don't strictly need to be added to the infra-sig
> group,but that would help to receive bug reports and notifications.

Sure. I can add you!

> > * Finally, I'd like to drop some packages that the sig currently
> > maintains. There's 68 packages that the infra-sig is admin on currently.
> > There's 222 packages infra-sig has commit on.
> >
> > I'm not sure how best to takle the list(s). I guess we could just go
> > through them one by one sometime? or everyone could propose a list we
> > should drop/add?
> >
> > https://www.scrye.com/~kevin/fedora/infra-sig (admin)
> > and
> > https://www.scrye.com/~kevin/fedora/infra-sig2 (commit)
> >
> > Some are obvious (pam_url), others less so (do we use python-gearbox?)
> >
> - I've recently orphaned pam_url because, as discussed in another
> thread, it's not used anymore in fedora infra. The infra-sig group was
> added as admin, so it should be possible to drop the package by anyone
> in the group.

Yeah, and done.

> 
> - python-robosignatory is in good shape and I added infra-sig as admin.

great!

> - reg is FTB lately. As discussed some time ago in another thread, I'm
> not particularly familiar with Golang and upstream is dead. The spec
> file was reworked by eclipseo few months ago. I can try to fix it, or
> ask for help by go-sig, but I remember there was a discussion to use
> flatpak-indexer or move the registry to quay
> (https://pagure.io/fedora-infrastructure/issue/10386).

Well, flatpak-indexer and reg do different things. 
flatpak-indexer basically makes delta sets, so flatpak updates only need
to download the delta/changes between versions, not the entire thing. 
reg makes a pretty index web page for people to see the containers we
have there if they want from a browser. 

Moving to quay should somewhat cause reg to no longer be needed, but
likely we will keep needing flatpak-indexer. 

> 
> - the 'bodhi' package can be retired and dropped. Instead, infra-sig
> should be added to 'bodhi-[server|client|messages]' packages.

Ah yeah. Good idea. 

kevin


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

Re: Fedora OCP 3.11 -> 4.10 Data Migration Proposal

[Kevin Fenzi]

On Mon, Jul 04, 2022 at 02:18:45PM +0100, David Kirwan wrote:
> I've added Prakash
> https://accounts.stg.fedoraproject.org/user/prakashmishra1598/ to the
> `sysadmin-openshift`, I'm not a sponsor for `sysadmin`, Kevin would you
> mind adding him there on staging please!

Sure. Done.

kevin


signature.asc
Description: PGP signature
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-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/infrastructure@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: infra-sig packaging group packages

[Kevin Fenzi]

On Sat, Jul 02, 2022 at 05:36:52PM -0500, Maxwell G wrote:
> On Saturday, July 2, 2022 2:51:02 PM CDT Kevin Fenzi wrote:
> > * Are you a packager already (ie, in the packager group) and would like
> > to help us out by maintaining infra-sig packages? Let me know if so!
> 
> I have been handling the ansible collections (besides ansible-collection-
> google-cloud) for a little while now. I'm happy to continue doing that. If 
> you 
> want to add me to the infra-sig, I can try to help out with bugs and updates 
> when I have the time.

That would be awesome!

> Also, I remember that there was an issue with the fedora-messaging ansible 
> callback plugin not working due to fedora-messaging not being packaged for 
> python38 on EPEL 8. Is that still an issue? I could maybe (not promising :)) 
> help with that.

Well, yes and no. Currently the callback plugin doesn't work, but that
just means no fedora-messages for ansible playbook runs in
infrastructure. I am not sure anyone but me cared about them. In order
to make it work, I think we would need to make a complete pile of
fedora-messaging packages against python3.8. However, I'm thinking we
should just move batcave01 to rhel9 soon and that will make this not
matter (at least for a while, until ansible-core needs python3.12 or
something). 
> 
> > * Finally, I'd like to drop some packages that the sig currently
> > maintains. There's 68 packages that the infra-sig is admin on currently.
> > There's 222 packages infra-sig has commit on.
> 
> I'm assuming the packages where Fedora Infra is the upstream (e.g. bodhi*) 
> will be kept?

Yes. Many of those were also setup with packit to keep them updated,
which is nice. 

> I opened up a couple random packages and noticed that mote, which is in the 
> second list, was retired by @churchyard 2 years due to it FTI, but it still 
> exists in epel7. I would suggest either going through the unretirement 
> process 
> or just completely retiring and then orphaning that package. 

We just deployed a completely new version of mote. 
We don't deploy it via rpms, and I don't know if there's any plans to
package it, but if there is, it could be re-added and use the mote rpm
package name. 

> pam_url was 
> orphaned two weeks ago, but @infra-sig still has admin on that package. 
> @infra-sig can probably be removed from that package.

Yeah. Done.

> Maybe it would also be worthwhile to triage/reassign bugs with the packages 
> the @infra-sig maintains in the weekly infra meeting so all of the work 
> doesn't fall on you? (I occasionally skim the meeting meeting minutes, but 
> maybe I'll join one day if the scheduling works out!).

We could... we already spend a lot of time on tickets tho. 
I suppose we could take our current schedule of doing one learning topic
and one ticket triage to 3: learning, then tickets, then bugs?

For incoming things we might be able to add them to the daily standup...
but I don't think we can get through backlog there. 

kevin


signature.asc
Description: PGP signature
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-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/infrastructure@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