Re: about dnf installonlypks

[Samuel Sieb]

On 7/26/22 19:27, Sérgio Basto wrote:

Hi,
after searching a lot still can't find how installonlypks package list
is generated

I found these 2 references :
https://dnf.readthedocs.io/en/latest/command_ref.html
https://docs.fedoraproject.org/en-US/Fedora/24/html/System_Administrators_Guide/sec-Configuring_DNF_and_DNF_Repositories.html

dnf repoquery --installonly
 Limit the resulting set to installed installonly packages.

I see the list of installonlypkgs , but where in Centos Stream 9, I get
his list of installonlypkgs and how I can modify it i.e. what package
set or unset packages on this list of installonly pakages ?


The default list is hardcoded into dnf.  I expect that you can modify it 
with a config option.

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

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

[updates]

The following Fedora EPEL 7 Security updates need testing:
 Age  URL
   4  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-e05ac11f9b   
openssl11-1.1.1k-4.el7


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

bgpq4-1.5-1.el7
tio-1.46-1.el7

Details about builds:



 bgpq4-1.5-1.el7 (FEDORA-EPEL-2022-541ae4b59c)
 Automate BGP filter generation based on routing database information

Update Information:

# bgpq4 1.5  This release adds support for the new Junos `as-path-origins`
feature. This Junos feature allows matching the right most AS number on the AS
path belongs to the `as-list-group` specified in the `as-path-origins`
configuration statement at the `[edit policy-options policy-statement policy-
name from]` hierarchy level.  Example:  ``` $ bgpq4 -J -H 15562 -l 15562_in
AS15562:AS-SNIJDERS policy-options { replace:  as-list-group 15562_in {   as-
list a0 members 15562;   as-list a1 members [ 112 234 267 8952 12654 31451 39765
41731 ];   as-list a2 members [ 41996 43997 44854 48603 51861 57436 57782 60003
];   as-list a3 members [ 60927 61438 199036 202314 202539 205591 205593 205956
];   as-list a4 members [ 206479 206499 206551 208241 210089 212121 ];  } } ```
Review the Junos documentation for more information:
https://www.juniper.net/documentation/us/en/software/junos/routing-
policy/topics/topic-map/Improve-as-path-lookup.html

ChangeLog:

* Tue Jul 26 2022 Robert Scheck  1.5-1
- Upgrade to 1.5 (#2110794)
* Wed Jul 20 2022 Fedora Release Engineering  - 1.4-3
- Rebuilt for https://fedoraproject.org/wiki/Fedora_37_Mass_Rebuild
* Wed Jan 19 2022 Fedora Release Engineering  - 1.4-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_36_Mass_Rebuild

References:

  [ 1 ] Bug #2110794 - bgpq4-1.5 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2110794




 tio-1.46-1.el7 (FEDORA-EPEL-2022-9cd4f841e0)
 Simple TTY terminal I/O application

Update Information:

# tio v1.46* Rework toggle and pulse feature to support all lines
Replace existing toggle and pulse key commands with the following generalized
key commands which allows to toggle or pulse all serial port lines:  `ctrl-t
g` Toggle serial port line  `ctrl-t p` Pulse serial port line  When
used, user will be asked which serial line to toggle or pulse.  Also
introduce `--line-pulse-duration` option for setting specific pulse duration in
milliseconds for each serial line using a key value pair format. Each key
represents a serial line. The following keys are available: DTR, RTS, CTS, DSR,
DCD, RI.  Example: `$ tio /dev/ttyUSB0 --line-pulse-duration
DTR=200,RTS=300,RI=50`  Likewise, the pulse duration can also be set via
configuration file using the line-pulse-duration variable:  `line-pulse-
duration = DTR=200,RTS=300,RI=50`* Upgrade inih wrap to r56*
Optimization* Add example configuration file

ChangeLog:

* Wed Jul 20 2022 Robert Scheck  1.46-1
- Upgrade to 1.46 (#2108938)

References:

  [ 1 ] Bug #2108938 - tio-1.47 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2108938


___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

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

[updates]

The following Fedora EPEL 8 Security updates need testing:
 Age  URL
   7  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-89ad385971   
chromium-103.0.5060.114-1.el8


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

bgpq4-1.5-1.el8
tio-1.46-1.el8

Details about builds:



 bgpq4-1.5-1.el8 (FEDORA-EPEL-2022-0b5cecfb51)
 Automate BGP filter generation based on routing database information

Update Information:

# bgpq4 1.5  This release adds support for the new Junos `as-path-origins`
feature. This Junos feature allows matching the right most AS number on the AS
path belongs to the `as-list-group` specified in the `as-path-origins`
configuration statement at the `[edit policy-options policy-statement policy-
name from]` hierarchy level.  Example:  ``` $ bgpq4 -J -H 15562 -l 15562_in
AS15562:AS-SNIJDERS policy-options { replace:  as-list-group 15562_in {   as-
list a0 members 15562;   as-list a1 members [ 112 234 267 8952 12654 31451 39765
41731 ];   as-list a2 members [ 41996 43997 44854 48603 51861 57436 57782 60003
];   as-list a3 members [ 60927 61438 199036 202314 202539 205591 205593 205956
];   as-list a4 members [ 206479 206499 206551 208241 210089 212121 ];  } } ```
Review the Junos documentation for more information:
https://www.juniper.net/documentation/us/en/software/junos/routing-
policy/topics/topic-map/Improve-as-path-lookup.html

ChangeLog:

* Tue Jul 26 2022 Robert Scheck  1.5-1
- Upgrade to 1.5 (#2110794)
* Wed Jul 20 2022 Fedora Release Engineering  - 1.4-3
- Rebuilt for https://fedoraproject.org/wiki/Fedora_37_Mass_Rebuild
* Wed Jan 19 2022 Fedora Release Engineering  - 1.4-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_36_Mass_Rebuild

References:

  [ 1 ] Bug #2110794 - bgpq4-1.5 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2110794




 tio-1.46-1.el8 (FEDORA-EPEL-2022-86cca7f7cf)
 Simple TTY terminal I/O application

Update Information:

# tio v1.46* Rework toggle and pulse feature to support all lines
Replace existing toggle and pulse key commands with the following generalized
key commands which allows to toggle or pulse all serial port lines:  `ctrl-t
g` Toggle serial port line  `ctrl-t p` Pulse serial port line  When
used, user will be asked which serial line to toggle or pulse.  Also
introduce `--line-pulse-duration` option for setting specific pulse duration in
milliseconds for each serial line using a key value pair format. Each key
represents a serial line. The following keys are available: DTR, RTS, CTS, DSR,
DCD, RI.  Example: `$ tio /dev/ttyUSB0 --line-pulse-duration
DTR=200,RTS=300,RI=50`  Likewise, the pulse duration can also be set via
configuration file using the line-pulse-duration variable:  `line-pulse-
duration = DTR=200,RTS=300,RI=50`* Upgrade inih wrap to r56*
Optimization* Add example configuration file

ChangeLog:

* Wed Jul 20 2022 Robert Scheck  1.46-1
- Upgrade to 1.46 (#2108938)

References:

  [ 1 ] Bug #2108938 - tio-1.47 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2108938


___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 2107867] perl-Net-Amazon-S3-0.991 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-Net-Amazon-S3-0.991-1. |perl-Net-Amazon-S3-0.991-1.
   |fc37|fc37
   |perl-Net-Amazon-S3-0.991-1. |perl-Net-Amazon-S3-0.991-1.
   |fc36|fc36
   |perl-Net-Amazon-S3-0.991-1. |perl-Net-Amazon-S3-0.991-1.
   |fc35|fc35
   ||perl-Net-Amazon-S3-0.991-1.
   ||el8



--- Comment #10 from Fedora Update System  ---
FEDORA-EPEL-2022-e8751d016e has been pushed to the Fedora EPEL 8 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=2107867
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: future of dual booting Windows and Fedora, redux

[Kevin Kofler via devel]

Chris Murphy wrote:
> cryptsetup does have Bitlocker support, so long as you have the recovery
> key you can unlock and get access to your data, I've tested this.

But you need a recovery key to begin with, because the main key is sealed in 
the TPM and not visible from anything other than Windows.

So Bitlocker essentially forces Windows on you.

> Bitlocker has nothing to do with Secure Boot.

Disabling "Secure" (Restricted) Boot will change the TPM measurements and 
hence also prevent the key from being unsealed.

https://docs.microsoft.com/en-us/windows/security/information-protection/bitlocker/bitlocker-countermeasures#uefi-and-secure-boot

So Bitlocker essentially forces Restricted Boot on you.

> This is entirely beside the point though, which is to try and make dual
> boot as useful for users as possible. We want users to be confident about
> both OS's remain accessible in a discoverable way, without having to jump
> through hoops.

Sure. Really sad though that we have to work around a broken piece of 
"security" software that effectively functions like a ransomware.

Where is the outcry about this misfeature?

Setting up Bitlocker behind the user's back, i.e., also without prompting 
for a passphrase, provides absolutely no security in the event of a stolen 
notebook because somebody else hitting the power button will NOT change the 
TPM measurements, the power button is not a fingerprint reader.

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

[Bug 2107867] perl-Net-Amazon-S3-0.991 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-Net-Amazon-S3-0.991-1. |perl-Net-Amazon-S3-0.991-1.
   |fc37|fc37
   |perl-Net-Amazon-S3-0.991-1. |perl-Net-Amazon-S3-0.991-1.
   |fc36|fc36
   ||perl-Net-Amazon-S3-0.991-1.
   ||fc35



--- Comment #9 from Fedora Update System  ---
FEDORA-2022-4706e7fa41 has been pushed to the Fedora 35 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=2107867
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 2109440] perl-Module-CoreList-5.20220720 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Resolution|--- |ERRATA
 Status|ON_QA   |CLOSED
   Fixed In Version|perl-Module-CoreList-5.2022 |perl-Module-CoreList-5.2022
   |0720-1.fc37 |0720-1.fc37
   ||perl-Module-CoreList-5.2022
   ||0720-1.fc36
Last Closed||2022-07-27 02:22:45



--- Comment #5 from Fedora Update System  ---
FEDORA-2022-59c24eb56a has been pushed to the Fedora 36 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=2109440
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 2107867] perl-Net-Amazon-S3-0.991 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Resolution|--- |ERRATA
 Status|ON_QA   |CLOSED
   Fixed In Version|perl-Net-Amazon-S3-0.991-1. |perl-Net-Amazon-S3-0.991-1.
   |fc37|fc37
   ||perl-Net-Amazon-S3-0.991-1.
   ||fc36
Last Closed||2022-07-27 02:22:03



--- Comment #8 from Fedora Update System  ---
FEDORA-2022-a4de56cc2d has been pushed to the Fedora 36 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=2107867
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: future of dual booting Windows and Fedora, redux

[Luya Tshimbalanga]

Could someone sign systemd-boot please? That EFI boot seems simple to 
use and very minimal especially for both x64 arch based desktop and laptop.


On 2022-07-26 16:14, Chris Murphy wrote:


On Tue, Jul 26, 2022, at 4:42 PM, Kevin Kofler via devel wrote:

Chris Murphy wrote:

On Tue, Jul 26, 2022, at 4:06 PM, Kevin Kofler via devel wrote:

As I already mentioned the last time this has come up: Why can we not,
instead of chainloading Windows directly, chainload a systemd-boot
configured to always bootnext to Windows?

Pretty sure shim still hard codes the name grub$arch.efi as the 2nd
bootloader. Hence having to rename sd-boot as grubx64.efi for shim to find
and run it. They can't co-exist right now. Also, there's no current plan
by anyone to add systemd-boot for Secure Boot signing.

That is not what I suggested.

I suggested shim → GRUB → systemd-boot → Windows (and shim → GRUB → Fedora,
systemd-boot would be configured to always reboot to Windows, booting Fedora
from GRUB would bypass it entirely), not shim → systemd-boot → Windows.

OK. But still systemd-boot would need to be signed by Fedora. And be capable of 
defaulting to Windows, and hidden menu, so it doesn't show bootloader snippets 
on the boot or EFI volumes. I don't know whether it can be configured this way.

It's a Rube Goldberg machine way of doing this. In effect three bootloaders to 
support. I'm not convinced this is the path of least resistance. But it seems 
to be worth considering.


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

about dnf installonlypks

[Sérgio Basto]

Hi,
after searching a lot still can't find how installonlypks package list
is generated 

I found these 2 references : 
https://dnf.readthedocs.io/en/latest/command_ref.html
https://docs.fedoraproject.org/en-US/Fedora/24/html/System_Administrators_Guide/sec-Configuring_DNF_and_DNF_Repositories.html

dnf repoquery --installonly
Limit the resulting set to installed installonly packages.

I see the list of installonlypkgs , but where in Centos Stream 9, I get
his list of installonlypkgs and how I can modify it i.e. what package
set or unset packages on this list of installonly pakages ? 

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

[Bug 2110575] perl-HTTP-Tiny-0.082 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #2 from Fedora Update System  ---
FEDORA-2022-a6671de59a has been pushed to the Fedora 36 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-a6671de59a`
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2022-a6671de59a

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=2110575
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: future of dual booting Windows and Fedora, redux

[Chris Murphy]

On Tue, Jul 26, 2022, at 7:18 PM, Chris Adams wrote:
> Once upon a time, Chris Murphy  said:
>> a. Fix GRUB by giving it the ability to modify UEFI NRAM "bootnext" value, 
>> so that instead of chainloading the Windows bootloader from GRUB, GRUB will 
>> modify the system NVRAM such that the next boot (only) will directly boot 
>> the Windows bootloader. Thus far there's no interest by GRUB upstream. 
>> Whereas systemd-boot has implemented it.
>
> Is GRUB upstream any more active these days?

It is but seems there's no interest in this particular issue.

I started a couple threads on this topic previously, but there's not much 
traction:

https://lists.gnu.org/archive/html/grub-devel/2022-02/msg00072.html
https://lists.gnu.org/archive/html/grub-devel/2022-03/msg00227.html


>  IIRC Fedora has a whole
> pile of patches; I'm sure nobody wants the pile to grow, but it doesn't
> look like that's changing.  Could this be implemented in Fedora's GRUB?

It's been cut down quit a bit actually. GRUB 2.06 cut the patchset around in 
half. And GRUB 2.12 release is imminent, which will cut things down farther.

Since the Red Hat bootloader team is pretty swamped as it is, and has indicated 
it needs to drop BIOS support (in favor of the newly minted BIOS SIG) soon, I'm 
skeptical the bootloader team has at least the time to work on this, maintain 
it, and try to push it upstream. Thing is, it really needs upstream to agree to 
it, because if it's not upstreamed, what's the point? This is an issue that 
affects all distros and quite a lot of users eventually, as Bitlocker by 
default becomes more prevalent. Maybe this issue needs more visibility? Behind 
the handful of lists I've tried so far?


-- 
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: future of dual booting Windows and Fedora, redux

[Chris Murphy]

On Tue, Jul 26, 2022, at 9:15 PM, Kevin Kofler via devel wrote:
> Chris Murphy wrote:
>> Summary: Windows 10/11 increasingly enables Bitlocker (full disk
>> encryption) out of the box with the encryption key sealed in the TPM.
> […]
>> The Bitlocker encryption key is unsealed only if the boot chain
>> measurement by the TPM matches the expected values in a TPM PCR.
>
> So, basically, they set up things without the user's knowledge so that the 
> user's data can only be decrypted from Windows, only when booted directly, 
> and only with Restricted Boot enabled. Does that not fit the definition of 
> ransomware? Treacherous Computing at its finest… Does anyone still believe 
> that all this is about security?

cryptsetup does have Bitlocker support, so long as you have the recovery key 
you can unlock and get access to your data, I've tested this.

Bitlocker has nothing to do with Secure Boot.

This is entirely beside the point though, which is to try and make dual boot as 
useful for users as possible. We want users to be confident about both OS's 
remain accessible in a discoverable way, without having to jump through hoops.

-- 
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: future of dual booting Windows and Fedora, redux

[Kevin Kofler via devel]

Chris Murphy wrote:
> Summary: Windows 10/11 increasingly enables Bitlocker (full disk
> encryption) out of the box with the encryption key sealed in the TPM.
[…]
> The Bitlocker encryption key is unsealed only if the boot chain
> measurement by the TPM matches the expected values in a TPM PCR.

So, basically, they set up things without the user's knowledge so that the 
user's data can only be decrypted from Windows, only when booted directly, 
and only with Restricted Boot enabled. Does that not fit the definition of 
ransomware? Treacherous Computing at its finest… Does anyone still believe 
that all this is about security?

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

Re: future of dual booting Windows and Fedora, redux

[Kevin Kofler via devel]

Chris Murphy wrote:
> It's a Rube Goldberg machine way of doing this.

Isn't that the Unix Way?

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

Re: Why is there antlr4-project package?

[Jerry James]

On Tue, Jul 26, 2022 at 5:18 AM Marián Konček  wrote:
> I would still do something about the manually expanded %mvn_install macro.
>
> Is it a big problem to have the java artifacts placed into a
> "anrlt4-project" directory?
>
> If nothing else, maybe you could rpm --eval %%mvn_install | sed '-n
> %{name}' or something like that in the %prep section?

If you find an approach that works, I am happy to accept a pull
request.  I've got enough other things on my plate that I'm probably
not going to mess with it.
-- 
Jerry James
http://www.jamezone.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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: future of dual booting Windows and Fedora, redux

[Chris Murphy]

On Tue, Jul 26, 2022, at 4:59 PM, Neal Gompa wrote:
> On Tue, Jul 26, 2022 at 1:43 PM Kevin Kofler via devel
>  wrote:
>>
>> Chris Murphy wrote:
>> > On Tue, Jul 26, 2022, at 4:06 PM, Kevin Kofler via devel wrote:
>> >> As I already mentioned the last time this has come up: Why can we not,
>> >> instead of chainloading Windows directly, chainload a systemd-boot
>> >> configured to always bootnext to Windows?
>> >
>> > Pretty sure shim still hard codes the name grub$arch.efi as the 2nd
>> > bootloader. Hence having to rename sd-boot as grubx64.efi for shim to find
>> > and run it. They can't co-exist right now. Also, there's no current plan
>> > by anyone to add systemd-boot for Secure Boot signing.
>>
>> That is not what I suggested.
>>
>> I suggested shim → GRUB → systemd-boot → Windows (and shim → GRUB → Fedora,
>> systemd-boot would be configured to always reboot to Windows, booting Fedora
>> from GRUB would bypass it entirely), not shim → systemd-boot → Windows.
>>
>
> That may work indeed, but we'd need to ensure it can't be used as a
> stage-two bootloader somehow.

Maybe systemd-boot signed with a Fedora key only GRUB provides, and shim does 
not?

Either shim or GRUB must have this key so regardless we need help from folks 
who can sign Fedora's bootloaders.

Seems more complicated compared to a user space program that merely does 
`efibootmgr --bootnext $windows` 

-- 
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: future of dual booting Windows and Fedora, redux

[Chris Adams]

Once upon a time, Chris Murphy  said:
> a. Fix GRUB by giving it the ability to modify UEFI NRAM "bootnext" value, so 
> that instead of chainloading the Windows bootloader from GRUB, GRUB will 
> modify the system NVRAM such that the next boot (only) will directly boot the 
> Windows bootloader. Thus far there's no interest by GRUB upstream. Whereas 
> systemd-boot has implemented it.

Is GRUB upstream any more active these days?  IIRC Fedora has a whole
pile of patches; I'm sure nobody wants the pile to grow, but it doesn't
look like that's changing.  Could this be implemented in Fedora's GRUB?
-- 
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: future of dual booting Windows and Fedora, redux

[Chris Murphy]

On Tue, Jul 26, 2022, at 4:42 PM, Kevin Kofler via devel wrote:
> Chris Murphy wrote:
>> On Tue, Jul 26, 2022, at 4:06 PM, Kevin Kofler via devel wrote:
>>> As I already mentioned the last time this has come up: Why can we not,
>>> instead of chainloading Windows directly, chainload a systemd-boot
>>> configured to always bootnext to Windows?
>> 
>> Pretty sure shim still hard codes the name grub$arch.efi as the 2nd
>> bootloader. Hence having to rename sd-boot as grubx64.efi for shim to find
>> and run it. They can't co-exist right now. Also, there's no current plan
>> by anyone to add systemd-boot for Secure Boot signing.
>
> That is not what I suggested.
>
> I suggested shim → GRUB → systemd-boot → Windows (and shim → GRUB → Fedora, 
> systemd-boot would be configured to always reboot to Windows, booting Fedora 
> from GRUB would bypass it entirely), not shim → systemd-boot → Windows.

OK. But still systemd-boot would need to be signed by Fedora. And be capable of 
defaulting to Windows, and hidden menu, so it doesn't show bootloader snippets 
on the boot or EFI volumes. I don't know whether it can be configured this way.

It's a Rube Goldberg machine way of doing this. In effect three bootloaders to 
support. I'm not convinced this is the path of least resistance. But it seems 
to be worth considering.

-- 
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Heads up for Rawhide users of Evolution with Google accounts

[Adam Williamson]

Hey folks! If you're running Rawhide and using Evolution - or anything
else backed by evolution-data-server - with a Google account, you may
have noticed that it doesn't work with evolution-data-server-3.45.1.

The GOA and Google support in Evolution was turned off with the 3.45.1
build, I think because of the ongoing libsoup 2->3 migration (no app
can use both libsoup2 and libsoup3 at the same time, and this is
causing all sorts of inconveniences as we work through moving
everything to libsoup3).

I've set up a COPR:
https://copr.fedorainfracloud.org/coprs/adamwill/evo-gdata-libsoup3/
which has libgdata and gvfs rebuilt against libsoup3, and e-d-s rebuilt
against the new libgdata with Google and GOA support turned back on. I
don't know how much of that was actually necessary, but it is
sufficient - with those builds, Google account support in e-d-s does
seem to work again. The builds aren't really suitable to go in Rawhide
(a couple of them are git snapshots, and a couple use WIP patches from
upstream) but if you really need this to work right away, give it a
shot. I've tried to version the builds such that the next official
builds will supersede them.

I expect mcrha and the rest of the desktop team will be able to fix
this up more permanently in Rawhide soonish.
-- 
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: future of dual booting Windows and Fedora, redux

[Neal Gompa]

On Tue, Jul 26, 2022 at 1:43 PM Kevin Kofler via devel
 wrote:
>
> Chris Murphy wrote:
> > On Tue, Jul 26, 2022, at 4:06 PM, Kevin Kofler via devel wrote:
> >> As I already mentioned the last time this has come up: Why can we not,
> >> instead of chainloading Windows directly, chainload a systemd-boot
> >> configured to always bootnext to Windows?
> >
> > Pretty sure shim still hard codes the name grub$arch.efi as the 2nd
> > bootloader. Hence having to rename sd-boot as grubx64.efi for shim to find
> > and run it. They can't co-exist right now. Also, there's no current plan
> > by anyone to add systemd-boot for Secure Boot signing.
>
> That is not what I suggested.
>
> I suggested shim → GRUB → systemd-boot → Windows (and shim → GRUB → Fedora,
> systemd-boot would be configured to always reboot to Windows, booting Fedora
> from GRUB would bypass it entirely), not shim → systemd-boot → Windows.
>

That may work indeed, but we'd need to ensure it can't be used as a
stage-two bootloader somehow.



-- 
真実はいつも一つ！/ 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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: future of dual booting Windows and Fedora, redux

[Kevin Kofler via devel]

Chris Murphy wrote:
> On Tue, Jul 26, 2022, at 4:06 PM, Kevin Kofler via devel wrote:
>> As I already mentioned the last time this has come up: Why can we not,
>> instead of chainloading Windows directly, chainload a systemd-boot
>> configured to always bootnext to Windows?
> 
> Pretty sure shim still hard codes the name grub$arch.efi as the 2nd
> bootloader. Hence having to rename sd-boot as grubx64.efi for shim to find
> and run it. They can't co-exist right now. Also, there's no current plan
> by anyone to add systemd-boot for Secure Boot signing.

That is not what I suggested.

I suggested shim → GRUB → systemd-boot → Windows (and shim → GRUB → Fedora, 
systemd-boot would be configured to always reboot to Windows, booting Fedora 
from GRUB would bypass it entirely), not shim → systemd-boot → Windows.

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

Re: future of dual booting Windows and Fedora, redux

[Neal Gompa]

On Tue, Jul 26, 2022 at 1:12 PM Chris Murphy  wrote:
>
>
>
> On Tue, Jul 26, 2022, at 4:06 PM, Kevin Kofler via devel wrote:
>
> > As I already mentioned the last time this has come up: Why can we not,
> > instead of chainloading Windows directly, chainload a systemd-boot
> > configured to always bootnext to Windows?
>
> Pretty sure shim still hard codes the name grub$arch.efi as the 2nd 
> bootloader. Hence having to rename sd-boot as grubx64.efi for shim to find 
> and run it. They can't co-exist right now. Also, there's no current plan by 
> anyone to add systemd-boot for Secure Boot signing.
>
> >GRUB would still think it boots
> > Windows directly. (I do not see why it would notice any difference, all that
> > would change is the name of the image that gets chainloaded.) And systemd-
> > boot does not need to know that it is being chainloaded from GRUB. So I do
> > not see why that would not work, without any changes to the software.
>

Put more directly: Microsoft will revoke our shim if we use
anything but GRUB as the stage-two bootloader.

Cf. https://github.com/rhboot/shim/issues/472#issuecomment-1118628769



--
真実はいつも一つ！/ 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 on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 2104259] adapt perl to removal of java on i686

[bugzilla]

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

Bug 2104097 Summary: native R depends on to be removed i686 java-openjdk 
packages
https://bugzilla.redhat.com/show_bug.cgi?id=2104097

   What|Removed |Added

 Status|NEW |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=2104259
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Heads-up: ODE soname bump

[Hedayat Vatankhah]

On ۱۴۰۱/۵/۳ ۴:۵۴ قبل‌ازظهر, Robert-André Mauchin wrote:

On 7/24/22 16:40, Hedayat Vatankhah wrote:

<...>


Use (Close: rhbz#1438205) instead of (rhbz#1438205)
or Closes: rhbz#1438205, Fix: rhbz#1438205, Fixes: rhbz#1438205
to automatically close the related nug


Thanks for the tip.



On 7/24/22 19:14, Maxwell G via devel wrote:
> On 22/07/24 06:05PM, Kalev Lember wrote:
>> If ODE 0.16 was only built as part of the mass rebuild and wasn't
>> available in the buildroot during the mass rebuild (and I don't think
>> it was), then all the other packages that depend on it were still
>> built against the older ODE 0.14 version as part of the mass rebuild.
>> Once the mass rebuild is merged back into f37 then all other packages
>> that depend on ODE are going to have broken dependencies.
>
> That indeed appears to be the case. The f37-rebuild build target[1]
> builds against f37-build but tags completed builds into f37-rebuild.
> ode-0.16.2-2.fc37[2] is only tagged into f37-rebuild.
>
> [1]: https://koji.fedoraproject.org/koji/buildtargetinfo?targetID=24581
> [2]: https://koji.fedoraproject.org/koji/buildinfo?buildID=2016899
>
> Also, looking at ompl, one of ode's dependents, you can see that it was
> rebuilt against the old version of ode:
>
>> DEBUG util.py:445: ode-devel  x86_64  
0.14-15.fc36 build   66 k

>
> -- 
https://kojipkgs.fedoraproject.org//packages/ompl/1.5.0/11.fc37/data/logs/x86_64/root.log 
and
> 
https://koji.fedoraproject.org/koji/buildinfo?buildID=2016925https://koji.fedoraproject.org/koji/buildinfo?buildID=2016925

>
> In order to fix this, a provenpackager will need to build all of the
> dependents in a sidetag like normal. Preferably, this could happen
> before the mass rebuild tag is merged back into f37. I am a bit busy
> today, but I suppose I could do this later if nobody beats me to it.
>

It is done: 
https://bodhi.fedoraproject.org/updates/FEDORA-2022-26df2fedba


Had to fixup freewrl though, the java thing on i686.


Thanks a lot for fixing this. And sorry for the trouble.


Thanks,

Hedayat






Best regards,

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

Re: Heads-up: ODE soname bump

[Hedayat Vatankhah]

  
  


On ۱۴۰۱/۵/۲ ۸:۳۵ بعدازظهر, Kalev Lember
  wrote:


  
  
On Sun, Jul 24, 2022 at 4:41 PM Hedayat Vatankhah
  
  wrote:


  

  Hi all,
  As part of building ODE 0.16, ode's soname has been
bumped from libode.so.4/libode-double.so.4  to
libode.so.8/libode-double.so.8. 
  
  This package is now built as part of Fedora 37 Mass
Rebuild, so we expect all dependent packages to be
automatically built again during this process. 
  
  We do not expect to see compilation failures because of
this update.

  
  
  
  Hi Hedayat,
  
  
  No, this is not how mass rebuilds work. If ODE 0.16 was
only built as part of the mass rebuild and wasn't available
in the buildroot during the mass rebuild (and I don't think
it was), then all the other packages that depend on it were
still built against the older ODE 0.14 version as part of
the mass rebuild. Once the mass rebuild is merged back into
f37 then all other packages that depend on ODE are going to
have broken dependencies.
  

  

Hi Kalev,
Oops, I'm really sorry; I didn't know this.


Thanks,
Hedayat


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

Re: future of dual booting Windows and Fedora, redux

[Chris Murphy]

On Tue, Jul 26, 2022, at 4:06 PM, Kevin Kofler via devel wrote:

> As I already mentioned the last time this has come up: Why can we not, 
> instead of chainloading Windows directly, chainload a systemd-boot 
> configured to always bootnext to Windows? 

Pretty sure shim still hard codes the name grub$arch.efi as the 2nd bootloader. 
Hence having to rename sd-boot as grubx64.efi for shim to find and run it. They 
can't co-exist right now. Also, there's no current plan by anyone to add 
systemd-boot for Secure Boot signing.

>GRUB would still think it boots 
> Windows directly. (I do not see why it would notice any difference, all that 
> would change is the name of the image that gets chainloaded.) And systemd-
> boot does not need to know that it is being chainloaded from GRUB. So I do 
> not see why that would not work, without any changes to the software.

-- 
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: future of dual booting Windows and Fedora, redux

[Kevin Kofler via devel]

Chris Murphy wrote:
> a. Fix GRUB by giving it the ability to modify UEFI NRAM "bootnext" value,
> so that instead of chainloading the Windows bootloader from GRUB, GRUB
> will modify the system NVRAM such that the next boot (only) will directly
> boot the Windows bootloader. Thus far there's no interest by GRUB
> upstream. Whereas systemd-boot has implemented it.

As I already mentioned the last time this has come up: Why can we not, 
instead of chainloading Windows directly, chainload a systemd-boot 
configured to always bootnext to Windows? GRUB would still think it boots 
Windows directly. (I do not see why it would notice any difference, all that 
would change is the name of the image that gets chainloaded.) And systemd-
boot does not need to know that it is being chainloaded from GRUB. So I do 
not see why that would not work, without any changes to the software.

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

Re: Upstream Release Monitoring - bug report

[Maxwell G via devel]

On 22/07/26 09:54AM, Kevin Fenzi wrote:
> If you want to watch activity on a package you want The little 'watch'
> pulldown under The package description. You can set there if you want to
> watch bugs, commits, both, etc. If you only wanted to watch koji builds,
> you would need to set that in FMN (apps.fedoraproject.org/notifications)

Neither FMN nor the "Watch commits" button on src.fp.o work for me. FMN
just shows a page to set my contact information with no way to create
filters; the "Watch commits" option doesn't work on src.fp.o (i.e. it
doesn't send notifications for new commits) despite working on
pagure.io. I believe the FMN brokenness has something to do with my
account not existing in the old FAS2 instance, but I'm not sure about
the src.fp.o issue. Is it some deliberate configuration difference or a
bug?

-- 
Thanks,

Maxwell G (@gotmax23)
Pronouns: He/Him/His


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 on the list, report it: 
https://pagure.io/fedora-infrastructure

future of dual booting Windows and Fedora, redux

[Chris Murphy]

Summary: Windows 10/11 increasingly enables Bitlocker (full disk encryption) 
out of the box with the encryption key sealed in the TPM. Two different issues 
result:

1. Fedora's installer, Anaconda, can't resize Bitlocker volumes. We could use 
better documentation to help the user perform the volume resize in Windows, 
before proceeding to booting our installation media. The documentation probably 
should be explicitly referenced by the Windows version of Fedora Media Writer.

2. The Bitlocker encryption key is unsealed only if the boot chain measurement 
by the TPM matches the expected values in a TPM PCR. When shim+GRUB are in the 
boot chain, as is the case in our default dual boot installation, the 
measurements are wrong, and this means the GRUB menu entry to boot Windows 
won't work. The user is dropped to a Windows Bitlocker recovery page. If they 
have their backup encryption key handy, it will work but to say the least this 
condition is unexpected and not  user friendly - not least of which is many 
users won't have this backup key handy since they didn't take the action to 
enable Bitlocker in the first place.

The bug report for this is https://bugzilla.redhat.com/show_bug.cgi?id=2049849

It was a Fedora 36 final release blocking bug, but considered a "difficult to 
fix" exceptional case, moving it to Fedora 37 final. Some of the options for 
consideration:

a. Fix GRUB by giving it the ability to modify UEFI NRAM "bootnext" value, so 
that instead of chainloading the Windows bootloader from GRUB, GRUB will modify 
the system NVRAM such that the next boot (only) will directly boot the Windows 
bootloader. Thus far there's no interest by GRUB upstream. Whereas systemd-boot 
has implemented it.

b. Add a user space utility modifies system NVRAM such that the next boot 
(only) will directly boot the Windows bootloader. And also remove the Windows 
boot entry in GRUB, on UEFI systems. (It would be retained on BIOS systems.)

c. Change the release criterion.
 
https://fedoraproject.org/wiki/Fedora_36_Final_Release_Criteria#Windows_dual_boot

Current: 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.

Replacement: The installer must be able to install into free space alongside an 
existing clean Windows installation, install and configure a bootloader that 
will boot Fedora. 

d. Consider the problem sufficiently difficult to fix that we need an extension 
to the exceptional case allowance, and wave the bug for another release.

Thoughts?


--
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Some spins/labs to be dropped from F37

[Matthew Miller]

On Thu, Jul 21, 2022 at 10:25:25AM -, Artur Frenszek-Iwicki wrote:
> > * Games Spin — https://fedoraproject.org/wiki/Games_Spin
> Unless someone more experienced comes along, I'd be willing
> to take a shot at maintaining the games spin.


This is how someone becomes experienced. :)

-- 
Matthew Miller

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

Re: Upstream Release Monitoring - bug report

[Kevin Fenzi]

On Mon, Jul 25, 2022 at 01:54:38PM +0200, Michal Schorm wrote:
> Ah, It's a bit more tangled than I thought:
> 
> I've somehow got an impression that the upstream release monitoring is
> not related to Fedora, but I expected the BZ bot should be.
> So I've looked for a place to report issues other than
> https://github.com/fedora-infra/anitya/issues, as I thought it is the
> upstream (not Fedora related) part of the project. Only after
> following the link I've seen it is a GitHub repo in the "fedora-infra"
> namespace.
> 
> I've actually thought that the "monitoring status" option in the
> src.fedoraproject.org does something different (pings you when
> _anyone_ do a build or scratch-build of your package in KOJI - which
> would be useful for watching who touches your pkg and how)
> 
> The Pagure documentation doesn't seem to know about that field:
> https://docs.pagure.org/pagure/search.html?q=monitoring
> 
> So the 'Monitoring' value is likely what I am looking for, thanks ! :)


Just to clairfy some: 

anitya is release-monitoring.org. It's the thing that watches upstream
releases and keeps a mapping of upstream name to downstream distro
names. It does this for a bunch of distros, not just fedora. It emits
messages on the fedora-messaging bus when mappings are made/changed and
when updates are seen. It's configured only on it's web interface
(release-monitoring.org).

the-new-hotness is a seperate, but related application that listens for
messages about new upstream releases, checks to see if that package in
fedora wants to be notified/have scratch builds done for those. It
handles filing bugzilla bugs, and doing scratch builds (if desired).
It can be configured as you note on src.fedoraproject.org. 

If you want to watch activity on a package you want The little 'watch'
pulldown under The package description. You can set there if you want to
watch bugs, commits, both, etc. If you only wanted to watch koji builds,
you would need to set that in FMN ( apps.fedoraproject.org/notifications)

kevin
--
> 
> --
> 
> On Mon, Jul 25, 2022 at 1:46 PM Fabio Valentini  wrote:
> > This sounds like it's trying to process and create patches for *the
> > same version* again and again?
> > If that is the case, you might want to file a bug with anitya /
> > the-new-hotness, as that's certainly not its intended behaviour.
> 
> Right, will report.
> 
> --
> 
> Michal Schorm
> Software Engineer
> Core Services - Databases Team
> Red Hat
> 
> --
> 
> On Mon, Jul 25, 2022 at 1:46 PM Fabio Valentini  wrote:
> >
> > On Mon, Jul 25, 2022 at 1:39 PM Michal Schorm  wrote:
> > >
> > > Hello,
> > > I don't know where to go, so I'm trying here.
> > >
> > > Package 'mariadb-connector-c' [1] I maintain has upstream release
> > > monitoring enabled [2].
> > > The bot opened a BZ [3] for me to notify about a new upstream release
> > > - as expected.
> > >
> > > It tried to come up with a patch and try to scratch-build the package
> > > with the patch.
> > > However it failed.
> > > And now it tries again and again, failing every time. Littering the BZ
> > > ticket with more and more comments with zero value. Spamming people in
> > > CC every day or two.
> > >
> > > I want it to stop.
> > >
> > > Ideally, I would like the bot to stop trying making patches and doing
> > > scratch builds on all my packages at all. It's a wasted effort (and
> > > computing time; and KOJI resources).
> > >
> > > Is that possible?
> > > How?
> > >
> > > --
> > >
> > > I logged into the https://release-monitoring.org/ , but there doesn't
> > > seem to be any setting regarding that.
> >
> > release-monitoring.org only has a mapping from upstream projects to
> > Fedora package names, but Fedora-specific settings live on
> > src.fedoraproject.org.
> > So, if you go to
> > https://src.fedoraproject.org/rpms/mariadb-connector-c (you actually
> > linked that page yourself), and are logged in:
> >
> > In the left-hand pane, there's a combobox where you can select "No
> > monitoring", "Monitoring", and "Scratch builds".
> > It's currently set to "Scratch builds", but if you know that those
> > won't work, then change the setting to "Monitoring".
> > That will at least cut down the number of notifications.
> >
> > > And now it tries again and again, failing every time.
> >
> > This sounds like it's trying to process and create patches for *the
> > same version* again and again?
> > If that is the case, you might want to file a bug with anitya /
> > the-new-hotness, as that's certainly not its intended behaviour.
> >
> > Fabio
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > Fedora Code of Conduct: 
> > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives: 
> > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 37 mass rebuild started

[Michael J Gruber]

> On 26. 07. 22 17:15, Michael J Gruber wrote:
> 
> I don't think so:
> 
> https://src.fedoraproject.org/rpms/redhat-rpm-config/c/1926c37598951ae307...
> 
> https://koji.fedoraproject.org/koji/buildinfo?buildID=1968550
> 
> https://bodhi.fedoraproject.org/updates/FEDORA-2022-925c18db47

Indeed. It was introduced in 219 for F36 and rawhide and in 201 for F35. That 
is not how I do my versions and branches, but to each their own.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fedora 37 mass rebuild complete

[Omair Majid]

Kevin Fenzi  writes:

> Failures can be seen
> https://kojipkgs.fedoraproject.org/mass-rebuild/f37-failures.html

dotnet-build-reference-packages and dotnet3.1 have a cyclic build
dependency on each other. dotnet3.1 was intentionally retired. This
package should have been retired along with it. Done now:

https://src.fedoraproject.org/rpms/dotnet-build-reference-packages/c/f9874ae6c13e6db7e534d77d08502127df1594f2?branch=rawhide

Thanks,
Omair

--
PGP Key: B157A9F0 (http://pgp.mit.edu/)
Fingerprint = 9DB5 2F0B FD3E C239 E108  E7BD DF99 7AF8 B157 A9F0
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fedora 37 mass rebuild started

[Miro Hrončok]

On 26. 07. 22 17:15, Michael J Gruber wrote:

The %java_arches macro mentioned in the change proposal is available on F36 and 
up only


I don't think so:

https://src.fedoraproject.org/rpms/redhat-rpm-config/c/1926c37598951ae30749eb212b2412973a0300e5?branch=f35

https://koji.fedoraproject.org/koji/buildinfo?buildID=1968550

https://bodhi.fedoraproject.org/updates/FEDORA-2022-925c18db47

--
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: [HEADS UP] wxGTK 3.2.0 in Rawhide

[Steven A. Falco]

On 7/26/22 10:07 AM, Scott Talbert wrote:

On Tue, 26 Jul 2022, Steven A. Falco wrote:


At long last wxWidgets 3.2.0 has been released and I'm getting it into Rawhide. 
 This comes with an soname bump (but this should be the last one as 3.2.x 
should now be ABI stable).

NOTE: users of wxWidgets 3.0 (wxGTK3 package) are now strongly encouraged to 
move their packages to use wxWidgets 3.2.

I've rebuilt these existing users in a side tag (f37-build-side-7):
- CubicSDR
- audacity
- wxmacmolplot

I see that erlang also snuck in as a user recently.  :)  @Peter, can you please 
rebuild erlang in side tag f37-build-side-7?  It should rebuild fine 
without any changes (I tested in copr).


That is great news.  Will the corresponding python3-wxpython4 package also be 
part of this?  I'll need that in order to move KiCad to the new version.


Not immediately.  I need to see if I can push upstream wxPython into making a 
release.  If not, I'll look into packaging a snapshot release as 4.0.7 is 
getting quite old and harder to maintain.


Thanks for the info, and I'll stay tuned for a compatible wxPython component.

Steve

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

Re: Fedora 37 mass rebuild started

[Michael J Gruber]

> Next failure is portmidi due to "Drop_i686_JDKs"
> https://fedoraproject.org/wiki/Changes/Drop_i686_JDKs
> 
> I don't know how I missed that change proposal. I cannot even make sense of 
> the
> English in those template mails (never got any myself). This is going to be a 
> lot of fun
> ... java-17-openjdk-devel got installed but JNI is missing???

For the record:
portmidi is rebuilt in rawhide now, with portmidi-tools dropping the pmdefaults 
app if java is not available on that arch.

The %java_arches macro mentioned in the change proposal is available on F36 and 
up only, btw, so the suggestions in that proposal need to be treated with some 
caveat, or as they say: caveat packagor ;-)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: List of long term FTBFS packages to be retired in August

[Mamoru TASAKA]

Miro Hrončok wrote on 2022/07/26 22:40:

On 26. 07. 22 15:07, Mamoru TASAKA wrote:

Miro Hrončok wrote on 2022/07/26 21:28:

Dear maintainers.

Based on the current fail to build from source policy, the following packages
will be retired from Fedora 37 approximately one week before branching (August 
2022).

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

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

This report is based on dist tags.

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

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

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

  Package   (co)maintainers
=
rubygem-sprockets-rails  jaruga, pvalena, ruby-packagers-sig

Depending on: rubygem-sprockets-rails (22)
 rubygem-actionmailbox (maintained by: pvalena)
 rubygem-actionmailbox-7.0.2.3-2.fc37.src requires 
rubygem(sprockets-rails) = 3.2.2

 rubygem-activestorage (maintained by: ruby-packagers-sig, vondruch)
 rubygem-activestorage-7.0.2.3-1.fc37.src requires 
rubygem(sprockets-rails) = 3.2.2

 rubygem-railties (maintained by: mmorsi, pvalena, tdawson, vondruch)
 rubygem-railties-7.0.2.3-2.fc37.src requires rubygem(sprockets-rails) 
= 3.2.2

 rubygem-sassc-rails (maintained by: pvalena)
 rubygem-sassc-rails-2.1.2-4.fc36.noarch requires 
rubygem(sprockets-rails) = 3.2.2
 rubygem-sassc-rails-2.1.2-4.fc36.src requires rubygem(sprockets-rails) 
= 3.2.2
...



Can you show what changed for rubygem-sprockets-rails compared with
the previous report one week ago?

https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/BEYCREMETV6DDVFMLKOE5HR2XWEWBPFE/

The above report seems to be saying that no package depends on 
rubygem-sprockets-rails,
but this time many packages depend on rubygem-sprockets-rails.


Only 4 packages directly require rubygem(sprockets-rails):

rubygem-actionmailbox
     rubygem-actionmailbox-7.0.2.3-2.fc37.src

rubygem-activestorage
     rubygem-activestorage-7.0.2.3-1.fc37.src

rubygem-railties
     rubygem-railties-7.0.2.3-2.fc37.src

rubygem-sassc-rails
     rubygem-sassc-rails-2.1.2-4.fc36.noarch
     rubygem-sassc-rails-2.1.2-4.fc36.src


I've checked and from the spec files, it seems that they always did.

I've repoqueried this compose 
https://kojipkgs.fedoraproject.org/compose/rawhide/Fedora-Rawhide-20220719.n.0/ 
and it seems that the requirements were there.

The only difference, it seems, is that rubygem-image_processing was part of the 
FTBFS packages set before and its dep tree already included those packages, so 
the script decided not to report them twice :(

https://pagure.io/releng/blob/c9a08daa74/f/scripts/find_unblocked_orphans.py#_419

When I remove this thing, and re-add rubygem-image_processing to the list of 
FTBFS packages, I see rubygem-sprockets-rails's dependencies reported.

I guess we should fix the script, this is dangerous.

And if you think this justifies not retiring rubygem-sprockets-rails this 
round, I am OK with that.

Thanks for spotting this. No other remaining packages here seem to be affected 
by this now.



Okay, thank you for confirmation.

Anyway now I checked the upstream repo and the upstream already fixed build 
issue.
So I've backported the upstream fix and now build was successful as
rubygem-sprockets-rails-3.2.2-6.fc37 .

https://koji.fedoraproject.org/koji/buildinfo?buildID=2036386

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

Re: [HEADS UP] wxGTK 3.2.0 in Rawhide

[Scott Talbert]

On Tue, 26 Jul 2022, Steven A. Falco wrote:

At long last wxWidgets 3.2.0 has been released and I'm getting it into 
Rawhide.  This comes with an soname bump (but this should be the last one 
as 3.2.x should now be ABI stable).


NOTE: users of wxWidgets 3.0 (wxGTK3 package) are now strongly encouraged 
to move their packages to use wxWidgets 3.2.


I've rebuilt these existing users in a side tag (f37-build-side-7):
- CubicSDR
- audacity
- wxmacmolplot

I see that erlang also snuck in as a user recently.  :)  @Peter, can you 
please rebuild erlang in side tag f37-build-side-7?  It should rebuild 
fine without any changes (I tested in copr).


That is great news.  Will the corresponding python3-wxpython4 package also be 
part of this?  I'll need that in order to move KiCad to the new version.


Not immediately.  I need to see if I can push upstream wxPython into 
making a release.  If not, I'll look into packaging a snapshot release as 
4.0.7 is getting quite old and harder to maintain.


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

[Bug 2110816] perl-File-Share-0.26 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Resolution|--- |RAWHIDE
 Status|ASSIGNED|CLOSED
   Fixed In Version||perl-File-Share-0.26-1.fc37
Last Closed||2022-07-26 14:05:21




-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2110816
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: List of long term FTBFS packages to be retired in August

[Miro Hrončok]

On 26. 07. 22 15:40, Miro Hrončok wrote:

On 26. 07. 22 15:07, Mamoru TASAKA wrote:

Miro Hrončok wrote on 2022/07/26 21:28:

Dear maintainers.

Based on the current fail to build from source policy, the following packages
will be retired from Fedora 37 approximately one week before branching 
(August 2022).


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



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

This report is based on dist tags.

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



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


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

  Package   (co)maintainers
=
rubygem-sprockets-rails  jaruga, pvalena, ruby-packagers-sig

Depending on: rubygem-sprockets-rails (22)
 rubygem-actionmailbox (maintained by: pvalena)
 rubygem-actionmailbox-7.0.2.3-2.fc37.src requires 
rubygem(sprockets-rails) = 3.2.2


 rubygem-activestorage (maintained by: ruby-packagers-sig, vondruch)
 rubygem-activestorage-7.0.2.3-1.fc37.src requires 
rubygem(sprockets-rails) = 3.2.2


 rubygem-railties (maintained by: mmorsi, pvalena, tdawson, vondruch)
 rubygem-railties-7.0.2.3-2.fc37.src requires 
rubygem(sprockets-rails) = 3.2.2


 rubygem-sassc-rails (maintained by: pvalena)
 rubygem-sassc-rails-2.1.2-4.fc36.noarch requires 
rubygem(sprockets-rails) = 3.2.2
 rubygem-sassc-rails-2.1.2-4.fc36.src requires 
rubygem(sprockets-rails) = 3.2.2

...



Can you show what changed for rubygem-sprockets-rails compared with
the previous report one week ago?

https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/BEYCREMETV6DDVFMLKOE5HR2XWEWBPFE/ 



The above report seems to be saying that no package depends on 
rubygem-sprockets-rails,

but this time many packages depend on rubygem-sprockets-rails.


Only 4 packages directly require rubygem(sprockets-rails):

rubygem-actionmailbox
     rubygem-actionmailbox-7.0.2.3-2.fc37.src

rubygem-activestorage
     rubygem-activestorage-7.0.2.3-1.fc37.src

rubygem-railties
     rubygem-railties-7.0.2.3-2.fc37.src

rubygem-sassc-rails
     rubygem-sassc-rails-2.1.2-4.fc36.noarch
     rubygem-sassc-rails-2.1.2-4.fc36.src


I've checked and from the spec files, it seems that they always did.

I've repoqueried this compose 
https://kojipkgs.fedoraproject.org/compose/rawhide/Fedora-Rawhide-20220719.n.0/ 
and it seems that the requirements were there.


The only difference, it seems, is that rubygem-image_processing was part of the 
FTBFS packages set before and its dep tree already included those packages, so 
the script decided not to report them twice :(


https://pagure.io/releng/blob/c9a08daa74/f/scripts/find_unblocked_orphans.py#_419

When I remove this thing, and re-add rubygem-image_processing to the list of 
FTBFS packages, I see rubygem-sprockets-rails's dependencies reported.


I guess we should fix the script, this is dangerous.

And if you think this justifies not retiring rubygem-sprockets-rails this 
round, I am OK with that.


Thanks for spotting this. No other remaining packages here seem to be affected 
by this now.


https://pagure.io/releng/pull-request/10924

--
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: [HEADS UP] wxGTK 3.2.0 in Rawhide

[Steven A. Falco]

On 7/25/22 10:18 PM, Scott Talbert wrote:

At long last wxWidgets 3.2.0 has been released and I'm getting it into Rawhide. 
 This comes with an soname bump (but this should be the last one as 3.2.x 
should now be ABI stable).

NOTE: users of wxWidgets 3.0 (wxGTK3 package) are now strongly encouraged to 
move their packages to use wxWidgets 3.2.

I've rebuilt these existing users in a side tag (f37-build-side-7):
- CubicSDR
- audacity
- wxmacmolplot

I see that erlang also snuck in as a user recently.  :)  @Peter, can you please 
rebuild erlang in side tag f37-build-side-7?  It should rebuild fine 
without any changes (I tested in copr).


That is great news.  Will the corresponding python3-wxpython4 package also be 
part of this?  I'll need that in order to move KiCad to the new version.

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

Re: List of long term FTBFS packages to be retired in August

[Miro Hrončok]

On 26. 07. 22 15:07, Mamoru TASAKA wrote:

Miro Hrončok wrote on 2022/07/26 21:28:

Dear maintainers.

Based on the current fail to build from source policy, the following packages
will be retired from Fedora 37 approximately one week before branching 
(August 2022).


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



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

This report is based on dist tags.

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



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


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

  Package   (co)maintainers
=
rubygem-sprockets-rails  jaruga, pvalena, ruby-packagers-sig

Depending on: rubygem-sprockets-rails (22)
 rubygem-actionmailbox (maintained by: pvalena)
 rubygem-actionmailbox-7.0.2.3-2.fc37.src requires 
rubygem(sprockets-rails) = 3.2.2


 rubygem-activestorage (maintained by: ruby-packagers-sig, vondruch)
 rubygem-activestorage-7.0.2.3-1.fc37.src requires 
rubygem(sprockets-rails) = 3.2.2


 rubygem-railties (maintained by: mmorsi, pvalena, tdawson, vondruch)
 rubygem-railties-7.0.2.3-2.fc37.src requires 
rubygem(sprockets-rails) = 3.2.2


 rubygem-sassc-rails (maintained by: pvalena)
 rubygem-sassc-rails-2.1.2-4.fc36.noarch requires 
rubygem(sprockets-rails) = 3.2.2
 rubygem-sassc-rails-2.1.2-4.fc36.src requires 
rubygem(sprockets-rails) = 3.2.2

...



Can you show what changed for rubygem-sprockets-rails compared with
the previous report one week ago?

https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/BEYCREMETV6DDVFMLKOE5HR2XWEWBPFE/ 



The above report seems to be saying that no package depends on 
rubygem-sprockets-rails,

but this time many packages depend on rubygem-sprockets-rails.


Only 4 packages directly require rubygem(sprockets-rails):

rubygem-actionmailbox
rubygem-actionmailbox-7.0.2.3-2.fc37.src

rubygem-activestorage
rubygem-activestorage-7.0.2.3-1.fc37.src

rubygem-railties
rubygem-railties-7.0.2.3-2.fc37.src

rubygem-sassc-rails
rubygem-sassc-rails-2.1.2-4.fc36.noarch
rubygem-sassc-rails-2.1.2-4.fc36.src


I've checked and from the spec files, it seems that they always did.

I've repoqueried this compose 
https://kojipkgs.fedoraproject.org/compose/rawhide/Fedora-Rawhide-20220719.n.0/ 
and it seems that the requirements were there.


The only difference, it seems, is that rubygem-image_processing was part of the 
FTBFS packages set before and its dep tree already included those packages, so 
the script decided not to report them twice :(


https://pagure.io/releng/blob/c9a08daa74/f/scripts/find_unblocked_orphans.py#_419

When I remove this thing, and re-add rubygem-image_processing to the list of 
FTBFS packages, I see rubygem-sprockets-rails's dependencies reported.


I guess we should fix the script, this is dangerous.

And if you think this justifies not retiring rubygem-sprockets-rails this 
round, I am OK with that.


Thanks for spotting this. No other remaining packages here seem to be affected 
by this now.


--
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 2110816] perl-File-Share-0.26 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC|jples...@redhat.com,|
   |ppi...@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=2110816
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 2110575] perl-HTTP-Tiny-0.082 is available

[bugzilla]

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



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


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2110575
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

List of long term FTBFS packages to be retired in August

[Miro Hrončok]

Dear maintainers.

Based on the current fail to build from source policy, the following packages
will be retired from Fedora 37 approximately one week before branching (August 
2022).


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


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

This report is based on dist tags.

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

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


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

 Package   (co)maintainers
=
golang-grpc-go4  eclipseo, go-sig, jchaloup
lancer   willb
php-aws-sdk3 lcts
php-pimple   lcts
recorder ddd
rubygem-coffee-rails jaruga, ruby-packagers-sig, vondruch
rubygem-minitest-reporters   pvalena
rubygem-sprockets-rails  jaruga, pvalena, ruby-packagers-sig
tinygo   go-sig, qulogic
uom-parent   lberk, mgoodwin, nathans
xs   petersen


The following packages require above mentioned packages:
Depending on: golang-grpc-go4 (1)
golang-x-build (maintained by: eclipseo, go-sig, jchaloup)
		golang-x-build-0-0.19.20201229git0a4bf69.fc35.src requires 
golang(grpc.go4.org) = 0-0.9.20180421git11d0a25.fc34, 
golang(grpc.go4.org/codes) = 0-0.9.20180421git11d0a25.fc34
		golang-x-build-devel-0-0.19.20201229git0a4bf69.fc35.noarch requires 
golang(grpc.go4.org) = 0-0.9.20180421git11d0a25.fc34, 
golang(grpc.go4.org/codes) = 0-0.9.20180421git11d0a25.fc34


Depending on: rubygem-sprockets-rails (22)
rubygem-actionmailbox (maintained by: pvalena)
		rubygem-actionmailbox-7.0.2.3-2.fc37.src requires rubygem(sprockets-rails) = 
3.2.2


rubygem-activestorage (maintained by: ruby-packagers-sig, vondruch)
		rubygem-activestorage-7.0.2.3-1.fc37.src requires rubygem(sprockets-rails) = 
3.2.2


rubygem-railties (maintained by: mmorsi, pvalena, tdawson, vondruch)
rubygem-railties-7.0.2.3-2.fc37.src requires 
rubygem(sprockets-rails) = 3.2.2

rubygem-sassc-rails (maintained by: pvalena)
rubygem-sassc-rails-2.1.2-4.fc36.noarch requires 
rubygem(sprockets-rails) = 3.2.2
rubygem-sassc-rails-2.1.2-4.fc36.src requires 
rubygem(sprockets-rails) = 3.2.2

	rubygem-rails (maintained by: jstribny, kanarip, mmorsi, mtasaka, pvalena, 
ruby-packagers-sig, sseago, tdawson, vondruch)

rubygem-rails-1:7.0.2.3-2.fc37.noarch requires 
rubygem(actionmailbox) = 7.0.2.3

rubygem-rspec-rails (maintained by: clalance, vondruch)
rubygem-rspec-rails-5.1.1-2.fc37.src requires 
rubygem(actionmailbox) = 7.0.2.3

rubygem-actiontext (maintained by: pvalena)
		rubygem-actiontext-7.0.2.3-2.fc37.noarch requires rubygem(activestorage) = 
7.0.2.3

rubygem-actiontext-7.0.2.3-2.fc37.src requires 
rubygem(activestorage) = 7.0.2.3

	rubygem-actionpack (maintained by: jaruga, jstribny, kanarip, mmorsi, pvalena, 
ruby-packagers-sig, sseago, vondruch)

rubygem-actionpack-1:7.0.2.3-1.fc37.src requires 
rubygem(railties) = 7.0.2.3

rubygem-actionview (maintained by: jaruga, pvalena, ruby-packagers-sig)
rubygem-actionview-7.0.2.3-1.fc37.src requires 
rubygem(railties) = 7.0.2.3

rubygem-activemodel (maintained by: jstribny, mmorsi, pvalena, tdawson, 
vondruch)
rubygem-activemodel-7.0.2.3-2.fc37.src requires 
rubygem(railties) = 7.0.2.3

rubygem-ammeter (maintained by: jstribny, ruby-packagers-sig, vondruch)
rubygem-ammeter-1.1.5-3.fc37.noarch requires rubygem(railties) 
= 7.0.2.3
rubygem-ammeter-1.1.5-3.fc37.src requires rubygem(railties) = 
7.0.2.3

	rubygem-font-awesome-rails (maintained by: abradshaw, ckyriakidou, evgeni, 
fale, snecker)
		rubygem-font-awesome-rails-4.7.0.8-2.fc37.noarch requires rubygem(railties) = 
7.0.2.3
		rubygem-font-awesome-rails-4.7.0.8-2.fc37.src requires rubygem(railties) = 
7.0.2.3


rubygem-generator_spec (maintained by: ilgrad)
rubygem-generator_spec-0.9.4-12.fc37.noarch requires 
rubygem(railties) = 7.0.2.3
rubygem-generator_spec-0.9.4-12.fc37.src requires 
rubygem(railties) = 7.0.2.3

rubygem-globalid (maintained by: jaruga, pvalena, ruby-packagers-sig)
rubygem-globalid-1.0.0-3.fc37.src requires rubygem(railties) = 
7.0.2.3

rubygem-haml (maintained by: kanarip, pvalena)

Automated reports redirected into a new mailing list: test-reports

[Kamil Paral]

Hello testers and developers,

please note that we've set up a new mailing list called test-reports [1]
and we've redirected all automated compose/updates/test/etc reports into
it. These reports were previously sent to the test list and devel list and
created a lot of visual noise among regular conversations (especially in
the test list). You can see test-reports archives [1] to see which emails
I'm talking about. The only exception is the main rawhide compose report,
which still goes to the devel list (as well as test-reports), because it
was deemed useful enough to be kept there.

If you're interested in receiving these reports, please subscribe to the
new list. The default reply is set to go to the test list, where we can
have conversations about any suspicious changes/outcomes, but you can of
course start your discussion in the devel list, if you prefer.

Cheers,
Kamil
Fedora QA

[1]
https://lists.fedoraproject.org/archives/list/test-repo...@lists.fedoraproject.org/
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: [HEADS UP] wxGTK 3.2.0 in Rawhide

[Peter Lemenkov]

Hey!
Sure I'll rebuild it soon

вт, 26 июл. 2022 г. в 04:18, Scott Talbert :
>
> At long last wxWidgets 3.2.0 has been released and I'm getting it into
> Rawhide.  This comes with an soname bump (but this should be the last one
> as 3.2.x should now be ABI stable).
>
> NOTE: users of wxWidgets 3.0 (wxGTK3 package) are now strongly encouraged
> to move their packages to use wxWidgets 3.2.
>
> I've rebuilt these existing users in a side tag (f37-build-side-7):
> - CubicSDR
> - audacity
> - wxmacmolplot
>
> I see that erlang also snuck in as a user recently.  :)  @Peter, can you
> please rebuild erlang in side tag f37-build-side-7?  It should rebuild
> fine without any changes (I tested in copr).
>
> Thanks,
> Scott



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

Re: List of long term FTBFS packages to be retired in August

[Mamoru TASAKA]

Miro Hrončok wrote on 2022/07/26 21:28:

Dear maintainers.

Based on the current fail to build from source policy, the following packages
will be retired from Fedora 37 approximately one week before branching (August 
2022).

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

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

This report is based on dist tags.

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

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

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

  Package   (co)maintainers
=
rubygem-sprockets-rails  jaruga, pvalena, ruby-packagers-sig

Depending on: rubygem-sprockets-rails (22)
 rubygem-actionmailbox (maintained by: pvalena)
     rubygem-actionmailbox-7.0.2.3-2.fc37.src requires 
rubygem(sprockets-rails) = 3.2.2

 rubygem-activestorage (maintained by: ruby-packagers-sig, vondruch)
     rubygem-activestorage-7.0.2.3-1.fc37.src requires 
rubygem(sprockets-rails) = 3.2.2

 rubygem-railties (maintained by: mmorsi, pvalena, tdawson, vondruch)
     rubygem-railties-7.0.2.3-2.fc37.src requires rubygem(sprockets-rails) 
= 3.2.2

 rubygem-sassc-rails (maintained by: pvalena)
     rubygem-sassc-rails-2.1.2-4.fc36.noarch requires 
rubygem(sprockets-rails) = 3.2.2
     rubygem-sassc-rails-2.1.2-4.fc36.src requires rubygem(sprockets-rails) 
= 3.2.2

 rubygem-rails (maintained by: jstribny, kanarip, mmorsi, mtasaka, pvalena, 
ruby-packagers-sig, sseago, tdawson, vondruch)
     rubygem-rails-1:7.0.2.3-2.fc37.noarch requires rubygem(actionmailbox) 
= 7.0.2.3

 rubygem-rspec-rails (maintained by: clalance, vondruch)
     rubygem-rspec-rails-5.1.1-2.fc37.src requires rubygem(actionmailbox) = 
7.0.2.3

 rubygem-actiontext (maintained by: pvalena)
     rubygem-actiontext-7.0.2.3-2.fc37.noarch requires 
rubygem(activestorage) = 7.0.2.3
     rubygem-actiontext-7.0.2.3-2.fc37.src requires rubygem(activestorage) 
= 7.0.2.3

 rubygem-actionpack (maintained by: jaruga, jstribny, kanarip, mmorsi, 
pvalena, ruby-packagers-sig, sseago, vondruch)
     rubygem-actionpack-1:7.0.2.3-1.fc37.src requires rubygem(railties) = 
7.0.2.3

 rubygem-actionview (maintained by: jaruga, pvalena, ruby-packagers-sig)
     rubygem-actionview-7.0.2.3-1.fc37.src requires rubygem(railties) = 
7.0.2.3

 rubygem-activemodel (maintained by: jstribny, mmorsi, pvalena, tdawson, 
vondruch)
     rubygem-activemodel-7.0.2.3-2.fc37.src requires rubygem(railties) = 
7.0.2.3

 rubygem-ammeter (maintained by: jstribny, ruby-packagers-sig, vondruch)
     rubygem-ammeter-1.1.5-3.fc37.noarch requires rubygem(railties) = 
7.0.2.3
     rubygem-ammeter-1.1.5-3.fc37.src requires rubygem(railties) = 7.0.2.3

 rubygem-font-awesome-rails (maintained by: abradshaw, ckyriakidou, evgeni, 
fale, snecker)
     rubygem-font-awesome-rails-4.7.0.8-2.fc37.noarch requires 
rubygem(railties) = 7.0.2.3
     rubygem-font-awesome-rails-4.7.0.8-2.fc37.src requires 
rubygem(railties) = 7.0.2.3

 rubygem-generator_spec (maintained by: ilgrad)
     rubygem-generator_spec-0.9.4-12.fc37.noarch requires rubygem(railties) 
= 7.0.2.3
     rubygem-generator_spec-0.9.4-12.fc37.src requires rubygem(railties) = 
7.0.2.3

 rubygem-globalid (maintained by: jaruga, pvalena, ruby-packagers-sig)
     rubygem-globalid-1.0.0-3.fc37.src requires rubygem(railties) = 7.0.2.3

 rubygem-haml (maintained by: kanarip, pvalena)
     rubygem-haml-5.2.2-3.fc37.src requires rubygem(railties) = 7.0.2.3

 rubygem-importmap-rails (maintained by: pvalena)
     rubygem-importmap-rails-1.0.3-2.fc37.noarch requires rubygem(railties) 
= 7.0.2.3

 rubygem-jbuilder (maintained by: pvalena, vondruch)
     rubygem-jbuilder-2.11.5-2.fc37.src requires rubygem(railties) = 7.0.2.3

 rubygem-jquery-rails (maintained by: jstribny, tdawson, vondruch)
     rubygem-jquery-rails-4.4.0-3.fc37.noarch requires rubygem(railties) = 
7.0.2.3

 rubygem-rails-controller-testing (maintained by: valtri)
     rubygem-rails-controller-testing-1.0.5-6.fc37.src requires 
rubygem(railties) = 7.0.2.3

 rubygem-sass-twitter-bootstrap (maintained by: tdawson)
     rubygem-sass-twitter-bootstrap-2.3.0-16.fc37.noarch requires 
rubygem(railties) = 7.0.2.3

 rubygem-slim (maintained by: vondruch)
     rubygem-slim-4.1.0-6.fc37.src requires rubygem(railties) = 7.0.2.3

 rubygem-web-console (maintained by: jaruga, ruby-packagers-sig, vondruch)
     rubygem-web-console-4.1.0-4.fc36.noarch requires 

Re: Is `/etc/sysconfig/desktop` still used?

[Franta Hanzlík via devel]

On Tue, 26 Jul 2022 10:09:39 +0100
Ankur Sinha  wrote:

> Hi folks,
> 
> While updating this quick-doc, I came across the last section where
> `/etc/sysconfig/desktop` is mentioned as a config file to change default
> desktop environment etc.
> 
> https://docs.fedoraproject.org/en-US/quick-docs/switching-desktop-environments/
> 
> I haven't been able to find any documentation on it, and no package in
> Fedora owns this file either. Would someone please be able to note if
> this file is still in use, and point to some documentation we could
> refer to?
> 
> I've also got a PR updating the page here. Reviews most most welcome:
> https://pagure.io/fedora-docs/quick-docs/pull-request/474
> 
> -- 

From my older configurations, it seems as '/etc/sysconfig/desktop':

1) was sourced in '/etc/X11/prefdm' for envvar 'DISPLAYMANAGER'; this
variable should contain one from recognized DM nickname (GNOME, KDE,
WDM or XDM) or path to displaymanager binary.
'/etc/X11/prefdm' was file in package 'initscripts' and was started as
sysV init/upstart/systemd service. The prefdm file was last seen in F17
and EL7 distros, then it is no longer in use - thus nor 'DISPLAYMANAGER'
envvar.

2) is still sourced from '/etc/X11/xinit/Xclients' for two envvars:
- 'DESKTOP' - nickname for one from recognized sessions (GNOME, KDE, MATE
or LXDE).
- 'PREFERRED' - in case when 'DESKTOP' unset/unrecognized, this variable
should be path for program starting graphical session (for example,
'/usr/bin/mate-session').
'/etc/X11/xinit/Xclients' file is in package 'xorg-x11-xinit' and is
needed e.g. for manual X session start via startx or xinit.
This file/package is actual, present in Fedora 36 (not sure about
Centos/RHEL, I'm not using its now).

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

[Bug 2110575] perl-HTTP-Tiny-0.082 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

   Fixed In Version||perl-HTTP-Tiny-0.082-1.fc37
 Status|ASSIGNED|MODIFIED




-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2110575
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

List of long term FTBFS packages to be retired in August

[Miro Hrončok]

Dear maintainers.

Based on the current fail to build from source policy, the following packages
will be retired from Fedora 37 approximately one week before branching (August 
2022).


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


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

This report is based on dist tags.

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

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


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

 Package   (co)maintainers
=
golang-grpc-go4  eclipseo, go-sig, jchaloup
lancer   willb
php-aws-sdk3 lcts
php-pimple   lcts
recorder ddd
rubygem-coffee-rails jaruga, ruby-packagers-sig, vondruch
rubygem-minitest-reporters   pvalena
rubygem-sprockets-rails  jaruga, pvalena, ruby-packagers-sig
tinygo   go-sig, qulogic
uom-parent   lberk, mgoodwin, nathans
xs   petersen


The following packages require above mentioned packages:
Depending on: golang-grpc-go4 (1)
golang-x-build (maintained by: eclipseo, go-sig, jchaloup)
		golang-x-build-0-0.19.20201229git0a4bf69.fc35.src requires 
golang(grpc.go4.org) = 0-0.9.20180421git11d0a25.fc34, 
golang(grpc.go4.org/codes) = 0-0.9.20180421git11d0a25.fc34
		golang-x-build-devel-0-0.19.20201229git0a4bf69.fc35.noarch requires 
golang(grpc.go4.org) = 0-0.9.20180421git11d0a25.fc34, 
golang(grpc.go4.org/codes) = 0-0.9.20180421git11d0a25.fc34


Depending on: rubygem-sprockets-rails (22)
rubygem-actionmailbox (maintained by: pvalena)
		rubygem-actionmailbox-7.0.2.3-2.fc37.src requires rubygem(sprockets-rails) = 
3.2.2


rubygem-activestorage (maintained by: ruby-packagers-sig, vondruch)
		rubygem-activestorage-7.0.2.3-1.fc37.src requires rubygem(sprockets-rails) = 
3.2.2


rubygem-railties (maintained by: mmorsi, pvalena, tdawson, vondruch)
rubygem-railties-7.0.2.3-2.fc37.src requires 
rubygem(sprockets-rails) = 3.2.2

rubygem-sassc-rails (maintained by: pvalena)
rubygem-sassc-rails-2.1.2-4.fc36.noarch requires 
rubygem(sprockets-rails) = 3.2.2
rubygem-sassc-rails-2.1.2-4.fc36.src requires 
rubygem(sprockets-rails) = 3.2.2

	rubygem-rails (maintained by: jstribny, kanarip, mmorsi, mtasaka, pvalena, 
ruby-packagers-sig, sseago, tdawson, vondruch)

rubygem-rails-1:7.0.2.3-2.fc37.noarch requires 
rubygem(actionmailbox) = 7.0.2.3

rubygem-rspec-rails (maintained by: clalance, vondruch)
rubygem-rspec-rails-5.1.1-2.fc37.src requires 
rubygem(actionmailbox) = 7.0.2.3

rubygem-actiontext (maintained by: pvalena)
		rubygem-actiontext-7.0.2.3-2.fc37.noarch requires rubygem(activestorage) = 
7.0.2.3

rubygem-actiontext-7.0.2.3-2.fc37.src requires 
rubygem(activestorage) = 7.0.2.3

	rubygem-actionpack (maintained by: jaruga, jstribny, kanarip, mmorsi, pvalena, 
ruby-packagers-sig, sseago, vondruch)

rubygem-actionpack-1:7.0.2.3-1.fc37.src requires 
rubygem(railties) = 7.0.2.3

rubygem-actionview (maintained by: jaruga, pvalena, ruby-packagers-sig)
rubygem-actionview-7.0.2.3-1.fc37.src requires 
rubygem(railties) = 7.0.2.3

rubygem-activemodel (maintained by: jstribny, mmorsi, pvalena, tdawson, 
vondruch)
rubygem-activemodel-7.0.2.3-2.fc37.src requires 
rubygem(railties) = 7.0.2.3

rubygem-ammeter (maintained by: jstribny, ruby-packagers-sig, vondruch)
rubygem-ammeter-1.1.5-3.fc37.noarch requires rubygem(railties) 
= 7.0.2.3
rubygem-ammeter-1.1.5-3.fc37.src requires rubygem(railties) = 
7.0.2.3

	rubygem-font-awesome-rails (maintained by: abradshaw, ckyriakidou, evgeni, 
fale, snecker)
		rubygem-font-awesome-rails-4.7.0.8-2.fc37.noarch requires rubygem(railties) = 
7.0.2.3
		rubygem-font-awesome-rails-4.7.0.8-2.fc37.src requires rubygem(railties) = 
7.0.2.3


rubygem-generator_spec (maintained by: ilgrad)
rubygem-generator_spec-0.9.4-12.fc37.noarch requires 
rubygem(railties) = 7.0.2.3
rubygem-generator_spec-0.9.4-12.fc37.src requires 
rubygem(railties) = 7.0.2.3

rubygem-globalid (maintained by: jaruga, pvalena, ruby-packagers-sig)
rubygem-globalid-1.0.0-3.fc37.src requires rubygem(railties) = 
7.0.2.3

rubygem-haml (maintained by: kanarip, pvalena)

Re: KOJI Rawhide error: "Empty %files file ...../debugsourcefiles.list"

[Kalev Lember]

Looks like it's caused by /usr/bin/file crashing:
https://bugzilla.redhat.com/show_bug.cgi?id=2110622

-- 
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Why is there antlr4-project package?

[Marián Konček]

There is no right or wrong, I just saw this as unusual.

I see this is a complex package and you went through some decision 
process when deciding on this.


I would still do something about the manually expanded %mvn_install macro.

Is it a big problem to have the java artifacts placed into a 
"anrlt4-project" directory?


If nothing else, maybe you could rpm --eval %%mvn_install | sed '-n 
%{name}' or something like that in the %prep section?


On 26. 7. 2022 11:33, Fabio Valentini wrote:

On Tue, Jul 26, 2022 at 11:08 AM Marián Konček  wrote:

I used a wrong mailing list, I meant to send it here.

I still see this approach as wrong. You can change the archfulness of
the main package. You can add a -java subpackage which is noarch and
provides the main package name for example. In the .spec I see you
manually invoke expanded %mvn_install macro.
"antlr4-project" is what "antlr4" should be in my opinion.

If you want to blame somebody for this, then blame me.
It was my suggestion to do it this way during package review:
https://bugzilla.redhat.com/show_bug.cgi?id=1795470#c2

However, I still think it was the right decision to do it this way.

And I don't think your alternative approach would work, because this
statement from your suggested alternative approach is wrong:


You can change the archfulness of the main package.

The main / source package needs to be "archful", because noarch source
packages cannot have non-noarch subpackages.
I just checked, and subpackages inherit the "BuildArch" tag from the
source package.
So you can override subpackages to make them noarch (archful package
with noarch subpackages), but *not* the other way round.

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


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

Re: KOJI Rawhide error: "Empty %files file ...../debugsourcefiles.list"

[Jarek Prokop]

Hi,

We have noticed the same issue when we wanted to do a scratch build of 
Ruby https://koji.fedoraproject.org/koji/taskinfo?taskID=90003939 .
If someone manages to reproduce it, my colleague created this patch for 
the script that could be worth trying out: 
https://gist.github.com/pvalena/8fe7899ca8ee6cd52c0db17d322503a4



To the failure itself,
The file is empty, simply because something inside the debuginfo RPM 
scripts segfaulted. From the logs of your build:

```
+ /usr/bin/find-debuginfo -j6 --strict-build-id -m -i --build-id-seed 
8.0.30-1.fc37 --unique-debug-suffix -8.0.30-1.fc37.x86_64 
--unique-debug-src-base community-mysql-8.0.30-1.fc37.x86_64 --run-dwz 
--dwz-low-mem-die-limit 1000 --dwz-max-die-limit 11000 -S 
debugsourcefiles.list /builddir/build/BUILD/mysql-8.0.30
/usr/bin/find-debuginfo: line 431: 653188 Done find "$RPM_BUILD_ROOT" ! 
-path "${debugdir}/*.debug" -type f \( -perm -0100 -or -perm -0010 -or 
-perm -0001 \) -print

 653189   | LC_ALL=C sort
 653190 Segmentation fault  (core dumped) | file -N -f -
 653191   | sed -n -e 's/^\(.*\):[ ]*.*ELF.*, 
not stripped.*/\1/p'
 653192   | xargs --no-run-if-empty stat -c '%h 
%D_%i %n'

 653193   | while read nlinks inum f; do
    if [ $nlinks -gt 1 ]; then
    var=seen_$inum; if test -n "${!var}"; then
    echo "$inum $f" >> "$temp/linked"; continue;
    else
    read "$var" < <(echo 1);
    fi;
    fi; echo "$nlinks $inum $f" >> "$temp/primary";
done
find: 'debug': No such file or directory
```
This is also the case of Ruby, it started happening after the mass rebuild.

Regards,
--
Jarek Prokop
Associate Software Engineer
Core Services - Apps
Red Hat

On 7/26/22 11:48, Michal Schorm wrote:

Hi,
I've just started (scratch-)building MySQL 8.0.30. (package 'community-mysql').
And the build on Rawhide failed with an error message, I haven't seen before:

"
Processing files: community-mysql-debugsource-8.0.30-1.fc37.x86_64
error: Empty %files file
/builddir/build/BUILD/mysql-8.0.30/debugsourcefiles.list
RPM build errors:
 Empty %files file /builddir/build/BUILD/mysql-8.0.30/debugsourcefiles.list
Child return code was: 1
"

Here is the build:
https://koji.fedoraproject.org/koji/taskinfo?taskID=90072976

The issue appeared on every architecture.

A build from the same sources for F35 (scratch-)builds fine:
https://koji.fedoraproject.org/koji/taskinfo?taskID=90073173

--

Does this error ring a bell to anyone?
Since the RPM debug-stuff is automatically generated and the package
builds fine for F35, I assume it's a KOJI issue rather than the
package issue.
I'll submit scratch builds for F36 & F37 in a moment.

--

Michal Schorm
Software Engineer
Core Services - Databases Team
Red Hat

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

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

Re: KOJI Rawhide error: "Empty %files file ...../debugsourcefiles.list"

[Kalev Lember]

On Tue, Jul 26, 2022 at 11:49 AM Michal Schorm  wrote:

> Hi,
> I've just started (scratch-)building MySQL 8.0.30. (package
> 'community-mysql').
> And the build on Rawhide failed with an error message, I haven't seen
> before:
>
> "
> Processing files: community-mysql-debugsource-8.0.30-1.fc37.x86_64
> error: Empty %files file
> /builddir/build/BUILD/mysql-8.0.30/debugsourcefiles.list
> RPM build errors:
> Empty %files file
> /builddir/build/BUILD/mysql-8.0.30/debugsourcefiles.list
> Child return code was: 1
> "
>
> Here is the build:
> https://koji.fedoraproject.org/koji/taskinfo?taskID=90072976
>
> The issue appeared on every architecture.
>
> A build from the same sources for F35 (scratch-)builds fine:
> https://koji.fedoraproject.org/koji/taskinfo?taskID=90073173
>
> --
>
> Does this error ring a bell to anyone?
> Since the RPM debug-stuff is automatically generated and the package
> builds fine for F35, I assume it's a KOJI issue rather than the
> package issue.
> I'll submit scratch builds for F36 & F37 in a moment.
>

I just ran into the same issue with glib2:
https://koji.fedoraproject.org/koji/buildinfo?buildID=2036224

Looks like something abort()s during find-debuginfo. I could find the
following in the build logs:

+ /usr/bin/find-debuginfo -j6 --strict-build-id -m -i --build-id-seed
2.73.2-5.fc37 --unique-debug-suffix -2.73.2-5.fc37.x86_64
--unique-debug-src-base glib2-2.73.2-5.fc37.x86_64 --run-dwz
--dwz-low-mem-die-limit 1000 --dwz-max-die-limit 11000 -S
debugsourcefiles.list /builddir/build/BUILD/glib-2.73.2
realloc(): invalid next size
/usr/bin/find-debuginfo: line 431: 2126552 Donefind
"$RPM_BUILD_ROOT" ! -path "${debugdir}/*.debug" -type f \( -perm -0100 -or
-perm -0010 -or -perm -0001 \) -print
 2126553   | LC_ALL=C sort
 2126554 Aborted (core dumped) | file -N -f -
 2126555   | sed -n -e 's/^\(.*\):[ ]*.*ELF.*, not
stripped.*/\1/p'
 2126556   | xargs --no-run-if-empty stat -c '%h
%D_%i %n'
 2126557   | while read nlinks inum f; do
if [ $nlinks -gt 1 ]; then
var=seen_$inum; if test -n "${!var}"; then
echo "$inum $f" >> "$temp/linked"; continue;
else
read "$var" < <(echo 1);
fi;
fi; echo "$nlinks $inum $f" >> "$temp/primary";
done

I tried downgrading glibc in a side tag but that didn't appear to change
anything. Let's see if we can narrow it down to one package (the mass
rebuild just landed in rawhide build roots so it's a lot of changes at the
same time). 

-- 
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Need to rename package? libphidget -> libphidget22

[Kevin Kofler via devel]

Richard Shaw wrote:
> I am trying to update the libphidget package which has not been updated in
> Fedora since 2014.
> 
> Apparently in 2017 the name was changed to "libphidget22" I'm guessing the
> soversion being embedded in the library name, seems awfully Debian
> centric.
> 
> The bigger problem is the version was reset from something 2.x

2.1.8.20140319 is what is now in Rawhide.

> back to 1.0.0, the current version being 1.10.

How about Name: libphidget, Version: 2.2.1.10?

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

KOJI Rawhide error: "Empty %files file ...../debugsourcefiles.list"

[Michal Schorm]

Hi,
I've just started (scratch-)building MySQL 8.0.30. (package 'community-mysql').
And the build on Rawhide failed with an error message, I haven't seen before:

"
Processing files: community-mysql-debugsource-8.0.30-1.fc37.x86_64
error: Empty %files file
/builddir/build/BUILD/mysql-8.0.30/debugsourcefiles.list
RPM build errors:
Empty %files file /builddir/build/BUILD/mysql-8.0.30/debugsourcefiles.list
Child return code was: 1
"

Here is the build:
https://koji.fedoraproject.org/koji/taskinfo?taskID=90072976

The issue appeared on every architecture.

A build from the same sources for F35 (scratch-)builds fine:
https://koji.fedoraproject.org/koji/taskinfo?taskID=90073173

--

Does this error ring a bell to anyone?
Since the RPM debug-stuff is automatically generated and the package
builds fine for F35, I assume it's a KOJI issue rather than the
package issue.
I'll submit scratch builds for F36 & F37 in a moment.

--

Michal Schorm
Software Engineer
Core Services - Databases Team
Red Hat

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

Re: Why is there antlr4-project package?

[Fabio Valentini]

On Tue, Jul 26, 2022 at 11:08 AM Marián Konček  wrote:
>
> I used a wrong mailing list, I meant to send it here.
>
> I still see this approach as wrong. You can change the archfulness of
> the main package. You can add a -java subpackage which is noarch and
> provides the main package name for example. In the .spec I see you
> manually invoke expanded %mvn_install macro.
> "antlr4-project" is what "antlr4" should be in my opinion.

If you want to blame somebody for this, then blame me.
It was my suggestion to do it this way during package review:
https://bugzilla.redhat.com/show_bug.cgi?id=1795470#c2

However, I still think it was the right decision to do it this way.

And I don't think your alternative approach would work, because this
statement from your suggested alternative approach is wrong:

> You can change the archfulness of the main package.

The main / source package needs to be "archful", because noarch source
packages cannot have non-noarch subpackages.
I just checked, and subpackages inherit the "BuildArch" tag from the
source package.
So you can override subpackages to make them noarch (archful package
with noarch subpackages), but *not* the other way round.

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

Re: Retiring the pcre package from Fedora

[Paolo Bonzini]

Due to static linking, not all functions will be included in the executable
and therefore some simple "hello world"  binaries will not need
sysprof-capture-static. However, anything that used the .pc file will need
it.

Technically, you could also use glib's static library without dependent .a
libraries if you link with glib's .a file but do not specify -static; but
that's not a good argument against having a Requires for the dependency in
my opinion, because it makes the .pc file not work out of the box. Perhaps
a weak dependency, but even that sounds strange.

As to glibc-static I think it's fair to say that whoever uses -static will
have to install it on their own, so it can be left out of glib2.spec.

Paolo


Il mar 26 lug 2022, 10:59 Daniel P. Berrangé  ha
scritto:

> Although listed in glib-2.0.pc, I didn't find any need for the
> sysprof-capture-static package, but it does need glibc-static
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Is `/etc/sysconfig/desktop` still used?

[Ankur Sinha]

Hi folks,

While updating this quick-doc, I came across the last section where
`/etc/sysconfig/desktop` is mentioned as a config file to change default
desktop environment etc.

https://docs.fedoraproject.org/en-US/quick-docs/switching-desktop-environments/

I haven't been able to find any documentation on it, and no package in
Fedora owns this file either. Would someone please be able to note if
this file is still in use, and point to some documentation we could
refer to?

I've also got a PR updating the page here. Reviews most most welcome:
https://pagure.io/fedora-docs/quick-docs/pull-request/474

-- 
Thanks,
Regards,
Ankur Sinha "FranciscoD" (He / Him / His) | 
https://fedoraproject.org/wiki/User:Ankursinha
Time zone: Europe/London


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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Retiring the pcre package from Fedora

[Kalev Lember]

On Tue, Jul 26, 2022 at 10:59 AM Daniel P. Berrangé 
wrote:

> On Tue, Jul 26, 2022 at 10:10:15AM +0200, Kalev Lember wrote:
> >
> > On 7/26/22 07:47, Paolo Bonzini wrote:
> > > On 7/24/22 15:42, Kalev Lember wrote:
> > > > On Sun, Jul 24, 2022 at 8:58 AM Paolo Bonzini  > > > > wrote:
> > > >
> > > >
> > > >
> > > > Il sab 23 lug 2022, 19:12 Adam Williamson
> > > > mailto:adamw...@fedoraproject.org>>
> ha
> > > > scritto:
> > > >
> > > > This of course begs a question: did qemu also have a
> > > > non-static pcre
> > > > requirement at the time? But it seems not:
> > > >
> > > > [adamw@xps13k qemu (f36 %)]$ git show 0835325:qemu.spec |
> > > > grep pcre
> > > > BuildRequires: glibc-static pcre-static glib2-static
> zlib-static
> > > >
> > > > so, I'm not sure why Daniel concluded this needs a
> > > > BuildRequires on
> > > > pcre-static, but the obvious thing to do would be to ask
> him, I
> > > > guess.
> > > >
> > > >
> > > > I think it could have been a missing requires of glib2-static,
> > > > because glib does use PCRE and therefore has it in the linker
> flags
> > > > for a static build. I will check next time I am at a computer.
> > > >
> > > >
> > > > glib2 switched to pcre2 in rawhide recently. Can you check if qemu
> > > > needs to be updated for that now so that it BuildRequires
> > > > pcre2-static instead?
> > >
> > > Yep, that works.  I still think that pcre2-static and
> > > sysprof-capture-devel belong in glib2's spec file though, but I
> > > committed that as a stopgap measure.
> >
> > Ah, yes, of course! I went ahead and added them in
> https://src.fedoraproject.org/rpms/glib2/c/5653dff1816e4bee3c3fdbcc00f2fea73a282093?branch=rawhide
> >
> > Does this look right to you? Do you want me to add them in other
> > branches as well or is rawhide sufficient for now?
>
> Although listed in glib-2.0.pc, I didn't find any need for the
> sysprof-capture-static package, but it does need glibc-static
>

Do you want to do a PR to fix it up?

-- 
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Why is there antlr4-project package?

[Marián Konček]

I used a wrong mailing list, I meant to send it here.

I still see this approach as wrong. You can change the archfulness of 
the main package. You can add a -java subpackage which is noarch and 
provides the main package name for example. In the .spec I see you 
manually invoke expanded %mvn_install macro.

"antlr4-project" is what "antlr4" should be in my opinion.

On 25. 7. 2022 16:28, Jerry James wrote:

On Mon, Jul 25, 2022 at 1:07 AM Marián Konček  wrote:

I noticed that the package "antlr4" was retired and another package
"anrlt4-project" was created some time after that.
Why was a new package added instead of antlr4 being unretired?

The problem is that the antlr4 package is noarch, and it is not
possible to have an archful subpackage of a noarch main package.  The
noarch antlr4 package was retired so that the archful antlr4-project
repo could be created with the various language runtimes.


Can we unretire antlr4?

No.  Why do you want to?  There is an antlr4 package, one of the
subpackages of antlr4-project.


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

Re: Retiring the pcre package from Fedora

[Daniel P . Berrangé]

On Tue, Jul 26, 2022 at 10:10:15AM +0200, Kalev Lember wrote:
> 
> On 7/26/22 07:47, Paolo Bonzini wrote:
> > On 7/24/22 15:42, Kalev Lember wrote:
> > > On Sun, Jul 24, 2022 at 8:58 AM Paolo Bonzini  > > > wrote:
> > > 
> > > 
> > > 
> > >     Il sab 23 lug 2022, 19:12 Adam Williamson
> > >     mailto:adamw...@fedoraproject.org>> ha
> > >     scritto:
> > > 
> > >     This of course begs a question: did qemu also have a
> > > non-static pcre
> > >     requirement at the time? But it seems not:
> > > 
> > >     [adamw@xps13k qemu (f36 %)]$ git show 0835325:qemu.spec |
> > > grep pcre
> > >     BuildRequires: glibc-static pcre-static glib2-static zlib-static
> > > 
> > >     so, I'm not sure why Daniel concluded this needs a
> > > BuildRequires on
> > >     pcre-static, but the obvious thing to do would be to ask him, I
> > >     guess.
> > > 
> > > 
> > >     I think it could have been a missing requires of glib2-static,
> > >     because glib does use PCRE and therefore has it in the linker flags
> > >     for a static build. I will check next time I am at a computer.
> > > 
> > > 
> > > glib2 switched to pcre2 in rawhide recently. Can you check if qemu
> > > needs to be updated for that now so that it BuildRequires
> > > pcre2-static instead?
> > 
> > Yep, that works.  I still think that pcre2-static and
> > sysprof-capture-devel belong in glib2's spec file though, but I
> > committed that as a stopgap measure.
> 
> Ah, yes, of course! I went ahead and added them in 
> https://src.fedoraproject.org/rpms/glib2/c/5653dff1816e4bee3c3fdbcc00f2fea73a282093?branch=rawhide
> 
> Does this look right to you? Do you want me to add them in other
> branches as well or is rawhide sufficient for now?

Although listed in glib-2.0.pc, I didn't find any need for the
sysprof-capture-static package, but it does need glibc-static


$ podman run -it fedora:rawhide

# cat > demo.c <

int main() {
  GString *s = g_string_new(NULL);
}
EOF

# gcc -o demo demo.c `pkg-config --cflags --libs --static glib-2.0` -static
/usr/bin/ld: cannot find -lm: No such file or directory
/usr/bin/ld: cannot find -lpcre2-8: No such file or directory
/usr/bin/ld: cannot find -lc: No such file or directory
collect2: error: ld returned 1 exit status

# dnf install pcre2-static

...snip...

Installed:
  pcre2-static-10.40-1.fc37.x86_64  

Complete!
# gcc -o demo demo.c `pkg-config --cflags --libs --static glib-2.0` -static
/usr/bin/ld: cannot find -lm: No such file or directory
/usr/bin/ld: cannot find -lc: No such file or directory
collect2: error: ld returned 1 exit status



With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Retiring the pcre package from Fedora

[Richard W.M. Jones]

On Sat, Jul 23, 2022 at 11:09:29AM +0100, Richard W.M. Jones wrote:
> > virt-p2v-1:1.42.1-1.fc37.src
> 
> This is a real one.  virt-p2v uses a small library called "miniexpect"
> which is based on pcre but needs to be ported to pcre2.

Fixed upstream now, I'll put it into Fedora after the next upstream
release.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Retiring the pcre package from Fedora

[Daniel P . Berrangé]

On Sun, Jul 24, 2022 at 08:58:18AM +0200, Paolo Bonzini wrote:
> Il sab 23 lug 2022, 19:12 Adam Williamson  ha
> scritto:
> 
> > This of course begs a question: did qemu also have a non-static pcre
> > requirement at the time? But it seems not:
> >
> > [adamw@xps13k qemu (f36 %)]$ git show 0835325:qemu.spec | grep pcre
> > BuildRequires: glibc-static pcre-static glib2-static zlib-static
> >
> > so, I'm not sure why Daniel concluded this needs a BuildRequires on
> > pcre-static, but the obvious thing to do would be to ask him, I guess.
> >
> 
> I think it could have been a missing requires of glib2-static, because glib
> does use PCRE and therefore has it in the linker flags for a static build.
> I will check next time I am at a computer.

Yes, the spec file is missing requires. I filed a bug about this but
it got auto-closed without being fixed :-(

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

With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Retiring the pcre package from Fedora

[Richard W.M. Jones]

On Tue, Jul 26, 2022 at 10:19:55AM +0200, Paolo Bonzini wrote:
> On Tue, Jul 26, 2022 at 10:10 AM Kalev Lember  wrote:
> > Does this look right to you? Do you want me to add them in other
> > branches as well or is rawhide sufficient for now?
> 
> Rawhide is enough, for other branches QEMU is working around it by
> requiring pcre-static. Thanks!
> 
> I'm now debugging the SIGABRT in file(1).

FYI there was another problem that turned up in the F37 mass rebuild
that you may hit later on:

ERROR: sizeof(size_t) doesn't match GLIB_SIZEOF_SIZE_T.
   You probably need to set PKG_CONFIG_LIBDIR
   to point to the right pkg-config files for your
   build target

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

Rich.

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

Re: Retiring the pcre package from Fedora

[Paolo Bonzini]

On Tue, Jul 26, 2022 at 10:10 AM Kalev Lember  wrote:
> Does this look right to you? Do you want me to add them in other
> branches as well or is rawhide sufficient for now?

Rawhide is enough, for other branches QEMU is working around it by
requiring pcre-static. Thanks!

I'm now debugging the SIGABRT in file(1).

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

Re: Fedora 37 mass rebuild complete

[Petr Pisar]

V Mon, Jul 25, 2022 at 11:47:24PM +0200, Miro Hrončok napsal(a):
> On 25. 07. 22 23:38, Richard W.M. Jones wrote:
> > On Mon, Jul 25, 2022 at 08:57:39AM -0700, Kevin Fenzi wrote:
> > > Hi all,
> > > 
> > > Per the Fedora 37 schedule[1] we started a mass rebuild for Fedora
> > > 37 on 2022/07/20. We did a mass rebuild for Fedora 37 for:
> > > 
> > > https://pagure.io/releng/issues?status=Open=mass+rebuild
> > > 
> > > The mass rebuild was done in a side tag (f37-rebuild) and moved over to
> > > f37. Failures can be seen
> > > https://kojipkgs.fedoraproject.org/mass-rebuild/f37-failures.html  Things
> > > still needing rebuilding
> > > https://kojipkgs.fedoraproject.org/mass-rebuild/f37-need-rebuild.html
> > I could be being stupid here, but what's the difference between
> > packages that failed to build and packages that need rebuilding?
> 
> Considering "need-rebuild" is a superset of "failures" (I've just checked
> [1]) the 2 differences I can think of are:
> 
> 1) Only builds that manage to get past buildSRPMFromSCM are associated to
> the particular package by Koji. Hence, packages that failed buildSRPMFromSCM
> or when the Koji build was not even submitted (i.e. there was no spec file,
> missing source, RPM parse error, noautobuild file, etc.) -- such package
> swill onyl be listed in "need-rebuild" as there is no known associated build
> failure with them.
> 
And then there are the mysterious packages like perl-Math-Cartesian-Product
which even do not have a mass rebuild commit.

I guess because of TCP rejects when pushing/cloning to/from dist-git. It would
be great if relengs retried these network failures next time.

-- 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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Retiring the pcre package from Fedora

[Kalev Lember]

On 7/25/22 10:23, Mamoru TASAKA wrote:

Kalev Lember wrote on 2022/07/25 0:45:

Those both sound a lot like regressions in g_regex_match() to me. If you
have time, any chance you could create smaller reproducers and file 
issues

for these upstream at https://gitlab.gnome.org/GNOME/glib ?


For issue A: reported (with smallest reproducer): 
https://gitlab.gnome.org/GNOME/glib/-/issues/2699


Excellent, thank you!

--
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Retiring the pcre package from Fedora

[Kalev Lember]

On 7/26/22 07:47, Paolo Bonzini wrote:

On 7/24/22 15:42, Kalev Lember wrote:
On Sun, Jul 24, 2022 at 8:58 AM Paolo Bonzini > wrote:




    Il sab 23 lug 2022, 19:12 Adam Williamson
    mailto:adamw...@fedoraproject.org>> ha
    scritto:

    This of course begs a question: did qemu also have a 
non-static pcre

    requirement at the time? But it seems not:

    [adamw@xps13k qemu (f36 %)]$ git show 0835325:qemu.spec | grep 
pcre

    BuildRequires: glibc-static pcre-static glib2-static zlib-static

    so, I'm not sure why Daniel concluded this needs a 
BuildRequires on

    pcre-static, but the obvious thing to do would be to ask him, I
    guess.


    I think it could have been a missing requires of glib2-static,
    because glib does use PCRE and therefore has it in the linker flags
    for a static build. I will check next time I am at a computer.


glib2 switched to pcre2 in rawhide recently. Can you check if qemu 
needs to be updated for that now so that it BuildRequires pcre2-static 
instead?


Yep, that works.  I still think that pcre2-static and 
sysprof-capture-devel belong in glib2's spec file though, but I 
committed that as a stopgap measure.


Ah, yes, of course! I went ahead and added them in 
https://src.fedoraproject.org/rpms/glib2/c/5653dff1816e4bee3c3fdbcc00f2fea73a282093?branch=rawhide


Does this look right to you? Do you want me to add them in other
branches as well or is rawhide sufficient for now?

--
Thanks,
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

default network attack surface, networkmanager stands out

[Nikos Mavrogiannopoulos]

Hi,
 I've been looking at Fedora's default --after installation-- attack
surface in terms of servers running, and I see chrony, and
NetworkManager running. NetworkManager runs as root, while chrony runs
as a dedicated user. NetworkManager according to lsof listens at the
bootpc and dhcpv6-client ports and is a pretty interesting setup.

The reason it is interesting is that when I upgrade chrony it restarts
(due to %systemd_postun_with_restart), but I do not see something
similar in NetworkManager. Meaning on a critical vulnerability that
affects the DHCP client paths of networkmanager all fedora systems
remain vulnerable even after installing the updated packages until
they reboot. Is there a particular reason network-manager or at least
its dhcp portion does not restart on upgade, or did I miss something
while looking at it?

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

Re: F37 proposal: Emacs 28 (Self-Contained Change proposal)

[Peter Oliver]

On Wed, 20 Jul 2022, Dan Čermák wrote:


After the Emacs 28 PR got merged, I went
ahead, built Emacs in Fedora 36 as well and submitted it as an
update


Why, by the way?  This isn’t intended to be a veiled criticism, I’m genuinely 
interested.

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

Re: F37 proposal: Emacs 28 (Self-Contained Change proposal)

[Peter Oliver]

On Sat, 23 Jul 2022, Marcus Müller wrote:


On 23.07.22 01:37, Peter Oliver wrote:


 The emacs developers discourage use of the GTK-only build on X11. Perhaps
 we will want a wrapper to select the most suitable binary.


Oh, I wasn't aware of that, is there somewhere I can read up on that?


See https://lists.gnu.org/archive/html/emacs-devel/2022-04/msg00761.html

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

[Test-Announce] Automated reports redirected into a new mailing list: test-reports

[Kamil Paral]

Hello testers and developers,

please note that we've set up a new mailing list called test-reports [1]
and we've redirected all automated compose/updates/test/etc reports into
it. These reports were previously sent to the test list and devel list and
created a lot of visual noise among regular conversations (especially in
the test list). You can see test-reports archives [1] to see which emails
I'm talking about. The only exception is the main rawhide compose report,
which still goes to the devel list (as well as test-reports), because it
was deemed useful enough to be kept there.

If you're interested in receiving these reports, please subscribe to the
new list. The default reply is set to go to the test list, where we can
have conversations about any suspicious changes/outcomes, but you can of
course start your discussion in the devel list, if you prefer.

Cheers,
Kamil
Fedora QA

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

[Bug 2110575] perl-HTTP-Tiny-0.082 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC|jples...@redhat.com,|
   |mspa...@redhat.com, |
   |ppi...@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=2110575
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure