Update of rust-svgtypes

[Rémi Lauzier via devel]

Hi! I will push the update for rust-svgtypes, done in a sidetag, in two weeks 
unless there is an objection. A member of the rust-sig will have to update 
rust-ttf_parser. if need i can update rust-owned_ttf_parser too.

f36-build-side-47900
f35-build-side-47902
f34-build-side-47904

Sent with ProtonMail Secure Email.

publickey - remilauzier@protonmail.com - 0x0C8AA258.asc
Description: application/pgp-keys


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

Re: Firefox Hardware acceleration & VA-API how-to

[Michael Cronenworth]

On 11/15/21 12:03 PM, PGNet Dev wrote:


launch @ shell

VDPAU_DRIVER=nvidia MOZ_LOG="Dmabuf:5, PlatformDecoderModule:5" firefox 


I think you mean:

LIBVA_DRIVER_NAME=nvidia firefox

I gave this a shot today, but running a video crashes the tab. Yes, we are almost 
there, but the VA-API / VDPAU driver has not seen that much love.

___
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: LTO objects after build: Rebuilding vs erroring out

[Kevin Kofler via devel]

Jakub Jelinek wrote:
> Or if we recorded all command line options we care about into LTO bytecode
> (Optimization/Target options are recorded already on a per-function basis
> but I'm worried about others), just have a gcc driver mode that turns
> a non-fat LTO object into normal non-LTO object.

That sounds to me like the most reasonable thing to do. LTO bytecode is 
designed to be compiled to object code (at link time) after all, so why 
should it not be possible to convert (compile) it to an object code object 
file directly, without having to recompile the source file completely (with 
-fno-lto, the hack currently done for Clang)?

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: F37 Change: RetireARMv7 (System-Wide Change proposal)

[Kevin Kofler via devel]

Zbigniew Jędrzejewski-Szmek wrote:

> On Mon, Nov 15, 2021 at 02:15:49PM -0500, Ben Cotton wrote:
>> == User Experience ==
>> Any current users of Fedora on ARMv7 devices won't be able to upgrade
>> to Fedora 37, they will have to stay on Fedora 36 until it's EOL.
> 
> Please add "and will have to retire the hardware or move to a different
> distribution afterwards". Explicit is good.

Realistically, they will just stick to Fedora 36 forever and just stop 
updating the devices (or try updating them anyway and get no updates from 
the server, obviously).

Sticking an EOL label on a software release is not going to magically make 
it go away.

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: F36 Change: Remove Wire Extensions Support (Self-Contained Change proposal)

[Kevin Kofler via devel]

> == Owner ==
> * Name: [[User:pbrobinson| Peter Robinson]]

> https://fedoraproject.org/wiki/Changes/RemoveWirelessExtensions
> 
> == Summary ==
> The legacy wireless extensions interface was replaced by the new
> mac80211/cfg80211 interface in 2007. The legacy Wireless Extensions
> support has been long deprecated and only supports long EOL WiFi
> encryption like WEP so it's time to disable it and remove it.

I do not believe that the assertion around encryption is true, unless 
wpa_supplicant has dropped support for the legacy interface over the years. 
I remember having used some legacy wext drivers with wpa_supplicant and WPA 
(maybe even WPA2) before everything was ported to mac80211 (the "DeviceScape 
stack" as it was called at the time). And https://w1.fi/wpa_supplicant/ 
lists not only "Linux drivers that support nl80211/cfg80211 (most new 
drivers)", but also "Linux drivers that support Linux Wireless Extensions 
v19 or newer with WPA/WPA2 extensions" as supported.

(For the record, I also remember my old Pentium II "notebook" (more like a 
thick laptop) taking a day or two to build a custom kernel with the 
DeviceScape/mac80211 stack that was not easily buildable out of tree, in 
order to build and use the Free-as-in-speech driver for a Broadcom PCMCIA 
WiFi card, but that is off topic. ;-) )

There were also some drivers implementing WPA on their own, or letting the 
hardware or firmware do it, in particular, Ralink's GPLed vendor driver. Of 
course, those nonstandard wext commands were not supported by 
NetworkManager, so I had to use a custom shell script. The driver was 
eventually replaced by the rt2x00 community rewrite that relies on 
wpa_supplicant and that was soon ported to mac80211. But I am pretty sure I 
also used a wext version of rt2x00 with wpa_supplicant at some point.

> The Wireless Extensions support in the kernel has been long replaced
> by the mac80211/cfg80211 support. Disable the kernel options and
> retire the wireless-tools userspace utilities. Wireless Extensions
> only supports a minor subset of the wireless interfaces, predominently
> the WEP interface and userspace has been replaced by iw/libnl/ip
> interfaces which offer a lot more advanced features as well as modern
> 802.11 functionality like WPA.

Users are going to miss the iwconfig tool. Not only is it still being used 
out of habit (just like ifconfig from net-tools), but (also just like 
ifconfig) it is also much more user-friendly. E.g., running "iwconfig" 
without arguments prints a nice summary of the wireless devices and their 
properties, such as access point ESSID and BSSID, bit rate, signal level, 
etc., whereas running "iw" without arguments prints a 132-line help output 
with around a hundred different commands (with no explanation as to what 
they do, as that would require even more than 132 lines: the --help output 
is 445 lines long). "iw" also exposes implementation details in the most 
unfriendly way, by requiring the user to use "dev ", "phy 
", "wdev ", or "reg" prefixes depending on the individual 
command (and it is entirely unclear to the user why something is a dev 
property, a phy property, or both), whereas "iwconfig" takes the same 
interface name for all commands.

The new ip, iw, and route tools have clearly been designed by kernel 
developers for kernel developers, not for end users or even system 
administrators. The old ifconfig and iwconfig are much easier to use.

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: F37 Change: RetireARMv7 (System-Wide Change proposal)

[Peter Robinson]

On Tue, Nov 16, 2021 at 8:10 PM Peter Boy  wrote:
>
>
>
> > Am 16.11.2021 um 20:37 schrieb Miro Hrončok :
> >
> > On 15. 11. 21 20:15, Ben Cotton wrote:
> >> https://fedoraproject.org/wiki/Changes/RetireARMv7
> >> == Owner ==
> >> * Name: [[User:pbrobinson| Peter Robinson]]
> >> * Email: 
> >
> > May I suggest to include 
> > https://lists.fedoraproject.org/archives/list/a...@lists.fedoraproject.org/thread/YC2LYBJSFKDAVBUJAIFQCCBS5VLW5TUB/
> >  in the feedback section (which is entirely missing from this proposal)?
>
> I've only been dealing with Arm SBC boards for a short time and therefore 
> only with aarch64 and certainly don't know many details yet.
>
> A big advantage of Linux is that older hardware is supported for a long time 
> and is still usable. This is almost a "trademark“.
>
> Therefore my question, would it reduce the effort already noticeably, if you 
> reduce armv7 to "server" (and evtl IoT), i.e. without all the graphical 
> interfaces? And without new, additional functionality, just security fixes? A 
> kind of „maintenance mode“?
>
> This could (hopefully) solve a number of problems raised by various 
> contributors to the discussion (and preserve the „trademark").

We've basically already done that, the amount of desktop images
produced has reduced over time, and the main focus for some time has
already been IoT/Server etc. We basically don't block on DEs any more.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: RetireARMv7 (System-Wide Change proposal)

[Peter Boy]

> Am 16.11.2021 um 21:23 schrieb Stephen John Smoogen :
> 
> 
> 
> On Tue, Nov 16, 2021 at 15:10 Peter Boy  wrote:
> 
> ...
> This could (hopefully) solve a number of problems raised by various 
> contributors to the discussion (and preserve the „trademark").
> 
> 
> The main problem is that armv7 is currently built on a set of AARCh64 dual 
> instruction CPU systems from AMPERE. These boxes can run VM’s of armv7 
> instructions and allow us to do builds for Fedora. They are also the way that 
> what few QA tests can be done are done. These systems are also no longer 
> built, and the newer systems are AARCH64 only. 
> 
> While it is possible to run ARM via QEMU emulation, this is mainly ‘for 
> demonstration purposes’ only. The QEMU emulation is about 4 times to 20 times 
> slower than native running and can lock and crash on non-reproducible faults 
> regularly. Because failed servers cause ALL koji architectures to fail a 
> build.. it would mean a lot of crashed builds for an architecture we can’t 
> regularly debug. 
> 
> Fedora does not do cross compilation so that is not a way out of this either. 
> 
> These are the major reasons for retiring the armv7 architecture with the hope 
> they are retired before we end up with no builders in the middle of a 
> release. 

Oh, I see, packages and their number are the least of the problems here.  
Thanks.

Peter

___
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: RFC: Reduce number of packages that are built for i686

[Fabio Valentini]

On Tue, Nov 16, 2021 at 9:27 PM Miro Hrončok  wrote:
>
> On 16. 11. 21 20:47, Fabio Valentini wrote:
> > Hi everybody,
> >
> > The announcement of the Change proposal to drop armv7 support with F37
> > has reminded me of something that I wanted to ask about some time ago:
> > How we could work towards reducing the number of packages we build for
> > i686.
> >
> > Our current approach, which is to "build everything but ship almost
> > nothing" - just to keep x86_64 / i686 multilib working - is, frankly,
> > very wasteful of computing and storage resources, as well as a burden
> > on maintainers of big packages, which frequently run up against limits
> > of 32-bit architectures.
> >
> > I think it should be possible to figure out a way to limit the number
> > of packages that need to be built for the common multilib usecases
> > (Wine + Steam ... am I forgetting something?), and just ... not build
> > anything else for i686.
>
> Have you seen this discussion?
>
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/TDDNEGF3PGCSIXITSIINUTZTFBSK4HGK/
>
> > This would probably involve the following steps:
> >
> > 1. determine the packages that need to be built on i686 for common
> > multilib scenarios
> > 2. determine recursive install-time and build-time dependencies of
> > those packages
> > 3. if necessary, update this list with any new build-or install-time
> > dependencies that are added to the package set
> >
> > As for how to implement this, I'm not sure about the details yet
> > (which is why I'm sending this as an RFC and not filing a Change
> > proposal yet).
>
> See for example my idea for implementation:
>
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/A5II3GGIDUDVCWLRZ6AXGAA4WWJH6VSN/
>
> However, I am not sure it is worth the trouble.

Yes, I remember that thread, but I thought it was started longer than
just two months ago ... time flies :|

The steps you outlined in your linked message mostly align with what I
was thinking of, as well. However, I don't think that we should just
keep *all* multilib packages, as most of them aren't needed or used at
all.

I already have a script lying around for resolving dependency trees
across both build- and runtime requires, so I could reuse them for the
purpose of determining the initial "minimal i686 core", considering
which packages get pulled in by, for example, wine + steam. I can
compute that list of packages, if it would help for the discussion.

As for "So it goes back to -- is it worth to burn people-energy on
this when we can just burn machine-energy?", I'd say, it's worth it,
considering that I myself am already head-butting my desk frequently
because of i686 build issues, so I'd consider this a worthwhile effort
indeed, especially since this problem isn't going away anytime soon
(and is probably only going to get worse). I'd even volunteer to
maintain that list and help with bootstrapping new i686 dependencies
...

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

Re: Long-running side tag for porting Fedora to C99 (no implicit decls)

[Miro Hrončok]

On 16. 11. 21 21:23, Fabio Valentini wrote:

On Fri, Nov 12, 2021 at 10:06 PM Kevin Fenzi  wrote:


On Wed, Nov 10, 2021 at 09:47:47AM +0100, Florian Weimer wrote:

* Kevin Fenzi:


On Tue, Nov 09, 2021 at 10:41:16AM +0100, Florian Weimer wrote:

* Kevin Fenzi:


Isn't this an ideal use case for copr?


I don't know.  I could piece together the Koji API fairly easily, and
had hoped to reuse some of the script logic.

Or does COPR have direct support this?  Can I tell it directly to report
rawhide in a special buildroot?  Is there a programmatic way to access
the resulting log files?

(I won't need the built RPMs, which is why I would use scratch builds in
Koji.)


Yes, copr has a api also.
https://python-copr.readthedocs.io/en/latest/ClientV3.html


Is there an overview similar to ?
It's hard to tell what the capbilities are.


I'm not sure and I was hoping one of the copr folks would chime in. ;)

CCing praiskup


I'm pretty sure the Python team is doing something very similar for
their Python, Sphinx, etc. rebase test build COPRs, like this one for
Python 3.10:
https://copr.fedorainfracloud.org/coprs/g/python/python3.10/

They're set up so that any dist-git commits (and PRs) are
automatically rebuilt in that COPR.
The COPR command-line tool (copr-cli) provides all commands that are
needed to set that up, as far as I know - so the copr python module
should do that, too.


The one for Python 3.10 has the automation already disabled, but there's one 
for Python 3.11 now:


https://copr.fedorainfracloud.org/coprs/g/python/python3.11/

One advantage of this automation is that any Pull Request to rawhide branch of 
tracked packages appears as a result in that Copr as well (the build is 
isolated from the others, similarly to Koji scratch-builds).


--
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: RFC: Reduce number of packages that are built for i686

[Miro Hrončok]

On 16. 11. 21 20:47, Fabio Valentini wrote:

Hi everybody,

The announcement of the Change proposal to drop armv7 support with F37
has reminded me of something that I wanted to ask about some time ago:
How we could work towards reducing the number of packages we build for
i686.

Our current approach, which is to "build everything but ship almost
nothing" - just to keep x86_64 / i686 multilib working - is, frankly,
very wasteful of computing and storage resources, as well as a burden
on maintainers of big packages, which frequently run up against limits
of 32-bit architectures.

I think it should be possible to figure out a way to limit the number
of packages that need to be built for the common multilib usecases
(Wine + Steam ... am I forgetting something?), and just ... not build
anything else for i686.


Have you seen this discussion?

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


This would probably involve the following steps:

1. determine the packages that need to be built on i686 for common
multilib scenarios
2. determine recursive install-time and build-time dependencies of
those packages
3. if necessary, update this list with any new build-or install-time
dependencies that are added to the package set

As for how to implement this, I'm not sure about the details yet
(which is why I'm sending this as an RFC and not filing a Change
proposal yet).


See for example my idea for implementation:

https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/A5II3GGIDUDVCWLRZ6AXGAA4WWJH6VSN/

However, I am not sure it is worth the trouble.

--
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: Long-running side tag for porting Fedora to C99 (no implicit decls)

[Fabio Valentini]

On Fri, Nov 12, 2021 at 10:06 PM Kevin Fenzi  wrote:
>
> On Wed, Nov 10, 2021 at 09:47:47AM +0100, Florian Weimer wrote:
> > * Kevin Fenzi:
> >
> > > On Tue, Nov 09, 2021 at 10:41:16AM +0100, Florian Weimer wrote:
> > >> * Kevin Fenzi:
> > >>
> > >> > Isn't this an ideal use case for copr?
> > >>
> > >> I don't know.  I could piece together the Koji API fairly easily, and
> > >> had hoped to reuse some of the script logic.
> > >>
> > >> Or does COPR have direct support this?  Can I tell it directly to report
> > >> rawhide in a special buildroot?  Is there a programmatic way to access
> > >> the resulting log files?
> > >>
> > >> (I won't need the built RPMs, which is why I would use scratch builds in
> > >> Koji.)
> > >
> > > Yes, copr has a api also.
> > > https://python-copr.readthedocs.io/en/latest/ClientV3.html
> >
> > Is there an overview similar to ?
> > It's hard to tell what the capbilities are.
>
> I'm not sure and I was hoping one of the copr folks would chime in. ;)
>
> CCing praiskup

I'm pretty sure the Python team is doing something very similar for
their Python, Sphinx, etc. rebase test build COPRs, like this one for
Python 3.10:
https://copr.fedorainfracloud.org/coprs/g/python/python3.10/

They're set up so that any dist-git commits (and PRs) are
automatically rebuilt in that COPR.
The COPR command-line tool (copr-cli) provides all commands that are
needed to set that up, as far as I know - so the copr python module
should do that, too.

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

Re: F37 Change: RetireARMv7 (System-Wide Change proposal)

[Stephen John Smoogen]

On Tue, Nov 16, 2021 at 15:10 Peter Boy  wrote:

>
>
> > Am 16.11.2021 um 20:37 schrieb Miro Hrončok :
> >
> > On 15. 11. 21 20:15, Ben Cotton wrote:
> >> https://fedoraproject.org/wiki/Changes/RetireARMv7
> >> == Owner ==
> >> * Name: [[User:pbrobinson| Peter Robinson]]
> >> * Email: 
> >
> > May I suggest to include
> https://lists.fedoraproject.org/archives/list/a...@lists.fedoraproject.org/thread/YC2LYBJSFKDAVBUJAIFQCCBS5VLW5TUB/
> in the feedback section (which is entirely missing from this proposal)?
>
> I've only been dealing with Arm SBC boards for a short time and therefore
> only with aarch64 and certainly don't know many details yet.
>
> A big advantage of Linux is that older hardware is supported for a long
> time and is still usable. This is almost a "trademark“.
>
> Therefore my question, would it reduce the effort already noticeably, if
> you reduce armv7 to "server" (and evtl IoT), i.e. without all the graphical
> interfaces? And without new, additional functionality, just security fixes?
> A kind of „maintenance mode“?
>
> This could (hopefully) solve a number of problems raised by various
> contributors to the discussion (and preserve the „trademark").



The main problem is that armv7 is currently built on a set of AARCh64 dual
instruction CPU systems from AMPERE. These boxes can run VM’s of armv7
instructions and allow us to do builds for Fedora. They are also the way
that what few QA tests can be done are done. These systems are also no
longer built, and the newer systems are AARCH64 only.

While it is possible to run ARM via QEMU emulation, this is mainly ‘for
demonstration purposes’ only. The QEMU emulation is about 4 times to 20
times slower than native running and can lock and crash on non-reproducible
faults regularly. Because failed servers cause ALL koji architectures to
fail a build.. it would mean a lot of crashed builds for an architecture we
can’t regularly debug.

Fedora does not do cross compilation so that is not a way out of this
either.

These are the major reasons for retiring the armv7 architecture with the
hope they are retired before we end up with no builders in the middle of a
release.



> ___
> 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
>
-- 
Stephen J Smoogen.
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren
___
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: RFC: Reduce number of packages that are built for i686

[Jason L Tibbitts III]

> Robbie Harwood  writes:

> Fabio Valentini  writes:
>> Since it's not practical to modify almost all Fedora packages to add
>> "ExcludeArch: %{ix86}" to them, we'd probably need a different
>> machanism for this.

> Is it really not?  This seems the easiest way to go about it, honestly
> - just have it be permitted for maintainers to opt their stuff out of
> building on x86 and let the problem take care of itself recursively.

I have to say that it would be nicer if building for i686 were opt-in
instead of opt-out.  Just figure out what we really need to build to
support the few things we want to support, let maintainers build
additional things if they want to do so, and have a mechanism for asking
someone to add an i686 build.

Basically not much different from EPEL.

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

Re: F37 Change: RetireARMv7 (System-Wide Change proposal)

[Peter Boy]

> Am 16.11.2021 um 20:37 schrieb Miro Hrončok :
> 
> On 15. 11. 21 20:15, Ben Cotton wrote:
>> https://fedoraproject.org/wiki/Changes/RetireARMv7
>> == Owner ==
>> * Name: [[User:pbrobinson| Peter Robinson]]
>> * Email: 
> 
> May I suggest to include 
> https://lists.fedoraproject.org/archives/list/a...@lists.fedoraproject.org/thread/YC2LYBJSFKDAVBUJAIFQCCBS5VLW5TUB/
>  in the feedback section (which is entirely missing from this proposal)?

I've only been dealing with Arm SBC boards for a short time and therefore only 
with aarch64 and certainly don't know many details yet.

A big advantage of Linux is that older hardware is supported for a long time 
and is still usable. This is almost a "trademark“.  

Therefore my question, would it reduce the effort already noticeably, if you 
reduce armv7 to "server" (and evtl IoT), i.e. without all the graphical 
interfaces? And without new, additional functionality, just security fixes? A 
kind of „maintenance mode“?

This could (hopefully) solve a number of problems raised by various 
contributors to the discussion (and preserve the „trademark").
___
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: RFC: Reduce number of packages that are built for i686

[Robbie Harwood]

Fabio Valentini  writes:

> Since it's not practical to modify almost all Fedora packages to add
> "ExcludeArch: %{ix86}" to them, we'd probably need a different
> machanism for this. I have a vague idea:

Is it really not?  This seems the easiest way to go about it, honestly -
just have it be permitted for maintainers to opt their stuff out of
building on x86 and let the problem take care of itself recursively.

Be well,
--Robbie


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

RFC: Reduce number of packages that are built for i686

[Fabio Valentini]

Hi everybody,

The announcement of the Change proposal to drop armv7 support with F37
has reminded me of something that I wanted to ask about some time ago:
How we could work towards reducing the number of packages we build for
i686.

Our current approach, which is to "build everything but ship almost
nothing" - just to keep x86_64 / i686 multilib working - is, frankly,
very wasteful of computing and storage resources, as well as a burden
on maintainers of big packages, which frequently run up against limits
of 32-bit architectures.

I think it should be possible to figure out a way to limit the number
of packages that need to be built for the common multilib usecases
(Wine + Steam ... am I forgetting something?), and just ... not build
anything else for i686.

This would probably involve the following steps:

1. determine the packages that need to be built on i686 for common
multilib scenarios
2. determine recursive install-time and build-time dependencies of
those packages
3. if necessary, update this list with any new build-or install-time
dependencies that are added to the package set

As for how to implement this, I'm not sure about the details yet
(which is why I'm sending this as an RFC and not filing a Change
proposal yet).

Since it's not practical to modify almost all Fedora packages to add
"ExcludeArch: %{ix86}" to them, we'd probably need a different
machanism for this. I have a vague idea:

- include the list of packages to be built ... somewhere (maybe in the
default buildroot?)
- if a package name matches a list entry, build it on i686. if it
doesn't, then don't.

As for the second step, I'm not sure how to do that yet - does
injecting ExcludeArch headers at SRPM build time in koji work, maybe
with some RPM macro that's included in every package anyway? Or could
we somehow influence the chroots that builds in koji are launched for?
Then the spec or SRPM wouldn't even have to be modified.

As I said, I'm not sure about the details yet, but we should be able
to figure out a way to do this, and make building Fedora packages less
wasteful. Consider this my "request for comments". :)

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

Re: F37 Change: RetireARMv7 (System-Wide Change proposal)

[Miro Hrončok]

On 15. 11. 21 20:15, Ben Cotton wrote:

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

== Owner ==
* Name: [[User:pbrobinson| Peter Robinson]]
* Email: 


May I suggest to include 
https://lists.fedoraproject.org/archives/list/a...@lists.fedoraproject.org/thread/YC2LYBJSFKDAVBUJAIFQCCBS5VLW5TUB/ 
in the feedback section (which is entirely missing from this proposal)?


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

Re: libnsl.so.2.0.1 updated to libnsl.so.3.0.0 without coordination, broke rawhide

[Björn 'besser82' Esser]

Am Dienstag, dem 16.11.2021 um 15:32 +0100 schrieb Miro Hrončok:
> On 13. 11. 21 11:03, Björn 'besser82' Esser wrote:
> > Am Freitag, dem 12.11.2021 um 21:33 +0100 schrieb Björn 'besser82'
> > Esser:
> > > Am Donnerstag, dem 11.11.2021 um 15:54 +0100 schrieb Miro Hrončok:
> > > > Hello,
> > > > 
> > > > Since this update:
> > > > 
> > > > https://src.fedoraproject.org/rpms/libnsl2/c/d2e2fab5e3ab07228a34f35ab8ec1954581153d0?branch=rawhide
> > > > 
> > > > Nothing in rawhide builds, because Python and hence dnf is not
> > > > installable:
> > > > 
> > > > Error:
> > > >    Problem 1: package python3-dnf-4.10.0-1.fc36.noarch requires
> > > > python3-libdnf,
> > > > but none of the providers can be installed
> > > >     - package python3-dnf-4.10.0-1.fc36.noarch requires python3-
> > > > libdnf
> > > > > =
> > > > 0.65.0, but none of the providers can be installed
> > > >     - package dnf-4.10.0-1.fc36.noarch requires python3-dnf =
> > > > 4.10.0-
> > > > 1.fc36, but
> > > > none of the providers can be installed
> > > >     - package python3-libdnf-0.65.0-1.fc36.ppc64le requires
> > > > libpython3.10.so.1.0()(64bit), but none of the providers can be
> > > > installed
> > > >     - conflicting requests
> > > >     - nothing provides libnsl.so.2()(64bit) needed by
> > > > python3-libs-3.10.0-3.fc36.ppc64le
> > > >     - nothing provides libnsl.so.2(LIBNSL_1.0)(64bit) needed by
> > > > python3-libs-3.10.0-3.fc36.ppc64le
> > > >    Problem 2: package python3-dnf-plugins-core-4.0.24-
> > > > 1.fc36.noarch
> > > > requires
> > > > python3-hawkey >= 0.46.1, but none of the providers can be
> > > > installed
> > > >     - package dnf-plugins-core-4.0.24-1.fc36.noarch requires
> > > > python3-dnf-plugins-core = 4.0.24-1.fc36, but none of the
> > > > providers
> > > > can be
> > > > installed
> > > >     - package python3-hawkey-0.65.0-1.fc36.ppc64le requires
> > > > libpython3.10.so.1.0()(64bit), but none of the providers can be
> > > > installed
> > > >     - conflicting requests
> > > >     - nothing provides libnsl.so.2()(64bit) needed by
> > > > python3-libs-3.10.0-3.fc36.ppc64le
> > > >     - nothing provides libnsl.so.2(LIBNSL_1.0)(64bit) needed by
> > > > python3-libs-3.10.0-3.fc36.ppc64le
> > > > (try to add '--skip-broken' to skip uninstallable packages)
> > > > 
> > > > 
> > > > Additionally, the following packages (and everything that
> > > > depends on
> > > > them) will
> > > > fail to install:
> > > > 
> > > > $ repoquery -q --repo=rawhide --whatrequires
> > > > 'libnsl.so.2()(64bit)'
> > > > autofs-1:5.1.8-1.fc36.x86_64
> > > > exim-0:4.95-1.fc36.x86_64
> > > > exim-mon-0:4.95-1.fc36.x86_64
> > > > libnsl2-devel-0:1.3.0-4.fc35.x86_64
> > > > nss_nis-0:3.1-9.fc35.x86_64
> > > > pam-0:1.5.2-6.fc36.x86_64
> > > > postfix-2:3.6.2-6.fc36.x86_64
> > > > python2.7-0:2.7.18-15.fc36.x86_64
> > > > python3-debug-0:3.10.0-2.fc36.x86_64
> > > > python3-libs-0:3.10.0-2.fc36.x86_64
> > > > python3.11-0:3.11.0~a1-1.fc36.x86_64
> > > > python3.6-0:3.6.15-2.fc36.x86_64
> > > > python3.7-0:3.7.12-2.fc36.x86_64
> > > > python3.8-0:3.8.12-2.fc36.x86_64
> > > > python3.9-0:3.9.8-1.fc36.x86_64
> > > > rwall-0:0.17-60.fc35.x86_64
> > > > rwall-server-0:0.17-60.fc35.x86_64
> > > > sendmail-0:8.17.1-2.fc36.x86_64
> > > > slapi-nis-0:0.56.7-2.fc35.x86_64
> > > > tcp_wrappers-0:7.6-98.fc35.x86_64
> > > > tcp_wrappers-libs-0:7.6-98.fc35.x86_64
> > > > yp-tools-0:4.2.3-10.fc35.x86_64
> > > > ypbind-3:2.7.2-5.fc35.x86_64
> > > > ypserv-0:4.2-1.fc36.x86_64
> > > > 
> > > > I've requested the package to be untagged:
> > > > 
> > > > https://pagure.io/releng/issue/10380
> > > > 
> > > > This change needs to be coordinated.
> > > 
> > > 
> > > I can take care to coordinate the rebuilds in a side-tag, if you
> > > don't
> > > mind.
> > > 
> > > Thanks,
> > > Björn
> > 
> > 
> > All required rebuilds have finished successfully and the side-tag is
> > merged with Rawhide.
> > 
> > https://bodhi.fedoraproject.org/updates/FEDORA-2021-bc52d69ab2
> 
> Thanks you very much for doing this, Björn, you are awesome!

You're welcome!  =)


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

FedoraRespin-35-updates-20211115.0 compose check report

[Fedora compose checker]

No missing expected images.

Failed openQA tests: 2/45 (x86_64)

ID: 1065763 Test: x86_64 KDE-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/1065763
ID: 1065771 Test: x86_64 KDE-live-iso desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/1065771

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

ID: 1065751 Test: x86_64 Workstation-live-iso gedit
URL: https://openqa.fedoraproject.org/tests/1065751

Passed openQA tests: 42/45 (x86_64)
-- 
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: libnsl.so.2.0.1 updated to libnsl.so.3.0.0 without coordination, broke rawhide

[Miro Hrončok]

On 13. 11. 21 11:03, Björn 'besser82' Esser wrote:

Am Freitag, dem 12.11.2021 um 21:33 +0100 schrieb Björn 'besser82'
Esser:

Am Donnerstag, dem 11.11.2021 um 15:54 +0100 schrieb Miro Hrončok:

Hello,

Since this update:

https://src.fedoraproject.org/rpms/libnsl2/c/d2e2fab5e3ab07228a34f35ab8ec1954581153d0?branch=rawhide

Nothing in rawhide builds, because Python and hence dnf is not
installable:

Error:
   Problem 1: package python3-dnf-4.10.0-1.fc36.noarch requires
python3-libdnf,
but none of the providers can be installed
    - package python3-dnf-4.10.0-1.fc36.noarch requires python3-libdnf

=

0.65.0, but none of the providers can be installed
    - package dnf-4.10.0-1.fc36.noarch requires python3-dnf = 4.10.0-
1.fc36, but
none of the providers can be installed
    - package python3-libdnf-0.65.0-1.fc36.ppc64le requires
libpython3.10.so.1.0()(64bit), but none of the providers can be
installed
    - conflicting requests
    - nothing provides libnsl.so.2()(64bit) needed by
python3-libs-3.10.0-3.fc36.ppc64le
    - nothing provides libnsl.so.2(LIBNSL_1.0)(64bit) needed by
python3-libs-3.10.0-3.fc36.ppc64le
   Problem 2: package python3-dnf-plugins-core-4.0.24-1.fc36.noarch
requires
python3-hawkey >= 0.46.1, but none of the providers can be installed
    - package dnf-plugins-core-4.0.24-1.fc36.noarch requires
python3-dnf-plugins-core = 4.0.24-1.fc36, but none of the providers
can be
installed
    - package python3-hawkey-0.65.0-1.fc36.ppc64le requires
libpython3.10.so.1.0()(64bit), but none of the providers can be
installed
    - conflicting requests
    - nothing provides libnsl.so.2()(64bit) needed by
python3-libs-3.10.0-3.fc36.ppc64le
    - nothing provides libnsl.so.2(LIBNSL_1.0)(64bit) needed by
python3-libs-3.10.0-3.fc36.ppc64le
(try to add '--skip-broken' to skip uninstallable packages)


Additionally, the following packages (and everything that depends on
them) will
fail to install:

$ repoquery -q --repo=rawhide --whatrequires 'libnsl.so.2()(64bit)'
autofs-1:5.1.8-1.fc36.x86_64
exim-0:4.95-1.fc36.x86_64
exim-mon-0:4.95-1.fc36.x86_64
libnsl2-devel-0:1.3.0-4.fc35.x86_64
nss_nis-0:3.1-9.fc35.x86_64
pam-0:1.5.2-6.fc36.x86_64
postfix-2:3.6.2-6.fc36.x86_64
python2.7-0:2.7.18-15.fc36.x86_64
python3-debug-0:3.10.0-2.fc36.x86_64
python3-libs-0:3.10.0-2.fc36.x86_64
python3.11-0:3.11.0~a1-1.fc36.x86_64
python3.6-0:3.6.15-2.fc36.x86_64
python3.7-0:3.7.12-2.fc36.x86_64
python3.8-0:3.8.12-2.fc36.x86_64
python3.9-0:3.9.8-1.fc36.x86_64
rwall-0:0.17-60.fc35.x86_64
rwall-server-0:0.17-60.fc35.x86_64
sendmail-0:8.17.1-2.fc36.x86_64
slapi-nis-0:0.56.7-2.fc35.x86_64
tcp_wrappers-0:7.6-98.fc35.x86_64
tcp_wrappers-libs-0:7.6-98.fc35.x86_64
yp-tools-0:4.2.3-10.fc35.x86_64
ypbind-3:2.7.2-5.fc35.x86_64
ypserv-0:4.2-1.fc36.x86_64

I've requested the package to be untagged:

https://pagure.io/releng/issue/10380

This change needs to be coordinated.



I can take care to coordinate the rebuilds in a side-tag, if you don't
mind.

Thanks,
Björn



All required rebuilds have finished successfully and the side-tag is
merged with Rawhide.

https://bodhi.fedoraproject.org/updates/FEDORA-2021-bc52d69ab2


Thanks you very much for doing this, Björn, you are awesome!

--
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: Keeping track of inconsistent backports

[Felix Schwarz]

Hi,

I have a similar problem (but on a much smaller scale): The certbot stack 
comprises ~ a dozen packages which should be updated in lockstep. We push the 
same version to all supported Fedora releases + EPEL (mostly).


To do that somewhat efficiently I built/extended some scripts:
https://github.com/FelixSchwarz/fedpkgscripts

Basically these handle issues like:
- merge a branch to N other branches
- push git changes in N branches
- build branch X for N packages (either in mock, in COPR or with koji)
- check for unpushed/uncommitted changes in a repo
- pull git changes for N packages
- set the new version in a spec file based on bugzilla queries, download the new
  sources, verify with gpg and run "fedpkg new-sources" if verification is
  successful
+ some other stuff I probably just did not remember

currently really a lot of "ad hoc" code but I'd be happy to contribute to a 
common set of tools :-)


Felix
___
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: Keeping track of inconsistent backports

[Major Hayden]

On 11/15/21 14:48, Fabio Valentini wrote:

I don't really have a solution here, but I'd be interested in looking
at this problem.

For example, most* [1] packages in the Rust stack will have (and
should! have) the same versions across all supported Fedora branches.
For any Rust packages that I push updates for, I update them right
away across all branches, and that works very well to prevent me from
forgetting things.
However, any "newcomers" (or contributors who are more easily
distracted than me) will often mess that up, making it hard for me
(main Rust stack maintainer right now) to keep things aligned when I
update other packages.


I'm glad to know I am not alone! I started down a path of writing a 
script that does something like this:


1) Scrape pagure's API to get all of my RPM repositories
2) Request the bodhi update versions for the package
3) Remove the ".fc##" from the version numbers
4) Examine the latest available versions for each release and highlight 
differences


Step #1 takes 1 API request per 100 packages (which is 3 API requests 
for me), but #2 requires one API request per package. I feel like 
someone's going to be upset with me eventually for running so many API 
calls. 😠


I thought Koschei might be able to help with this but I couldn't figure 
out a way to get that information from there.


--
Major Hayden


OpenPGP_0x737051E0C1011FB1.asc
Description: OpenPGP public key


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

Re: HEADS UP: OpenSceneGraph 3.6.5 and osgearth 3.2 landing in rawhide + review request python-sphinx-markdown-tables

[Zbigniew Jędrzejewski-Szmek]

On Tue, Nov 16, 2021 at 09:17:39AM +0100, Sandro Mani wrote:
> >https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2023118
Reviewed.

> >Happy to review in exchange.

Maybe take https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2023514?
It should be very quick too.

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

Re: Orphaned package plantuml

[Blaise Pabon]

I love plantuml and would be happy to take it.

 I've made  several attempts over the past four years to become a fully
qualified packager but I have not made it all the way.

On Tue, Nov 16, 2021, 4:58 AM Jan Šafránek 
wrote:

> PlantUML package is free to take. It has few open bugs, mostly related to
> Java dependencies and it needs an update from upstream. Otherwise it
> requires very low effort to maintain it, upstream is stable and friendly.
>
> https://plantuml.com/
> https://src.fedoraproject.org/rpms/plantuml
>
> https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&classification=Fedora&component=plantuml&product=Fedora&product=Fedora%20EPEL
>
> Jan
> ___
> 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

Orphaned package plantuml

[Jan Šafránek]

PlantUML package is free to take. It has few open bugs, mostly related to Java 
dependencies and it needs an update from upstream. Otherwise it requires very 
low effort to maintain it, upstream is stable and friendly.

https://plantuml.com/
https://src.fedoraproject.org/rpms/plantuml
https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&classification=Fedora&component=plantuml&product=Fedora&product=Fedora%20EPEL

Jan
___
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-34-20211116.0 compose check report

[Fedora compose checker]

No missing expected images.

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

Old soft failures (same test soft failed in Fedora-Cloud-34-2025.0):

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

Passed openQA tests: 7/8 (x86_64), 7/8 (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: F37 Change: RetireARMv7 (System-Wide Change proposal)

[Zbigniew Jędrzejewski-Szmek]

On Tue, Nov 16, 2021 at 08:34:07AM +, Ahmed Almeleh wrote:
> I agree that the ARMv7 architecture is in decline and echo the opinion
> of Zbigniew
> that the user base will be very low once the EOL for F36 falls.
> 
> Overall I think it is best to remove the ARMv7 architecture. It may also
> make it easier to push advanced features into new releases quicker.
> 
> On Tue, 16 Nov 2021 at 08:02, Zbigniew Jędrzejewski-Szmek 
> wrote:
> 
> > On Mon, Nov 15, 2021 at 02:15:49PM -0500, Ben Cotton wrote:
> > > https://fedoraproject.org/wiki/Changes/RetireARMv7
> > >
> > > == Owner ==
> > > * Name: [[User:pbrobinson| Peter Robinson]]
> > > * Email: 
> > >
> > > == Detailed Description ==
> > >
> > > The ARMv7 arm architecture was the second variant of the arm
> > > architecture that Fedora has supported, the first was ARMv5, the third
> > > is aarch64. The proposal is to retire ARMv7 as part of the Fedora 37
> > > release. This will allow ARMv7/armhfp to be supported until the Fedora
> > > 36 end of life in around June 2023.
> > >
> > > Overall arm32 is generally waning with generally few new ARMv7 devices
> > > added to Fedora in recent releases. To add to that a number of newer
> > > Fedora features designed to improve speed and security of the Fedora
> > > release are causing 32 bit architectures in general primarily due to
> >
> > "issues" or "problems" seems to be missing in this sentence.
> >
> > > the process memory limit when linking large applications. The
> > > ARMv7/armhfp is the last fully supported 32 bit architecture, we still
> > > currently build i686 packages, but it's not shipped as artefacts.
> >
> > "it's" → "they are"?
> >
> > > == User Experience ==
> > > Any current users of Fedora on ARMv7 devices won't be able to upgrade
> > > to Fedora 37, they will have to stay on Fedora 36 until it's EOL.
> >
> > Please add "and will have to retire the hardware or move to a different
> > distribution afterwards". Explicit is good.
> >
> > > == Release Notes ==
> > >
> > > Fedora Linux 37 with the ARMv7 architecture is retired into the
> > > sunset. There will definitely be celebrations, there will likely be
> > > some that shed some tears! Overall for the maintainers it will likely
> > > be seen as a net win, for the few, generally shrinking, users it's
> > > probably a net loss but they can probably just go and buy a Raspberry
> > > Pi Zero 2W for US$15. ¯\_(ツ)_/¯
> >
> > Based on the countme graphs that mattdm has been showing, the fraction
> > on arm32 systems is very very small. And arm32 has been a drag on
> > maintainer resources, with the slow builds and timeouts. Dropping the
> > arch will not be without some pain for the people using those boards,
> > but I think it's the right thing to do for the distro. And the whole
> > thing will happen more then a year from now, and by that time the
> > number of those arm32 boards will be even lower.

Images from mattdm's brontosaurifier are attached. It seems that the
fall of arm32 happened even earlier, there are significantly fewer arm32
systems updating F33 than F32.

Zbyszek

P.S. I'm not sure if the attachments will make it through, so the plots
are also at
https://in.waw.pl/~zbyszek/fedora/fedora-updates-waffle-arch-for-release-32-all.svg
https://in.waw.pl/~zbyszek/fedora/fedora-updates-waffle-arch-for-release-33-all.svg
https://in.waw.pl/~zbyszek/fedora/fedora-updates-waffle-arch-for-release-34-all.svg
https://in.waw.pl/~zbyszek/fedora/fedora-updates-waffle-arch-for-release-35-all.svg
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: RetireARMv7 (System-Wide Change proposal)

[Ahmed Almeleh]

I agree that the ARMv7 architecture is in decline and echo the opinion
of Zbigniew
that the user base will be very low once the EOL for F36 falls.

Overall I think it is best to remove the ARMv7 architecture. It may also
make it easier to push advanced features into new releases quicker.



Thanks,
Ahmed Almeleh,
Fedora QA


On Tue, 16 Nov 2021 at 08:02, Zbigniew Jędrzejewski-Szmek 
wrote:

> On Mon, Nov 15, 2021 at 02:15:49PM -0500, Ben Cotton wrote:
> > https://fedoraproject.org/wiki/Changes/RetireARMv7
> >
> > == Owner ==
> > * Name: [[User:pbrobinson| Peter Robinson]]
> > * Email: 
> >
> > == Detailed Description ==
> >
> > The ARMv7 arm architecture was the second variant of the arm
> > architecture that Fedora has supported, the first was ARMv5, the third
> > is aarch64. The proposal is to retire ARMv7 as part of the Fedora 37
> > release. This will allow ARMv7/armhfp to be supported until the Fedora
> > 36 end of life in around June 2023.
> >
> > Overall arm32 is generally waning with generally few new ARMv7 devices
> > added to Fedora in recent releases. To add to that a number of newer
> > Fedora features designed to improve speed and security of the Fedora
> > release are causing 32 bit architectures in general primarily due to
>
> "issues" or "problems" seems to be missing in this sentence.
>
> > the process memory limit when linking large applications. The
> > ARMv7/armhfp is the last fully supported 32 bit architecture, we still
> > currently build i686 packages, but it's not shipped as artefacts.
>
> "it's" → "they are"?
>
> > == User Experience ==
> > Any current users of Fedora on ARMv7 devices won't be able to upgrade
> > to Fedora 37, they will have to stay on Fedora 36 until it's EOL.
>
> Please add "and will have to retire the hardware or move to a different
> distribution afterwards". Explicit is good.
>
> > == Release Notes ==
> >
> > Fedora Linux 37 with the ARMv7 architecture is retired into the
> > sunset. There will definitely be celebrations, there will likely be
> > some that shed some tears! Overall for the maintainers it will likely
> > be seen as a net win, for the few, generally shrinking, users it's
> > probably a net loss but they can probably just go and buy a Raspberry
> > Pi Zero 2W for US$15. ¯\_(ツ)_/¯
>
> Based on the countme graphs that mattdm has been showing, the fraction
> on arm32 systems is very very small. And arm32 has been a drag on
> maintainer resources, with the slow builds and timeouts. Dropping the
> arch will not be without some pain for the people using those boards,
> but I think it's the right thing to do for the distro. And the whole
> thing will happen more then a year from now, and by that time the
> number of those arm32 boards will be even lower.
>
> Zbyszek
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam 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: OpenSceneGraph 3.6.5 and osgearth 3.2 landing in rawhide + review request python-sphinx-markdown-tables

[Sandro Mani]

On 15.11.21 15:20, Sandro Mani wrote:


Hi

I'll be updating to OpenSceneGraph 3.6.5 and osgearth 3.2 in rawhide 
in the f36-build-side-47862 side tag, and I'll also rebuild the 
following packages:


fgrun-2016.3.1-45.fc36.src.rpm
FlightGear-2020.3.11-1.fc36.src.rpm
scribus-1.5.7-6.fc36.src.rpm
SimGear-2020.3.11-1.fc36.src.rpm
speed-dreams-2.2.3-1.fc36.src.rpm


This is done now.


I've already performed all the builds in this [1] copr repo.

To update osgearth, I'd appreciate a review of 
python-sphinx-markdown-tables, required for building the osgearth 
documentation. The review is here


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

Happy to review in exchange.

osgearth build without docs for now, still looking forward to getting 
this reviewed :)


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

Re: F37 Change: RetireARMv7 (System-Wide Change proposal)

[Zbigniew Jędrzejewski-Szmek]

On Mon, Nov 15, 2021 at 02:15:49PM -0500, Ben Cotton wrote:
> https://fedoraproject.org/wiki/Changes/RetireARMv7
> 
> == Owner ==
> * Name: [[User:pbrobinson| Peter Robinson]]
> * Email: 
> 
> == Detailed Description ==
> 
> The ARMv7 arm architecture was the second variant of the arm
> architecture that Fedora has supported, the first was ARMv5, the third
> is aarch64. The proposal is to retire ARMv7 as part of the Fedora 37
> release. This will allow ARMv7/armhfp to be supported until the Fedora
> 36 end of life in around June 2023.
> 
> Overall arm32 is generally waning with generally few new ARMv7 devices
> added to Fedora in recent releases. To add to that a number of newer
> Fedora features designed to improve speed and security of the Fedora
> release are causing 32 bit architectures in general primarily due to

"issues" or "problems" seems to be missing in this sentence.

> the process memory limit when linking large applications. The
> ARMv7/armhfp is the last fully supported 32 bit architecture, we still
> currently build i686 packages, but it's not shipped as artefacts.

"it's" → "they are"?

> == User Experience ==
> Any current users of Fedora on ARMv7 devices won't be able to upgrade
> to Fedora 37, they will have to stay on Fedora 36 until it's EOL.

Please add "and will have to retire the hardware or move to a different
distribution afterwards". Explicit is good.

> == Release Notes ==
> 
> Fedora Linux 37 with the ARMv7 architecture is retired into the
> sunset. There will definitely be celebrations, there will likely be
> some that shed some tears! Overall for the maintainers it will likely
> be seen as a net win, for the few, generally shrinking, users it's
> probably a net loss but they can probably just go and buy a Raspberry
> Pi Zero 2W for US$15. ¯\_(ツ)_/¯

Based on the countme graphs that mattdm has been showing, the fraction
on arm32 systems is very very small. And arm32 has been a drag on
maintainer resources, with the slow builds and timeouts. Dropping the
arch will not be without some pain for the people using those boards,
but I think it's the right thing to do for the distro. And the whole
thing will happen more then a year from now, and by that time the
number of those arm32 boards will be even lower.

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