Re: Rewriting RPM macros using Lua

[Florian Weimer]

* Mark Wielaard:

> Hi Florian,
>
> On Thu, 2021-04-29 at 16:33 +0200, Florian Weimer wrote:
>> I need to wrap find-debuginfo.sh because there is a single shared
>> object
>> in my package that must not be stripped.  find-debuginfo.sh does not
>> support that, and probably never will, at least not in its current
>> shell-based incarnation.
>
> I happened to have a patch that was never submitted upstream that might
> (or might not) help:
> https://code.wildebeest.org/git/user/mjw/rpm/commit/?h=find-debuginfo-exclude
>
> Would that be useful?

My requirements have changed.  I want to preserve debuginfo in full, but
still run dwz in single-file mode (nice size reduction), produce the
source files for /usr/src/debug, and rewrite the file paths to point to
that.  And also merge notes (mainly for annobin).  In the future, we
might apply section compression as well.

See the patch posted here:



All this is really quite specific.

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

Re: Outreachy Final Application help

[Ngulefac Queeniva]

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

Re: plocate?

[Dominique Martinet]

(added mlocate maintainer msekleta in Ccs; hopefully that's a still
valid address)

Zbigniew Jędrzejewski-Szmek wrote on Sat, Feb 20, 2021 at 02:06:00PM +:
> Debian is apparently switching to plocate as the the default
> locate/mlocate provider [0], a bit faster and more disk-efficient.
> Would it make sense to do the same in Fedora?
> 
> I prepared a package [1, 2]. The code seems nice and clean enough.
> I'd be happy to take it through review, but I'm not particular keen
> on long-term maintenance…

Having just tried I think it'd make sense, the difference is striking.
Small db update is a bit slower but that's a background activity, and
search really feels instant (tens of ms) compared to a handful of
seconds.


I think that'll require a bit more work though, and we can start by just
having the package available it doesn't have to be the default right
away (I remembered that there was a discussion but not where it had
ended, so was surprised to find no package in main repos!)

In particular I think we'll need to first rework mlocate to use
alternatives for locate/updatedb, so plocate can use the same names
while keeping both packages parallely installable.


I guess it'd also be fine if the packages would just plain Conflict and
overwrite each other but it's important the commands stay the same
(In that case we can probably also get away by not including
plocate-build in the package, the command converts mlocate db to plocate
format and is probably not going to see any use)



(I'm willing to help with the one-time transition to alternatives if
that's the way forward, or the initial package integration, but I don't
think it'd be reasonable to take plocate myself given my free time
lately... Anyway, let's discuss where we want to go first)

-- 
Dominique
___
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 8 updates-testing report

[updates]

The following Fedora EPEL 8 Security updates need testing:
 Age  URL
  13  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-5b261a2216   
nextcloud-client-3.1.3-1.el8
  12  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-c18d19cbdc   
fluidsynth-2.1.8-3.el8
   8  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-0754fdd085   
openvpn-2.4.11-1.el8
   6  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-24ab212ee8   
p7zip-16.02-20.el8
   3  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-3a1aaec707   
pngcheck-2.4.0-8.el8
   3  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-b308580516   
perl-Image-ExifTool-12.16-3.el8
   2  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-bbc31e5925   
java-latest-openjdk-16.0.1.0.9-1.rolling.el8
   2  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-33433b2f22   
python-yara-4.1.0-1.el8 yara-4.1.0-1.el8


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

dcfldd-1.7-1.el8
dd_rescue-1.99.11-1.el8
duplicity-0.8.19-1.el8
siege-4.0.9-1.el8
vmtouch-1.3.1-1.el8

Details about builds:



 dcfldd-1.7-1.el8 (FEDORA-EPEL-2021-045a8ee6d2)
 Improved dd, useful for forensics and security

Update Information:

switch to fork https://github.com/resurrecting-open-source-projects/dcfldd

ChangeLog:


References:

  [ 1 ] Bug #1955105 - dcfldd-1.7 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1955105




 dd_rescue-1.99.11-1.el8 (FEDORA-EPEL-2021-5aeafff032)
 Fault tolerant "dd" utility for rescuing data from bad media

Update Information:

bump to 1.99.11

ChangeLog:

* Thu Apr 29 2021 Michal Ambroz  - 1.99.11-1
- bump to 1.99.11

References:

  [ 1 ] Bug #1955030 - dd_rescue-1.99.11 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1955030




 duplicity-0.8.19-1.el8 (FEDORA-EPEL-2021-36612779b0)
 Encrypted bandwidth-efficient backup using rsync algorithm

Update Information:

0.8.19

ChangeLog:

* Thu Apr 29 2021 Gwyn Ciesla  - 0.8.19-1
- 0.8.19
* Tue Jan 26 2021 Fedora Release Engineering  - 
0.8.18-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_34_Mass_Rebuild

References:

  [ 1 ] Bug #1955291 - duplicity-0.8.19 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1955291




 siege-4.0.9-1.el8 (FEDORA-EPEL-2021-1a6f123178)
 HTTP regression testing and benchmarking utility

Update Information:

2021/04/17 Jeffrey Fulmer http://www.joedog.org/support/   * src/cookie.c
Added NULL checks for getters  * version.c  Version increment: 4.0.9
2021/04/17 Vedran Miletic https://github.com/vedranmiletic   * src/main.c
Prettified json

ChangeLog:

* Thu Apr 29 2021 Denis Fateyev  - 4.0.9-1
- Update to 4.0.9 (#1950658)

References:

  [ 1 ] Bug #1950658 - siege-4.0.9 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1950658




 vmtouch-1.3.1-1.el8 (FEDORA-EPEL-2021-948b95a4a8)
 Portable file system cache diagnostics and control

Update Information:

Vmtouch is a tool for learning about and controlling the file system cache of
Unix and Unix-like systems.

ChangeLog:

[Bug 1953837] perl-PDL-2.041 is available

[bugzilla]

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

Upstream Release Monitoring  
changed:

   What|Removed |Added

Summary|perl-PDL-2.040 is available |perl-PDL-2.041 is available



--- Comment #1 from Upstream Release Monitoring 
 ---
Latest upstream release: 2.041
Current version/release in rawhide: 2.39.0-1.fc35
URL: http://search.cpan.org/dist/PDL/

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


More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring


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


Based on the information from anitya:
https://release-monitoring.org/project/3205/


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
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 1952398] perl-SVG-2.86 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version|perl-SVG-2.86-1.fc35|perl-SVG-2.86-1.fc35
   ||perl-SVG-2.86-1.fc34
 Resolution|--- |ERRATA
Last Closed||2021-04-30 00:55:29



--- Comment #3 from Fedora Update System  ---
FEDORA-2021-6f9732fcfe has been pushed to the Fedora 34 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.
___
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 1952135] perl-Module-ScanDeps-1.31 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version|perl-Module-ScanDeps-1.31-1 |perl-Module-ScanDeps-1.31-1
   |.fc35   |.fc35
   ||perl-Module-ScanDeps-1.31-1
   ||.fc34
 Resolution|--- |ERRATA
Last Closed||2021-04-30 00:55:22



--- Comment #3 from Fedora Update System  ---
FEDORA-2021-3d07738140 has been pushed to the Fedora 34 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.
___
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 1951972] perl-CPAN-Perl-Releases-5.20210420 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-CPAN-Perl-Releases-5.2 |perl-CPAN-Perl-Releases-5.2
   |0210420-1.fc35  |0210420-1.fc35
   |perl-CPAN-Perl-Releases-5.2 |perl-CPAN-Perl-Releases-5.2
   |0210420-1.fc33  |0210420-1.fc33
   |perl-CPAN-Perl-Releases-5.2 |perl-CPAN-Perl-Releases-5.2
   |0210420-1.fc32  |0210420-1.fc32
   ||perl-CPAN-Perl-Releases-5.2
   ||0210420-1.fc34



--- Comment #9 from Fedora Update System  ---
FEDORA-2021-7883d76468 has been pushed to the Fedora 34 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.
___
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

Fedora-IoT-34-20210429.1 compose check report

[Fedora compose checker]

No missing expected images.

Failed openQA tests: 1/16 (x86_64), 1/15 (aarch64)

New failures (same test not failed in Fedora-IoT-34-20210423.0):

ID: 873671  Test: x86_64 IoT-dvd_ostree-iso iot_clevis
URL: https://openqa.fedoraproject.org/tests/873671

Old failures (same test failed in Fedora-IoT-34-20210423.0):

ID: 873687  Test: aarch64 IoT-dvd_ostree-iso iot_clevis@uefi
URL: https://openqa.fedoraproject.org/tests/873687

Passed openQA tests: 15/16 (x86_64), 14/15 (aarch64)

Installed system changes in test x86_64 IoT-dvd_ostree-iso 
install_default_upload: 
System load changed from 0.05 to 0.30
Previous test data: https://openqa.fedoraproject.org/tests/868176#downloads
Current test data: https://openqa.fedoraproject.org/tests/873673#downloads

Installed system changes in test aarch64 IoT-dvd_ostree-iso 
install_default_upload@uefi: 
System load changed from 0.33 to 0.17
Previous test data: https://openqa.fedoraproject.org/tests/868191#downloads
Current test data: https://openqa.fedoraproject.org/tests/873688#downloads
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
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: New RPM submission

[Dominik 'Rathann' Mierzejewski]

(fixed quoting)

On Thursday, 29 April 2021 at 21:27, Joan Moreau via devel wrote:
> On 2021-04-29 14:51, Qiyu Yan wrote:
> > 在 2021-04-29星期四的 13:25 +0100，Joan Moreau via devel写道：
> > 
> > > Concretely, how to "find a sponsor" ?
[...]
> > FYI:
> > https://fedoraproject.org/wiki/How_to_get_sponsored_into_the_packager_group
[...]
> Isn´t there a much more systemic (and simpler) process to push a RPM in the
> distribution ?

What do you mean by "systemic"? What part of the process would you like
to see simplified?

Bear in mind that Fedora is not just a dumping ground for RPM packages.
Certain level of commitment from package submitters is expected, e.g.
ongoing maintenance of the accepted package.

Regards,
Dominik
-- 
Fedora   https://getfedora.org  |  RPM Fusion  http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
___
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-Legal-README.txt in installation media outdated?

[Kevin Fenzi]

On Thu, Apr 29, 2021 at 11:03:08AM +0200, Miro Hrončok wrote:
> On 28. 04. 21 22:40, Kevin Fenzi wrote:
> > On Wed, Apr 28, 2021 at 02:12:15PM +0800, Qiyu Yan wrote:
> > > If you download a Fedora 34 live iso at https://getfedora.org/
> > > with filename: Fedora-Workstation-Live-x86_64-34-1.2.iso
> > > 
> > > Mount it and see Fedora-Legal-README.txt in the image. There are many
> > > Fedora 31 things show up, should this file be updated on each release
> > > cycle?
> > > 
> > > (Maybe not, unless someone like me mounts the iso file by mistake, and
> > > check the Legal file by curiosity LOL)
> > 
> > It is. It's updated in the prep of fedora-release package, but perhaps
> > something went wrong and the image didn't get the updated version. :(
> 
> There is no updated version.
> 
> https://src.fedoraproject.org/rpms/fedora-release/history/Fedora-Legal-README.txt?identifier=rawhide
> 
> The text was not updated since Fedora 31.

It used to be updated in the spec file %prep
(see up to f28 timeframe):

sed -i 's|@@VERSION@@|%{dist_version}|g' Fedora-Legal-README.txt

Anyhow, I've proposed a change that will hopefully make it version
agnostic and we don't have to update it all the time. 

Thanks again for noting this... we will see what legal says. 

kevin


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

Re: RPM name collisions

[Nicolas Chauvet]

Le jeu. 29 avr. 2021 à 22:04, przemek klosowski via devel
 a écrit :
>...
> For completness, here are the remaining strange cases:
>
> openhantek.x86_64  2.06-1.fc31rpmfusion-nonfree
> openhantek.x86_64  3.2-1.fc34 fedora

I've fixed this one on f35+ for rpmfusion-nonfree. Package moved to
fedora in 2019 but wasn't properly untagged from repo.

Thanks for the notice.
___
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: Outreachy Final Application help

[Lukas Brabec]

Thanks, timeline looks good.

On Thu, Apr 29, 2021 at 3:09 PM Ngulefac Queeniva 
wrote:

> i updated the recent one even more and came up with this. pls review it
> sir
>
>
>
> Week 1-2
> -Discussion with mentors team members and finalizing the approach of the
> project implementation
> -Refactor Code:
> -making components more reusable, that is : Moving class components to
> separate files
> -Make code look cleaner
> -Translate untranslated words.
>
>
> Week 3-4
> -Restructure and order information on the landing page
> -Make content on the page  more presentable, that is
> -using more infographics
> -Changing the way the links and buttons look(making use of iconography)
> -Including additional information and using familiar terms that could be
> easily understood by newcomers
>
>
> Week 5-6
> -Make the wizard section a lot more interactive and user  friendly by :
> -Including proper navigations
> -Including clear instructions, code snippets and results where necessary.
>
>
> Week 7-8
> -Make user experience a lot better and also improve UI
>
>
> Week 9-11
> -Translate the application to the several new languages suggested
> -Period for any pending task
>
>
> ___
> qa-devel mailing list -- qa-devel@lists.fedoraproject.org
> To unsubscribe send an email to qa-devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/qa-devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
>
___
qa-devel mailing list -- qa-devel@lists.fedoraproject.org
To unsubscribe send an email to qa-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/qa-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: RPM name collisions

[Kevin Kofler via devel]

przemek klosowski via devel wrote:
> but the recent trend is to loosen up and increase the
> repository set: rpmfusion, ROCm, packages-microsoft-com-prod are likely
> to be used because they contain useful software.

IMHO, everyone using the Microsoft repository is on their own. Isn't the 
whole reason many of us switched to GNU/Linux to NOT depend on that company?

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: F35 Change: Node.js 16.x by default (System-Wide Change proposal)

[Miro Hrončok]

On 29. 04. 21 21:14, Ben Cotton wrote:

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

== Summary ==
The latest release of Node.js to carry a 30-month lifecycle is the
16.x series. As with 14.x, 12.x, 10.x and 8.x before it, Fedora 35
will carry 16.x as the default Node.js interpreter for the system. The
14.x and 12.x interpreters will remain available as non-default module
streams.
...snip...


I just wanted to say that this is very nicely crafted change proposal, thanks!

--
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: The Death of Java (packages)

[Hans de Goede]

Hi,

On 4/29/21 12:00 PM, Mikolaj Izdebski wrote:
> Hi Hans,
> 
> On Wed, Apr 28, 2021 at 3:47 PM Hans de Goede  wrote:
>> Also I hope it is ok if I pick your brain a bit on a java
>> packaging issue which I've been having.
>>
>> I maintain a couple of java leave packages (games) + some deps
>> which AFAIK are only used by these games.
>>
>> One of these deps (dom4j) has been FTBFS since F34:
>> https://bugzilla.redhat.com/show_bug.cgi?id=1923601
>>
>> I've been looking into this and the actual problem seems to
>> be with Java 9 now including what once was the org.relaxng.datatype
>> except they did not just bundle it, they also changed where it
>> sits in the namespace to com.sun.tools.rngdatatype 
>>
>> Just doing a s/org.relaxng.datatype/com.sun.tools.rngdatatype/
>> got me a bit further, but it seems that msv, which is a dep of
>> dom4j needs to be rebuild first with the same search-replace
>> done on it and the FTBFS bug of msv is stuck because of one
>> of its deps getting orphaned+retired :
>> https://bugzilla.redhat.com/show_bug.cgi?id=1923446
>>
>> So I think I can fix this by:
>>
>> 1. Unorphaning jvnet-parent, which is the missing msv dep
> 
> You can unorphan/unretire it, but removing dependency on jvnet-parent
> is another choice. Probably better choice as jvnet-parent is no longer
> developed or maintained by upstream.
> 
>> 2. Do a s/org.relaxng.datatype/com.sun.tools.rngdatatype/ in msv, rebuild
>> 3. Do a s/org.relaxng.datatype/com.sun.tools.rngdatatype/ in dom4j, rebuild
> 
> relaxngDatatype was retired in Fedora. A replacement is
> jaxb-relaxng-datatype package (built from jaxb source package), but it
> uses a different namespace. Therefore steps 2 and 3 seem correct and
> necessary.
> 
>> And then either do this only for rawhide, or push all 3 modified
>> packages to F34 in a single bodhi update.
>>
>> Mikolaj, does this sounds like a reasonable plan to you; or
>> should I approach this differently?
> 
> Yes, that sounds good. I would also double check to see whether
> msv/dom4j are really needed by your packages.

Thank you for this hint. dom4j is still used by 4 packages,
but "dnf repoquery --whatrequires msv-" returns nothing
but msv for all msv packages. So it seems that nothing is using this
at runtime. As such I've just removed the classes from dom4j which
depend on msv as those seem to be unused.

I've only pushed this to rawhide for now and I've asked the
maintainers of the other 3 packages to test them with the new
dom4j build.

I'll also add a comment to the msv FTBFS bug that it might be
best to just orphan msv as it has been deprecated upstream and
not seen a new release since 2013 it seems.

>> Also if yes this is a reasonable plan any advice on also
>> pushing the fixed packages to F34, or not ?
> 
> I am in favor of F34 update. Users of dom4j/msv that do not rely on
> relaxngDatatype-related functionality should be unaffected by the
> update. Users that do rely on it would get it fixed.

Ok, I'll update dom4j once I've positive testing feedback from
the maintainers of the other pkgs depending on it.

Regards,

Hans
___
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: Rewriting RPM macros using Lua

[Mark Wielaard]

Hi Florian,

On Thu, 2021-04-29 at 16:33 +0200, Florian Weimer wrote:
> I need to wrap find-debuginfo.sh because there is a single shared
> object
> in my package that must not be stripped.  find-debuginfo.sh does not
> support that, and probably never will, at least not in its current
> shell-based incarnation.

I happened to have a patch that was never submitted upstream that might
(or might not) help:
https://code.wildebeest.org/git/user/mjw/rpm/commit/?h=find-debuginfo-exclude

Would that be useful? find-debuginfo.sh is currently maintained in the
debugedit project https://sourceware.org/debugedit which will hopefully
soon enter Fedora so rpm can use it:
https://bugzilla.redhat.com/show_bug.cgi?id=1953633

Cheers,

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

[389-devel] please review: UI - make sure dsconf always uses the LDAPI path and not the server ID

[Mark Reynolds]

https://github.com/389ds/389-ds-base/pull/4743

--

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

Intention to dropping the the "Allow SSH root login with password" option from the installer GUI

[Martin Kolman]

Hi!
At the moment the Anaconda installer used by Fedora contains an option
called "Allow SSH root login with password" on the root password
configuration screen.

This is how it looks like at the moment, on latest Fedora Rawhide
installer image:

https://m4rtink.fedorapeople.org/screenshots/fedora/rawhide_f35/root_password_screen.png

For some backstory - in 2015 the OpenSSH upstream decided to disable
password based root logins by default. This was done for security
reasons as an attacker needs to only guess password to gain access to
the root account. For a user account the attacker needs to guess both
the username and password and the user account not even have admin
privileges, making the remote password guessing attack both harder and
less useful.

The Fedora OpenSSH package carried downstream patches to revert this
upstream change up until summer 2019 when it was decided to restore the
upstream behavior and drop the downstream patches as enough tools that
required password based SSH login have been migrated to use either key
authentication or user based login methods.

Now back to the "Allow SSH root login with password" checkbox in
the installer GUI. :)

The option was added in 2019 when Fedora disabled password based root
SSH login by default, as a temporary migration aid for users of the
graphical installer. 

Note that the checkbox is not ticked by default, the user needs to make
a conscious choice to allow this security problematic SSH login
behavior.

Now fast forward to today, it's 2021, any use cases that needed
password based root login via SSH had 2 more years to migrate while the
amount of password guessing attacks certainly didn't get any lower.

For that reason we in the Anaconda development team feel like it's a
good time to finally drop the "Allow SSH root login with password" from
the Anaconda GUI.

If you are aware of some critical Fedora/Fedora spin usecase that
depends on users regularly ticking this option, please let us know! 

If no such critical usecase is found, we will proceed with removing the
option from the Anaconda GUI in a ~week from now in Rawhide.

Best Wishes
Martin Kolman & the Anaconda team
___
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 1778698] Non-responsive maintainer check for delete

[bugzilla]

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

Matías Kreder  changed:

   What|Removed |Added

 Status|NEW |CLOSED
 Resolution|--- |NOTABUG
Last Closed||2021-04-29 20:05:56




-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
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 1778698] Non-responsive maintainer check for delete

[bugzilla]

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

Matías Kreder  changed:

   What|Removed |Added

   Doc Type|--- |If docs needed, set a value



--- Comment #3 from Matías Kreder  ---
I came back recently, sorry for the delay.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
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

RPM name collisions

[przemek klosowski via devel]

Few weeks ago we had an announcement of a Python supply chain hack where 
people supplied libraries with names matching some private library 
names, which took precedence and overrode those private libraries, 
giving the hackers control.


Now, the name collisions are built-in into RPM, because that's how 
updates work: the original package is in 'fedora' and the updates are 
in, well, 'updates'.  This is fine as long as we control all 
repositories, but the recent trend is to loosen up and increase the 
repository set: rpmfusion, ROCm, packages-microsoft-com-prod are likely 
to be used because they contain useful software. I am all for including 
them, but since we have no control over them, necessarily, maybe we 
should rethink the consequences for the end users.


Specifically, for example, Microsoft likes to keep multiple versions 
online: for instance  aadlogin has nearly 30 versions from 
1.0.00485001-1 to 1.0.015280001-1. As long as this is their exclusive 
package, this is fine---but sometimes it gets more complicated than 
that. For instance, there's aspnetcore-runtime, which is in Fedora, but 
also has nearly 70 versions in MS repo (they cover aspnetcore-runtime 
versions from 2.1 to 5.0; just the 3.1 variants amount just to 18 or so 
packages, that intersect with Fedora ones:


...

aspnetcore-runtime-3.1.x86_64    3.1.12-1 packages-microsoft-com-prod
aspnetcore-runtime-3.1.x86_64    3.1.13-1 packages-microsoft-com-prod
aspnetcore-runtime-3.1.x86_64    3.1.13-2.fc34 fedora
aspnetcore-runtime-3.1.x86_64    3.1.14-1 packages-microsoft-com-prod
aspnetcore-runtime-3.1.x86_64    3.1.14-1.fc34 updates
...

These packages are actually coming from Microsoft, and the versioning 
seems consistent, so I guess there's nothing wrong with this setup 
besides a possibility for confusion as to which one is actually 
installed. But sometimes the versions are much more divergent:


netstandard-targeting-pack-2.1.x86_64  2.1.0-1 packages-microsoft-com-prod
netstandard-targeting-pack-2.1.x86_64  5.0.104-1.fc34 fedora
netstandard-targeting-pack-2.1.x86_64  5.0.202-1.fc34   updates

and here's a really weird one:

hello.x86_64    2.8-1    packages-microsoft-com-prod
hello.x86_64    2.10-5.fc34   fedora

Why would they put it in their repo? I don't expect any harm here, but 
just looking at this this made me think of the Python debacle I 
mentioned earlier.


Is that something we need to worry about? I couldn't think of any new 
rules to impose on repositories, but maybe dnf should have more explicit 
warnings when it sees multiple versions of the same package, or at least 
a way to show such versions.


As it is now, I think it just handles the most current version, but this 
is fragile across separately managed repositories, and doesn't easily 
show all the available versions---in order to collect the data I wrote a 
script that iterates over 'yum repolist' and disables */enables one repo 
at a time.





For completness, here are the remaining strange cases:

openhantek.x86_64  2.06-1.fc31    rpmfusion-nonfree
openhantek.x86_64  3.2-1.fc34 fedora

procdump.x86_64   1.1-207         packages-microsoft-com-prod
procdump.x86_64   1.1.1-3.fc34    fedora
procdump.x86_64   1.1.1-218  packages-microsoft-com-prod
procdump.x86_64   1.1.1-220  packages-microsoft-com-prod
___
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: New RPM submission

[Joan Moreau via devel]

THank you

Isn´t there a muh more systemic (and simpler) process to push a RPM in 
the distribution ?


On 2021-04-29 14:51, Qiyu Yan wrote:


在 2021-04-29星期四的 13:25 +0100，Joan Moreau via devel写道：


Thank you
Concretely, how to "find a sponsor" ?

FYI:
https://fedoraproject.org/wiki/How_to_get_sponsored_into_the_packager_group

___
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

F35 Change: Node.js 16.x by default (System-Wide Change proposal)

[Ben Cotton]

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

== Summary ==
The latest release of Node.js to carry a 30-month lifecycle is the
16.x series. As with 14.x, 12.x, 10.x and 8.x before it, Fedora 35
will carry 16.x as the default Node.js interpreter for the system. The
14.x and 12.x interpreters will remain available as non-default module
streams.

== Owner ==
* Name: [[User:zvetlik| Zuzana Svetlikova]]
* Email: zsvet...@redhat.com
* Name: [[User:Sgallagh| Stephen Gallagher]]
* Email: sgall...@fedoraproject.org
* Responsible SIG: Node.js SIG



== Detailed Description ==
Fedora 35 will ship with the latest LTS version of Node.js. '''dnf
install nodejs''' will give users nodejs-16.x and the matching npm
package.

== Benefit to Fedora ==
Node.js is a popular server-side JavaScript engine. Keeping Fedora on
the latest release allows us to continue tracking the state-of-the-art
in that space. For those whose applications do not yet work with the
16.x release, Fedora 35 will also have the 14.x and 12.x releases
available as selectable module streams.

== Scope ==
* Proposal owners: The packages are already built for Fedora 33, 34
and 35 in a non-default module stream. On June 14th, 2021, the
nodejs-16.x packages will be built in the non-modular repository and
thus become the default in Fedora 35.

* Other developers: Any developer with a package that depends on
Node.js at run-time or build-time should test with the 16.x module
stream enabled as soon as possible. Issues should be reported to
nod...@lists.fedoraproject.org

* Release engineering: We will coordinate with the Node.js SIG to
create a side-tag to perform the rebuilds before making 16.x the
default.
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)


== Upgrade/compatibility impact ==
As with previous releases, users running Fedora 33 or Fedora 34 with
the non-modular nodejs-14.x packages will be automatically upgraded to
the 16.x packages when they upgrade to Fedora 35, which may cause
issues. If users are running software known not to support Node.js
16.x yet, they can switch the system to use 14.x with '''dnf module'''
commands.

== How To Test ==
* Confirm that `dnf install nodejs` results in Node.js 16.x being installed.
* Confirm that upgrading from Fedora 33 or Fedora 34 with nodejs-14.x
installed (non-modular) results in an upgrade to nodejs-16.x
* Confirm that upgrading from Fedora 33 or Fedora 34 with the
`nodejs:14` module enabled does *not* result in an upgrade to 16.x and
still has `nodejs:14` enabled on Fedora 35.
* Confirm that upgrading from Fedora 33 or Fedora 34 with the
`nodejs:16` module enabled upgrades successfully and still has
`nodejs:16` enabled on Fedora 33.

== User Experience ==
Users will have the 16.x release of Node.js available by default. See
the "Upgrade/compatibility impact" section for specific details.

== Dependencies ==
All packages prefixed with `nodejs-` depend on this package. If they
do not work with Node.js 16.x, they will need to be updated, made
modular and dependent upon the `nodejs:14` stream or else removed from
Fedora 35.

Prior to the switchover date to Node.js 16.x as the default, packagers
are strongly encouraged to test their existing Node modules with 16.x
via the Modular version by running:


dnf module reset nodejs
dnf module install nodejs:16/development


Packagers can also test their builds using `mock` by creating the file
`/etc/mock/fedora-rawhide-x86_64-nodejs16.cfg` with the following
contents:


config_opts['target_arch'] = 'x86_64'
config_opts['legal_host_arches'] = ('x86_64',)
config_opts['enable_disable_repos'] = ['--enablerepo', 'rawhide-modular']
config_opts['module_install'] = ['nodejs:16/development']

include('templates/fedora-rawhide.tpl')


Then call

mock -r fedora-rawhide-x86_64-nodejs16 --enablerepo=rawhide-modular nodejs-foo


(Note that the `--enablerepo=rawhide-modular` portion looks redundant,
but this is because of
[https://github.com/rpm-software-management/mock/issues/591 a mock
bug])

== Contingency Plan ==
* Contingency mechanism:
Revert to Node.js 14.x as the default Node.js interpreter. This will
require bumping epoch.

* Contingency deadline: Beta Freeze
* Blocks release? No
* Blocks product? No

== Documentation ==
* https://nodejs.org/dist/latest-v16.x/docs/api/
* https://github.com/nodejs/node/blob/master/doc/changelogs/CHANGELOG_V16.md

== Release Notes ==
Fedora 35 now ships with Node.js 16.x as the default Node.js
JavaScript server-side engine. If your applications are not yet ready
for this newer version, you can revert to the 14.x series by running
the following commands


dnf remove nodejs
dnf module reset nodejs
dnf module install nodejs:14



-- 
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe 

F35 Change: Node.js 16.x by default (System-Wide Change proposal)

[Ben Cotton]

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

== Summary ==
The latest release of Node.js to carry a 30-month lifecycle is the
16.x series. As with 14.x, 12.x, 10.x and 8.x before it, Fedora 35
will carry 16.x as the default Node.js interpreter for the system. The
14.x and 12.x interpreters will remain available as non-default module
streams.

== Owner ==
* Name: [[User:zvetlik| Zuzana Svetlikova]]
* Email: zsvet...@redhat.com
* Name: [[User:Sgallagh| Stephen Gallagher]]
* Email: sgall...@fedoraproject.org
* Responsible SIG: Node.js SIG



== Detailed Description ==
Fedora 35 will ship with the latest LTS version of Node.js. '''dnf
install nodejs''' will give users nodejs-16.x and the matching npm
package.

== Benefit to Fedora ==
Node.js is a popular server-side JavaScript engine. Keeping Fedora on
the latest release allows us to continue tracking the state-of-the-art
in that space. For those whose applications do not yet work with the
16.x release, Fedora 35 will also have the 14.x and 12.x releases
available as selectable module streams.

== Scope ==
* Proposal owners: The packages are already built for Fedora 33, 34
and 35 in a non-default module stream. On June 14th, 2021, the
nodejs-16.x packages will be built in the non-modular repository and
thus become the default in Fedora 35.

* Other developers: Any developer with a package that depends on
Node.js at run-time or build-time should test with the 16.x module
stream enabled as soon as possible. Issues should be reported to
nod...@lists.fedoraproject.org

* Release engineering: We will coordinate with the Node.js SIG to
create a side-tag to perform the rebuilds before making 16.x the
default.
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)


== Upgrade/compatibility impact ==
As with previous releases, users running Fedora 33 or Fedora 34 with
the non-modular nodejs-14.x packages will be automatically upgraded to
the 16.x packages when they upgrade to Fedora 35, which may cause
issues. If users are running software known not to support Node.js
16.x yet, they can switch the system to use 14.x with '''dnf module'''
commands.

== How To Test ==
* Confirm that `dnf install nodejs` results in Node.js 16.x being installed.
* Confirm that upgrading from Fedora 33 or Fedora 34 with nodejs-14.x
installed (non-modular) results in an upgrade to nodejs-16.x
* Confirm that upgrading from Fedora 33 or Fedora 34 with the
`nodejs:14` module enabled does *not* result in an upgrade to 16.x and
still has `nodejs:14` enabled on Fedora 35.
* Confirm that upgrading from Fedora 33 or Fedora 34 with the
`nodejs:16` module enabled upgrades successfully and still has
`nodejs:16` enabled on Fedora 33.

== User Experience ==
Users will have the 16.x release of Node.js available by default. See
the "Upgrade/compatibility impact" section for specific details.

== Dependencies ==
All packages prefixed with `nodejs-` depend on this package. If they
do not work with Node.js 16.x, they will need to be updated, made
modular and dependent upon the `nodejs:14` stream or else removed from
Fedora 35.

Prior to the switchover date to Node.js 16.x as the default, packagers
are strongly encouraged to test their existing Node modules with 16.x
via the Modular version by running:


dnf module reset nodejs
dnf module install nodejs:16/development


Packagers can also test their builds using `mock` by creating the file
`/etc/mock/fedora-rawhide-x86_64-nodejs16.cfg` with the following
contents:


config_opts['target_arch'] = 'x86_64'
config_opts['legal_host_arches'] = ('x86_64',)
config_opts['enable_disable_repos'] = ['--enablerepo', 'rawhide-modular']
config_opts['module_install'] = ['nodejs:16/development']

include('templates/fedora-rawhide.tpl')


Then call

mock -r fedora-rawhide-x86_64-nodejs16 --enablerepo=rawhide-modular nodejs-foo


(Note that the `--enablerepo=rawhide-modular` portion looks redundant,
but this is because of
[https://github.com/rpm-software-management/mock/issues/591 a mock
bug])

== Contingency Plan ==
* Contingency mechanism:
Revert to Node.js 14.x as the default Node.js interpreter. This will
require bumping epoch.

* Contingency deadline: Beta Freeze
* Blocks release? No
* Blocks product? No

== Documentation ==
* https://nodejs.org/dist/latest-v16.x/docs/api/
* https://github.com/nodejs/node/blob/master/doc/changelogs/CHANGELOG_V16.md

== Release Notes ==
Fedora 35 now ships with Node.js 16.x as the default Node.js
JavaScript server-side engine. If your applications are not yet ready
for this newer version, you can revert to the 14.x series by running
the following commands


dnf remove nodejs
dnf module reset nodejs
dnf module install nodejs:14



-- 
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to 

[Bug 1955258] New: perl-Graphics-TIFF-12 is available

[bugzilla]

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

Bug ID: 1955258
   Summary: perl-Graphics-TIFF-12 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Graphics-TIFF
  Keywords: FutureFeature, Triaged
  Assignee: ppi...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: perl-devel@lists.fedoraproject.org, ppi...@redhat.com
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 12
Current version/release in rawhide: 11-1.fc35
URL: http://search.cpan.org/dist/Graphics-TIFF/

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


More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring


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


Based on the information from anitya:
https://release-monitoring.org/project/15735/


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
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 1379554] perl-XML-Twig: expand_external_ents option fails to work as documented [fedora-all]

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

Version|32  |34




-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
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

REMINDER: Fedora Linux 32 End of Life on 2021-05-25

[Ben Cotton]

Fedora Linux 32 will reach EOL on Tuesday 25 May 2021. On this day, we
will close all of the F32 bugs which remain open.

You have a few weeks remaining to submit updates, if you have any,
before the Fedora 32 release becomes unsupported. As a reminder,
updates that are still in testing when EOL is reached will not be
pushed to stable.

-- 
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
___
devel-announce mailing list -- devel-annou...@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org
Do not reply to spam 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

REMINDER: Fedora Linux 32 End of Life on 2021-05-25

[Ben Cotton]

Fedora Linux 32 will reach EOL on Tuesday 25 May 2021. On this day, we
will close all of the F32 bugs which remain open.

You have a few weeks remaining to submit updates, if you have any,
before the Fedora 32 release becomes unsupported. As a reminder,
updates that are still in testing when EOL is reached will not be
pushed to stable.

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

[Bug 1835359] perl-Email-MIME: rubygem-mail: Out of memory issue through nested MIME parts [fedora-all]

[bugzilla]

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



--- Comment #9 from Fedora Program Management 
 ---
This message is a reminder that Fedora 32 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 32 on 2021-05-25.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with
a
Fedora 'version' of '32'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 32 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
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 1835354] perl-Email-MIME-ContentType: rubygem-mail: Out of memory issue through nested MIME parts [fedora-all]

[bugzilla]

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



--- Comment #9 from Fedora Program Management 
 ---
This message is a reminder that Fedora 32 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 32 on 2021-05-25.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with
a
Fedora 'version' of '32'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 32 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
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 1795179] Non-responsive maintainer check for ddick

[bugzilla]

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



--- Comment #3 from Fedora Program Management 
 ---
This message is a reminder that Fedora 32 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 32 on 2021-05-25.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with
a
Fedora 'version' of '32'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 32 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
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 1778699] Non-responsive maintainer check for iarnell

[bugzilla]

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



--- Comment #2 from Fedora Program Management 
 ---
This message is a reminder that Fedora 32 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 32 on 2021-05-25.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with
a
Fedora 'version' of '32'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 32 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
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 1379554] perl-XML-Twig: expand_external_ents option fails to work as documented [fedora-all]

[bugzilla]

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



--- Comment #11 from Fedora Program Management 
 ---
This message is a reminder that Fedora 32 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 32 on 2021-05-25.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with
a
Fedora 'version' of '32'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 32 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
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 1778698] Non-responsive maintainer check for delete

[bugzilla]

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



--- Comment #2 from Fedora Program Management 
 ---
This message is a reminder that Fedora 32 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 32 on 2021-05-25.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with
a
Fedora 'version' of '32'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 32 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
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 1887111] SELinux is preventing graph.cgi from read access on the directory cpu.

[bugzilla]

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



--- Comment #3 from Fedora Program Management 
 ---
This message is a reminder that Fedora 32 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 32 on 2021-05-25.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with
a
Fedora 'version' of '32'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 32 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
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 1786000] Perl 5.30 always crashed at Perl__invlist_intersection_maybe_complement_2nd by segfault.

[bugzilla]

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



--- Comment #4 from Fedora Program Management 
 ---
This message is a reminder that Fedora 32 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 32 on 2021-05-25.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with
a
Fedora 'version' of '32'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 32 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
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 1781757] Co-maintainer request (to maintain EPEL8 branch)

[bugzilla]

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



--- Comment #2 from Fedora Program Management 
 ---
This message is a reminder that Fedora 32 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 32 on 2021-05-25.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with
a
Fedora 'version' of '32'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 32 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
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: Unretiring and maintaining the Fish Fillets NG game

[Nikolay Nikolov]

On 4/29/21 11:19 AM, Kamil Paral wrote:
On Thu, Apr 29, 2021 at 3:59 AM Nikolay Nikolov > wrote:


What are the next steps for unretiring these two packages and
maintaining them?


Hey Nikolay,
thanks for taking care of Fish Fillets, it's a great game (and also 
from my country). Here I found the instructions for unretiring a package:
https://fedoraproject.org/wiki/Orphaned_package_that_need_new_maintainers#Claiming_Ownership_of_a_Retired_Package 



Ok, I filed a review request:

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

Now I'm waiting for someone to review it.

Best regards,

Nikolay

___
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 1781734] Co-maintainer request (to maintain EPEL8 branch)

[bugzilla]

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

Matías Kreder  changed:

   What|Removed |Added

 Status|NEW |CLOSED
 Resolution|--- |RAWHIDE
   Doc Type|--- |If docs needed, set a value
Last Closed||2021-04-29 16:09:24



--- Comment #3 from Matías Kreder  ---
Sorry for the huge delay on this, I have had limited time during the last few
years but I am back now. 
I have added 2 users as co-maintainers for this package.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
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 1768805] perl-RDF-Trine for EL8

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Depends On|1769774 |





Referenced Bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=1769774
[Bug 1769774] Add redland-bindings to EPEL8
-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
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 1781205] XML::LibXSLT appears to suffer from latent libxml2's API misuse, only got exposed with libxml2 2.9.10

[bugzilla]

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



--- Comment #2 from Fedora Program Management 
 ---
This message is a reminder that Fedora 32 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 32 on 2021-05-25.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with
a
Fedora 'version' of '32'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 32 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
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 1781758] Co-maintainer request (to maintain EPEL8 branch)

[bugzilla]

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



--- Comment #3 from Fedora Program Management 
 ---
This message is a reminder that Fedora 32 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 32 on 2021-05-25.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with
a
Fedora 'version' of '32'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 32 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
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 1781741] Co-maintainer request (to maintain EPEL8 branch)

[bugzilla]

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



--- Comment #3 from Fedora Program Management 
 ---
This message is a reminder that Fedora 32 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 32 on 2021-05-25.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with
a
Fedora 'version' of '32'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 32 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
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 1781734] Co-maintainer request (to maintain EPEL8 branch)

[bugzilla]

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



--- Comment #2 from Fedora Program Management 
 ---
This message is a reminder that Fedora 32 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 32 on 2021-05-25.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with
a
Fedora 'version' of '32'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 32 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
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 1748928] perl-PDL-2.19.0-8 FTBFS: proj-nad dependency does not exist

[bugzilla]

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



--- Comment #8 from Fedora Program Management 
 ---
This message is a reminder that Fedora 32 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 32 on 2021-05-25.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with
a
Fedora 'version' of '32'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 32 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
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 1731721] perl-Font-AFM depends on files/directories from non-standard locations

[bugzilla]

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



--- Comment #5 from Fedora Program Management 
 ---
This message is a reminder that Fedora 32 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 32 on 2021-05-25.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with
a
Fedora 'version' of '32'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 32 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
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 1731718] perl-Convert-Color depends on files/directories from non-standard locations

[bugzilla]

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



--- Comment #5 from Fedora Program Management 
 ---
This message is a reminder that Fedora 32 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 32 on 2021-05-25.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with
a
Fedora 'version' of '32'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 32 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
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 1708214] Upgrade perl-Net-DNS-SEC to 1.17

[bugzilla]

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



--- Comment #11 from Fedora Program Management 
 ---
This message is a reminder that Fedora 32 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 32 on 2021-05-25.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with
a
Fedora 'version' of '32'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 32 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
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 1581656] Please remove dependency on a2ps

[bugzilla]

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



--- Comment #5 from Fedora Program Management 
 ---
This message is a reminder that Fedora 32 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 32 on 2021-05-25.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with
a
Fedora 'version' of '32'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 32 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
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: mingw-gcc to 11.1 ?

[Richard W.M. Jones]

On Thu, Apr 29, 2021 at 05:22:03PM +0200, Sandro Mani wrote:
> 
> On 29.04.21 17:14, Richard W.M. Jones wrote:
> >This patch (attached, slightly different from the one I sent to you
> >earlier) builds a package for me using 'fedpkg local'.
> >
> >What do you think?
> 
> Yep, I also had to add g++-mapper-server, and the build succeeds.
> I'm performing a full chain gcc (bootstrap) -> crt -> gcc
> (bootstrap2) -> winpthreads -> gcc (full) here [1] and if all works
> then I'd proceed with the build in Rawhide.
> 
> As for pulling the patches from the native package, I don't really
> have the capacity to follow up with all downstream/backported
> patches, but I certainly don't have any objections if it were done!

It seems like it would be worth having them.  Unfortunately the patch
numbers of the base patches clash with the ones for mingw-gcc, so to
be neat we'd need to renumber the mingw-gcc ones.

When you finish your build and it's in Rawhide then I'll see how hard
it will be to add the gcc patches.

Rich.

> Sandro
> 
> [1] https://copr.fedorainfracloud.org/coprs/smani/mingw-gcc-11/builds/

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: mingw-gcc to 11.1 ?

[Sandro Mani]

On 29.04.21 17:14, Richard W.M. Jones wrote:

This patch (attached, slightly different from the one I sent to you
earlier) builds a package for me using 'fedpkg local'.

What do you think?


Yep, I also had to add g++-mapper-server, and the build succeeds. I'm 
performing a full chain gcc (bootstrap) -> crt -> gcc (bootstrap2) -> 
winpthreads -> gcc (full) here [1] and if all works then I'd proceed 
with the build in Rawhide.


As for pulling the patches from the native package, I don't really have 
the capacity to follow up with all downstream/backported patches, but I 
certainly don't have any objections if it were done!


Sandro

[1] https://copr.fedorainfracloud.org/coprs/smani/mingw-gcc-11/builds/
___
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: mingw-gcc to 11.1 ?

[Richard W.M. Jones]

This patch (attached, slightly different from the one I sent to you
earlier) builds a package for me using 'fedpkg local'.

What do you think?

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
>From a9856ef0042a26adcc832391376f123a679c1dad Mon Sep 17 00:00:00 2001
From: "Richard W.M. Jones" 
Date: Thu, 29 Apr 2021 13:56:41 +0100
Subject: [PATCH] Update to 11.1.1

---
 .gitignore |  1 +
 mingw-gcc-config.patch | 24 
 mingw-gcc.spec | 21 +++--
 sources|  2 +-
 4 files changed, 25 insertions(+), 23 deletions(-)

diff --git a/.gitignore b/.gitignore
index 047789b..e8e7dc5 100644
--- a/.gitignore
+++ b/.gitignore
@@ -40,3 +40,4 @@ gcc-4.5.1.tar.bz2
 /gcc-10.1.1-20200618.tar.xz
 /gcc-10.2.1-20200723.tar.xz
 /gcc-10.3.1-20210422.tar.xz
+/gcc-11.1.1-20210428.tar.xz
diff --git a/mingw-gcc-config.patch b/mingw-gcc-config.patch
index 1484357..bfad352 100644
--- a/mingw-gcc-config.patch
+++ b/mingw-gcc-config.patch
@@ -1,7 +1,7 @@
-diff -rupN --no-dereference gcc-10.3.1-20210422/config/intdiv0.m4 
gcc-10.3.1-20210422-new/config/intdiv0.m4
 gcc-10.3.1-20210422/config/intdiv0.m4  2021-04-22 19:22:55.0 
+0200
-+++ gcc-10.3.1-20210422-new/config/intdiv0.m4  2021-04-26 18:35:17.451105239 
+0200
-@@ -31,10 +31,10 @@ sigfpe_handler (sig) int sig;
+diff -ur gcc-11.1.1-20210428.old/config/intdiv0.m4 
gcc-11.1.1-20210428.new/config/intdiv0.m4
+--- gcc-11.1.1-20210428.old/config/intdiv0.m4  2021-04-28 12:34:08.0 
+0100
 gcc-11.1.1-20210428.new/config/intdiv0.m4  2021-04-29 14:01:47.129662449 
+0100
+@@ -31,10 +31,10 @@
exit (sig != SIGFPE);
  }
  
@@ -16,10 +16,10 @@ diff -rupN --no-dereference 
gcc-10.3.1-20210422/config/intdiv0.m4 gcc-10.3.1-202
  
  int main ()
  {
-diff -rupN --no-dereference gcc-10.3.1-20210422/libiberty/aclocal.m4 
gcc-10.3.1-20210422-new/libiberty/aclocal.m4
 gcc-10.3.1-20210422/libiberty/aclocal.m4   2021-04-22 19:22:55.0 
+0200
-+++ gcc-10.3.1-20210422-new/libiberty/aclocal.m4   2021-04-26 
18:35:17.591105242 +0200
-@@ -149,7 +149,7 @@ if test $ac_cv_os_cray = yes; then
+diff -ur gcc-11.1.1-20210428.old/libiberty/acinclude.m4 
gcc-11.1.1-20210428.new/libiberty/acinclude.m4
+--- gcc-11.1.1-20210428.old/libiberty/acinclude.m4 2021-04-28 
12:34:08.0 +0100
 gcc-11.1.1-20210428.new/libiberty/acinclude.m4 2021-04-29 
14:02:45.821440514 +0100
+@@ -157,7 +157,7 @@
  fi
  
  AC_CACHE_CHECK(stack direction for C alloca, ac_cv_c_stack_direction,
@@ -28,10 +28,10 @@ diff -rupN --no-dereference 
gcc-10.3.1-20210422/libiberty/aclocal.m4 gcc-10.3.1-
  {
static char *addr = 0;
auto char dummy;
-diff -rupN --no-dereference gcc-10.3.1-20210422/libiberty/configure.ac 
gcc-10.3.1-20210422-new/libiberty/configure.ac
 gcc-10.3.1-20210422/libiberty/configure.ac 2021-04-22 19:22:55.0 
+0200
-+++ gcc-10.3.1-20210422-new/libiberty/configure.ac 2021-04-26 
18:35:17.591105242 +0200
-@@ -664,7 +664,7 @@ if test -z "${setobjs}"; then
+diff -ur gcc-11.1.1-20210428.old/libiberty/configure.ac 
gcc-11.1.1-20210428.new/libiberty/configure.ac
+--- gcc-11.1.1-20210428.old/libiberty/configure.ac 2021-04-28 
12:34:08.0 +0100
 gcc-11.1.1-20210428.new/libiberty/configure.ac 2021-04-29 
14:01:47.131662473 +0100
+@@ -665,7 +665,7 @@
for v in $vars; do
  AC_MSG_CHECKING([for $v])
  AC_CACHE_VAL(libiberty_cv_var_$v,
diff --git a/mingw-gcc.spec b/mingw-gcc.spec
index 853384a..04bf2d2 100644
--- a/mingw-gcc.spec
+++ b/mingw-gcc.spec
@@ -23,10 +23,10 @@
 # Run the testsuite
 %global enable_tests 0
 
-%global DATE 20210422
-%global GITREV dc5e381a715a658cfcc08ba3cbaa6bc53adc596f
-%global gcc_version 10.3.1
-%global gcc_major 10
+%global DATE 20210428
+%global GITREV eb4b27fdf644012c40fe49ba8440594770dd8289
+%global gcc_version 11.1.1
+%global gcc_major 11
 
 Name:   mingw-gcc
 Version:%{gcc_version}
@@ -459,6 +459,7 @@ ln -sf %{mingw64_bindir}/libssp-0.dll 
%{buildroot}%{mingw64_libdir}/libssp.dll.a
 %{_prefix}/lib/gcc/%{mingw32_target}/%{version}/include/*.h
 %{_prefix}/lib/gcc/%{mingw32_target}/%{version}/install-tools/*
 %{_libexecdir}/gcc/%{mingw32_target}/%{version}/collect2
+%{_libexecdir}/gcc/%{mingw32_target}/%{version}/g++-mapper-server
 %{_libexecdir}/gcc/%{mingw32_target}/%{version}/lto-wrapper
 %{_libexecdir}/gcc/%{mingw32_target}/%{version}/install-tools
 %{_mandir}/man1/%{mingw32_target}-gcc.1*
@@ -488,9 +489,7 @@ ln -sf %{mingw64_bindir}/libssp-0.dll 
%{buildroot}%{mingw64_libdir}/libssp.dll.a
 %dir %{_prefix}/lib/gcc/%{mingw32_target}/%{version}/include/ssp
 %{_prefix}/lib/gcc/%{mingw32_target}/%{version}/include/ssp/*.h
 

Rewriting RPM macros using Lua

[Florian Weimer]

I need to wrap find-debuginfo.sh because there is a single shared object
in my package that must not be stripped.  find-debuginfo.sh does not
support that, and probably never will, at least not in its current
shell-based incarnation.

So I came up with this:

%{lua:
local wrapper = rpm.expand("%{SOURCE10}")
local ldso = rpm.expand("%{glibc_sysroot}/%{_lib}/ld-%{VERSION}.so")
local original = rpm.expand("%{macrobody:__debug_install_post}")
-- Strip leading newline.  It confuses the macro redefinition.
-- Avoid embedded newlines that confuse the macro definition.
original = original:match("^%s*(.-)%s*$"):gsub("\\\n", "")
rpm.define("__debug_install_post bash " .. wrapper
  .. " " .. ldso .. " " .. original)
}

It seems to work, but is there a better way to re-define a macro?

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

Re: New RPM submission

[Qiyu Yan]

在 2021-04-29星期四的 13:25 +0100，Joan Moreau via devel写道：
> Thank you
> Concretely, how to "find a sponsor" ?
FYI:
https://fedoraproject.org/wiki/How_to_get_sponsored_into_the_packager_group


-- 
Qiyu Yan
GPG keyid: 0x4FC914F065F2DF12






signature.asc
Description: This is a digitally signed message part
___
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: mingw-gcc to 11.1 ?

[Richard W.M. Jones]

On Thu, Apr 29, 2021 at 02:44:12PM +0200, Sandro Mani wrote:
> Hi Rich
> 
> Last attempt stranded on [1], I haven't tried since but looks like
> the bug is still open. If you want to give it a go, please do!

Things seem to be going better here.

I'm hitting:

error: File not found: 
/home/rjones/rpmbuild/BUILDROOT/mingw-gcc-11.1.1-1.fc35.x86_64/usr/libexec/gcc/i686-w64-mingw32/11.1.1/liblto_plugin.so.0
error: File not found: 
/home/rjones/rpmbuild/BUILDROOT/mingw-gcc-11.1.1-1.fc35.x86_64/usr/libexec/gcc/i686-w64-mingw32/11.1.1/liblto_plugin.so.0.0.0

The problem is actually that the symlinks are not being created.
liblto_plugin.so exists.

The base gcc package uses "liblto_plugin.so*" in the files section
instead of the explicit named files.  So I'm not sure how important
that is.

Are you aiming to keep alignment with base gcc patches?  There are
quite a lot of them -- about 20 -- but none of them are copied over
the mingw-gcc at the moment.

My patch is attached.

Rich.

> Many thanks
> Sandro
> 
> 
> [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97618
> 
> On 29.04.21 10:07, Richard W.M. Jones wrote:
> >Hi Sandro,
> >
> >Are you planning to update mingw-gcc to 11.1?  The main gcc package
> >was updated to this version yesterday:
> >
> >https://src.fedoraproject.org/rpms/gcc/commits/rawhide
> >
> >If not, then I would like to do it if you have no objections.
> >
> >Rich.
> >

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/
>From ece44660ca2c9ba6de6cf5c3f011f79bf07611fc Mon Sep 17 00:00:00 2001
From: "Richard W.M. Jones" 
Date: Thu, 29 Apr 2021 13:56:41 +0100
Subject: [PATCH] Update to 11.1.1

---
 .gitignore |  1 +
 mingw-gcc-config.patch | 24 
 mingw-gcc.spec | 19 +--
 sources|  2 +-
 4 files changed, 23 insertions(+), 23 deletions(-)

diff --git a/.gitignore b/.gitignore
index 047789b..e8e7dc5 100644
--- a/.gitignore
+++ b/.gitignore
@@ -40,3 +40,4 @@ gcc-4.5.1.tar.bz2
 /gcc-10.1.1-20200618.tar.xz
 /gcc-10.2.1-20200723.tar.xz
 /gcc-10.3.1-20210422.tar.xz
+/gcc-11.1.1-20210428.tar.xz
diff --git a/mingw-gcc-config.patch b/mingw-gcc-config.patch
index 1484357..bfad352 100644
--- a/mingw-gcc-config.patch
+++ b/mingw-gcc-config.patch
@@ -1,7 +1,7 @@
-diff -rupN --no-dereference gcc-10.3.1-20210422/config/intdiv0.m4 
gcc-10.3.1-20210422-new/config/intdiv0.m4
 gcc-10.3.1-20210422/config/intdiv0.m4  2021-04-22 19:22:55.0 
+0200
-+++ gcc-10.3.1-20210422-new/config/intdiv0.m4  2021-04-26 18:35:17.451105239 
+0200
-@@ -31,10 +31,10 @@ sigfpe_handler (sig) int sig;
+diff -ur gcc-11.1.1-20210428.old/config/intdiv0.m4 
gcc-11.1.1-20210428.new/config/intdiv0.m4
+--- gcc-11.1.1-20210428.old/config/intdiv0.m4  2021-04-28 12:34:08.0 
+0100
 gcc-11.1.1-20210428.new/config/intdiv0.m4  2021-04-29 14:01:47.129662449 
+0100
+@@ -31,10 +31,10 @@
exit (sig != SIGFPE);
  }
  
@@ -16,10 +16,10 @@ diff -rupN --no-dereference 
gcc-10.3.1-20210422/config/intdiv0.m4 gcc-10.3.1-202
  
  int main ()
  {
-diff -rupN --no-dereference gcc-10.3.1-20210422/libiberty/aclocal.m4 
gcc-10.3.1-20210422-new/libiberty/aclocal.m4
 gcc-10.3.1-20210422/libiberty/aclocal.m4   2021-04-22 19:22:55.0 
+0200
-+++ gcc-10.3.1-20210422-new/libiberty/aclocal.m4   2021-04-26 
18:35:17.591105242 +0200
-@@ -149,7 +149,7 @@ if test $ac_cv_os_cray = yes; then
+diff -ur gcc-11.1.1-20210428.old/libiberty/acinclude.m4 
gcc-11.1.1-20210428.new/libiberty/acinclude.m4
+--- gcc-11.1.1-20210428.old/libiberty/acinclude.m4 2021-04-28 
12:34:08.0 +0100
 gcc-11.1.1-20210428.new/libiberty/acinclude.m4 2021-04-29 
14:02:45.821440514 +0100
+@@ -157,7 +157,7 @@
  fi
  
  AC_CACHE_CHECK(stack direction for C alloca, ac_cv_c_stack_direction,
@@ -28,10 +28,10 @@ diff -rupN --no-dereference 
gcc-10.3.1-20210422/libiberty/aclocal.m4 gcc-10.3.1-
  {
static char *addr = 0;
auto char dummy;
-diff -rupN --no-dereference gcc-10.3.1-20210422/libiberty/configure.ac 
gcc-10.3.1-20210422-new/libiberty/configure.ac
 gcc-10.3.1-20210422/libiberty/configure.ac 2021-04-22 19:22:55.0 
+0200
-+++ gcc-10.3.1-20210422-new/libiberty/configure.ac 2021-04-26 
18:35:17.591105242 +0200
-@@ -664,7 +664,7 @@ if test -z "${setobjs}"; then
+diff -ur gcc-11.1.1-20210428.old/libiberty/configure.ac 
gcc-11.1.1-20210428.new/libiberty/configure.ac
+--- gcc-11.1.1-20210428.old/libiberty/configure.ac 2021-04-28 
12:34:08.0 +0100
 gcc-11.1.1-20210428.new/libiberty/configure.ac 2021-04-29 
14:01:47.131662473 +0100
+@@ -665,7 +665,7 @@
for v in $vars; do
  AC_MSG_CHECKING([for $v])
  AC_CACHE_VAL(libiberty_cv_var_$v,
diff --git a/mingw-gcc.spec 

Re: Heads-up: RPM 4.17 alpha coming to rawhide near you

[Miro Hrončok]

On 29. 04. 21 14:23, Panu Matilainen wrote:

On 4/29/21 11:58 AM, Miro Hrončok wrote:

On 26. 04. 21 12:36, Panu Matilainen wrote:
It's spring, it's raining sleet where I live, and it's also the season for 
new rpm in rawhide. As per https://fedoraproject.org/wiki/Changes/RPM-4.17.


The changes to the macro subsystem internals have been quite large, and while 
it's supposed to be backwards compatible with changes this big it'd be 
foolish not to expect some amount of the unexpected. So please pay attention, 
and don't be shy about filing bugs.


Another regression found:

Convenient public macro %apply_patch removed without warning
https://bugzilla.redhat.com/show_bug.cgi?id=1954999



An intentional change does not classify as a regression in my books.


It is a matter of perspective: A sudden unannounced breakage of something that 
worked and appeared as part of the API classifies as regression in my books :)


The macro always was just an internal helper and intentionally entirely 
undocumented, just mistakenly lacking the preceding undrescores (but then 
neither of those ever stopped people from using "stuff").


It is documented in the macros file (very briefly), like all the other related 
macros.


We can make the change more visible, and we can consider temporary patches in 
Fedora, but %apply_patch is not an interface we want to support.


Let's deprecate it maybe in that case?

What is the supported alternative?

--
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: mingw-gcc to 11.1 ?

[Sandro Mani]

Hi Rich

Last attempt stranded on [1], I haven't tried since but looks like the 
bug is still open. If you want to give it a go, please do!


Many thanks
Sandro


[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97618

On 29.04.21 10:07, Richard W.M. Jones wrote:

Hi Sandro,

Are you planning to update mingw-gcc to 11.1?  The main gcc package
was updated to this version yesterday:

https://src.fedoraproject.org/rpms/gcc/commits/rawhide

If not, then I would like to do it if you have no objections.

Rich.


___
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: New RPM submission

[Joan Moreau via devel]

Thank you

Concretely, how to "find a sponsor" ?

On 2021-04-27 22:19, Emmanuel Seyman wrote:


* Joan Moreau [27/04/2021 20:51] :


Hi Emmanuel

I am trying my best to foloow the process but I get nowhere

Now I get a "koji" error ("AuthError: unable to obtain a session")


That looks like a recurring kerberos issue.

https://pagure.io/koji/issue/2063
https://pagure.io/releng/issue/7522

You probably want to contact releng to help solve this.

I tried "fedpkg request-repo --exception dovecot-fts-xapian" -> Lead 
some

error ("fedpkg request-repo --exception dovecot-fts-xapian")


Why is this package exempt from the review process?


I filed a "bug" on redhat :
https://bugzilla.redhat.com/show_bug.cgi?id=1953340

And now, how to get things moving ?


You need to seek out a sponsor:
https://fedoraproject.org/wiki/How_to_get_sponsored_into_the_packager_group


Isnt' there just a repo where to push the RPM ? (similar to Arch)


There is COPR but I suspect this is reserved to Fedora packagers so you
will still need to be sponsored.

https://fedoraproject.org/wiki/Category:Copr

Emmanuel
___
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: Heads-up: RPM 4.17 alpha coming to rawhide near you

[Panu Matilainen]

On 4/29/21 11:58 AM, Miro Hrončok wrote:

On 26. 04. 21 12:36, Panu Matilainen wrote:
It's spring, it's raining sleet where I live, and it's also the season 
for new rpm in rawhide. As per 
https://fedoraproject.org/wiki/Changes/RPM-4.17.


The changes to the macro subsystem internals have been quite large, 
and while it's supposed to be backwards compatible with changes this 
big it'd be foolish not to expect some amount of the unexpected. So 
please pay attention, and don't be shy about filing bugs.


Another regression found:

Convenient public macro %apply_patch removed without warning
https://bugzilla.redhat.com/show_bug.cgi?id=1954999



An intentional change does not classify as a regression in my books.
The macro always was just an internal helper and intentionally entirely 
undocumented, just mistakenly lacking the preceding undrescores (but 
then neither of those ever stopped people from using "stuff").


We can make the change more visible, and we can consider temporary 
patches in Fedora, but %apply_patch is not an interface we want to support.


- Panu -
___
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: Outreachy Final Application help

[Ngulefac Queeniva]

i updated the recent one even more and came up with this. pls review it sir 



Week 1-2
-Discussion with mentors team members and finalizing the approach of the 
project implementation
-Refactor Code: 
-making components more reusable, that is : Moving class components to separate 
files
-Make code look cleaner
-Translate untranslated words.


Week 3-4
-Restructure and order information on the landing page
-Make content on the page  more presentable, that is 
-using more infographics
-Changing the way the links and buttons look(making use of iconography)
-Including additional information and using familiar terms that could be easily 
understood by newcomers


Week 5-6
-Make the wizard section a lot more interactive and user  friendly by :
-Including proper navigations 
-Including clear instructions, code snippets and results where necessary.


Week 7-8
-Make user experience a lot better and also improve UI


Week 9-11
-Translate the application to the several new languages suggested
-Period for any pending task


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

Re: Spin maintainers attention required! Anaconda keyboard layout switching needs to change

[jkonecny]

Adding anaconda-devel list too.

On Thu, 2021-04-29 at 12:26 +0200, jkone...@redhat.com wrote:
> Hi everyone,
> 
> I've just filed a bug with all the details about the topic so we can
> start discussion there:
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1955025
> 
> 
> I gave a short summary here.
> 
> The libxklavier library will be deprecated from a future Fedora (it
> doesn't mean Fedora 35!). Anaconda and InitialSetup are using this
> library to be able to read and switch keyboard layouts. We need to
> find
> a proper replacement and for that I need to get ideas from Fedora
> Spin
> maintainers. I don't know your environment good enough to decide what
> would be best for your spin.
> 
> Please if you have an idea how to approach this issue. Tell us
> ideally
> in the bug. Thanks for everyone for your input!
> 
> 
> Best Regards,
> Jirka from Anaconda team
> 

___
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

Spin maintainers attention required! Anaconda keyboard layout switching needs to change

[jkonecny]

Hi everyone,

I've just filed a bug with all the details about the topic so we can
start discussion there:

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


I gave a short summary here.

The libxklavier library will be deprecated from a future Fedora (it
doesn't mean Fedora 35!). Anaconda and InitialSetup are using this
library to be able to read and switch keyboard layouts. We need to find
a proper replacement and for that I need to get ideas from Fedora Spin
maintainers. I don't know your environment good enough to decide what
would be best for your spin.

Please if you have an idea how to approach this issue. Tell us ideally
in the bug. Thanks for everyone for your input!


Best Regards,
Jirka from Anaconda team
___
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: The Death of Java (packages)

[Mikolaj Izdebski]

Hi Hans,

On Wed, Apr 28, 2021 at 3:47 PM Hans de Goede  wrote:
> Also I hope it is ok if I pick your brain a bit on a java
> packaging issue which I've been having.
>
> I maintain a couple of java leave packages (games) + some deps
> which AFAIK are only used by these games.
>
> One of these deps (dom4j) has been FTBFS since F34:
> https://bugzilla.redhat.com/show_bug.cgi?id=1923601
>
> I've been looking into this and the actual problem seems to
> be with Java 9 now including what once was the org.relaxng.datatype
> except they did not just bundle it, they also changed where it
> sits in the namespace to com.sun.tools.rngdatatype 
>
> Just doing a s/org.relaxng.datatype/com.sun.tools.rngdatatype/
> got me a bit further, but it seems that msv, which is a dep of
> dom4j needs to be rebuild first with the same search-replace
> done on it and the FTBFS bug of msv is stuck because of one
> of its deps getting orphaned+retired :
> https://bugzilla.redhat.com/show_bug.cgi?id=1923446
>
> So I think I can fix this by:
>
> 1. Unorphaning jvnet-parent, which is the missing msv dep

You can unorphan/unretire it, but removing dependency on jvnet-parent
is another choice. Probably better choice as jvnet-parent is no longer
developed or maintained by upstream.

> 2. Do a s/org.relaxng.datatype/com.sun.tools.rngdatatype/ in msv, rebuild
> 3. Do a s/org.relaxng.datatype/com.sun.tools.rngdatatype/ in dom4j, rebuild

relaxngDatatype was retired in Fedora. A replacement is
jaxb-relaxng-datatype package (built from jaxb source package), but it
uses a different namespace. Therefore steps 2 and 3 seem correct and
necessary.

> And then either do this only for rawhide, or push all 3 modified
> packages to F34 in a single bodhi update.
>
> Mikolaj, does this sounds like a reasonable plan to you; or
> should I approach this differently?

Yes, that sounds good. I would also double check to see whether
msv/dom4j are really needed by your packages.

> Also if yes this is a reasonable plan any advice on also
> pushing the fixed packages to F34, or not ?

I am in favor of F34 update. Users of dom4j/msv that do not rely on
relaxngDatatype-related functionality should be unaffected by the
update. Users that do rely on it would get it fixed.

>
> Regards,
>
> Hans
>
___
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

Fedora-Cloud-32-20210429.0 compose check report

[Fedora compose checker]

No missing expected images.

Soft failed openQA tests: 1/7 (x86_64), 1/7 (aarch64)
(Tests completed, but using a workaround for a known bug)

Old soft failures (same test soft failed in Fedora-Cloud-32-20210428.0):

ID: 873167  Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproject.org/tests/873167
ID: 873174  Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi
URL: https://openqa.fedoraproject.org/tests/873174

Passed openQA tests: 6/7 (x86_64), 6/7 (aarch64)
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
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-Legal-README.txt in installation media outdated?

[Miro Hrončok]

On 28. 04. 21 22:40, Kevin Fenzi wrote:

On Wed, Apr 28, 2021 at 02:12:15PM +0800, Qiyu Yan wrote:

If you download a Fedora 34 live iso at https://getfedora.org/
with filename: Fedora-Workstation-Live-x86_64-34-1.2.iso

Mount it and see Fedora-Legal-README.txt in the image. There are many
Fedora 31 things show up, should this file be updated on each release
cycle?

(Maybe not, unless someone like me mounts the iso file by mistake, and
check the Legal file by curiosity LOL)


It is. It's updated in the prep of fedora-release package, but perhaps
something went wrong and the image didn't get the updated version. :(


There is no updated version.

https://src.fedoraproject.org/rpms/fedora-release/history/Fedora-Legal-README.txt?identifier=rawhide

The text was not updated since Fedora 31.


--
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: RPM 4.17 alpha coming to rawhide near you

[Miro Hrončok]

On 26. 04. 21 12:36, Panu Matilainen wrote:
It's spring, it's raining sleet where I live, and it's also the season for new 
rpm in rawhide. As per https://fedoraproject.org/wiki/Changes/RPM-4.17.


The changes to the macro subsystem internals have been quite large, and while 
it's supposed to be backwards compatible with changes this big it'd be foolish 
not to expect some amount of the unexpected. So please pay attention, and don't 
be shy about filing bugs.


Another regression found:

Convenient public macro %apply_patch removed without warning
https://bugzilla.redhat.com/show_bug.cgi?id=1954999

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

Fedora-IoT-35-20210429.0 compose check report

[Fedora compose checker]

No missing expected images.

Failed openQA tests: 3/16 (x86_64), 2/15 (aarch64)

New failures (same test not failed in Fedora-IoT-35-20210411.0):

ID: 873134  Test: x86_64 IoT-dvd_ostree-iso iot_clevis
URL: https://openqa.fedoraproject.org/tests/873134
ID: 873135  Test: x86_64 IoT-dvd_ostree-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/873135
ID: 873136  Test: x86_64 IoT-dvd_ostree-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/873136
ID: 873151  Test: aarch64 IoT-dvd_ostree-iso install_default_upload@uefi
URL: https://openqa.fedoraproject.org/tests/873151

Old failures (same test failed in Fedora-IoT-35-20210411.0):

ID: 873150  Test: aarch64 IoT-dvd_ostree-iso iot_clevis@uefi
URL: https://openqa.fedoraproject.org/tests/873150

Skipped non-gating openQA tests: 26 of 31
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
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] Fedora-IoT 35 RC 20210429.0 nightly compose nominated for testing

[rawhide]

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

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

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

https://fedoraproject.org/wiki/Test_Results:Fedora-IoT_35_RC_20210429.0_Summary

The individual test result pages are:

https://fedoraproject.org/wiki/Test_Results:Fedora-IoT_35_RC_20210429.0_General

Thank you for testing!
-- 
Mail generated by relvalconsumer: https://pagure.io/fedora-qa/relvalconsumer
___
test-announce mailing list -- test-annou...@lists.fedoraproject.org
To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org
Do not reply to spam 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: Unretiring and maintaining the Fish Fillets NG game

[Kamil Paral]

On Thu, Apr 29, 2021 at 3:59 AM Nikolay Nikolov  wrote:

> What are the next steps for unretiring these two packages and
> maintaining them?
>

Hey Nikolay,
thanks for taking care of Fish Fillets, it's a great game (and also from my
country). Here I found the instructions for unretiring a package:
https://fedoraproject.org/wiki/Orphaned_package_that_need_new_maintainers#Claiming_Ownership_of_a_Retired_Package
___
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

Fedora-Cloud-33-20210429.0 compose check report

[Fedora compose checker]

No missing expected images.

Soft failed openQA tests: 1/7 (x86_64), 1/7 (aarch64)
(Tests completed, but using a workaround for a known bug)

Old soft failures (same test soft failed in Fedora-Cloud-33-20210428.0):

ID: 872895  Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproject.org/tests/872895
ID: 872902  Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi
URL: https://openqa.fedoraproject.org/tests/872902

Passed openQA tests: 6/7 (x86_64), 6/7 (aarch64)
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
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

mingw-gcc to 11.1 ?

[Richard W.M. Jones]

Hi Sandro,

Are you planning to update mingw-gcc to 11.1?  The main gcc package
was updated to this version yesterday:

https://src.fedoraproject.org/rpms/gcc/commits/rawhide

If not, then I would like to do it if you have no objections.

Rich.

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

Fedora-Rawhide-20210428.n.1 compose check report

[Fedora compose checker]

No missing expected images.

Compose FAILS proposed Rawhide gating check!
11 of 43 required tests failed
openQA tests matching unsatisfied gating requirements shown with **GATING** 
below

Failed openQA tests: 32/189 (x86_64), 26/127 (aarch64)

New failures (same test not failed in Fedora-Rawhide-20210425.n.0):

ID: 872321  Test: x86_64 Server-dvd-iso server_freeipa_replication_master
URL: https://openqa.fedoraproject.org/tests/872321
ID: 872325  Test: x86_64 Server-dvd-iso 
server_role_deploy_domain_controller **GATING**
URL: https://openqa.fedoraproject.org/tests/872325
ID: 872328  Test: x86_64 Server-dvd-iso install_vnc_client
URL: https://openqa.fedoraproject.org/tests/872328
ID: 872329  Test: x86_64 Server-dvd-iso server_realmd_join_kickstart 
**GATING**
URL: https://openqa.fedoraproject.org/tests/872329
ID: 872332  Test: x86_64 Server-dvd-iso modularity_tests
URL: https://openqa.fedoraproject.org/tests/872332
ID: 872333  Test: x86_64 Server-dvd-iso realmd_join_sssd **GATING**
URL: https://openqa.fedoraproject.org/tests/872333
ID: 872339  Test: x86_64 Server-dvd-iso server_freeipa_replication_replica
URL: https://openqa.fedoraproject.org/tests/872339
ID: 872342  Test: x86_64 Server-dvd-iso server_cockpit_updates
URL: https://openqa.fedoraproject.org/tests/872342
ID: 872345  Test: x86_64 Server-dvd-iso server_freeipa_replication_client
URL: https://openqa.fedoraproject.org/tests/872345
ID: 872347  Test: x86_64 Server-dvd-iso server_cockpit_basic
URL: https://openqa.fedoraproject.org/tests/872347
ID: 872349  Test: x86_64 Server-dvd-iso realmd_join_cockpit
URL: https://openqa.fedoraproject.org/tests/872349
ID: 872365  Test: x86_64 Workstation-live-iso desktop_login
URL: https://openqa.fedoraproject.org/tests/872365
ID: 872366  Test: x86_64 Workstation-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/872366
ID: 872379  Test: x86_64 KDE-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/872379
ID: 872424  Test: aarch64 Server-dvd-iso install_vnc_client@uefi
URL: https://openqa.fedoraproject.org/tests/872424
ID: 872437  Test: aarch64 Server-dvd-iso server_cockpit_basic@uefi
URL: https://openqa.fedoraproject.org/tests/872437
ID: 872445  Test: aarch64 Server-dvd-iso release_identification@uefi
URL: https://openqa.fedoraproject.org/tests/872445
ID: 872446  Test: aarch64 Server-dvd-iso 
server_role_deploy_domain_controller@uefi
URL: https://openqa.fedoraproject.org/tests/872446
ID: 872447  Test: aarch64 Server-dvd-iso realmd_join_cockpit@uefi
URL: https://openqa.fedoraproject.org/tests/872447
ID: 872450  Test: aarch64 Server-dvd-iso server_realmd_join_kickstart@uefi
URL: https://openqa.fedoraproject.org/tests/872450
ID: 872453  Test: aarch64 Server-dvd-iso modularity_tests@uefi
URL: https://openqa.fedoraproject.org/tests/872453
ID: 872456  Test: aarch64 Server-dvd-iso 
server_freeipa_replication_master@uefi
URL: https://openqa.fedoraproject.org/tests/872456
ID: 872459  Test: aarch64 Server-dvd-iso 
server_freeipa_replication_replica@uefi
URL: https://openqa.fedoraproject.org/tests/872459
ID: 872460  Test: aarch64 Server-dvd-iso realmd_join_sssd@uefi
URL: https://openqa.fedoraproject.org/tests/872460
ID: 872461  Test: aarch64 Server-dvd-iso 
server_freeipa_replication_client@uefi
URL: https://openqa.fedoraproject.org/tests/872461
ID: 872476  Test: aarch64 Workstation-raw_xz-raw.xz desktop_browser@uefi
URL: https://openqa.fedoraproject.org/tests/872476
ID: 872581  Test: aarch64 universal upgrade_2_server_domain_controller@uefi
URL: https://openqa.fedoraproject.org/tests/872581
ID: 872592  Test: aarch64 universal upgrade_server_domain_controller@uefi
URL: https://openqa.fedoraproject.org/tests/872592

Old failures (same test failed in Fedora-Rawhide-20210425.n.0):

ID: 872297  Test: x86_64 Server-boot-iso install_default **GATING**
URL: https://openqa.fedoraproject.org/tests/872297
ID: 872298  Test: x86_64 Server-boot-iso install_default@uefi **GATING**
URL: https://openqa.fedoraproject.org/tests/872298
ID: 872309  Test: x86_64 Server-dvd-iso install_vnc_server
URL: https://openqa.fedoraproject.org/tests/872309
ID: 872351  Test: x86_64 Everything-boot-iso memory_check@uefi
URL: https://openqa.fedoraproject.org/tests/872351
ID: 872352  Test: x86_64 Everything-boot-iso install_default **GATING**
URL: https://openqa.fedoraproject.org/tests/872352
ID: 872353  Test: x86_64 Everything-boot-iso install_default@uefi **GATING**
URL: https://openqa.fedoraproject.org/tests/872353
ID: 872417  Test: aarch64 Server-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/872417
ID: 872419  Test: aarch64 Server-dvd-iso install_vnc_server@uefi
URL: https://openqa.fedoraproject.org/tests/872419
ID: 872490  Test: x86_64 universal install_kickstart_firewall_disabled 
**GATING**
URL: https://openqa.fedoraproject.org/tests/872490
ID: 

Re: Where'd my package builds go?

[Otto Urpelainen]

Mamoru TASAKA kirjoitti 29.4.2021 klo 8.55:

Greg Hellings wrote on 2021/04/29 14:46:

So I built my package a few times for F34 in the Rawhide cycle (e.g.
https://bodhi.fedoraproject.org/updates/FEDORA-2020-90a4c6ba11)

It was rebuilt successfully by releng for F34 (e.g.
https://koji.fedoraproject.org/koji/buildinfo?buildID=1695213)

However, it does not appear in F34 in this version (1.9.0-3) but 
instead in
a version from 2 months before my last build and 4 months before the 
releng

build (1.9.0RC3-1 from last August). Neither do any of the newer builds
live in Rawhide.

What am I doing wrong that my package has happily built, but apparently
never made it into Rawhide or F34? Those later builds, up through 
1.9.0-2,
are in F33. Is there some additional step that's new in the F34 cycle 
that

I missed, that I need to do? I'm executing a rebuild of the package so I
can push it through Bodhi, but the previous versions also went through
there but never appeared on mirrors.

--Greg



I guess this is because "1.9.0RC3-1.fc34" is higher than "1.9.0-3.fc34" 
with

rpm versioning.

$ rpmdev-vercmp "1.9.0RC3-1.fc34" "1.9.0-3.fc34"
1.9.0RC3-1.fc34 > 1.9.0-3.fc34

You should have used "1.9.0-0.1.RC3" or "1.9.0~RC3-1.fc34".
If you want to upgrade to "1.9.0", you have to use epoch, or
you can wait for 1.9.1 to be released?


Just a note, these schemes are documented in the packaging guidelines:

https://docs.fedoraproject.org/en-US/packaging-guidelines/Versioning/
___
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: [Test-Announce] Fedora 35 Rawhide 20210428.n.1 nightly compose nominated for testing

[Luna Jernberg]

Workstation live & Server dvd ISOs work
Everything boot does not work

On Thu, Apr 29, 2021 at 6:03 AM  wrote:

> Announcing the creation of a new nightly release validation test event
> for Fedora 35 Rawhide 20210428.n.1. Please help run some tests for this
> nightly compose if you have time. For more information on nightly
> release validation testing, see:
> https://fedoraproject.org/wiki/QA:Release_validation_test_plan
>
> Test coverage information for the current release can be seen at:
> https://openqa.fedoraproject.org/testcase_stats/35
>
> You can see all results, find testing instructions and image download
> locations, and enter results on the Summary page:
>
>
> https://fedoraproject.org/wiki/Test_Results:Fedora_35_Rawhide_20210428.n.1_Summary
>
> The individual test result pages are:
>
>
> https://fedoraproject.org/wiki/Test_Results:Fedora_35_Rawhide_20210428.n.1_Installation
>
> https://fedoraproject.org/wiki/Test_Results:Fedora_35_Rawhide_20210428.n.1_Base
>
> https://fedoraproject.org/wiki/Test_Results:Fedora_35_Rawhide_20210428.n.1_Server
>
> https://fedoraproject.org/wiki/Test_Results:Fedora_35_Rawhide_20210428.n.1_Cloud
>
> https://fedoraproject.org/wiki/Test_Results:Fedora_35_Rawhide_20210428.n.1_Desktop
>
> https://fedoraproject.org/wiki/Test_Results:Fedora_35_Rawhide_20210428.n.1_Security_Lab
>
> Thank you for testing!
> --
> Mail generated by relvalconsumer:
> https://pagure.io/fedora-qa/relvalconsumer
> ___
> test-announce mailing list -- test-annou...@lists.fedoraproject.org
> To unsubscribe send an email to
> test-announce-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org
> Do not reply to spam 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
>
___
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