[Bug 2184301] perl-Syntax-Feature-Loop-1.8.0-18.fc39 FTBFS: t/01_basic.t and 3 more tests fail

[bugzilla]

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



--- Comment #8 from Fedora Release Engineering  ---
Dear Maintainer,

your package has an open Fails To Build From Source bug for Fedora 39.
Action is required from you.

If you can fix your package to build, perform a build in koji, and either
create
an update in bodhi, or close this bug without creating an update, if updating
is
not appropriate [1]. If you are working on a fix, set the status to ASSIGNED to
acknowledge this. If you have already fixed this issue, please close this
Bugzilla report.

Following the policy for such packages [2], your package will be orphaned if
this bug remains in NEW state more than 8 weeks (not sooner than 2023-05-30).

A week before the mass branching of Fedora 40 according to the schedule [3],
any packages not successfully rebuilt at least on Fedora 38 will be
retired regardless of the status of this bug.

[1] https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/
[2]
https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/
[3] https://fedorapeople.org/groups/schedule/f-40/f-40-key-tasks.html


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

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202184301%23c8
--
___
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 40 compose report: 20240413.n.1 changes

[Fedora Branched Report]

OLD: Fedora-40-20240412.n.0
NEW: Fedora-40-20240413.n.1

= SUMMARY =
Added images:1
Dropped images:  3
Added packages:  0
Dropped packages:0
Upgraded packages:   4
Downgraded packages: 0

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

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

= ADDED IMAGES =
Image: SoaS raw-xz aarch64
Path: Spins/aarch64/images/Fedora-SoaS-40-20240413.n.1.aarch64.raw.xz

= DROPPED IMAGES =
Image: Workstation live-osbuild aarch64
Path: 
Workstation/aarch64/iso/Fedora-Workstation-Live-osb-40-20240412.n.0.aarch64.iso
Image: Workstation live-osbuild x86_64
Path: 
Workstation/x86_64/iso/Fedora-Workstation-Live-osb-40-20240412.n.0.x86_64.iso
Image: Workstation live aarch64
Path: 
Workstation/aarch64/iso/Fedora-Workstation-Live-aarch64-40-20240412.n.0.iso

= ADDED PACKAGES =

= DROPPED PACKAGES =

= UPGRADED PACKAGES =
Package:  alsa-sof-firmware-2024.03-2.fc40
Old package:  alsa-sof-firmware-2023.12.1-1.fc40
Summary:  Firmware and topology files for Sound Open Firmware project
RPMs: alsa-sof-firmware alsa-sof-firmware-debug
Size: 6.17 MiB
Size change:  1.79 MiB
Changelog:
  * Wed Apr 03 2024 Jaroslav Kysela  - 2024.03-2
  - Update to v2024.03


Package:  kernel-6.8.5-301.fc40
Old package:  kernel-6.8.4-300.fc40
Summary:  The Linux kernel
RPMs: bpftool 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-selftests-internal 
kernel-tools kernel-tools-libs kernel-tools-libs-devel kernel-uki-virt libperf 
libperf-devel perf python3-perf rtla rv
Size: 1.09 GiB
Size change:  344.61 KiB
Changelog:
  * Wed Apr 10 2024 Justin M. Forbes  [6.8.5-0]
  - Set configs for SPECTRE_BHI (Justin M. Forbes)
  - Add AMD PMF bug (Justin M. Forbes)
  - redhat/configs: Enable CONFIG_AMDTEE for x86 (David Arcari)
  - Add CVE fix for 6.8.5 (Justin M. Forbes)
  - Linux v6.8.5

  * Thu Apr 11 2024 Justin M. Forbes  [6.8.5-301]
  - nouveau: fix devinit paths to only handle display on GSP. (Dave Airlie)
  - Add bluetooth bug to Bugsfixed for 6.8.6 (Justin M. Forbes)
  - Bluetooth: l2cap: Don't double set the HCI_CONN_MGMT_CONNECTED bit (Archie 
Pusaka)


Package:  khelpcenter-1:24.02.1-3.fc40
Old package:  khelpcenter-1:24.02.1-2.fc40
Summary:  Show documentation for KDE applications
RPMs: khelpcenter
Size: 7.51 MiB
Size change:  562 B
Changelog:
  * Thu Apr 11 2024 Adam Williamson  - 24.02.1-3
  - Backport better fix for subpage opening (#2271837)


Package:  python-django-4.2.11-2.fc40
Old package:  python-django-4.2.6-3.fc40
Summary:  A high-level Python Web framework
RPMs: python-django-bash-completion python3-django python3-django-doc
Size: 10.22 MiB
Size change:  10.05 KiB
Changelog:
  * Tue Mar 12 2024 Miro Hron??ok  - 4.2.6-5
  - No longer own the /usr/share/bash-completion directory

  * Mon Apr 08 2024 Michel Lind  - 4.2.11-1
  - Update to 4.2.11
  - Resolves CVE-2024-24680 (rhbz#2263505)
  - Resolves CVE-2024-27351 (rhbz#2267654)

  * Tue Apr 09 2024 Michel Lind  - 4.2.11-2
  - Update list of bundled Javascript modules
  - Add virtual Provides and Conflicts to allow swapping Django stacks
  - Re-enable tests temporarily disabled for Python 3.12 beta



= 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

Opensubdiv updated to 3.6.0

[Luya Tshimbalanga]

Hello team,

Opensubdiv is updated to 3.6.0 with a soversion changes that may affect 
the following packages:


- blender-1:4.0.2-1.fc40.x86_64
* luxcorerender-core-0:2.7-0.13.beta1.fc40.x86_64
* usd-libs-0:23.11-7.fc40.x86_64
* wdune-0:1.958-12.fc39.i686

Please use the following side tag for rebuilding:

* f41-build-side-87693 
 for 
Fedora Rawhide/41


* f40-build-side-86961 
 for Fedora 40


--
Luya Tshimbalanga
Fedora Design Team
Fedora Design Suite maintainer
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
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: network service removed in Fedora 40 without a Change proposal(?)

[Chris Adams]

Once upon a time, Matthew Miller  said:
> > With this change, existing profiles in ifcfg format will be automatically
> > migrated to the native keyfile format via a migration service shipped with
> > the NetworkManager-initscripts-ifcfg-rh package. In Fedora, we plan to
> > drop the plugin by Fedora Linux 41.
> 
> (Emphasis on the last line.)
> 
> The words "the network-scripts subpackage is deprecated and will be removed"
> do not seem to have appeared in the release notes, and in retrospect that
> probably should have been stronger.
> 
> "Gone in 40" _does_ technically fit into the letter of "drop by 41"... but
> maybe not the spirit?

Dropping the NM ifcfg plugin is very different from dropping the actual
old network scripts.

-- 
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: network service removed in Fedora 40 without a Change proposal(?)

[Matthew Miller]

On Fri, Apr 12, 2024 at 06:00:41PM -0700, Adam Williamson wrote:
> > This should have been an announced Change. This is a significant
> > change with wide impact.
> 
> I've filed a bug, proposed it as a blocker, and filed a FESCo ticket
> asking FESCo to designate the bug as a blocker.
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=2274830
> https://pagure.io/fesco/issue/3196

I admit I was also initially surprised. But, this actually has been going
through the Change process for a while:

F33: 
https://fedoraproject.org/wiki/Changes/NetworkManager_keyfile_instead_of_ifcfg_rh
F36: https://fedoraproject.org/wiki/Changes/NoIfcfgFiles
F39: https://fedoraproject.org/wiki/Changes/MigrateIfcfgToKeyfile

That last one actually says: 

> The upstream NetworkManager project has recently declared the ifcfg plugin
> as deprecated. This means that the code will only receive bug fixes, and
> will not get new functionality such as supporting new properties.
>
> With this change, existing profiles in ifcfg format will be automatically
> migrated to the native keyfile format via a migration service shipped with
> the NetworkManager-initscripts-ifcfg-rh package. In Fedora, we plan to
> drop the plugin by Fedora Linux 41.

(Emphasis on the last line.)

The words "the network-scripts subpackage is deprecated and will be removed"
do not seem to have appeared in the release notes, and in retrospect that
probably should have been stronger.

"Gone in 40" _does_ technically fit into the letter of "drop by 41"... but
maybe not the spirit?

I think a "drop in 41" change (and a clear item in the F40 release notes!)
is probably the best way to clear the air -- but I don't think the
maintainers stepped around the process here.

-- 
Matthew Miller

Fedora Project Leader
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
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 2274936] New: perl-Business-ISBN-Data-20240413.001 is available

[bugzilla]

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

Bug ID: 2274936
   Summary: perl-Business-ISBN-Data-20240413.001 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Business-ISBN-Data
  Keywords: FutureFeature, Triaged
  Assignee: jples...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: jples...@redhat.com, ka...@ucw.cz, mspa...@redhat.com,
p...@city-fan.org, perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



Releases retrieved: 20240413.001
Upstream release that is considered latest: 20240413.001
Current version/release in rawhide: 20240323.001-1.fc41
URL: https://metacpan.org/dist/Business-ISBN-Data/

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


To change the monitoring settings for the project, please visit:
https://src.fedoraproject.org/rpms/perl-Business-ISBN-Data


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

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202274936%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: F41 Change Proposal - Reproducible Package Builds (System-Wide)

[Zbigniew Jędrzejewski-Szmek]

On Sat, Apr 13, 2024 at 01:38:49PM +, Zbigniew Jędrzejewski-Szmek wrote:
> On Sat, Apr 13, 2024 at 01:41:59PM +0200, Fabio Valentini wrote:
> > On Sat, Apr 13, 2024 at 1:18 PM Zbigniew Jędrzejewski-Szmek
> >  wrote:
> > >
> > > Yes. But actually I think Rust is the optimal choice here. Writing
> > > this in Python would be possibly slightly nicer, but we don't want
> > > to pull the interpreter and packages into the buildroot. Python
> > > also has the problem (challenge?) that it needs to be bootstrapped
> > > once per year. The less packages are involved in the bootstrap, the
> > > easier it is. And if the brp was written in Python, we'd need to
> > > deal with that, and it would probably increase the number of builds
> > > which are done without the cleanup. Having this as an indepedent
> > > binary avoids some of the issues with bootstrap.
> > 
> > I think Rust *would* be a good choice here ...
> > BUT add-determinism uses pyo3 to link to CPython, so it pulls in
> > python3-libs anyway.
> > So you get the downsides of pulling in Python without the upsides of
> > using Rust ...
> 
> Yes, it currently pulls in python3-libs as a dependency, but not the
> rest of the Python stack. Ideally, the dependency on python3-libs will
> become optional, and we'll use it if found at runtime if found and
> ignore otherwise. (Anything that creates pyc files will have python
> installed, so it's fine if the pyc handler only works if there.)
> How to best do this is something that needs to be figured out…

https://github.com/keszybz/add-determinism/pull/1 makes the dependency
on libpython optional. One option would be to compile the binary
twice, and use rich dependencies to install the heavyweight one if
python3 is installed. If somebody has a better approach, I'm all ears.

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

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

[Jonathan Steffan]

On Thu, Apr 11, 2024 at 6:50 PM Adam Williamson 
wrote:

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


If this is going to end up required in one way or another to a
larger group, we should also commit to getting FAS FIDO2 enabled and GOA
fixed. The current FAS MFA is less than ideal, though you do get used to it.

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

spice-vdagent

[Steven A. Falco]

I noticed that the load average on a rawhide vm was higher than expected, and 
according to 'top' I had two copies of /usr/bin/spice-vdagent running, with one 
of them taking up a whole cpu core.

I removed /etc/xdg/autostart/spice-vdagent.desktop and rebooted.  Now there is 
only one copy of spice-vdagent running, and the load average is back to normal. 
 The vm behaves normally, with cut/paste, resize, etc. all working fine.

This vm is running with the KDE desktop in x11 mode.

Can anyone suggest why I might have two copies of spice-vdagent running?  I'm 
happy to have found a work-around, but this really doesn't make sense.

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

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

[Gary Buhrmaster]

On Fri, Apr 12, 2024 at 4:05 PM Kevin Fenzi  wrote:

> So, if FESCo decided we wanted to enforce 2fa for provenpackagers or
> whatever, right now that would require some work on some scripting,
> which I guess would remove people without otp? But then there would
> still be a window when the user was added and before the script removed
> them. Or some way for sponsors to check otp status before sponsoring
> someone, but if thats manually it could be missed.
>
> I think in any case it might be good to find all the {proven}packager
> members without otp and perhaps email them a note about how to set
> things up, etc.

Finding the (proven)package
members without 2FA might be a
useful thing to know in order to
influence any decision or the
implementation time frame (is it
20% or 80% of (P)Ps?).

That said, I would rather see any
such follow up directed email
happen after a FESCo decision
about 2FA is made in order to
avoid possible multiple emails
(one sent soonish saying that
you *could* add 2FA, should you
want to, and another, should
the decision be made to require
2FA, to say that you will be
required to add 2FA after some
date; one email is better).

That does presume that FESCo
will make a decision in the near
term such that any email text
can be appropriately crafted.

While there will always be some
window/edge cases, I think we
should start with the presumption
that most (proven)packagers will
wish to do the right thing, and
will use 2FA if that is the stated
requirement.  After the fact
cleanup/removals as the community
now does for inactive packages
may not be ideal but is arguable
sufficient as a first step.
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[Kevin Fenzi]

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

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

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

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

kevin


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

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

[Gary Buhrmaster]

On Sat, Apr 13, 2024 at 8:44 AM Richard W.M. Jones  wrote:

> I sometimes think how hard it would be to explain all of this to my
> mother.  I don't understand why 2FA needs to be so obscure and clumsy
> to use.

FIDO2 (Apple branded[0] as "passkeys") is
not that hard to use, or explain.  The problem
is that (a) passkeys are not yet universally
supported (and, in this case specifically, by
FAS[1]), and (b) unlike Apple (macOS, iOS,
etc.), Microsoft (Windows), and Android,
where the passkey is integrated into the
OS inside a protected enclave, there is no
trusted integrated support in Linux without
an external FIDO2 key[2][3] or using the
"scan a QR code" workaround with a
mobile device which does support use of
passkeys.

Unless your mother is using Linux (and
while Mrs. Roberts has been using Linux
for a long time, most moms don't), this is
likely a time limited issue as more and
more sites support passkeys and from
the consumer point of view it all mostly
just works.

I would like to imagine that FAS' current
2FA will eventually also be reasonably
easy with FIDO2/passkeys, which is why
I occasionally ask about the FIDO2
support status.





[0] I don't remember if there was any
official assignment of the branding, but
I heard that Apple was the org that
suggested the name.

[1] As I understand it, if/when some of the
FAS IdP moves to keycloak, FIDO2 2FA
*could* be supported.  However, there is
no current schedule for that move that I
am aware of, and unless Fedora uses the
RHBK runtime, building keycloak from
source for Fedora can be a real PITA
(at least last I looked at it, maybe it has
gotten easier).

[2] As I understand it, the issue is the
lack of the required trusted environment
in generic Linux.  There are software
implementations that do not have the
hardware enclave protections,

[3] External FIDO2 keys are also not free,
although I did see a $10 Adafruit FIDO2
key, which is the cheapest I have seen.
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[Carlos Rodriguez-Fernandez]

On 4/13/24 01:44, Richard W.M. Jones wrote:

On Fri, Apr 12, 2024 at 04:50:13PM -0500, Chris Adams wrote:

Once upon a time, Richard W.M. Jones  said:

So the problem with github is they don't allow you to have 2FA on a
backup device (or rather, it *is* possible, but the process is
ludicrous[1]).  If you have your phone as second FA and lose it then
you have to immediately fall back to the piece of paper.


I haven't seen a site with TOTP 2FA allow multiple TOTP codes, they all
just store one.  It's trivial to scan the TOTP code into multiple
devices (depending on the software used, you can sometimes "export" a
TOTP code from one device to another by showing a QR code on the first
device), so that's hardly a "ludicrous" method.


I sometimes think how hard it would be to explain all of this to my
mother.  I don't understand why 2FA needs to be so obscure and clumsy
to use.

Rich.



You got a really good point there. All MFA implementations the industry 
has come up with are less than ideal in one way or the other.




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

Fedora rawhide compose report: 20240413.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20240412.n.0
NEW: Fedora-Rawhide-20240413.n.0

= SUMMARY =
Added images:1
Dropped images:  1
Added packages:  8
Dropped packages:3
Upgraded packages:   110
Downgraded packages: 0

Size of added packages:  2.48 MiB
Size of dropped packages:1.07 MiB
Size of upgraded packages:   2.73 GiB
Size of downgraded packages: 0 B

Size change of upgraded packages:   -47.51 MiB
Size change of downgraded packages: 0 B

= ADDED IMAGES =
Image: KDE live aarch64
Path: Spins/aarch64/iso/Fedora-KDE-Live-aarch64-Rawhide-20240413.n.0.iso

= DROPPED IMAGES =
Image: LXQt live aarch64
Path: Spins/aarch64/iso/Fedora-LXQt-Live-aarch64-Rawhide-20240412.n.0.iso

= ADDED PACKAGES =
Package: golang-github-containerd-1.6.23-1.fc41
Summary: An open and reliable container runtime
RPMs:golang-github-containerd-devel
Size:1.49 MiB

Package: golang-github-mattn-pointer-0.0.1-10.fc41
Summary: Pass Go pointers to C code
RPMs:golang-github-mattn-pointer-devel
Size:11.15 KiB

Package: python-zstarfile-0.2.0-1.fc41
Summary: Tarfile extension with additional compression algorithms and PEP 706 
by default
RPMs:python3-zstarfile python3-zstarfile+all python3-zstarfile+lz4 
python3-zstarfile+zstandard
Size:41.15 KiB

Package: rust-pyo3-build-config0.20-0.20.3-1.fc41
Summary: Build configuration for the PyO3 ecosystem
RPMs:rust-pyo3-build-config0.20+abi3-devel 
rust-pyo3-build-config0.20+abi3-py310-devel 
rust-pyo3-build-config0.20+abi3-py311-devel 
rust-pyo3-build-config0.20+abi3-py312-devel 
rust-pyo3-build-config0.20+abi3-py37-devel 
rust-pyo3-build-config0.20+abi3-py38-devel 
rust-pyo3-build-config0.20+abi3-py39-devel 
rust-pyo3-build-config0.20+default-devel 
rust-pyo3-build-config0.20+extension-module-devel 
rust-pyo3-build-config0.20+resolve-config-devel rust-pyo3-build-config0.20-devel
Size:107.98 KiB

Package: rust-pyo3-ffi0.20-0.20.3-1.fc41
Summary: Python-API bindings for the PyO3 ecosystem
RPMs:rust-pyo3-ffi0.20+abi3-devel rust-pyo3-ffi0.20+abi3-py310-devel 
rust-pyo3-ffi0.20+abi3-py311-devel rust-pyo3-ffi0.20+abi3-py312-devel 
rust-pyo3-ffi0.20+abi3-py37-devel rust-pyo3-ffi0.20+abi3-py38-devel 
rust-pyo3-ffi0.20+abi3-py39-devel rust-pyo3-ffi0.20+default-devel 
rust-pyo3-ffi0.20+extension-module-devel rust-pyo3-ffi0.20-devel
Size:152.09 KiB

Package: rust-pyo3-macros-backend0.20-0.20.3-1.fc41
Summary: Code generation for PyO3 package
RPMs:rust-pyo3-macros-backend0.20+default-devel 
rust-pyo3-macros-backend0.20-devel
Size:63.56 KiB

Package: rust-pyo3-macros0.20-0.20.3-1.fc41
Summary: Proc macros for PyO3 package
RPMs:rust-pyo3-macros0.20+default-devel 
rust-pyo3-macros0.20+multiple-pymethods-devel rust-pyo3-macros0.20-devel
Size:30.04 KiB

Package: rust-pyo3_0.20-0.20.3-1.fc41
Summary: Bindings to Python interpreter
RPMs:rust-pyo3_0.20+abi3-devel rust-pyo3_0.20+abi3-py310-devel 
rust-pyo3_0.20+abi3-py311-devel rust-pyo3_0.20+abi3-py312-devel 
rust-pyo3_0.20+abi3-py37-devel rust-pyo3_0.20+abi3-py38-devel 
rust-pyo3_0.20+abi3-py39-devel rust-pyo3_0.20+anyhow-devel 
rust-pyo3_0.20+auto-initialize-devel rust-pyo3_0.20+chrono-devel 
rust-pyo3_0.20+default-devel rust-pyo3_0.20+either-devel 
rust-pyo3_0.20+experimental-inspect-devel rust-pyo3_0.20+extension-module-devel 
rust-pyo3_0.20+eyre-devel rust-pyo3_0.20+full-devel 
rust-pyo3_0.20+hashbrown-devel rust-pyo3_0.20+indexmap-devel 
rust-pyo3_0.20+indoc-devel rust-pyo3_0.20+inventory-devel 
rust-pyo3_0.20+macros-devel rust-pyo3_0.20+multiple-pymethods-devel 
rust-pyo3_0.20+nightly-devel rust-pyo3_0.20+num-bigint-devel 
rust-pyo3_0.20+num-complex-devel rust-pyo3_0.20+pyo3-macros-devel 
rust-pyo3_0.20+rust_decimal-devel rust-pyo3_0.20+serde-devel 
rust-pyo3_0.20+smallvec-devel rust-pyo3_0.20+unindent-devel rust-pyo3_0.20-devel
Size:606.67 KiB


= DROPPED PACKAGES =
Package: plasma-applet-weather-widget-1.6.10-18.fc40
Summary: Plasma applet for displaying weather information
RPMs:plasma-applet-weather-widget
Size:638.42 KiB

Package: rust-gstreamer-base-sys0.21-0.21.1-1.fc41
Summary: FFI bindings to libgstbase-1.0
RPMs:rust-gstreamer-base-sys0.21+default-devel 
rust-gstreamer-base-sys0.21+v1_14_1-devel 
rust-gstreamer-base-sys0.21+v1_14_3-devel 
rust-gstreamer-base-sys0.21+v1_16-devel rust-gstreamer-base-sys0.21+v1_18-devel 
rust-gstreamer-base-sys0.21+v1_20-devel rust-gstreamer-base-sys0.21+v1_22-devel 
rust-gstreamer-base-sys0.21+v1_24-devel rust-gstreamer-base-sys0.21-devel
Size:105.12 KiB

Package: rust-gstreamer0.21-0.21.3-1.fc41
Summary: Rust bindings for GStreamer
RPMs:rust-gstreamer0.21+default-devel rust-gstreamer0.21+serde-devel 
rust-gstreamer0.21+serde_bytes-devel rust-gstreamer0.21+v1_16-devel 
rust-gstreamer0.21+v1_18-devel rust-gstreamer0.21+v1_20-devel 
rust-gstreamer0.21+v1_22-devel rust-gstreamer0.21+v1_24-devel 
rust-gstreamer0.21-devel
Size:350.73 KiB


= UPGRADED PACKAGES =
Package:  clipman

Re: F41 Change Proposal - Reproducible Package Builds (System-Wide)

[Zbigniew Jędrzejewski-Szmek]

On Sat, Apr 13, 2024 at 01:41:59PM +0200, Fabio Valentini wrote:
> On Sat, Apr 13, 2024 at 1:18 PM Zbigniew Jędrzejewski-Szmek
>  wrote:
> >
> > Yes. But actually I think Rust is the optimal choice here. Writing
> > this in Python would be possibly slightly nicer, but we don't want
> > to pull the interpreter and packages into the buildroot. Python
> > also has the problem (challenge?) that it needs to be bootstrapped
> > once per year. The less packages are involved in the bootstrap, the
> > easier it is. And if the brp was written in Python, we'd need to
> > deal with that, and it would probably increase the number of builds
> > which are done without the cleanup. Having this as an indepedent
> > binary avoids some of the issues with bootstrap.
> 
> I think Rust *would* be a good choice here ...
> BUT add-determinism uses pyo3 to link to CPython, so it pulls in
> python3-libs anyway.
> So you get the downsides of pulling in Python without the upsides of
> using Rust ...

Yes, it currently pulls in python3-libs as a dependency, but not the
rest of the Python stack. Ideally, the dependency on python3-libs will
become optional, and we'll use it if found at runtime if found and
ignore otherwise. (Anything that creates pyc files will have python
installed, so it's fine if the pyc handler only works if there.)
How to best do this is something that needs to be figured out…

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

Re: F41 Change Proposal - Reproducible Package Builds (System-Wide)

[Fabio Valentini]

On Sat, Apr 13, 2024 at 1:18 PM Zbigniew Jędrzejewski-Szmek
 wrote:
>
> Yes. But actually I think Rust is the optimal choice here. Writing
> this in Python would be possibly slightly nicer, but we don't want
> to pull the interpreter and packages into the buildroot. Python
> also has the problem (challenge?) that it needs to be bootstrapped
> once per year. The less packages are involved in the bootstrap, the
> easier it is. And if the brp was written in Python, we'd need to
> deal with that, and it would probably increase the number of builds
> which are done without the cleanup. Having this as an indepedent
> binary avoids some of the issues with bootstrap.

I think Rust *would* be a good choice here ...
BUT add-determinism uses pyo3 to link to CPython, so it pulls in
python3-libs anyway.
So you get the downsides of pulling in Python without the upsides of
using Rust ...

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: Orphaned packages looking for new maintainers

[Michael J Gruber]

Michel Lind venit, vidit, dixit 2024-04-12 21:59:42:
> On Fri, Apr 12, 2024 at 07:59:46AM -0700, Carlos Rodriguez-Fernandez wrote:
> > Regarding libteam, the author of the package is the maintainer, email in
> > bugzilla is different than the one on the project. I wonder if Jiro just
> > missed the notification that his package is failing to build in F40.
> > 
> Indeed. cc-ing Jiri to see if he wants to be added back. Jiri, if you do
> so, maybe change your email in
> https://accounts.fedoraproject.org/user/salimma/settings/email/ ?
> 
> Meanwhile I'm doing a build that removes the network-scripts-teamd
> subpackage - my initial glance at the changelog was wrong, most Fedora
> releases are already on 1.32 so we don't need to bump the package yet.
> 

Don't we need to obsolete the subpackage, though, so that it gets
removed on upgrade? Or can we rely on the fact that it had been pulled
in as a dependency only (rather than installed directly)?

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

Re: F41 Change Proposal - Reproducible Package Builds (System-Wide)

[Zbigniew Jędrzejewski-Szmek]

On Sat, Apr 13, 2024 at 04:12:09AM -0500, Neal Gompa wrote:
> On Sat, Apr 13, 2024 at 3:59 AM Richard W.M. Jones  wrote:
> >
> > On Fri, Apr 12, 2024 at 10:41:43PM +0100, Aoife Moloney wrote:
> > > [https://github.com/keszybz/add-determinism add-determinism] is a Rust
> > > program which, as its name suggests, adds determinism to files that
> > > are given as input by attempting to standardize metadata contained in
> > > binary or source files to ensure consistency and clamping to
> > > $SOURCE_DATE_EPOCH in all instances. `add-determinism` is the "Fedora
> > > version" of 
> > > [https://salsa.debian.org/reproducible-builds/strip-nondeterminism
> > > strip-nondeterminism] from the Debian project. Since
> > > strip-nondeterminism is written in perl, it is undesirable for use in
> > > Fedora, as we don't want to pull perl in the buildroot for every
> > > package.

The proposal explicitly states that we don't want Perl in all buildroots.
It doesn't say that explicitly, but we also don't want Python.
In the past we made an effort to remove gcc and make
[https://fedoraproject.org/wiki/Changes/Remove_make_from_BuildRoot,
https://fedoraproject.org/wiki/Changes/Remove_GCC_from_BuildRoot],
and Python would be a fairly big addition.

If we don't want to pull in an additional language framework, the
options are either a compiled language or a scripting language that is
already installed anyway, i.e. bash or awk. Considering that we want
to do multiprocessing and/or multithreading to make things quick, a
compiled language seems better. And among the compiled languages, I
think Rust should be the default choice nowadays.

The resulting binary is a single file of 2.6 MB, which is more than
it'd be if written in C, but still reasonably small.

> > https://github.com/keszybz/add-determinism looks like a package with a
> > lot of Rust dependencies just to make some small changes to four
> > different file types. Isn't there an easier way to do this?  I would
> > have thought a Python library would be more suitable as the most
> > complicated bit is the *.pyc change which is done using Python code.

The program currently has just four "handlers", but I expect that we'll
need to add some more. Those four address issues that were apparent
after a "mini mass rebuild" of ~2k packages, but that covered only
a subset of packages, and it's possible that those most obvious issues
masked other issues, and we didn't analyze all failures in detail, etc.
The program is structured so that it should be simple to add
additional handlers.

Now I'll try to channel Fabio V.: all the crates that are dependencies
are commonly used, i.e. they're in the common set of crates that are
used by modern Rust code and we need them to be packaged anyway. The
packaging effort for add-determinism was miniscule.
(I made a mistake by packaging a snapshot, which the guidelines
disallow like I did it, but when doing it correctly, it's really just
a matter of running rust2rpm and filling in some blanks.)

> Considering Debian's version is in Perl, yes, it's quite reasonable to
> consider that. It could have been written in Python, C++, or even
> shell (if you truly hated yourself). I'm not a big fan of Rust for
> this either. But unless someone offers to make another version that is
> more appealing, this is what we have.

Yes. But actually I think Rust is the optimal choice here. Writing
this in Python would be possibly slightly nicer, but we don't want
to pull the interpreter and packages into the buildroot. Python
also has the problem (challenge?) that it needs to be bootstrapped
once per year. The less packages are involved in the bootstrap, the
easier it is. And if the brp was written in Python, we'd need to
deal with that, and it would probably increase the number of builds
which are done without the cleanup. Having this as an indepedent
binary avoids some of the issues with bootstrap.

Please note that add-determinism has:
- configurable logging
- unit tests
- integration tests
- multiprocess support
- atomic file replacements (for files without hardlinks)
- rewriting of files in place (for files with hardlinks)

Doing this in bash would be doable, but not worth it, IMO.

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

Re: F41 Change Proposal - Python Built with gcc -03 (self-contained)

[Nikita Popov]

On Sat, Apr 13, 2024 at 5:55 PM Richard W.M. Jones 
wrote:

> On Fri, Apr 12, 2024 at 07:08:36PM -0500, Neal Gompa wrote:
> > I would like for us to consider evaluating a global change to -O3. I
> > am not convinced that there's a good reason anymore to remain at -O2.
>
> FYI here are the optimizations added by gcc -O3 (over -O2), from
> https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html
>
>   -fgcse-after-reload
>   -fipa-cp-clone
>   -floop-interchange
>   -floop-unroll-and-jam
>   -fpeel-loops
>   -fpredictive-commoning
>   -fsplit-loops
>   -fsplit-paths
>   -ftree-loop-distribution
>   -ftree-partial-pre
>   -funswitch-loops
>   -fvect-cost-model=dynamic
>   -fversion-loops-for-strides
>
> Mainly lots of loop optimizations :-)
>
> For clang, -O3 is simply described as this, I can't immediately find
> any more detail:
>
>   -O3 Like -O2, except that it enables optimizations that take longer
>   to perform or that may generate larger code (in an attempt to make
>   the program run faster).
>

Clang enables a small number of additional optimizations at O3 (the most
important of which are probably argument promotion and non-trivial loop
unswitching), but probably the largest difference is that O3 uses higher
cost thresholds for things like inlining and unrolling.

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

Re: F41 Change Proposal - Reproducible Package Builds (System-Wide)

[Neal Gompa]

On Sat, Apr 13, 2024 at 3:59 AM Richard W.M. Jones  wrote:
>
> On Fri, Apr 12, 2024 at 10:41:43PM +0100, Aoife Moloney wrote:
> > [https://github.com/keszybz/add-determinism add-determinism] is a Rust
> > program which, as its name suggests, adds determinism to files that
> > are given as input by attempting to standardize metadata contained in
> > binary or source files to ensure consistency and clamping to
> > $SOURCE_DATE_EPOCH in all instances. `add-determinism` is the "Fedora
> > version" of 
> > [https://salsa.debian.org/reproducible-builds/strip-nondeterminism
> > strip-nondeterminism] from the Debian project. Since
> > strip-nondeterminism is written in perl, it is undesirable for use in
> > Fedora, as we don't want to pull perl in the buildroot for every
> > package.
>
> https://github.com/keszybz/add-determinism looks like a package with a
> lot of Rust dependencies just to make some small changes to four
> different file types.  Isn't there an easier way to do this?  I would
> have thought a Python library would be more suitable as the most
> complicated bit is the *.pyc change which is done using Python code.
>

Considering Debian's version is in Perl, yes, it's quite reasonable to
consider that. It could have been written in Python, C++, or even
shell (if you truly hated yourself). I'm not a big fan of Rust for
this either. But unless someone offers to make another version that is
more appealing, this is what we have.



--
真実はいつも一つ！/ Always, there's only one truth!
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F41 Change Proposal - Reproducible Package Builds (System-Wide)

[Richard W.M. Jones]

On Fri, Apr 12, 2024 at 10:41:43PM +0100, Aoife Moloney wrote:
> [https://github.com/keszybz/add-determinism add-determinism] is a Rust
> program which, as its name suggests, adds determinism to files that
> are given as input by attempting to standardize metadata contained in
> binary or source files to ensure consistency and clamping to
> $SOURCE_DATE_EPOCH in all instances. `add-determinism` is the "Fedora
> version" of [https://salsa.debian.org/reproducible-builds/strip-nondeterminism
> strip-nondeterminism] from the Debian project. Since
> strip-nondeterminism is written in perl, it is undesirable for use in
> Fedora, as we don't want to pull perl in the buildroot for every
> package.

https://github.com/keszybz/add-determinism looks like a package with a
lot of Rust dependencies just to make some small changes to four
different file types.  Isn't there an easier way to do this?  I would
have thought a Python library would be more suitable as the most
complicated bit is the *.pyc change which is done using Python code.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
nbdkit - Flexible, fast NBD server with plugins
https://gitlab.com/nbdkit/nbdkit
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F41 Change Proposal - Python Built with gcc -03 (self-contained)

[Richard W.M. Jones]

On Sat, Apr 13, 2024 at 10:18:03AM +0200, Miro Hrončok wrote:
> On 13. 04. 24 10:04, Miro Hrončok wrote:
> >On 13. 04. 24 2:33, Kevin Kofler via devel wrote:
> >>How much larger is Python at -O3 compared to -O2? And other packages?
> >
> >That is a good question, will measure.
> 
> -O2 RPM size:
> python3-3.12.2-3.fc41.x86_6432638
> python3-libs-3.12.2-3.fc41.x86_644246
> 
> -O3 RPM size:
> python3-3.12.2-3.O3.fc41.x86_64 32638
> python3-libs-3.12.2-3.O3.fc41.x86_64 43389702
> 
> Difference of python3-libs:
> 
> 500856 == 489 kB = 1.1678 % increase in size of pytohn3-libs itself
> or 1.1669 % of python3-libs+python3 combined size.
> 
> (I added this to the change proposal.)

Is it possible you could add compilation time too?  It seems like -O3
will take longer, but it'd be interesting to know how much longer.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F41 Change Proposal - Python Built with gcc -03 (self-contained)

[Richard W.M. Jones]

On Fri, Apr 12, 2024 at 07:08:36PM -0500, Neal Gompa wrote:
> I would like for us to consider evaluating a global change to -O3. I
> am not convinced that there's a good reason anymore to remain at -O2.

FYI here are the optimizations added by gcc -O3 (over -O2), from
https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html

  -fgcse-after-reload
  -fipa-cp-clone
  -floop-interchange
  -floop-unroll-and-jam
  -fpeel-loops
  -fpredictive-commoning
  -fsplit-loops
  -fsplit-paths
  -ftree-loop-distribution
  -ftree-partial-pre
  -funswitch-loops
  -fvect-cost-model=dynamic
  -fversion-loops-for-strides

Mainly lots of loop optimizations :-)

For clang, -O3 is simply described as this, I can't immediately find
any more detail:

  -O3 Like -O2, except that it enables optimizations that take longer
  to perform or that may generate larger code (in an attempt to make
  the program run faster).

As gcc -Os was mentioned too, that is -O2 with the following
optimizations disabled:

  -falign-functions  -falign-jumps
  -falign-labels  -falign-loops
  -fprefetch-loop-arrays  -freorder-blocks-algorithm=stc

Clang just says:

  -Os Like -O2 with extra optimizations to reduce code size.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[Richard W.M. Jones]

On Fri, Apr 12, 2024 at 04:50:13PM -0500, Chris Adams wrote:
> Once upon a time, Richard W.M. Jones  said:
> > So the problem with github is they don't allow you to have 2FA on a
> > backup device (or rather, it *is* possible, but the process is
> > ludicrous[1]).  If you have your phone as second FA and lose it then
> > you have to immediately fall back to the piece of paper.
> 
> I haven't seen a site with TOTP 2FA allow multiple TOTP codes, they all
> just store one.  It's trivial to scan the TOTP code into multiple
> devices (depending on the software used, you can sometimes "export" a
> TOTP code from one device to another by showing a QR code on the first
> device), so that's hardly a "ludicrous" method.

I sometimes think how hard it would be to explain all of this to my
mother.  I don't understand why 2FA needs to be so obscure and clumsy
to use.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
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] Mass license change MPLv2.0 to MPL-2.0

[Miroslav Suchý]

Dne 06. 04. 24 v 10:14 dop. Miroslav Suchý napsal(a):
I am going to do the mass change of the license from MPLv2.0 to MPL-2.0 


Done.

--
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: F41 Change Proposal - Python Built with gcc -03 (self-contained)

[Miro Hrončok]

On 13. 04. 24 10:04, Miro Hrončok wrote:

On 13. 04. 24 2:33, Kevin Kofler via devel wrote:

How much larger is Python at -O3 compared to -O2? And other packages?


That is a good question, will measure.


-O2 RPM size:
python3-3.12.2-3.fc41.x86_6432638
python3-libs-3.12.2-3.fc41.x86_644246

-O3 RPM size:
python3-3.12.2-3.O3.fc41.x86_64 32638
python3-libs-3.12.2-3.O3.fc41.x86_64 43389702

Difference of python3-libs:

500856 == 489 kB = 1.1678 % increase in size of pytohn3-libs itself or 1.1669 % 
of python3-libs+python3 combined size.


(I added this to the change proposal.)

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

Re: F41 Change Proposal - Python Built with gcc -03 (self-contained)

[Miro Hrončok]

On 13. 04. 24 2:33, Kevin Kofler via devel wrote:

How much larger is Python at -O3 compared to -O2? And other packages?


That is a good question, will measure.

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
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: convert everything to rpmautospec?

[Miro Hrončok]

On 07. 04. 24 17:47, Miro Hrončok wrote:
Note that it produces incorrect results if the Release value is not numerical 
(or if it is a greater number than count of the commits since last bump). It 
will happily convert release 0.1 to 3, 29.20130501hg26242d0aa7b8 to 30 or even 
release 500 to 10.


I converted all of my packages with it and in some cases I had to manually fix 
the results.


E.g.:

https://src.fedoraproject.org/rpms/printrun/pull-request/8
https://src.fedoraproject.org/rpms/pypy3.10/pull-request/15#comment-179619
https://src.fedoraproject.org/rpms/poly2tri/pull-request/2 + fixup commit on 
top https://src.fedoraproject.org/rpms/poly2tri/c/053f90


I had to push https://src.fedoraproject.org/rpms/simarrange/c/4ec0880c after a 
broked automated conversion. It's very hard to notice this when converting ~100 
packages at the same time.


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