OpenSSL performance tuning Webinar

[Dmitry Belyavskiy]

Dear colleagues,

OpenSSL has announced the performance tuning webinar on August 1
https://openssl.org/blog/blog/2024/07/18/August-Webinar/

Feel free to register and join

-- 
Dmitry Belyavskiy

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

Re: Fedora rawhide (to be f41) and openssl engines

[Clemens Lang]

Hi,

> On 22. Jul 2024, at 20:42, Zbigniew Jędrzejewski-Szmek  
> wrote:
> 
> At this point, this sounds like the best approach.
> The problem is well understood and the build failures are trivially
> resolved by adding a single BuildRequires line or a single define.
> 
> If we start changing things again, some packages will already adapted
> will need to adapt again, and overall there'll much more confusion.

I won’t object to this, it’s overall less work for Dmitry and me.

However, we should still consider the effect this will have on developers that 
build software on Fedora — they will also have to specify -DOPENSSL_NO_ENGINE 
now or see failing builds, and we don’t really see that impact until 41 
releases.


-- 
Clemens Lang
RHEL Crypto Team
Red Hat



-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
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 Mass Rebuild 41 has completed

[Zbigniew Jędrzejewski-Szmek]

On Mon, Jul 22, 2024 at 11:32:03PM +, Zbigniew Jędrzejewski-Szmek wrote:
> On Tue, Jul 23, 2024 at 01:19:27AM +0200, Miro Hrončok wrote:
> > On 23. 07. 24 1:07, Zbigniew Jędrzejewski-Szmek wrote:
> > > I noticed the following when comparing packages after the rebuild:
> > > 
> > > │ │ │ 
> > > -{"type":"rpm","name":"guile22","version":"2.2.7-12.fc41","architecture":"x86_64","osCpe":"cpe:/o:fedoraproject:fedora:40"}
> > > │ │ │ 
> > > +{"type":"rpm","name":"guile22","version":"2.2.7-14.fc41","architecture":"x86_64","osCpe":"cpe:/o:fedoraproject:fedora:40"}
> > > 
> > > It seems the info in os-release hasn't been updated so the
> > > package notes embedded in the binaries are off.
> > 
> > 
> > package-notes has:
> > 
> > %build
> > sed "s|@OSCPE@|$(cat /usr/lib/system-release-cpe)|" %{SOURCE0}
> > >redhat-package-notes
> > 
> > But the last build before the mass rebuild happened on Fedora 40.
> > 
> > To prevent this situation in the future, package-notes needs to be rebuilt
> > right after branching.
> 
> You are right, that's really a bug in package-notes.
> I think we could replace the static string with a read of
> /usr/lib/system-release-cpe.

I forgot that the latest implementation uses the linker spec file
"language" to insert the note. After banging my head against the screen
and keyboard for an hour, I couldn't figure out any way to make this
happen. It seems that we can only substitute variables, but not read
an arbitrary file.

The only solution I can think of is to set $RPM_OS_RELEASE_CPE along
with other variables in the rpm setup, and use that via getenv in
/usr/lib/rpm/redhat/redhat-package-notes.

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

Re: [Java related] packaging Italian ID card middleware

[Julian Sikorski]

Am 22.07.24 um 22:53 schrieb Kevin Kofler via devel:

Julian Sikorski wrote:

Germany uses their own implementation too:
https://src.fedoraproject.org/rpms/AusweisApp2
To add insult to injury, it requires the use of custom EC curves, which
are bound to stop working at any moment:
https://bugzilla.redhat.com/show_bug.cgi?id=2259403


At which point you should probably just bundle a static OpenSSL with
AusweisApp2. As unfortunate as it is, there appears to be little other
choice to keep the package running here, and bundling forked libraries is no
longer against Fedora packaging guidelines. And there are other packages
already bundling forked versions of OpenSSL (e.g., Chromium and derivatives
all bundle some version of "BoringSSL").


Well so far it is working, let's hope it stays this way as long as 
possible. If upstream drops legacy OpenSSL API support or using it no 
longer helps, I am probably going to orphan the package. There is a 
flatpak which seems to be maintained by one of the upstream developers. 
Bundling a security-critical library in a package used for ID 
verification is not something I would be willing to take on.




And at least the German stuff (and the Italian, Portuguese, and Estonian
ones) is Free Software. The Austrian ID Austria app is entirely proprietary.
Though, as far as I know, you can buy physical FIDO2 hardware, then go
register that with the ID Austria office, and then log in on the ID Austria
website with any FIDO2 enabled browser and the hardware you bought. But the
default workflow goes through a proprietary smartphone app.


Definitely. Polish ID software is closed source too and from the brief 
look was even allegedly violating LGPL at some point.




 Kevin Kofler


Best regards,
Julian
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
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: [Java related] packaging Italian ID card middleware

[Petr Pisar]

V Tue, Jul 23, 2024 at 12:15:39PM +0200, Julian Sikorski napsal(a):
> Am 22.07.24 um 22:53 schrieb Kevin Kofler via devel:
> > Julian Sikorski wrote:
> > > Germany uses their own implementation too:
> > > https://src.fedoraproject.org/rpms/AusweisApp2
> > > To add insult to injury, it requires the use of custom EC curves, which
> > > are bound to stop working at any moment:
> > > https://bugzilla.redhat.com/show_bug.cgi?id=2259403
> > 
> > At which point you should probably just bundle a static OpenSSL with
> > AusweisApp2. As unfortunate as it is, there appears to be little other
> > choice to keep the package running here, and bundling forked libraries is no
> > longer against Fedora packaging guidelines. And there are other packages
> > already bundling forked versions of OpenSSL (e.g., Chromium and derivatives
> > all bundle some version of "BoringSSL").
> 
> Well so far it is working, let's hope it stays this way as long as possible.
> If upstream drops legacy OpenSSL API support or using it no longer helps, I
> am probably going to orphan the package. There is a flatpak which seems to
> be maintained by one of the upstream developers. Bundling a
> security-critical library in a package used for ID verification is not
> something I would be willing to take on.
> 
> > 
> > And at least the German stuff (and the Italian, Portuguese, and Estonian
> > ones) is Free Software. The Austrian ID Austria app is entirely proprietary.
> > Though, as far as I know, you can buy physical FIDO2 hardware, then go
> > register that with the ID Austria office, and then log in on the ID Austria
> > website with any FIDO2 enabled browser and the hardware you bought. But the
> > default workflow goes through a proprietary smartphone app.
> 
> Definitely. Polish ID software is closed source too and from the brief look
> was even allegedly violating LGPL at some point.
> 
Slovak ID is also proprietary. Someone reverse engineered it, merged the
implementation into OpenSC and got sued by the vendor
.

-- Petr


signature.asc
Description: PGP signature
-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
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 Tuesday's FESCo Meeting (2024-07-23)

[Zbigniew Jędrzejewski-Szmek]

Following is the list of topics that will be discussed in the
FESCo meeting Tuesday at 17:00 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-07-23 17:00 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 =

#3242 Change: Opt-In Metrics for Fedora Workstation
https://pagure.io/fesco/issue/3242
APPROVED (+6, 0, 0)

#3243 Change: IPU6 Camera Support
https://pagure.io/fesco/issue/3243
APPROVED (+8, 0, 0)

#3244 Change: Retire Python 2.7 
https://pagure.io/fesco/issue/3244
APPROVED (+8, 0, 0)

#3245 Change: Reduce the amount of "dontaudit" rules pertaining to unlabeled_t
https://pagure.io/fesco/issue/3245
APPROVED (+7, 0, 0)


= Followups =

#3230 Mass license change
https://pagure.io/fesco/issue/3230

Latest proposal: All old license strings shall be converted to SPDX
format. For licenses where a 1:1 mapping exists from the legacy Fedora
tag to SPDX, the normal SPDX tag shall be used. For licenses where the
old license tag maps to more than one possible license in the SPDX
database, a tag in the form of
LicenseRef--* where * is the old
Fedora identifier shall be used. In both cases, a comment shall be
included in the spec file to indicate that the conversion was done
automatically and review is warranted. For the second case, the
comment should also indicate that the maintainers should update to
normal SPDX tags after review.

#3235 Change: Fedora KDE Plasma Mobile
https://pagure.io/fesco/issue/3235


= New business =

#3248 Git Forge Evaluation FESCo Rep(s)
https://pagure.io/fesco/issue/3248


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

[Test-Announce]Fedora 41 Rawhide 20240723.n.0 nightly compose nominated for testing

[rawhide]

Announcing the creation of a new nightly release validation test event
for Fedora 41 Rawhide 20240723.n.0. Please help run some tests for this
nightly compose if you have time. For more information on nightly
release validation testing, see:
https://fedoraproject.org/wiki/QA:Release_validation_test_plan

Notable package version changes:
anaconda - 20240719.n.1: anaconda-41.25-1.fc41.src, 20240723.n.0: 
anaconda-41.25-2.fc41.src
python-blivet - 20240719.n.1: python-blivet-3.10.1-2.fc41.src, 20240723.n.0: 
python-blivet-3.10.1-3.fc41.src
pyparted - 20240719.n.1: pyparted-3.13.0-6.fc41.src, 20240723.n.0: 
pyparted-3.13.0-7.fc41.src
parted - 20240719.n.1: parted-3.6-4.fc40.src, 20240723.n.0: 
parted-3.6-6.fc41.src
pykickstart - 20240719.n.1: pykickstart-3.55-2.fc41.src, 20240723.n.0: 
pykickstart-3.55-3.fc41.src
lorax - 20240719.n.1: lorax-41.3-1.fc41.src, 20240723.n.0: lorax-41.3-2.fc41.src
pungi - 20240719.n.1: pungi-4.6.3-1.fc41.src, 20240723.n.0: 
pungi-4.6.3-2.fc41.src

Test coverage information for the current release can be seen at:
https://openqa.fedoraproject.org/testcase_stats/41

You can see all results, find testing instructions and image download
locations, and enter results on the Summary page:

https://fedoraproject.org/wiki/Test_Results:Fedora_41_Rawhide_20240723.n.0_Summary

The individual test result pages are:

https://fedoraproject.org/wiki/Test_Results:Fedora_41_Rawhide_20240723.n.0_Installation
https://fedoraproject.org/wiki/Test_Results:Fedora_41_Rawhide_20240723.n.0_Base
https://fedoraproject.org/wiki/Test_Results:Fedora_41_Rawhide_20240723.n.0_Server
https://fedoraproject.org/wiki/Test_Results:Fedora_41_Rawhide_20240723.n.0_Cloud
https://fedoraproject.org/wiki/Test_Results:Fedora_41_Rawhide_20240723.n.0_Desktop
https://fedoraproject.org/wiki/Test_Results:Fedora_41_Rawhide_20240723.n.0_Security_Lab

Thank you for testing!
-- 
Mail generated by relvalconsumer: https://pagure.io/fedora-qa/relvalconsumer
-- 
___
test-announce mailing list -- test-annou...@lists.fedoraproject.org
To unsubscribe send an email to test-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/test-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

Re: F42 Change Proposal: Enable Drm Panic (system-wide)

[Jocelyn Falempe]

Hi,

It's no longer necessary to disable VT_CONSOLE to enable DRM_PANIC.
So I have updated the wiki page, and also moved it to 
self-contained-change, as there are no more system-wide impact by 
enabling DRM_PANIC.


I've also made a new kernel build, with VT_CONSOLE and DRM_PANIC 
enabled, so you can check by yourself that it works:


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


--

Jocelyn

--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
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: Enable Drm Panic (system-wide)

[Neal Gompa]

On Tue, Jul 23, 2024 at 8:32 AM Jocelyn Falempe  wrote:
>
> Hi,
>
> It's no longer necessary to disable VT_CONSOLE to enable DRM_PANIC.
> So I have updated the wiki page, and also moved it to
> self-contained-change, as there are no more system-wide impact by
> enabling DRM_PANIC.
>
> I've also made a new kernel build, with VT_CONSOLE and DRM_PANIC
> enabled, so you can check by yourself that it works:
>
> https://koji.fedoraproject.org/koji/taskinfo?taskID=120743811

Awesome, thank you!



-- 
真実はいつも一つ！/ Always, there's only one truth!
-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
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: Enable Drm Panic (system-wide)

[Chris Adams]

Once upon a time, Jocelyn Falempe  said:
> It's no longer necessary to disable VT_CONSOLE to enable DRM_PANIC.
> So I have updated the wiki page, and also moved it to
> self-contained-change, as there are no more system-wide impact by
> enabling DRM_PANIC.

Thanks for the additional work on this.
-- 
Chris Adams 
-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
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: libarrow (Apache Arrow) SONAME bump in rawhide

[Kaleb Keithley]

On Tue, Apr 23, 2024 at 1:24 PM Adam Williamson 
wrote:

> On Tue, 2024-04-23 at 10:15 -0700, Adam Williamson wrote:
> > On Mon, 2024-04-22 at 11:04 -0400, Kaleb Keithley wrote:
> > > Coming soon.
> > >
> > > Updating to Arrow 16.0.0
> >
> > Thanks for the minimal notice, but that is not how this is supposed to
> > be done.
> >
> > You are supposed to mail all the maintainers of dependent components
> > and provide at least a week to co-ordinate rebuilds in a side tag, then
> > send out an update with all the rebuilds together.
>

Well, then consider this a call for someone whose $dayjob it is to do this
to take over ownership of libarrow and liborc.

I packaged Apache Arrow and ORC (libarrow, liborc) for *Ceph*. But even
packaging Ceph is not really part of my $dayjob.

I did not sign up to build dozens of other packages or jump through side
tag hoops.

I have libarrow-17 essentially ready to go. Let me know if you're
interested in taking it over.

-- 

Kaleb
-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
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: Flaws detected by static analyzers in Fedora 41 Critical Path Packages

[Siteshwar Vashisht]

On Tue, Jul 9, 2024 at 2:28 PM Richard W.M. Jones  wrote:
>
> On Tue, Jul 09, 2024 at 01:37:20PM +0200, Siteshwar Vashisht wrote:
> > I request somebody from the tools team to comment on these concerns. We only
> > report the defects identified by gcc, clang etc.
>
> You wrote:
>
>   > TLDR: This report[2] contains 73976 identified defects.
>
> and again above said they were "defects".  Well, we know the ones in
> libvirt & QEMU are nearly all NOT defects, so don't use that word.
>

I have opened a GitHub issue[1] to follow up on this suggestion. Thanks!

[1] https://github.com/csutils/csdiff/issues/193

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

Maintainer of kata-containers

[Emanuel Lima]

I would like to become the official and only maintainer of kata-containers
as etrunko (Eduardo Lima) has been non responsive to me and has left Red
Hat (as far as I know). Does anyone know how I should proceed or who should
I contact?

Thanks in advance.

-- 

Kind Regards,

Emanuel Lima

Software Engineer, Virtualization CI
-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
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: libarrow (Apache Arrow) SONAME bump in rawhide

[Stephen Smoogen]

On Tue, 23 Jul 2024 at 08:59, Kaleb Keithley  wrote:
>
>
>
> On Tue, Apr 23, 2024 at 1:24 PM Adam Williamson  
> wrote:
>>
>> On Tue, 2024-04-23 at 10:15 -0700, Adam Williamson wrote:
>> > On Mon, 2024-04-22 at 11:04 -0400, Kaleb Keithley wrote:
>> > > Coming soon.
>> > >
>> > > Updating to Arrow 16.0.0
>> >
>> > Thanks for the minimal notice, but that is not how this is supposed to
>> > be done.
>> >
>> > You are supposed to mail all the maintainers of dependent components
>> > and provide at least a week to co-ordinate rebuilds in a side tag, then
>> > send out an update with all the rebuilds together.
>
>
> Well, then consider this a call for someone whose $dayjob it is to do this to 
> take over ownership of libarrow and liborc.
>
> I packaged Apache Arrow and ORC (libarrow, liborc) for *Ceph*. But even 
> packaging Ceph is not really part of my $dayjob.
>
> I did not sign up to build dozens of other packages or jump through side tag 
> hoops.
>

OK what did you sign up for then? I realize it's hot and humid and the
summer tempers are wearing thin, but if this isn't what you are
wanting to do, it might be better for everyone to orphan these things
soon versus hitting a worse part later on. If they are that important
for enough people, then maybe someone will get assigned to them or
volunteer to handle them or just remove them.

> I have libarrow-17 essentially ready to go. Let me know if you're interested 
> in taking it over.
>
> --
>
> Kaleb
> --
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it: 
> https://pagure.io/fedora-infrastructure/new_issue



-- 
Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard
battle. -- Ian MacClaren

-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
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: Maintainer of kata-containers

[Yaakov Selkowitz]

On 7/23/24 09:04, Emanuel Lima wrote:
I would like to become the official and only maintainer of 
kata-containers as etrunko (Eduardo Lima) has been non responsive to me 
and has left Red Hat (as far as I know). Does anyone know how I should 
proceed or who should I contact?


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

--
Yaakov Selkowitz
Principal Software Engineer, Emerging RHEL
Red Hat, Inc.

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

How to make the rpminspect test required to pass Zuul CI?

[Jun Aruga (he / him)]

Hello,

Currently the rpminspect test is executed as non-voting in Zuul CI.[1]
I want to change the setting to make rpminspect required to pass the
Zuul CI on the rpms/rubygem-mysql2 dist-git repository.
Could you tell me how to do it?

Thanks.

[1] 
https://fedora.softwarefactory-project.io/zuul/buildset/d894f015352e42d08844338f0e88722e
[2] https://src.fedoraproject.org/rpms/rubygem-mysql2

-- 
Jun | He - Him | Timezone: UTC+1 or +2

-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
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: How to make the rpminspect test required to pass Zuul CI?

[Cristian Le via devel]

On the dist-git I don't think there is any. For bodhi though you can 
make `gating.yaml` file. Here [1] is one which includes `rpminspect`


```yaml
--- !Policy
product_versions:
  - fedora-*
decision_contexts:
  - bodhi_update_push_stable
subject_type: koji_build
rules:
  - !PassingTestCaseRule {test_case_name: 
fedora-ci.koji-build.rpminspect.static-analysis}


```

[1]: 
https://sourcegraph.com/src.fedoraproject.org/rpms/zlib-ng/-/blob/gating.yaml?L11-13


On 2024/07/23 16:10, Jun Aruga (he / him) wrote:

Hello,

Currently the rpminspect test is executed as non-voting in Zuul CI.[1]
I want to change the setting to make rpminspect required to pass the
Zuul CI on the rpms/rubygem-mysql2 dist-git repository.
Could you tell me how to do it?

Thanks.

[1] 
https://fedora.softwarefactory-project.io/zuul/buildset/d894f015352e42d08844338f0e88722e
[2] https://src.fedoraproject.org/rpms/rubygem-mysql2


--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
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: How to make the rpminspect test required to pass Zuul CI?

[Aleksandra Fedorova]

Hi,

On Tue, Jul 23, 2024 at 4:18 PM Jun Aruga (he / him) 
wrote:

> Hello,
>
> Currently the rpminspect test is executed as non-voting in Zuul CI.[1]
> I want to change the setting to make rpminspect required to pass the
> Zuul CI on the rpms/rubygem-mysql2 dist-git repository.
> Could you tell me how to do it?
>

For Zuul CI you need an entry in the projects.yaml which would override the
job configuration per project.

It should look similar to

*
https://pagure.io/fedora-zuul-jobs-config/blob/master/f/zuul.d/projects.yaml#_61

with the obvious `voting: true` change


>
> Thanks.
>
> [1]
> https://fedora.softwarefactory-project.io/zuul/buildset/d894f015352e42d08844338f0e88722e
> [2] https://src.fedoraproject.org/rpms/rubygem-mysql2
>
> --
> Jun | He - Him | Timezone: UTC+1 or +2
>
> --
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>

-- 
Aleksandra Fedorova
bookwar
-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
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: Maintainer of kata-containers

[Eduardo Lima (Etrunko)]

Hi Emanuel,

Although I've left RH, I'm still active on email. I'm sorry if I missed any
messages you tried sending me, but I couldn't find any from you in my
inbox, until today.



On Tue, Jul 23, 2024 at 10:05 AM Emanuel Lima  wrote:

> I would like to become the official and only maintainer of kata-containers
> as etrunko (Eduardo Lima) has been non responsive to me and has left Red
> Hat (as far as I know). Does anyone know how I should proceed or who should
> I contact?
>
> Thanks in advance.
>
> --
>
> Kind Regards,
>
> Emanuel Lima
>
> Software Engineer, Virtualization CI
>
> --
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>


-- 
Eduardo de Barros Lima ◤✠◢
ebl...@gmail.com
-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

List of long term FTBFS packages to be retired in 1 week

[Miro Hrončok]

Dear maintainers.

Based on the current fail to build from source policy, the following packages
should be retired from Fedora 41 approximately one week before branching.

5 weekly reminders are required, hence the retirement will happen
approximately in 1 week, i.e. around 2024-07-30.

Policy: 
https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/


The packages in rawhide were not successfully built at least since Fedora 38.

This report is based on dist tags.

Packages collected via:
https://github.com/hroncok/fedora-report-ftbfs-retirements/blob/master/ftbfs-retirements.ipynb

If you see a package that was built, please let me know.
If you see a package that should be exempted from the process,
please let me know and we can work together to get a FESCo approval for that.

If you see a package that can be rebuilt, please do so.

Package (co)maintainers
===
adwaita-blue-gtk-theme  abompard, ryanlerch
apmdaekoroglu, jskarvad
aspell-no   jchaloup, ljavorsk, nforro
biboumi misc
efitoolsvladius
fonts-KOI8-Rthan
golang-github-acme-lego @go-sig, eclipseo
golang-github-ajstarks-deck @go-sig, eclipseo
golang-github-prometheus@go-sig, fuller, mikelo2
golang-storj-drpc   @go-sig, mikelo2
grpcurl @go-sig, mikelo2
gtk+extra   rrankin
jack_captureverdurin
jowldaxelrod
ksensorskkofler
libgsystem  walters
libtpcmisc  ankursinha
netbox  ignatenkobrain, ngompa
new-session-manager eeickmeyer
octave-odepkg   cbm, orphan
open-policy-agent   @go-sig, olem
openstack-java-sdk  fsimonce
pesign-test-app javierm, nfrayer, pjones, rharwood
php-doctrine-doctrine-bundleorphan
php-phpdocumentor-reflection1   siwinski
php-symfony siwinski
php-symfony-psr-http-message-bridge siwinski
php-symfony3remi, siwinski
postsrsdduck
unicornscan robert
wiki2beamer sdyroff

The following packages require above mentioned packages:
Depending on: adwaita-blue-gtk-theme (1)
gnofract4d (maintained by: orphan)
gnofract4d-4.3-17.fc41.src requires adwaita-blue-gtk-theme

Depending on: golang-github-ajstarks-deck (4)
golang-github-ajstarks-svgo (maintained by: @go-sig, eclipseo, jchaloup)
		golang-github-ajstarks-svgo-0-23.20210108git7a3c8b5.fc41.src requires 
golang(github.com/ajstarks/deck/generate)
	 
golang-github-ajstarks-svgo-personal-devel-0-23.20210108git7a3c8b5.fc41.noarch 
requires golang(github.com/ajstarks/deck/generate)


golang-github-aclements-gg (maintained by: @go-sig, alexsaezm, jchaloup)
		golang-github-aclements-gg-0-20.20180422gitabd1f79.fc41.src requires 
golang(github.com/ajstarks/svgo)
		golang-github-aclements-gg-devel-0-20.20180422gitabd1f79.fc41.noarch requires 
golang(github.com/ajstarks/svgo)


golang-github-ajstarks-deck (maintained by: @go-sig, eclipseo)
		golang-github-ajstarks-deck-0-0.15.20210114git30c9fc6.fc38.src requires 
golang(github.com/ajstarks/svgo), golang(github.com/ajstarks/svgo/float)


golang-x-perf (maintained by: @go-sig, alexsaezm, jchaloup)
		golang-x-perf-0-0.23.20210123gitbdcc622.fc40.src requires 
golang(github.com/aclements/go-gg/generic/slice), 
golang(github.com/aclements/go-gg/ggstat), golang(github.com/aclements/go-gg/table)
		golang-x-perf-devel-0-0.23.20210123gitbdcc622.fc40.noarch requires 
golang(github.com/aclements/go-gg/generic/slice), 
golang(github.com/aclements/go-gg/ggstat), golang(github.com/aclements/go-gg/table)


Depending on: golang-github-prometheus (31)
golang-contrib-opencensus-exporter-stackdriver (maintained by: @go-sig, 
alexsaezm)
		golang-contrib-opencensus-exporter-stackdriver-0.13.14-1.fc41.src requires 
golang(github.com/prometheus/prometheus/model/value)
		golang-contrib-opencensus-exporter-stackdriver-devel-0.13.14-1.fc41.noarch 
requires golang(github.com/prometheus/prometheus/model/value)


golang-github-oklog (maintained by: @go-sig, eclipseo)
		golang-github-oklog-0.3.2-19.20190701gitca7cdf5.fc40.src requires 
golang(github.com/prometheus/prometheus/util/testutil)


golang-opentelemetry-contrib-0.20 (maintained by: @go-sig, alexsaezm)
		golang-opentelemetry-contrib-0.20-0.20.0-12.fc41.src requires 
golang(

Re: Maintainer of kata-containers

[Eduardo Lima (Etrunko)]

There you go, I've promoted you to admin role on the project.

On Tue, Jul 23, 2024 at 11:28 AM Eduardo Lima (Etrunko) 
wrote:

> Hi Emanuel,
>
> Although I've left RH, I'm still active on email. I'm sorry if I missed
> any messages you tried sending me, but I couldn't find any from you in my
> inbox, until today.
>
>
>
> On Tue, Jul 23, 2024 at 10:05 AM Emanuel Lima  wrote:
>
>> I would like to become the official and only maintainer of
>> kata-containers as etrunko (Eduardo Lima) has been non responsive to me and
>> has left Red Hat (as far as I know). Does anyone know how I should proceed
>> or who should I contact?
>>
>> Thanks in advance.
>>
>> --
>>
>> Kind Regards,
>>
>> Emanuel Lima
>>
>> Software Engineer, Virtualization CI
>>
>> --
>> ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>> Fedora Code of Conduct:
>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives:
>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>> Do not reply to spam, report it:
>> https://pagure.io/fedora-infrastructure/new_issue
>>
>
>
> --
> Eduardo de Barros Lima ◤✠◢
> ebl...@gmail.com
>


-- 
Eduardo de Barros Lima ◤✠◢
ebl...@gmail.com
-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
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: How to make the rpminspect test required to pass Zuul CI?

[Aleksandra Fedorova]

Hi,

On Tue, Jul 23, 2024 at 4:26 PM Cristian Le via devel <
devel@lists.fedoraproject.org> wrote:

> On the dist-git I don't think there is any. For bodhi though you can
> make `gating.yaml` file. Here [1] is one which includes `rpminspect`
>
> ```yaml
> --- !Policy
> product_versions:
>- fedora-*
> decision_contexts:
>- bodhi_update_push_stable
> subject_type: koji_build
> rules:
>- !PassingTestCaseRule {test_case_name:
> fedora-ci.koji-build.rpminspect.static-analysis}
>
> ```
>

We are mixing CI systems here.

Zuul CI acts on open Pull Requests on Pagure and reports results back to
Pagure. It is not controlled by gating.yaml

gating.yaml controls gating of Bodhi updates which happens after the change
is merged and built in Koji.



> [1]:
>
> https://sourcegraph.com/src.fedoraproject.org/rpms/zlib-ng/-/blob/gating.yaml?L11-13
>
> On 2024/07/23 16:10, Jun Aruga (he / him) wrote:
> > Hello,
> >
> > Currently the rpminspect test is executed as non-voting in Zuul CI.[1]
> > I want to change the setting to make rpminspect required to pass the
> > Zuul CI on the rpms/rubygem-mysql2 dist-git repository.
> > Could you tell me how to do it?
> >
> > Thanks.
> >
> > [1]
> https://fedora.softwarefactory-project.io/zuul/buildset/d894f015352e42d08844338f0e88722e
> > [2] https://src.fedoraproject.org/rpms/rubygem-mysql2
> >
> --
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>


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

Re: Fedora rawhide (to be f41) and openssl engines

[Gary Buhrmaster]

On Tue, Jul 23, 2024 at 8:55 AM Clemens Lang  wrote:

> However, we should still consider the effect this will have on developers 
> that build software on Fedora — they will also have to specify 
> -DOPENSSL_NO_ENGINE now or see failing builds, and we don’t really see that 
> impact until 41 releases.

Or, perhaps, if they build locally, just
   `dnf install openssl-devel-engine`
once and not have to worry about
changing their build recipes until
OpenSSL 4.0 (or later).

That is certainly going to be a choice
some will make, and you should
always offer that as a possible
solution even if you wish it was not
used.
-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Fedora rawhide (to be f41) and openssl engines

[Clemens Lang]

Hi,

> On 23. Jul 2024, at 16:36, Gary Buhrmaster  wrote:
> 
> On Tue, Jul 23, 2024 at 8:55 AM Clemens Lang  wrote:
> 
>> However, we should still consider the effect this will have on developers 
>> that build software on Fedora — they will also have to specify 
>> -DOPENSSL_NO_ENGINE now or see failing builds, and we don’t really see that 
>> impact until 41 releases.
> 
> Or, perhaps, if they build locally, just
>   `dnf install openssl-devel-engine`
> once and not have to worry about
> changing their build recipes until
> OpenSSL 4.0 (or later).
> 
> That is certainly going to be a choice
> some will make, and you should
> always offer that as a possible
> solution even if you wish it was not
> used.

Sure, people can do that, but they will just see an error saying that 
openssl/engine.h could not be found and start hunting for solutions. Let’s hope 
that until that happens, enough people have blogged about this (or Google has 
indexed this thread) to point them to potential solutions, because otherwise 
this will be a situation of “works on Ubuntu and everything else, but is just 
bad developer experience on Fedora”.

We already saw a number of threads on the mailing list and a ticket reporting 
this precise situation.

I guess from this thread it is pretty clear that there is no consensus on 
improving this for F41, so I’ll stop now.


-- 
Clemens Lang
RHEL Crypto Team
Red Hat



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

Re: Fedora rawhide (to be f41) and openssl engines

[Stephen Smoogen]

On Tue, 23 Jul 2024 at 11:02, Clemens Lang  wrote:
>
> Hi,
>
> > On 23. Jul 2024, at 16:36, Gary Buhrmaster  
> > wrote:
> >
> > On Tue, Jul 23, 2024 at 8:55 AM Clemens Lang  wrote:
> >
> >> However, we should still consider the effect this will have on developers 
> >> that build software on Fedora — they will also have to specify 
> >> -DOPENSSL_NO_ENGINE now or see failing builds, and we don’t really see 
> >> that impact until 41 releases.
> >
> > Or, perhaps, if they build locally, just
> >   `dnf install openssl-devel-engine`
> > once and not have to worry about
> > changing their build recipes until
> > OpenSSL 4.0 (or later).
> >
> > That is certainly going to be a choice
> > some will make, and you should
> > always offer that as a possible
> > solution even if you wish it was not
> > used.
>
> Sure, people can do that, but they will just see an error saying that 
> openssl/engine.h could not be found and start hunting for solutions. Let’s 
> hope that until that happens, enough people have blogged about this (or 
> Google has indexed this thread) to point them to potential solutions, because 
> otherwise this will be a situation of “works on Ubuntu and everything else, 
> but is just bad developer experience on Fedora”.
>
> We already saw a number of threads on the mailing list and a ticket reporting 
> this precise situation.
>
> I guess from this thread it is pretty clear that there is no consensus on 
> improving this for F41, so I’ll stop now.
>

In order for it to be improved, it really needed to be done before the
mass rebuild. After that happens there really isn't much time for
medium to major changes. There are too many other groups all trying to
get their parts fixed and a lot of the Red Hat employees focus more on
getting EL10 beta and EL9.5 items than Fedora. I realize that this
isn't 'ideal' in any form but it is basically what happens every
couple of years when a new EL comes out.

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



-- 
Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard
battle. -- Ian MacClaren

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

Re: Fedora rawhide (to be f41) and openssl engines

[Joe Orton]

On Tue, Jul 23, 2024 at 10:54:12AM +0200, Clemens Lang wrote:
> However, we should still consider the effect this will have on 
> developers that build software on Fedora — they will also have to 
> specify -DOPENSSL_NO_ENGINE now or see failing builds, and we don’t 
> really see that impact until 41 releases.

Yup, exactly. This is only a bad outcome and will be seen (correctly) by 
upstream projects as Fedora shipping a broken OpenSSL when we start 
wasting their time with people filing "I couldn't build on Fedora" bug 
reports.

The time Fedora maintainers have spent on this is a sunk cost, doing 
nothing is clearly inferior to all other options. At minimum we should 
ship F41 with openssl-devel Requires: openssl-engine-devel again. 
(Having OpenSSL  #define OPENSSL_NO_ENGINE properly is 
by far my preferred option)

Regards, Joe

-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
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: Maintainer of kata-containers

[Emanuel Lima]

Thanks Eduardo. I wasn't aware of your gmail account.
-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Summary/Minutes from today's FESCo Meeting (2024-07-23)

[Zbigniew Jędrzejewski-Szmek]

Text Log: 
https://meetbot.fedoraproject.org/meeting_matrix_fedoraproject-org/2024-07-23/fesco.2024-07-23-17.00.log.txt
HTML Log: 
https://meetbot.fedoraproject.org/meeting_matrix_fedoraproject-org/2024-07-23/fesco.2024-07-23-17.00.log.html
Text Minutes: 
https://meetbot.fedoraproject.org/meeting_matrix_fedoraproject-org/2024-07-23/fesco.2024-07-23-17.00.txt
HTML Minutes: 
https://meetbot.fedoraproject.org/meeting_matrix_fedoraproject-org/2024-07-23/fesco.2024-07-23-17.00.html

Meeting summary
---
* TOPIC: Init Process
* TOPIC: #3230 Mass license change
* INFO: Votes in the ticket: (+5, 0, 0)

* AGREED: All old license strings shall be converted to SPDX format. For
  licenses where a 1:1 mapping exists from the legacy Fedora tag to SPDX,
  the normal SPDX tag shall be used. For licenses where the old license tag
  maps to more than one possible license in the SPDX database, a tag in the
  form of LicenseRef--* where * is the
  old Fedora identifier shall be used. In both cases, a comment shall be
  included in the spec file to indicate that the conversion was done
  automatically and review is warranted. For the second case, the comment
  should also indicate that the maintainers should update to normal SPDX
  tags after review. (+7, 0, 0)

* TOPIC: #3235 Change: Fedora KDE Plasma Mobile
* AGREED: APPROVED (+8, 0, -1)
* ACTION: Change owners to document which hardware this is for
* LINK: 
https://docs.fedoraproject.org/en-US/program_management/pgm_guide/sop/spins-keepalive/

* TOPIC: #3248 Git Forge Evaluation FESCo Rep(s)
* INFO: Stephen Gallagher volunteered to be the rep
* AGREED: Stephen Gallagher is approved as FESCo rep for the Git Forge 
Evaluation project (+8, 0, 0)

* TOPIC: Next week's chair
* ACTION: jednorozec will chair the next meeting.

* TOPIC: Open Floor
* INFO: The session in two weeks will most likely be moved to the live 
"Meet your FESCo" panel during Flock.
* LINK: https://cfp.fedoraproject.org/flock-2024/talk/9VEHJX/

Action items

* Change owners to document which hardware KDE Plasma Mobile spin is for 
* jednorozec will chair the next meeting. 
-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Fedora rawhide compose report: 20240723.n.0 changes/updates

[Kevin Fenzi]

Hi everyone. 

The mass rebuild finished yesterday and after some untagging and
restarting composes, the rawhide compose finished. 

For the next 2 weeks, You can see the report at: 

https://kojipkgs.fedoraproject.org/compose/rawhide/Fedora-Rawhide-20240723.n.0/logs/changelog-Fedora-Rawhide-20240723.n.0.verbose

Warning: it's 10MB

Unfortunately the oom killer killed the compose just after it finished,
but before it could sync and send the report. I am manually syncing it
now and it should be done in the next few hours. 

kevin


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

[Heads up]: python-PyGithub major update coming to rawhide soon

[Sandro via devel]

Hi,

PyGithub will be updated to 2.3.0 in rawhide soon. This is a major 
update and according to upstream's changelog [1] it comes with breaking 
changes. The first update containing breaking changes is 1.59.0. We are 
currently on 1.58.2.


Please take a look yourself if it affects your package.

I did a preliminary smoke test in Copr [2] and none of the dependent 
packages broke. Of course, some issues may only reveal themselves once 
the packages are being used with PyGithub 2.3.0.


The update is required by Spyder, which I will be updating to version 
6.0.0b3 at the same time. Ideally, I would like to update F40 to the 
same release. But for that to happen, I need to be sure that PyGithub 
2.3.0 does not cause any trouble for packages depending on it.


Strictly speaking, major updates should be avoided within stable 
releases. But since the set of dependent packages is rather small, I'd 
like to evaluate if it might be possible to get F40 updated as well.


Your feedback is welcome.

[1] https://github.com/PyGithub/PyGithub/blob/v2.3.0/doc/changes.rst
[2] https://copr.fedorainfracloud.org/coprs/gui1ty/pygithub/builds/

Cheers,

--
Sandro
FAS:   gui1ty
Matrix:Penguinpee
Elsewhere: [Pp]enguinpee

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

RPM build warning

[Steve Dickson]

Hello

I've got the following warning

RPM build warnings:
source_date_epoch_from_changelog set but %changelog is missing

The spec file definitely has a %changelog section.
What is it the warning about?

tia,

steved.

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

Re: RPM build warning

[Zbigniew Jędrzejewski-Szmek]

On Tue, Jul 23, 2024 at 04:31:31PM -0400, Steve Dickson wrote:
> Hello
> 
> I've got the following warning
> 
> RPM build warnings:
> source_date_epoch_from_changelog set but %changelog is missing
> 
> The spec file definitely has a %changelog section.
> What is it the warning about?

What package? Link to build?

Fedora sets %source_date_epoch_from_changelog globally, and that requires
the changelog to have at least one entry.

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

Re: RPM build warning

[Steve Dickson]

On 7/23/24 4:36 PM, Zbigniew Jędrzejewski-Szmek wrote:

On Tue, Jul 23, 2024 at 04:31:31PM -0400, Steve Dickson wrote:

Hello

I've got the following warning

RPM build warnings:
 source_date_epoch_from_changelog set but %changelog is missing

The spec file definitely has a %changelog section.
What is it the warning about?


What package? 

libtirpc


Link to build?

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



Fedora sets %source_date_epoch_from_changelog globally, and that requires
the changelog to have at least one entry.

The package has been around since 2006 so the spec
files has a number entries.

steved.


Zbyszek


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

Re: RPM build warning

[Elliott Sales de Andrade]

On Tue, Jul 23, 2024 at 4:56 PM Steve Dickson  wrote:
> On 7/23/24 4:36 PM, Zbigniew Jędrzejewski-Szmek wrote:
> > On Tue, Jul 23, 2024 at 04:31:31PM -0400, Steve Dickson wrote:
> >> Hello
> >>
> >> I've got the following warning
> >>
> >> RPM build warnings:
> >>  source_date_epoch_from_changelog set but %changelog is missing
> >>
> >> The spec file definitely has a %changelog section.
> >> What is it the warning about?
> >
> > What package?
> libtirpc
>
> > Link to build?
> https://koji.fedoraproject.org/koji/taskinfo?taskID=120921123
>

The error is on the line above the warning:

error: bad date in %changelog: Tue Jul 23 Steve Dickson
 - 1.3.5-0

> >
> > Fedora sets %source_date_epoch_from_changelog globally, and that requires
> > the changelog to have at least one entry.
> The package has been around since 2006 so the spec
> files has a number entries.
>
> steved.
> >
> > Zbyszek
>

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

Review swaps once again.

[Peter Lemenkov]

Hello All!
I've got a few packages waiting for review and I am willing to review
yours in return.

First I have two Erlang-related packages. Both passes unit-tests,
builds just fine,

* https://bugzilla.redhat.com/2299556 - erlang-gpb, a modern Google
Protobuf compiler for Erlang.
* https://bugzilla.redhat.com/2296364 - erlang-hut, yet another one
logging library for Erlang.

Also I have these three Python packages:

* https://bugzilla.redhat.com/2297640 - python-base58, Base58 and
Base58Check implementation
* https://bugzilla.redhat.com/2293913 - python-lru-dict, A fast and
memory efficient LRU cache
* https://bugzilla.redhat.com/2293503 -
python-pygments-lexer-solidity, Solidity lexer for Pygments

Please choose any of these ones.
-- 
With best regards, Peter Lemenkov.
-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Schedule for Tuesday's FESCo Meeting (2024-07-23)

[Kevin Kofler via devel]

Zbigniew Jędrzejewski-Szmek wrote:
> #3244 Change: Retire Python 2.7
> https://pagure.io/fesco/issue/3244
> APPROVED (+8, 0, 0)

This is going to break the build of a whole bunch of compatibility packages, 
which will in turn break a lot of software in Fedora.

Do you expect packages to do what Qt5WebEngine did for EPEL and bundle their 
own copy of Python 2 to be used at build time? This just does not make any 
sense whatsoever.

For Qt5WebEngine, there is now a patch from Arch Linux to make it build with 
Python 3 that we could apply, but both the Qt 4 and 5 QtWebKit require 
Python 2 to build. As do several other packages, I am pretty sure.

Kevin Kofler

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

Re: Schedule for Tuesday's FESCo Meeting (2024-07-23)

[Kevin Kofler via devel]

Zbigniew Jędrzejewski-Szmek wrote:
> #3242 Change: Opt-In Metrics for Fedora Workstation
> https://pagure.io/fesco/issue/3242
> APPROVED (+6, 0, 0)

And this one is yet another case of FESCo rubberstamping a change without 
even any dissenting vote despite loads of negative mailing list feedback. I 
really wonder what we give feedback for at all if FESCo OKs any and all 
changes (except ones that propose to replace GNOME as the default desktop 
environment) anyway.

Kevin Kofler

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

Re: Schedule for Tuesday's FESCo Meeting (2024-07-23)

[Josh Boyer]

On Tue, Jul 23, 2024, 6:38 PM Kevin Kofler via devel <
devel@lists.fedoraproject.org> wrote:

> Zbigniew Jędrzejewski-Szmek wrote:
> > #3242 Change: Opt-In Metrics for Fedora Workstation
> > https://pagure.io/fesco/issue/3242
> > APPROVED (+6, 0, 0)
>
> And this one is yet another case of FESCo rubberstamping a change without
> even any dissenting vote despite loads of negative mailing list feedback.
> I
> really wonder what we give feedback for at all if FESCo OKs any and all
> changes (except ones that propose to replace GNOME as the default desktop
> environment) anyway.
>

FESCo is an elected body.  If people aren't happy with how they are being
represented, I would encourage them to find candidates they feel will
represent their interests better and get them to run for election.

If they feel that isn't feasible for whatever reason, then I can only
suggest they really think about what they value and whether they feel the
project is headed in a direction that matches those values.  If not, they
should consider if there's another productive way to change things or if
their time and energy is being spent on something that benefits them.

Kevin, you've been in Fedora for as long as I have and that's a very long
time.  If you still value Fedora as a project and are simply expressing
dissent with a subset of decisions, then perhaps you can phrase it that way
more clearly.  If you really feel the project isn't being represented well
at this point, then why are you still here?  I don't particularly want to
see you go, but I struggle to think of any posts in recent memory that I'd
phrase as positive.

josh


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

Re: Schedule for Tuesday's FESCo Meeting (2024-07-23)

[Gary Buhrmaster]

On Tue, Jul 23, 2024 at 10:30 PM Kevin Kofler via devel
 wrote:
>
> Zbigniew Jędrzejewski-Szmek wrote:
> > #3244 Change: Retire Python 2.7
> > https://pagure.io/fesco/issue/3244
> > APPROVED (+8, 0, 0)
>
> This is going to break the build of a whole bunch of compatibility packages,
> which will in turn break a lot of software in Fedora.
>
> Do you expect packages to do what Qt5WebEngine did for EPEL and bundle their
> own copy of Python 2 to be used at build time? This just does not make any
> sense whatsoever.
>
> For Qt5WebEngine, there is now a patch from Arch Linux to make it build with
> Python 3 that we could apply, but both the Qt 4 and 5 QtWebKit require
> Python 2 to build. As do several other packages, I am pretty sure.

I believe qt5-qtwebkit uses python3 for builds
(I believe the qt4 variant does use python2,
but a quick repoquery indicates no fedora
package depends on qtwebkit-devel, although
I admit the query may have been wrong,
and I think it goes without question that there
will be some independent projects that are
still on qt4 and may use qtwebkit).

Four (or so) years ago about 30 packages
needed a FESCo exception for python2.
It may be worth reviewing that list to
insure the packages have been updated
(as I recall, many were close to being
updated upstream, but the Fedora and
upstream release schedules required a
formal exception).
-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Schedule for Tuesday's FESCo Meeting (2024-07-23)

[Gary Buhrmaster]

On Wed, Jul 24, 2024 at 12:23 AM Gary Buhrmaster
 wrote:

> I believe qt5-qtwebkit uses python3 for builds
> (I believe the qt4 variant does use python2,
> but a quick repoquery indicates no fedora
> package depends on qtwebkit-devel, although
> I admit the query may have been wrong,
> and I think it goes without question that there
> will be some independent projects that are
> still on qt4 and may use qtwebkit).

And, FWIW, it appears that qtwebkit has been
FTBFS since F39, so qtwebkit could end up
being a moot point.
-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: RPM build warning

[Steve Dickson]

On 7/23/24 5:04 PM, Elliott Sales de Andrade wrote:

On Tue, Jul 23, 2024 at 4:56 PM Steve Dickson  wrote:

On 7/23/24 4:36 PM, Zbigniew Jędrzejewski-Szmek wrote:

On Tue, Jul 23, 2024 at 04:31:31PM -0400, Steve Dickson wrote:

Hello

I've got the following warning

RPM build warnings:
  source_date_epoch_from_changelog set but %changelog is missing

The spec file definitely has a %changelog section.
What is it the warning about?


What package?

libtirpc


Link to build?

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



The error is on the line above the warning:

error: bad date in %changelog: Tue Jul 23 Steve Dickson
 - 1.3.5-0

Thank you... I didn't see I forgot the year...

Sorry for the noise!

steved.




Fedora sets %source_date_epoch_from_changelog globally, and that requires
the changelog to have at least one entry.

The package has been around since 2006 so the spec
files has a number entries.

steved.


Zbyszek






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

Re: Schedule for Tuesday's FESCo Meeting (2024-07-23)

[Gary Buhrmaster]

On Tue, Jul 23, 2024 at 10:38 PM Kevin Kofler via devel
 wrote:

> And this one is yet another case of FESCo rubberstamping a change without
> even any dissenting vote despite loads of negative mailing list feedback.

How can one determine "loads"?  Since the
feedback itself is opt-in, no statistically
valid conclusion can be reached based on
the feedback received(*).  FESCo needs to
review the feedback that was received,
and use their best judgement as to whether
to approve or disapprove, and no one
should expect there to be a dissenting
vote just because of negative feedback.




(*) And in addition, there is lots of cases
where only those with negative feedback
will decide to "opt-in" to offer an opinion,
as they are motivated.
-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Schedule for Tuesday's FESCo Meeting (2024-07-23)

[Kevin Kofler via devel]

Am Mittwoch, 24. Juli 2024 02:41:12 CEST schrieb Gary Buhrmaster:

And, FWIW, it appears that qtwebkit has been
FTBFS since F39, so qtwebkit could end up
being a moot point.


It built fine in the F39 mass rebuild, only started failing in the F40 one. 
So it is NOT in the list of packages to be retired in this cycle. I will 
try to fix the FTBFS ASAP, but the unilateral removal of Python 2 is going 
to make it a lot harder to get this package to build again.


The current error is just due to an incompatible libxslt change requiring a 
"const" to be added somewhere:

https://bugzilla.redhat.com/show_bug.cgi?id=2261634#c4

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

Re: Schedule for Tuesday's FESCo Meeting (2024-07-23)

[Kevin Kofler via devel]

Am Mittwoch, 24. Juli 2024 02:52:44 CEST schrieb Gary Buhrmaster:

On Tue, Jul 23, 2024 at 10:38 PM Kevin Kofler via devel
 wrote:


And this one is yet another case of FESCo rubberstamping a change without
even any dissenting vote despite loads of negative mailing list feedback.


How can one determine "loads"?  Since the
feedback itself is opt-in, no statistically
valid conclusion can be reached based on
the feedback received(*).  FESCo needs to
review the feedback that was received,
and use their best judgement as to whether
to approve or disapprove, and no one
should expect there to be a dissenting
vote just because of negative feedback.


I would actually expect FESCo to unanimously vote against the feature if 
the feedback on the mailing list is overwhelmingly negative. Or at least a 
majority of FESCo, if it is controversial. But unanimous approval shows 
that the feedback on the mailing list has been completely ignored, making 
the feedback process entirely useless.



(*) And in addition, there is lots of cases
where only those with negative feedback
will decide to "opt-in" to offer an opinion,
as they are motivated.


If there are not enough people motivated enough to comment in favor of the 
Change, this shows that the Change is not valuable enough to be 
implemented. If in addition, enough people object to the Change for good 
reasons, it follows that the Change should be rejected.


The big issue with the process is that there is this ground assumption in 
Fedora that change is inherently good, and hence any Change should be 
approved by default. But IMHO, Fedora used to already be almost perfect, to 
the point where changing anything could only possibly make it worse. And, 
again IMHO, make it worse the Changes did. Some Changes globally increased 
the size of the distribution (though admittedly a lot of the creeping bloat 
also comes from upstream feature creep beyond the Fedora Project's 
control). Some Changes needlessly broke backwards compatibility, making 
existing software users were still relying on suddenly break. (The "Retire 
Python 2.7" Change is in that category.) Some Changes replaced working 
technologies with incomplete and/or buggy replacements that do not work for 
users' workflows. Sometimes, an opt-out is possible (and then I end up 
opting out on my machines more often than not, making my setup diverge more 
and more from the default), sometimes the replacement is unconditionally 
forced onto all users (and sometimes the opt-out gets silently discontinued 
in a later release without even a new Change). Some Changes were about 
gradually making native distribution packages second-class citizens, second 
to inferior technologies such as atomic images, containerized applications 
(Flatpak, Docker, …), etc. Some Changes are a threat to users' privacy. 
(The "Opt-In Metrics for Fedora Workstation" Change is in that category. 
All the more if the opt-in process uses the planned weasel wording to trick 
users into "opting in".) Some Changes are a threat to users' freedom, e.g., 
by offering proprietary software for download through various means. And 
there are probably more reasons I and others objected to Changes. Those 
objections were unfortunately never treated by FESCo as a reason to reject 
the Change.


   Kevin Kofler
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
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: [Heads up]: python-PyGithub major update coming to rawhide soon

[Sandro via devel]

On 23-07-2024 20:30, Sandro via devel wrote:
PyGithub will be updated to 2.3.0 in rawhide soon. This is a major 
update and according to upstream's changelog [1] it comes with breaking 
changes. The first update containing breaking changes is 1.59.0. We are 
currently on 1.58.2.


Please take a look yourself if it affects your package.

I did a preliminary smoke test in Copr [2] and none of the dependent 
packages broke. Of course, some issues may only reveal themselves once 
the packages are being used with PyGithub 2.3.0.


I forgot to list the packages depending on python-PyGithub, though all 
maintainers were in cc of the original message:


$ fedrq wrsrc -F name -Xs python-PyGithub
azure-cli
python-keep
python-ogr
python-papermill

I'll push the update before end of day (UTC).

-- Sandro

--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
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: [Java related] packaging Italian ID card middleware

[Björn Persson]

Kevin Kofler via devel wrote:
> And at least the German stuff (and the Italian, Portuguese, and Estonian 
> ones) is Free Software. The Austrian ID Austria app is entirely proprietary. 
> Though, as far as I know, you can buy physical FIDO2 hardware, then go 
> register that with the ID Austria office, and then log in on the ID Austria 
> website with any FIDO2 enabled browser and the hardware you bought. But the 
> default workflow goes through a proprietary smartphone app.

I wish I were allowed to use FIDO2. The dominant ID protocol in Sweden
is called BankID. It's a proprietary and secretive protocol that
requires a proprietary app that requires an operating system from
either Apple or Google – or sometimes Microsoft, but in many cases not
even Windows is allowed. No FIDO2 or other open standard is allowed.

It's becoming ever more difficult to be a Fedora user in Sweden.
Several banks require BankID. Members of various associations must have
BankID to log in to membership pages. Many webshops accept payment only
through Klarna, and Klarna now requires everybody to use BankID. Thus
the BankID cartel effectively controls which operating systems have
access to the Swedish market. Users of other operating systems are
severely restricted in which banks they can have accounts in, which
shops they can buy from, et cetera.

By the way, the BankID protocol has fundamental design flaws that enable
an ongoing fraud campaign, and the more BankID becomes a routine in
people's daily lives, the easier it becomes for scammers to convince
victims to click through the BankID dialog that authorizes the scammer
to empty the victim's bank account.

There are also at least two other proprietary ID protocols, which only
government agencies accept. One of those offers a Firefox extension that
can actually be used on a GNU/Linux system. It's unfree, buggy and
unmaintained, but usually works just about well enough to be usable on
the one website I need to access that accepts it.

Government agencies seem to have some requirement to be vendor-neutral,
and they believe that means they must buy incompatible proprietary
services from all the vendors, instead of defining a standard that any
vendor can implement. Everyone who isn't required to be vendor-neutral
accepts only BankID and contributes to strengthening the Apple/Google
duopoly.

Björn Persson


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