Re: F40 Change: Privacy-preserving Telemetry for Fedora Workstation (System-Wide)

[Kevin Fenzi]

On Fri, Apr 19, 2024 at 09:37:38AM GMT, Igor Kerstges wrote:
> Those questions regarding privacy are asked and answered to my satisfaction. 
> I'd like to understand more implications about this change..

There are none. This proposal was withdrawn.

It may be adjusted and submitted for consideration again, but that has
not yet happened.

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: Three steps we could take to make supply chain attacks a bit harder

[Kevin Fenzi]

On Fri, Apr 12, 2024 at 03:45:40PM -0400, Steve Cossette wrote:
> What about simply blocking access to the git repos/koji/bodhi for those
> without 2fa?

Well, git I suppose could be a hook that checks the status of the user,
but koji and bodhi don't really have any place to hook that in directly.
They would have to add something in their permissions models to check
for specific actions.

Denying access to koji and bodhi entirely for people without 2fa is...
way too wide. bodhi updates would never get karma from users who didn't
bother to set it up, people just doing scratch builds would be affected,
etc.

So, sure, it's possible, but would be a lot of new code needing written.

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: Three steps we could take to make supply chain attacks a bit harder

[Kevin Fenzi]

On Fri, Apr 12, 2024 at 09:47:04AM -0700, Adam Williamson wrote:
> On Thu, 2024-04-11 at 19:52 -0700, Carlos Rodriguez-Fernandez wrote:
> > I was hesitant to have MFA for a while. Imagine losing a phone with tons 
> > of tokens. What a hassle to recover from that. I found it less than 
> > ideal for practical reasons.
> 
> This is one reason most systems provide a sheet of one-time backup
> codes that you're meant to print out and keep in a safe place, for
> recovery from exactly that scenario.
> 
> Alternatively, if you have an old phone or tablet lying around, just
> install an MFA app on that and enrol it too, lock it in a cabinet, then
> if you ever lose your primary phone, use it to recover.
> 
> Also, these days, most authenticator apps support some kind of backup
> mechanism. FreeOTP lets you back up to a file (which you should, of
> course, keep somewhere safe and ideally encrypted). Google
> Authenticator can backup To The Cloud.

yeah, I'll put in a plug for the one I use:
https://github.com/beemdevelopment/Aegis

It's open source, available on f-droid and play store, can to encrypted
backups, pretty active upstream, highly rated in reviews.

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: RFC: Django latest vs LTS maintenance plan

[Kevin Fenzi]

On Thu, Apr 11, 2024 at 03:41:02PM -0500, Michel Lind wrote:
> Hi all,
> 
> With the recent EOL of the Django 3.2 LTS series[^1], and Django being a
> key component of our mailing list infra for both Fedora and CentOS, I
> would like to propose the following plan to maintain Django in both
> Fedora and EPEL:
> 
> - Fedora: `python-django` maintained as currently, not tracking any LTS
>   series
>   - **but** also fork off `python-django` each time it hits an LTS
> series to make a new `python-djangoX.Y` (e.g.
> https://bugzilla.redhat.com/show_bug.cgi?id=2274198)
> - LTS packages are introduced in Fedora first, until they either reach
>   EOL or no longer build, at which point they are retired in Rawhide.
>   See below for the EOL case.
> - EPEL: we will only branch LTS packages (as is the case now, with
>   `python-django3` - though under the new naming scheme it should have
>   been `python-django3.2`)
> - Handling EOL
> - not an issue for `python-django` - we just keep rebasing it

To be clear, in fedora right? There wouldn't be a bare python-django in
EPEL?

> - for LTS releases in Fedora, retire in Rawhide if the series will
>   EOL before the EOL of the upcoming Fedora release
> - for LTS releases in EPEL, once it is EOL (like `python-django3`)
>   we mark it as `Provides: deprecated()` and retire it if there is a
>   replacement that works with add-on packages, *and* there is a CVE
>   that is not fixed
> - Package ACL: cc-ing the current maintainers of python-django here.
>   Please let me know if
>   - you want to be added to the LTS packages as well
>   - you want to be removed from python-django
>   - you're not currently involved but want to help out
>   - I'll also add infra-sig to the ACL for the LTS packages, as in
> practice they might need access to fix any issue affecting Mailman
> 
> The different Django stacks are in the process of being updated so they
> can be swapped without affecting dependents, by providing and
> conflicting with the virtual `python-django-impl`; not only will this
> allow us to swap one Django LTS for another in EPEL when the older one
> EOLs, but it also allows those with dependencies that are not qualified
> for the latest Django to swap to the LTS in Fedora
> 
> Let me know if this makes sense, or if you have ideas of how to handle
> some of these better.

I think it does make a lot of sense. ;) 

On the epel side, it would be good to make some noise/announce when a
LTS one is marked deprecated and when it's retired, since 3rd parties
might be using it for the external stuff even if everything in EPEL
moves to the new one. 

Would a EPEL package moving to a new LTS release need
exceptions/announcements also? I mean, ideally it doesn't matter, but it
would be a large version jump, even if the dependent package didn't
change otherwise. Also, there might be cases where the dependent package
does have to change... ie, foo-1.0 works with django-3.2, but when 4.2
lands you have to upgrade to foo-2.0 to work with it?

Anyhow, I think this is a pretty reasonable process, but we should make
sure and communicate it very well, document it and make sure epel
steering comittee is happy with it. 

kevin


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

Re: Three steps we could take to make supply chain attacks a bit harder

[Kevin Fenzi]

On Thu, Apr 11, 2024 at 05:49:27PM -0700, Adam Williamson wrote:
> On Fri, 2024-04-12 at 00:09 +, Gary Buhrmaster wrote:
> > 
> > What is the best way to formally propose
> > that 2FA is required for packagers after
> > some date
> 
> There is already a FESCo ticket. https://pagure.io/fesco/issue/3186 /
> Please don't discuss there, discuss here; FESCo will vote in that
> ticket or a meeting when they feel it appropriate.

I was wanting to circle back and add some more info to this thread too.

So, right now as far as I know, IPA doesn't have a way to easily say
'require a otp to be enrolled if you want to be added to this group'.

We do have a script that can check current members of a group(s) for otp
and nag them. This is what we do for sysadmin groups, although we
haven't done it in a while. 

So, if FESCo decided we wanted to enforce 2fa for provenpackagers or
whatever, right now that would require some work on some scripting,
which I guess would remove people without otp? But then there would
still be a window when the user was added and before the script removed
them. Or some way for sponsors to check otp status before sponsoring
someone, but if thats manually it could be missed.

I think in any case it might be good to find all the {proven}packager
members without otp and perhaps email them a note about how to set
things up, 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

Re: Looking for people to be stewards of rpminspect-data-fedora

[Kevin Fenzi]

On Tue, Apr 09, 2024 at 01:55:41PM -0400, David Cantrell wrote:
> Hello all,
> 
> I am looking for multiple people to help be upstream stewards of the 
> rpminspect-data-fedora project.  This is a project that contains config files 
> and rules for running rpminspect on Fedora builds.  It is a package 
> containing distribution policy.  It needs people to look over it and review 
> and merge contributions from other developers, do occassional releases, and 
> ensure that it is updated as new releases of Fedora are started (and we get 
> new dist tags).
> 
> The project currently lives here:
> 
> https://github.com/rpminspect/rpminspect-data-fedora
> 
> But absolutely can move depending on the desires of the individuals who take 
> over maintenance.  I created these rules files in the data package for 
> rpminspect so that different vendors can customize how rpminspect runs and 
> reacts to findings.  Maintenance of the rules is independent of the software 
> maintenance.
> 
> If you are interested, please email me directly and we can get going on the 
> logistics.  If you have general questions, feel free to ask here.

I wonder if this isn't something we should have the QE or releng teams
manage... ie, adding new branch info (releng), adjusting tests (qe)?

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 Monday's FESCo Meeting (2024-04-08)

[Kevin Fenzi]

On Mon, Apr 08, 2024 at 06:19:31PM +, Zbigniew Jędrzejewski-Szmek wrote:
> On Sat, Apr 06, 2024 at 10:45:52AM -0700, Kevin Fenzi wrote:
> > = Discussed and Voted in the Ticket =
> > 
> > Change: GNU Toolchain F41
> > https://pagure.io/fesco/issue/3181
> > APPROVED (+6, 3, -0)
> 
> Not that it matters for anything, but it's actually (+6, 0, 0),
> i.e. there were no abstaining votes. (I was surprised by the three,
> so I went to check the ticket.)

Sorry, my brain somehow decided that was 'didn't vote' instead of
'actually abstained'.

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: EPEL9 updates obsoleted

[Kevin Fenzi]

On Sun, Apr 07, 2024 at 10:11:56PM +0200, Fabio Valentini wrote:
> On Sun, Apr 7, 2024 at 10:10 PM Fabio Valentini  wrote:
> >
> > On Sun, Apr 7, 2024 at 7:06 PM Antonio T. sagitter
> >  wrote:
> > >
> > > Hi all.
> > >
> > > Can this update be re-activated or i have to rebuild everything?
> > > https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-c154b725ab
> >
> > I'm not sure how the update got into the "obsoleted" state without
> > being obsoleted by ... *something*?
> > It should have been "unpushed", which should allow you to to un-unpush
> > it, but de-obsoleting doesn't seem to be possible.

It looks like it hit the -3 karma limit and it got obsoleted.
It does seem like that should have just unpushed it...

> > Since the update was created from a side tag, you can't just remove
> > all builds from the update and add them to another one ...
> > But tagging the builds into a fresh side tags won't work either (IIUC)
> > because there already exists and update for these builds :(
> >
> > Not sure how this update got into this weird state, but I don't think
> > there's a way around rebuilding things in a fresh side-tag.
> > (People who know better than me, please correct me if that is incorrect.)
> 
> Oh! One thing you *could* try is to untag the builds from the side-tag
> for the obsoleted update, edit the update to refresh the list of
> builds, and save an "empty" update. Not sure if that will work though
> ... Then it would be possible to tag the builds into a fresh side-tag.

You cannot remove the last build from an update, so you would have to
rebuild the one thing anyhow. ;( 

So, probibly best to just bump and rebuild em all?

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

Schedule for Monday's FESCo Meeting (2024-04-08)

[Kevin Fenzi]

Following is the list of topics that will be discussed in the
FESCo meeting Monday at 19:30 UTC in #meeting:fedoraproject.org
on Matrix.

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

or run:
  date -d '2024-04-08 19:30 UTC'

Links to all issues to be discussed can be found at: 
https://pagure.io/fesco/report/meeting_agenda

= Discussed and Voted in the Ticket =

Change: GNU Toolchain F41
https://pagure.io/fesco/issue/3181
APPROVED (+6, 3, -0)

= Followups =

None

= New business =

#3183 Change: PHP No 32-bit
https://pagure.io/fesco/issue/3183

#3191 Change: Switch to DNF5
https://pagure.io/fesco/issue/3191

= Open Floor = 

For more complete details, please visit each individual
issue.  The report of the agenda items can be found at
https://pagure.io/fesco/report/meeting_agenda

If you would like to add something to this agenda, you can
reply to this e-mail, file a new issue at
https://pagure.io/fesco, e-mail me directly, or bring it
up at the end of the meeting, during the open floor topic. Note
that added topics may be deferred until the following meeting. 


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: Introduction and Application for Sponsorship

[Kevin Fenzi]

On Fri, Apr 05, 2024 at 03:07:39PM +, seanmott...@posteo.net wrote:
> Hi devel!
> 
> I'm Sean (FAS: seaninspace). I've been working professionally in Linux
> Sysadmin/Engineering positions for over a decade now, and would like to help
> out more :)
> 
> I've spent most of my Fedora time in QA with the installer, specifically the
> XFCE Live ISO. Additionally, I have maintained small/personal packages
> outside of the official repositories in the past, and have previously
> maintained an RPM mirror with a decent amount of traffic. I'm hoping to
> learn more and give back by adopting this package.
> 
> I've submitted a sponsorship ticket here:
> https://pagure.io/packager-sponsors/issue/643

Welcome Sean!

Feel free to ask here or in the #devel:fedoraproject.org matrix channel
if you run into any problems/questions.

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: Switching XZ for ZSTD?

[Kevin Fenzi]

On Thu, Apr 04, 2024 at 08:11:42PM +0200, Leon Fauster via devel wrote:
> 
> One approach that would be at least bring some light into "weak"
> (non technical layer) components (albeit not sure how feasible it is),
> could be:
> 
>  - Checking the resources of a packaged project.
>Resources in terms of man or firm power that backup the project
> 
>  - Contribution activity of people
> 
>  - General activity of the project
> 
>  - Transparency of the workflow / tools
> 
> and that for all projects that the distribution includes.
> 
> Why? This would allow to plan internal review activities
> (or processes) more effectively. They would be directed
> to the "weak" components with higher priority (recurrent, actions).
> 
> 
> Like the current process for checking the license (SPDX) of a project,
> it could also collect such metrics right away.

Well, as others have noted there is already OpenSSF scorecards.

I agree it's good to know this info, and for maintainers that have a ton
of packages they maintain, it might be good to be able to look at this
to remind them. For maintainers with fewer packages, they likely already
just know this from interacting with the upstream project already.

I don't think we can or should use that for things like deciding if we
allow packages into the collection or the like, there's a lot of ways a
low score there could not matter or be non represenative of what the
project is like.

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: F41 Change Proposal: Switch to DNF5 (system-wide)

[Kevin Fenzi]

On Thu, Apr 04, 2024 at 07:00:13AM +0200, Jan Kolarik wrote:
> Hi guys,
> 
> the dnf-automatic command will be obsoleted.
> >
> 
> Oh, sorry about that. This portion of the text was inadvertently altered
> during the review process. I've already corrected the text on the wiki.
> 
> The dnf-automatic command will still be available, now provided as a plugin
> and functionally compatible with dnf4. Although the configuration files'
> location has changed, it will be documented in the dnf4 vs. dnf5 changes
> documentation .

Yeah, on digging more into the docs it looks like this should be fine.

Just needs adjustment of the config and enabling the timer you want.

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: Switching XZ for ZSTD?

[Kevin Fenzi]

On Thu, Apr 04, 2024 at 05:04:20PM +, Arnie T via devel wrote:
> Hi Stephen,
> 
> Thanks for the explanation.
> 
> I just caught up with the article at the New York Times,
> 
> Did One Guy Just Stop a Huge Cyberattack?
> https://www.nytimes.com/2024/04/03/technology/prevent-cyberattack-linux.html
> 
> And the comic that looks like it fits the problem I'm most noticing here!
> 
> https://xkcd.com/2347/
> 
> I have to admit that I still don't know what the best or most official "At 
> least do this" instruction page is for a Fedora user.
> I don't see anything at the main https://fedoraproject.org/ website or its 
> "News & Announcements" page.

The magazine article should cover this. 

If you are using Fedora 38 or Fedora 39, nothing to do. The versions
affected were never in there.

If you are using Fedora 40 (prerelease) or Rawhide you should urgently update.
This will get you the clean version. If you wish to be extra cautious,
you could reinstall from current nightly media.

> In this thread its becoming about the details of the process. But not yet 
> about a solution. All of which I get.
> And in private emails people are insisting on sending to me about how I'm 
> unreasonable for asking the questions, and "should have" understood this or 
> that.
> So, with your discussion the best guess I can some up with is to make sure XZ 
> is downgraded and just hope that one of this Jia Tan's 6000+ commits are 
> still hidden in some other project with not enough eyes. Or that the XKCD 
> coming true doesn't happen again.

Lots of folks are scrutinizing those commits.
There were some minor things discovered, but nothing (at least that I
know of right now) that affects Fedora.

There are changes coming in systemd, openssh and other places that would
make this particular vector harder/impossible also.

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: Switching XZ for ZSTD?

[Kevin Fenzi]

On Thu, Apr 04, 2024 at 01:26:14PM +, Arnie T via devel wrote:
> Hi,
> 
> I just installed Fedora on 2 of my PCs a couple of weeks ago.  One version of 
> Fedora 39 release and one of Fedora 40 to see where things are going.
> 
> I learned about this XZ-hack from Ars Technica & The Economist.
> 
> I got to the Fedora Magazine article and wasn't really clear on that.
> 
> So I followed the discussion to this thread in this Development mailing list.
> 
> I read a lot of it but _still_ can't 100% figure out what the final solution 
> is going to be.

There's no 'solution' really... there's a lot of discussion around what
we can improve at the distro level, what we can urge upstreams to do,
how we can help out more, etc. 

I'm hopeful some things will come out of this as it's a chance for us to
look at our processes and improve them. 

> I have a question about that.
> 
> I'm for sure OK that a responsibly developed FOSS project can contribute 
> value and should be welcomed.
> 
> ISTM that if a package is used on critical-path or security-path by default 
> in a Distro it needs a higher bar.
> 
> IIUC from this thread and online discussions about XZ & alternatives that
> 
> 1] Lack of committer 'Real' identity confidence and verification is a problem.

IMHO this isn't a problem. We don't have a right to demand anything from
open source projects. We can ask, we can urge, we can contribute and
change things, we can choose to not use something, or fork something. 

> 2] Undetected differences source + packaging in repo vs tarballs are 
> unchecked.

Yeah, a lot of the discussion has been in this area. 

I'm wondering if perhaps we shouldn't revisit source-git, or at least
a variant of it where we keep the upstream sources in a branch always
and apply packaging on top of that and build from there. 

> 3] Under-resourced development creates risk; 'Many eyes' bench depth in 
> development is needed.

Yep. I think also visibility of changes can be improved.
So, maintainers know more about whats in a new version and how it works. 



kevin


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

Re: F41 Change Proposal: Switch to DNF5 (system-wide)

[Kevin Fenzi]

On Wed, Apr 03, 2024 at 11:57:48AM -0700, Adam Williamson wrote:
> On Wed, 2024-04-03 at 14:27 -0400, Przemek Klosowski via devel wrote:
> > On 4/3/24 06:36, Aoife Moloney wrote:
> > > the dnf-automatic command will be obsoleted.
> > 
> > https://dnf5.readthedocs.io/en/latest/changes.html does not say anything 
> > about automatic updates, and
> > 
> > https://packages.fedoraproject.org/pkgs/dnf5/dnf5-plugin-automatic/
> > 
> > simply suggests that dns update be executed from systemd timers or cron 
> > jobs.
> > 
> > 
> > dns-automatic provided a simple interface to a setup-and-forget 
> > automatic updates; will DNF5 leave it to be set up by hand?
> > 
> > I am asking because systemd timers have surprising behavior for 
> > suspendable systems, which leads to problems if updates are scheduled 
> > for off-hours.
> > 
> > My experience is that even |WakeSystem=true does not make them reliable, 
> > but I am not sure how to debug this (because the system is suspended, heh).
> > 
> 
> We do use dnf-automatic quite extensively within infra, I think. Has
> this been discussed with infra?

Not that I know of. Yes, we do use dnf-automatic all over the place. ;( 

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: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)

[Kevin Fenzi]

On Wed, Apr 03, 2024 at 04:24:08AM +0200, Kevin Kofler via devel wrote:
> Kevin Fenzi wrote:
> > Why not the opposite:
> > 
> > Download Workstation
> > 
> > [I'm a linux user and know what I want, just show me the full list of
> > downloads, click here]?
> 
> Because that still leads people to click that "Download Workstation" link 
> before even seeing the options. "I do not want to have to choose" should be 
> a concious choice, also considering that the mostly unconfigurable (by 
> design) GNOME is very likely to be the wrong option for anybody not in that 
> category. And besides:

It's still a choice. Just a better presentation IMHO for people who 'do
not want to choose'.

> > (Which is pretty much what we have now)
> 
> Well, not quite, it is more like:
> 
> [LOGO Workstation (Download Now) (Learn More)]
> 
> [LOGO Server (Download Now) (Learn More)]
> 
> [LOGO IoT (Download Now) (Learn More)]
> 
> [LOGO Cloud (Download Now) (Learn More)]
> 
> [LOGO CoreOS (Download Now) (Learn More)]
> 
> Want more Fedora options?
> 
> Atomic Desktops (Learn More) ← no frame nor logo nor mention of "download"
> 
> Fedora Spins (Learn More) ← no frame nor logo nor mention of "download"
> 
> Fedora Labs (Learn More) ← no frame nor logo nor mention of "download"
> 
> Fedora ALT Downloads (Learn More) ← no frame nor logo
> 
> So you get offered a lot of (most likely) irrelevant (to you) options 

to you? They are quite relevent to others... 

Anyhow, I think our positions are pretty clear here, so no need to
prolong this subthread.

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: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)

[Kevin Fenzi]

On Wed, Apr 03, 2024 at 06:17:59PM +0200, Leon Fauster via devel wrote:
> Am 02.04.24 um 23:32 schrieb Adam Williamson:
> > On Tue, 2024-04-02 at 17:37 -0300, Sergio Belkin wrote:
> > > 
> > > I am a happy KDE user, since the good old days of version 1.0. I celebrate
> > > this decision! My recognition goes to the enormous and sustained work of
> > > the entire KDE community.
> > > Cheers,
> > > Sergiio
> > 
> > To be clear, there is no 'decision'. This is a Change proposal. Any
> > Fedora community member can submit a Change proposal proposing just
> > about any change; I could submit one tomorrow proposing we abandon all
> > software development and open a yak farm instead.
> > 
> > A Change proposal existing is in no way an indication of any ultimate
> > outcome. Change proposals can be, and frequently are, rejected.
> 
> 
> Sorry, for not knowing the process right but where to vote up/down for such
> proposal?

You can provide your feedback here or in the discussion thread.

The actual voting on proposals happens with FESCo members once the
proposal has had feedback from the community (and of course if it's not
withdrawn, 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

Re: Three steps we could take to make supply chain attacks a bit harder

[Kevin Fenzi]

On Wed, Apr 03, 2024 at 07:27:12AM -0400, Stephen Gallagher wrote:
> On Tue, Apr 2, 2024 at 7:41 PM Kevin Fenzi  wrote:
> >
> > On Tue, Apr 02, 2024 at 04:38:25PM -0400, Stephen Gallagher wrote:
> > > On Tue, Apr 2, 2024 at 3:55 PM Steve Cossette  wrote:
> > > >
> > > > I personally would very much agree with enforcing the use of 2fa on the 
> > > > Fedora Account System. Maybe take that opportunity to make it a bit 
> > > > more user friendly? (Such as the fkinit prompt requiring the 2fa code 
> > > > being added at the end of your password -- to be clear I think the 2fa 
> > > > code should be separate)
> > >
> > > https://pagure.io/fedora-packager/pull-request/179
> >
> > I agree that fixing the mismatch in prompts might be nice, but why does
> > having 2fa seperate make things any better? I mean, it's one more return
> > you get to hit. ;)
> >
> > And... I am not sure about moving the handling of passwords to a bash
> > script from a kinit prompt.
> >
> 
> The kinit is already being run inside a bash script, so if bash is
> compromised with a keylogger, you've already lost the game... I'm not
> sure how this is worse.

Well, I meant more that now $PASSWORD has your password where before
kinit was the only thing you input your password into. :) 
So, if someone does say a 'sh -x fkinit' to look at something, their
password will show up, but it's probibly fine.

> Yeah, it's an extra keystroke, but I think there's value in helping
> the user provide the input in the proper format. Right now it's
> confusing (particularly since the kinit prompt gives bad information
> that we have to warn about).

Sure.

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: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)

[Kevin Fenzi]

On Wed, Apr 03, 2024 at 02:36:07AM +0200, Kevin Kofler via devel wrote:
> Kevin Fenzi wrote:
> > Ok, thats obvously somewhat tounge in cheek, but if we promote multiple
> > things, we need some way to describe them to uses who might not know the
> > history of things and do it in a quick enough way that they won't decide
> > it's all confusing and go do something else.
> 
> It is actually quite simple:
> 
> Here are your options:



Why not the opposite:

Download Workstation

[I'm a linux user and know what I want, just show me the full list of
downloads, click here]?

(Which is pretty much what we have 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: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)

[Kevin Fenzi]

On Tue, Apr 02, 2024 at 04:06:45PM -0400, Steve Cossette wrote:
> Alright, so a substantial amount of information changed since the original
> submission of the change proposal. We aren't necessarily thinking of
> demoting Gnome. The overall spirit of the CP is that we think KDE, and to
> some extent the other spins too, need a bit more visibility on the website.
> At the very least, Gnome and KDE should be up front on the frontpage.

So, I am far from a web designer, but if you aren't a Linux savvy person
and just decided to try out this Fedora thing because you heard it was
nice and you go to download it and get:

our website: Want a workstation?
user: yes!

our website: great! We have Gnome and KDE!
user: what? what does that mean? which one should I get?

our website: 

Gnome: "Get things done with ease, comfort, and control.
An easy and elegant way to use your computer,
GNOME is designed to help you have the best possible computing experience."

KDE: "Powerful, multi-platform, and for everyone
Use KDE software to surf the web, keep in touch with colleagues, friends
and family, manage your files, enjoy music and videos; and get creative
and productive at work. The KDE community develops and maintains more
than 200 applications which run on any Linux desktop, and often other
platforms too."

User: ok, that didn't tell me much, whats the difference? 
perhaps I will just keep using windows. 

Ok, thats obvously somewhat tounge in cheek, but if we promote multiple
things, we need some way to describe them to uses who might not know the
history of things and do it in a quick enough way that they won't decide
it's all confusing and go do something else. 

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: Three steps we could take to make supply chain attacks a bit harder

[Kevin Fenzi]

On Tue, Apr 02, 2024 at 04:38:25PM -0400, Stephen Gallagher wrote:
> On Tue, Apr 2, 2024 at 3:55 PM Steve Cossette  wrote:
> >
> > I personally would very much agree with enforcing the use of 2fa on the 
> > Fedora Account System. Maybe take that opportunity to make it a bit more 
> > user friendly? (Such as the fkinit prompt requiring the 2fa code being 
> > added at the end of your password -- to be clear I think the 2fa code 
> > should be separate)
> 
> https://pagure.io/fedora-packager/pull-request/179

I agree that fixing the mismatch in prompts might be nice, but why does
having 2fa seperate make things any better? I mean, it's one more return
you get to hit. ;)

And... I am not sure about moving the handling of passwords to a bash
script from a kinit prompt.

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 40 Final Freeze

[Kevin Fenzi]

On Tue, Apr 02, 2024 at 02:24:51PM +0200, Frantisek Zatloukal wrote:
> On Tue, Apr 2, 2024 at 12:39 PM Jakub Jelinek  wrote:
> 
> > sting->stable marked updates be still included in
> > stable without having to go through the exception/blocker process?
> >
> 
> I was told there would be one more stable push at the releng channel on
> matrix.

Yeah, there's a final stable push right before freezing. 

Thats been done, so check now if you still are looking to get anything
in. If so, it will need a approved freeze exception or blocker.

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

[Kevin Fenzi]

On Mon, Apr 01, 2024 at 05:07:13PM +, Christopher Klooz wrote:
> 
> On 31/03/2024 23.08, Kevin Fenzi wrote:
> > On Sun, Mar 31, 2024 at 10:30:23PM +0200, Leon Fauster via devel wrote:
> > > Not sure, if it was already mentioned -> containers. I had here a toolbox
> > > environment with F40. That I had not in my first actions
> > > on the screen. The last state had 5.6.0-3 installed but not sure
> > > if the previous release was also installed ...
> > You should pull the latest version and restart any containers you were
> > running.
> > 
> > kevin
> 
> I assume rawhide has been fixed, too? So that rawhide users also just need to 
> follow the same instructions as F40? Or do they need to reinstall?

Yes. The downgrade was pushed out on friday along with the f40 one. 

> If possible, I would like to end the topic updates in Fedora Discussion 
> tomorrow and suggest users that they can consider the issue solved once they 
> conducted all suggested steps and thus stop following the topic anylonger, 
> but for rawhide I still have the warning issued to not use it at this time. 
> Is the rawhide issue still open?

No, it should have the same resolution as f40.

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

[Kevin Fenzi]

On Sun, Mar 31, 2024 at 08:55:37PM +, Christopher Klooz wrote:
> The repo files should be the same on Fedora containers, so if the container 
> is F40 and the testing repo is enabled, it might have installed the malicious 
> build.

Right, if it was dnf updated during the time that the bad update was in
updates-testing.

Folks should pull the latest and restart.

> Preemptively, I added yesterday to the Fedora Discussion topic that people 
> shall also update their toolbox containers. I am not sure if a container can 
> end up in a condition that is vulnerable (especially since it has no 
> dedicated systemd), but I assume we do not know for sure at this time, and 
> the package was available to toolbox if the testing was enabled on a F40 
> container (I assume there are already F40 containers available? Didn't 
> verify).

Yeah, best to be safe and pull the latest that doesn't have the affected
build and rerun.

Yes, there are f40 containers available.

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

[Kevin Fenzi]

On Sun, Mar 31, 2024 at 10:30:23PM +0200, Leon Fauster via devel wrote:
> 
> Not sure, if it was already mentioned -> containers. I had here a toolbox
> environment with F40. That I had not in my first actions
> on the screen. The last state had 5.6.0-3 installed but not sure
> if the previous release was also installed ...

You should pull the latest version and restart any containers you were
running. 

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

[Kevin Fenzi]

On Sun, Mar 31, 2024 at 03:52:12PM -0500, Alex Thomas wrote:
> Just to be clear, as I was getting ready to put 40 Beta on a test
> machine, this has been fixed. I do the install and run updates and the
> compromised version of xz is never installed?

Correct.

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: Three steps we could take to make supply chain attacks a bit harder

[Kevin Fenzi]

On Sun, Mar 31, 2024 at 09:12:30AM -0700, Adam Williamson wrote:
> Thanks Arthur, yes, that was *exactly* the point.
> 
> I would argue there's a danger of getting too tied up in very specific
> technical details of this attack. Yes, it's reasonable to think of ways
> to mitigate those specific mechanisms, at least at the appropriate
> levels (arguably, most of this is really directly an issue upstream of
> us). But it has been - for me - persuasively argued that the specific
> technical details were decided based on the wider goals of the attack.
> 
> I buy the scenario where the starting point was "how can we poison the
> major distributions?" and everything from there derived from that
> starting point. xz was picked as the target because of all the specific
> technical stuff about systemd and ssh links which people are keen to
> dive deep into the details of, but *if that vector hadn't existed the
> attacker would just have chosen the next best one*. The specific form
> of the attack was then customized to the specific properties of xz,
> very cunningly - the whole thing about hiding the payload in binary
> test files. But if the attacker had chosen to attack a different
> project with different properties, they would have customized their
> attack to *that* environment with equal cunning, and it would probably
> look quite different.

I think even stepping further back from the technical details is worth
considering. I think xz was picked because it had one maintainer who had
personal issues and low time/desire to continue work, and they were a
good target to be bullied into adding another maintainer. Are there
other critical packages we ship in similar situations? 

> Worrying *only* about binary blobs in source repos or the specific
> details of how systemd opens compression libraries feels a bit narrow,
> to me - and especially so when we do it down at the distribution level
> where it's not necessarily primarily our responsibility, and I would
> argue is definitely not the *lowest* hanging fruit if we take a broader
> view of "what should we as a project be doing to raise the difficulty
> of supply chain attacks?"

Agreed. I think theres lots of places we should improve, and focusing on
our own backyard first might be wise. But we can also work on the other
parts too!

There are lots of things we _could_ do... we should discuss and consider
what ones make sense in what order. We should just do something because
we can. ;)

Also, a reminder... nothing is ever 'secure'. security is a process. We
consider likelt threats, we try and mitigate them, and we keep doing it.
Things change and we should too.

kevin


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

Re: Three steps we could take to make supply chain attacks a bit harder

[Kevin Fenzi]

On Sun, Mar 31, 2024 at 07:42:24AM -0400, Neal Gompa wrote:
> 
> At this point, I'm used to MFA for stuff (and I use a password manager
> that handles 2FA OTPs too), but the Fedora implementation of MFA is
> uniquely bad because we have to do a lot in the terminal, and our MFA
> implementation sucks for terminal usage.
> 
> If MFA is turned on:
> 
> 1. The Fedora account integration in GNOME breaks

To clarify, goa cannot get a new token for you, but once you have gotten
one with your otp, it will renew it for you until it's renewal time is
over. 

> 2. You need to concatenate password and OTP for getting a krb5 session ticket

Yep. I think this is being worked on...

> 3. The recovery mechanism involves GPG signed emails

Yep. Or... you can enroll multiple otps. You only need one to be
working. You can enroll more and keep backup ones. 

> The experience using 2FA for Fedora accounts is sufficiently
> unpleasant that I really don't want to use it.

:( 

kevin


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

Re: xz backdoor

[Kevin Fenzi]

On Sat, Mar 30, 2024 at 11:12:02PM +0100, Sandro wrote:
> 
> From what I understood, F40 Beta, the official Beta release, available from
> the website as of March 26, has updates-testing disabled by default. That

Nope. 

> was confirmed by several people in #devel yesterday when the Fedora Magazine
> article was still being worked on.

I am pretty sure I said the opposite... 

nirik: Branched enables updates-testing... so if you installed f40 anytime, you 
will have it enabled and if you then applied updates it would be in them
nirik: yes, we disable updates-testing by default right before release.

I guess that could have been read as right before beta release, but
thats not the case or what I meant. ;) 

It's before _Final_ release that we disable updates-testing.
It's enabled by default from when we branch the release off until the
time right before release when we switch it (usually with a freeze
break/blocker bug)

> It's the RC composes that are made after branching and before Beta is
> declared GO, that have updates-testing enabled by default. I was one of the
> persons raising that point. I'm less certain wrt upgrades in the period
> between branching and Beta release.

I think the confusion here is "Beta Release" vs "Final release".

We enable updates-testing at branching time all the way until right
before "Final release". :) 

> If that is incorrect and Beta shipped with updates-testing enabled,
> deliberately or by accident, then I stand corrected.

Yes, it did/does. :) 

The logic is that most people who install betas or pre-releases want to
help test updates. If for some reason they don't, they can disable it,
but the default option is on.
 
> > It is obviously still an issue that is evolving and what seems clear now
> > might prove different later. But so far I tend to leave the discussion
> > topic as it is and ensure that F40 users expect being compromised and
> > get informed to act correspondingly with the suggested actions. However,
> > I already added a point how users can check if they have a malicious
> > build.
> 
> I agree. Once the levees broke, news was traveling fast and, for some, panic
> may have set in, not helping in determining what information is accurate.
> 
> Advise to err on the side of caution, check your system and upgrade if
> unsure, is certainly what I would tell anyone. Even distros (Arch, Gentoo)
> where it turned out the payload wasn't injected, acted out of an abundance
> of caution, put out advisories and updates for their users.
> 
> What's written on Discussion looks to be covering the broad spectrum. Maybe
> the Fedora Magazine article could link to that post for further
> clarification.

Yeah, still lots to know about 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

Reminder: F40 final freeze starts next week (2024-04-02)

[Kevin Fenzi]

Just a reminder that, because Beta used it's 'target date #2'
(ie, today), the gap between the Beta release and Final freeze is only 1
week this time. 

So, please take this time to do any last minute testing and bugfixing
and make sure any packages you expect to be in the final f40 base
repositories are pushed stable before next Tuesday (2024-04-02).

https://fedorapeople.org/groups/schedule/f-40/f-40-key-tasks.html

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

Reminder: F40 final freeze starts next week (2024-04-02)

[Kevin Fenzi]

Just a reminder that, because Beta used it's 'target date #2'
(ie, today), the gap between the Beta release and Final freeze is only 1
week this time. 

So, please take this time to do any last minute testing and bugfixing
and make sure any packages you expect to be in the final f40 base
repositories are pushed stable before next Tuesday (2024-04-02).

https://fedorapeople.org/groups/schedule/f-40/f-40-key-tasks.html

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: Fedora Linux 40 Beta Released

[Kevin Fenzi]

On Tue, Mar 26, 2024 at 02:24:10PM +, Barry wrote:
> Why is the version of this announcement missing all the details
> here? 
> https://discussion.fedoraproject.org/t/fedora-linux-40-beta-released/109684

I think it was being edited when you looked?

It seems to have the details now? Or is there something missing?

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: Retiring Celestia from Fedora due to licensing issues

[Kevin Fenzi]

On Wed, Mar 20, 2024 at 04:36:02PM +, Mattia Verga via devel wrote:
> After I requested [1] Celestia project upstream to better define 
> licensing of all the textures and 3d models included in upstream data, 
> it turned out that at least some content is licensed CC-BY-NC-SA-3.0 [2] 
> which is not permitted in Fedora.
> 
> Upstream is still working on specify exactly the licenses of each file 
> and, maybe, in future will replace the problematic content with FOSS 
> textures. However, since there's no ETA for those tasks and the main 
> program cannot work by simply stripping out the problematic content, I 
> am forced to retire Celestia from Fedora.
> 
> I will be following the procedure for completely removing a package [3], 
> however there are a couple of things that I'd like to ask:
> 
> - should I wait for the flatpak maintainer to retire the flatpaks 
> (celestia-gtk and celestia-qt) before retiring the RPMs (celestia and 
> celestia-content)?

I don't think thats needed. The flatpak will not be able to build after
the rpm is gone, but thats ok, it shouldn't be in this case. 

> - do I need to ask releng to purge celestia sources from the lookaside 
> cache as well?

I'm not sure? Perhaps we could try and ask on the legal list?
We aren't really 'distributing' it there, just using that as part of our
build process. But of course it's available there.

> -do the flatpaks need to be added to fedora-obsolete-packages (or 
> something similar for flatpaks)?

Not sure on this one either. Would ask the flatpak sig.

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: F41 Change Proposal: Change Compose Settings (system-wide)

[Kevin Fenzi]

On Mon, Mar 25, 2024 at 10:59:15PM +0100, Kevin Kofler via devel wrote:
> Zbigniew Jędrzejewski-Szmek wrote:
> 
> > On Mon, Mar 25, 2024 at 04:50:28PM -0400, Neal Gompa wrote:
> >> Keep in mind we also want to make the compose process faster too, I
> >> don't know if it's worth it to spend 20x more time compressing
> >> repodata when we keep trying to get back hours and minutes in the
> >> compose time.
> > 
> > I wanted to write that the compression times are small enough for this not
> > not matter, but indeed, at the very highest levels, they do become
> > noticable.
> 
> 5 minutes? On a process that is run once every 24 hours? While at the same 
> time saving download time for all Fedora users? I fail to see the issue.

7 repodata files compressed x 5 arches x 2 (debuginfo) x 2 (server and
Everything ) = 140 files * 5min -> 11 hours?

Thats of course a inflation of what it would be... most of the repodata
files are way smaller than filelists, but still... keep in mind that any
one thing we do, if we do it a zillion times will add up. 

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: glibc32 in rawhide is now built from glibc

[Kevin Fenzi]

On Tue, Mar 19, 2024 at 04:36:03PM +0100, Florian Weimer wrote:
> * Kevin Fenzi:
> 
> > So, seems glibc32 was updated to update license headers?
> >
> > https://bodhi.fedoraproject.org/updates/FEDORA-2024-cd577e1535
> >
> > So, it's in f40-updates-testing now. 
> >
> > It's not in rawhide or f40 composes because pungi filters it out, but
> > it's currently not filtered in updates-testing. I can fix that, but...
> > isn't this package just going to be retired/blocked now?
> 
> Uh-oh?  Does this mean that glibc32 (the binary package) will land in
> updates-testing as well, each time we have glibc in gating?

Yep. So I will filter it there too...

> I planned to retire glibc32 after my vacation, in early April, but I can
> retire it now if that's better.

Naw, I can add it to filter out and then it shouldn't matter.

However, our filter config is... quite possibly out of date. :)

Currently it is: 

filter_packages = [
("^.*$", {
"*": ["glibc32", "libgcc32"],
"s390x": ["rust-std-static-wasm*"],
}),
('(Server)$', {
'*': [
'kernel*debug*',
'kernel-kdump*',
'kernel-tools*',
'syslog-ng*',
'astronomy-bookmarks',
'generic*',
'GConf2-dbus*',
'bluez-gnome',
'java-11-openjdk',
'community-mysql*',
'jruby*',
'gimp-help-*',
]
}),
]

Does libgcc32 exist anymore? 
Do we need that exclude on wasm on s390x?
Those sever ones look... weird.

Anyhow, I have filed: 
https://pagure.io/releng/issue/12023
on this, so if you want something to stay in there that's listed above,
please note it 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: glibc32 in rawhide is now built from glibc

[Kevin Fenzi]

On Fri, Mar 15, 2024 at 05:10:52PM +0100, Florian Weimer wrote:
> Joseph Myers enhanced glibc.spec so that we no longer need the separate
> glibc32 source package which its tarball of pre-built glibc binaries.
> 
> As part of the DNF5 adjustment to the removal of filelists, I believe
> some reverse dependencies (including gcc) have been adjusted to use the
> package name explicitly, as in:
> 
> %ifarch x86_64
> BuildRequires: (glibc32 or glibc-devel(%{__isa_name}-32))
> %endif
> 
> Most packages have dropped the glibc32 dependency because it was
> unneeded (or should do so).
> 
> This new package only contains the glibc files needed to build gcc.
> Other shared objects, such as libcrypt.so.2 or libgcc_s.so.1, are no
> longer included.
> 
> There is a pungi configuration which is expected to filter out glibc32
> from the compose.  We'll see how that works out.  The new glibc32
> package does not have any ELF dependency information, so the risk of it
> being installed by accident is reduced compared to the old one.
> 
> Once we have a compose without glibc32, I will retire the glibc32 source
> package because we no longer need it.  Currently, glibc32 is still
> tagged in, but it has a lower version than the glibc-built package, so
> the latter is installed in the buildroot.

So, seems glibc32 was updated to update license headers?

https://bodhi.fedoraproject.org/updates/FEDORA-2024-cd577e1535

So, it's in f40-updates-testing now. 

It's not in rawhide or f40 composes because pungi filters it out, but
it's currently not filtered in updates-testing. I can fix that, but...
isn't this package just going to be retired/blocked 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: glibc32 in rawhide is now built from glibc

[Kevin Fenzi]

On Fri, Mar 15, 2024 at 05:10:52PM +0100, Florian Weimer wrote:
> Joseph Myers enhanced glibc.spec so that we no longer need the separate
> glibc32 source package which its tarball of pre-built glibc binaries.
> 
> As part of the DNF5 adjustment to the removal of filelists, I believe
> some reverse dependencies (including gcc) have been adjusted to use the
> package name explicitly, as in:
> 
> %ifarch x86_64
> BuildRequires: (glibc32 or glibc-devel(%{__isa_name}-32))
> %endif
> 
> Most packages have dropped the glibc32 dependency because it was
> unneeded (or should do so).
> 
> This new package only contains the glibc files needed to build gcc.
> Other shared objects, such as libcrypt.so.2 or libgcc_s.so.1, are no
> longer included.
> 
> There is a pungi configuration which is expected to filter out glibc32
> from the compose.  We'll see how that works out.  The new glibc32
> package does not have any ELF dependency information, so the risk of it
> being installed by accident is reduced compared to the old one.
> 
> Once we have a compose without glibc32, I will retire the glibc32 source
> package because we no longer need it.  Currently, glibc32 is still
> tagged in, but it has a lower version than the glibc-built package, so
> the latter is installed in the buildroot.

Awesome. Thanks for all the work on this... I realize it's a weird
corner case, but now it's a lot more sane.

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 - fedora.im / chat.fedoraproject.org matrix server - 2024-03-14 07:00 UTC

[Kevin Fenzi]

Planned Outage - fedora.im / chat.fedoraproject.org matrix server - 2024-03-14 
07:00 UTC

There will be an outage starting at 2024-03-14 07:00UTC,
which will last approximately 1 hour.

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

date -d '2024-03-14 07:00UTC'

Reason for outage:

The fedora.im / chat.fedoraproject.org and fedoraproject.org matrix servers will
be down for 30-45minutes for database maintainance. Messages sent during the 
outage
should arrive after the outage via federation.

Affected Services:

fedora.im / chat.fedoraproject.org matrix server
fedoraproject.org matrix server

Ticket Link:

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

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

Updated status for this outage may be available at
https://www.fedorastatus.org/


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 - fedora.im / chat.fedoraproject.org matrix server - 2024-03-14 07:00 UTC

[Kevin Fenzi]

Planned Outage - fedora.im / chat.fedoraproject.org matrix server - 2024-03-14 
07:00 UTC

There will be an outage starting at 2024-03-14 07:00UTC,
which will last approximately 1 hour.

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

date -d '2024-03-14 07:00UTC'

Reason for outage:

The fedora.im / chat.fedoraproject.org and fedoraproject.org matrix servers will
be down for 30-45minutes for database maintainance. Messages sent during the 
outage
should arrive after the outage via federation.

Affected Services:

fedora.im / chat.fedoraproject.org matrix server
fedoraproject.org matrix server

Ticket Link:

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

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

Updated status for this outage may be available at
https://www.fedorastatus.org/


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: F41 Change Proposal: PHP no 32 bit / PHP 64-bit only (self-contained)

[Kevin Fenzi]

On Tue, Mar 12, 2024 at 07:17:23PM +0100, Fabio Valentini wrote:
> 
> I have thought about this when proposing the Change to make dropping
> support for i686 easier. What you suggest is probably not as easy as you
> think - the packages that are required for multilib purposes change over
> time, and in turn the packages that are necessary to *build* those packages
> are also not constant. It would be easy to end up in a situation where some
> packages that are needed on i686 can no longer be built there because they
> start requiring other packages that were already dropped from i686.
> 
> Worst case scenario (if too many things were to be dropped at some point),
> a re-bootstrapping of i686 might be necessary to get things into a working
> state again (and I'm pretty sure at that point we might as well just turn
> it off entirely because it would not be worth the effort).
> 
> I'm hoping that we can get there in a different way: The cases where
> multilib support is actually needed are going away.
> 
> - I think koji now supports a setup where "noarch" packages are never built
> on i686.

Yes. It's enabled on f41/rawhide.
I have not seen any problems reported on it, so perhaps we can just set
it for everything 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: So you can't just copy 'sources' from one package to another?

[Kevin Fenzi]

On Fri, Mar 08, 2024 at 04:19:11PM +, Richard W.M. Jones wrote:
> For mingw-* packages we (sometimes) have a separate package from the
> native package, eg. libgcrypt vs mingw-libgcrypt.  Therefore two
> different packages are sometimes built with the exact same sources.
> 
> However I discovered copying 'sources' (ie the file) from libgcrypt
> dist-git to mingw-libgcrypt dist-git alone isn't sufficient to get the
> package to build.  You still have to download the source tarballs in
> libgcrypt, copy them to mingw-libgcrypt, and 'fedpkg new-sources
> ' to upload them again.
> 
> Isn't the lookaside cache shared across the whole of Fedora?
> 
> (This doesn't matter, I was just wondering aloud.)

Yeah, it's not really designed for easy sharing accross packages. 

It looks up things like: 

https://src.fedoraproject.org/repo/pkgs/rpms

So, since the package name is in there if you just move it the archive
isn't under that and it doesn't work. ;( 

It would likely need a redesign to support that use case sadly.

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: Possible intermittent lost mail from Pagure

[Kevin Fenzi]

On Wed, Mar 06, 2024 at 11:44:51AM +, Richard W.M. Jones wrote:
> I can't quite point to proper evidence, but I have a feeling that
> email notifications are being lost from Pagure.

I'm guessing from below you mean the src.fedoraproject.org instance?
(pagure.io is the other one, so it's best to be clear which one)

> One case where I'm about 90% sure this happened was with:
> 
>   https://src.fedoraproject.org/rpms/ogre/pull-request/3
> 
> where I did not receive the "cc @rjones" email.  I don't think it was
> dropped by spam filters etc.
> 
> I've seen other people complaining about this too, today for instance:
> 
>   https://src.fedoraproject.org/rpms/pcp/pull-request/25#comment-187753

So, src.fedoraproject.org should output fedora-messaging messages and
then notifications acts on those to notify people. 

What settings do you have in https://notifications.fedoraproject.org ?
Also, does this only happen some of the time? or always?

It might be a fmn bug, or something deeper. ;( 

Can you start by filing on fmn:
https://github.com/fedora-infra/fmn/
and we can try and track it down from there?

> On a related subject, pagure does not send out email when someone
> rebases / force pushes to a pull request, which seems like a pretty
> big problem.

I think that might be an upstream pagure issue?
https://pagure.io/pagure

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: libxslxwriter (misspelled package) in zombie state

[Kevin Fenzi]

On Fri, Mar 01, 2024 at 11:49:06AM +, Richard W.M. Jones wrote:
> 
> We were discussing this on IRC, so just to bring the topic up on the
> mailing list ...
> 
> (1) Package libxslxwriter (note: "xslx") with only automated activity
> and no builds:
> https://src.fedoraproject.org/rpms/libxslxwriter/commits/rawhide
> https://koji.fedoraproject.org/koji/packageinfo?packageID=32741
> 
> (2) Package libxlsxwriter (note: "xlsx") which is normal:
> https://src.fedoraproject.org/rpms/libxlsxwriter/commits/rawhide
> https://koji.fedoraproject.org/koji/packageinfo?packageID=32754
> 
> It seems like the first package is in some sort of zombie state?

Yeah, the package owner (or a provenpackager) should just be able to
'fedpkg retire' 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: Login issues to lists.* and src.*? Any outages?

[Kevin Fenzi]

All that said, I have filed:
https://pagure.io/fedora-infrastructure/issue/11799
for us to investigate why it's not properly disabling the unresponsive
nodes and look into the underlying unresponsiveness issue. 

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: Login issues to lists.* and src.*? Any outages?

[Kevin Fenzi]

On Thu, Feb 22, 2024 at 04:46:23PM -0500, Christopher wrote:
> On Thu, Feb 22, 2024 at 4:01 PM Gary Buhrmaster
>  wrote:
> >
> > On Thu, Feb 22, 2024 at 8:20 PM Christopher  
> > wrote:
> > >
> > > Are there any known issues right now for logging in to 
> > > lists.fedoraproject.org or src.fedoraproject.org?
> > > Do we have a page for known outages?
> >
> > https://status.fedoraproject.org/
> >
> > It currently reports all systems operational
> >
> 
> Yeah, I found that after asking. It also says it's updated manually,
> so I'm not sure how reliable it is.

Well, I am not sure how to answer that... if we know about some issue
that affects a lot of people we try and update it. If we don't know
about an issue, we can't know to update it and if the issue is something
that doesn't seem to affect a lot of people or is something we can
quickly fix, we often don't update it.

> > > I can log in to accounts.fedoraproject.org, so I know my password and 2FA 
> > > token still works, but not to src.f.o or lists.f.o.
> > > I tried to disable my 2FA in there, to see if that had an effect, but it 
> > > wouldn't let me (I thought it was optional?)

What happens when you try and login?
Hangs? an error? a timeout? 

We have had one of our identity provider vm's from time to time stop
responding to requests (although it responds to liveness checks). 
This might be a case of that if you see it timeout.
I just checked and they are both up and working now... are you still
seeing this?

> > Enrolling in 2FA is a one-way action
> > (like Hotel California, you can never leave).

You can actually, but you have to mail ad...@fedoraproject.org, use some
method to prove you are you and then your token can be removed. 

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

koji news and 1.34.0 upgrade

[Kevin Fenzi]

Greetings. After the outage that just completed, koji has been upgraded
to 1.34.0 plus a few patches from upstream. Some highlights:

* The scheduler has been redone completely, hopefully this will allow
for more complex scheduling adjustments. In the mean time it should be
pretty similar from the perspective of when builds are picked up, etc.
You may see the 'assigned' state more often as the hub assigns builds.

* A patch has been added allowing us to set 'noarch_arches' on build
tags. This allows us to specify what arch builders will do noarch
builds. Without any setting it's any arch, but this presents problems
for noarch packages that have some dependencies that have dropped i686.
For f41 / rawhide, this has been set to "aarch64 x86_64 ppc64le s390x"
(ie, excluding i686). If this works well we can extend it to other build
tags. 

* The kiwi plugin has been enabled (although we still need to create
some build tags and groups to fully enable it). 

* image builds now don't pass units in size requests (allowing the
underlying image tool to decide if 1 is 1G or 1GiB.

* Unrelated to the koji upgrade, the s390x builders have been
reinstalled on a new mainframe. The new hardware is faster, the new
builders have more memory and disk space and the network to this
datacenter is much faster. Currently we have allocated fewer 'larger'
builders, but if they cannot handle the volume of builds we may
rebalance them into more smaller instances.

As well as all the upstream changes:
https://docs.pagure.org/koji/release_notes/release_notes_1.34/

Please report any problems to the infrastructure issue tracker:
https://pagure.io/fedora-infrastructure

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

koji news and 1.34.0 upgrade

[Kevin Fenzi]

Greetings. After the outage that just completed, koji has been upgraded
to 1.34.0 plus a few patches from upstream. Some highlights:

* The scheduler has been redone completely, hopefully this will allow
for more complex scheduling adjustments. In the mean time it should be
pretty similar from the perspective of when builds are picked up, etc.
You may see the 'assigned' state more often as the hub assigns builds.

* A patch has been added allowing us to set 'noarch_arches' on build
tags. This allows us to specify what arch builders will do noarch
builds. Without any setting it's any arch, but this presents problems
for noarch packages that have some dependencies that have dropped i686.
For f41 / rawhide, this has been set to "aarch64 x86_64 ppc64le s390x"
(ie, excluding i686). If this works well we can extend it to other build
tags. 

* The kiwi plugin has been enabled (although we still need to create
some build tags and groups to fully enable it). 

* image builds now don't pass units in size requests (allowing the
underlying image tool to decide if 1 is 1G or 1GiB.

* Unrelated to the koji upgrade, the s390x builders have been
reinstalled on a new mainframe. The new hardware is faster, the new
builders have more memory and disk space and the network to this
datacenter is much faster. Currently we have allocated fewer 'larger'
builders, but if they cannot handle the volume of builds we may
rebalance them into more smaller instances.

As well as all the upstream changes:
https://docs.pagure.org/koji/release_notes/release_notes_1.34/

Please report any problems to the infrastructure issue tracker:
https://pagure.io/fedora-infrastructure

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

[Kevin Fenzi]

On Wed, Feb 21, 2024 at 04:43:26PM +0100, Miro Hrončok wrote:
> NOTE: This was not sent to individual maintainers, as @fedoraproject.org
> aliases are currently broken
> https://pagure.io/fedora-infrastructure/issue/11768

(Side note: This should now be fixed)

kevin


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

Re: The semiannual "Transaction failed: Signature verification failed." exercise

[Kevin Fenzi]

On Sun, Feb 18, 2024 at 12:32:45PM +, Zbigniew Jędrzejewski-Szmek wrote:
> 
> Oh, OK. So it was a misunderstanding on my side. I thought that since e.g. F41
> has a bunch of packages taken from F40 and F39 and earlier, they will be 
> signed
> by those respective keys. But we resign them, so they are not. (To make this
> more confusing, on upgraded systems if the package version didn't change,
> and it doesn't if the package isn't rebuilt, we have the old package signed
> by the old key, while an "identical" package on a newer install will be signed
> by a newer key. But that's all OK, once you know about the resigning.)

Yeah... 

> I meant that F_40_ installations don't allow the F41 key. (F41/rawhide 
> installations
> allow both, that is fine.)  But now I understand that F40 will get packages
> signed by the F40 key, and F41/rawhide will get resigned packages. So all is 
> OK.
> 
> > > 3. If F42 key has already been generated, why isn't it distributed in
> > >distribution-gpg-keys already, to make it well known and make the
> > >transition easier in the future?
> > 
> > It should have been. I am not sure where the process failed. 
> > 
> > I did generate the fedora-42 key.
> 
> Right. The key is there, and even distribution-gpg-keys package has in on F39.
> 
> So I think the whole issue can be solved by letting tools use
> two keys for rawhide. The patch for mkosi was merged [1].
> Should we do something similar for mock?
> 
> [1] 
> https://github.com/systemd/mkosi/commit/f221562c945a48db9384f8521f67b9b02cd71ac1

I think that would help a good bit if we can. 

I do see logic there to use rawhide and rawhide-1, but I think it needs
rawhide+1 also (at least around branching time)?

Can someone file a mock bug/pr?

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 - koji upgrade - 2024-02-21 21:00 UTC

[Kevin Fenzi]

Planned Outage - koji upgrade - 2024-02-21 21:00 UTC

There will be an outage starting at 2024-02-21 21:00 UTC,
which will last approximately 3 hours.

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

date -d '2024-02-21 21:00UTC'

Reason for outage:

koji will be upgraded to 1.34.0, which requires a schema update that touches 
many rows.
We estimate this will take about 45minutes to complete and during that time,
koji will be completely offline.

Package maintainers are advised to not start any long term builds before the 
outage.

Affected Services:

koji
bodhi

Ticket Link:

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

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

Updated status for this outage may be available at
https://www.fedorastatus.org/


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 - koji upgrade - 2024-02-21 21:00 UTC

[Kevin Fenzi]

Planned Outage - koji upgrade - 2024-02-21 21:00 UTC

There will be an outage starting at 2024-02-21 21:00 UTC,
which will last approximately 3 hours.

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

date -d '2024-02-21 21:00UTC'

Reason for outage:

koji will be upgraded to 1.34.0, which requires a schema update that touches 
many rows.
We estimate this will take about 45minutes to complete and during that time,
koji will be completely offline.

Package maintainers are advised to not start any long term builds before the 
outage.

Affected Services:

koji
bodhi

Ticket Link:

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

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

Updated status for this outage may be available at
https://www.fedorastatus.org/


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: The semiannual "Transaction failed: Signature verification failed." exercise

[Kevin Fenzi]

On Fri, Feb 16, 2024 at 09:37:25AM -0800, Kevin Fenzi wrote:
...snip...
> 
> It should have been. I am not sure where the process failed. 
> 
> I did generate the fedora-42 key. 

FYI, I was lacking coffee or something. 
it's there in the rawhide fedora-repos:

https://src.fedoraproject.org/rpms/fedora-repos/c/d10a092adbcf0e0b2d7e4f05311255c805c878b5?branch=rawhide

Needs updating in other places though.

kevin


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

Re: The semiannual "Transaction failed: Signature verification failed." exercise

[Kevin Fenzi]

On Fri, Feb 16, 2024 at 11:12:07AM +, Zbigniew Jędrzejewski-Szmek wrote:
> On Thu, Feb 15, 2024 at 06:03:59PM -0800, Kevin Fenzi wrote:
> > That won't do it. We need mock to update it's config at exactly the same
> > moment a successfull rawhide compose completes and mirrors to whatever
> > mirror you are hitting. ;( 
> > 
> > We make keys a year ahead now. The f42 key is in fedora-release already.
> 
> Oh, I didn't know that. I see that I have
> /usr/share/distribution-gpg-keys/fedora/RPM-GPG-KEY-fedora-40-primary
> /usr/share/distribution-gpg-keys/fedora/RPM-GPG-KEY-fedora-41-primary
> on both my F39 and ~rawhide systems.

yes. The 42 one should have been added too... not sure why it didn't
land. ;( 

> This means that both keys are on the system, it's just a matter of
> pointing dnf/other tools at them.

Yes. Looking more I think we just need mock to list both the current
one and the next one.

fedora-repos already does this and I think dnf/dfn5 honor it.

> But let's not talk about mock, let's talk about mkosi.

ok

> In my earlier message I quoted this case:
> 
> > [1] From 
> > https://github.com/systemd/systemd/actions/runs/7919159325/job/21619276641?pr=31338:
> >
> > Running transaction
> > Importing PGP key 0xA15B79CC:
> >  Userid : "Fedora (40) "
> >  Fingerprint: 115DF9AEF857853EE8445D0A0727707EA15B79CC
> >  From   : 
> > file:///usr/share/distribution-gpg-keys/fedora/RPM-GPG-KEY-fedora-rawhide-primary
> > The key was successfully imported.
> >
> > Transaction failed: Signature verification failed.
> > PGP check for package "filesystem-3.18-8.fc40.x86_64"
> > (/var/cache/libdnf5/fedora-306b6523e9c8dc02/packages/filesystem-3.18-8.fc40.x86_64.rpm)
> >  from
> > repo "fedora" has failed: Import of the key didn't help, wrong key?
> 
> /usr/share/distribution-gpg-keys/fedora/RPM-GPG-KEY-fedora-rawhide-primary
> points to RPM-GPG-KEY-fedora-40-primary.
> So everythould be fine, no? filesystem-3.18-8.fc40.x86_64 is clearly an F40
> package, so it should be signed with the RPM-GPG-KEY-fedora-40-primary key.

Not really no. 

When we branch, the branched release gets all the already signed by
fedora-40 key packages. Rawhide is completely re-signed with the new
fedora-41 key. The dist tag of packages has nothing to do with it. 

So, day X, rawhide is all signed by fedora-40 key. 
Day X+1 we branch and get a new rawhide compose and all rawhide is
signed by the fedora-41 key.

> But it has
> "Signature   : RSA/SHA256, Fri 09 Feb 2024 01:30:23 PM CET, Key ID 
> d0622462e99d6ad1"
> which is RPM-GPG-KEY-fedora-41-primary.
> 
> This actually raises a bunch of questions:
> 1. Why is the .f40 package signed with the F41 key?

Because it's composed in rawhide. That same package composed in branched
composes _is_ signed by the fedora-40 key.

> 2. How does this even work later on? Wouldn't F40 installations refuse
>packages signed with the F41 key?

refuse where? dnf/dnf5 use the line in fedora-rawhide.repo that lists
Both keys.

> 3. If F42 key has already been generated, why isn't it distributed in
>distribution-gpg-keys already, to make it well known and make the
>transition easier in the future?

It should have been. I am not sure where the process failed. 

I did generate the fedora-42 key. 

> and also:
> 
> 4. https://fedoraproject.org/fedora.gpg contains keys for F35, F36, F37, F38, 
> F38, F40.
>Why not F41 and F42?

Yes, it should be added. 

> For mkosi specifically, I guess could try to import also the "next" key
> when configuring rawhide installs, but I'd like to first understand why
> the packages are signed with the F41 key.

See above, happy to expand or try better to explain.

kevin


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

Re: The semiannual "Transaction failed: Signature verification failed." exercise

[Kevin Fenzi]

On Fri, Feb 16, 2024 at 09:46:05AM +0100, Vít Ondruch wrote:
> 
> 
> Other solution could be if Rawhide lived in rawhide repos instead of f41.

I'm not sure I follow... rawhide is in a rawhide repo?

pub/fedora/linux/development/rawhide/

Or did you mean to sign rawhide with a 'rawhide' key always that never
changes? Thats an option, but then there's no regular key rotation...

kevin


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

Re: The semiannual "Transaction failed: Signature verification failed." exercise

[Kevin Fenzi]

On Thu, Feb 15, 2024 at 07:57:37PM +, Zbigniew Jędrzejewski-Szmek wrote:
> It's this time of the year again:
...
> 
> Could we please do something so that this doesn't happen?
> Dunno, generate and distribute the keys earlier so that mock
> and https://fedoraproject.org/fedora.gpg get updated _before_
> we need it?

That won't do it. We need mock to update it's config at exactly the same
moment a successfull rawhide compose completes and mirrors to whatever
mirror you are hitting. ;( 

We make keys a year ahead now. The f42 key is in fedora-release already.

> I know this subject comes up approx. twice a year (or once once for F21 ;) ),
> e.g. [2]. I know this can be "fixed" with some manual steps, but I posit
> that this should never occur in the first place.

I guess one possible solution would be for rpm to support multiple
signatures and koji to support writing out those rpms and then we could
sign new rawhide with both keys at least for a while. 

I guess I had that idea 7 years ago:
https://github.com/rpm-software-management/rpm/issues/189

Or I suppose we could move to just one key for everything, but then it
would have a larger effect if we ever had to revoke/reissue. 

At the very least, perhaps mock could try and identify this problem and
note to upgrade mock-core-configs?

Dunno. I agree it's not good, but it's not easy to solve either. 

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 Monday's FESCo Meeting (2024-02-12)

[Kevin Fenzi]

On Tue, Feb 13, 2024 at 02:57:15AM +0100, Kevin Kofler via devel wrote:
> Stephen Gallagher wrote:
> > Meeting summary
> 
> Do we have the full log somewhere?

html:

https://meetbot.fedoraproject.org/meeting_matrix_fedoraproject-org/2024-02-12/fesco.2024-02-12-19.30.log.html

plain text:

https://meetbot-raw.fedoraproject.org//meeting_matrix_fedoraproject-org/2024-02-12/fesco.2024-02-12-19.30.log.txt

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: FYI: removal of bastion server in DNSBL spam.dnsbl.anonmails.de requested

[Kevin Fenzi]

On Mon, Feb 12, 2024 at 09:04:25AM -0500, Stephen Smoogen wrote:
> On Mon, 12 Feb 2024 at 06:12, Marius Schwarz  wrote:
> 
> > Hi,
> >
> > as die Infrastructure ML did not react ( or could not react ;) ), I
> > requested the removal at that antispam blacklist.
> >
> >
> I did not see any email to the infrastructure list about this so I am
> wondering if your email (and other emails) have gotten trashed? Did you
> open a ticket on this at https://pagure.io/fedora-infrastructure/ already?
> There is another email issue that was listed there earlier today but I
> don't know if they are related.

I didn't see any emails on this subject either but it sounds like it
got addressed somehow anyhow?

But yes, always open a ticket if you want something addressed... I try
and watch lists and such for issues, but I could easily miss something.

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: just to let you know FESCo agreed to a preliminary injunction while we consider this issue

[Kevin Fenzi]

On Thu, Feb 08, 2024 at 08:43:52PM +0100, Fabio Valentini wrote:
> 
> One thing that seems to be overlooked in many of the posts on this thread:
> 
> Nobody can *force* the KDE Plasma maintainers to do *anything*, just
> like nobody can force *any* packager to do anything. Fedora a
> volunteer-run project. We're mostly doing this "for fun" (or at least,
> some definition of "fun"). So if the KDE Plasma maintainers / the KDE
> SIG decides that they do not want to keep supporting the Plasma / X11
> session, that is their choice. However, I am not sure whether I like
> it or not that there's an ongoing effort to add this functionality
> back with separate packages.
> 
> For me, the only acceptable way to do this would be in a way that does
> in no way make maintaining the Plasma / Wayland packages more
> difficult or burdensome, since the original intent of dropping the
> Plasma / X11 session was to *lower* the maintenance burden. Adding
> back the Plasma / X11 session with separate packages might cause
> additional overhead for the KDE SIG (for example, needing to update
> kwin-x11 whenever there is a kwin update). That would be the "usual"
> way to handle this according to Fedora policies.
> 
> However, that would be counter to the original purpose of dropping the
> functionality from the packages maintained by the KDE SIG. But again,
> nobody can *force* package maintainers to support something they don't
> want to support. So in this case, I think it would be good to have
> something like a clarification to the Updates Policy (and / or other
> policies, as necessary) for this case to resolve the contradiction -
> something like "updates for KDE Plasma packages are not required to be
> coordinated with packages for the Plasma / X11 session".
> 
> I'm also unsure how handling bug reports would best work in this
> situation. People *will* report bugs against the wrong components,
> causing additional work for the KDE SIG. (Hell, I'm getting bug
> reports filed against elementary / Pantheon packages, and there's not
> even a usable Pantheon session in Fedora yet!)

Yeah. So, what advantages are there to this being in the main fedora
collection of packages over just in a copr?

I suppose with official packages you get bugzilla for bugs?
Although copr's get discussion threads that many people use that way.

kevin


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

Planned Outage - server updates - 2024-02-07 22:00 UTC

[Kevin Fenzi]

There will be an outage starting at 2024-02-07 22:00UTC,
which will last approximately 6 hours.

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

date -d '2024-02-07 22:00UTC'

Reason for outage:

We will be applying updates and rebooting servers. No one service should be 
down long, but may be up and down in the outage window.
Additionally, as time permits we will be doing the following additional work:

- resizing disks on database servers

- moving some database servers to rhel9 and newer postgresql

- applying some firmware updates

Affected Services:

Most services will be affected for a short time, but end user facing services 
(mirrorlists, websites) should not be affected.

Ticket Link:

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

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

Updated status for this outage may be available at
https://www.fedorastatus.org/


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 - server updates - 2024-02-07 22:00 UTC

[Kevin Fenzi]

There will be an outage starting at 2024-02-07 22:00UTC,
which will last approximately 6 hours.

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

date -d '2024-02-07 22:00UTC'

Reason for outage:

We will be applying updates and rebooting servers. No one service should be 
down long, but may be up and down in the outage window.
Additionally, as time permits we will be doing the following additional work:

- resizing disks on database servers

- moving some database servers to rhel9 and newer postgresql

- applying some firmware updates

Affected Services:

Most services will be affected for a short time, but end user facing services 
(mirrorlists, websites) should not be affected.

Ticket Link:

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

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

Updated status for this outage may be available at
https://www.fedorastatus.org/


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: Re: Re: A reminder: you cannot just "revert" package version bumps

[Kevin Fenzi]

On Thu, Feb 01, 2024 at 02:51:54AM +0100, Kevin Kofler via devel wrote:
> kevin wrote:
> > distro-sync is nice and all, but it's not a silver bullet.
> > In cases of simple packages a downgrade may not break anything, but in
> > cases where other things already built upon it, where the new one
> > changed conguration or interface, or even where the upgrade changed
> > data, it can leave things in a pretty unfortunate state.
> 
> And the proposed "solution" of bumping Epoch fixes none of that. It just 
> introduces an Epoch that we will be stuck with forever. It will not 
> magically make the downgrade safe in any of the 3 situations you describe.

I am unsure when I proposed Epoch's. I'm not a great fan of them either.
In addition to what you mentioned, Epochs have another problem:
Depending on how dependent packages (build)require your package, they
must be adjusted for the new Epoch too.

Anyhow, to be more clear: 

I don't think we can or should say "just downgrade whenever you like",
unless/until dnf5 gets rid of update and only has distro-sync.
Nor do I think we should rush to using Epochs. In rare cases we should
go back to older versions, but it should be a discussion and other
alternatives should all be exhausted first (patch the problem and push a
newer update, push a revert of the problematic part, engage with
upstream for a solution, 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

Re: Re: Are package-owner mail addresses working?

[Kevin Fenzi]

On Wed, Jan 03, 2024 at 09:59:23AM -0500, Stephen Gallagher wrote:
> On Wed, Jan 3, 2024 at 8:15 AM Sergio Pascual  wrote:
> >
> > El lun, 1 ene 2024 a las 13:49, Mamoru TASAKA
> > () escribió:
> > >
> > > Sergio Pascual wrote on 2024/01/01 21:36:
> > > > Hello and happy new year.
> > > >
> > > > Are package-owner mail addresses working? I have send mails to several
> > > > and they return a 550 error message, for example:
> > > >
> > > > 550 5.1.1 : Recipient address
> > > > rejected: User unknown in local recipient table
> > > >
> > > > Best, Sergio
> > > > --
> > >
> > > Currently it is -maintain...@fedoraproject.org :
> > >
> > > https://fedoraproject.org/wiki/EmailAliases
> > >
> >
> > Great, thank you. In that case, the "senmail.to" property in the rpm
> > git repositories should be updated to point to the correct address. I
> > have checked several repositories and all have -owner addresses there.
> >
> > For example:
> >
> > $ git config sendemail.to
> > cfitsio-ow...@fedoraproject.org
> >
> 
> 
> Please file a report with Fedora Infrastructure at
> https://pagure.io/fedora-infrastructure/new_issue

This is actually set in fedpkg (or perhaps rpkg?).

So, best to file it there and get it fixed 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: Creation of new package repo failed, Invalid or expired token

[Kevin Fenzi]

On Tue, Dec 12, 2023 at 11:14:03AM -, Felix Wang wrote:
> I opened an releng issue about this. [1] At the time of writing, I noticed 
> that there is probably an similar issue of failure of package creation 
> appeared. [2] Hope anyone can help me solve the problem, which maybe the 
> cause of my personal issue, or other factors. Thanks in advance.
> 
> [1] https://pagure.io/releng/issue/11829
> [2] https://pagure.io/releng/fedora-scm-requests/issue/58752

Just to note, this was all taken care shortly after you opened the
tickets. :) 

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: Proven to be sickened

[Kevin Fenzi]

On Mon, Dec 11, 2023 at 08:28:31AM -0500, Stephen Gallagher wrote:
> 
> While I generally agree that a merge request is a more polite and
> elegant solution, if a package is listed as FTBFS (having had a bug
> automatically opened) and some reasonable amount of time (two, three
> weeks?) has passed, then I think it's perfectly reasonable to assume
> that the maintainer is vacant (either entirely or because they lack
> the available time to deal with it at this point). In that case, I
> don't see it as a problem to jump in and fix the package as a
> provenpackager if the fix is relatively minor (yes, this is
> subjective). I'd hesitate at rebasing to a new version, but if the
> issue is that a dependency changed its name or the newest gcc made a
> warning into an error, I think that's a perfectly acceptable fix to
> make. The ideal case is for it to go through a merge request, but if
> the package happens to be blocking other work, I think expediency is
> completely warranted.

I think the key here is that everyone needs to make sure and communicate
with others. 

If there's a FTBFS bugzilla bug and you are working on a good fix with
upstream, say so in the bug. If you are a provenpackager and you need to
fix a FTBFS quickly for some reason, look at the bug, if you see the
maintainer(s) mentioning they were working on it, ask in bug if you
could push a quick fix now and explain why you need it. Use good commit
messages. "Fix FTBFS" is not a good commit message, "Fix FTBFS with a
quick fix to xyz because we need to rebuild the package for rebuild of
package X, this may not be the final fix". Use the
packagename-maintainers aliases and notify when you are doing things. 
Even if everyone doesn't have time to react to communications, just
making the effort helps everyone know what happened and whats going 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: Fedora Review Service and setting the AutomationTriaged keyword

[Kevin Fenzi]

Thanks for working on this Jakub. I think it's quite useful. :)

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 we retire the mailx package?

[Kevin Fenzi]

I'm definitely in favor. I hit this broken step a while back myself. ;( 

Hopefully the current maintainers are on board with 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: Synching user database from Fedora IPA to pagure

[Kevin Fenzi]

On Tue, Nov 28, 2023 at 10:13:35AM +, Mattia Verga via devel wrote:
> I'd like to start writing a script to synch users/groups from Fedora IPA 
> to pagure.io and src.fp.o: both pagure.io and src.fp.o logins are based 
> on Fedora accounts, but the Pagure user database is only updated when a 
> user login in Pagure.

Yeah, there was a script for fas2:
https://pagure.io/pagure-utility/blob/master/f/sync_fas_group_membership.py
But I guess that would need to be ported to current.

> That means that by searching for a user or looking group memberships in 
> Pagure we don't have an updated, real view of what we have in IPA. With 
> the old FAS system there used to be a synch script provided by 
> pagure-dist-git plugin, so I plan to use that as the base for a new 
> synch script from IPA.
> 
> However, before digging in how (and if) is possible to add new users 
> using pagure libraries, I'd like to ask if it would be acceptable to 
> "copy" user data from one database to another (except passwords, which 
> remain in IPA only). We will need to pass username, full name, email and 
> group memberships from IPA to pagure.io/src.fp.o, which is what is done 
> when a user logs in for the first time.
> 
> If that's not acceptable, I think I can just only update group 
> membership for users already in pagure database.
> 
> Thoughts?

There was some renewed interest in syncing things not long ago, at least
for pagure.io groups. See: 

https://pagure.io/fedora-infra/toddlers/issue/177

Note that that needs a upstream pending pr to be merged, a new release
cut and us to update to it to get the api endpoint.

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

[Kevin Fenzi]

Also... if you meant the scm-commits mailing list, then yeah, that is broken
currently. ;( 

https://github.com/fedora-infra/fmn/issues/1024

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

[Kevin Fenzi]

On Sun, Nov 19, 2023 at 03:13:21PM -0500, Stephen Smoogen wrote:
> It could be due to the retirement of the old notifications system earlier
> this month. See the email "intent to retire: fedmsg-irc, old fmn, osbs"
> sent to the mailing list earlier.
> 
> FMN is the tool which sends notifications and it was replaced with a newer
> version earlier this year. Here is the April announcement:

Right. 

koschei isn't supported yet in the new application: 
https://github.com/fedora-infra/fmn/issues/915
:(

src commits should work fine, but you need to set up that you want
them in the new application: 
https://notifications.fedoraproject.org/

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 packages removed from packager group

[Kevin Fenzi]

On Mon, Nov 20, 2023 at 08:27:47AM +1100, Arthur G wrote:
> I recall a number of years back a proposed gcc upgrade broke many builds.
> This required most maintainers to log in and refactor their source code
> against the new gcc (and new gcc options).
> 
> I hadn't logged into Fedora for years however I did do my due diligence and
> rather quickly logged in and fixed any issues.
> 
> The recent move to remove inactive maintainers from the maintainers group
> is something I fully agree with for reasons of security against the current
> limitations of the maintainer privileges framework.
> 
> However, this latest move to orphan packages that don't have maintainers
> seems rather clandestine as it's not related to security but rather a
> byproduct of the point mentioned above. If security wasn't an issue in the
> first place then we wouldn't be having this discussion.

I'm not sure if I follow here. The reason the packages are orphaned is
because the maintainers were removed from the packager group. We can't
just leave them there as it would mean bugs would still be assigned to
them and they would be unable to actually push any changes or do
anything with the package(s).

> I wonder what spectacle will ensue should we ever need to refactor the
> source code again for extraneous reasons only to find a significant part of
> the maintainer cohort needs to go through the proven maintainer process
> again.

Well, active maintainers should be the ones to do this... so as long as
we have those...

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 packages removed from packager group

[Kevin Fenzi]

On Sun, Nov 19, 2023 at 06:34:39PM +, Richard W.M. Jones wrote:
> On Sun, Nov 19, 2023 at 08:33:02AM +, Mattia Verga via devel wrote:
> > rpms/cairo
> > rpms/createrepo_c
> > rpms/desktop-backgrounds
> > rpms/ed
> > rpms/libcap
> > rpms/vim
> 
> Just noting that these packages seem to be very important, yet not
> volunteering to take them ...

They are all assigned now. I think it all cases here it was 'main admin
is not around anymore and one of the co-maintainers has been maintaining
it for a long while'. 

I suppose we could try and do something better than orphaning them, but
not sure what. If we just reassigned to another co-maintainer, we could
get another inactive one. I suppose we could try and see which
co-maintainer last committed to it... 

> > rpms/libldm
> 
> I thought I was already doing this one, since I semi-maintain it
> upstream already.  I'd like to comaintainer it, but I totally can't
> find the right button in the UI ...

Email the main admin to add you.

...snip...

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

Inactive packages removed from packager group

[Kevin Fenzi]

Hi all,

Today, 2023-11-18, we have removed inactive packagers
from the packager group.

This is in accordance with the FESCo policy on inactive packagers:
https://docs.fedoraproject.org/en-US/fesco/Policy_for_inactive_packagers/

If the removed user is 'main admin' for a package, this package
will be orphaned. If there are co-maintainers for the package,
one of them should take the role of 'main admin',
by clicking "✋ Take" on
`https://src.fedoraproject.org/rpms/`".

Otherwise any packager may take the package while it's orphaned.
After 6 weeks, the package will be retired.
After another 8 weeks, a new review is needed to unretire it.
see 
https://docs.fedoraproject.org/en-US/fesco/Policy_for_orphan_and_retired_packages/
for more details.

More details available in https://pagure.io/fedora-infrastructure/issue/11621

Packages that have been orphaned are:

rpms/gtksourceview5
rpms/python-typing-inspect
rpms/xorg-x11-drv-qxl
rpms/coin-or-lemon
rpms/fish
rpms/nvme-cli
rpms/u2f-hidraw-policy
rpms/virtme
rpms/elementary-onboarding
rpms/vala-language-server
rpms/perl-MooseX-Role-Matcher
rpms/perl-Net-Google-AuthSub
rpms/drupal7-advanced_help
rpms/drupal7-auto_nodetitle
rpms/drupal7-calendar
rpms/drupal7-ckeditor
rpms/drupal7-date_ical
rpms/drupal7-email
rpms/drupal7-features
rpms/drupal7-feeds
rpms/drupal7-flexifilter
rpms/drupal7-footnotes
rpms/drupal7-google_analytics
rpms/drupal7-honeypot
rpms/drupal7-job_scheduler
rpms/drupal7-mediawiki_api
rpms/drupal7-module_filter
rpms/drupal7-panels
rpms/drupal7-pathauto
rpms/drupal7-rules
rpms/drupal7-site_map
rpms/drupal7-strongarm
rpms/drupal7-theme-adaptivetheme
rpms/drupal7-token
rpms/drupal7-views_bulk_operations
rpms/drupal7-views_slideshow
rpms/drupal7-webform
rpms/drupal7-workbench
rpms/drupal7-workbench_moderation
rpms/drupal7-xmlsitemap
rpms/python-ironicclient
rpms/qtractor
rpms/rtirq
rpms/dropbear
rpms/byzanz
rpms/cairo
rpms/golang-github-elithrar-simple-scrypt
rpms/golang-github-kurin-blazer
rpms/golang-github-minio
rpms/golang-github-pkg-xattr
rpms/golang-github-restic-chunker
rpms/restic
rpms/aspell-ar
rpms/aspell-he
rpms/bidiv
rpms/hspell
rpms/hunspell-ar
rpms/python-pthreading
rpms/taarich
rpms/tex-fonts-hebrew
rpms/golang-rsc-pdf
rpms/wavbreaker
rpms/python-timeunit
rpms/python-vagrantpy
rpms/streamtuner
rpms/bird
rpms/ovirt-guest-agent
rpms/vsqlite++
rpms/dovecot-fts-xapian
rpms/VirtualGL
rpms/python-autograd
rpms/python-read-roi
rpms/byobu
rpms/kflickr
rpms/nfacct
rpms/perl-Audio-Beep
rpms/perl-CDDB
rpms/perl-Getopt-Simple
rpms/perl-NetPacket-LLC
rpms/perl-NetPacket-SpanningTree
rpms/perl-Pod-Coverage-Moose
rpms/perl-Proc-Simple
rpms/perl-XML-Parser-Lite-Tree-XPath
rpms/rust-atomic
rpms/rust-binascii
rpms/rust-cfb
rpms/rust-email-encoding
rpms/rust-infer
rpms/rust-inlinable_string
rpms/rust-multer
rpms/rust-rmpv
rpms/rust-serde_qs
rpms/rust-totp-lite
rpms/rust-ubyte
container/glusterfs
rpms/python-oslo-vmware
rpms/perl-Hash-Diff
rpms/perl-Test-Script-Run
rpms/esc
rpms/bash-completion-extras
rpms/apiextractor
rpms/appmenu-qt
rpms/arora
rpms/beefy-miracle-kde-theme
rpms/bluedevil
rpms/cagibi
rpms/colord-kde
rpms/constantine-kde-theme
rpms/dogtail
rpms/generatorrunner
rpms/goddard-kde-theme
rpms/herqq
rpms/jovie
rpms/kaccessible
rpms/kde-plasma-ihatethecashew
rpms/kio-ftps
rpms/kmag
rpms/kmousetool
rpms/kmouth
rpms/ktp-accounts-kcm
rpms/ktp-approver
rpms/ktp-auth-handler
rpms/ktp-common-internals
rpms/ktp-contact-list
rpms/ktp-filetransfer-handler
rpms/ktp-kded-integration-module
rpms/ktp-send-file
rpms/ktp-text-ui
rpms/kvkbd
rpms/laughlin-kde-theme
rpms/leonidas-kde-theme
rpms/libkcddb
rpms/libkcompactdisc
rpms/lovelock-kde-theme
rpms/pairs
rpms/plasma-widget-menubar
rpms/polkit-kde
rpms/prison
rpms/pyside-tools
rpms/python-pyside
rpms/qt-at-spi
rpms/qtsoap
rpms/shiboken
rpms/solar-kde-theme
rpms/telepathy-qt
rpms/verne-kde-theme
rpms/gogoc
rpms/lua-argparse
rpms/ibutils
rpms/keychecker
rpms/mediawiki-SpecialInterwiki
rpms/multitail
rpms/supybot-koji
rpms/trace-gui
modules/X11-base
modules/cloud-init
modules/dhcp
modules/networking-base
modules/shared-userspace
modules/storage-devices
rpms/dictd
rpms/ed
rpms/libcap
rpms/vim
rpms/cutter
rpms/groonga
rpms/groonga-normalizer-mysql
rpms/sentencepiece
rpms/salt
rpms/boinc-client
rpms/glue-validator
rpms/lcg-infosites
rpms/nagios-plugins-bdii
rpms/icaro
rpms/legofy
rpms/pg_view
rpms/zeek
rpms/gnome-video-arcade
rpms/pygtksourceview
rpms/python-etcd
rpms/libldm
rpms/golang-github-mattetti-filebuffer
rpms/golang-github-vividcortex-mysqlerr
rpms/golang-xorm
rpms/fbf-mukti-fonts
rpms/uniol-fonts
rpms/pg_auto_failover
rpms/fontopia
rpms/gball
rpms/gnudos
rpms/gosnake
rpms/layla-fonts
rpms/shaman
rpms/tcalc
rpms/beefy-miracle-backgrounds
rpms/constantine-backgrounds
rpms/desktop-backgrounds
rpms/echo-artist
rpms/f21-backgrounds
rpms/f22-backgrounds
rpms/gears-backgrounds
rpms/goddard-backgrounds
rpms/gtk-murrine-engine
rpms/heisenbug-backgrounds
rpms/laughlin-backgrounds
rpms/leonidas-backgrounds
rpms/libass

Inactive packages removed from packager group

[Kevin Fenzi]

Hi all,

Today, 2023-11-18, we have removed inactive packagers
from the packager group.

This is in accordance with the FESCo policy on inactive packagers:
https://docs.fedoraproject.org/en-US/fesco/Policy_for_inactive_packagers/

If the removed user is 'main admin' for a package, this package
will be orphaned. If there are co-maintainers for the package,
one of them should take the role of 'main admin',
by clicking "✋ Take" on
`https://src.fedoraproject.org/rpms/`".

Otherwise any packager may take the package while it's orphaned.
After 6 weeks, the package will be retired.
After another 8 weeks, a new review is needed to unretire it.
see 
https://docs.fedoraproject.org/en-US/fesco/Policy_for_orphan_and_retired_packages/
for more details.

More details available in https://pagure.io/fedora-infrastructure/issue/11621

Packages that have been orphaned are:

rpms/gtksourceview5
rpms/python-typing-inspect
rpms/xorg-x11-drv-qxl
rpms/coin-or-lemon
rpms/fish
rpms/nvme-cli
rpms/u2f-hidraw-policy
rpms/virtme
rpms/elementary-onboarding
rpms/vala-language-server
rpms/perl-MooseX-Role-Matcher
rpms/perl-Net-Google-AuthSub
rpms/drupal7-advanced_help
rpms/drupal7-auto_nodetitle
rpms/drupal7-calendar
rpms/drupal7-ckeditor
rpms/drupal7-date_ical
rpms/drupal7-email
rpms/drupal7-features
rpms/drupal7-feeds
rpms/drupal7-flexifilter
rpms/drupal7-footnotes
rpms/drupal7-google_analytics
rpms/drupal7-honeypot
rpms/drupal7-job_scheduler
rpms/drupal7-mediawiki_api
rpms/drupal7-module_filter
rpms/drupal7-panels
rpms/drupal7-pathauto
rpms/drupal7-rules
rpms/drupal7-site_map
rpms/drupal7-strongarm
rpms/drupal7-theme-adaptivetheme
rpms/drupal7-token
rpms/drupal7-views_bulk_operations
rpms/drupal7-views_slideshow
rpms/drupal7-webform
rpms/drupal7-workbench
rpms/drupal7-workbench_moderation
rpms/drupal7-xmlsitemap
rpms/python-ironicclient
rpms/qtractor
rpms/rtirq
rpms/dropbear
rpms/byzanz
rpms/cairo
rpms/golang-github-elithrar-simple-scrypt
rpms/golang-github-kurin-blazer
rpms/golang-github-minio
rpms/golang-github-pkg-xattr
rpms/golang-github-restic-chunker
rpms/restic
rpms/aspell-ar
rpms/aspell-he
rpms/bidiv
rpms/hspell
rpms/hunspell-ar
rpms/python-pthreading
rpms/taarich
rpms/tex-fonts-hebrew
rpms/golang-rsc-pdf
rpms/wavbreaker
rpms/python-timeunit
rpms/python-vagrantpy
rpms/streamtuner
rpms/bird
rpms/ovirt-guest-agent
rpms/vsqlite++
rpms/dovecot-fts-xapian
rpms/VirtualGL
rpms/python-autograd
rpms/python-read-roi
rpms/byobu
rpms/kflickr
rpms/nfacct
rpms/perl-Audio-Beep
rpms/perl-CDDB
rpms/perl-Getopt-Simple
rpms/perl-NetPacket-LLC
rpms/perl-NetPacket-SpanningTree
rpms/perl-Pod-Coverage-Moose
rpms/perl-Proc-Simple
rpms/perl-XML-Parser-Lite-Tree-XPath
rpms/rust-atomic
rpms/rust-binascii
rpms/rust-cfb
rpms/rust-email-encoding
rpms/rust-infer
rpms/rust-inlinable_string
rpms/rust-multer
rpms/rust-rmpv
rpms/rust-serde_qs
rpms/rust-totp-lite
rpms/rust-ubyte
container/glusterfs
rpms/python-oslo-vmware
rpms/perl-Hash-Diff
rpms/perl-Test-Script-Run
rpms/esc
rpms/bash-completion-extras
rpms/apiextractor
rpms/appmenu-qt
rpms/arora
rpms/beefy-miracle-kde-theme
rpms/bluedevil
rpms/cagibi
rpms/colord-kde
rpms/constantine-kde-theme
rpms/dogtail
rpms/generatorrunner
rpms/goddard-kde-theme
rpms/herqq
rpms/jovie
rpms/kaccessible
rpms/kde-plasma-ihatethecashew
rpms/kio-ftps
rpms/kmag
rpms/kmousetool
rpms/kmouth
rpms/ktp-accounts-kcm
rpms/ktp-approver
rpms/ktp-auth-handler
rpms/ktp-common-internals
rpms/ktp-contact-list
rpms/ktp-filetransfer-handler
rpms/ktp-kded-integration-module
rpms/ktp-send-file
rpms/ktp-text-ui
rpms/kvkbd
rpms/laughlin-kde-theme
rpms/leonidas-kde-theme
rpms/libkcddb
rpms/libkcompactdisc
rpms/lovelock-kde-theme
rpms/pairs
rpms/plasma-widget-menubar
rpms/polkit-kde
rpms/prison
rpms/pyside-tools
rpms/python-pyside
rpms/qt-at-spi
rpms/qtsoap
rpms/shiboken
rpms/solar-kde-theme
rpms/telepathy-qt
rpms/verne-kde-theme
rpms/gogoc
rpms/lua-argparse
rpms/ibutils
rpms/keychecker
rpms/mediawiki-SpecialInterwiki
rpms/multitail
rpms/supybot-koji
rpms/trace-gui
modules/X11-base
modules/cloud-init
modules/dhcp
modules/networking-base
modules/shared-userspace
modules/storage-devices
rpms/dictd
rpms/ed
rpms/libcap
rpms/vim
rpms/cutter
rpms/groonga
rpms/groonga-normalizer-mysql
rpms/sentencepiece
rpms/salt
rpms/boinc-client
rpms/glue-validator
rpms/lcg-infosites
rpms/nagios-plugins-bdii
rpms/icaro
rpms/legofy
rpms/pg_view
rpms/zeek
rpms/gnome-video-arcade
rpms/pygtksourceview
rpms/python-etcd
rpms/libldm
rpms/golang-github-mattetti-filebuffer
rpms/golang-github-vividcortex-mysqlerr
rpms/golang-xorm
rpms/fbf-mukti-fonts
rpms/uniol-fonts
rpms/pg_auto_failover
rpms/fontopia
rpms/gball
rpms/gnudos
rpms/gosnake
rpms/layla-fonts
rpms/shaman
rpms/tcalc
rpms/beefy-miracle-backgrounds
rpms/constantine-backgrounds
rpms/desktop-backgrounds
rpms/echo-artist
rpms/f21-backgrounds
rpms/f22-backgrounds
rpms/gears-backgrounds
rpms/goddard-backgrounds
rpms/gtk-murrine-engine
rpms/heisenbug-backgrounds
rpms/laughlin-backgrounds
rpms/leonidas-backgrounds
rpms/libass

Re: Rust bindings for Python (pyo3 versions <0.19, cpython) broken with Python 3.12

[Kevin Fenzi]

On Mon, Nov 13, 2023 at 07:25:10PM +0100, Fabio Valentini wrote:
> 
> Yup, I've mentioned that in the bug I filed for python-bcrypt -
> It might be as simple as bumping the dependency on pyo3 from v0.15 to v0.19.

I've made an attempt here: 
https://src.fedoraproject.org/rpms/python-bcrypt/pull-request/9

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 - pagure.io network switch updates - 2023-11-17 13:00 UTC

[Kevin Fenzi]

Planned Outage - pagure.io network switch updates - 2023-11-17 13:00 UTC

There will be an outage starting at 2023-11-17 13:00UTC,
which will last approximately 4 hours.

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

date -d '2023-11-17 13:00UTC'

Reason for outage:

Network switches in the datacenter that hosts pagure.io will be
updated and rebooted. This should result in a small (~20m) break
in connectivity sometime in the outage window.

Affected Services:

pagure.io

Ticket Link:

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

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

Updated status for this outage may be available at
https://www.fedorastatus.org/



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 - pagure.io network switch updates - 2023-11-17 13:00 UTC

[Kevin Fenzi]

Planned Outage - pagure.io network switch updates - 2023-11-17 13:00 UTC

There will be an outage starting at 2023-11-17 13:00UTC,
which will last approximately 4 hours.

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

date -d '2023-11-17 13:00UTC'

Reason for outage:

Network switches in the datacenter that hosts pagure.io will be
updated and rebooted. This should result in a small (~20m) break
in connectivity sometime in the outage window.

Affected Services:

pagure.io

Ticket Link:

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

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

Updated status for this outage may be available at
https://www.fedorastatus.org/



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

Planned Outage - Server updates/Reboots - 2023-11-15 20:00 UTC

[Kevin Fenzi]

Planned Outage - Server updates/Reboots - 2023-11-15 20:00 UTC

There will be an outage starting at 2023-11-15 20:00 UTC,
which will last approximately 6 hours.

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

date -d '2023-11-15 20:00UTC'

Reason for outage:

We will be applying various updates to servers and rebooting them
into new kernels/firmware.
Various services may be up and down in the outage window.

Affected Services:

Most services maintainer / contributor services will be affected
at various times in the outage window.
End user services should be mostly available.

Ticket Link:

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

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

Updated status for this outage may be available at
https://www.fedorastatus.org/


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 - Server updates/Reboots - 2023-11-15 20:00 UTC

[Kevin Fenzi]

Planned Outage - Server updates/Reboots - 2023-11-15 20:00 UTC

There will be an outage starting at 2023-11-15 20:00 UTC,
which will last approximately 6 hours.

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

date -d '2023-11-15 20:00UTC'

Reason for outage:

We will be applying various updates to servers and rebooting them
into new kernels/firmware.
Various services may be up and down in the outage window.

Affected Services:

Most services maintainer / contributor services will be affected
at various times in the outage window.
End user services should be mostly available.

Ticket Link:

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

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

Updated status for this outage may be available at
https://www.fedorastatus.org/


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: dnf conflict in rawhide Docker container in GitHub Action

[Kevin Fenzi]

On Mon, Nov 13, 2023 at 11:02:29AM -0800, Adam Williamson wrote:
> 
> Neither I nor nirik can reproduce this as described. Note the web UI is
> basically just lies / incomplete info; I think it's telling you when
> the tag was created, not when the image behind it was last updated.

The web page is... unfortunate.

So, we setup that page orig using 'reg' to generate a web page from the
existing registry contents, I am not sure who this was intended for. :( 
contributors? end users? who looks at it instead of just pulling or
using skopeo?

reg is a golang app, the server it's running on is currently rhel7 and
it's been a bit of pain to keep it building. Then, a few months ago, it
started failing... some of the time. I couldn't track down why sometimes
it failed, but when it did all the files were 0 length and the registry
page would be blank.

I talked with websites folks and we thought it might be nice to just
redirect that page to a 'fedora containers' type websites page,
explaining how to use the containers, etc. Thats not yet happened.

Also, we are looking at migrating soon to just use quay.io and point
registry.fedoraproject.org there. Thats not yet happened either. 

Of course we can do both...

So, I manually updated the web page, so it should be accurate again.

I can try and look at replacing it with a placeholder page, or see where
websites folks are in making a page.

Anyhow, as far as I can see the image is the GA f39 image and is right
and correct, it's just the web page thats misleading.

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

intent to retire: fedmsg-irc, old fmn, osbs

[Kevin Fenzi]

Greetings everyone.

Now that fedora 39 is out the door, I'd like to schedule some
retirements of a few old services:

fedmsg-irc: This is a old fedmsg process that send fedmsg's to IRC.
Currently we have one running in production and one in staging, both on
rhel7 vm's that we would like to retire. They currently gateway the
entire message bus to #fedora-fedmsg (prod) and #fedora-fedmsg-stg
(staging), but due to the volume and IRC throttling they are way behind.
It's often behind by 12-48 hours. Additionally, it sends some matching
messages to the #fedora-releng channel (composes, etc). We plan to
replace that with a matrix bot webhook at some point.

old fmn (old fedora notifications service).
https://apps.fedoraproject.org/notifications-old/
This was replaced with https://notifications.fedoraproject.org/
and we said we would sunset the old one after f39 was out.
If you're missing features with the new one, please make sure they are
tracked at https://github.com/fedora-infra/fmn/issues

osbs (openshift build service). This is 4 openshift 3.11 clusters. (one
each for x86_64 and aarch64 x production and staging). This service
built containers for us, but all the containers we now build are done
via ImageFactory (base, minimal, toolbox) or elsewhere (quay.io, etc).

I'd like to turn these services off next wed (2023-11-15) if there's no
reasons I missed to do so before then. We will keep the data from them
around in case we need to bring them back or get data from them.

Please let us know if there's any uses for these services we aren't
aware of before next wed. 

https://pagure.io/fedora-infrastructure/issue/11504 is a tracking ticket
for the osbs cluster retirement.

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: Self Introduction: Jamie Chapman

[Kevin Fenzi]

Hey Jamie!

Welcome. :)

If you get a chance do drop by our matrix space and chime in with any
questions or comments.

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: Didn't get an email about a new merge request on a package

[Kevin Fenzi]

On Wed, Nov 08, 2023 at 01:26:53PM +0100, Fabio Valentini wrote:
...snip...
> 
> So to me this sounds like there was just some hiccup somewhere that
> resulted in the email not being sent.

Yeah, seems like: 

Oct 28 09:04:13 pkgs01 celery[1147999]: 2023-10-28 09:04:13,585 [ERROR] 
celery.app.trace: Task 
pagure.lib.tasks.update_git[c29a4cbf-ba3d-41f6-b29f-6a74bf400fa2] raised 
unexpected: Exception('Unable to find object',)
Oct 28 09:04:13 pkgs01 celery[1147999]: Traceback (most recent call last):
Oct 28 09:04:13 pkgs01 celery[1147999]:  File 
"/usr/lib/python3.6/site-packages/celery/app/trace.py", line 385, in trace_task
Oct 28 09:04:13 pkgs01 celery[1147999]:R = retval = fun(*args, **kwargs)
Oct 28 09:04:13 pkgs01 celery[1147999]:  File 
"/usr/lib/python3.6/site-packages/celery/app/trace.py", line 648, in 
__protected_call__
Oct 28 09:04:13 pkgs01 celery[1147999]:return self.run(*args, **kwargs)
Oct 28 09:04:13 pkgs01 celery[1147999]:  File 
"/usr/lib/python3.6/site-packages/pagure/lib/tasks_utils.py", line 36, in 
decorated_function
Oct 28 09:04:13 pkgs01 celery[1147999]:return function(self, session, 
*args, **kwargs)
Oct 28 09:04:13 pkgs01 celery[1147999]:  File 
"/usr/lib/python3.6/site-packages/pagure/lib/tasks.py", line 357, in update_git
Oct 28 09:04:13 pkgs01 celery[1147999]:raise Exception("Unable to find 
object")
Oct 28 09:04:13 pkgs01 celery[1147999]: Exception: Unable to find object

I am not sure what happened there. ;( Some kind of race condition?

But that matches up exactly when the PR was created.

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: DNF5: Checking signatures of packages installed out of a repository?

[Kevin Fenzi]

On Wed, Nov 01, 2023 at 11:05:33AM -0400, Christopher wrote:
> On Tue, Oct 31, 2023 at 7:50 PM Kevin Fenzi  wrote:
> >
> > FWIW, from what I can recall, yum used to check all packages, but this
> > resulted in tons of people complaining because they did not want it to
> > check their local packages. So, a localpkg_gpgcheck option was added and
> > set to false. dnf4 still has this option.
> 
> I wasn't aware of that change in behavior. I can't find that option
> documented in the man page for dnf or any other readily available docs
> about dnf in my installation, or present in my dnf.conf file. I don't

Odd. It's in the dnf.conf man page here in rawhide:

"localpkg_gpgcheck
  boolean

  Whether  to  perform  a  GPG signature check on local packages 
(packages in a
  file, not in a repository).  The default is False.  This option 
is subject to
  the active RPM security policy (see gpgcheck for more details).
"

Looks like it was added to yum 13 years ago:
https://github.com/rpm-software-management/yum/commit/290933489b1aaeb1017d10fb59ccf3231e309115

> remember anybody ever complaining, certainly not "tons of people".

This was 13-14 years ago. 

> Using local RPMs is a pretty rare thing. I can't imagine too many
> people complaining about this. It was never much of a burden, and to
> the extent that it was, it was a burden that was a worthwhile tradeoff
> for increased security.

I'm just relaying the history here... 

> It's also not clear when this option would take effect. Would it take
> effect if I did `dnf install /path/to/local/file` or just when I did

no, because that looks up that file in your repos and downloads the repo
version of the package.

> `dnf localinstall /path/to/local/file`? What if I did `dnf

yes.

> localinstall remotepath:/to/remote/file`? All of these work, as it
> seems "localinstall" and "install" both just work if given a URL,
> local or remote.

remote path just downloads the file and installs it, so it's the same as
the last case. 

> This option seems poorly rolled out, unclear in function, and overall
> bad for security.

Well, nothing was rolled out, it's been that way for 13 years.
Should it be revisited? Sure, and thats what this thread is for?
> 
> >
> > It's also worth noting that if you pass yum/dnf/dnf5 urls for the
> > package(s) you want to install, it's not using a repo at all, it's
> > downloading those packages and treating them as local packages.
> 
> Is this meant to imply that it doesn't do checks by default whenever
> you pass a URL?! That's even worse! From this user's perspective, a
> URL pointing to a package in a repo, is just a more fully-qualified
> way of specifying the shorthand package name. It seems very odd if

But dnf has no way to know https://foo.bar/packagename is in a repo.
If it is, you should enable the repo and install it with 'dnf install
packagename'.

> passing a fully-qualified path to a remote package results in less
> security than specifying the (possibly ambiguous) shortname for a
> package that DNF resolves via NVR.

Yep. 

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: DNF5: Checking signatures of packages installed out of a repository?

[Kevin Fenzi]

FWIW, from what I can recall, yum used to check all packages, but this
resulted in tons of people complaining because they did not want it to
check their local packages. So, a localpkg_gpgcheck option was added and
set to false. dnf4 still has this option.

It's also worth noting that if you pass yum/dnf/dnf5 urls for the
package(s) you want to install, it's not using a repo at all, it's
downloading those packages and treating them as local packages.

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: Is package (gnome-shell extension) split into legacy and current required?

[Kevin Fenzi]

On Mon, Oct 16, 2023 at 12:02:05PM +0200, Alexander Ploumistos wrote:
> Hello,
> 
> I maintain the gnome-shell extension for bubblemail. I was informed by
> the upstream developer that in order to support GNOME ≥ 45, he is
> rewriting most of the code. What is currently the master branch will
> support (recent) GNOME versions up to 44.x and there will be another
> branch for 45 and newer.

I assume you mean you maintain the Fedora package? Or are you maintainer
of the extension and asking what you should do upstream?

> Do I need to create something like a compat package or can I just
> switch to the new source/branch from F39 onward? I suppose that a
> bugfix for F37 and F38 down the road is not out of the question, so
> there will be two different upstream branches for different Fedora
> versions.

You should target the gnome version in each release, no need for compat
packages. That assumes versions on the package(s) are such that users
can upgrade going from one release to the next.

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: Self Introduction: Pavol Zacik

[Kevin Fenzi]

On Thu, Oct 12, 2023 at 03:35:10PM +0200, Pavol Zacik wrote:
> Hello all,
> 
> I have recently joined Red Hat as a software engineer, where I will
> hopefully get to contribute to multiple Fedora packages such as TuneD.
> Previously, I've made some contributions e.g., to the Botan C++
> cryptography library.

Welcome Pavol!

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: [Test-Announce] Fedora Linux 39 Final is NO-GO

[Kevin Fenzi]

On Wed, Oct 11, 2023 at 09:45:01AM -0700, Adam Williamson wrote:
> On Wed, 2023-10-11 at 15:45 +0200, Michael J Gruber wrote:
> > I was just wondering what the "anchor" is, say "right after final
> > freeze" or "7 days before GA". We could put "updates-testing disabled
> > in fedora-release GA version" as a remark in there, just like "xy plan
> > on this" and such.
> 
> The anchor is "whenever someone remembers we have to do it".

I suppose we could hold fedora-repos/fedora-release updates in testing
until right before the first RC is requested, but that doesn't really
pin it down any more, as that will happen when all known blockers have
been addressed, which could be anytime...

We could add a note to any RC testing announcements?

For that matter we could suggest a distro-sync with the release
announcement, but I guess that could be confusing to some.

kevin


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

Re: Occasional random Koji build failures only on ppc64le

[Kevin Fenzi]

Circling back here... I downgraded the hosts yesterday and they have
been all checking in reliably as far as I can see. 

Are you still seeing any build issues?

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: Intention to tighten RPM crypto-policy back

[Kevin Fenzi]

On Fri, Oct 06, 2023 at 01:09:08PM +0200, Petr Pisar wrote:
> 
> These Fedora Project keys distribute in 
> are also affected:
> 
> $ gpg --list-keys 6A2FAEA2352C64E5
> pub   rsa4096 2013-12-16 [SCE]
>   91E97D7C4A5E96F17F3E888F6A2FAEA2352C64E5
> uid   [  neznámá   ] Fedora EPEL (7) 
> 
> $ gpg --list-keys 21EA45AB2F86D6A1
> pub   rsa4096 2019-06-05 [SCE]
>   94E279EB8D8F25B21810ADF121EA45AB2F86D6A1
> uid   [  neznámá   ] Fedora EPEL (8) 
> 
> $ gpg --list-keys 7BB90722DBBDCF7C
> pub   rsa4096 2018-11-13 [SCE] [platnost skončí: 2028-12-31]
>   C2A3FA9DC67F68B98BB543F47BB90722DBBDCF7C
> uid   [  neznámá   ] Fedora (iot 2019) 

Yes. I think we should split the epel and fedora keys there (and the iot
one isn't used for a long time and can be dropped). 

I don't think it makes much sense to force changes to the epel7/epel8
keys now just to check some compatibility box on fedora installs. ;) 

See 

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

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: Mock v5.0 released (and mock-core-configs v39)

[Kevin Fenzi]

On Wed, Oct 04, 2023 at 11:24:15PM +0200, Pavel Raiskup wrote:
> On úterý 3. října 2023 21:48:24 CEST Kevin Fenzi wrote:
> > On Tue, Oct 03, 2023 at 10:30:45AM +0200, Pavel Raiskup wrote:
> > > 
> > > Well, in what shape is our "layered image" build system?  Aren't we able
> > 
> > Terrible, and going to be decomissioned after f39 release. ;) 
> > 
> > But if you mean base images... those are fine.
> 
> I fear that doing this as additional full Fedora image would be a waste
> of space in the Fedora registry?  Or not?  We basically need the base
> image + python3-dnf-plugins-core:

Yes, it would be a lot of wasted space/duplication. ;( 

> Installing:
>  python3-dnf-plugins-core  noarch 4.4.2-1.fc39   rawhide  
>  293 k
> Installing dependencies:
>  dbus-libs x86_64 1:1.14.10-1.fc40   rawhide  
>  155 k
>  fonts-filesystem  noarch 1:2.0.5-12.fc39rawhide  
>  8.2 k
>  js-jquery noarch 3.7.1-1.fc40   rawhide  
>  169 k
>  python3-dateutil  noarch 1:2.8.2-10.fc39rawhide  
>  355 k
>  python3-dbus  x86_64 1.3.2-4.fc39   rawhide  
>  157 k
>  python3-distronoarch 1.8.0-6.fc39   rawhide  
>   49 k
>  python3-six   noarch 1.16.0-12.fc39 rawhide  
>   41 k
>  python3-systemd   x86_64 235-5.fc39 rawhide  
>  107 k
>  web-assets-filesystem noarch 5-20.fc39  rawhide  
>  7.9 k
> Installing weak dependencies:
>  python-systemd-docx86_64 235-5.fc39 rawhide  
>   75 k
> 
> For DNF5 images (41+), I hope we can put the dnf5-plugins
> (dnf-plugins-core alternative in c++) directly into the base image since
> it has no additional deps.

So, what do you need out of there? builddep? or?

> > > to create a new official image say 
> > > `fedora-mock-bootstrap:`
> > > that would be automatically built (ideally at least as frequently as the
> > > base image is)?  This way we could optimize fedora builds for everyone.
> > 
> > Yes, we could. Just wouldn't be a layer, it would be it's own image. 
> 
> Do we have some HOWTO document how to start?  I suppose I have to
> provide a kickstart file in fedora-kickstarts.git?  Would the image be
> built automatically/when? :-)

I'm not convinced this is worth it... especially if dnf5 will mean it
doesn't matter anymore and currently it just means people have to
download a few packages at the start of a build.

I guess I would say a f40 change and with that discussion all the
details would be worked out. Is it release blocking? Does it need to be
advertised anywhere on websites? 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

Re: Occasional random Koji build failures only on ppc64le

[Kevin Fenzi]

On Thu, Oct 05, 2023 at 09:23:57PM +0200, Fabio Valentini wrote:
> On Thu, Oct 5, 2023 at 9:12 PM Richard W.M. Jones  wrote:
> >
> > Getting $SUBJECT.  The errors are always of the form:
> >
> > DEBUG util.py:446:: Cannot download, all mirrors were 
> > already tried without success
> >
> > for various s.  Examples:
> >
> > https://koji.fedoraproject.org/koji/taskinfo?taskID=107101090
> > https://koji.fedoraproject.org/koji/taskinfo?taskID=107097695
> > https://koji.fedoraproject.org/koji/taskinfo?taskID=107097917
> >
> > Retrying the builds seems to fix it.
> >
> > Could be a problem with a server or mirror somewhere?
> 
> I see these regularly in koschei failures as well.
> x86_64 and aarch64 builds succeed, but ppc64le fails with network issues.

yeah. Shortly before final freeze I updated the virthosts those builders
are on. Sadly, somehow the newer kernels cause those weird network
hiccups. Builders stop checking in, or don't return when uploading as
well.

I moved one of them back to the previous kernel to confirm it was ok and
it has been. I am downgrading all the rest now, so they should all be
back to hopefully being stable later this afternoon. 

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: Mock v5.0 released (and mock-core-configs v39)

[Kevin Fenzi]

On Tue, Oct 03, 2023 at 10:30:45AM +0200, Pavel Raiskup wrote:
> 
> Well, in what shape is our "layered image" build system?  Aren't we able

Terrible, and going to be decomissioned after f39 release. ;) 

But if you mean base images... those are fine.

> to create a new official image say `fedora-mock-bootstrap:`
> that would be automatically built (ideally at least as frequently as the
> base image is)?  This way we could optimize fedora builds for everyone.

Yes, we could. Just wouldn't be a layer, it would be it's own image. 

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: time is running: security issue BZ#2241470

[Kevin Fenzi]

On Sat, Sep 30, 2023 at 11:13:32AM +0200, Marius Schwarz wrote:
> 
> Hi,
> 
> this is emerg ping for the security team, to take a look at this bz :
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=2241470

If this is an embargoed bug (I can't see it, so no idea if it is, but it
seems likely), please don't discuss it on a public mailing list. 

Fedora has no means to secretly build anything, so it may be that the
maintainers of whatever this is are waiting for the embargo to lift to
push fedora updates. 

If you have access to the bug, thats the place to comment further.

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: retirement of klee from EPEL 9

[Kevin Fenzi]

On Thu, Sep 28, 2023 at 10:37:28PM -0500, Carl George wrote:
> It recently came to my attention that the klee package in EPEL 9
> needed to be rebuilt against the LLVM 15 library that shipped in RHEL
> 9.2.  I filed a bug for this [0], and then noticed it was assigned to
> "Orphan Owner".  It looks like the maintainer retired it from Fedora
> [1][2] due the upstream not being compatible with LLVM 15 [3].  I am
> not the maintainer of this package, but I intend to retire this
> package from EPEL 9 to avoid having a package with installation issue
> lingering around.  The EPEL retirement policy [4] doesn't cover this
> exact scenario, so I plan to bring it up for discussion at the next
> EPEL Steering Committee meeting.  We could delay the retirement for
> one week (the policy for security-related retirements) or two weeks
> (the policy for lack-of-time retirements), but my preference would be
> to retire it ASAP.

Retiring seems reasonable here. 

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: Packaging guidelines - validation of AppStream metadata files

[Kevin Fenzi]

On Thu, Sep 28, 2023 at 01:03:08PM +0100, Richard Hughes wrote:
> On Wed, 27 Sept 2023 at 22:41, Kevin Fenzi  wrote:
> > I'm not sure at all that it would be possible to do at compose-time...
> > composes are taking around 3.5-4hours and thats after I have done
> > a lot to speed them up, but might be worth some benchmarking
> > to see how much slower it would be. If we are going to go that route, we
> > should see if support could be added to pungi.
> 
> On server class hardware with fast disk access it's an additional 10
> minutes or so.
> 
> > Moving this from a package to in repodata would grow the repodata quite
> > a lot right?
> 
> 6.9Mfedora-39-icons.tar.gz
> 6.3Mfedora-39.xml.gz

So, on re-reading this thread and the upstream issues... it really seems
like the best case would be createrepo_c just adding support, but that
seems stalled/blocked due to i/o concerns? (which I can understand, but
it could be default off?)

How does the local/rpm data interact with the repodata (if it exists)?
Or does it depend on the tool?

I suppose in the short term at least if you wanted you could hand off
the generation/rpm updating to releng? (Not that releng wants more to
do, but I don't think you should carry this by yourself).

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: Packaging guidelines - validation of AppStream metadata files

[Kevin Fenzi]

On Wed, Sep 27, 2023 at 10:05:38AM -0400, Neal Gompa wrote:
> On Wed, Sep 27, 2023 at 9:48 AM Richard Hughes  wrote:
> >
> > On Wed, 27 Sept 2023 at 13:23, Mattia Verga via devel
> >  wrote:
> > > Can't this script be moved to run in Openshift as cron-based?
> >
> > Yes! In fact, that's what I proposed about a decade ago when I wanted
> > to include the data in the metadata like Debian does. I do think it
> > should be managed by someone in the rel-eng/infra team rather than me.
> >
> 
> openSUSE and Mageia both do it this way too. If we move to running the
> script in infra, we should just make the switch to appending it to the
> repodata. When I helped Mageia set it up[1], we elected to compose it weekly
> and re-append the results for every repo push until the appstream
> repodata was regenerated.
> 
> Also, our compose process *has* gotten faster over the past decade, so
> we may be able to do this at compose-time now.

Here's the old releng ticket about this (I think):
https://pagure.io/releng/issue/5721

In addition to appstream data, there's the screenshots.

I agree much has changed and we should revisit how best to do this
process. 

I'm not sure at all that it would be possible to do at compose-time...
composes are taking around 3.5-4hours and thats after I have done
a lot to speed them up, but might be worth some benchmarking
to see how much slower it would be. If we are going to go that route, we
should see if support could be added to pungi.

Moving this from a package to in repodata would grow the repodata quite
a lot right?

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: Intention to tighten RPM crypto-policy back

[Kevin Fenzi]

On Tue, Sep 26, 2023 at 07:22:56PM +0200, Alexander Sosedkin wrote:
> 
> Whoa, that's too many, I suspect misreporting.

Could be. 

> I seriously doubt they were all really using DSA-1024 and switched over.
> But if that really was the case --- great job to all of them.
> 
> > The list from there:
> > Google Chrome (RPM signature rejected, repo key rejected)
> Repo has added RSA-4096, RPM is signed with SHA-512, installs
> 
> > Microsoft Edge (repo key rejected)
> RSA-2048, RPM is signed with SHA-256, installs
> 
> > Dropbox (repo key rejected)
> RSA-2048, RPM is signed with SHA-512
> 
> > Skype (repo key rejected)
> RSA-2048 / SHA-512
> 
> > Visual Studio Code (repo key rejected)
> RSA-2048 / SHA-256 (let's name a package `code`. outstanding move)
> 
> > Sublime Text (repo key rejected)
> RSA-4096 / SHA-256
> 
> > Microsoft Teams (repo key rejected)
> RSA-2048, but https://packages.microsoft.com/yumrepos/ms-teams/repodata
> looks barren
> 
> > TeamViewer (repo key rejected)
> RSA-4096 / SHA-256

Nice. 

Yeah, then it seems like this may well be a time to try again.

I look forward to the 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

Re: Intention to tighten RPM crypto-policy back

[Kevin Fenzi]

On Tue, Sep 19, 2023 at 11:19:18AM +0200, Alexander Sosedkin wrote:
> Hello,
> 
> 6 months ago, there's been a F38 blocker: https://pagure.io/fesco/issue/2960
> Long story short:
> RPM has moved to sequoia,
> sequoia has started respecting crypto-policies,
> Google repos have been signed with a 1024-bit DSA key,
> Google Chrome was not installable => F38 blocker.
> Back at the time, it's been hastily "resolved"
> by relaxing RPM security through crypto-policies
> just enough to tolerate that Google signature:
> https://bugzilla.redhat.com/show_bug.cgi?id=2170878
> https://gitlab.com/redhat-crypto/fedora-crypto-policies/-/merge_requests/129
> 
> Since then it has been brought to my attention that
> Google has now added a 4096 bit RSA key
> https://www.google.com/linuxrepositories/
> (EB4C 1BFD 4F04 2F6D DDCC EC91 7721 F63B D38B 4796)
> 
> Because of that, I'd like to revert that RPM policy relaxation
> https://gitlab.com/redhat-crypto/fedora-crypto-policies/-/commit/a12f7b20638be8f872ad1995c7d2edce41c227b5
> in (f39) rawhide and align RPM security with the rest of the policy.
> 
> Thoughts / feedback?

It might be good to go through all the ones that were hit by this (it
wasn't just chrome) and indicate if they are now fixed.
You can see a partial list in the common bug: 

https://discussion.fedoraproject.org/t/popular-third-party-rpms-fail-to-install-update-remove-due-to-security-policies-verification/70498

and in the discussion off it. 

The list from there:

Google Chrome (RPM signature rejected, repo key rejected)
Microsoft Edge (repo key rejected)
Dropbox (repo key rejected)
Skype (repo key rejected)
Visual Studio Code (repo key rejected)
Sublime Text (repo key rejected)
Microsoft Teams (repo key rejected)
TeamViewer (repo key rejected)

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 39 Beta Released

[Kevin Fenzi]

On Tue, Sep 19, 2023 at 09:57:35AM -0500, Michael Catanzaro wrote:
> On Tue, Sep 19 2023 at 04:01:59 PM +0200, Tomas Hrcka 
> wrote:
> > Download the prerelease from our Get Fedora site:
> > * Get Fedora Linux 39 Beta Workstation:
> > https://getfedora.org/workstation/download/
> > * Get Fedora Linux 39 Beta Server:
> > https://getfedora.org/server/download/
> > * Get Fedora Linux 39 Beta IoT: https://getfedora.org/iot/download/
> > * Get Fedora Linux 39 Beta CoreOS:
> > https://fedoraproject.org/coreos/download/
> > * Get Fedora Linux 39 Beta Cloud:
> > https://fedoraproject.org/cloud/download
> 
> Uh-oh. I see we can download the beta version of Server and Cloud by
> toggling the "Show Beta Downloads" switch, but there doesn't appear to be
> any way to download the beta for Workstation or IoT.

Odd. It shows fine here. 

Caching issue?

kevin


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

Re: The new Change discussion process is painful

[Kevin Fenzi]

On Thu, Sep 14, 2023 at 10:44:22AM +0200, Vít Ondruch wrote:
> If I was subscribed to some categories without doing anything, e.g. "Package
> Reviews Swaps" (why I cannot copy the string from UI , this is precisely
> the annoyance with web applications), why I have not been subscribed to
> "Change proposals"?

The 'package review swaps' thing was a mistake/hasty setup by mattdm. :)

Basically the category was setup and the thought was "hey, all people in
the packager group would be interested in this, right?" and so everyone
in the packager group (that had logged into discourse) was added to it.

This should have been reverted not long after... 

There's no single group that would make sense to just auto subscribe to
change proposals. Anyone could be interested in it, or 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