[EPEL-devel] Fedora EPEL 7 updates-testing report

[updates]

The following builds have been pushed to Fedora EPEL 7 updates-testing

libfullock-1.0.53-1.el7.1

Details about builds:



 libfullock-1.0.53-1.el7.1 (FEDORA-EPEL-2023-bfc3a6d64d)
 Fast User Level LOCK (FULLOCK) library for C/C++

Update Information:

Updates to libfullock-1.0.53

ChangeLog:

* Mon Aug 28 2023 Hirotaka Wakabayashi  - 1.0.53-1
- Updates to libfullock-1.0.53
* Thu Jul 20 2023 Fedora Release Engineering  - 
1.0.51-1.1
- Rebuilt for https://fedoraproject.org/wiki/Fedora_39_Mass_Rebuild


___
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

[Test-Announce] [Test Week] F39 Anaconda WebUI Installer for Workstation is underway!

[Sumantro Mukherjee]

Hey folks,

This week we will be testing the new Anaconda WebUI installer written with
React and Cockpit. This installer will be default for Workstation for now and
we would like to run through as many tests as possible from [0].
Note from developers/other likely scenarios are
a) Test the new mount point assignment UI and for this the most likely
use case will be that the user will create the partitioning manually
using blivet-gui (which can now be started from the WebUI interface)
and then switch to the mount point assignment and assign/map the
created devices to mount points
b) Test any system with multiple types of disks a combination (LVM and
RAID), and different bootloader configs.

[0] https://testdays.fedoraproject.org/events/165

-- 
//sumantro
Fedora QE
TRIED AND PERSONALLY TESTED, ERGO TRUSTED
___
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

[Bug 2235533] perl-Glib-Object-Introspection-0.051 is available

[bugzilla]

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



--- Comment #2 from Upstream Release Monitoring 
 ---
the-new-hotness/release-monitoring.org's scratch build of
perl-Glib-Object-Introspection-0.051-1.fc38.src.rpm for rawhide failed
http://koji.fedoraproject.org/koji/taskinfo?taskID=105461120


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2235533

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202235533%23c2
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Bug 2235533] perl-Glib-Object-Introspection-0.051 is available

[bugzilla]

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



--- Comment #1 from Upstream Release Monitoring 
 ---
Created attachment 1985726
  --> https://bugzilla.redhat.com/attachment.cgi?id=1985726=edit
Update to 0.051 (#2235533)


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2235533

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202235533%23c1
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Bug 2235533] New: perl-Glib-Object-Introspection-0.051 is available

[bugzilla]

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

Bug ID: 2235533
   Summary: perl-Glib-Object-Introspection-0.051 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Glib-Object-Introspection
  Keywords: FutureFeature, Triaged
  Assignee: ser...@serjux.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: berra...@redhat.com,
perl-devel@lists.fedoraproject.org, ser...@serjux.com
  Target Milestone: ---
Classification: Fedora



Releases retrieved: 0.051
Upstream release that is considered latest: 0.051
Current version/release in rawhide: 0.050-5.fc39
URL: http://search.cpan.org/dist/Glib-Object-Introspection/

Please consult the package updates policy before you issue an update to a
stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/


More information about the service that created this bug can be found at:
https://docs.fedoraproject.org/en-US/package-maintainers/Upstream_Release_Monitoring


Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.


Based on the information from Anitya:
https://release-monitoring.org/project/2924/


To change the monitoring settings for the project, please visit:
https://src.fedoraproject.org/rpms/perl-Glib-Object-Introspection


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2235533

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202235533%23c0
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Donate 1 minute of your time to test upgrades from F38 to F39

[Luna Jernberg]

Did this on my Thinkpad Edge a couple of days ago, and it went fine :)

Den ons 23 aug. 2023 kl 20:23 skrev Miroslav Suchý :
>
> Do you want to make Fedora 39 better? Please spend 1 minute of your time and 
> try to run:
>
> # Run this only if you use default Fedora modules
> # next time you run any DNF command default modules will be enabled again
> sudo dnf module reset '*'
>
> dnf --releasever=39 --setopt=module_platform_id=platform:f39 \
> --enablerepo=updates-testing \
> $(rpm -q fedora-repos-modular >/dev/null && echo 
> --enablerepo=updates-testing-modular) \
> --assumeno distro-sync
>
>
> This command does not replace `dnf system-upgrade`, but it will reveal 
> potential problems.
>
> You may also run `dnf upgrade` before running this command.
>
>
> The `--assumeno` will just test the transaction, but does not make the actual 
> upgrade.
>
>
> In case you hit dependency issues, please report it against the appropriate 
> package.
>
> Or against fedora-obsolete-packages if that package should be removed in 
> Fedora 39. Please check existing reports against fedora-obsolete-packages 
> first:
>
> https://red.ht/2kuBDPu
>
> and also there is already bunch of "Fails to install" (F39FailsToInstall) 
> reports:
>
> https://bugzilla.redhat.com/buglist.cgi?bug_id=2168845_id_type=anddependson=tvp_id=12486533
>
>
> Two notes:
>
> * you may want to run the same command with dnf5 to help test new dnf.
>
> * this command found zero issues on my personal system - great work all 
> everybody!
>
>
> Thank you
>
> Miroslav
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> 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: Adding Passim as a Fedora 40 feature?

[Richard Hughes]

On Mon, 28 Aug 2023 at 21:50, Simo Sorce  wrote:
> It could be improved by using TOFU, so that the window of impersonation
> is small, but requires clients to cache an association and then has
> weird failure modes to be dealt with if one of the actors get re-imaged
> or changes the cert for any reason.

I was thinking of implementing TOFU; good idea or bad idea?

Richard.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
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: Adding Passim as a Fedora 40 feature?

[Richard Hughes]

On Mon, 28 Aug 2023 at 21:14, Chris Adams  wrote:
> Without identification though, it doesn't do that, because there's no
> way for client B to know it is really talking to client A - it could be
> talking to client C with a man-in-the-middle attack and a different
> self-signed cert pretending to be client A.

Yes, that's perfectly fine. Every client receiving files has to verify
the sha256 of the file at the least, and the PKCS#7 signature of the
file in the common case.

Richard.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
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: Adding Passim as a Fedora 40 feature?

[Simo Sorce]

On Mon, 2023-08-28 at 15:14 -0500, Chris Adams wrote:
> Once upon a time, Richard Hughes  said:
> > On Mon, 28 Aug 2023 at 16:27, Leon Fauster via devel
> >  wrote:
> > > whats the benefit of this "self-signed TLS certificate" (as it does
> > > not provide any "security")? Is this stub for something later ... ?
> > 
> > It's a good question. It provides encryption (so client A can provide
> > the file to client B without client C being aware what's being sent)
> 
> Without identification though, it doesn't do that, because there's no
> way for client B to know it is really talking to client A - it could be
> talking to client C with a man-in-the-middle attack and a different
> self-signed cert pretending to be client A.

It helps dealing with passive attacks, but not with active attacks.

It could be improved by using TOFU, so that the window of impersonation
is small, but requires clients to cache an association and then has
weird failure modes to be dealt with if one of the actors get re-imaged
or changes the cert for any reason.


Richard,
given your files are all independently integrity checked, you should
probably not use a TLS connection, because it will be flagged up pretty
rapidly if it is using a self-singed cert anyway.

This thing works only within the same LAN, therefore already "within" a
firewall so it does not need to cross any boundary for which encryption
matters enough.

Finally if an enterprise says TLS is a must you could give an option to
use TLS if said enterprise provides the certs (they will probably
disable the service anyway otherwise).

There is one more option you could entertain, and that is to use a
"well know" pre-shared key instead of certificates for authentication,
will be faster, and will give you the "fake-secure" TLS tunnel without
the self-signed cert headache I think ... (not endorsing this option,
just mentioning it).

HTH,
Simo.

-- 
Simo Sorce
RHEL Crypto Team
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

Re: Adding Passim as a Fedora 40 feature?

[Chris Adams]

Once upon a time, Richard Hughes  said:
> On Mon, 28 Aug 2023 at 16:27, Leon Fauster via devel
>  wrote:
> > whats the benefit of this "self-signed TLS certificate" (as it does
> > not provide any "security")? Is this stub for something later ... ?
> 
> It's a good question. It provides encryption (so client A can provide
> the file to client B without client C being aware what's being sent)

Without identification though, it doesn't do that, because there's no
way for client B to know it is really talking to client A - it could be
talking to client C with a man-in-the-middle attack and a different
self-signed cert pretending to be client A.

-- 
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: Adding Passim as a Fedora 40 feature?

[Richard Hughes]

On Fri, 25 Aug 2023 at 12:42, Richard Hughes  wrote:
> I was thinking of adding Passim as a default-installed and
> default-enabled dep of fwupd in the Fedora 40 release. Before I create
> lots of unnecessary drama, is there any early feedback on what's
> described in https://github.com/hughsie/passim/blob/main/README.md
> please.

Given that I've not been flamed into a cave with the suggestion,
should this be a standalone change or a system-wide change? I could
argue it either way.

Richard.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
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: Adding Passim as a Fedora 40 feature?

[Richard Hughes]

On Mon, 28 Aug 2023 at 11:05, Petr Pisar  wrote:
> V Fri, Aug 25, 2023 at 07:34:35PM +0100, Richard Hughes napsal(a):
> > you need to reboot into the new firmware before the published firmware gets
> > shared;
> Won't this suppress an effeciency of the local sharing?

Yes -- but it's a compromise between efficiency and also broadcasting
to the network that you've just downloaded a firmware with a security
fix and the firmware you're running right now can be attacked.

> If a typical period
> between a download and the reboot is significantly longer than a period in
> which machines check for and download the firmaware, it will happen that all
> machines will sepearately download the firmware from a central server instead
> of downloading it from local peers. Because all the machines will be waiting
> on the reboot.

Yes, that's certainly fair -- although I hope that at least one person
would reboot straight away given it's a security update.

> For how long is the firmware adveritised? As long as it is advertised, people
> know what version you are currently running. This information becomes
> interesting when a new firmware is released. Then you have exactly the same
> problem you want to address.

It's up to the thing publishing -- for the case of firmware payload
(which is a default off option) it's 30 days for firmware and 24 hours
for metadata (which would be default on).

Richard
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
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: Adding Passim as a Fedora 40 feature?

[Richard Hughes]

On Mon, 28 Aug 2023 at 16:27, Leon Fauster via devel
 wrote:
> whats the benefit of this "self-signed TLS certificate" (as it does
> not provide any "security")? Is this stub for something later ... ?

It's a good question. It provides encryption (so client A can provide
the file to client B without client C being aware what's being sent)
-- and also placates various corporate security teams that say that
HTTP without TLS isn't good enough -- even if it's got two other
layers of protection.

Richard
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
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: Adding Passim as a Fedora 40 feature?

[Richard Hughes]

On Mon, 28 Aug 2023 at 15:53, Vít Ondruch  wrote:
> Sorry, I am probably missing something, but how this would help my
> computer (or three I have at home)?

One computer downloads the 2MB from the CDN and the other two download
it from the first computer. This saves you 4MB in bandwidth, and saves
me ~2*1,000,000 MB

> And why there is need to download ~2 MB of data every day? My laptop has
> just a couple devices. I can't see why the metadata for their possible
> update should take that much.

Firmware security updates happen all the time, you wouldn't want to
check monthly.

Richard
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
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: process to unretire/re-review package where some branches still exist?

[Pete Walter]

28.08.2023, 20:08, "Fabio Valentini" :On Mon, Aug 28, 2023 at 7:53 PM Pete Walter  wrote: 28.08.2023, 18:34, "Scott Talbert" : On Mon, 28 Aug 2023, Mark E. Fuller wrote:  Hi all,  I'm trying to unretire golang-github-google-renameio-2 and have completed a  re-review.  However, since the package still exists in F37 and F38, the process for  getting the F39 and rawhide branches "back" and getting control of the  package repo is unclear.  Can anyone advise? It's just the normal process. The fact that F37 and F38 branches exist doesn't change anything. (Packages can't be retired in already-released versions, so that's why F37 and F38 branches still exist.) https://docs.fedoraproject.org/en-US/package-maintainers/Package_Retirement_Process/#claiming No, the process does not work like that in practice. I tried to unretire a few retired rust packages before the 2 month deadline passed where re-review is not needed, but Fabio Valentini told me that I cannot do that because he is still maintaining them for the f36 and f37 branches (it was several months ago). Releng agreed and refused to unretire the packages. https://pagure.io/releng/issue/11372 https://pagure.io/releng/issue/11373 https://pagure.io/releng/issue/11374 I may have overreacted in the ticket but in my opinion this is an incredibly antisocial process where one person has the power to permanently retire something and then refuse to bring it back. I needed it for packaging fractal where as a result of being able to unretire them I had to bundle all dependencies. Same person tried to stop that as well... https://bugzilla.redhat.com/show_bug.cgi?id=2223224Can you please stop spreading lies about me?Anybody can read these public tickets, and see that I didn't refuse*anything* (other than having my maintainer rights taken away from me*without my knowledge*), and that I offered help instead. You gave up your maintainer rights when you retired the package but then you refused to let another person pick it up. You "offering help" was just a way to look nice in the ticket - where is the package now? Let me answer that for you: Still retired. Offered help never arrived. I am done with this discussion. Pete___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
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: Current rawhide iso stops at grub and don't fully work

[Ryan Bach via devel]

> On Mon, 2023-08-28 at 19:19 +, Ryan Bach via devel wrote:
> 
> Which one? There are 36 ISOs in the current Rawhide compose.
> 
> None of the ones tested in openQA testing behaved like this:
> https://openqa.fedoraproject.org/tests/overview?distri=fedora...
https://dl.fedoraproject.org/pub/fedora/linux/development/rawhide/Workstation/x86_64/iso/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
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: Current rawhide iso stops at grub and don't fully work

[Adam Williamson]

On Mon, 2023-08-28 at 19:19 +, Ryan Bach via devel wrote:
> Is this a know issue, if so where could I find the link to the bug/issue? 
> Anyone know?

Which one? There are 36 ISOs in the current Rawhide compose.

None of the ones tested in openQA testing behaved like this:
https://openqa.fedoraproject.org/tests/overview?distri=fedora=Rawhide=Fedora-Rawhide-20230828.n.0=1
-- 
Adam Williamson (he/him/his)
Fedora QA
Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org
https://www.happyassassin.net



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

Current rawhide iso stops at grub and don't fully work

[Ryan Bach via devel]

Is this a know issue, if so where could I find the link to the bug/issue? 
Anyone know?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
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: AVX extensions not detected properly on a Zen 2 CPU?

[Florian Weimer]

* Przemek Klosowski via devel:

> Nevermind, my mistake---I have
> dl_hwcap2=0x0

I think you mean dl_hwcaps_subdirs_active=0x4.  That's actually the
relevant line.

The dl_hwcap2 difference is about FSGSBASE support, which requires
kernel enablement, but doesn't have an XCR0 bit, so support information
is carried in the (software-only) auxiliary vector.

Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
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: process to unretire/re-review package where some branches still exist?

[Fabio Valentini]

On Mon, Aug 28, 2023 at 7:53 PM Pete Walter  wrote:
>
> 28.08.2023, 18:34, "Scott Talbert" :
>
> On Mon, 28 Aug 2023, Mark E. Fuller wrote:
>
>
>  Hi all,
>
>  I'm trying to unretire golang-github-google-renameio-2 and have completed a
>  re-review.
>  However, since the package still exists in F37 and F38, the process for
>  getting the F39 and rawhide branches "back" and getting control of the
>  package repo is unclear.
>  Can anyone advise?
>
>
> It's just the normal process. The fact that F37 and F38 branches exist
> doesn't change anything. (Packages can't be retired in already-released
> versions, so that's why F37 and F38 branches still exist.)
>
> https://docs.fedoraproject.org/en-US/package-maintainers/Package_Retirement_Process/#claiming
>
>
> No, the process does not work like that in practice.
> I tried to unretire a few retired rust packages before the 2 month deadline 
> passed where re-review is not needed, but Fabio Valentini told me that I 
> cannot do that because he is still maintaining them for the f36 and f37 
> branches (it was several months ago). Releng agreed and refused to unretire 
> the packages.
>
> https://pagure.io/releng/issue/11372
> https://pagure.io/releng/issue/11373
> https://pagure.io/releng/issue/11374
>
> I may have overreacted in the ticket but in my opinion this is an incredibly 
> antisocial process where one person has the power to permanently retire 
> something and then refuse to bring it back.
>
> I needed it for packaging fractal where as a result of being able to unretire 
> them I had to bundle all dependencies. Same person tried to stop that as 
> well... https://bugzilla.redhat.com/show_bug.cgi?id=2223224

Can you please stop spreading lies about me?
Anybody can read these public tickets, and see that I didn't refuse
*anything* (other than having my maintainer rights taken away from me
*without my knowledge*), and that I offered help instead.

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

Re: AVX extensions not detected properly on a Zen 2 CPU?

[Przemek Klosowski via devel]

Nevermind, my mistake---I have
dl_hwcap2=0x0

On 8/28/23 14:27, Przemek Klosowski via devel wrote:

On 8/28/23 09:15, Florian Weimer wrote:

* Julian Sikorski:

I have noticed the following message in my kernel log today after I
attempted to decrypt my veracrypt external hard drive:

[20542.328594] AVX2 instructions are not detected.
[20542.382731] AVX or AES-NI instructions are not detected.
...

$ ld.so --list-diagnostics
dl_dst_lib="lib64"
dl_hwcap=0x2
dl_hwcap_important=0x6
dl_hwcap2=0x2
dl_hwcaps_subdirs="x86-64-v4:x86-64-v3:x86-64-v2"
dl_hwcaps_subdirs_active=0x6

That indicates that userspace has access to AVX2 CPU capabilities.
So this must some kernel thing.  Sorry, no idea what is going on.



I have the same ld.so output, but my CPU (Intel Core i7-3770) reports 
only AVX in /proc/cpuinfo (no avx2).



flags        : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge 
mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe 
syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl 
xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor 
ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic 
popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm 
cpuid_fault epb pti ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority 
ept vpid fsgsbase smep erms xsaveopt dtherm ida arat pln pts md_clear 
flush_l1d

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 
https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
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: AVX extensions not detected properly on a Zen 2 CPU?

[Przemek Klosowski via devel]

On 8/28/23 09:15, Florian Weimer wrote:

* Julian Sikorski:

I have noticed the following message in my kernel log today after I
attempted to decrypt my veracrypt external hard drive:

[20542.328594] AVX2 instructions are not detected.
[20542.382731] AVX or AES-NI instructions are not detected.
...

$ ld.so --list-diagnostics
dl_dst_lib="lib64"
dl_hwcap=0x2
dl_hwcap_important=0x6
dl_hwcap2=0x2
dl_hwcaps_subdirs="x86-64-v4:x86-64-v3:x86-64-v2"
dl_hwcaps_subdirs_active=0x6

That indicates that userspace has access to AVX2 CPU capabilities.
So this must some kernel thing.  Sorry, no idea what is going on.



I have the same ld.so output, but my CPU (Intel Core i7-3770) reports 
only AVX in /proc/cpuinfo (no avx2).



flags        : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca 
cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall 
nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology 
nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx 
est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt 
tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm cpuid_fault epb pti 
ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid fsgsbase smep 
erms xsaveopt dtherm ida arat pln pts md_clear flush_l1d

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
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: Add a push update mechanism for https://release-monitoring.org/

[Ryan Bach via devel]

> On Mon, Aug 28, 2023 at 5:29 AM Ryan Bach via devel
>  
> There's a problem with an approach like this: You need to check
> *manually* that the new version builds and doesn't violate any of our
> policies, for example, that it doesn't contain any prohibited items
> (like new code or content that's under non-FOSS / non-commercial /
> non-redistributable licenses).
> 
> For projects where the people who are responsible for the upstream
> project are the same people who maintain the Fedora package, this is
> mostly a non-issue - and for these cases, there's Packit [0] (which I
> think does what you are looking for).
> 
> Fabio
> 
> [0]: https://packit.dev
I mean for anitya https://release-monitoring.org
https://github.com/fedora-infra/anitya/issues
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
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: Donate 1 minute of your time to test upgrades from F38 to F39

[Przemek Klosowski via devel]

On 8/26/23 00:51, Solomon Peachy via devel wrote:


I have twenty-year-old perl scripts that still work just fine, but in my
experience, even couple-years-old python code most likely won't.


I love both perl and python, but have to say that perl stability is 
partly due to the fact that its development stalled at some point so 
that the current perl is 5.34  and Perl 5.0 was released in 1994.


I feel that this stasis is not necessarily so bad---not that perl is 
perfect, but it just works so well for short targeted data manipulation. 
Reminds me of the well know quote(1) : "If you don't want your 
environment/language to develop and improve, you have no heart;  if you 
insist on it constantly changing, you have no brain".


The downside of course is that perl is not getting much in the way of 
new tech like machine learning, AI/LLM, etc, and is not a good match for 
large projects because of too much of duck typing.



(1) "If you're not a liberal when you're 20, you have no heart. If 
you're not a conservative when you're 40, you have no head"---it's 
widely mis-attributed to Winston Churchill but he didn't use it apparently.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
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: process to unretire/re-review package where some branches still exist?

[Sérgio Basto]

On Mon, 2023-08-28 at 20:28 +0300, Mark E. Fuller wrote:
> Hi all,
> 
> I'm trying to unretire golang-github-google-renameio-2 and have 
> completed a re-review.


package golang-github-google-renameio-2 is in the list of 
Retired for
https://fedoraproject.org/wiki/Changes/Mass_Retire_Golang_Leaves

is not retired in practice 
https://src.fedoraproject.org/rpms/golang-github-google-renameio-2

> However, since the package still exists in F37 and F38, the process
> for 
> getting the F39 and rawhide branches "back" and getting control of
> the 
> package repo is unclear.
> Can anyone advise?
> 
> Thanks,
> fuller
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines:
> https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue

-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
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: process to unretire/re-review package where some branches still exist?

[Pete Walter]

28.08.2023, 18:34, "Scott Talbert" :On Mon, 28 Aug 2023, Mark E. Fuller wrote:  Hi all, I'm trying to unretire golang-github-google-renameio-2 and have completed a re-review. However, since the package still exists in F37 and F38, the process for getting the F39 and rawhide branches "back" and getting control of the package repo is unclear. Can anyone advise?It's just the normal process. The fact that F37 and F38 branches existdoesn't change anything. (Packages can't be retired in already-releasedversions, so that's why F37 and F38 branches still exist.)https://docs.fedoraproject.org/en-US/package-maintainers/Package_Retirement_Process/#claiming No, the process does not work like that in practice.I tried to unretire a few retired rust packages before the 2 month deadline passed where re-review is not needed, but Fabio Valentini told me that I cannot do that because he is still maintaining them for the f36 and f37 branches (it was several months ago). Releng agreed and refused to unretire the packages. https://pagure.io/releng/issue/11372https://pagure.io/releng/issue/11373https://pagure.io/releng/issue/11374 I may have overreacted in the ticket but in my opinion this is an incredibly antisocial process where one person has the power to permanently retire something and then refuse to bring it back. I needed it for packaging fractal where as a result of being able to unretire them I had to bundle all dependencies. Same person tried to stop that as well... https://bugzilla.redhat.com/show_bug.cgi?id=2223224 (I am no longer interested in bringing the rust dependencies back. Bundling works much better. Thank you very much.) Pete___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
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: process to unretire/re-review package where some branches still exist?

[Scott Talbert]

On Mon, 28 Aug 2023, Mark E. Fuller wrote:


Hi all,

I'm trying to unretire golang-github-google-renameio-2 and have completed a 
re-review.
However, since the package still exists in F37 and F38, the process for 
getting the F39 and rawhide branches "back" and getting control of the 
package repo is unclear.

Can anyone advise?


It's just the normal process.  The fact that F37 and F38 branches exist 
doesn't change anything.  (Packages can't be retired in already-released 
versions, so that's why F37 and F38 branches still exist.)


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

process to unretire/re-review package where some branches still exist?

[Mark E. Fuller]

Hi all,

I'm trying to unretire golang-github-google-renameio-2 and have 
completed a re-review.
However, since the package still exists in F37 and F38, the process for 
getting the F39 and rawhide branches "back" and getting control of the 
package repo is unclear.

Can anyone advise?

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

Re: F40 Change Proposal: SQLAlchemy 2

[Brad Smith]

I had the same question. Then I noticed this pinned post in Fedora Discussions:

"We are experimenting 2 with using Fedora Discussion as part of the
Changes process. Change announcements (like the one you are reading
right now) will still be sent to the devel-announce mailing list, but
the conversation about each change will take place on Fedora
Discussion at Change Proposals - Fedora Discussion"

So a summary might be sufficient to attract interested readers to the
discussion?

best regards

On Mon, Aug 28, 2023 at 9:52 AM Vít Ondruch  wrote:
>
> Thank you for sharing this. However, I wonder why is just the summary
> shared?
>
>
> Vít
>
>
> Dne 24. 08. 23 v 11:46 Zbigniew Jędrzejewski-Szmek napsal(a):
> > == Summary ==
> > The python-sqlalchemy package is upgraded to major version 2. A
> > compatibility package python-sqlalchemy1.4 is added to the
> > distribution to cater for software which doesn’t yet use the new API,
> > this can be installed side-by-side. Other packages using SQLAlchemy
> > are identified and, if necessary, steps are taken to ensure they use
> > the correct major version package.
> >
> > See 
> > https://discussion.fedoraproject.org/t/f40-change-proposal-sqlalchemy-2/87805
> > for details and to reply.
> > ___
> > 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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F40 Change Proposal: SQLAlchemy 2

[Tomasz Torcz]

On Mon, Aug 28, 2023 at 06:51:52PM +0200, Vít Ondruch wrote:
> 
> 
> Dne 24. 08. 23 v 11:46 Zbigniew Jędrzejewski-Szmek napsal(a):
> > == Summary ==
> > The python-sqlalchemy package is upgraded to major version 2. A
> > compatibility package python-sqlalchemy1.4 is added to the
> > distribution to cater for software which doesn’t yet use the new API,
> > this can be installed side-by-side. Other packages using SQLAlchemy
> > are identified and, if necessary, steps are taken to ensure they use
> > the correct major version package.

> > See 
> > https://discussion.fedoraproject.org/t/f40-change-proposal-sqlalchemy-2/87805
> > for details and to reply.

> Thank you for sharing this. However, I wonder why is just the summary
> shared?

  I guess sharing only a summary is a way to drive interested people to
discussion.fedoraproject.org, where, well, discussion is supposed to
take place.

-- 
Tomasz Torcz   There exists no separation between gods and men:
to...@pipebreaker.pl   one blends softly casual into the other.  — Frank 
Herbert
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F40 Change Proposal: SQLAlchemy 2

[Vít Ondruch]

Thank you for sharing this. However, I wonder why is just the summary 
shared?



Vít


Dne 24. 08. 23 v 11:46 Zbigniew Jędrzejewski-Szmek napsal(a):

== Summary ==
The python-sqlalchemy package is upgraded to major version 2. A
compatibility package python-sqlalchemy1.4 is added to the
distribution to cater for software which doesn’t yet use the new API,
this can be installed side-by-side. Other packages using SQLAlchemy
are identified and, if necessary, steps are taken to ensure they use
the correct major version package.

See 
https://discussion.fedoraproject.org/t/f40-change-proposal-sqlalchemy-2/87805
for details and to reply.
___
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


OpenPGP_signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
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: Add a push update mechanism for https://release-monitoring.org/

[Frantisek Lachman]

Hello,

as Fabio has pointed out, you can use Packit to get your releases to
Fedora via pull-requests. Packit supports both push and newly also
pull workflow. (So you don't need to have access to the upstream
repository because it gets the info about the new version from Release
Monitoring.)

Thanks to it being pull-request-based, there is a Fedora CI involved
and you, as a maintainer, can see the build/test results and decide if
this should go to Fedora or not. Plus, an automatic Koji build and
Bodhi update is possible as well.

It's easy to set up. Here is the documentation for the Fedora automation:
https://packit.dev/docs/fedora-releases-guide#pull-from-upstream-job

And don't be afraid to ask. We, as a Packit team, are happy to help.

František
Packit Product Owner..;)

#packit:fedora.im (Element / Matrix)
#packit:libera.chat (IRC)
he...@packit.dev
@pac...@fosstodon.org (Mastodon)


On Mon, Aug 28, 2023 at 3:01 PM Sérgio Basto  wrote:
>
> On Mon, 2023-08-28 at 13:52 +0100, Sérgio Basto wrote:
> > On Mon, 2023-08-28 at 03:28 +, Ryan Bach via devel wrote:
> > > Faster updates are always as plus.
> > >
> > > Should this be under infrastructure list?
> > >
> > > Thoughts?
> > >
> >
> > if you got a scratch build completed in a bugzilla for example :
> >
> > https://bugzilla.redhat.com/show_bug.cgi?id=2231971
> >
> > you may use my helper script update_from_bugzilla.sh
> >
> > `fedpkg clone package-foo; cd package-foo ;
> > ../update_from_bugzilla.sh`
>
> forgot to add bugzilla number, so should be
>
> `fedpkg clone package-foo; cd package-foo ; ../update_from_bugzilla.sh
> 2231971`
>
> >
> > > Thanks in advance for all the work done to make this distro great.
> > > ___
> > > devel mailing list -- devel@lists.fedoraproject.org
> > > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > > Fedora Code of Conduct:
> > > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > > List Guidelines:
> > > https://fedoraproject.org/wiki/Mailing_list_guidelines
> > > List Archives:
> > > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> > > Do not reply to spam, report it:
> > > https://pagure.io/fedora-infrastructure/new_issue
> >
> > --
> > Sérgio M. B.
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > Fedora Code of Conduct:
> > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines:
> > https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives:
> > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> > Do not reply to spam, report it:
> > https://pagure.io/fedora-infrastructure/new_issue
>
> --
> Sérgio M. B.
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> 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: SPDX Statistics - Voyager 2 edition

[Miroslav Suchý]

Dne 28. 08. 23 v 15:36 Richard Fontana napsal(a):

As for + being valid SPDX syntax, can that be supported by
fedora-license-validate or whatever the tool is called today?

That's probably a good idea, though it would seem to be predicated on
us documenting that any "allowed" license identifier is still allowed
if it adds the `+` operator.


I filed issue https://gitlab.com/fedora/legal/fedora-license-data/-/issues/308

Lets continue there.

--
Miroslav Suchy, RHCA
Red Hat, Manager, Packit and CPT, #brno, #fedora-buildsys
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
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: Adding Passim as a Fedora 40 feature?

[Leon Fauster via devel]

Hi Richard,

Am 25.08.23 um 13:42 schrieb Richard Hughes:

Hi all,

I was thinking of adding Passim as a default-installed and
default-enabled dep of fwupd in the Fedora 40 release. Before I create
lots of unnecessary drama, is there any early feedback on what's
described in https://github.com/hughsie/passim/blob/main/README.md
please.




whats the benefit of this "self-signed TLS certificate" (as it does
not provide any "security")? Is this stub for something later ... ?

--
Leon


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

[Vít Ondruch]

Sorry, I am probably missing something, but how this would help my 
computer (or three I have at home)? Why should I have anything like this 
installed on my computer(s)? Why they should talk "secretly" to each other?


And why there is need to download ~2 MB of data every day? My laptop has 
just a couple devices. I can't see why the metadata for their possible 
update should take that much.



Vít


Dne 25. 08. 23 v 13:42 Richard Hughes napsal(a):

Hi all,

I was thinking of adding Passim as a default-installed and
default-enabled dep of fwupd in the Fedora 40 release. Before I create
lots of unnecessary drama, is there any early feedback on what's
described in https://github.com/hughsie/passim/blob/main/README.md
please.

The tl;dr: is I want to add a mDNS server that reshares the public
firmware update metadata from the LVFS on your LAN. The idea is that
rather than 25 users in an office downloading the same ~2MB file from
the CDN every day, the first downloads from the CDN and the other 24
download from the first machine. All machines still download the
[tiny] jcat file from the CDN still so we know the SHA256 to search
for and verify.

The backstory is that as the fwupd grows and grows (to ChromeOS,
FreeBSD, Windows and macOS) we need to scale things up a couple of
orders of magnitude. This isn't specific to firmware stuff, although I
think it makes a great testcase which we could add dnf or ostree
content to in the future. Comments and questions are most welcome.
Thanks,

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


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

teckit license corrected

[Petr Pisar]

After clarifying an MPL version with an upstream, I corrected a license tag
from:

(LGPL-2.1-or-later OR CPL-1.0) AND (LGPL-2.1-or-later OR GPL-2.0-or-later OR 
MPL-2.0 OR MPL-1.1)

to:

(LGPL-2.1-or-later OR CPL-1.0) AND (LGPL-2.1-or-later OR GPL-2.0-or-later OR 
MPL-2.0)

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

Announcing qatlib soversion bump in next release

[Giovanni Cabiddu]

Hi All,

QATlib 23.08 (https://github.com/intel/qatlib) is going to be released
in about 2 weeks. This will include a soversion bump (from 3 to 4) due
to an ABI breakage.
The API between this and the previous version is the same, however, the
ABI changed due to a change in register allocation in few functions
that have been implemented in the new version (those functions in the
previous version were ignoring all input parameters and returning an
UNSUPPORTED return code).

I will coordinate with the maintainers of the dependent packages
(qatlib and qatengine) so they are rebuilt once qatlib is be updated.

Regards,

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

RFC: Pull request for zlib-ng compat Was: zlib-ng as a compat replacement for zlib

[Tulio Magno Quites Machado Filho]

I went ahead and started to modify Jacek's initial proposal [1] in order
to integrate the feedback from this thread as well as some changes I had
in mind.

I have created a RFC pull request [2]. Hopefully this will help answer
some of the questions we've seen here. Feedback is appreciated.

I have also created packages in a Copr project [3], but I haven't tested
this yet.

Future work:
 - Run tests using these packages.
 - Write the F40 change request based on the RFC pull request.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=2145239
[2] https://src.fedoraproject.org/rpms/zlib-ng/pull-request/3
[3] https://copr.fedorainfracloud.org/coprs/tuliom/zlib-ng/

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

[Bug 2120427] perl-Astro-FITS-CFITSIO-1.16 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=2120427
Bug 2120427 depends on bug 2122431, which changed state.

Bug 2122431 Summary: Review Request: perl-Alien-CFITSIO - Build and Install the 
CFITSIO library
https://bugzilla.redhat.com/show_bug.cgi?id=2122431

   What|Removed |Added

 Status|POST|CLOSED
 Resolution|--- |RAWHIDE




-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2120427
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Bug 2229332] perl-App-cpm-0.997013 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=2229332
Bug 2229332 depends on bug 2230468, which changed state.

Bug 2230468 Summary: Review Request: perl-Proc-ForkSafe - Help make objects 
fork safe
https://bugzilla.redhat.com/show_bug.cgi?id=2230468

   What|Removed |Added

 Status|POST|CLOSED
 Resolution|--- |RAWHIDE




-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2229332
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: SPDX Statistics - Voyager 2 edition

[Richard Fontana]

On Mon, Aug 28, 2023 at 8:30 AM Fabio Valentini  wrote:

> What's the commended approach for packages that use deprecated
> identifiers then? I would rather not just convert "GPL-2.0" to
> "GPL-2.0-or-later" or "GPL-2.0-only", since it's almost always not
> obvious which one was originally intended. Do we need to file issues
> with upstream projects and ask them to clarify?

That is probably not worthwhile in most cases. I think it makes more
sense to document some general policies about this.

For example, any Rust crate metadata using `GPL-2.0` (i.e.., *seeming*
to use the deprecated SPDX identifier) can probably be assumed to mean
`GPL-2.0-only` if there is no other information in the project
suggesting otherwise. However, if a project just says "Licensed under
GPLv2", there's an undocumented Fedora convention from the Callaway
era of assuming (at least where convenient) that means GPLv2 or later
if there is no further information suggesting otherwise. Getting this
issue right (i.e., how to represent the *GPL licenses (in terms of the
"or-later" vs. "only" characteristic) probably no longer has much
practical significance so it's not worth spending too much energy on.

> As for + being valid SPDX syntax, can that be supported by
> fedora-license-validate or whatever the tool is called today?

That's probably a good idea, though it would seem to be predicated on
us documenting that any "allowed" license identifier is still allowed
if it adds the `+` operator.

Richard
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
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 39 compose report: 20230828.n.0 changes

[Fedora Branched Report]

OLD: Fedora-39-20230827.n.0
NEW: Fedora-39-20230828.n.0

= SUMMARY =
Added images:4
Dropped images:  2
Added packages:  0
Dropped packages:0
Upgraded packages:   0
Downgraded packages: 0

Size of added packages:  0 B
Size of dropped packages:0 B
Size of upgraded packages:   0 B
Size of downgraded packages: 0 B

Size change of upgraded packages:   0 B
Size change of downgraded packages: 0 B

= ADDED IMAGES =
Image: i3 live aarch64
Path: Spins/aarch64/iso/Fedora-i3-Live-aarch64-39-20230828.n.0.iso
Image: Silverblue dvd-ostree ppc64le
Path: 
Silverblue/ppc64le/iso/Fedora-Silverblue-ostree-ppc64le-39-20230828.n.0.iso
Image: Silverblue dvd-ostree aarch64
Path: 
Silverblue/aarch64/iso/Fedora-Silverblue-ostree-aarch64-39-20230828.n.0.iso
Image: Kinoite dvd-ostree x86_64
Path: Kinoite/x86_64/iso/Fedora-Kinoite-ostree-x86_64-39-20230828.n.0.iso

= DROPPED IMAGES =
Image: LXQt live aarch64
Path: Spins/aarch64/iso/Fedora-LXQt-Live-aarch64-39-20230827.n.0.iso
Image: Workstation live aarch64
Path: 
Workstation/aarch64/iso/Fedora-Workstation-Live-aarch64-39-20230827.n.0.iso

= ADDED PACKAGES =

= DROPPED PACKAGES =

= UPGRADED PACKAGES =

= DOWNGRADED PACKAGES =
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
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: Adding Passim as a Fedora 40 feature?

[Nicolas Mailhot via devel]

Le samedi 26 août 2023 à 15:14 +0100, Peter Robinson a écrit :
> 
> In a lot of corporate datacentre networks the "users" on the network
> would know what the network is comprised of, and often on these
> networks they will have 10s, 100s of even 1000s of identical devices
> where being able to do sharing of the same firmware is useful. Maybe
> make that configurable so the network/system admin can make the
> decision for what's best for their usecase?

This king of corporate datacenter network will proxy system downloads
(more to detect attacks than to save any bandwidth), they won’t benefit
at all from domain-specific download sharing. (Unless the original
source plays cdn games that breaks proxying that is)

Regards,

-- 
Nicolas Mailhot
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
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: AVX extensions not detected properly on a Zen 2 CPU?

[Florian Weimer]

* Julian Sikorski:

> Am 28.08.23 um 14:39 schrieb Florian Weimer:
>> * Julian Sikorski:
>> 
>>> I have noticed the following message in my kernel log today after I
>>> attempted to decrypt my veracrypt external hard drive:
>>>
>>> [20542.328594] AVX2 instructions are not detected.
>>> [20542.382731] AVX or AES-NI instructions are not detected.
>>> [20542.404097] AVX or AES-NI instructions are not detected.
>>> [20542.560078] AVX2 instructions are not detected.
>>>
>>> My CPU (AMD Ryzen 5 4500U) supports aes, avx and avx2 according to
>>> /proc/cpuid. Is this a bug?
>> What does ld.so --list-diagnostics show?  Is this a virtual machine?
>
> It is not a VM, bare metal Fedora 38 install. It is a ZenBook UM425IA
> laptop.
>
> $ ld.so --list-diagnostics
> dl_dst_lib="lib64"
> dl_hwcap=0x2
> dl_hwcap_important=0x6
> dl_hwcap2=0x2
> dl_hwcaps_subdirs="x86-64-v4:x86-64-v3:x86-64-v2"
> dl_hwcaps_subdirs_active=0x6

That indicates that userspace has access to AVX2 CPU capabilities.
So this must some kernel thing.  Sorry, no idea what is going on.

Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
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: Add a push update mechanism for https://release-monitoring.org/

[Sérgio Basto]

On Mon, 2023-08-28 at 13:52 +0100, Sérgio Basto wrote:
> On Mon, 2023-08-28 at 03:28 +, Ryan Bach via devel wrote:
> > Faster updates are always as plus.
> > 
> > Should this be under infrastructure list?
> > 
> > Thoughts?
> > 
> 
> if you got a scratch build completed in a bugzilla for example :  
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=2231971
> 
> you may use my helper script update_from_bugzilla.sh 
> 
> `fedpkg clone package-foo; cd package-foo ;
> ../update_from_bugzilla.sh`

forgot to add bugzilla number, so should be   

`fedpkg clone package-foo; cd package-foo ; ../update_from_bugzilla.sh
2231971`

> 
> > Thanks in advance for all the work done to make this distro great.
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > Fedora Code of Conduct:
> > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines:
> > https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives:
> > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> > Do not reply to spam, report it:
> > https://pagure.io/fedora-infrastructure/new_issue
> 
> -- 
> Sérgio M. B.
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines:
> https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue

-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
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: Add a push update mechanism for https://release-monitoring.org/

[Sérgio Basto]

On Mon, 2023-08-28 at 03:28 +, Ryan Bach via devel wrote:
> Faster updates are always as plus.
> 
> Should this be under infrastructure list?
> 
> Thoughts?
> 

if you got a scratch build completed in a bugzilla for example :  

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

you may use my helper script update_from_bugzilla.sh 

`fedpkg clone package-foo; cd package-foo ; ../update_from_bugzilla.sh`

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

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

[Bug 2235322] perl-Crypt-CBC-3.04 of RHEL9 can not decrypt ciphertext created with 'header' => 'randomiv'

[bugzilla]

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

Paulo Andrade  changed:

   What|Removed |Added

 Attachment|1   |0
#1985652 is||
private||




-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2235322
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Bug 2235322] perl-Crypt-CBC-3.04 of RHEL9 can not decrypt ciphertext created with 'header' => 'randomiv'

[bugzilla]

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

Paulo Andrade  changed:

   What|Removed |Added

  Comment #1 is|1   |0
private||




-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2235322
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: AVX extensions not detected properly on a Zen 2 CPU?

[Julian Sikorski]

Am 28.08.23 um 14:39 schrieb Florian Weimer:

* Julian Sikorski:


I have noticed the following message in my kernel log today after I
attempted to decrypt my veracrypt external hard drive:

[20542.328594] AVX2 instructions are not detected.
[20542.382731] AVX or AES-NI instructions are not detected.
[20542.404097] AVX or AES-NI instructions are not detected.
[20542.560078] AVX2 instructions are not detected.

My CPU (AMD Ryzen 5 4500U) supports aes, avx and avx2 according to
/proc/cpuid. Is this a bug?


What does ld.so --list-diagnostics show?  Is this a virtual machine?


It is not a VM, bare metal Fedora 38 install. It is a ZenBook UM425IA 
laptop.


$ ld.so --list-diagnostics
dl_dst_lib="lib64"
dl_hwcap=0x2
dl_hwcap_important=0x6
dl_hwcap2=0x2
dl_hwcaps_subdirs="x86-64-v4:x86-64-v3:x86-64-v2"
dl_hwcaps_subdirs_active=0x6
dl_pagesize=0x1000
dl_platform="x86_64"
dl_profile_output="/var/tmp"
dl_string_platform=0x
dso.ld="ld-linux-x86-64.so.2"
dso.libc="libc.so.6"
env_filtered[0x0]="SHELL"
env_filtered[0x1]="SESSION_MANAGER"
env_filtered[0x2]="COLORTERM"
env_filtered[0x3]="HISTCONTROL"
env_filtered[0x4]="XDG_MENU_PREFIX"
env_filtered[0x5]="HISTSIZE"
env_filtered[0x6]="HOSTNAME"
env_filtered[0x7]="SSH_AUTH_SOCK"
env_filtered[0x8]="XMODIFIERS"
env_filtered[0x9]="DESKTOP_SESSION"
env_filtered[0xa]="EDITOR"
env_filtered[0xb]="PWD"
env_filtered[0xc]="LOGNAME"
env_filtered[0xd]="XDG_SESSION_DESKTOP"
env_filtered[0xe]="XDG_SESSION_TYPE"
env_filtered[0xf]="SYSTEMD_EXEC_PID"
env_filtered[0x10]="XAUTHORITY"
env_filtered[0x11]="GDM_LANG"
env_filtered[0x12]="HOME"
env_filtered[0x13]="USERNAME"
env[0x14]="LANG=de_DE.UTF-8"
env_filtered[0x15]="LS_COLORS"
env_filtered[0x16]="XDG_CURRENT_DESKTOP"
env_filtered[0x17]="VTE_VERSION"
env_filtered[0x18]="WAYLAND_DISPLAY"
env_filtered[0x19]="INVOCATION_ID"
env_filtered[0x1a]="MANAGERPID"
env_filtered[0x1b]="MOZ_GMP_PATH"
env_filtered[0x1c]="GNOME_SETUP_DISPLAY"
env_filtered[0x1d]="XDG_SESSION_CLASS"
env_filtered[0x1e]="TERM"
env_filtered[0x1f]="LESSOPEN"
env_filtered[0x20]="USER"
env_filtered[0x21]="DISPLAY"
env_filtered[0x22]="SHLVL"
env_filtered[0x23]="QT_IM_MODULE"
env_filtered[0x24]="XDG_RUNTIME_DIR"
env_filtered[0x25]="DEBUGINFOD_URLS"
env_filtered[0x26]="JOURNAL_STREAM"
env_filtered[0x27]="XDG_DATA_DIRS"
env[0x28]="PATH=/home/julas/.local/bin:/home/julas/bin:/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin"
env_filtered[0x29]="GDMSESSION"
env_filtered[0x2a]="DBUS_SESSION_BUS_ADDRESS"
env_filtered[0x2b]="MAIL"
env_filtered[0x2c]="_"
path.prefix="/usr"
path.rtld="/lib64/ld-linux-x86-64.so.2"
path.sysconfdir="/etc"
path.system_dirs[0x0]="/lib64/"
path.system_dirs[0x1]="/usr/lib64/"
version.release="stable"
version.version="2.37"
auxv[0x0].a_type=0x21
auxv[0x0].a_val=0x7fff469d
auxv[0x1].a_type=0x33
auxv[0x1].a_val=0x6f0
auxv[0x2].a_type=0x10
auxv[0x2].a_val=0x178bfbff
auxv[0x3].a_type=0x6
auxv[0x3].a_val=0x1000
auxv[0x4].a_type=0x11
auxv[0x4].a_val=0x64
auxv[0x5].a_type=0x3
auxv[0x5].a_val=0x7f73e0dde040
auxv[0x6].a_type=0x4
auxv[0x6].a_val=0x38
auxv[0x7].a_type=0x5
auxv[0x7].a_val=0xb
auxv[0x8].a_type=0x7
auxv[0x8].a_val=0x0
auxv[0x9].a_type=0x8
auxv[0x9].a_val=0x0
auxv[0xa].a_type=0x9
auxv[0xa].a_val=0x7f73e0df93b0
auxv[0xb].a_type=0xb
auxv[0xb].a_val=0x3e8
auxv[0xc].a_type=0xc
auxv[0xc].a_val=0x3e8
auxv[0xd].a_type=0xd
auxv[0xd].a_val=0x3e8
auxv[0xe].a_type=0xe
auxv[0xe].a_val=0x3e8
auxv[0xf].a_type=0x17
auxv[0xf].a_val=0x0
auxv[0x10].a_type=0x19
auxv[0x10].a_val=0x7fff46996c99
auxv[0x11].a_type=0x1a
auxv[0x11].a_val=0x2
auxv[0x12].a_type=0x1f
auxv[0x12].a_val="/usr/bin/ld.so"
auxv[0x13].a_type=0xf
auxv[0x13].a_val="x86_64"
auxv[0x14].a_type=0x1b
auxv[0x14].a_val=0x1c
auxv[0x15].a_type=0x1c
auxv[0x15].a_val=0x20
uname.sysname="Linux"
uname.nodename="snowball3"
uname.release="6.4.12-200.fc38.x86_64"
uname.version="#1 SMP PREEMPT_DYNAMIC Wed Aug 23 17:46:49 UTC 2023"
uname.machine="x86_64"
uname.domainname="(none)"
x86.cpu_features.basic.kind=0x2
x86.cpu_features.basic.max_cpuid=0x10
x86.cpu_features.basic.family=0x17
x86.cpu_features.basic.model=0x60
x86.cpu_features.basic.stepping=0x1
x86.cpu_features.features[0x0].cpuid[0x0]=0x860f01
x86.cpu_features.features[0x0].cpuid[0x1]=0x6060800
x86.cpu_features.features[0x0].cpuid[0x2]=0x7ed8320b
x86.cpu_features.features[0x0].cpuid[0x3]=0x178bfbff
x86.cpu_features.features[0x0].active[0x0]=0x0
x86.cpu_features.features[0x0].active[0x1]=0x0
x86.cpu_features.features[0x0].active[0x2]=0x7ed83203
x86.cpu_features.features[0x0].active[0x3]=0x17888110
x86.cpu_features.features[0x1].cpuid[0x0]=0x0
x86.cpu_features.features[0x1].cpuid[0x1]=0x219c91a9
x86.cpu_features.features[0x1].cpuid[0x2]=0x44
x86.cpu_features.features[0x1].cpuid[0x3]=0x0
x86.cpu_features.features[0x1].active[0x0]=0x0
x86.cpu_features.features[0x1].active[0x1]=0x218c0128
x86.cpu_features.features[0x1].active[0x2]=0x40
x86.cpu_features.features[0x1].active[0x3]=0x0
x86.cpu_features.features[0x2].cpuid[0x0]=0x860f01

Re: AVX extensions not detected properly on a Zen 2 CPU?

[Florian Weimer]

* Julian Sikorski:

> I have noticed the following message in my kernel log today after I
> attempted to decrypt my veracrypt external hard drive:
>
> [20542.328594] AVX2 instructions are not detected.
> [20542.382731] AVX or AES-NI instructions are not detected.
> [20542.404097] AVX or AES-NI instructions are not detected.
> [20542.560078] AVX2 instructions are not detected.
>
> My CPU (AMD Ryzen 5 4500U) supports aes, avx and avx2 according to
> /proc/cpuid. Is this a bug?

What does ld.so --list-diagnostics show?  Is this a virtual machine?

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

[Bug 2235322] New: perl-Crypt-CBC-3.04 of RHEL9 can not decrypt ciphertext created with 'header' => 'randomiv'

[bugzilla]

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

Bug ID: 2235322
   Summary: perl-Crypt-CBC-3.04 of RHEL9 can not decrypt
ciphertext created with 'header' => 'randomiv'
   Product: Fedora EPEL
   Version: epel9
  Hardware: All
OS: Linux
Status: NEW
 Component: perl-Crypt-CBC
  Severity: low
  Assignee: andr...@bawue.net
  Reporter: pandr...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: andr...@bawue.net, p...@city-fan.org,
perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



Created attachment 1985651
  --> https://bugzilla.redhat.com/attachment.cgi?id=1985651=edit
randomiv.patch

The function sub key_and_iv () in the module Crypt/CBC/PBKDF.pm (part of the
perl-Crypt-CBC-3.04-1.el9.noarch) looks like this:

sub key_and_iv {
...
my $key  = substr($hash,0,$self->{key_len});
my $iv   = substr($hash,$self->{key_len},$self->{iv_len});
return ($key,$iv);
}

This function returns the extracted key as first value and the suggested patch
fills this first value into the $self->{key}.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2235322

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202235322%23c0
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: SPDX Statistics - Voyager 2 edition

[Fabio Valentini]

On Mon, Aug 28, 2023 at 4:39 AM Jilayne Lovejoy  wrote:
>
> Top-posting a few comments related to this thread in total (instead of 
> multiple responses to separate posts) and in hopes that people will be more 
> likely to see/read :)
>
> As to Rust saying MPL-2.0+ is invalid - this is likely because Rust thinks of 
> the SPDX License List as *only* what is this page https://spdx.org/licenses/ 
> - ignoring the links at the top of that page that provide the greater 
> context, which is really important to understand. This is a somewhat common 
> misconception, especially when adoption of SPDX ids occurs without actual 
> engagement in the SPDX community. Some time ago, I started (in presentations) 
> to repeat "it's not just a 'list'" to help educate people and updated the 
> first FAQ to this end - 
> https://github.com/spdx/license-list-XML/blob/main/DOCS/faq.md

It's not "Rust" language per se, but about crates.io, the central
package ("crate") registry.

The package manager itself (cargo) has no requirements about license
specifications at all, and treats the "license" field in package
metadata as free-form text.
Only crates.io looks at the text of the "license" in the crate
metadata, attempts to parse it, and adds links to the license's pages
on choosealicense.com.

However, it looks like this SPDX expression parser is still limited
and doesn't support the full SPDX specification:
https://doc.rust-lang.org/cargo/reference/manifest.html#the-license-and-license-file-fields

Reading these docs again, it sounds like the only issue here is that
the parser doesn't understand the full SPDX syntax, but that doesn't
mean that you can't *use* valid SPDX syntax.

>  Maybe I need to re-write that lead-in language on the top of the page again 
> or put a big yellow flashing sign also? sigh
>
> If you want to pass along this concept to people at Rust and tell them to 
> join the spdx-legal mailing list, we'd be happy to help advise.

As I said, it looks like this is not about *validity*, but more about
"we can't parse everything yet", so I don't see this is a problem.

> As for deprecated SPDX ids and validity in the context of Fedora - I would 
> strongly urge us to use the current ids and not muddy things with the use of 
> deprecated ids. The change as of the SPDX License List 2.0 added the 
> operators (AND, OR, WITH, and +) and so it would super confusing if people 
> still used the ids from v1.0

What's the commended approach for packages that use deprecated
identifiers then? I would rather not just convert "GPL-2.0" to
"GPL-2.0-or-later" or "GPL-2.0-only", since it's almost always not
obvious which one was originally intended. Do we need to file issues
with upstream projects and ask them to clarify?

As for + being valid SPDX syntax, can that be supported by
fedora-license-validate or whatever the tool is called today?
I'd rather not go filing unnecessary bugs with upstream again, just to
learn that I filed bugs for things that aren't even wrong.

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

Re: Add a push update mechanism for https://release-monitoring.org/

[Fabio Valentini]

On Mon, Aug 28, 2023 at 5:29 AM Ryan Bach via devel
 wrote:
>
> Faster updates are always as plus.

There's a problem with an approach like this: You need to check
*manually* that the new version builds and doesn't violate any of our
policies, for example, that it doesn't contain any prohibited items
(like new code or content that's under non-FOSS / non-commercial /
non-redistributable licenses).

For projects where the people who are responsible for the upstream
project are the same people who maintain the Fedora package, this is
mostly a non-issue - and for these cases, there's Packit [0] (which I
think does what you are looking for).

Fabio

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

[Bug 2235314] New: perl-Mail-Box-POP3-3.006 is available

[bugzilla]

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

Bug ID: 2235314
   Summary: perl-Mail-Box-POP3-3.006 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Mail-Box-POP3
  Keywords: FutureFeature, Triaged
  Assignee: jples...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: jples...@redhat.com,
perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



Releases retrieved: 3.006
Upstream release that is considered latest: 3.006
Current version/release in rawhide: 3.005-14.fc39
URL: http://search.cpan.org/dist/Mail-Box-POP3/

Please consult the package updates policy before you issue an update to a
stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/


More information about the service that created this bug can be found at:
https://docs.fedoraproject.org/en-US/package-maintainers/Upstream_Release_Monitoring


Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.


Based on the information from Anitya:
https://release-monitoring.org/project/13813/


To change the monitoring settings for the project, please visit:
https://src.fedoraproject.org/rpms/perl-Mail-Box-POP3


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2235314

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202235314%23c0
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Fedora rawhide compose report: 20230828.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20230827.n.0
NEW: Fedora-Rawhide-20230828.n.0

= SUMMARY =
Added images:5
Dropped images:  1
Added packages:  5
Dropped packages:0
Upgraded packages:   69
Downgraded packages: 0

Size of added packages:  257.46 KiB
Size of dropped packages:0 B
Size of upgraded packages:   1.12 GiB
Size of downgraded packages: 0 B

Size change of upgraded packages:   3.70 MiB
Size change of downgraded packages: 0 B

= ADDED IMAGES =
Image: Silverblue dvd-ostree aarch64
Path: 
Silverblue/aarch64/iso/Fedora-Silverblue-ostree-aarch64-Rawhide-20230828.n.0.iso
Image: Kinoite dvd-ostree aarch64
Path: Kinoite/aarch64/iso/Fedora-Kinoite-ostree-aarch64-Rawhide-20230828.n.0.iso
Image: Kinoite dvd-ostree x86_64
Path: Kinoite/x86_64/iso/Fedora-Kinoite-ostree-x86_64-Rawhide-20230828.n.0.iso
Image: Sericea dvd-ostree x86_64
Path: Sericea/x86_64/iso/Fedora-Sericea-ostree-x86_64-Rawhide-20230828.n.0.iso
Image: Onyx dvd-ostree x86_64
Path: Onyx/x86_64/iso/Fedora-Onyx-ostree-x86_64-Rawhide-20230828.n.0.iso

= DROPPED IMAGES =
Image: Silverblue dvd-ostree ppc64le
Path: 
Silverblue/ppc64le/iso/Fedora-Silverblue-ostree-ppc64le-Rawhide-20230827.n.0.iso

= ADDED PACKAGES =
Package: golang-modernc-cc-3-3.41.0-1.fc40
Summary: C99 compiler front end
RPMs:golang-modernc-cc-3-devel
Size:162.60 KiB

Package: golang-modernc-ebnf-1.1.0-1.fc40
Summary: Package ebnf is a library for EBNF grammars
RPMs:golang-modernc-ebnf-devel
Size:13.59 KiB

Package: golang-modernc-scannertest-1.0.2-1.fc40
Summary: Provides helpers for automated testing of scanners/lexers/tokenizers
RPMs:golang-modernc-scannertest-devel
Size:13.44 KiB

Package: rust-enumn-0.1.11-1.fc40
Summary: Convert number to enum
RPMs:rust-enumn+default-devel rust-enumn-devel
Size:22.71 KiB

Package: rust-four-cc-0.3.0-2.fc40
Summary: Newtype wrapper for representing four-character-code values
RPMs:rust-four-cc+default-devel rust-four-cc+nightly-devel 
rust-four-cc+serde-devel rust-four-cc+std-devel rust-four-cc-devel
Size:45.12 KiB


= DROPPED PACKAGES =

= UPGRADED PACKAGES =
Package:  alizams-1.9.3-1.fc40
Old package:  alizams-1.9.1-3.fc39
Summary:  Aliza MS DICOM Viewer
RPMs: alizams
Size: 4.32 MiB
Size change:  5.33 KiB
Changelog:
  * Sun Aug 27 2023 alciregi  - 1.9.1-4
  - Update to 1.9.3

  * Sun Aug 27 2023 alciregi  - 1.9.3-1
  - Update to 1.9.3


Package:  atlantik-0.7.80~20230806.git01397fd-2.fc40
Old package:  atlantik-0.7.80~20230806.git01397fd-1.fc40
Summary:  KDE monopd game client
RPMs: atlantik atlantik-devel atlantik-libs
Size: 2.29 MiB
Size change:  828 B
Changelog:
  * Mon Aug 28 2023 Yaakov Selkowitz  - 
0.7.80~20230806.git01397fd-2
  - Obsoletes: kdeaddons-atlantikdesigner


Package:  chatterino2-2.4.5-3.fc40
Old package:  chatterino2-2.4.3-2.fc39
Summary:  Chat client for https://twitch.tv
RPMs: chatterino2
Size: 13.12 MiB
Size change:  295.22 KiB
Changelog:
  * Sun Aug 27 2023 Artem Polishchuk  - 2.4.4-1
  - chore: Update to 2.4.4

  * Sun Aug 27 2023 Artem Polishchuk  - 2.4.5-1
  - chore: Update to 2.4.5 (rh#2195932)

  * Sun Aug 27 2023 Christian Birk  - 2.4.5-2
  - Update miniaudio for the latest release. Fix dependency numbers for
shortcommit11 and shortcommit12 to reflext the correct commits.

  * Sun Aug 27 2023 Artem Polishchuk  - 2.4.5-3
  - build: Add missed sources


Package:  exercism-3.2.0-1.fc40
Old package:  exercism-3.1.0-3.fc39
Summary:  Exercism command-line interface
RPMs: exercism
Size: 13.36 MiB
Size change:  15.59 KiB
Changelog:
  * Sun Aug 27 2023 Elliott Sales de Andrade  - 
3.2.0-1
  - Update to latest version (#2228145)


Package:  gensio-2.7.5-1.fc40
Old package:  gensio-2.7.4-1.fc40
Summary:  General Stream I/O
RPMs: gensio libgensio libgensio-devel libgensio-ipmisol libgensio-mdns 
libgensio-sound libgensio-tcl python3-gensio
Size: 5.26 MiB
Size change:  8.23 KiB
Changelog:
  * Mon Aug 28 2023 Felix Kaechele  - 2.7.5-1
  - update to 2.7.5


Package:  kernel-6.5.0-57.fc40
Old package:  kernel-6.5.0-0.rc7.20230825git4f9e7fabf864.54.fc40
Summary:  The Linux kernel
RPMs: kernel kernel-core kernel-debug kernel-debug-core 
kernel-debug-devel kernel-debug-devel-matched kernel-debug-modules 
kernel-debug-modules-core kernel-debug-modules-extra 
kernel-debug-modules-internal kernel-debug-uki-virt kernel-devel 
kernel-devel-matched kernel-doc kernel-modules kernel-modules-core 
kernel-modules-extra kernel-modules-internal kernel-uki-virt
Size: 937.50 MiB
Size change:  -1.55 MiB
Changelog:
  * Sat Aug 26 2023 Fedora Kernel Team  
[6.5.0-0.rc7.7d2f353b2682.55.eln130]
  - redhat/kernel.spec.template: update compression variables to support zstd 
(Brian Masney)
  - Linux v6.5.0-0.rc7.7d2f353b2682

  * Sun Aug 27 2023 Fedora Kernel Team  
[6.5.0-0.rc7.28f20a19294d.56.eln130]
  - Linux

Re: Adding Passim as a Fedora 40 feature?

[Petr Pisar]

V Fri, Aug 25, 2023 at 07:34:35PM +0100, Richard Hughes napsal(a):
> you need to reboot into the new firmware before the published firmware gets
> shared;

Won't this suppress an effeciency of the local sharing? If a typical period
between a download and the reboot is significantly longer than a period in
which machines check for and download the firmaware, it will happen that all
machines will sepearately download the firmware from a central server instead
of downloading it from local peers. Because all the machines will be waiting
on the reboot.

> on the logic that you don't want to advertise to the world that you're
> currently running insecure firmware.
> 
For how long is the firmware adveritised? As long as it is advertised, people
know what version you are currently running. This information becomes
interesting when a new firmware is released. Then you have exactly the same
problem you want to address.

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

[Bug 2229718] perl-Mozilla-CA-20230821 is available

[bugzilla]

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

Michal Josef Spacek  changed:

   What|Removed |Added

 Resolution|--- |RAWHIDE
   Fixed In Version||perl-Mozilla-CA-20230821-1.
   ||fc40
 Status|ASSIGNED|CLOSED
Last Closed||2023-08-28 08:50:10




-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2229718
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

AVX extensions not detected properly on a Zen 2 CPU?

[Julian Sikorski]

Hello,

I have noticed the following message in my kernel log today after I 
attempted to decrypt my veracrypt external hard drive:


[20542.328594] AVX2 instructions are not detected.
[20542.382731] AVX or AES-NI instructions are not detected.
[20542.404097] AVX or AES-NI instructions are not detected.
[20542.560078] AVX2 instructions are not detected.

My CPU (AMD Ryzen 5 4500U) supports aes, avx and avx2 according to 
/proc/cpuid. Is this a bug?


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