date:20210429

Re: Rewriting RPM macros using Lua

2021-04-29 Thread 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: plocate?

2021-04-29 Thread 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

Fedora-IoT-34-20210429.1 compose check report

2021-04-29 Thread 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

2021-04-29 Thread 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?

2021-04-29 Thread 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

2021-04-29 Thread 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: RPM name collisions

2021-04-29 Thread 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)

2021-04-29 Thread 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)

2021-04-29 Thread 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

2021-04-29 Thread 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

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

2021-04-29 Thread 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

RPM name collisions

2021-04-29 Thread 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

2021-04-29 Thread 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)

2021-04-29 Thread 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 dev

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

2021-04-29 Thread 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

Re: Unretiring and maintaining the Fish Fillets NG game

2021-04-29 Thread 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

Re: mingw-gcc to 11.1 ?

2021-04-29 Thread 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 ?

2021-04-29 Thread 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 ?

2021-04-29 Thread 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
 %{_libexecdir}/gcc/%{ming

Rewriting RPM macros using Lua

2021-04-29 Thread 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

2021-04-29 Thread 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 ?

2021-04-29 Thread 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

2021-04-29 Thread 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 ?

2021-04-29 Thread 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

2021-04-29 Thread 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

2021-04-29 Thread 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: Spin maintainers attention required! Anaconda keyboard layout switching needs to change

2021-04-29 Thread 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

2021-04-29 Thread 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)

2021-04-29 Thread 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

2021-04-29 Thread 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?

2021-04-29 Thread 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

2021-04-29 Thread 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

2021-04-29 Thread 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

2021-04-29 Thread 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

2021-04-29 Thread 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

2021-04-29 Thread 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 ?

2021-04-29 Thread 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

2021-04-29 Thread 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: 872

38 matches

Mail list logo