Re: Release criteria proposal: except BitLocker-enabled installs from Windows dual-boot criterion bootloader requirement

[Chris Murphy]

On Mon, Sep 19, 2022, at 2:45 PM, Robbie Harwood wrote:

> I'm fine with the proposed change.  I'm also fine with the original
> text.
>
> During boot, certain actions are taken that are recorded in the TPM.
> These include, for instance, any loaders that are run - like grub2.  The
> result is that if you load Windows from grub2 rather than the EFI
> firmware, the TPM state will be different.  Bitlocker cares about this
> TPM state.
>
> So: if you install Windows and set up Bitlocker booting through grub, it
> will continue to work through grub.  

The Windows installer drops a payload on the drive, and sets a bootnext for an 
entry that points to the Windows bootloader, not via GRUB. 

And then, the instant we update either shim or grub, Windows boot will break. 

I think working around this is sufficiently tedious no users are likely to do 
it.

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

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

[updates]

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

inxi-3.3.21-1.el7

Details about builds:



 inxi-3.3.21-1.el7 (FEDORA-EPEL-2022-411d87008f)
 A full featured system information script

Update Information:

Update to 3.3.21.

ChangeLog:

* Mon Sep 19 2022 Vasiliy N. Glazov  - 3.3.21-1
- Update to 3.3.21
* Thu Jul 21 2022 Fedora Release Engineering  - 
3.3.19-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_37_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

[Bug 2127738] perl-Time-Warp-0.55 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #2 from Fedora Update System  ---
FEDORA-2022-482dff1a6c has been pushed to the Fedora 37 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh
--advisory=FEDORA-2022-482dff1a6c`
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2022-482dff1a6c

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information
on how to test updates.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2127738
___
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 2126682] Obsolete perl-Lingua-EN-Syllable as it was retired and is blocking the upgrade path to Fedora 37

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version||fedora-obsolete-packages-37
   ||-6
 Status|ON_QA   |CLOSED
 Resolution|--- |ERRATA
Last Closed|2022-09-14 08:48:55 |2022-09-20 00:15:44



--- Comment #3 from Fedora Update System  ---
FEDORA-2022-7f390fcbe8 has been pushed to the Fedora 37 stable repository.
If problem still persists, please make note of it in this bug report.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2126682
___
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 2127069] perl-Log-Report-1.34 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version|perl-Log-Report-1.34-1.fc38 |perl-Log-Report-1.34-1.fc38
   ||perl-Log-Report-1.34-1.fc37
 Resolution|--- |ERRATA
Last Closed||2022-09-20 00:16:40



--- Comment #8 from Fedora Update System  ---
FEDORA-2022-227be6757a has been pushed to the Fedora 37 stable repository.
If problem still persists, please make note of it in this bug report.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2127069
___
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 2126978] perl-Regexp-Grammars-1.058 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version||perl-Regexp-Grammars-1.058-
   ||1.fc37
 Resolution|--- |ERRATA
Last Closed||2022-09-20 00:16:43



--- Comment #5 from Fedora Update System  ---
FEDORA-2022-9cbeed5e2b has been pushed to the Fedora 37 stable repository.
If problem still persists, please make note of it in this bug report.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2126978
___
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 2126679] Obsolete perl-Lingua-EN-Fathom as it was retired and is blocking the upgrade path to Fedora 37

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version||fedora-obsolete-packages-37
   ||-6
 Resolution|--- |ERRATA
Last Closed|2022-09-14 08:44:21 |2022-09-20 00:15:41



--- Comment #3 from Fedora Update System  ---
FEDORA-2022-7f390fcbe8 has been pushed to the Fedora 37 stable repository.
If problem still persists, please make note of it in this bug report.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2126679
___
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 2126677] Obsolete perl-File-Inplace as it was retired and is blocking the upgrade path to Fedora 37

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version||fedora-obsolete-packages-37
   ||-6
 Status|ON_QA   |CLOSED
 Resolution|--- |ERRATA
Last Closed|2022-09-14 08:34:55 |2022-09-20 00:15:39



--- Comment #3 from Fedora Update System  ---
FEDORA-2022-7f390fcbe8 has been pushed to the Fedora 37 stable repository.
If problem still persists, please make note of it in this bug report.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2126677
___
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 2126661] Remove from a distribution

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Resolution|RAWHIDE |ERRATA



--- Comment #5 from Fedora Update System  ---
FEDORA-2022-7f390fcbe8 has been pushed to the Fedora 37 stable repository.
If problem still persists, please make note of it in this bug report.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2126661
___
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: Release criteria proposal: except BitLocker-enabled installs from Windows dual-boot criterion bootloader requirement

[Chris Adams]

Once upon a time, Robbie Harwood  said:
> So: if you install Windows and set up Bitlocker booting through grub, it
> will continue to work through grub.  If you install Windows outside grub
> (or it's pre-provisioned), it will continue to work outside grub.  If
> you want to move from not using grub to using grub, then Bitlocker needs
> to be reestablished with the new TPM values.

Aside from this not covering what is likely the most common case of
installing Linux on a computer that had Windows pre-installed (as Adam
pointed out)... is there any documentation on how to fix a pre-existing
Windows install that is broken by booting grub?

Also: if I understand the TPM measured boot methodology correctly, this
exposes the Windows install to being lost when grub is updated, because
there's no way for the Linux system updating grub to update the Windows
stored hash.  Users would have to have their Bitlocker recovery key at
the ready (and know how to use it) BEFORE any potential grub update.

We really need grub to support setting the UEFI BootNext value; it's the
safest and sanest way to boot Windows with the least impact.  Is there a
technical reason grub should _not_ do this?

I guess an alternative if grub devs refuse to support this would be a
stand-alone UEFI executable that could set BootNext and reboot.

-- 
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: Release criteria proposal: except BitLocker-enabled installs from Windows dual-boot criterion bootloader requirement

[Demi Marie Obenour]

On 9/19/22 16:45, Robbie Harwood wrote:
> Adam Williamson  writes:
> 
>> For background here, see:
>> https://bugzilla.redhat.com/show_bug.cgi?id=2049849
>>
>> right now, when installing Fedora alongside a Windows install with
>> BitLocker enabled, trying to boot Windows from the Fedora boot menu
>> does not work.
>>
>> We waived the bug as a blocker for Fedora 36 on the basis upstream did
>> not consider it fixable within the F36 timeframe. We agreed that if
>> upstream still couldn't get this fixed for F37, we'd consider revising
>> the criteria.
>>
>> Well, we're approaching F37 Final and the bug is still open, and
>> there's no appreciable movement upstream, so I'm proposing the criteria
>> change. I propose we change this:
>>
>> "The installer must be able to install into free space alongside an
>> existing clean Windows installation and install a bootloader which can
>> boot into both Windows and Fedora."
>>
>> to say:
>>
>> "The installer must be able to install into free space alongside an
>> existing clean Windows installation. As long as the Windows
>> installation does not have BitLocker enabled, the installer must also
>> install a bootloader which can boot into both Windows and Fedora."
> 
> (Fedora grub2 maintainer hat on)
> 
> I'm fine with the proposed change.  I'm also fine with the original
> text.
> 
> During boot, certain actions are taken that are recorded in the TPM.
> These include, for instance, any loaders that are run - like grub2.  The
> result is that if you load Windows from grub2 rather than the EFI
> firmware, the TPM state will be different.  Bitlocker cares about this
> TPM state.
> 
> So: if you install Windows and set up Bitlocker booting through grub, it
> will continue to work through grub.  If you install Windows outside grub
> (or it's pre-provisioned), it will continue to work outside grub.  If
> you want to move from not using grub to using grub, then Bitlocker needs
> to be reestablished with the new TPM values.
> 
> It is the opinion of the grub2 maintainers that this constitutes being
> able to boot both Windows and Fedora today.  However, we also understand
> that not everyone agrees with this, as evidenced by the existence of the
> bug and this thread about changing RC.
> 
> The only way to get the TPM state to match not using a particular loader
> is to not use a loader - i.e., have grub2 (or efibootmgr in Fedora
> userspace) set EFI BootNext and reboot the machine.  But generally, if
> users want to be booting Windows through grub, we recommend they
> configure Bitlocker against those PCR values instead.

That is a terrible user experience.  Grub should support setting BootNext
and rebooting.
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
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: Release criteria proposal: except BitLocker-enabled installs from Windows dual-boot criterion bootloader requirement

[Adam Williamson]

On Mon, 2022-09-19 at 16:45 -0400, Robbie Harwood wrote:
> Adam Williamson  writes:
> 
> > For background here, see:
> > https://bugzilla.redhat.com/show_bug.cgi?id=2049849
> > 
> > right now, when installing Fedora alongside a Windows install with
> > BitLocker enabled, trying to boot Windows from the Fedora boot menu
> > does not work.
> > 
> > We waived the bug as a blocker for Fedora 36 on the basis upstream did
> > not consider it fixable within the F36 timeframe. We agreed that if
> > upstream still couldn't get this fixed for F37, we'd consider revising
> > the criteria.
> > 
> > Well, we're approaching F37 Final and the bug is still open, and
> > there's no appreciable movement upstream, so I'm proposing the criteria
> > change. I propose we change this:
> > 
> > "The installer must be able to install into free space alongside an
> > existing clean Windows installation and install a bootloader which can
> > boot into both Windows and Fedora."
> > 
> > to say:
> > 
> > "The installer must be able to install into free space alongside an
> > existing clean Windows installation. As long as the Windows
> > installation does not have BitLocker enabled, the installer must also
> > install a bootloader which can boot into both Windows and Fedora."
> 
> (Fedora grub2 maintainer hat on)
> 
> I'm fine with the proposed change.  I'm also fine with the original
> text.
> 
> During boot, certain actions are taken that are recorded in the TPM.
> These include, for instance, any loaders that are run - like grub2.  The
> result is that if you load Windows from grub2 rather than the EFI
> firmware, the TPM state will be different.  Bitlocker cares about this
> TPM state.
> 
> So: if you install Windows and set up Bitlocker booting through grub, it
> will continue to work through grub.  If you install Windows outside grub
> (or it's pre-provisioned), it will continue to work outside grub.  If
> you want to move from not using grub to using grub, then Bitlocker needs
> to be reestablished with the new TPM values.
> 
> It is the opinion of the grub2 maintainers that this constitutes being
> able to boot both Windows and Fedora today.  However, we also understand
> that not everyone agrees with this, as evidenced by the existence of the
> bug and this thread about changing RC.

Practically speaking, the way this is "expected" to work is, you get a
system with Windows pre-installed, then you install Fedora, and Fedora
makes it so you can boot both Fedora and Windows. This is the
expectation that's built up around how things ought to work, and it's
what the existing criterion is trying to express.

In general, people do not start out with Linux installed and then
install Windows, this just isn't really a thing that happens a lot.

The word 'you' in your text is kinda doing a lot of heavy lifting. I
would say that what we (we-as-in-Fedora) are concerned with here are
users who do not want to know or care about the details of grub or UEFI
or Windows or BitLocker. The user does not really "want" to "move from
not using grub to using grub". The user wants to move from only having
Windows to having both Windows and Linux. That's the high-level goal
here. grub is an implementation detail (chosen by "us", Fedora, not by
the user).

> The only way to get the TPM state to match not using a particular loader
> is to not use a loader - i.e., have grub2 (or efibootmgr in Fedora
> userspace) set EFI BootNext and reboot the machine.  But generally, if
> users want to be booting Windows through grub, we recommend they
> configure Bitlocker against those PCR values instead.

Is there a good place to point folks who are interested in the
technical details here for documentation?

Thanks!
-- 
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
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

Re: Release criteria proposal: except BitLocker-enabled installs from Windows dual-boot criterion bootloader requirement

[Robbie Harwood]

Adam Williamson  writes:

> For background here, see:
> https://bugzilla.redhat.com/show_bug.cgi?id=2049849
>
> right now, when installing Fedora alongside a Windows install with
> BitLocker enabled, trying to boot Windows from the Fedora boot menu
> does not work.
>
> We waived the bug as a blocker for Fedora 36 on the basis upstream did
> not consider it fixable within the F36 timeframe. We agreed that if
> upstream still couldn't get this fixed for F37, we'd consider revising
> the criteria.
>
> Well, we're approaching F37 Final and the bug is still open, and
> there's no appreciable movement upstream, so I'm proposing the criteria
> change. I propose we change this:
>
> "The installer must be able to install into free space alongside an
> existing clean Windows installation and install a bootloader which can
> boot into both Windows and Fedora."
>
> to say:
>
> "The installer must be able to install into free space alongside an
> existing clean Windows installation. As long as the Windows
> installation does not have BitLocker enabled, the installer must also
> install a bootloader which can boot into both Windows and Fedora."

(Fedora grub2 maintainer hat on)

I'm fine with the proposed change.  I'm also fine with the original
text.

During boot, certain actions are taken that are recorded in the TPM.
These include, for instance, any loaders that are run - like grub2.  The
result is that if you load Windows from grub2 rather than the EFI
firmware, the TPM state will be different.  Bitlocker cares about this
TPM state.

So: if you install Windows and set up Bitlocker booting through grub, it
will continue to work through grub.  If you install Windows outside grub
(or it's pre-provisioned), it will continue to work outside grub.  If
you want to move from not using grub to using grub, then Bitlocker needs
to be reestablished with the new TPM values.

It is the opinion of the grub2 maintainers that this constitutes being
able to boot both Windows and Fedora today.  However, we also understand
that not everyone agrees with this, as evidenced by the existence of the
bug and this thread about changing RC.

The only way to get the TPM state to match not using a particular loader
is to not use a loader - i.e., have grub2 (or efibootmgr in Fedora
userspace) set EFI BootNext and reboot the machine.  But generally, if
users want to be booting Windows through grub, we recommend they
configure Bitlocker against those PCR values instead.

Be well,
--Robbie


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

[EPEL-devel] Re: Fwd: xscreensaver package for epel9 (Bugzilla 2120163)

[Jonathan Wright via epel-devel]

I replied to the BZ offering to package it in EPEL9.  Requester should get
copied on that.

On Mon, Sep 19, 2022 at 11:29 AM Troy Dawson  wrote:

> For those that are wondering, the latest version in rawhide build on epel9
> without any changes needed.
> So it should be fairly straightforward.
>
> Troy
>
>
> On Mon, Sep 19, 2022 at 4:20 AM Stephen Smoogen 
> wrote:
>
>>
>> This went to the mailing list admins versus the list. I don't think this
>> person is on the list so you will need to cc them an answer.
>>
>> -- Forwarded message -
>> From: metatron...@yahoo.com 
>> Date: Sun, 18 Sept 2022 at 20:01
>> Subject: xscreensaver package for epel9 (Bugzilla 2120163)
>> To: epel-devel-ow...@lists.fedoraproject.org <
>> epel-devel-ow...@lists.fedoraproject.org>
>>
>>
>> Hello EPEL Development Team,
>>
>> I was wondering if there are any packagers who would be willing to
>> package and maintain xscreensaver in EPEL9. I previously created a Bugzilla
>> ticket at https://bugzilla.redhat.com/show_bug.cgi?id=2120163. The
>> current package maintainer for Fedora is not able to maintain an EPEL
>> package (as noted in the comments of the ticket). Is there a packager who
>> would be willing to make xscreensaver available in EPEL9? Thank you so much
>> for your consideration!
>>
>> Regards,
>> metatron320
>>
>>
>>
>>
>> --
>> Stephen Smoogen, Red Hat Automotive
>> Let us be kind to one another, for most of us are fighting a hard battle.
>> -- Ian MacClaren
>> ___
>> epel-devel mailing list -- epel-devel@lists.fedoraproject.org
>> To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
>> Fedora Code of Conduct:
>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives:
>> https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
>> Do not reply to spam, report it:
>> https://pagure.io/fedora-infrastructure/new_issue
>>
> ___
> epel-devel 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
>


-- 
Jonathan Wright
AlmaLinux Foundation
Mattermost: chat 
___
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

[Bug 2124543] perl-SOAP-WSDL-3.004-11.fc38 FTBFS: Can't locate CGI.pm in @INC at t/SOAP/WSDL/Server/Simple.t line 6

[bugzilla]

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

Bug 2126943 Summary: Review Request: perl-Template-Plugin-CGI - Simple Template 
Toolkit plugin interfacing to the CGI.pm module
https://bugzilla.redhat.com/show_bug.cgi?id=2126943

   What|Removed |Added

 Status|ASSIGNED|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=2124543
___
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

F38 proposal: PHP 8.2 (Self-Contained Change proposal)

[Ben Cotton]

https://fedoraproject.org/wiki/Changes/php82

This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.

== Summary ==
Update the PHP stack in Fedora to the latest version 8.2.x

== Owner ==
* Name: [[User:Remi| Remi Collet]] and [[SIGs/PHP|PHP SIG]]
* Email: remi at fedoraproject dot org


== Detailed Description ==

Update the PHP stack in Fedora to latest version 8.2.x.

Fedora has a 6 months cycle, PHP a 1 year cycle, our common practice
for some years:

* 2 Fedora cycles for each PHP minor release (exceptions below)
* 3 Fedora cycles for latest minor (e.g. 5.6 or 7.4) to give more time
before next major
* 1 Fedora cycle for first major (e.g. 7.0 or 8.0)

== Benefit to Fedora ==

Provides the latest PHP version to developers and system administrators.


== Scope ==
* Proposal owners: Check Koschei status. Test with latest version to
ensure compatibility. Work with upstream on bug fixing. Needed mass
rebuild (C extensions) done by change owner.

* Other developers: N/A (not a System Wide Change)
* Release engineering:
* Policies and guidelines: N/A (not a System Wide Change)
* Trademark approval: N/A (not needed for this Change)


== Upgrade/compatibility impact ==
N/A (not a System Wide Change)

== How To Test ==

* The PHP stack (extensions and libraries) are monitored by Koschei,
see the 
[https://apps.fedoraproject.org/koschei/groups/php?order_by=state%2C-started
Koschei PHP group]
* install and play with your web applications

== User Experience ==

Developers and system administrators will have the great benefit or
running the latest PHP version.


== Dependencies ==

All php-* packages (and some *-php)

== Contingency Plan ==

* Contingency mechanism: Drop not compatible packages.
 Contingency deadline: N/A (not a System Wide Change)
* Blocks release? N/A
* Blocks product?

== Documentation ==
* [https://raw.githubusercontent.com/php/php-src/PHP-8.2/UPGRADING UPGRADING]
* [https://raw.githubusercontent.com/php/php-src/PHP-8.2/UPGRADING.INTERNALS
UPGRADING.INTERNALS]

== Release Notes ==



-- 
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

F38 proposal: PHP 8.2 (Self-Contained Change proposal)

[Ben Cotton]

https://fedoraproject.org/wiki/Changes/php82

This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.

== Summary ==
Update the PHP stack in Fedora to the latest version 8.2.x

== Owner ==
* Name: [[User:Remi| Remi Collet]] and [[SIGs/PHP|PHP SIG]]
* Email: remi at fedoraproject dot org


== Detailed Description ==

Update the PHP stack in Fedora to latest version 8.2.x.

Fedora has a 6 months cycle, PHP a 1 year cycle, our common practice
for some years:

* 2 Fedora cycles for each PHP minor release (exceptions below)
* 3 Fedora cycles for latest minor (e.g. 5.6 or 7.4) to give more time
before next major
* 1 Fedora cycle for first major (e.g. 7.0 or 8.0)

== Benefit to Fedora ==

Provides the latest PHP version to developers and system administrators.


== Scope ==
* Proposal owners: Check Koschei status. Test with latest version to
ensure compatibility. Work with upstream on bug fixing. Needed mass
rebuild (C extensions) done by change owner.

* Other developers: N/A (not a System Wide Change)
* Release engineering:
* Policies and guidelines: N/A (not a System Wide Change)
* Trademark approval: N/A (not needed for this Change)


== Upgrade/compatibility impact ==
N/A (not a System Wide Change)

== How To Test ==

* The PHP stack (extensions and libraries) are monitored by Koschei,
see the 
[https://apps.fedoraproject.org/koschei/groups/php?order_by=state%2C-started
Koschei PHP group]
* install and play with your web applications

== User Experience ==

Developers and system administrators will have the great benefit or
running the latest PHP version.


== Dependencies ==

All php-* packages (and some *-php)

== Contingency Plan ==

* Contingency mechanism: Drop not compatible packages.
 Contingency deadline: N/A (not a System Wide Change)
* Blocks release? N/A
* Blocks product?

== Documentation ==
* [https://raw.githubusercontent.com/php/php-src/PHP-8.2/UPGRADING UPGRADING]
* [https://raw.githubusercontent.com/php/php-src/PHP-8.2/UPGRADING.INTERNALS
UPGRADING.INTERNALS]

== Release Notes ==



-- 
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Release criteria proposal: except BitLocker-enabled installs from Windows dual-boot criterion bootloader requirement

[Adam Williamson]

For background here, see:
https://bugzilla.redhat.com/show_bug.cgi?id=2049849

right now, when installing Fedora alongside a Windows install with
BitLocker enabled, trying to boot Windows from the Fedora boot menu
does not work.

We waived the bug as a blocker for Fedora 36 on the basis upstream did
not consider it fixable within the F36 timeframe. We agreed that if
upstream still couldn't get this fixed for F37, we'd consider revising
the criteria.

Well, we're approaching F37 Final and the bug is still open, and
there's no appreciable movement upstream, so I'm proposing the criteria
change. I propose we change this:

"The installer must be able to install into free space alongside an
existing clean Windows installation and install a bootloader which can
boot into both Windows and Fedora."

to say:

"The installer must be able to install into free space alongside an
existing clean Windows installation. As long as the Windows
installation does not have BitLocker enabled, the installer must also
install a bootloader which can boot into both Windows and Fedora."
-- 
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
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

Re: FYI: livesys and livesys-late init.d files left over after Fedora installation

[Adam Williamson]

On Mon, 2022-09-19 at 12:53 -0400, Neal Gompa wrote:
> On Mon, Sep 19, 2022 at 12:50 PM Brian C. Lane  wrote:
> > 
> > On Mon, Sep 19, 2022 at 11:08:35AM +0200, Kamil Paral wrote:
> > > On Mon, Sep 19, 2022 at 10:46 AM Marius Schwarz 
> > > wrote:
> > > 
> > > > 
> > > > Hi,
> > > > 
> > > > if Fedora 35 Liveimage is used to install Fedora, livesys and
> > > > livesys-late initscripts are incorrectly copied onto the system
> > > > or not deleted after they lost their functionality.
> > > > 
> > > 
> > > That's not a bug, that's expected. They should be no-op on the installed
> > > system. Nobody cared enough to come up with a better system yet. But now
> > > that fedora-autofirstboot exists, I filed a ticket about it here:
> > > https://pagure.io/fedora-autofirstboot/issue/3
> > 
> > A while back there was an initial attempt at replacing the scripts with
> > a proper package and systemd units:
> > 
> > https://pagure.io/livesys-scripts
> > 
> 
> I'd like to switch to this for F38 if we can. :)

Then it'd probably be a good idea to file a Change...
-- 
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
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

Re: Donate 1 minute of your time to test upgrades from F36 to F37

[James E. LaBarre]

Also encountered the same error for 0ad
---

Error: 
 Problem: problem with installed package 0ad-0.0.25b-2.fc36.x86_64
  - package 0ad-0.0.25b-2.fc36.x86_64 requires 
libboost_filesystem.so.1.76.0()(64bit), but none of the providers can be 
installed
  - boost-filesystem-1.76.0-12.fc36.x86_64 does not belong to a distupgrade 
repository
(try to add '--skip-broken' to skip uninstallable packages)

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

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

[Kevin Fenzi]

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

- Forwarded message from Jiri Olsa  -

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

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

> Date: Sun, 4 Sep 2022 14:36:13 +0200
> From: Jiri Olsa 
> To: devel@lists.fedoraproject.org, Kevin Fenzi 
> Cc: jo...@fedoraproject.org
> Subject: Re: unannounced soname bump in libbpf
> 
> On Sat, Sep 03, 2022 at 05:01:47PM -0700, Kevin Fenzi wrote:
> > Greetings. 
> > 
> > Seems the latest rawhide build of libbpf bumps soname, breaking a number
> > of dependent packages. ;( 
> > 
> > https://koji.fedoraproject.org/koji/buildinfo?buildID=2057060
> > 
> > According to the rawhide updates policy: 
> > https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#_rawhide
> > 
> > "When a proposed update contains an ABI or API change: 
> > notify a week in advance both the devel list and maintainers directly
> > (using the packagename-maintain...@fedoraproject.org alias)
> > whose packages depend on yours to rebuild or offer to do these rebuilds for 
> > them."
> 
> hi,
> sorry, I overlooked this
> 
> > 
> > I've untagged that build from rawhide, can you please make a sidetag
> > (fedpkg request-sidetag) and tag that build in there and get all the
> > dependent packages rebuilt with it?
> > 
> > Let me know if you have any questions/need any help, happy to help out. 
> > 
> > kevin
> 
> I'll check on that and let you know, thanks for help

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

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

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

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

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

I have few questions:

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

and that chage goes to rawhide branch?

thanks,
jirka


- End forwarded message -


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

Re: FYI: livesys and livesys-late init.d files left over after Fedora installation

[Neal Gompa]

On Mon, Sep 19, 2022 at 12:50 PM Brian C. Lane  wrote:
>
> On Mon, Sep 19, 2022 at 11:08:35AM +0200, Kamil Paral wrote:
> > On Mon, Sep 19, 2022 at 10:46 AM Marius Schwarz 
> > wrote:
> >
> > >
> > > Hi,
> > >
> > > if Fedora 35 Liveimage is used to install Fedora, livesys and
> > > livesys-late initscripts are incorrectly copied onto the system
> > > or not deleted after they lost their functionality.
> > >
> >
> > That's not a bug, that's expected. They should be no-op on the installed
> > system. Nobody cared enough to come up with a better system yet. But now
> > that fedora-autofirstboot exists, I filed a ticket about it here:
> > https://pagure.io/fedora-autofirstboot/issue/3
>
> A while back there was an initial attempt at replacing the scripts with
> a proper package and systemd units:
>
> https://pagure.io/livesys-scripts
>

I'd like to switch to this for F38 if we can. :)



-- 
真実はいつも一つ！/ 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: FYI: livesys and livesys-late init.d files left over after Fedora installation

[Brian C. Lane]

On Mon, Sep 19, 2022 at 11:08:35AM +0200, Kamil Paral wrote:
> On Mon, Sep 19, 2022 at 10:46 AM Marius Schwarz 
> wrote:
> 
> >
> > Hi,
> >
> > if Fedora 35 Liveimage is used to install Fedora, livesys and
> > livesys-late initscripts are incorrectly copied onto the system
> > or not deleted after they lost their functionality.
> >
> 
> That's not a bug, that's expected. They should be no-op on the installed
> system. Nobody cared enough to come up with a better system yet. But now
> that fedora-autofirstboot exists, I filed a ticket about it here:
> https://pagure.io/fedora-autofirstboot/issue/3

A while back there was an initial attempt at replacing the scripts with
a proper package and systemd units:

https://pagure.io/livesys-scripts

the current scripts check for rd.live.image on the cmdline and won't run
without it. They also check for /.liveimg-configured or
/.liveimg-late-configured and won't run with those files present.

https://pagure.io/fedora-kickstarts/blob/main/f/fedora-live-base.ks

Brian

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

Re: Inactive packagers to be removed after the F37 release

[Kevin Fenzi]

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

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

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

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

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

Absoluetely.

kevin


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

[EPEL-devel] Re: Fwd: xscreensaver package for epel9 (Bugzilla 2120163)

[Troy Dawson]

For those that are wondering, the latest version in rawhide build on epel9
without any changes needed.
So it should be fairly straightforward.

Troy


On Mon, Sep 19, 2022 at 4:20 AM Stephen Smoogen  wrote:

>
> This went to the mailing list admins versus the list. I don't think this
> person is on the list so you will need to cc them an answer.
>
> -- Forwarded message -
> From: metatron...@yahoo.com 
> Date: Sun, 18 Sept 2022 at 20:01
> Subject: xscreensaver package for epel9 (Bugzilla 2120163)
> To: epel-devel-ow...@lists.fedoraproject.org <
> epel-devel-ow...@lists.fedoraproject.org>
>
>
> Hello EPEL Development Team,
>
> I was wondering if there are any packagers who would be willing to package
> and maintain xscreensaver in EPEL9. I previously created a Bugzilla ticket
> at https://bugzilla.redhat.com/show_bug.cgi?id=2120163. The current
> package maintainer for Fedora is not able to maintain an EPEL package (as
> noted in the comments of the ticket). Is there a packager who would be
> willing to make xscreensaver available in EPEL9? Thank you so much for your
> consideration!
>
> Regards,
> metatron320
>
>
>
>
> --
> Stephen Smoogen, Red Hat Automotive
> Let us be kind to one another, for most of us are fighting a hard battle.
> -- Ian MacClaren
> ___
> epel-devel mailing list -- epel-devel@lists.fedoraproject.org
> To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Fedora rawhide compose report: 20220917.n.0 changes

[Vít Ondruch]

The only sad thing about this is that "FINISHED" compose very likely 
does not create "releng/failed-composes" ticket, so it is harder to 
notice. Therefore thx for the heads up and congratulations to everybody 
involved.



Vít


Dne 17. 09. 22 v 19:07 Kevin Fenzi napsal(a):

On Sat, Sep 17, 2022 at 11:15:40AM +, Fedora Rawhide Report wrote:

OLD: Fedora-Rawhide-20220916.n.0
NEW: Fedora-Rawhide-20220917.n.0

On Sat, Sep 17, 2022 at 12:51:42PM +, Fedora Rawhide Report wrote:

OLD: Fedora-37-20220916.n.0
NEW: Fedora-37-20220917.n.0

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

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

kevin

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
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
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: Inactive packagers to be removed after the F37 release

[Vít Ondruch]

Dne 16. 09. 22 v 19:03 Kevin Fenzi napsal(a):

On Fri, Sep 16, 2022 at 10:03:35AM +0200, Vít Ondruch wrote:

Isn't peer review much better and easier solution over all? We could also
require signed commits I guess.

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



This proposal was based mainly upon the conversation, where nothing what 
was proposed was secure enough. Every proposal was shot down having some 
possible holes. While peer review might be slow and it is certainly not 
bullet proof, I don't think we can do any better.


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



Vít




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

kevin

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

[Lokesh Mandvekar]

On Thu, Sep 15, 2022 at 6:06 PM Sérgio Basto  wrote:
>
> if we can have chromium-src-devel ...

Thanks.

Couldn't find a prior bz so I filed
https://bugzilla.redhat.com/show_bug.cgi?id=2128011

>
> > > > But, one thing that could be done to simplify things would be to
> > > > ship
> > > > a chromium-src-devel package in the chromium package that
> > > > electron
> > > > could pull in. That would tightly couple the chromium and
> > > > electron
> > > > packages, but it would mean that improvements we make to the
> > > > chromium
>
> On Thu, 2022-09-15 at 15:14 -0400, Lokesh Mandvekar wrote:
> > Resuming this thread as the podman and podman-desktop teams are
> > looking to get podman-desktop packaged in Fedora
> > But it's unlikely either team would be able to own the nodejs-
> > electron dep.
> >
> > Would the nodejs sig and/or fedora desktop team and/or chromium
> > maintainers be willing to package and own nodejs-electron?
> >
> > There's an open github issue pointing to this thread but that may not
> > get enough Fedora eyes so I'm
> > checking back here. (See:
> > https://github.com/containers/podman-desktop/issues/112)
> >
> > On Sun, Mar 27, 2022 at 3:38 PM Sérgio Basto 
> > wrote:
> > >
> > > On Sun, 2022-03-27 at 14:52 -0400, Neal Gompa wrote:
> > > > On Sun, Mar 27, 2022 at 2:42 PM Sérgio Basto 
> > > > wrote:
> > > > >
> > > > > On Sun, 2022-02-27 at 17:15 +0100, Andreas Schneider wrote:
> > > > > > On Sunday, 27 February 2022 10:06:17 CET Vitaly Zaitsev via
> > > > > > devel
> > > > > > wrote:
> > > > > > > On 27/02/2022 08:23, Andreas Schneider wrote:
> > > > > > >
> > > > > > > > You don't have to. You can point electron builder to your
> > > > > > > > system
> > > > > > > > electron
> > > > > > > > and
> > > > > >  it will use that. Then you just do not package the electron
> > > > > > files.
> > > > > > > > All you need is the resources directory.
> > > > > > >
> > > > > > >
> > > > > > > You must run electron-builder on Fedora Koji. Pre-built
> > > > > > > packages
> > > > > > > are
> > > > > > > not
> > > > > > > allowed.
> > > > > >
> > > > > > You should not package electron at all with your package! You
> > > > > > should
> > > > > > use the
> > > > > > nodejs-electron in the distribution and just point it to the
> > > > > > sources to
> > > > > > load:
> > > > > >
> > > > > > cat <%{buildroot}%{_bindir}/signal-desktop
> > > > > > #!/bin/sh
> > > > > > export NODE_ENV=production
> > > > > >
> > > > > > exec %{_bindir}/electron
> > > > > > %{_libdir}/%{name}/resources/app.asar
> > > > > > "\$@"
> > > > > > EOF
> > > > > > chmod +x %{buildroot}%{_bindir}/signal-desktop
> > > > >
> > > > > I started build electron on copr [1]
> > > > >
> > > > > I built ffmpeg , nodejs-electron, element-web and element-
> > > > > desktop
> > > > > for
> > > > > Fedora 34 and 35 successfully element-web fails on F36+
> > > > >
> > > > > I rebuilt ffmpeg-free from Fedora to F35 and F34
> > > > > after I used
> > > > > https://build.opensuse.org/package/show/network:im:signal/nodejs-electron
> > > > > https://build.opensuse.org/package/show/devel:languages:javascript/element-web
> > > > > https://build.opensuse.org/package/show/home:sergiomb/element-desktop
> > > > >
> > > > >
> > > > > build on electron took 11 hours on x64 and 15 hours in aarch ,
> > > > > is
> > > > > almost a build o chromium , which make me wonder if we can't
> > > > > use a
> > > > > chromium as a library
> > > > > https://www.electronjs.org/blog/electron-internals-building-chromium-as-a-library
> > > > >
> > > >
> > > > libchromiumcontent hasn't been a thing in a *very* long time. It
> > > > was
> > > > merged into Electron in Electron 4.0 (which was years ago!) and
> > > > it's
> > > > all built as one runtime environment binary.
> > > >
> > > > But, one thing that could be done to simplify things would be to
> > > > ship
> > > > a chromium-src-devel package in the chromium package that
> > > > electron
> > > > could pull in. That would tightly couple the chromium and
> > > > electron
> > > > packages, but it would mean that improvements we make to the
> > > > chromium
> > > > package would be easily consumed by electron...
> > > >
> > >
> > > yes, I think that should be the path and and I'd love see that done
> > > ,
> > > also for other projects like nwjs (node-webkit)
> > > https://github.com/nwjs/nw.js , doesn't make sense to me build
> > > chromium
> > > all the times , mainly because chromium takes hours and hours to
> > > build
> > > and consumes a lot and a lot of resources.
> > >
> > > > I'm not sure we *want* to do that, but I have seen that done
> > > > before
> > > > for Electron packaging...
> > > >
> > > >
> > > > --
> > > > 真実はいつも一つ！/ 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:
> > > > 

Lenovo Linux systems online in Europe - and thank you Fedora community!

[Mark Pearson]

For anybody who went and left feedback on the web sales site asking for
Linux after my last email - a big thank you. I can't help but think it
must have been a factor in the below.

Linux systems (multiple!) are now available in Europe, including of
course Fedora:

I think the below is the full list currently:
  Carbon 10 (includes Fedora)
  Z13  (includes Fedora)
  Z16  (includes Fedora)
  P14s
  P16s
  X13 Yoga G3
  T14s G3
  T14 G3
  T16 G3
  P360 (tiny, tower, ultra)
(Missing from our completed platforms is the X1 Nano G2, and the
L-series strangely)

We have more coming and the best thing is that the EMEA team have made
it so if Linux is available it should just be added. How well that works
we'll see - but I'm optimistic I won't have to battle them going forwards.

I do have some notes of caution:

 - The user interface is not perfect, especially around invalid
configurations (e.g. if you select the MIPI camera on the X1 Carbon).
The invalid config will get flagged, but it's kinda annoying.
They are looking at how to improve it so please don't beat them up about
it - the alternative was to not have Linux online (for potentially a
long time). We'll make it better - and the ultimate aim is to have no
Linux limitations!

 - In Europe they also have the 'no-OS' option and that is still
(usually) cheaper than the Linux option. Realistically - there is no
good technical reason not to buy no-OS as the Fedora (or Ubuntu) image
is not modified by Lenovo. But please consider:

 1) Some of the proceeds from that extra goes to the Lenovo Linux team
directly. We're quite a small team and I'd like us to grow and in
particular get more engineering experience so we can contribute more
directly to projects upstream - we don't do enough of it. It's also the
best way I'm likely going to be able to grow the team to take on more
platforms - we're pretty swamped with what we currently have.

 2) This is the *only* way we have of measuring real consumer demand for
Linux. This will drive the web teams to keep doing (and hopefully do
more) Linux; and it gets the product teams to think about it and
recognise the market for Linux is really there.

We should have some more AMD platforms in the next few weeks. The mobile
workstations are proving to be challenging so are still a bit out. I
have concerns about the Fedora offering there because of the Nvidia
driver - but we'll do what we can.

I'm still working on the other geo's but will be using Europe as an
example of what can be done (and hopefully we get the sales that make it
meaningful and act as an extra carrot). Please spread the word in the
Linux community (I'm not allowed to contact any media outlets directly -
I'm working with the marketing team...but they don't understand Linux).

If the system you want isn't available in your geo - let the web team
know through the feedback form :)

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

[Michael Catanzaro]

On Mon, Sep 19 2022 at 04:29:22 PM +0200, Kalev Lember 
 wrote:
I would guess it happened because the F36 webkitgtk version number 
was ahead of the F37 webkitgtk version, so the versioned obsoletes 
that the F37 webkitgtk packages have didn't match.


Oh, OK then. Good catch!

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

[Kalev Lember]

On Mon, Sep 19, 2022 at 3:52 PM Michael Catanzaro 
wrote:

> On Mon, Sep 19 2022 at 12:08:10 AM +0200, Robert-André Mauchin
>  wrote:
> > Error: Transaction test error:
> >   file /usr/bin/WebKitWebDriver from install of
> > webkit2gtk4.1-2.37.91-1.fc37.x86_64
> > conflicts with file from package webkit2gtk3-2.38.0-2.fc36.x86_64
>
> This problem would go away if webkit2gtk3 (F36 package) were replaced
> by webkit2gtk4.0 (corresponding F37 package, which does not provide
> /usr/bin/WebKitWebdriver). I don't know why that is not happening, so
> I'm not sure what to do about this.
>

I would guess it happened because the F36 webkitgtk version number was
ahead of the F37 webkitgtk version, so the versioned obsoletes that the F37
webkitgtk packages have didn't match.

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

[Michael Catanzaro]

I see a similar report here:

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

which reveals a packaging bug. But that one is slightly different 
because there is an additional conflict with webkit2gtk5.0 as well, 
which is a bug (only one of the F37 packages should provide the file 
/usr/bin/WebKitWebDriver). I will fix that, but if you provided the 
full error message, then it won't help with your problem.


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

[Michael Catanzaro]

On Mon, Sep 19 2022 at 12:08:10 AM +0200, Robert-André Mauchin 
 wrote:

Error: Transaction test error:
  file /usr/bin/WebKitWebDriver from install of 
webkit2gtk4.1-2.37.91-1.fc37.x86_64

conflicts with file from package webkit2gtk3-2.38.0-2.fc36.x86_64


This problem would go away if webkit2gtk3 (F36 package) were replaced 
by webkit2gtk4.0 (corresponding F37 package, which does not provide 
/usr/bin/WebKitWebdriver). I don't know why that is not happening, so 
I'm not sure what to do about this.


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

[Fedora Rawhide Report]

OLD: Fedora-37-20220918.n.0
NEW: Fedora-37-20220919.n.0

= SUMMARY =
Added images:0
Dropped images:  0
Added packages:  6
Dropped packages:0
Upgraded packages:   188
Downgraded packages: 0

Size of added packages:  3.54 MiB
Size of dropped packages:0 B
Size of upgraded packages:   1.74 GiB
Size of downgraded packages: 0 B

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

= ADDED IMAGES =

= DROPPED IMAGES =

= ADDED PACKAGES =
Package: fedora-autofirstboot-1-1.fc37
Summary: Collection of firstboot services for Fedora
RPMs:fedora-autofirstboot
Size:16.74 KiB

Package: gnome-browser-connector-42.1-1.fc37
Summary: GNOME Shell browser connector
RPMs:gnome-browser-connector
Size:256.33 KiB

Package: libmd-1.0.4-2.fc37
Summary: Library that provides message digest functions from BSD systems
RPMs:libmd libmd-devel
Size:375.57 KiB

Package: plasma-mobile-5.25.5-1.fc37
Summary: General UI components for Plasma Phone including shell, containment 
and applets
RPMs:plasma-mobile
Size:2.43 MiB

Package: plasma-nano-5.25.5-1.fc37
Summary: A minimalist Plasma shell for developing custom experiences on 
embedded devices.
RPMs:plasma-nano
Size:474.39 KiB

Package: rust-gag-1.0.0-1.fc37
Summary: Redirect, or hold stdout/stderr output
RPMs:rust-gag+default-devel rust-gag-devel
Size:20.86 KiB


= DROPPED PACKAGES =

= UPGRADED PACKAGES =
Package:  YafaRay-3.5.1-19.fc37
Old package:  YafaRay-3.5.1-18.fc37
Summary:  A free open-source ray-tracing render engine
RPMs: YafaRay YafaRay-blender YafaRay-devel YafaRay-lib python3-YafaRay
Size: 4.54 MiB
Size change:  -1.70 KiB
Changelog:
  * Mon Sep 12 2022 Luya Tshimbalanga  - 3.5.1-19
  - Rebuild for blender 3.3.0


Package:  ansible-collection-community-general-5.6.0-1.fc37
Old package:  ansible-collection-community-general-5.4.0-1.fc37
Summary:  Modules and plugins supported by Ansible community
RPMs: ansible-collection-community-general
Size: 1.49 MiB
Size change:  15.06 KiB
Changelog:
  * Thu Aug 25 2022 Maxwell G  - 5.5.0-1
  - Update to 5.5.0. Fixes rhbz#2120735.

  * Tue Sep 13 2022 Maxwell G  - 5.6.0-1
  - Update to 5.6.0.


Package:  autofs-1:5.1.8-6.fc37
Old package:  autofs-1:5.1.8-5.fc37
Summary:  A tool for automatically mounting and unmounting filesystems
RPMs: autofs
Size: 1.50 MiB
Size change:  18.15 KiB
Changelog:
  * Tue Sep 13 2022 Ian Kent  - 1:5.1.8-6
  - fix changelog out of order entry.
  - fix missing unlock in sasl_do_kinit_ext_cc().
  - fix file listed twice in spec file.
  - fix build breakage due to glibc change.


Package:  blender-1:3.3.0-4.fc37
Old package:  blender-1:3.2.2-2.fc37
Summary:  3D modeling, animation, rendering and post-production
RPMs: blender blender-rpm-macros
Size: 152.89 MiB
Size change:  -7.34 MiB
Changelog:
  * Mon Sep 12 2022 Luya Tshimbalanga  1:3.3.0-1
  - Update to 3.3.0 (#2125188)

  * Tue Sep 13 2022 Luya Tshimbalanga  1:3.3.0-2
  - Disable native Wayland support reserved for Rawhide

  * Wed Sep 14 2022 Luya Tshimbalanga  1:3.3.0-4
  - Synchronise all branches


Package:  bluedevil-5.25.5-1.fc37
Old package:  bluedevil-5.25.4-1.fc37
Summary:  Bluetooth stack for KDE
RPMs: bluedevil
Size: 1.91 MiB
Size change:  855 B
Changelog:
  * Wed Sep 07 2022 Marc Deop  - 5.25.5-1
  - 5.25.5


Package:  breeze-gtk-5.25.5-1.fc37
Old package:  breeze-gtk-5.25.4-1.fc37
Summary:  Breeze widget theme for GTK
RPMs: breeze-gtk breeze-gtk-common breeze-gtk-gtk2 breeze-gtk-gtk3 
breeze-gtk-gtk4
Size: 412.96 KiB
Size change:  -65 B
Changelog:
  * Wed Sep 07 2022 Marc Deop  - 5.25.5-1
  - 5.25.5


Package:  breeze-icon-theme-5.98.0-1.fc37
Old package:  breeze-icon-theme-5.96.0-2.fc37
Summary:  Breeze icon theme
RPMs: breeze-icon-theme breeze-icon-theme-rcc
Size: 11.45 MiB
Size change:  1.83 MiB
Changelog:
  * Sat Aug 13 2022 Justin Zobel  - 5.97.0-1
  - Update to 5.97.0

  * Mon Aug 15 2022 Yaroslav Sidlovsky  - 5.97.0-2
  - BR: python3-lxml

  * Thu Sep 15 2022 Marc Deop  - 5.98.0-1
  - 5.98.0


Package:  canl-java-2.8.2-1.fc37
Old package:  canl-java-2.8.0-2.fc37
Summary:  EMI Common Authentication library - bindings for Java
RPMs: canl-java canl-java-javadoc
Size: 804.15 KiB
Size change:  455 B
Changelog:
  * Wed Sep 14 2022 Mattias Ellert  - 2.8.2-1
  - Update to 2.8.2


Package:  cataclysm-dda-0.F.3-1.fc37
Old package:  cataclysm-dda-0.F.2-3.fc36
Summary:  Turn-based survival game set in a post-apocalyptic world
RPMs: cataclysm-dda cataclysm-dda-data cataclysm-dda-tiles 
cataclysm-dda-tiles-data
Size: 82.30 MiB
Size change:  -6.33 MiB
Changelog:
  * Fri Sep 02 2022 Petr Salaba  - 0.F.3-1
  - Update to 0.F-3

  * Fri Sep 02 2022 Petr Salaba  - 0.F.2-6
  - Fix compile error

Re: Inactive packagers to be removed after the F37 release

[Demi Marie Obenour]

On 9/19/22 04:52, Petr Pisar wrote:
> V Fri, Sep 16, 2022 at 01:56:03PM -0400, Todd Zullinger napsal(a):
>> Kevin Fenzi wrote:
>>> On Fri, Sep 16, 2022 at 10:03:35AM +0200, Vít Ondruch wrote:
 Isn't peer review much better and easier solution over all? We could also
 require signed commits I guess.
>>>
>>> I think it would slow things down quite a lot to require peer review of
>>> every commit. 
>>>
>>> I'd personally like to avoid anything where we need to support gpg.
>>> It's a mess and I think it would waste a lot of cycles explaining how to
>>> use it or help people get setup. ;( If there's some easier/more clear
>>> way to sign things that could be a option tho.
>>
>> Since git-2.34 (released in November of last year), ssh may
>> be used for signing commits and/or pushes.  That's likely a
>> bit simpler than gpg.
>>
> Is administrating SSH keys any easier (for a packager and for Fedora
> infrastructure) than PGP keys?

Yes, it is.  ssh-keygen -Y is much much simpler to use than gpg.
Verifying SSH signatures does not expose Fedora servers to DoS
attacks the way verifying PGP signatures would.  And the same
key can be used for both SSH and for signing, without creating
security risks.  Furthermore, OpenSSH supports using any FIDO2
token for key storage, not just more expensive PGP-capable
tokens.
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
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: 20220919.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20220918.n.0
NEW: Fedora-Rawhide-20220919.n.0

= SUMMARY =
Added images:0
Dropped images:  1
Added packages:  0
Dropped packages:0
Upgraded packages:   63
Downgraded packages: 2

Size of added packages:  0 B
Size of dropped packages:0 B
Size of upgraded packages:   370.12 MiB
Size of downgraded packages: 2.53 MiB

Size change of upgraded packages:   -5.28 MiB
Size change of downgraded packages: 68.90 KiB

= ADDED IMAGES =

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

= ADDED PACKAGES =

= DROPPED PACKAGES =

= UPGRADED PACKAGES =
Package:  asahi-scripts-20220918.2-4.fc38
Old package:  asahi-scripts-20220821-3.fc38
Summary:  Miscellaneous admin scripts for Asahi Linux
RPMs: asahi-scripts dracut-asahi update-m1n1 update-vendor-firmware
Added RPMs:   asahi-scripts dracut-asahi
Dropped RPMs: dracut-config-asahi
Size: 40.27 KiB
Size change:  12.30 KiB
Changelog:
  * Sun Sep 18 2022 Davide Cavalca  20220821-4
  - Refresh dracut config and install it in the correct path

  * Sun Sep 18 2022 Davide Cavalca  20220918.2-1
  - Update to 20220918.2

  * Sun Sep 18 2022 Davide Cavalca  20220918.2-2
  - Add dracut module

  * Sun Sep 18 2022 Davide Cavalca  20220918.2-3
  - Rename dracut-config-asahi to dracut-asahi

  * Sun Sep 18 2022 Davide Cavalca  20220918.2-4
  - Add trailing slash to folders


Package:  blivet-gui-2.4.0-1.fc38
Old package:  blivet-gui-2.3.0-8.fc38
Summary:  Tool for data storage configuration
RPMs: blivet-gui blivet-gui-runtime
Size: 435.22 KiB
Size change:  26.49 KiB
Changelog:
  * Sun Sep 18 2022 Vojtech Trefny  - 2.4.0-1
  - Translated using Weblate (Russian) (mistresssilvara)
  - Translated using Weblate (Russian) (xasertop)
  - misc: Add vagrant and ansible configuration for openSUSE (vtrefny)
  - packit: Add srpm_build_deps for SRPM builds in Copr (vtrefny)
  - Tell blivet to ignore zRAM devices (vtrefny)
  - Translated using Weblate (Portuguese (Brazil)) (mairacanal)
  - Use "folder" icon for LVM and other "complex" devices (vtrefny)
  - Translated using Weblate (Hungarian) (meskobalazs)
  - Check arguments when running blivet-gui-daemon (#2106214) (vtrefny)
  - Translated using Weblate (Georgian) (temuri.doghonadze)
  - Translated using Weblate (Georgian) (temuri.doghonadze)
  - Added translation using Weblate (Georgian) (temuri.doghonadze)
  - misc: Vagrantfile updated with latest Fedora and Ubuntu releases (vtrefny)
  - Do not install the libreport/abrt configuration in setup.py (vtrefny)
  - Remove python3-mock from test dependencies (vtrefny)
  - ci: Use latest checkout action in GitHub actions (vtrefny)
  - Replace pocketlint with a custom script (vtrefny)
  - ci: Run static analysis checks in GitHub actions (vtrefny)
  - Translated using Weblate (Friulian) (f.t.public)
  - pylint: Remove deprecated pylint warnings from pylintrc and code (vtrefny)
  - Translated using Weblate (Spanish) (alex)
  - Translated using Weblate (Swedish) (bittin)
  - Translated using Weblate (Bengali (India)) (mitra_anirban)
  - Translated using Weblate (Slovak) (feonsu)
  - spec: Remove dependecy on gettext (vtrefny)
  - Translated using Weblate (Spanish) (alex)
  - Translated using Weblate (Czech) (pavel.borecki)
  - Translated using Weblate (Croatian) (linux.hr)
  - Translated using Weblate (Korean) (simmon)
  - Translated using Weblate (Turkish) (oguz)
  - Translated using Weblate (Finnish) (ricky.tigg)
  - Translated using Weblate (Ukrainian) (yurchor)
  - Translated using Weblate (Polish) (piotrdrag)
  - Update translation files (noreply)
  - Fix grammar for some visible labels in LVMEditDialog (vtrefny)
  - appdata: Remove information about kickstart support (vtrefny)
  - pylint: Allow loading all C extensions (vtrefny)
  - POT file update (vtrefny)
  - Add missing log calls for utils functions (vtrefny)
  - Use close button for the device info dialog instead of cancel (vtrefny)
  - Change label for the LUKS "decrypt" menu item to "unlock" (vtrefny)
  - Small UI adjustments in FormatDialog (vtrefny)
  - POT file update (vtrefny)
  - Remove old remnants of Python 2 support (vtrefny)
  - Add tooltips for the toolbar buttons (vtrefny)
  - Remove unused code from actions list (vtrefny)
  - Log set_mountpoint operation to the utils log (vtrefny)
  - utils: Add function to log to the utils log (vtrefny)
  - Various grammar fixes in README.md, CONTRIBUTING.md and doc/intro.rst 
(vtrefny)
  - tests: Add tests for dialogs helper functions (vtrefny)
  - tests: Add test for ResizeDialog (vtrefny)
  - tests: Add test for UnmountDialog (vtrefny)
  - tests: Add test for LabelDialog (vtrefny)
  - tests: Add test for MountpointDialog (vtrefny)
  - Add more tests for ListPartitions covering missing functions (vtrefny)
  - Remove some old

[EPEL-devel] Fwd: xscreensaver package for epel9 (Bugzilla 2120163)

[Stephen Smoogen]

This went to the mailing list admins versus the list. I don't think this
person is on the list so you will need to cc them an answer.

-- Forwarded message -
From: metatron...@yahoo.com 
Date: Sun, 18 Sept 2022 at 20:01
Subject: xscreensaver package for epel9 (Bugzilla 2120163)
To: epel-devel-ow...@lists.fedoraproject.org <
epel-devel-ow...@lists.fedoraproject.org>


Hello EPEL Development Team,

I was wondering if there are any packagers who would be willing to package
and maintain xscreensaver in EPEL9. I previously created a Bugzilla ticket
at https://bugzilla.redhat.com/show_bug.cgi?id=2120163. The current package
maintainer for Fedora is not able to maintain an EPEL package (as noted in
the comments of the ticket). Is there a packager who would be willing to
make xscreensaver available in EPEL9? Thank you so much for your
consideration!

Regards,
metatron320




-- 
Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Fedora support for new aarch64 chip

[Peter Robinson]

Hi Hua,

> I need to install Fedora IoT to our chip but I realize that the 
> Fedora-IoT-ostree-aarch64-36-20220618.0.iso does not support our GPU driver 
> so we can't install it.
>
> + Document about our chip: 
> https://www.google.com/url?sa=t=j==s=web==rja=8=2ahUKEwjetPb6iKD6AhVrqFYBHcmdAUkQFnoECA4QAQ=https%3A%2F%2Fwww.renesas.com%2Fus%2Fen%2Fproducts%2Fmicrocontrollers-microprocessors%2Frz-mpus%2Frzg2m-ultra-high-performance-microprocessors-arm-cortex-a57-and-arm-cortex-a53-cpus-3d-graphics-and-4k=AOvVaw3Ymgg6zOhVGXdomup7g4Ef

The general process is to engage with the Arm SIG [1] and work with
them on it. We have not enabled Renesas in the past because their SoC
parts have typically been focused towards automotive and they've not
engaged with us so we can engage with the SoC in case of problems. In
the very least we will need commitments to testing the SoC in an
ongoing manner to ensure it continues to work.

> + This is our GPU driver: 
> https://github.com/renesas-rz/rz_linux-cip/tree/rz-5.10-cip1-rt1/drivers/gpu/drm/rcar-du

This will need to be upstreamed in the upstream linus kernel before we
can look at enabling it.

> Could anyone help me with how I can integrate our GPU driver into OS?

It will not just be the GPU, but the whole SoC that will need to be enabled.

[1] https://lists.fedoraproject.org/archives/list/a...@lists.fedoraproject.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

Schedule for Tuesday's FESCo Meeting (2022-09-20)

[Miro Hrončok]

Following is the list of topics that will be discussed in the
FESCo meeting Tuesday at 17:00UTC in #fedora-meeting on
irc.libera.chat.

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

or run:
  date -d '2022-09-20 17:00 UTC'


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

= Discussed and Voted in the Ticket =

Nonresponsive maintainer: Daniel Bruno 
https://pagure.io/fesco/issue/2852
APPROVED (+1, 0, -0)

Change: pcre deprecation
https://pagure.io/fesco/issue/2862
APPROVED (+3, 0, -0)

= Followups =

#2859 F37 incomplete Changes: 100% complete deadline
https://pagure.io/fesco/issue/2859

https://fedoraproject.org/wiki/Changes/JdkInTreeLibsAndStdclibStatic was 
submitted as an Fedora 37 update after it was deferred to Fedora 38. We need to 
decide what to do.


= Open Floor =

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

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

--
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: FYI: livesys and livesys-late init.d files left over after Fedora installation

[Kamil Paral]

On Mon, Sep 19, 2022 at 10:46 AM Marius Schwarz 
wrote:

>
> Hi,
>
> if Fedora 35 Liveimage is used to install Fedora, livesys and
> livesys-late initscripts are incorrectly copied onto the system
> or not deleted after they lost their functionality.
>

That's not a bug, that's expected. They should be no-op on the installed
system. Nobody cared enough to come up with a better system yet. But now
that fedora-autofirstboot exists, I filed a ticket about it here:
https://pagure.io/fedora-autofirstboot/issue/3
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: FYI: livesys and livesys-late init.d files left over after Fedora installation

[yanqiyu]

在 2022-09-19星期一的 10:44 +0200，Marius Schwarz写道：
> 
> Hi,
> 
> if Fedora 35 Liveimage is used to install Fedora, livesys and 
> livesys-late initscripts are incorrectly copied onto the system
> or not deleted after they lost their functionality.

I believe that everything in Live image is copied to installed system,
like I can found anaconda related packages on in installed Fedora. 

$ rpm -qa|grep anaconda
anaconda-user-help-26.2-3.fc37.noarch
kdump-anaconda-addon-006-7.20220714git7ca2d3e.fc37.noarch
anaconda-widgets-37.12.4-1.fc37.x86_64
anaconda-tui-37.12.4-1.fc37.x86_64
anaconda-core-37.12.4-1.fc37.x86_64
anaconda-gui-37.12.4-1.fc37.x86_64
anaconda-37.12.4-1.fc37.x86_64
anaconda-live-37.12.4-1.fc37.x86_64
anaconda-install-env-deps-37.12.4-1.fc37.x86_64
libreport-anaconda-2.17.4-1.fc37.x86_64

> [...]
> 
> afaik they don't do harm if not deleted.

They don't harm, but I tend to delete them, I just deleted those
anaconda packages too (be careful this will clean up some depends like
tmux, use `dnf mark install` if you don't want to)

Also, why don't we do the clean up as part of configuration of
installed system? This can be a good feature for anaconda.

> 
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines:
> https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> 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: Inactive packagers to be removed after the F37 release

[Petr Pisar]

V Fri, Sep 16, 2022 at 01:56:03PM -0400, Todd Zullinger napsal(a):
> Kevin Fenzi wrote:
> > On Fri, Sep 16, 2022 at 10:03:35AM +0200, Vít Ondruch wrote:
> >> Isn't peer review much better and easier solution over all? We could also
> >> require signed commits I guess.
> > 
> > I think it would slow things down quite a lot to require peer review of
> > every commit. 
> > 
> > I'd personally like to avoid anything where we need to support gpg.
> > It's a mess and I think it would waste a lot of cycles explaining how to
> > use it or help people get setup. ;( If there's some easier/more clear
> > way to sign things that could be a option tho.
> 
> Since git-2.34 (released in November of last year), ssh may
> be used for signing commits and/or pushes.  That's likely a
> bit simpler than gpg.
> 
Is administrating SSH keys any easier (for a packager and for Fedora
infrastructure) than PGP keys?

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

Re: Inactive packagers to be removed after the F37 release

[Petr Pisar]

V Fri, Sep 16, 2022 at 05:30:13PM +, Tommy Nguyen napsal(a):
> With that being said, if a GPG key would be compromised, wouldn't it
> result in an error when trying to update the package? An end user would
> then report the bug, someone would see that the key does not match the
> signature in the gpg-distribution package, signalling that it's
> compromised.

Compromised GPG key means something else. It means that you have a valid
signature for a package made with a genuine Fedora packager's key. But not
made by the Fedora packager. You won't recognize a compromised key by checking
the signatures.

You probably wanted to write a compromised dist-git account. In that case the
GPG signature would help.

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

FYI: livesys and livesys-late init.d files left over after Fedora installation

[Marius Schwarz]

Hi,

if Fedora 35 Liveimage is used to install Fedora, livesys and 
livesys-late initscripts are incorrectly copied onto the system

or not deleted after they lost their functionality.

This happens afterwards...

[Jul 5 17:01] systemd-sysv-generator[72798]: SysV service 
'/etc/rc.d/init.d/livesys' lacks a native systemd unit file. 
Automatically generating a unit file for compatibility. Please update 
package to include a native systemd unit file, in order to make it more 
safe and robust.
[  +0,26] systemd-sysv-generator[72798]: SysV service 
'/etc/rc.d/init.d/livesys-late' lacks a native systemd unit file. 
Automatically generating a unit file for compatibility. Please update 
package to include a native systemd unit file, in order to make it more 
safe and robust.
[  +0,368763] systemd-sysv-generator[72836]: SysV service 
'/etc/rc.d/init.d/livesys' lacks a native systemd unit file. 
Automatically generating a unit file for compatibility. Please update 
package to include a native systemd unit file, in order to make it more 
safe and robust.
[  +0,24] systemd-sysv-generator[72836]: SysV service 
'/etc/rc.d/init.d/livesys-late' lacks a native systemd unit file. 
Automatically generating a unit file for compatibility. Please update 
package to include a native systemd unit file, in order to make it more 
safe and robust.


afaik they don't do harm if not deleted.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
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 2127738] perl-Time-Warp-0.55 is available

[bugzilla]

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



--- Comment #1 from Fedora Update System  ---
FEDORA-2022-482dff1a6c has been submitted as an update to Fedora 37.
https://bodhi.fedoraproject.org/updates/FEDORA-2022-482dff1a6c


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2127738
___
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 2127738] perl-Time-Warp-0.55 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED
   Fixed In Version||perl-Time-Warp-0.55-1.fc38




-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2127738
___
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

[rpms/perl-Time-Warp] PR #1: Tests

[Jitka Plesnikova]

jplesnik merged a pull-request against the project: `perl-Time-Warp` that you 
are following.

Merged pull-request:

``
Tests
``

https://src.fedoraproject.org/rpms/perl-Time-Warp/pull-request/1
___
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

[rpms/perl-Time-Warp] PR #1: Tests

[Jitka Plesnikova]

jplesnik opened a new pull-request against the project: `perl-Time-Warp` that 
you are following:
``
Tests
``

To reply, visit the link below
https://src.fedoraproject.org/rpms/perl-Time-Warp/pull-request/1
___
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: Explicit dependency on systemd-rpm-macros now required?

[Dan Horák]

On Fri, 16 Sep 2022 13:42:42 +
Zbigniew Jędrzejewski-Szmek  wrote:

> On Fri, Sep 16, 2022 at 03:35:29PM +0200, Florian Weimer wrote:
> > * Zbigniew Jędrzejewski-Szmek:
> > 
> > > So… we certainly don't want people having to declare the dependency
> > > manually everywhere.
> > 
> > The packaging guidelines seem to say that the manual dependency is
> > required, though.
> 
> Yeah, you need *some* dependency. But opencryptoki has
> BR:systemd-devel, and systemd-devel has R:systemd, which has the
> Requires(meta) under discussion. So an explicit BR:systemd-rpm-macros
> should be redundant.

the BR: systemd-devel in opencryptoki might be just a historical
relict, because it used to be required to define the various macros
(IIRC)


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

Re: Fedora support for new aarch64 chip

[Dan Horák]

On Mon, 19 Sep 2022 05:31:38 -
"Hua Duy"  wrote:

> Hello all,
> 
> I need to install Fedora IoT to our chip but I realize that the 
> Fedora-IoT-ostree-aarch64-36-20220618.0.iso does not support our GPU driver 
> so we can't install it.
> 
> + Document about our chip: 
> https://www.google.com/url?sa=t=j==s=web==rja=8=2ahUKEwjetPb6iKD6AhVrqFYBHcmdAUkQFnoECA4QAQ=https%3A%2F%2Fwww.renesas.com%2Fus%2Fen%2Fproducts%2Fmicrocontrollers-microprocessors%2Frz-mpus%2Frzg2m-ultra-high-performance-microprocessors-arm-cortex-a57-and-arm-cortex-a53-cpus-3d-graphics-and-4k=AOvVaw3Ymgg6zOhVGXdomup7g4Ef
> 
> + This is our GPU driver: 
> https://github.com/renesas-rz/rz_linux-cip/tree/rz-5.10-cip1-rt1/drivers/gpu/drm/rcar-du
> 
> Could anyone help me with how I can integrate our GPU driver into OS? 

Fedora can only distribute drivers that are part of the official Linux
kernel tree.


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

Re: Fedora support for new aarch64 chip

[Florian Weimer]

* Hua Duy:

> Hello all,
>
> I need to install Fedora IoT to our chip but I realize that the 
> Fedora-IoT-ostree-aarch64-36-20220618.0.iso does not support our GPU driver 
> so we can't install it.
>
> + Document about our chip: 
> https://www.google.com/url?sa=t=j==s=web==rja=8=2ahUKEwjetPb6iKD6AhVrqFYBHcmdAUkQFnoECA4QAQ=https%3A%2F%2Fwww.renesas.com%2Fus%2Fen%2Fproducts%2Fmicrocontrollers-microprocessors%2Frz-mpus%2Frzg2m-ultra-high-performance-microprocessors-arm-cortex-a57-and-arm-cortex-a53-cpus-3d-graphics-and-4k=AOvVaw3Ymgg6zOhVGXdomup7g4Ef
>
> + This is our GPU driver: 
> https://github.com/renesas-rz/rz_linux-cip/tree/rz-5.10-cip1-rt1/drivers/gpu/drm/rcar-du
>
> Could anyone help me with how I can integrate our GPU driver into OS?

Looks like this is still being submitted upstream:

  [PATCH v7 0/2] Add RZ/G2L DSI driver
  


Fedora does not usually take non-upstream patches (although AArch64 has
historically been an exception), so I suggest to wait for the kernel
integration.  You may still have to submit a MR update with a config
update to .

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: Explicit dependency on systemd-rpm-macros now required?

[Florian Weimer]

* Zbigniew Jędrzejewski-Szmek:

> On Fri, Sep 16, 2022 at 03:35:29PM +0200, Florian Weimer wrote:
>> * Zbigniew Jędrzejewski-Szmek:
>> 
>> > So… we certainly don't want people having to declare the dependency
>> > manually everywhere.
>> 
>> The packaging guidelines seem to say that the manual dependency is
>> required, though.
>
> Yeah, you need *some* dependency. But opencryptoki has
> BR:systemd-devel, and systemd-devel has R:systemd, which has the
> Requires(meta) under discussion. So an explicit BR:systemd-rpm-macros
> should be redundant.

That's not how I interpret the guidelines.  It mentions
systemd-rpm-macros only.  Relying on systemd (or some other package
that's not closely related to the control of the package being built) is
brittle, as we've seen.

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 2127738] perl-Time-Warp-0.55 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC|iarn...@gmail.com,  |
   |jples...@redhat.com |
   Doc Type|--- |If docs needed, set a value




-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2127738
___
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