Re: Enabling plymouth on livemedia-creator iso creation

[Kevin Fenzi]

On Tue, Feb 14, 2023 at 02:19:15PM -0800, Brian C. Lane wrote:
> Way back in the day... :) livemedia-creator inherited an '--omit
> plymouth' from the boot.iso creation process. The boot.iso was changed a
> few years later, but lmc kept it. Fred noticed this and submitted
> https://github.com/weldr/lorax/pull/1307 to conditionally fix it.
> 
> But I think we can just remove it. This has been working fine for the
> boot.iso and in my testing here with a BIOS and UEFI VM it works fine
> when you drop it from lmc's dracut configuration as well.
> 
> So, are there any objections to
> https://github.com/weldr/lorax/pull/1308 for rawhide at least? I'm not
> sure if we want to change it for F38 at this point or not (less change
> is better).

Seems fine to me. If you are gonna do it for f38, I would do it very
soon so there's time before freeze to revert if anything happens...

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: Planned Outage - s390x builders - 2023-02-10 08:00 UTC -> 22:00 UTC

[Kevin Fenzi]

On Mon, Feb 13, 2023 at 03:01:34PM +0100, Luna Jernberg wrote:
> ssmoogen
> Current s390x status: Networking and storage on systems is not acting
> appropriately. Site admins are trying to figure out what is going on.

Everything is back up now. 

Sorry for the extended outage. We will will talking with various folks
to try and prevent this happening again. 

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: Planned Outage - s390x builders - 2023-02-10 08:00 UTC -> 22:00 UTC

[Kevin Fenzi]

On Sun, Feb 12, 2023 at 09:30:53PM +, Sérgio Basto wrote:
> On Sat, 2023-02-11 at 10:54 +0100, Dan Horák wrote:
> > On Sat, 11 Feb 2023 09:37:08 +
> > "Richard W.M. Jones"  wrote:
> > 
> > > On Thu, Feb 09, 2023 at 11:35:14AM -0500, Stephen Smoogen wrote:
> > > > Affected Services:
> > > > 
> > > > s390x koji builders. Jobs will queue up, but not be processed
> > > > until
> > > > the builders are back online. Maintainers are urged to just avoid
> > > > submitting builds just before and during this outage.
> > > 
> > > Do we need to cancel & resubmit hanging jobs, eg:
> > > 
> > > https://koji.fedoraproject.org/koji/taskinfo?taskID=97341784
> > 
> > those are OK, they are waiting. When s390x builders are back up, they
> > will pick them and finish the builds.
> 
> 
> I saw that s390x are back but seems to me that they are all stuck :(

They are not back. At least I see no evidence that they are. ;) 

Sorry this outage has gone on. The power was restored pretty quickly,
but apparently there's some issue with the mainframe storage now. ;( 

I hope it will be sorted out tomorrow. 

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: Unable to create f38 branch

[Kevin Fenzi]

On Sat, Feb 11, 2023 at 12:19:30PM -0800, Luya Tshimbalanga wrote:
> 
> On 2023-02-11 12:15, Kevin Fenzi wrote:
> > On Sat, Feb 11, 2023 at 11:47:26AM -0800, Luya Tshimbalanga wrote:
> > > Hello team,
> > > 
> > > I am unable to create a f38 branch for f38-backgrounds at this time of
> > > writing. Does it mean the branching is in process?
> > No, branching was all completed a while back.
> > 
> > Can you expand on why/what happens/what you are doing that makes it
> > unable to be created? Can you file the ticket? did the scm processor
> > fail to process it? was there any errors?
> > 
> > kevin
> > 
> Yes using the simple "fedpkg request-branch --repo" command. See the ticket
> on https://pagure.io/releng/fedora-scm-requests/issue/51086 showing
> 
> "Couldn't find standard SLA for branch 'f38'" message.

Ah yes, thats tracked at https://pagure.io/releng/issue/11271

Tomas is looking into 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

Re: Unable to create f38 branch

[Kevin Fenzi]

On Sat, Feb 11, 2023 at 11:47:26AM -0800, Luya Tshimbalanga wrote:
> Hello team,
> 
> I am unable to create a f38 branch for f38-backgrounds at this time of
> writing. Does it mean the branching is in process?

No, branching was all completed a while back. 

Can you expand on why/what happens/what you are doing that makes it
unable to be created? Can you file the ticket? did the scm processor
fail to process it? was there any errors?

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: s390x emulation build woes

[Kevin Fenzi]

On Sat, Feb 11, 2023 at 06:42:51AM -0600, Richard Shaw wrote:
> On Sat, Feb 11, 2023 at 12:13 AM John Reiser  wrote:
> 
> > On 2/10/23 19:57, Richard Shaw wrote:
> > > So I know the s390x builders are down but I have an active BZ for tests
> > failing with s390x so I figured what the heck, maybe doing a local
> > mocbuild attempt using qemu could help here like it did with aarch64.
> > >
> > > Well at first everything seemed to be working as normal but all of the
> > repo package GPG checks failed.
> >
> > Almost certainly an endian problem (or two, or three).
> > x390x is big endian; almost everything else is little ehdian.
> > Run the self tests of each crypto piece using the same emulator.
> >
> 
> Well it looks like I mis-spoke slightly late last night... the GPG check
> didn't fail, it's saying they aren't available:
> Public key for zstd-1.5.2-4.fc38.s390x.rpm is not installed. Failing
> package is: zstd-1.5.2-4.fc38.s390x
>  GPG Keys are configured as:
> file:///usr/share/distribution-gpg-keys/fedora/RPM-GPG-KEY-fedora-38-primary,
> file:///usr/share/distribution-gpg-keys/fedora/RPM-GPG-KEY-fedora-38-primary,

Is that really the same one twice?

> file:///usr/share/distribution-gpg-keys/fedora/RPM-GPG-KEY-fedora-37-primary
> Error: GPG check FAILED
> 
> Perhaps this is a branching issue, I'm F37 now and it appears to be
> working, albeit quite slow :)

Yes, it could be... we need to get new branched/rawhide composes out to
fix up the last of the issues, but we cannot until the s390x builders
are back. ;( 

Hopefully later 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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Request exemption for f38-backgrounds

[Kevin Fenzi]

On Wed, Feb 08, 2023 at 07:42:35PM -0800, Luya Tshimbalanga wrote:
> Hello team,

Hey there. 

> I filed an exemption[1] for f38-backgrounds packaging review[2] as
> suggestion from desktop team on discussion last year. The spec file remains
> virtually unchanged other than an updated default wallpaper.

Cool. 

Note, with the exception, there's no need to file a review ticket. 
You can just close that as fixed. The exception there bypasses the
requirement for a review. 

Thanks for working on this...

kevin


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Fedora Linux 38 branched

[Kevin Fenzi]

On Fri, Feb 10, 2023 at 03:21:06PM +, Zbigniew Jędrzejewski-Szmek wrote:
> On Thu, Feb 09, 2023 at 06:44:03PM +0100, Tomas Hrcka wrote:
> > Hi All,
> > 
> > Fedora Linux 38 has now been branched, please be sure to do a git pull
> > --rebase to pick up the new branch
> 
> I know this has been discussed seemingly on every branching since the
> switch to git, but anyway...
> 
> 'git pull --rebase' is a strange command to suggest. I does the job,
> but almost by accident, and it's confusing things by mixing in rebasing.
> Can we make this just say 'git fetch' or 'git fetch -v' ?

Sure!

I've pressed to move all our email announcements into git...

so https://pagure.io/releng/blob/main/f/mail-templates/03-mass-branch.txt

PR's welcome!

I mostly just moved the old email versions into there, so they could
likely use a lot of improvement.

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: Risc-V SIG?

[Kevin Fenzi]

On Thu, Feb 09, 2023 at 11:03:27AM +, Zbigniew Jędrzejewski-Szmek wrote:
> On Thu, Feb 09, 2023 at 10:55:50AM +, Richard W.M. Jones wrote:
> > On Thu, Feb 09, 2023 at 10:38:38AM +, Zbigniew Jędrzejewski-Szmek wrote:
> > I just got a VF2 as well (as in, yesterday).  I'm still waiting on
> > some bits and pieces before I try to make it work.
> 
> FWIW, it seems to work fine with just a shared USB power supply and an
> ethernet cable. It warms up to ~64C when running all 4 cores, so I
> just ordered a rpi heatsink to glue on top.
> 
> > I support creating a SIG.
> 
> I'll wait for some more replies and then see what paperwork is needed.
> IIRC, it's mostly a question of creating a page with a short intro
> and a list of names.

Yep. Sigs exist because they say they do. ;) 

The risc-v sig has been around for a while, but I guess a sig wiki page
was never made. :( 

So, sure, we should setup a page and point to the discussion topic and
irc/matrix rooms. :)

If you could do that it would be great... otherwise 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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: bodhi tests missing

[Kevin Fenzi]

On Fri, Feb 03, 2023 at 05:27:06PM -0700, Orion Poplawski wrote:
> 
> Thanks, but no go:
> 
> bodhi updates trigger-tests FEDORA-2023-96ebcd6f4d
> Login successful!
> Traceback (most recent call last):

This may well be because those updates are in a updates push right now
and the updates are locked. 

Try again later tonight/tomorrow/later?

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: shorter shutdown timers are now enabled in rawhide

[Kevin Fenzi]

On Fri, Feb 03, 2023 at 06:32:20PM +0100, Fabio Valentini wrote:
> 
> It's a 1:1 copy of the update "notes" from bodhi (except re-flowed to
> fit into however many columns plain-text emails support).
> So it's "markdown", not "awful", but sometimes it's hard to see the
> difference ;)
> Not sure if it would be possible for bodhi to convert markdown update
> notes to "plain text" (i.e. drop all markup) before including it in
> the emails it sends out ...

Yeah. Please file RFE at https://github.com/fedora-infra/bodhi ?

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: [SPF:fail] A coordinated plan for ansible-collection updates in EPEL?

[Kevin Fenzi]

On Tue, Jan 31, 2023 at 07:21:03PM -0700, Orion Poplawski wrote:
> On 1/31/23 11:03, Maxwell G wrote:
> > On Tue Jan 31, 2023 at 15:01 +0200, Sagi Shnaidman wrote:
> > Hi all,
> > 
> > > Hi, Orion
> > > Thanks for raising this question.
> > 
> > Indeed!
> > 
> > > I wonder if it's possible to continue to update collections to the
> > > newest versions anyway. If someone wants to use the collection version
> > > provided in "big ansible", they would use ansible 6.3.0 with all
> > > included. If they want a newer collection, they can install a separate
> > > newest RPM.
> > 
> > I agree. I think we should update collections to the next major version
> > (if it exists) after each RHEL minor release and then keep them updated
> > with point releases in between. We update the ansible bundle to the next
> > major version that corresponds to RHEL's ansible-core version at each
> > RHEL minor release, so it makes to do the same with the standalone
> > collection packages. Collection versions that are EOL upstream won't be
> > tested with newer ansible-core versions.
> 
> Does this capture the general sentiment?
> 
> - ansible is the static/stable collection of collections paired with the
> provided ansible-core for the life of the point release
> 
> - ansible-collection-* packages will be at least the version of the
> collection in ansible, and optionally higher while giving due diligence to
> avoiding breaking changes.

That sounds mostly reasonable. I guess I could come up with a crazy case
like 'the version in ansible has some problem that wasn't noticed, so I
want to keep the seperate collection on a older version until it's
fixed' though. 

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: How to migrate database format during package update?

[Kevin Fenzi]

On Wed, Feb 01, 2023 at 01:56:20PM +0100, Milan Crha wrote:
>   Hi,
> this is a query for an opinion and a best-practice experience for a
> case when a package needs to change its internal database format
> between versions, in an environment, which does not allow real
> migration, aka the app cannot read both formats, it can use one or the
> other.
...snip...
> 
> I'm sure you might find more disadvantages, these are just the top
> four.
> 
> That being said, any such change surely deserves release notes, with
> the commands what to do to export and then back import the wordlist.
> There should be filled a corresponding Change too, I guess.
> 
> Still, how does other packages migrate their data, or at least help the
> users with the migration? Is there any way?

Modifying users home directories is explicitly against packagin
guidelines. ;(

https://docs.fedoraproject.org/en-US/packaging-guidelines/#_no_files_or_directories_under_srv_usrlocal_or_homeuser

Is there any way to pull the functionaly into the process itself? 
ie, the first time it's called, it converts the db? (But that might make
it really slow on the first call). Or perhaps it just warns there and
points to the script the user can run to do the conversion?

I suppose there's the way postgresql does it... including a copy of the
old server binaries that can read the old format in the new rpm so it
can use that to convert to the new format?

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: Bootstrapping package with circular dependencies in koji

[Kevin Fenzi]

On Tue, Jan 31, 2023 at 07:06:25PM -0700, Orion Poplawski wrote:
> On 1/31/23 11:06, Kevin Fenzi wrote:
> > On Tue, Jan 31, 2023 at 02:23:48PM +0100, Vít Ondruch wrote:
> > > 
> > > 
> > > It seems that Koji supports this, but it need some configuration change. I
> > > have opened followup ticket here:
> > > 
> > > https://pagure.io/releng/issue/11254
> > 
> > Yeah, my first thought about this was that it might be too broad, but it
> > was pointed out that maintainers can already override macros in specs
> > anyhow.
> > 
> > Might run it by FESCo just to make sure everyone is ok with enabling...
> > 
> > kevin
> 
> I would think the main concern is the audit trail.  Defining a macro in a
> spec file is checked into git and there is a record.  Is there a record (and
> relatively easily accessed) for the macros set in a side tage?

Yeah, koji list-history will show it... but that may not be an obvious
place to look. For bootstrap purposes you still need 1 commit saying you
did the bootstrap, so perhaps thats enough...

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: What should we do about "shopping list" groups in comps?

[Kevin Fenzi]

On Tue, Jan 31, 2023 at 02:39:27PM -0800, Adam Williamson wrote:
> Hey folks!
> 
...snip...
> 
> So, I'm wondering what folks think we should do with these. We could,
> of course, just get rid of them. But perhaps they are still of value to
> someone? Is anyone still "package shopping" via dnfdragora or some
> other tool, using these groups? Does anyone want to step up and
> actively 'own' some of them for maintenance? Any other thoughts?

I'd be in favor of removing them (of course with a change and giving
notice, etc). 

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: [SPF:fail] A coordinated plan for ansible-collection updates in EPEL?

[Kevin Fenzi]

On Tue, Jan 31, 2023 at 06:03:48PM +, Maxwell G wrote:
> On Tue Jan 31, 2023 at 15:01 +0200, Sagi Shnaidman wrote:
> Hi all,

Note that some folks cc'ed are not subscribed to epel-devel, so it
probibly rejected their posts. :( 

> 
> > Hi, Orion
> > Thanks for raising this question.
> 
> Indeed!
> 
> > I wonder if it's possible to continue to update collections to the
> > newest versions anyway. If someone wants to use the collection version
> > provided in "big ansible", they would use ansible 6.3.0 with all
> > included. If they want a newer collection, they can install a separate
> > newest RPM.
> 
> I agree. I think we should update collections to the next major version
> (if it exists) after each RHEL minor release and then keep them updated
> with point releases in between. We update the ansible bundle to the next
> major version that corresponds to RHEL's ansible-core version at each
> RHEL minor release, so it makes to do the same with the standalone
> collection packages. Collection versions that are EOL upstream won't be
> tested with newer ansible-core versions.

Yes, when we first started to package collections we made sure (although
I have not checked if anything changed) that the seperately packaged
collections would override the bundled ones in the ansible package. 

So, while the ansible collection of collections and ansible-core are
(and should be) closely tied together, the seperately packaged ansible
collections should be free to update as long as they continue to work ok
with ansible-core thats provided/etc. 

So, in practice I personally have been thinking of 'ansible' as the
stable collection of collections, and the seperately packaged
collections as 'next' or 'fast moving' channel. 

Just my 2cents.

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

[EPEL-devel] Re: Replace versioned MODULE_COMPAT_ requires by generators

[Kevin Fenzi]

On Tue, Jan 31, 2023 at 10:19:09AM +0100, Jitka Plesnikova wrote:
> Hi,
> 
> I added the package perl-generators-epel to EPEL 7/8/9. The package is
> adding the behavior provided in perl-generators-1.16.
> 
> I created pull requests for epel-rpm-macros to add perl-generators-epel
> to EPEL buildroot.
> 
> Pull Request
> EPEL 7: https://src.fedoraproject.org/rpms/epel-rpm-macros/pull-request/61
> EPEL 8: https://src.fedoraproject.org/rpms/epel-rpm-macros/pull-request/60
> EPEL 9: https://src.fedoraproject.org/rpms/epel-rpm-macros/pull-request/59
> 
> Could anybody please merge them and build the packages or shall I do it
> myself?

Done. Building now. 

Thanks for the pr's

kevin
--
> 
> Thanks,
> Jitka
> 
> On 12/6/22 04:40, Maxwell G via epel-devel wrote:
> > On Mon Dec 5, 2022 at 21:52 +0100, Jitka Plesnikova wrote:
> > > Could be the following file added to the package epel-rpm-macros (or
> > > anything like this) for EPEL 9?
> > It could, but it might be better to include this in a subpackage of
> > epel-rpm-macros or as a separate perl-generators-epel component. We
> > could pull it in with (package-name-here if perl-generators). This won't
> > work in EPEL 7 which unfortunately doesn't support rich dependencies.
> > 
> > > But I don't know how to do it for EPEL 7/8, because the above file
> > > doesn't work.
> > > It ends with error [2]:
> > > error: Couldn't exec perl-libs: No such file or directory
> > > 
> > > Do you have any idea if there is any other way how to provide
> > > maintainers this functionality for EPEL 7/8?
> > Parametric macro dependency generators are not supported in EPEL 7 and
> > 8's RPM versions. You can still implement this using a "regular"
> > dependency generator. This is also described in the RPM
> > documentation[1]. Instead of specifying %__perlcompat_requires() and
> > writing an RPM macro that accepts a path name as %1, you specify
> > `%__percompat_requires /path/to/executable`. That script receives a
> > newline separated list of paths as stdin and prints the generated
> > dependencies to stdout separated by newlines.
> > 
> > So perlcompat.attr could look something like
> > 
> > ```
> > %__perlcompat_requires %{_rpmconfigdir}/perlcompat.req %{perl_version}
> > 
> > # %%__perlcompat_path can stay the same.
> > ```
> > 
> > These are usually stored in %%{_rpmconfigdir}. %%{perl_version} is
> > passed to the script as an argument, because the script of course
> > doesn't have access to the RPM context. This can be any executable
> > written in any language, but it should be straightforward to do this in
> > shell.
> > 
> > 
> > [1]: 
> > https://rpm-software-management.github.io/rpm/manual/dependency_generators.html
> > 
> > --
> > Maxwell G (@gotmax23)
> > Pronouns: He/Him/His
> > ___
> > 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
> 
> -- 
> Jitka Plesnikova
> Senior Software Engineer
> Red Hat
> ___
> 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


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: Bootstrapping package with circular dependencies in koji

[Kevin Fenzi]

On Tue, Jan 31, 2023 at 02:23:48PM +0100, Vít Ondruch wrote:
> 
> 
> It seems that Koji supports this, but it need some configuration change. I
> have opened followup ticket here:
> 
> https://pagure.io/releng/issue/11254

Yeah, my first thought about this was that it might be too broad, but it
was pointed out that maintainers can already override macros in specs
anyhow. 

Might run it by FESCo just to make sure everyone is ok with enabling...

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 38 mass rebuild is finished

[Kevin Fenzi]

On Tue, Jan 24, 2023 at 09:42:10AM +, Zbigniew Jędrzejewski-Szmek wrote:
> On Mon, Jan 23, 2023 at 06:52:30PM -0800, Kevin Fenzi wrote:
> > On Mon, Jan 23, 2023 at 10:26:18PM +, Sérgio Basto wrote:
> > > 
> > > I found more 5 with
> > > https://koji.fedoraproject.org/koji/tasks?owner=releng=active=tree=all=-id
> > > 
> > > 96481236   build (f38-rebuild,
> > > /rpms/yaksa.git:528d57e3c954abfedba6f530f5ac09abaa9170fa)
> > > 
> > > 96474133   build (f38-rebuild, /rpms/trace-
> > > cmd.git:d9631ac81ad4f30b7ca5ed8a7d3b57131c545080)
> > > 
> > > 96404064   build (f38-rebuild, /rpms/perl-
> > > SDL.git:347cf3fb5ac90e14b96381722bc335744077e967)
> > > 
> > > 96383273   build (f38-rebuild,
> > > /rpms/octave.git:93e5fb4a813805c66ec7107da26be2d52039106d
> > > 
> > > 96368979   build (f38-rebuild,
> > > /rpms/libtracecmd.git:121d11cfd26c3a0d61671b83f32b0be1ec75f1ff)
> > 
> > Yes, I have canceled all those now. 
> 
> I started builds for all of those now.

All of them have hung again after running since you started them. 

I think someone is going to need to try and build them in local mock and
see where they are getting stuck. 

Can you cancel them again? Or would you like me to try and look and see
what they are hung on?

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: Proposal: dnf should offer to update all of the dependencies of any package installed or updated

[Kevin Fenzi]

On Sat, Jan 28, 2023 at 09:03:35PM +, Zbigniew Jędrzejewski-Szmek wrote:
> 
> This is indeed a shortcoming in the rpm symbol dependency generation scheme.

Is it though? I'm probibly reading this too quickly and missing
something, but isn't the underlying problem here that nghttp2 changed
abi and didn't change soname? If they had, soup would have kept the
older version around, or asked to upgrade both libsoup and libnghttp2?

Or did I miss some part of this?

...snip symbol versioning... 

symbol versioning does indeed sound like a better way to do 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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Nonresponsive maintainers ( was Re: Red Hat Bugzilla mail FAS field is now handled correctly by Bugzilla sync scripts )

[Kevin Fenzi]

On Tue, Jan 17, 2023 at 02:49:10PM +0100, Michal Konecny wrote:
> Hi everybody,
> 
> TL;DR; Check if you have correct e-mail in Red Hat Bugzilla Mail field in
> Fedora Accounts [0]. Empty mail is also OK.
> 
> the Red Hat Bugzilla Email field in Fedora Accounts [0] was till now ignored
> by most of the apps.
> 
> This was changed now with the latest update to toddlers [1], which contains
> most of the syncing scripts that are run automatically in Fedora Infra
> including distgit_bugzilla_sync [2], packager_bugzilla_sync [3] and
> packagers_without_bugzilla [4] scripts. All these scripts are using shared
> methods for working with Fedora Accounts system.
> 
> With the addition of scm_request_processor [5] there was a small change in
> how the Fedora Accounts mails are handled in regard to Red Hat Bugzilla
> mail. This change caused it to first look for Red Hat Bugzilla Mail and then
> look at the personnel e-mail associated with the account if Bugzilla mail is
> not set.
> 
> This unfortunately caused issues for some users that had Red Hat Bugzilla
> Mail field set incorrectly. I was the one who did the change and I actually
> forgot about it, because it happened at the beginning of
> scm_request_processor development cycle and I didn't know it could have that
> large impact. So I apologize for any issue this could have caused for you.
> 
> If you are one of the users, who were impacted by this change, you can fix
> it by adding correct Red Hat Bugzilla mail to your Fedora Account. You can
> do this in Settings->Emails in Fedora Accounts page [0].
> 
> We will fix the message that is being sent to packagers without Bugzilla
> e-mail to correspond with this change.

Hello everyone. 

After this we still have 4 users who's bugzilla email does not exist. :( 

They are: 

dctrud
jaltman
npmccallum
sbluhm

Does anyone know how to contact them?

If not, I will file a FESCo ticket in a week indicating that they have
no bugzilla email set (or set wrong) and should be removed from any
packages they maintain or watch. 

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: List of long term FTBFS packages to be retired in February​

[Kevin Fenzi]

On Thu, Jan 26, 2023 at 11:07:34PM +0100, Miro Hrončok wrote:
> 
> Unfortunately, as seen by the lenght of the packages listed in my emails,
> thsi is not always the case.

Yeah. ;( 

> Some packagers do set the bugzillas to ASSIGNED to get rid of the reminders
> and then they forget to actually fix the FTBFS, cannot figure out how to fix
> it, are blocked on externalities that never happen, etc.

Yep. Can happen to us all. 

> Oh but they are different. FTBFS are not urgent and the policy is only set
> to retire packages that FTBFS for more than 2 release cycles.
> 
> For a package to be considered for retirement in February 23, it would have
> to fail to build:
> 
>  - During the Fedora 36 mass rebuild in January 22.
>  - During the Fedora 37 mass rebuild in July 22.
>  - During the Fedora 38 mass rebuild in January 23.
> 
> That is not urgent, that is "not being fixed".

Right.

> We can make this even longer, but I don't think it'll make a difference --
> eventually we will just get a list of packages that aren't beign fixed, but
> for a longer time.

Yeah, no... 

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: List of long term FTBFS packages to be retired in February​

[Kevin Fenzi]

On Thu, Jan 26, 2023 at 10:21:27AM +0100, Miro Hrončok wrote:
> On 26. 01. 23 4:51, Yaakov Selkowitz wrote:
> > On Tue, 2023-01-24 at 15:55 +0100, Miro Hrončok wrote:
> > > Based on the current fail to build from source policy, the following
> > > packages
> > > should be retired from Fedora 38 approximately one week before branching.
> > > 
> > > 5 weekly reminders are required, hence the retirement will happen
> > > approximately in 2 weeks, i.e. around 2023-02-08.
> > > Since this is unfortunately after the branching,
> > > packages will be retired on rawhide and f38.
> > > 
> > > Policy:
> > > https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/
> > 
> > Why isn't automatic orphaning at the beginning of this countdown part of 
> > this
> > policy, so that others have the chance to take and fix the package?  If
> > someone (other than the maintainer, who should already be well aware) were 
> > to
> > just now notice that one of these packages were about to be retired, there
> > isn't really enough time to go through the BZ route to get it orphaned 
> > first.
> 
> That is a good question.
> 
> The original idea is that FTBFS packages are orphaned when the maintainers
> don't respond to the FTBFS bugzillas. But many do set the bugzillas to
> ASSIGNED to avoid the orphaning or sometimes the FTBFS bugzillas are closed
> in mistake or not opened at all.

Well, if it's ASSIGNED, you don't want to orphan it, the maintainer is
working on it right?

> I suppose orphaning the packages first would make perfect sense, but the
> devil is in the details. I suppose packagers might feel bad if suddenly
> "their" packages are orphaned without any reminder or warning of some sort.

Yeah, I think that would be quite bad. 

> So we would need to modify the policy from:
> 
> 1. warn
> 2. warn
> 3. warn
> 4. warn
> 5. warn
> 6. retire
> 
> To something like:
> 
> 1. warn
> 2. warn
> 3. warn
> 4. orphan
> 5. warn
> 6. warn
> 7. warn
> 8. retire
> 
> And make the process much longer. And we would need to figure out what to do
> if the package is taken (unorphaned) in between 4. and 8. without being
> fixed.

I suppose FTBFS is less urgent and FTI bugs... perhaps they should be
different in this process?

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: Bootstrapping package with circular dependencies in koji

[Kevin Fenzi]

On Wed, Jan 25, 2023 at 03:45:35PM +0100, Jaroslav Skarvada wrote:
> On Wed, Jan 25, 2023 at 12:13 PM Miro Hrončok  wrote:
> >
> > On 25. 01. 23 11:50, Vít Ondruch wrote:
> > > Reading the thread, I was afraid this will be the end result. 
> > > Nevertheless,
> > > given this would be used just for side-tags, is there a chance to exclude 
> > > side
> > > tags from the policy? Who would handle such request?

I thought we had already done this, but it seems not. 

I am not 100% koji has the needed policy for this, so I'd say file the
issue first as a koji issue and once we can allow/disallow this via
policy we can allow it for sidetags... but see below.

> > > Although being able to modify one macro means also possibility to edit all
> > > macros. Not sure this is desired. However one can achieve almost 
> > > everything by
> > > changing .spec file, so that should not be blocker IMHO.
> >
> Or add an option that will mark/unmark the sidetag for bootstrapping,
> i.e. option that will add only this specific bootstrap macro to the
> sidetag and nothing more.

Yeah, that would be better than allowing all tag options to be set.

> > I think the "commit the bootstrap conditional directly to bootstrap 
> > something"
> > approach is much more transparent than "fiddling with macros in Koji to save
> > myself one tiny commit" anyway.
> >
> It's one commit per package. If you rebuild more packages there may be
> more things that need bootstrapping.

Also: commits to reverse the horrible with/without syntax are error
prone. If we can avoid doing them, we can probibly avoid some mistakes. 

> > To answer the original question, it can be done like this:
> >
> > 1. commit all commits and push them all
> > 2. fedpkg request-side-tag
> > 3. koji chain-build --nowait f38-build-side-6
> > 'git+https://src.fedoraproject.org/rpms/python3.12.git#fe95b37f25338c94bcfa2fb653e53b5262ec2812'
> > : ..instert mid deps here... :
> > 'git+https://src.fedoraproject.org/rpms/python3.12.git#1bc45ffecb2b268fb56fbdc61ceb0ff429168d19'
> >
> If there already are the boostrap conditionals in the specs the logic
> progress is to have some support in the infra. Just manually reverting
> the condition in the spec is, let's say not the optimal solution. Just
> my two cents.

I personally agree. 

I think ideally koji would allow us to allow/deny changing taginfo to
side tags, and even better allow/deny changing just bootstrap=1. 

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 Update] [CRITPATH] [comment] alt-ergo-2.3.3-5.fc38, apron-0.9.13-16.fc38, and 182 more

[Kevin Fenzi]

On Wed, Jan 25, 2023 at 01:12:47PM +, Richard W.M. Jones wrote:
 
...snip...

> Alternately, why does an older build block a push to stable?  Won't
> the old build simply be ignored if there's a higher NVR version
> around?

Nope, koji and pungi have no idea about 'older' or 'newer', they only
know 'latest tagged package' and 'previously tagged package'. 

So, when pungi does a compose it asks koji: "hey, give me the last
tagged package for all packages in f38 tag". 

So, in this case if we did let this through, the 'older' one would be in
the compose. 

kevin


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Bootstrapping package with circular dependencies in koji

[Kevin Fenzi]

On Tue, Jan 24, 2023 at 03:36:41PM -0500, Neal Gompa wrote:
> On Tue, Jan 24, 2023 at 3:00 PM Kevin Fenzi  wrote:
> >
> > On Tue, Jan 24, 2023 at 07:54:29PM +0100, Jaroslav Skarvada wrote:
> > >
> > > I initially thought about:
> > > release bump
> > > $ koji edit-tag SIDETAG -x %_with_bootstrap=1
> > > build
> > > handle circular dep
> > > $ koji edit-tag SIDETAG -r %_with_bootstrap
> > > build
> > >
> > > But I haven't tried it yet because I didn't want to break anything :)
> > > Is this the correct way to do it?
> >
> > That should work, (as long as you bump the release for the second build
> > as koji will not let you rebuild the same n-v-r)
> > but I am not sure anyone has tried it.
> >
> 
> The NVR will automatically change when you flip between modes, since
> it changes the DistTag.

Ah indeed. 

So you should only need 1 initial commit. 

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: Bootstrapping package with circular dependencies in koji

[Kevin Fenzi]

On Tue, Jan 24, 2023 at 07:54:29PM +0100, Jaroslav Skarvada wrote:
> 
> I initially thought about:
> release bump
> $ koji edit-tag SIDETAG -x %_with_bootstrap=1
> build
> handle circular dep
> $ koji edit-tag SIDETAG -r %_with_bootstrap
> build
> 
> But I haven't tried it yet because I didn't want to break anything :)
> Is this the correct way to do it?

That should work, (as long as you bump the release for the second build
as koji will not let you rebuild the same n-v-r)
but I am not sure anyone has tried it. 

The "old" way to do it, is as you assumed, to just modify the spec to
enable the bootstrap path, build and then change back. 

The sidetag way would save you a commit, so that seems better to me, but
up to you. 

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 38 mass rebuild is finished

[Kevin Fenzi]

On Mon, Jan 23, 2023 at 10:26:18PM +, Sérgio Basto wrote:
> 
> I found more 5 with
> https://koji.fedoraproject.org/koji/tasks?owner=releng=active=tree=all=-id
> 
> 96481236   build (f38-rebuild,
> /rpms/yaksa.git:528d57e3c954abfedba6f530f5ac09abaa9170fa)
> 
> 96474133   build (f38-rebuild, /rpms/trace-
> cmd.git:d9631ac81ad4f30b7ca5ed8a7d3b57131c545080)
> 
> 96404064   build (f38-rebuild, /rpms/perl-
> SDL.git:347cf3fb5ac90e14b96381722bc335744077e967)
> 
> 96383273   build (f38-rebuild,
> /rpms/octave.git:93e5fb4a813805c66ec7107da26be2d52039106d
> 
> 96368979   build (f38-rebuild,
> /rpms/libtracecmd.git:121d11cfd26c3a0d61671b83f32b0be1ec75f1ff)

Yes, I have canceled all those now. 

kevin


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Fedora 38 mass rebuild is finished

[Kevin Fenzi]

On Mon, Jan 23, 2023 at 08:11:03PM -0500, Rafael Aquini wrote:
> FYI:
> 
> memkind failure (aarch64) seems to be koji/mock related:
> 
> This package was updated and sucessfully built in rawhide and f37 a week
> ago (01/13)
> 
> ---8<---
> 
> EXCEPTION: [Error('Command failed: \n # /usr/bin/systemd-nspawn -q -M
> b67a9ff69f3540e9bb559e45f9dafdf5 -D
> /var/lib/mock/f38-build-40444675-4981555/root -a -u mockbuild
> --capability=cap_ipc_lock
> --bind=/tmp/mock-resolv._3nfqeom:/etc/resolv.conf
> --bind=/dev/btrfs-control --bind=/dev/mapper/control
> --bind=/dev/loop-control --bind=/dev/loop0 --bind=/dev/loop1
> --bind=/dev/loop2 --bind=/dev/loop3 --bind=/dev/loop4
> --bind=/dev/loop5 --bind=/dev/loop6 --bind=/dev/loop7
> --bind=/dev/loop8 --bind=/dev/loop9 --bind=/dev/loop10
> --bind=/dev/loop11 --console=pipe --setenv=TERM=vt100
> --setenv=SHELL=/bin/bash --setenv=HOME=/builddir
> --setenv=HOSTNAME=mock --setenv=PATH=/usr/bin:/bin:/usr/sbin:/sbin
> --setenv=PROMPT_COMMAND=printf "\\033]0;\\007"
> --setenv=PS1= \\s-\\v\\$  --setenv=LANG=C.UTF-8
> --resolv-conf=off bash --login -c /usr/bin/rpmbuild -bb --noclean
> --target aarch64 --nodeps /builddir/build/SPECS/memkind.spec\n', 1)]
> Traceback (most recent call last):
>   File "/usr/lib/python3.11/site-packages/mockbuild/trace_decorator.py",
> line 93, in trace
> result = func(*args, **kw)
> 
> --->8---

Very odd failure. :( 

It looks like it finished linking and then somehow systemd-nspawn
crashed, but I don't see in the logs any reason why. :( 

I'd say try a scratch build and if that works, just resubmit 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

Re: Fedora 38 mass rebuild is finished

[Kevin Fenzi]

On Mon, Jan 23, 2023 at 01:36:10PM -0600, Jonathan Wright via devel wrote:
> I'm seeing the same errors on rawhide buildroot right now.

The problem was libunistring-1.1-3.fc38 (again). 

We untagged it in december, but looks like no one followed up to get
dependent packages rebuilt: 

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

I have untagged it (again) for now. 

kevin


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Fedora 38 mass rebuild is finished

[Kevin Fenzi]

On Mon, Jan 23, 2023 at 10:30:05AM -0700, Jerry James wrote:
> 
> Can somebody cancel the bigloo build?  It's been running for several
> days and is obviously off in the weeds.  I'll investigate.

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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Rawhide updates stuck for the past ~4 hours?

[Kevin Fenzi]

On Sat, Jan 21, 2023 at 03:25:48PM +, Sérgio Basto wrote:
> On Fri, 2023-01-20 at 15:54 -0600, Michel Alexandre Salim wrote:
> > On Fri, 2023-01-20 at 22:44 +0100, Miro Hrončok wrote:
> > > My Rawhide Bodhi updates are stuck in pending, so I've checked
> > > 
> > > https://bodhi.fedoraproject.org/updates/?releases=F38
> > > 
> > > and it seems that everything created after 2023-01-20 17:35 UTC is
> > > stuck.
> > > 
> > > Is this a natural slowdown due to the mass rebuild or is something
> > > broken?
> > > 
> > Per nirik on #releng, looks like robosignatory is backlogged on
> > signing
> > packages.

Yep. There's 2 things ongoing that should hopefully improve this next
time:
1. There's a plan to add some priority levels to robosignatory. That way
we can tell it the mass rebuild signing is a lower priority. Hopefully
we will get some cycles to work on the code for this soon. 

2. There is work to rework how sigul signs things. Right now it copies
around entire rpms, but it really only needs the hash. This should make
it a lot faster to sign things. 

I hope both those will be in place for the next mass rebuild. 

> mass rebuild finished today at 2023-01-21 08:33:18
> tha build was done  at sidetag f38-rebuild 
> 
> - when it is merged ? 

Probibly monday. It's not "done" yet... there's still some larger
packages building like libreoffice and webkitgtk. 

> - The packages that failed to build , can I build it in f38-rebuild
> sidetag ? 

Please just rebuild it as normal in f38 as you normally would. 

When the f38-rebuild tag is merged, anything that has a newer build in
f38 tag will just not be merged. 

So, as always: just rebuild like you normally would.
 
> - Again we have a problem of race condition with sidetags , for example
> the first build after mass rebuild finished, gnome-boxes-43.2-3.fc38
> will be override by gnome-boxes-43.2-2.fc38 on side tag . i.e. if build
> was successful in a sidetag, koji should denied the build for f38 tag
> (the tag that side-tag is target).

no. When we merge the f38-rebuild tag, the script will see there is a
newer build there in f38 and simply not tag the older one in f38-rebuild
in. It will work fine. ;) 

> - BTW , in the same way, when mass branch starts , koji should not
> accept builds for rawhide until rawhide is fully branched and PDC
> indicates that rawhide now is tag f39 . 

Thats... not how things work.

We are NOT branching f38 from rawhide right now. The mass rebuild is
DELIBERATELY a while before that. This allows maintainers to fix issues
and only have to do one build. By the time we branch a lot of these
failures will be fixed and then both rawhide (going on to f39) and f38
will have the fix, instead of branching now and having to fix things in
2 places and do 2 builds, etc. 

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: When to close CVE's

[Kevin Fenzi]

On Fri, Jan 20, 2023 at 04:47:05PM +, Gary Buhrmaster wrote:
> On Fri, Jan 20, 2023 at 3:48 PM Richard Shaw  wrote:
> 
> > I think in practical terms that makes sense but our tools don't really help.
> 
> I agree, and that seems to be an artifact of
> the single Fedora component in RHBZ, which
> treats Fedora as one thing.
> 
> I supposed (in theory again) that there could
> be a master bugzilla for the CVE which depends
> on child bugzillas for each impacted Fedora
> release, and would get (auto) closed only when
> all the child bugzillas are resolved (either by
> updates or the Fedora release aging out).
> 
> Alternatively, an entirely different bugzilla for
> each Fedora release (but as Fedora is just
> a single component, unlike each RHEL
> which has different components for each
> version, I don't think that works).

I think that sort of thing indeed reflects reality better, but at the
cost of much more complexity. Maintainers already dislike the amount of
bugs to deal with, having tons more doesn't sound too appealing... at
least to me.

> > So I guess what I'm asking is if there is a specific policy around this? If 
> > not, should there be?
> 
> I think there should be at least an agreed
> upon best practice, which needs to be
> explicitly documented somewhere (maybe
> it is, but I don't recall seeing it, so I am
> not following it).

I'm not sure we can have any specific policy.

CVE's are all over the map. Sure we have priorities and 'scores' but
even then, they often are not quite right or don't apply the same way to
the way Fedora has packaged the software. 

I think we can perhaps have a 'rule of thumb'/SHOULD type of advice: 
* If it's high or critical, do consider updating stable releases if you
  can.
* If you decide not to update stable releases, please add a comment to
  the bug noting that and close it.

> So, as with much of Fedora, we fall back
> to depending on (usually volunteer)
> packagers to do the right thing (which works
> out well most of the time because packagers
> such as yourself are contentious about
> doing the right thing).

yeah, I think this is just too complex an area for us to have a detailed
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: Improving Fedora boot time when libvirt is installed

[Kevin Fenzi]

On Thu, Jan 19, 2023 at 11:32:24AM -0800, Gordon Messmer wrote:
> On 2023-01-19 09:48, Daniel P. Berrangé wrote:
> > The idea is that an application will put a dep on the
> > specific libvirt-daemon-driver-XXX that its functionality
> > requires. If Boxes requires storage APIs, then add a
> > Requires: libvirt-daemon-driver-storage-core, along with
> > any of the storage backends Boxes uses.
> 
> 
> It looks like there are currently ~ 13 packages that currently require
> libvirt or libvirt-daemon-kvm that would need review and possibly
> adjustment, and I'm willing to do that work, but I have to ask:  How likely
> is it that "fedora-comps" would accept a PR that narrows the libvirt package
> set in the "virtualization" and "virtualization-headless" groups?

I think that would be an acceptable PR personally. 

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: Automation of Fedora SCM requests

[Kevin Fenzi]

On Wed, Jan 18, 2023 at 12:36:35PM -0600, Michel Alexandre Salim wrote:
> Hi Michal,
> 
> On Wed, 2023-01-11 at 17:13 +0100, Michal Konecny wrote:
> >  Hi everyone,
> >  
> >  all the remaining issues were solved and the bot is now processing
> > tickets as it should. I will watch the SCM request repository for
> > next few days to see if everything is working as it should.
> >  Thanks for your patience.
> >  
> Where can I direct feature requests? Per
> https://pagure.io/releng/fedora-scm-requests/issue/50507 seems like
> requesting repos with exceptions (e.g. for Rust compat packages) is
> currently not automated.

I'm not sure how we can automate this. 

I mean I guess we could just check that the requestor is a packager and
let them create any package name they wish? Or is there some programic
way we can tell it's a compat package and that its correctly named?

Perhaps we could extend fedpkg to ask for and provide more info to the
processing ticket? like name of orig package (check that it exists, etc)
and that the new compat package has a name thats based on it?

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

bodhi upgraded to 7.0.1

[Kevin Fenzi]

Hey folks, just a heads up that bodhi has been updated to 7.0.1 now. 

https://bodhi.fedoraproject.org

See: 
https://github.com/fedora-infra/bodhi/releases
for a full list of bugs fixed/enhancements. 

Note that this adds the concept of 'frozen' releases, which will: 
* show a warning / note for those releases to explain that it's frozen
  and updates will stay in testing unless cleared by QA as fixing a
  blocker/exception.
* allow releng to use the same automated push process, meaning that
  updates pushes will stay at the same time (00:14UTC) as always.

Along with many other bugfixes and enhancements.

Thanks to everyone who worked on it!

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, report it: 
https://pagure.io/fedora-infrastructure/new_issue
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

bodhi upgraded to 7.0.1

[Kevin Fenzi]

Hey folks, just a heads up that bodhi has been updated to 7.0.1 now. 

https://bodhi.fedoraproject.org

See: 
https://github.com/fedora-infra/bodhi/releases
for a full list of bugs fixed/enhancements. 

Note that this adds the concept of 'frozen' releases, which will: 
* show a warning / note for those releases to explain that it's frozen
  and updates will stay in testing unless cleared by QA as fixing a
  blocker/exception.
* allow releng to use the same automated push process, meaning that
  updates pushes will stay at the same time (00:14UTC) as always.

Along with many other bugfixes and enhancements.

Thanks to everyone who worked on it!

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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: HyperKitty: Thread tree broken?

[Kevin Fenzi]

On Thu, Jan 12, 2023 at 07:14:33PM +0100, Jun Aruga (he / him) wrote:
> > > > 1.
> > > > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/Z2RR2OE5TAQH5CVJ5VB5T3R7OM5ULYPQ/#QZUTH6DSULKYBMGPPYNZMPX7YSYKOBTT
> > > > 2.
> > > > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/2JLCYG4HBG2WP2MB4EZY5ODWXZCD4PDL/#2JLCYG4HBG2WP2MB4EZY5ODWXZCD4PDL
> > > >
> > > > It seems that the Message-ID header's value of the almost last email:
> > > >
> > > > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/QZ5WZ33D2NZXR4O447WD3ELV2BTC5VJY/
> > > > is referred to by the following email by the References header's value.
> >
> > This is likely because someone requested we delete their post in the
> > archives because they used the wrong address, and I forgot to reattach
> > the thread after deleting it.
> >
> > I just tried to reattach it, does it look better now?
> 
> Yeah, now thread 1 is nicely combined with thread 2. Thanks!
> I shared the thread link to let people know about it on the Fedora
> Discussion forum and another forum outside Fedora. Then I noticed this
> issue.

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

Re: HyperKitty: Thread tree broken?

[Kevin Fenzi]

On Thu, Jan 12, 2023 at 11:41:20AM -0500, Stephen Smoogen wrote:
> On Thu, 12 Jan 2023 at 11:34, Jun Aruga (he / him) 
> wrote:
> 
> > I see one issue on HyperKitty on the Fedora project.
> >
> > Below is thread 1 and 2 for the actual thread: "RISC-V -- are we ready
> > for more, and what do we need to do it?" Do you know why it's not one
> > thread page?
> >
> > 1.
> > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/Z2RR2OE5TAQH5CVJ5VB5T3R7OM5ULYPQ/#QZUTH6DSULKYBMGPPYNZMPX7YSYKOBTT
> > 2.
> > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/2JLCYG4HBG2WP2MB4EZY5ODWXZCD4PDL/#2JLCYG4HBG2WP2MB4EZY5ODWXZCD4PDL
> >
> > It seems that the Message-ID header's value of the almost last email:
> >
> > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/QZ5WZ33D2NZXR4O447WD3ELV2BTC5VJY/
> > is referred to by the following email by the References header's value.

This is likely because someone requested we delete their post in the
archives because they used the wrong address, and I forgot to reattach
the thread after deleting it. 

I just tried to reattach it, does it look better now?

kevin


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F38 proposal: Shorter Shutdown Timer (System-Wide Change proposal)

[Kevin Fenzi]

On Wed, Jan 11, 2023 at 04:35:33PM +, Zbigniew Jędrzejewski-Szmek wrote:
> 
> We have thousands of systemd services in Fedora. To "just add timeouts
> to things that take too long" would mean updating them individually.
> (Or maybe only some, but we don't really know which ones.)

Sure, although you can get user reports of them. 

> This is never going to happen, it's just too much work, and there is
> no clear clear understanding if it is "safe" for any specific service.

Well, I would hope package maintainers would be able to know/figure this
out on their packages? I realize there's a lot of variables there, but
if a service is ok with the current timeout, but not ok with the new
proposed timeout the maintainer should be able to figure out why and fix
it, or add a timeout back to the old one?

> Instead, the idea is to attack the problem from the other end: reduce
> the timeout for everyone. Once this happens, we should start getting
> feedback about what services where this doesn't work. Some services
> legitimately need a long timeout (databases, etc), and for those the
> maintainers would usually have a good idea and can extend the timeout
> easily. Some services are just buggy, and with the additional visibility
> and tracebacks, it should be much easier to diagnose why they are slow.
> 
> Approaching the problem from this side is much more feasible. We'll
> probably have to touch a dozen files instead of thousands.

Well, yes, for you, but it's not so great for the user with the dead
modem or broken databases. :(

But I guess in the end a service that is ok with 120 seconds, but not ok
with 15 seconds would hopefully be quite rare. 

I do appreciate the change to do an abort on these units. Will that get
reported via abrt?

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: Schedule for Tuesday's FESCo Meeting (2023-01-03)

[Kevin Fenzi]

On Tue, Jan 10, 2023 at 09:15:41PM -0500, Siddhesh Poyarekar wrote:
...snip...
> 
> Finally, another voting member commented, this time on the re-vote
> ticket[1], again indicating that the reason for the revote is the
> misdirection in the _FORTIFY_SOURCE proposal discussion.

Just to set the record straight here: I made that comment, and I was
wondering/suggesting (or as I note in the comment "guessing") as to why
the revote was taking place. I was not involved in the revote and
indeed I was trying to say "if this is because of the _FORTIFY_SOURCE proposal,
there's a lot of difference between them and I can't see why it would change 
things."

Indeed it didn't change anything for me, as I kept my -1 vote. 

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: Shorter Shutdown Timer (System-Wide Change proposal)

[Kevin Fenzi]

On Tue, Jan 10, 2023 at 06:00:59PM -0600, Michael Catanzaro wrote:
> On Tue, Jan 10 2023 at 03:19:10 PM -0800, Kevin Fenzi 
> wrote:
> > Is there something wrong with that approach that I am not understanding?
> 
> No, I don't think you're missing anything. That should work fine for
> PackageKit. But of course it won't do a thing to help with for other
> services that are misbehaving! The goal here is to make the operating system
> generally more robust.

Ok, but it seems safer to just add timeouts to things that take too long
and can safely be killed off rather than lowering the timeout for
everything and potentially kill things that cannot safely be killed. 

I realize it's a lot more work to try and fix particular slow things.

It's hard to know what really needs more time and what just should be
killed off sooner. :(

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: Shorter Shutdown Timer (System-Wide Change proposal)

[Kevin Fenzi]

On Mon, Jan 09, 2023 at 08:45:43PM +, Zbigniew Jędrzejewski-Szmek wrote:
> 
> The current default is mostly arbitrary. It was just selected as a nice round
> value, in the spirit of "let's pick something large enough to be larger than 
> any
> realistic process will ever need".
> 
> I think you're misinterpreting Michael's words that "it's safe enough to 
> ignore this problem".
> IIUC, the idea is to set a longer timeout in those cases at the service level.
> I.e. the problem is "ignored" only in the sense of the system-wide default 
> being
> smaller, and the specific services setting a higher timeout as required.
> 
> Also, even with the current high defaults, some services still actually time 
> out.
> If something bad happens in that case, it is already happening. This is bad
> for users in at least two ways. First, because they have to wait and wait, and
> second because the timeout is actually hit so things *do* get terminated but 
> when
> this happens, we do nothing. The idea would be to lower the default timeouts,
> but also approach any cases where we hit the timeout much more seriously.

I'm a bit confused why we can't just fix the units that are taking too
long instead of changing the global value. The change page mentions that
"it's not possible to fix every misbehaving service: in some cases the
misbehaviour comes from design flaws that are difficult to resolve." but
can't we just change their timeout? ie, add to packagekitd's service
file: 
TimeoutStopSec=30s
(or 15 or whatever)?

Is there something wrong with that approach that I am not understanding?

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: TeXLive 2022 landing in rawhide today

[Kevin Fenzi]

On Sat, Jan 07, 2023 at 09:11:32AM -0700, Orion Poplawski wrote:
> 
> Seems to be breaking LaTeXML's tests:
> https://apps.fedoraproject.org/koschei/package/LaTeXML?collection=f38
> 
> Unfortunately koschei's query to see what else might be affected hits a
> gateway timeout:
> 
> https://koschei.fedoraproject.org/affected-by/texlive-latex?epoch1=9=20210325=52.fc38=10=svn63825=55.fc38=f38
> 
> Would be nice if that could be given more time to complete.

Looks like it takes about 45s for that to load. 
I increased the timeout to 180s. :) 

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: Rpmautospec by Default (System-Wide Change proposal)

[Kevin Fenzi]

On Sat, Dec 31, 2022 at 03:37:34PM -0500, Stephen Smoogen wrote:
> On Sat, 31 Dec 2022 at 13:40, Kevin Kofler via devel <
> > https://docs.pagure.org/fedora-infra.rpmautospec/autochangelog.html#changelog-entries-generated-from-commit-messages
> >
> > All in all a very complicated and error-prone process just to save some
> > extremely lazy packagers a 5-second copy I really do not see why
> > that
> > should be the default and recommended process.
> >
> > The rules how to format the commit message are error-prone, and if you get
> > them wrong, you usually only notice when it is too late to fix it (because
> > force-pushes are not allowed). Yes, you can manually run "rpmautospec
> > generate-changelog", but that is actually no less effort than just taking
> > care of the changelog manually to begin with.
> >
> 
> My main questions are what is this supposed to fix long term?

My understanding is that the main thing rpmautospec is supposed to
address is to decouple changelog and release values from specific
changes. This for example makes pull requests much easier. 

Without it, pull requests either have to specifically tie a change to a
release/changelog entry or leave that to the maintainer. 
With it, PR's can be applied in any order or after some other unrelated
changes without a bunch of back and forth to adjust the
release/changelog to match unrelated changes. 

I think moving more things to it makes a lot of sense as long as we are
moving to a more pull request flow. I can't speak for others, but I have
indeed noticed a increase in PR's on packages I maintain over the last
few years.

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: Scripts to rebuild dependencies in copr

[Kevin Fenzi]

On Wed, Dec 21, 2022 at 09:15:10PM -0700, Orion Poplawski wrote:
> I've been using an old review_pr.py script produced by the Fedora
> Stewardship SIG to rebuild the depedencies of a package in COPR to test
> changes/updates to packages.  It's been incredibly useful.  However, it
> seems that the github repo has disappeared.
> 
> Is there anything else out there in use that is actively maintained?

There's the mass pre build project that was recently announced here:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/IT347SLVZ6QYNCMYRR3MNB25SJ7W5R3P/

I've not tried it yet, but it's on my list to look at.

It looks like it mostly does everything the review_pr.py script did,
except you have to give it a src.rpm instead of just the pr. 
(possibly that could be a RFE on mass prebuild?)

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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Orphaned packages looking for new maintainers

[Kevin Fenzi]

On Mon, Dec 19, 2022 at 05:47:52PM +, Barry Scott wrote:
> 
> 
> > On 19 Dec 2022, at 17:40, Ben Cotton  wrote:
> > 
> > On Mon, Dec 19, 2022 at 12:36 PM Barry  wrote:
> >> 
> >> Why is pysvn on the list? I the pysvn maintainer and i am active.
> >> I am also the upstream maintainer.
> > 
> > The "main admin" is orphan. You should be able to go to
> > https://src.fedoraproject.org/rpms/pysvn and click the "Take" button
> > on the left-hand side. (This is an unfortunate side-effect of how
> > dist-git works).
> 
> Taken and I'm the bugzilla contact as well.
> 
> Does "main admin" being "orphan" go away when background processes catch up 
> with the changes I just made?

Yes. The existing bugs should be reassigned from orphan to you after a
while. 

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: Some reasons I really dislike buildroot overrides and would like us to get rid of them soon

[Kevin Fenzi]

On Sat, Dec 03, 2022 at 12:04:18PM +0100, Vitaly Zaitsev via devel wrote:
> On 02/12/2022 22:30, Adam Williamson wrote:
> > 1. Packages that have been pushed stable since the last time a compose
> > succeeded (for Rawhide that's a Rawhide compose, for Branched it's a
> > Branched compose, for stable releases it's an updates compose)
> > 2. Packages that have active buildroot overrides
> 
> I use buildroot overrides because generating side tags for stable releases
> of Fedora is a very slow process.
> 
> Two days ago I created F36, F37 and F38 side tags. F38 side tag was ready in
> 10 minutes, and F36+F37 wasn't generated even after 6 hours. That's why I
> created a new buildroot override and built everything directly.
> 
> Before disabling buildroot overrides this issue must be fixed. Waiting for
> 6+ hours is unacceptable.

I don't think thats at all normal. We had mass updates/reboots and there
was an issue with some ppc64le vm's not having the needed nfs mounts,
causing them to fail newrepo tasks. This would have been the timeframe
for that issue. 

Can you try again now and see if the stable release sidetags are not
ready in ~10min? 

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: Need help with disappeared update from repository

[Kevin Fenzi]

On Thu, Dec 01, 2022 at 04:51:18PM +, Sérgio Basto wrote:
> On Thu, 2022-12-01 at 13:21 +0800, yanq...@fedoraproject.org wrote:
> > Hi all,
> > 
> > It seems update fcitx5-qt-5.0.16-2.fc37 from [1] somehow did not make
> > it to stable repository while other package in same update did. This
> > caused broken dependences during update [2].
> > 
> > Seems that bodhi is doing something weird. I might have an idea how
> > this happened.]: I decided to update fcitx5-qt to 5.0.16 and created
> > a
> > update [3] containing fcitx5-qt-5.0.16-1.fc37, during [3] waiting to
> > make it to stable, qt6 rebuild happens and created another update
> > with
> > fcitx5-qt-5.0.16-2.fc37 [1]. [1] gets a lot karma and pushed to
> > stable
> > soon. And when [3] gets pushed afterwards, somehow fcitx5-qt-5.0.16-
> > 1.fc37 overrides fcitx5-qt-5.0.16-2.fc37. 
> > 
> 
> IMO , when fcitx5-qt-5.0.16-2.fc37  went to bodhi should have obsoleted
> fcitx5-qt-5.0.16-1.fc37 .

It couldn't, because that update was in an update with other packages. 
In that case, bodhi isn't sure what to do with those other packages. 

I'm proposed in this case to just reject the new update and force the
maintainer(s) to sort this out. By removing the 'older' update or
editing the other packages into a newer update or something. 

> But if fcitx5-qt-5.0.16-1.fc37 was already marked got to stable , was
> not obsoleted , and a race condition might happened .

It wasn't stable, but bodhi won't obsolete a update with multiple builds
in it. ;( 

> In resume I think is a bug 
> 
> > I don't know if this behavior should be considered as a bug, but
> > anyway, it seems that manual override from releng is needed to fix
> > the
> > broken dependencies.

Yep. I've retagged the -2 one in and it should be fixed in the next
compose.

kevin


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Planned Outage - Updates / Reboots - 2022-11-30 21:00 UTC

[Kevin Fenzi]

There will be an outage starting at 2022-11-30 21:00 UTC
which will last approximately 5 hours.

To convert UTC to your local time, take a look at
http://fedoraproject.org/wiki/Infrastructure/UTCHowto
or run:

date -d '2022-11-30 21:00UTC'

Reason for outage:

We will be applying updates and rebooting servers. This will update some 
servers to RHEL8.7, some to 9.1 and we will be updating others to Fedora 37.

Affected Services:

A large number of services may be affected for short times in the outage 
window. Critical services (websites, mirrorlists) will be up the entire time.

Ticket Link:

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

Please join #fedora-admin or #fedora-noc on irc.libera.chat
or add comments to the ticket for this outage above.


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, report it: 
https://pagure.io/fedora-infrastructure/new_issue
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Planned Outage - Updates / Reboots - 2022-11-30 21:00 UTC

[Kevin Fenzi]

There will be an outage starting at 2022-11-30 21:00 UTC
which will last approximately 5 hours.

To convert UTC to your local time, take a look at
http://fedoraproject.org/wiki/Infrastructure/UTCHowto
or run:

date -d '2022-11-30 21:00UTC'

Reason for outage:

We will be applying updates and rebooting servers. This will update some 
servers to RHEL8.7, some to 9.1 and we will be updating others to Fedora 37.

Affected Services:

A large number of services may be affected for short times in the outage 
window. Critical services (websites, mirrorlists) will be up the entire time.

Ticket Link:

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

Please join #fedora-admin or #fedora-noc on irc.libera.chat
or add comments to the ticket for this outage above.


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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Direct to stable updates

[Kevin Fenzi]

On Sat, Nov 26, 2022 at 05:27:30PM -, Mattia Verga via devel wrote:
> @kevin I've announced on Bodhi matrix channel that I was planning to draft 
> the new release, but since I received no response I've pushed out Bodhi 7.0.0.
> 
> I have followed the SOP at [1] and bodhi-* RPMs are now available in both 
> f37-infra-stg and f36-infra-stg. Tests run smoothly in F37, so I think it's 
> ok to move bodhi-backend on it.
> 
> Can you take care of running the playbooks on staging so that we can start 
> testing the new version?

Yep. I will do so sometime in the coming week.

Will have more of an idea when tomorrow.

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: Should the policy documents better reflect real package maintenance practice?

[Kevin Fenzi]

On Fri, Nov 25, 2022 at 12:20:10AM +, Gary Buhrmaster wrote:
> On Thu, Nov 24, 2022 at 1:40 PM Miroslav Suchý  wrote:
> 
> > I have to make confession. I am breaking this guidelines too. With 
> > releasing of new version of Mock and fedora-license-data. The problem for 
> > me is that the list of these exception is not available and not maintained. 
> > I inherited Mock from Clark and later gave it to Pavel and I am now merely 
> > co-maintainer. So I really do not know if Mock has had the exception. And 
> > because no one enforce it I even did not apply for the exception for 
> > fedora-license-data and I use common sense, becase it does not have sense 
> > to have old data in stable branches.
> 
> Unfortunately, this discussion runs into a multidimensional
> matrix of considerations, and different people may make
> different choices at each checkbox.

...snip...

Absoletely. There's a ton of variables that go into the decision, but I
think it's important for there to be some general guidance to err on the
side of not changing the user experence in stable releases if you can.

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: Should the policy documents better reflect real package maintenance practice?

[Kevin Fenzi]

On Thu, Nov 24, 2022 at 01:42:20PM -0800, Adam Williamson wrote:
> 
> Thinking it over some more - I think Gordon's right that I hadn't
> considered all the language - I think my personal opinion would be that
> the policy should be adjusted to be less opinionated on this idea of
> "introducing features", and concentrate more on "unexpected changes to
> the user experience". There are a lot of cases where introducing
> features is entirely benign, after all. If a CLI tool I use grows a
> useful extra option while still supporting all the ones it had before
> and behaving in the same way when using those, that just does not seem
> like something to be concerned about. I'd happily send such an update
> to stable.
> 
> If the update *removes* some existing argument, or changes the
> behaviour of one, that's much more significant.
> 
> This is really kinda the rule about API/ABI changes, only for
> applications, in a way. Adding new functions to a library doesn't
> change the API, only removing or changing the behaviour of existing
> ones.

I agree. I think this is something we have in the past for gui things
called 'changes in the user experence'. But yeah, we could clarify this
better. 

FWIW I think some cases were grandfathered in when the policy was first
aadopted. firefox and kde for sure. I know I requested a exception for
calibre. 

The policy is also a bit unclear (or just wrong as written) saying
exceptions need to file for every update or can be just 'you have an
exception for this package/collection of packages unless something
changes'. 

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: spin-kickstarts package

[Kevin Fenzi]

On Wed, Nov 23, 2022 at 09:33:48PM -0500, Neal Gompa wrote:
> 
> Is there a reason we couldn't just automatically update the package
> once we're in freeze so that it has what we're shipping? By the time
> we're down to the wire for final freeze, we're not changing the
> kickstarts that often.

Thats what we used to do, but it has a bunch of process overhead. 

Someone has to file a blocker bug on it, it gets voted on and approved,
then the package update has to be made, submitted, karma and request to
go stable. 

A few times in the past we _have_ made kickstart changes during rc's,
then it means we have to update the package and do all the overhead
again. 

I'm just not sure what utility the package has, wouldn't everyone just
get it from git and make sure they have the latest? 

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: Orphaned a lot of (mostly) Go packages owned by @fpokorny

[Kevin Fenzi]

On Wed, Nov 23, 2022 at 05:44:01PM +, Daniel P. Berrangé wrote:
> 
> The mitigation/successor strategy is to have comaintainers for every
> package.
> 
> Unfortunately our tools enforce the notion of a "main admin" and
> if that person leaves that role has to be given to another
> comaintainer explicitly.

Thats due to bugzilla really. bugzilla only supports assigning a bug to
1 account. ;( 

> IMHO we would be better off eliminating the notion of 'main admin'
> entirely and have all co-maintainers be at the equal level, so there
> is no need for a dance to give packages to comaintainers. There
> should only be manual action needed if the last comaintainer quits.

+100

> A workaround for the 'main admin' problem is to have a robot account
> as the 'main admin' and all the real people as merely 'admin', so
> the main admin never leaves, but that's a bit tedious to setup.

I agree, but it would be a good deal of work to switch to.

I'd definitely like to do this when/if we move away from 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

spin-kickstarts package

[Kevin Fenzi]

Greetings everyone. 

So, we used to have a release requirement that we package up and release
along side the release a spin-kickstarts rpm package with the current
kickstarts used for that release. 

This resulted in a bunch of last minute scrambling and blockers, and
even then, we often pushed fixes after release and people would get the
out of date one in the package and get confused. 

So, we changed that requirement, but then since there was no
requirement, we haven't really been updating the rpm much. 
(see https://bugzilla.redhat.com/show_bug.cgi?id=2144207 )

I'd like to just retire the rpm package and point folks to the git repo.
I think this will get people up to date versions of things,
and avoid pointlessly updating a package. 

Anyone have any arguments to save the rpm version?
Or shall I just retire it/update docs?

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: Direct to stable updates

[Kevin Fenzi]

On Fri, Nov 18, 2022 at 08:10:56AM +, Mattia Verga via devel wrote:
> Il 17/11/22 18:10, Adam Williamson ha scritto:
> > On Wed, 2022-11-16 at 17:37 +, Mattia Verga via devel wrote:
> >> Kevin, the PR for Bodhi is nearly finished, it will add support for
> >> using the 'frozen' release state to avoid pausing the push cron job and
> >> avoid direct pending to stable push of updates when the release is frozen.
> >>
> >> I'll open a ticket to releng for changing the usual workflow of new
> >> releases once the PR gets merged and a new Bodhi release is drafted and
> >> pushed to prod. About the avoidance of direct to stable pushing, do you
> >> think it needs to be discussed by FESCo?
> > Hey Mattia! Can you keep me in the loop on the new version and
> > deployment also? The final phase of my work on critical path status by
> > group is waiting on that. Thanks!
> 
> Hello Adam,
> 
> as soon as the last batch of PRs I submitted are merged, I plan to ask
> @abompard (or whoever is taking care of Bodhi now) to draft and deploy
> the new version.

I can help with the deployment. :) 

It might also be nice to move bodhi-backend01 to f37.

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: koji down?

[Kevin Fenzi]

On Wed, Nov 16, 2022 at 11:37:43AM -0600, Richard Shaw wrote:
> On Wed, Nov 16, 2022 at 11:32 AM Kevin Fenzi  wrote:
> 
> > Everything should be back up now...
> >
> > I'm watching it for a bit before I declare things are back fully to
> > normal though. ;)
> >
> > Do note that mailing list threads aren't a great place to report
> > outages. Please report them to the infrastructure ticket tracker:
> > https://pagure.io/fedora-infrastructure/
> 
> 
> I recently switched internet providers so I was looking for an ACK that it
> wasn't just me.
> 
> But on a related note, it can be somewhat difficult to remember all the
> different sites and which is appropriate for what when you don't deal with
> them on a regular basis..

Yeah. 

I'm not sure how to make things more visible, but really the best link
to know is the one you get to via docs.fedoraproject.org, engineering
teams, fedora infra, working with fedora infra. ie,
https://docs.fedoraproject.org/en-US/infra/day_to_day_fedora/

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: Direct to stable updates

[Kevin Fenzi]

On Wed, Nov 16, 2022 at 02:09:47PM +0100, Kevin Kofler via devel wrote:
> 
> Kevin Fenzi is currently a member of FESCo (see 
> https://docs.fedoraproject.org/en-US/fesco/) and has been in that role for 
> years. So pushing the blame off to "someone else" is not going to work.

You're welcome to bring anything you like to me. (That goes for
everyone!)

That said, it doesn't mean I have to agree with you or do what you want.

> And I have brought this issue to FESCo (which is where most of the update 
> policies came from, not FPC or the Council) more than once. Usually, it was 
> not even brought to a vote. And whenever there was a vote about the issue, 
> it was always in favor of either the status quo or even stricter rules.

Indeed.
That might be an indicator that not so many people agree with you? 
 
> > They are the ones who over time have listened to packagers, users, and
> > developers about what was expected from the build system
> 
> And that is exactly what I am disputing, that they are listening to what 
> packagers expect. Because it can surely not be the packagers' wish to have 
> some piece of software stubbornly dictate that no, that package can not be 
> pushed to stable now because it reached testing only 6 days, 23 hours, 59 
> minutes and 59.99 seconds ago. (I believe the timestamps in Bodhi have 
> microsecond resolution internally. They used to be displayed that way, at 
> least.)

With my packager hat on, yes, I am completely fine with bodhi telling me
that. 

> Nor can it be in the interest of the Bodhi developers to have to maintain 
> all that complex logic: you pointed out yourself that "what happens is that 
> you will get into about 1/3rd of the way into it and find you have now to 
> add a bunch of new requirements" – surely that is not what the developers 
> expect.

I agree that bodhi is a complex application, but I disagree most
strongly that the solution is to just make it not do all those things
that I find useful and desireable. 

> > and they are the ones who have given general guidance over the last 10+
> > years of bodhi development.
> 
> If by "general guidance" you mean skyrocketing requirements, then I agree. 
> Otherwise, I don't, sorry. See above, you admitted yourself that the 
> requirements keep increasing all the time, forcing a major refactoring.
> 
> These days, even Rawhide (!) gets forced through Bodhi, though with an 
> entirely different workflow (but in turn, that means the Bodhi developers 
> get to maintain 2 completely different workflows with completely different 
> rules). That is something Bodhi was never designed for. And the policy 
> changes that have been made for Rawhide over the years have also changed 
> things for the worse: It used to be that you were able to just do 
> development in Rawhide, without having to bother about broken dependencies 
> (which would just show up in the daily dependency report and get fixed 
> there: I remember provenpackagers, mainly Alex Lancaster and me, mass-
> rebuilding packages to fix broken dependencies; Rawhide composes did NOT 
> fail due to broken dependencies at the time, the deliverables that failed to 
> compose would just be missing that day), upgrade paths (from Rawhide to 
> Rawhide, really no reason to not just let the users use distro-sync there 
> and allow the version to go backwards; upgrade paths make sense only for 
> releases), test failures (Rawhide was expected to be broken, as is normal), 
> etc. Now we just make life harder for everyone, both package maintainers and 
> Bodhi developers, for no reason.

I think the current situation is much better than what we had then. 
Blocking updates that break things is desireable, they will be fixed
sooner and not break everyone else that is trying to integrate their
changes. 

We can of course make things better, but I don't have any desire to go
back to the "good old days". 

Anyhow, I am done, feel free to get the last words in the thread. :) 

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: Direct to stable updates

[Kevin Fenzi]

On Wed, Nov 16, 2022 at 05:37:07PM +, Mattia Verga via devel wrote:
> 
> Kevin, the PR for Bodhi is nearly finished, it will add support for
> using the 'frozen' release state to avoid pausing the push cron job and
> avoid direct pending to stable push of updates when the release is frozen.

Awesome.

> I'll open a ticket to releng for changing the usual workflow of new
> releases once the PR gets merged and a new Bodhi release is drafted and
> pushed to prod. About the avoidance of direct to stable pushing, do you
> think it needs to be discussed by FESCo?

No, I think it's a implementation detail that makes things better for
releng, but has no end visible changes, so no need to run it by FESCo. 

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: koji down?

[Kevin Fenzi]

Everything should be back up now...

I'm watching it for a bit before I declare things are back fully to
normal though. ;) 

Do note that mailing list threads aren't a great place to report
outages. Please report them to the infrastructure ticket tracker: 
https://pagure.io/fedora-infrastructure/

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: Direct to stable updates

[Kevin Fenzi]

On Mon, Nov 14, 2022 at 11:54:32PM +0100, Kevin Kofler via devel wrote:
...snip...

I think we are going to just have to agree to disagree here. 

I think we have had this discussion a number of times now and aren't
going to convince the other. 

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: Pull-request related question.

[Kevin Fenzi]

On Sat, Nov 12, 2022 at 08:29:17PM -, Sergey Mende wrote:
> Hi,
> during development of my own project I hit the bug in `gdb` that is already 
> fixed upstream but not backported to rawhide yet.
> I did a backport and ready to submit a PR. What is the right way to proceed: 
> 
> a) just file a PR;
> b) open a bug in bugzilla, submit a PR;
> c) submit a PR, open a bug in bugzilla noting that PR is in a way?

There's no hard rule or even good convention here, but I would
personally say just a PR and waiting a bit would be best. If there's no
answer after a while, a bug could be filed to attract the maintainers(s)
attention. 

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: Direct to stable updates

[Kevin Fenzi]

For a few years I was keeping track of updates that caused big problems:

https://fedoraproject.org/wiki/Updates_Lessons

The orig "very bad" update was a dbus update that broke everything. 

In any case I have seen our current updates system working and blocking
tons of harmfull updates over the years. I think direct to stable is a
bad idea. 

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: Direct to stable updates

[Kevin Fenzi]

On Thu, Nov 10, 2022 at 05:16:44PM +, Mattia Verga via devel wrote:
> Il 10/11/22 01:58, Kevin Kofler via devel ha scritto:
> > Kevin Kofler via devel wrote:
> >
> >> Mattia Verga via devel wrote:
> >>> with the current workflow, Bodhi doesn't know when a release is freezed.
> >>> There is support for a "Freeze" state, but it was never used.
> >> How do we prevent then that pushes to stable actually move forward? If
> >> rel- eng just hits a different button / runs a different script to push
> >> testing only instead of both testing and stable, that is the "can we push
> >> to stable?" property Bodhi needs to check.
> > PS: The "worst mistake" that can happen then is that if we push only testing
> > to a non-frozen release for whatever reason, the update will be included in
> > that testing push, and then move forward to stable in the next stable push.
> > I do not see this as a real issue.
> >
> I'm working on fixing some bits in Bodhi before proposing to releng the
> use of the 'frozen' release state. That will enable Bodhi to avoid
> pushing updates directly to stable if the release is frozen, as well as
> some small tweaks that were requested and would make life easier for
> releng folks.

Thanks!

To explain a bit to everyone the current workflow: 

* In non freeze times, we have a cron job that pushes "all pending
updates" at 00:14 UTC every day. This is stable and testing for anything
thats pending moving to a new state. 

* In freezes however, we have to disable the cron job and manually: 
- First push branched version updates-testing by itself.
- Then push everything else (minus the branched version). 

This sucks, because it's manual, there's a hour or so wait for
updates-testing to finish before we can do the rest, and you have to
remember to list: 
--releases 
EPEL-9N,EPEL-7,EPEL-8,F36,F36C,EPEL-8M,EPEL-9,EPEL-8N,F35,F35M,F35C,F36M,F35F,F36F

If we could just mark branched frozen and have it not push stable there
(without specific builds, because we do still need to push stable
requests through the freeze) that would be great. We could also actually
note this in updates so people don't get confused why their update
didn't get pushed stable.

> It shouldn't be too hard, it's just that Bodhi code is
> sometimes so contorted that by making a simple change it's easy to break
> something else... moving updates from one state to another and tagging
> builds in the correct way without losing the right track is one of those
> contorted part.

Yeah. ;( 

Thanks again for working 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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F37 proposal: Add -fno-omit-frame-pointer to default compilation flags (System-Wide Change proposal)

[Kevin Fenzi]

On Wed, Nov 09, 2022 at 04:26:23AM +, Naheem Zaffar wrote:
> On Tue, 8 Nov 2022, 19:22 Vitaly Zaitsev via devel, <
> devel@lists.fedoraproject.org> wrote:
> 
> > On 08/11/2022 19:53, Naheem Zaffar wrote:
> > > Has there been any consideration to turn on frame pointers for atleast
> > > dev releases?
> >
> >
> > Fedora has no dev releases. Mass rebuild is a huge pain for maintainers
> > due to FTBFS issues, and doing it multiple times is unacceptable.
> >
> I think I explained the idea poorly.
> 
> Not all builds in rawhide are release builds. You will get for instance the
> whole gnome stack beta releases and rc releases during development.
> 
> This isnt limited to gnome, most software will go into rawhide first to
> stabilise.
> 
> It is almost never intended for these builds to end up in the final
> release  ll, but they are useful and necessary parts of the development
> cycle. Theywill be replaced before general availability, all without a mass
> rebuild.
> 
> It's not a silver bullet solution but atleast it starts things off on a
> path where profiling can be done in a limited manner compared to the other
> proposed alternatives where the tooling doesnt exist and will likely not
> ever be written.

The problem is, there's no one size fits all here.
Different upstreams do wildly different things. 

Some have "stable" releases and "dev" releases before that. (Like gnome)
Some just mix features and bugfixes into a single stream.
Some only seem to have prereleases and take years to actually do a point
release. 

etc. 

So, asking that "dev" releases use different options I think would just
result in a bunch of confusion along with a mix of things with some
using frame pointers and some things not. 

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: Help understanding Fedora CI failure wrt RPM Sequoia

[Kevin Fenzi]

On Thu, Nov 10, 2022 at 11:39:27AM +0200, Panu Matilainen wrote:
> 
> So, overnight somebody updated the koji package in
> https://kojipkgs.fedoraproject.org/repos/rawhide/ to the current unsigned
> rawhide build, which makes the issue go away.

Nothing should have updated the koji package. 

The last change was in october:

Wed Oct 26 14:08:39 2022 koji-1.30.1-2.fc38 tagged into f38 by bodhi [still 
active]

In fact there's no such actual build: 

➜  ~ koji list-history --build koji-1.28.1-1.fc38
2022-11-10 12:39:45,017 [ERROR] koji: GenericError: No such build: 
'koji-1.28.1-1.fc38'

Very odd that ci would use a build that doesn't exist. (I guess it's a
scratch build it made itself?)

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: MobilityPhoshImage (Self-Contained Change proposal)

[Kevin Fenzi]

On Thu, Nov 10, 2022 at 01:35:36AM -, Scott Anecito via devel wrote:
> What is the driver for choosing Phosh over GNOME Shell?

There's no choosing something over something else. This isn't a Fedora
Mobility Edition, but rather a first look at a Phosh based setup. 

Phosh has been around a long while, the remix that the mobility sig
makes currently uses it, and it seems to be making progress all the
time. 

The plasma mobile desktop has also been around a while, but I am not
sure if it's all packaged up yet or how it fits together. The kde sig
has been working on this. If they reach a point where things are
working, they can submit a plasma-mobile change. 

If down the road we think this area should be covered by a edition, then
we would need to closely decide what would meet our users needs.

> Let me first say the amount of work put in by both Purism and the GNOME 
> community into Phosh and other mobile components like libhandy has been 
> critical to Linux mobile space. While mobile friendly GNOME Shell 
> improvements only recently started and is not currently as feature rich as 
> Phosh, the recent focus on it by the GNOME community has lead to some fast 
> and impressive development as seen on the GNOME blog: 
> https://blogs.gnome.org/shell-dev/2022/09/09/gnome-shell-on-mobile-an-update/
> 
> Most of the changes in the blog look to be targeting merging upstream in time 
> for 44's release which I believe would be in Fedora 38. Even then though 
> GNOME Shell wouldn't be at feature parity with Phosh. However, the main 
> argument long term for having a mobile image that uses GNOME Shell over Phosh 
> is more resourcing due to mutual benefits on mobile and desktop with things 
> like the new gesture API referenced in the blog.

gnome-shell's mobility changes look really interesting and I would
encourage folks interested in that to work on a gnome mobility spin?

> If feature set is the driver, I understand, but as a Librem5 owner and 
> someone with all their boxes imaged with Fedora I'd be curious if there would 
> be any plans to eventually switch to GNOME Shell once feature parity happens.

I don't know of any plans right now, but I think it's likely to happen
if things are merged and are in a workable state. :) 

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: MobilityPhoshImage (Self-Contained Change proposal)

[Kevin Fenzi]

On Tue, Nov 08, 2022 at 03:09:46PM -0500, Ben Cotton wrote:
> On Tue, Nov 8, 2022 at 1:34 PM Kevin Fenzi  wrote:
> >
> > Yeah, was going to try and work it out with them (which I have not yet
> > done). Where's the best place to engage with them these days?
> 
> I'd start with either Discussion[1] or chat[2]. There are a couple of
> Pagure repos as well, but the new work is being done in GitLab, so
> depending on where the content ends up, the repo may change.
> 
> [1] https://discussion.fedoraproject.org/c/project/websites/66
> [2] https://chat.fedoraproject.org/#/room/#websites:fedoraproject.org

https://discussion.fedoraproject.org/t/fitting-the-new-f38-mobile-phosh-spin-lab-in-websites/43887

Everyone welcome to follow along/chime in 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: F38 proposal: MobilityPhoshImage (Self-Contained Change proposal)

[Kevin Fenzi]

On Tue, Nov 08, 2022 at 10:21:43AM -0500, Ben Cotton wrote:
> On Tue, Nov 8, 2022 at 10:10 AM Ben Cotton  wrote:
> >
> > Initial images are produced for x86_64 and aarch64 mobile devices
> > using the Phosh desktop.
> 
> Is the plan to add these images to an existing website or a new one?

The new one I would think?

> Or are you going to work that out with the Websites & Apps team? (Note
> that they're targeting F38 for the launch of a reconfigured getfedora,
> so it's good to engage with them early on this.)

Yeah, was going to try and work it out with them (which I have not yet
done). Where's the best place to engage with them these days?

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 SCM requests on the weekend

[Kevin Fenzi]

On Mon, Nov 07, 2022 at 10:21:43AM +0100, Mikel Olasagasti wrote:
> Hi Kevin,
> 
> Hau idatzi du Kevin Fenzi (ke...@scrye.com) erabiltzaileak (2022 uzt.
> 9, lr. (20:11)):
> >
> > 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...
> 
> Any updates on this front? Is there a ticket I can track?

The automation is setup in staging now and we are trying to test more
corner cases on it. Likely we will roll it out to production after f37
release. 

https://pagure.io/releng/issue/9274 is the ticket on this. 
(Although I see it needs updating)

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: Karma for OpenSSL needed

[Kevin Fenzi]

On Thu, Nov 03, 2022 at 12:51:28PM +0100, Vít Ondruch wrote:
> 
> Now who will be motivated enough to at least open the Koji ticket as
> suggested in the other place of this thread? :D
> 
> Actually, for my purposes, it would be much better if there was something
> like `koji download-url --signed openssl`. This would be useful to feed DNF
> directly: `dnf install $(koji download-url --signed openssl)`, because I
> don't like to create some temporary directories.

That could be unexpected if the package is signed by more than one key. 
I guess it would download them all ? But then you have duplicates... 

Not sure the best answer 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: Karma for OpenSSL needed

[Kevin Fenzi]

On Wed, Nov 02, 2022 at 08:15:00PM +0200, Otto Liljalaakso wrote:
> Vít Ondruch kirjoitti 2.11.2022 klo 16.18:
> > 
> > Dne 01. 11. 22 v 18:59 Fabio Valentini napsal(a):
> > > On Tue, Nov 1, 2022 at 6:53 PM Demi Marie Obenour
> > >  wrote:
> > > > 
> > > > Please push them out to testing immediately.  Some, such as
> > > > myself, simply
> > > > refuse to install unsigned packages.
> > > The packages are already signed, no need to wait for them to be pushed
> > > to testing.
> > > 
> > 
> > Just FTR, this is the URL which can be obtained from Koji:
> > 
> > https://kojipkgs.fedoraproject.org//packages/openssl/3.0.5/3.fc37/x86_64/openssl-libs-3.0.5-3.fc37.x86_64.rpm
> > 
> > and this is the signed version:
> > 
> > https://kojipkgs.fedoraproject.org//packages/openssl/3.0.5/3.fc37/data/signed/5323552a/x86_64/openssl-libs-3.0.5-3.fc37.x86_64.rpm
> > 
> > 
> > Not sure if there is any better way to obtain the signed version early.
> 
> Would it be possible to update Koji's web UI so that it offers the signed
> one for download? Is there anything going for the current behavior of
> offering the unsigned one instead?

Which signed one?
Some packages have multiple signed copies at the same time. 

koji also only knows them by their short hash of the key, not
'fedora-37' or something. 

Signed packages are cleaned up after some amount of time if they are not
in a tag requiring keeping them. 

So, I suppose the web interface could offer signed copies if they exist,
but might be confusing if you don't know what the various keys short
hash is. Feel free to file a RFE for koji folks: https://pagure.io/koji

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: Fwd: Your message to devel@lists.fedoraproject.org awaits moderator approval

[Kevin Fenzi]

On Wed, Nov 02, 2022 at 08:02:07AM -0500, Richard Shaw wrote:
> U... Isn't it considered a good practice to CC maintainers of affected
> packages? Should I have done it as BCC instead?

You could do BCC instead, but then if there's some feedback that someone
wants to send to everyone, you would have to resend to everyone. 

Or you can just ignore the moderation message. I pass all these through
moderation anyhow, it's just a slight delay. 

kevin
--
> 
> -- Forwarded message -
> From: 
> Date: Wed, Nov 2, 2022 at 7:59 AM
> Subject: Your message to devel@lists.fedoraproject.org awaits moderator
> approval
> To: 
> 
> 
> Your mail to 'devel@lists.fedoraproject.org' with the subject
> 
> New OpenColorIO 2.2.0 requires yaml-cpp 0.7.0
> 
> Is being held until the list moderator can review it for approval.
> 
> The message is being held because:
> 
> Message has more than 10 recipients
> 
> Either the message will get posted to the list, or you will receive
> notification of the moderator's decision.

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



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: systemd 252 feature: SUPPORT_END in /etc/os-release

[Kevin Fenzi]

On Tue, Nov 01, 2022 at 07:02:33PM -0400, Matthew Miller wrote:
> See:  
> https://lists.freedesktop.org/archives/systemd-devel/2022-October/048519.html
> 
>Systemd will set the taint flag 'support-ended' if it detects that
>the OS image is past its end-of-support date. This date is declared
>in a new /etc/os-release field SUPPORT_END= described below.
> 
>[...]
> 
>os-release gained a new field SUPPORT_END=-MM-DD to inform the user
>when their system will become unsupported.
> 
> 
> Should we set this? I kind of think we should.
> 
> I would suggest we set it to the expected EOL based on the nominal schedule.
> We could either release updates to extend it if we slip... or... just not do
> that.

I think we should also. 

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

PR's welcome. 

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: Karma for OpenSSL needed

[Kevin Fenzi]

On Tue, Nov 01, 2022 at 02:55:34PM -0700, Josh Stone wrote:
> On 11/1/22 11:16 AM, Neal Gompa wrote:
> > That said, the packages *are* signed in Koji, because as soon as it's
> > submitted to Bodhi, the packages are signed in-place in Koji.
> 
> Is that really in-place? Bodhi says these are signed, but when I
> download from koji, "rpm -qip" still shows "Signature: (none)".

If you download the direct build links you get unsigned copies. 

If you use something like: 

koji download-build --key=5323552a openssl-3.0.5-2.fc37

you get builds signed with the f37 key. 

Or you can look directly at: 
https://kojipkgs.fedoraproject.org/packages/openssl/3.0.5/3.fc37/data/signed/5323552a/

where data/signed/ has a dir for any keys the rpms are signed with and
written out currently.

Currently we are waiting for the CI tests to all complete, then the f36
one will be pushed stable, and likely the f37 one won't be far behind. 

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: F40 proposal: Porting Fedora to Modern C (System-Wide Change proposal)

[Kevin Fenzi]

On Wed, Oct 26, 2022 at 10:23:40AM +0200, Florian Weimer wrote:
> * Zbigniew Jędrzejewski-Szmek:
> 
> > On Tue, Oct 25, 2022 at 10:05:52AM -0400, Ben Cotton wrote:

...snip...

> >> == How To Test ==
> >
> > As discussed by others, this needs to explain how to opt-in for early
> > testing, and also how to opt-out in packages, how to opt-out as a user
> > (if the default touches users), etc.
> 
> The challenge with that is that I've been told not to do this work in
> Fedora proper by release engineering, and a request for a long-living
> side tag with a suitable compiler has not been approved:
> 
>   Long-term side tag for toolchain experiment
>   

Sorry that got dropped...

The thread about it I suggested copr, some other folks thought that
might work, and I don't recall ever hearing if that would work for you
or not. So, seems communication broke down here somewhere. 

I suppose it's too late now for this to matter aside from us trying to
not have it happen again? In the future, if a releng issue gets stuck,
please do drop by the releng and infra standups (mon/tue/wed/thu) at
18UTC in #fedora-meeting-3 / meeting-3:fedoraproject.org and bring up
the issue. 

> More recently, I was explicitly told not to keep the compiler changes on
> a branch in Fedora dist-git.
> 
> It is not really possible to get realistic testing through compiler flag
> injection because crufty old code that is problematic for these changes
> often does not inject flags properly.  Certain likely changes cannot be
> modeled through -Werror= options (but can be patched into GCC).  Some
> build systems explicitly filter out -Werror= options during the
> configure stage (generally a good idea, but not helpful here).
> 
> So I'm a bit at a loss what to do here.  Maybe releng can reconsider
> their approach.

So, can you say that copr definitely will not work for this?
If it will, great, use that. If it won't, we can make you a side tag, I
don't really have any objection to it other than it seems like copr was
better designed for this sort of work...

kevin


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: [side tags] Undesired automatic side-tag removal happened - how to deal with it in the future?

[Kevin Fenzi]

On Mon, Oct 17, 2022 at 12:55:44PM +0200, Zdenek Dohnal wrote:
> Koji devs forwarded me to releng pagure, so there is a new issue for this
> https://pagure.io/releng/issue/11093 .

So, it turns out that koji upstream added a 'inactivity' check. 
ie, no builds tagged in or out in a timeperiod. We were not setting
anything for this (since our cron job predates it existing) and we got
the default (10days). 

I have a PR in to set it to 21 days: 
https://pagure.io/fedora-infra/ansible/pull-request/1238
which I think is a bit more reasonable, but further input welcome. 

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: [side tags] Undesired automatic side-tag removal happened - how to deal with it in the future?

[Kevin Fenzi]

On Tue, Oct 11, 2022 at 08:08:32AM -, Michael J Gruber wrote:
> > Oh, also I forgot to mention... 
> > 
> > If your sidetag is deleted, you can just request a new one, tag the old
> > builds back into it and be back in business. I realize that that could
> > be anoying if you told people a specific one and then had to make a new
> > one, but it's not like those builds are lost. 
> 
> Good to know :)
> I think this info in a delete notification e-mail ("Your side-tag xy was 
> deleted after 30 days. It contained the following builds: ... You can re-tag 
> them into a new side-tag with: ...") would solve most problems. And we can 
> skip that mail if the side-tag has been merged already.
> Michael

I've created https://pagure.io/releng/issue/11082 to capture these
ideas/track implementing. 

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: stuck s390x builds in koji

[Kevin Fenzi]

On Tue, Oct 11, 2022 at 11:35:45AM +0200, Dominik 'Rathann' Mierzejewski wrote:
> On Tuesday, 11 October 2022 at 11:27, Dan Horák wrote:
> > On Tue, 11 Oct 2022 11:18:12 +0200
> > Luna Jernberg  wrote:
> > > On 10/11/22, Dominik 'Rathann' Mierzejewski  
> > > wrote:
> > > > Hi!
> > > > It seems that s390x builds in koji are not progressing. At the time of
> > > > writing, I can see ~150 s390x buildArch tasks in "free" state. I've
> > > > opened https://pagure.io/releng/issue/11079 to track this issue.
> > > >
> > 
> > > This might be related:
> > > https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org/thread/CLWFDN22YDF65R33BB3ZRSZHBZOE2LCK/
> > 
> > right, the builders are not running yet
> 
> Why does koji think they're Enabled and Ready, then?
> 
> https://koji.fedoraproject.org/koji/hosts?arch=s390x=enabled=name=all=all

Enabled/disabled to koji is a admin thing. If an admin didn't disable
them they are enabled. 

Ready is a koji load thing. If a builder has build(s) it's doing that
reach or excede it's 'weight' then it tells koji it's 'not ready' for
anymore builds. Otherwise it tells koji it's 'ready'. 

So, really you should look at the last checkin time. kojid checks in
pretty often to the hub. If it's more than a few minutes old, likely
something happened to that builder. Of course the hub has no idea, it's
just waiting to accept info from builders, it doesn't iniate connections
back. 

I often use something like: 

koji list-hosts --enabled |grep -v "11 Oct 2022 10:2"

ie, show all hosts that are enabled and have checked in in the last few
minutes. 

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: [side tags] Undesired automatic side-tag removal happened - how to deal with it in the future?

[Kevin Fenzi]

Oh, also I forgot to mention... 

If your sidetag is deleted, you can just request a new one, tag the old
builds back into it and be back in business. I realize that that could
be anoying if you told people a specific one and then had to make a new
one, but it's not like those builds are lost. 

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: [side tags] Undesired automatic side-tag removal happened - how to deal with it in the future?

[Kevin Fenzi]

So, just to add some data... sidetags are cleaned up via a cron job that
calls: 

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

So, it should have only deleted it if it was empty after 14 days, but it
looks like it deleted it with things tagged into it. ;( 
Would you be willing to file a koji bug on this? 
( https://pagure.io/koji ) or if you prefer I can. 

On Mon, Oct 10, 2022 at 02:08:26PM +0200, Adam Williamson wrote:
> On Mon, 2022-10-10 at 21:02 +0900, Mamoru TASAKA wrote:
> > Zdenek Dohnal wrote on 2022/10/10 17:17:
> > > Hi all,
> > > 
> > > I maintain qpdf in Fedora, which recently got a new major release 
> > > version, which breaks compatibility with other packages, so I created a 
> > > side tag for other maintainers to use for building, and then releasing it 
> > > altogether in rawhide.
> > > 
> > > However the side tag:
> > > 
> > > f38-build-side-58658
> > > 
> > > got automatically deleted, even when it had builds connected to it 
> > > already. Documentation [1] does not mention any automatic side-tags 
> > > cleanup and its deadlines.

We should update the docs. We did announce adding this. 

> > > Although packagers can create a new side tag easily, I found it 
> > > inconvenient for maintainers, because the synchronization among the 
> > > maintainers can take weeks to finish the rebuild and release the update 
> > > and automatic removal without notice (do excuse me if I missed a 
> > > notification email about this - I have many filters and it could end up 
> > > somewhere where I wasn't able to find it) prolongs this process.
> > > 
> > > What I would like to propose are the following options:
> > > 
> > > A) don't do side-tag cleanups after a specific time frame, but only when 
> > > the specific event happens - branching, GA, EOL - it can be consuming to 
> > > our resources, but maintainer are still able to remove the side tags 
> > > manually in case it contains a big set of packages and AFAIK the process 
> > > itself is not such spread in usage...

Side tags are actually pretty costly on the server end. It means every
single time a build lands in the parent tag they have to have their
rpeodata regenerated. It's tons of newRepos. I'd prefer to clean them up
as quickly as we can, but no quicker. :) 

> > > 
> > > or
> > > 
> > > B) do a side-tags cleanup and mention it in the documentation together 
> > > with specification what the removal's time frame is, so maintainers can 
> > > act accordingly

We should do this in any case. 

> > > or
> > > 
> > > C) (my preferred) Koji or releng (depends on whether the cleanup happened 
> > > automatically or manually) will send an email to a side tag creator with 
> > > 'Hi, your side tag is going to expire - do you need it?' Or with 
> > > automaton - 'use this command to prolong it.' And if there is no response 
> > > or if the creator approves, remove the side tag.

Doable, but more notifications and things to deal with. 

Note that sidetag cleanup has a newer option we aren't using yet too: 

  --inactive-delay=DAYS
delete tags inactive for DAYS (no build was un/tagged
there)

We could perhaps use this.

> > IMO basically side-tag is not expected to exist for such a long time, 
> > side-tag requester should
> > take effort to merge it into main buildroot within, say, one week at most.
> 
> I'm not sure this is always going to be realistic. We are increasingly
> encouraging folks to do big complicated rebases in side tags rather
> than breaking Rawhide or Branched for days at a time; sometimes this
> might take more than a week. I don't want folks to be discouraged from
> using side tags and just go back to breaking Rawhide because of this
> kind of cleanup.

I agree... I'm open to adjusting the cleanup script, but I do think we
should limit sidetags somewhat. 

We should in any case document and fix the empty thing. 

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: SRPM macros, EPEL, and side tags

[Kevin Fenzi]

On Wed, Oct 05, 2022 at 08:40:12PM -, Artur Frenszek-Iwicki wrote:
> Hi all,
> 
> some time ago I've built the Free Pascal Compiler [0] for EPEL9,
> and recently I got the idea it might be good to do the same with
> the Lazarus IDE [1]. Testing things locally with mock,
> I realized that Lazarus used a macro from fpc-srpm-macros [2],
> which hasn't been built for EPEL9 yet.
> 
> No biggie, I thought. I created a side tag, built fpc-srpm-macros there,
> then added "BuildRequires: fpc-srpm-macros" to the Lazarus spec
> and tried building it in the side tag. The build failed, and looking at
> root.log, the fpc-srpm-macros package was not installed [3].

srpm's are built in a different buildroot koji has defined as
'srpm-build'.

You can see whats in this with a 'koji list-groups epel9-build'

So yeah, you need something to pull in that fpc-srpm-macros, 
(likely epel-release) or have it added to the srpm-build 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

Re: Replacing GNOME Disks with Blivet GUI in comps' admin-tools?

[Kevin Fenzi]

On Wed, Oct 05, 2022 at 02:22:52PM -0400, Ben Cotton wrote:
> In going through the bugs against comps, I came across
> https://bugzilla.redhat.com/show_bug.cgi?id=1971338
> 
> The "admin-tools" group in comps includes GNOME Disks, which is a
> surprise for KDE Plasma users. We can swap it out for blivet-gui (note
> that other groups for GTK-based desktops would still include GNOME
> Disks) easily enough, but I didn't want to do that without seeking
> comment.
> 
> Does anyone have a good reason we shouldn't make this change?
> 
> (I don't think this rises to the level of requiring a Self-Contained
> Change proposal, but I'm happy to submit one if the consensus is that
> it should have one)

+1 to just do it. I don't think it needs a change. 

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

aarch64 builders upgrade

[Kevin Fenzi]

Greetings. 

I thought I would let everyone know that I have moved all the buildvm-a64
instances from some older hardware (lenovo emags) to newer hardware
(altra Mt. Snow). This should result in a noticable speed increase
along with allowing us to increase density of vm's per host.

If you notice any issues with buildvm-a64 machines, please file an 
infrastructure ticket: https://pagure.io/fedora-infrastructure

Thanks, 

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, report it: 
https://pagure.io/fedora-infrastructure/new_issue
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

aarch64 builders upgrade

[Kevin Fenzi]

Greetings. 

I thought I would let everyone know that I have moved all the buildvm-a64
instances from some older hardware (lenovo emags) to newer hardware
(altra Mt. Snow). This should result in a noticable speed increase
along with allowing us to increase density of vm's per host.

If you notice any issues with buildvm-a64 machines, please file an 
infrastructure ticket: https://pagure.io/fedora-infrastructure

Thanks, 

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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: How do I "unstick" koji?

[Kevin Fenzi]

On Wed, Sep 28, 2022 at 10:10:34AM -0400, Steven A. Falco wrote:
> On 9/28/22 09:59 AM, Stephen Smoogen wrote:
> > 
> > 
> > On Wed, 28 Sept 2022 at 09:53, Steven A. Falco  > > wrote:
> > 
> > Yesterday, I had a build that failed.  The task ID is 92381483.
> > 
> > I tried rebuilding it today in task 92397327 but I get the error 
> > message:
> > 
> > "GenericError: Build already in progress (task 92381483)"
> > 
> > I tried doing "koji cancel 92381483" but that doesn't help.  Another 
> > attempt (task 92398262) failed the same way.
> > 
> > Is it possible to clear this state or do I just have to bump the 
> > release number and try again?
> > 
> > 
> > There was an outage and some other issues with koji in the last 24 hours. 
> > It may take a releng person to clear this. Could you open a ticket at 
> > https://pagure.io/releng/  for that to happen?
> 
> I opened #11055 https://pagure.io/releng/issue/11055

Yeah, these builds were in a weird state because they just finished
right when the unexpected kojipkgs01 outage happened this morning. ;( 

I managed to cancel them via the api and rebuilds should finish. 

If there's any other builds in this state please 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: F39 proposal: Replace DNF with DNF5 (System-Wide Change proposal)

[Kevin Fenzi]

Sorry for the delay in my reply here. ;( 

Some questions: 

> * Release engineering: [https://pagure.io/releng/issues #Releng issue number]

no releng ticket? :( 

releng depends on dnf4 for a LOT of scripts. 
We will need a lot of help moving those to dnf5 I am sure. 
A porting guide for the python bindings would be welcome.

> The new DNF5 will provide a symlink to `/usr/bin/dnf` therefore users
> will see the replacement as an upgrade of DNF with limited but
> documented syntax changes. The DNF5 will provide some compatible
> aliases of commands and options to improve adoption of the DNF5.

A document like the yum2dnf man page with every single change would be
welcome. Also it would be nice if dnf5 accepted things and just warned
on them... ie '--refresh' or 'list' (use repoquery I guess)...

> == Dependencies ==
> There is a long list of dependent packages

I see a big one missing: koji

We also have some applications that might use dnf python bindings
(bodhi, packages, etc)

IMHO, I think it would be nice to get dnf5 reviewed and landed in Fedora
as soon as you can, because then you would have a place for people to
file bugs and iterate on things, but of course thats up to you. 

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

Planned Outage - networking work - 2022-09-26 21:00 UTC and 2022-09-27 21:00 UTC

[Kevin Fenzi]

There will be an outage starting at 2022-09-26/2022-09-27 21:00 UTC,
which will last approximately 4 hours on 2022-09-26 and 5 hours on 2022-09-27.

To convert UTC to your local time, take a look at
http://fedoraproject.org/wiki/Infrastructure/UTCHowto
or run:

date -d '2022-09-26 21:00UTC'
date -d '2022-09-27 21:00UTC'

Reason for outage:

On 2022-09-26 internet edge routers and switches will be upgraded. During this 
time period various
Fedora services will be down as switches and routers are rebooted.

On 2022-09-27 1gb internal switches will be upgraded. a 30min outage is likely 
during this time period.

Affected Services:

All services at the IAD2 datacenter

Ticket Link:

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

Please join #fedora-admin or #fedora-noc on irc.libera.chat
or add comments to the ticket for this outage above.


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, report it: 
https://pagure.io/fedora-infrastructure/new_issue
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Planned Outage - networking work - 2022-09-26 21:00 UTC and 2022-09-27 21:00 UTC

[Kevin Fenzi]

There will be an outage starting at 2022-09-26/2022-09-27 21:00 UTC,
which will last approximately 4 hours on 2022-09-26 and 5 hours on 2022-09-27.

To convert UTC to your local time, take a look at
http://fedoraproject.org/wiki/Infrastructure/UTCHowto
or run:

date -d '2022-09-26 21:00UTC'
date -d '2022-09-27 21:00UTC'

Reason for outage:

On 2022-09-26 internet edge routers and switches will be upgraded. During this 
time period various
Fedora services will be down as switches and routers are rebooted.

On 2022-09-27 1gb internal switches will be upgraded. a 30min outage is likely 
during this time period.

Affected Services:

All services at the IAD2 datacenter

Ticket Link:

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

Please join #fedora-admin or #fedora-noc on irc.libera.chat
or add comments to the ticket for this outage above.


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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Summary/Minutes from today's FESCo Meeting (2022-09-20)

[Kevin Fenzi]

On Wed, Sep 21, 2022 at 02:47:21AM +0200, Kevin Kofler via devel wrote:
> Miro Hrončok wrote:
> >* https://fedoraproject.org/wiki/Changes/JdkInTreeLibsAndStdclibStatic
> >  was submitted as an Fedora 37 update after it was deferred to Fedora
> >  38. We need to decide what to do.   (mhroncok, 17:02:38)
> [snip]
> >* AGREED: The update may be shipped after Fedora  37 Beta release,
> >  before the Fedora 37 Final Freeze. (+7,0,-0)  (mhroncok, 17:12:48)
> 
> This makes a farce of the whole Change process. I do not see why a Change 
> that was deferred to the next release can now be rushed in post Beta during 
> a feature freeze period where only release-critical bugs should be fixed. 

The impact was deemed to be small, (at least by me, I can't speak for the rest 
of fesco)
Also QA was ok with it since any impacts should show up in final testing. 

> (And in the particular case of this Change, I also do not see why it was 
> approved at all, be it for Fedora 37, 38, or some future version, for the 
> reasons that were already stated by me and others when the Change was pre-
> announced for discussion. The feedback on the mailing list was entirely 
> negative, the only people in favor were the submitters.)

Not that the discussion was about all the changes/phases openjdk
maintainers wanted to make. ( ie,
https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs ) 

This is just the first part and it had reasonable amount of support.
( https://fedoraproject.org/wiki/Changes/JdkInTreeLibsAndStdclibStatic )

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: Proposal: disable comps component in Bugzilla

[Kevin Fenzi]

On Tue, Sep 20, 2022 at 10:01:36AM -0400, Ben Cotton wrote:
> comps, the system of XML files used to put packages into functional
> groups is hosted on a Pagure repo[1] but also has a Bugzilla
> component. In the interests of simplicity, I propose to disable the
> comps component and use the Pagure repo for all comps issues. In the
> case where a change in comps is necessary for Bugzilla-based processes
> (e.g. blockers), we can use a bug in the distribution component.
> 
> I don't see a benefit to having the Bugzilla component for comps as a
> general matter, but if there's a good argument for keeping it, let me
> know. Otherwise, I plan to disable the component on Thursday 29
> September.

Amusingly I think we in the past discussed closing the pagure project to
issues and using bugzilla only. ;) 

But I'm fine doing either one... having one place for bugs instead of
two is a good thing. 

What will be done with the existing open bugzilla bugs?
(There's some overlap between the two it looks like).
Close and ask them to refile? Refile for them?

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

[olsaj...@gmail.com: Re: unannounced soname bump in libbpf]

[Kevin Fenzi]

This seems to have gone to the devel-owner instead of the list:

- Forwarded message from Jiri Olsa  -

Date: Sun, 18 Sep 2022 22:55:39 +0200
From: Jiri Olsa 
To: devel-ow...@lists.fedoraproject.org
Cc: olsaj...@gmail.com
Subject: Re: unannounced soname bump in libbpf

On Sun, Sep 04, 2022 at 12:37:19PM +, devel-ow...@lists.fedoraproject.org 
wrote:
> Your message to the devel mailing-list was rejected for the following
> reasons:
> 
> The message is not from a list member
> 
> The original message as received by Mailman is attached.

> Date: Sun, 4 Sep 2022 14:36:13 +0200
> From: Jiri Olsa 
> To: devel@lists.fedoraproject.org, Kevin Fenzi 
> Cc: jo...@fedoraproject.org
> Subject: Re: unannounced soname bump in libbpf
> 
> On Sat, Sep 03, 2022 at 05:01:47PM -0700, Kevin Fenzi wrote:
> > 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."
> 
> hi,
> sorry, I overlooked this
> 
> > 
> > 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
> 
> I'll check on that and let you know, thanks for help

hi,
sorry for delay, linux plumbers conf that was last week
got in the way..

so I created the side tag:
  https://koji.fedoraproject.org/koji/buildtargetinfo?name=f38-build-side-58568

and build libbpf for that:
  https://koji.fedoraproject.org/koji/taskinfo?taskID=92151200

I got the packages that have dependencies on libbpf with
  $ dnf repoquery --alldeps --whatrequires libbpf

so IIUC now I need to make build for that side tag for each
package from that list

I have few questions:

I just increase current release number for each package
and make build for the side tag, right?

and that chage goes to rawhide branch?

thanks,
jirka


- End forwarded message -


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 Mon, Sep 19, 2022 at 05:58:36PM +0200, Vít Ondruch wrote:
> 
> Dne 16. 09. 22 v 19:03 Kevin Fenzi napsal(a):
> > On Fri, Sep 16, 2022 at 10:03:35AM +0200, Vít Ondruch wrote:
> > > Isn't peer review much better and easier solution over all? We could also
> > > require signed commits I guess.
> > I think it would slow things down quite a lot to require peer review of
> > every commit.
> 
> 
> This proposal was based mainly upon the conversation, where nothing what was
> proposed was secure enough. Every proposal was shot down having some
> possible holes. While peer review might be slow and it is certainly not
> bullet proof, I don't think we can do any better.

Well, the problem is 'secure enough'. Security is not a checkbox. 
You can't ever say "ok, we are secure". Security is a process. What
things you do are based on what possible solutions you have and what
possible attacks you have and the tradeoffs you have to make to
implement things. 

I don't personally think right now the tradeoffs are worth requiring
review for every change. I fear it would result in a lot of "hey can you
+1 my change" and people just clicking reviewed without reviewing. Bad
actors would just need to find another person to approve their change
without much review. Of course a lot of people would review and perhaps
it would improve overall quality.

Long ago, when number of changes was small... I used to actually read
all of them and comment when I found something concerning. I've not been
able to do that in many years tho... In the past 30 days there have been
41080 changes to spec files. That is a ton.

> And BTW, when I talk about peer review, I think that also ex-post peer
> review is valuable. E.g. if I contribute to some package, I'll look at every
> commit notification and check the changes. If I see something concerning,
> I'll try to address it. Better late then never.

Absoluetely.

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: 20220917.n.0 changes

[Kevin Fenzi]

On Sat, Sep 17, 2022 at 11:15:40AM +, Fedora Rawhide Report wrote:
> OLD: Fedora-Rawhide-20220916.n.0
> NEW: Fedora-Rawhide-20220917.n.0

On Sat, Sep 17, 2022 at 12:51:42PM +, Fedora Rawhide Report wrote:
> OLD: Fedora-37-20220916.n.0
> NEW: Fedora-37-20220917.n.0

I'd like to note that today, both rawhide and branched composes
completed with status "FINISHED". This means every single artifact that
was supposed to be composed was. :)

Keep up the great work everyone... lets see if we can keep it going. 

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 Fri, Sep 16, 2022 at 10:03:35AM +0200, Vít Ondruch wrote:
> Isn't peer review much better and easier solution over all? We could also
> require signed commits I guess.

I think it would slow things down quite a lot to require peer review of
every commit. 

I'd personally like to avoid anything where we need to support gpg.
It's a mess and I think it would waste a lot of cycles explaining how to
use it or help people get setup. ;( If there's some easier/more clear
way to sign things that could be a option tho.

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 Fri, Sep 16, 2022 at 10:29:17AM +0300, Alexander Bokovoy wrote:
> 
> One thing I want to get properly implemented in SSSD in upcoming FIDO2
> support is to allow admins to filter out certain types of public SSH
> keys associated with the user account. E.g. get a way for administrator
> to say 'only FIDO2 keys and their OpenSSH equivalents (ecdsa-sk,
> ed25519-sk) allowed for these users' and let SSSD's
> sss_ssh_authorized_keys to filter all other types. Then your git server
> could be able to deny non-FIDO2 SSH keys on per-user base.

That would be cool. 

Even better IMHO would be support for ssh certs. 
ie, auth with your FIDO2 key/otp and you get a ssh cert thats has a time
limit / other restrictions for just pushing git commits, etc.

> FreeIPA Kerberos already gives you this feature for various
> authentication methods[1] but it is not integrated in OpenSSH's GSSAPI
> support.
> 
> [1] 
> https://freeipa.readthedocs.io/en/latest/workshop/11-kerberos-ticket-policy.html
> 
> > > 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.
> 
> Solving this is a social problem. I'd like to remove technical
> roadblocks so that we can better focus on the solutions to social
> problems. Right now we aren't there on both sides.

Agreed.

...snip...

> Sure. I guess we can aim last week of October. I'll write up a call for
> participation next week.

Thanks.
 
> > > > > Do we have any statistics of how we stand now that Fedora Accounts is
> > > > > deployed for more than a year and people were enabled to use 2FA 
> > > > > tokens
> > > > > through it?
> > > >
> > > > I could try and gather some. What stats would be helpfull?
> > > 
> > > A particular argument by smooge and others was arount 'passwords or
> > > tokens being lost frequently'. I'd like to see how widespread is this
> > > problem. Can we collect stats on amount of requests to reset passwords,
> > > reset tokens, etc. for a period of a year or so?
> > 
> > We currently have 1560 tokens enrolled.
> > (Of course some users have more than one, but most seem to have one)
> > 
> > In the 1 year period from 2021-07-01 to 2022-07-01 we had 87 requests to
> > reset otp. Some of these were people who were confused and didn't actually
> > even have a otp enabled, but it's hard to count those without going
> > through each request.
> > 
> > So, it's less than 5% a year it seems like, or a request every 4days if
> > they were evenly spaced.
> 
> Thank you. This is actually better than I expected to see. Improving
> technical measures and UX should help but there always will be something
> that is harder to deal with, anyway.

I'll also note that I think many more of them came toward the first part
of that time period. We made some changes to the interface that helped a
good deal. At first we had a mailto: link and got a bunch of blank
emails (bots just following the link? confused users?)
https://github.com/fedora-infra/noggin/issues/678

So, it might be interesting to see how things look after that change
landed.

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 Thu, Sep 15, 2022 at 04:34:08PM -0400, Demi Marie Obenour wrote:
> On 9/15/22 13:55, Kevin Fenzi wrote:
> > 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.
> 
> SSH keys are fine.

Sure, but unless you are using ecdsa-sk or ed25519-sk keys, they aren't
2factor enabled. Your account could be using OTP, but if someone gets
your ssh private key they can commit as you. 

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 Thu, Sep 15, 2022 at 11:54:13AM -0700, Adam Williamson wrote:
> On Thu, 2022-09-15 at 10:55 -0700, Kevin Fenzi wrote:
> > 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. 
> 
> I kinda feel like we really ought to just stick a check for this
> *somewhere*. An alert should pop up somewhere any time anyone adds a
> Supplements: line to *anything*. It's a sufficiently odd thing to do
> that it shouldn't happen very often, I think...
> 
> I suspect in the past the answer to this would be "Patrick probably
> does it already". Did we find a Patrick 2.0 yet? :D

Ha. no. 

There is a hook we have that notifies people when someone adds an
exclude/exclusivearch. We could make another one that checks for
Suggests I suppose. 

They could just add Requires tho, or add something that makes the auto
dep generating scripts add a requires or suggests. 

So, perhaps a CI check would be better, to check the actual produced
binary package.

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