Re: A way to request/vote for packages to add next to Fedora Linux?

[Qiyu Yan]

在 2021-11-19星期五的 05:32 +，Reon Beon via devel写道：
> Video2X would be a nice add.
Not really, see https://github.com/k4yt3x/video2x .
It seems that Video2X depends on ffmpeg, which is only available in
rpmfusion. You may ask in rpmfusion list to see if anyone is interested
to package Video2X.
> ___
> 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

-- 
Qiyu Yan
GPG keyid: 0x4FC914F065F2DF12
About: https://fedoraproject.org/wiki/User:Yanqiyu






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

xorg-macros

[Globe Trotter via devel]

Hi,

oclock has been orphaned from F35 so i was trying to roll my own rpm (building 
off the spec file for F34). I noticed that the spec file contains:

BuildRequires:  pkgconfig(xorg-macros) >= 1.8

but I can not find this in the F34 repos. Where do I get this? If I succeed 
with rolling a oclock rpm, I would like to submit and maintain the package.

Thanks!
___
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

A way to request/vote for packages to add next to Fedora Linux?

[Reon Beon via devel]

Video2X would be a nice add.
___
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

Package review requests from games-sig

[Jan K]

Forwarding following review requests on behalf of games SIG.

Jan
fas copperi


From: Dennis Payne 
Sent: Thursday, November 18, 2021 3:51 PM
To: Fedora Games 
Subject: [games-sig] Cataclysm: Dark Days Ahead

Finally got the latest Cataclysm: Dark Days Ahead working. I've now
adopted the package.

Still looking for reviewers on two new packages.

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

--
Dennis Payne
du...@identicalsoftware.com
https://mastodon.gamedev.place/@dulsi

___
Fedora Games SIG mailing list -- ga...@lists.fedoraproject.org
To unsubscribe send an email to games-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/ga...@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: Non-responsive maintainer: sjenning

[Gary Buhrmaster]

On Thu, Nov 18, 2021 at 11:10 PM Arthur Bols  wrote:
>
> Hi,
>
> Does anyone know if Seth Jennings (sjenning) is stil active in Fedora? I
> sent him an email in June without response.
> The package pam-u2f has been outdated for a while and I've created the
> non-responsive maintainer bug [1]. There is also a bug open for pyscard [2].
>
> Please ping me on irc (principis) or reply to this email if anyone knows
> anything. I'm would like to maintain pam-u2f if needed.

(Eventually) going down the pam-u2f upgrade
process was on my infinitely countable TODO
list for some time.  Thanks for raising it!

I am also willing to be a (co)-maintainer for pam-u2f
if needed/necessary/desired (I am the maintainer for
what will end up being a new dependency with a
recent pam-u2f, i.e. libfido2).

As I recall, upgrading pam-u2f to a recent release
would allow orphaning/removing of a couple of the
dependencies (libu2f-server/client).

FWIW, I have been building (recent) pam-u2f
versions in copr for my own use for a while now
(so I even have a recently valid spec file should
one want).

Thanks!
___
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]

Missing expected images:

Soas live x86_64

Failed openQA tests: 1/45 (x86_64)

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

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: 43/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

Non-responsive maintainer: sjenning

[Arthur Bols]

Hi,

Does anyone know if Seth Jennings (sjenning) is stil active in Fedora? I 
sent him an email in June without response.
The package pam-u2f has been outdated for a while and I've created the 
non-responsive maintainer bug [1]. There is also a bug open for pyscard [2].


Please ping me on irc (principis) or reply to this email if anyone knows 
anything. I'm would like to maintain pam-u2f if needed.


Thanks,
Arthur

[1] https://bugzilla.redhat.com/show_bug.cgi?id=2024771
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1690777

___
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: [EPEL-devel] Re: RFC: generating openssl3 packages from openssl spec

[Michel Alexandre Salim]

On Fri, Nov 12, 2021 at 03:21:35PM -0800, Michel Alexandre Salim wrote:
> On Wed, Nov 10, 2021 at 03:50:44PM -0800, Michel Alexandre Salim wrote:
> > On Wed, 2021-11-10 at 15:48 -0800, Michel Alexandre Salim wrote:
> > > 
> > > This shows the minimum changes needed to:
> > > - have openssl3-libs parallel installable with openssl-libs (tested in
> > > mock for x86_64)
> > > - mark the base, devel, and perl subpackages as conflicting
> > >   - openssl3 and openssl both ship binaries in %{_bindir}
> > >   - ditto with openssl3-perl and openssl-perl
> > >   - openssl3-devel and openssl-devel both ship headers and includes
> > > with the same names
> > > 
> > And of course I forgot to paste in the commit:
> > https://gitlab.com/michel-slm/openssl3/-/commit/3649e51f898dbe1d97695cd8aca206c262a03617
> > 
> 
> It's been 2 days, so I'm assuming I'm not doing anything insanely silly
> here. I've put up the package for review:
> 
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2022907
> 
> cc:ing Sahana who is driving the OpenSSL 3 migration in Fedora. Sahana,
> would it make sense to have this in Fedora 34 and 35 as well?
> 
> Best regards,
> 
Updating to close the loop: openssl3 is landing in epel8!

https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-ff6e908f7e

If anyone thinks they need this in Fedora 34 and 35, please let me know,
otherwise I'll keep this EPEL8 only for now.

Thanks to Neal Gompa for all the review feedbacks, and everyone here for
shooting down the original idea of doing this in the epel8 branch of the
main openssl dist-git repo.

Best regards,

-- 
Michel Alexandre Salim
profile: https://keyoxide.org/mic...@michel-slm.name


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: I will take orphaned plantUML

[Blaise Pabon]

Hi Otto,

Thanks for your thorough response because it confirms that:
- I was reading the right pages
- They are confusing.

I fully agree that it is suboptimal to involve releng in "unorphaning".
I will try to entice someone to sponsor me for packaging. The fact that I
am still interested is a testament to my tenacity.

-Blaise

On Thu, Nov 18, 2021 at 2:32 PM Otto Urpelainen  wrote:

> Hello Blaise,
>
> I am not familiar with this particular package, but about becoming a
> packager and unorphaning packages in general:
>
> Blaise Pabon kirjoitti 18.11.2021 klo 16.35:
> > This is my first fedora package.
> > (I have tried before, but not made it this far.)
>
> Good luck, I hope you make it this time!
>
> > In the spirit of begging forgiveness rather than permission, I opened:
> > https://pagure.io/releng/issue/10393
>
> There is no need involve releng when unorphaning packages. Packagers can
> do that themselves, with the Take button that you are already familiar
> with.
>
> I assume you filed the ticket because of section Claiming Ownership of
> an Orphaned Package [1] in the Package Maintainer Docs. That section
> needs to be clarified a bit. In your case releng cannot (or perhaps
> should not?) help you — you just have to gain access to the packager so
> that you can help yourself.
>
> > Is the next step for me to:
> >
> > - get added to the packagers group so that I can "take" ownership
>
> Yes. Instructions are at How to Get Sponsored into the Packager Group [2].
>
> Also this page needs to be improved, the instructions are not very clear
> for your case. I would say a good way to proceed would be to first do
> enough of the things listed in "Convincing someone to sponsor you", then
> submit a ticket to the sponsors ticketing system [3], listing all those
> things.
>
> > - use my fork to update the broken dependencies and submit a PR?
>
> That will not directly help. The package is orphaned, so there is no
> maintainer to merge your pull request and issue a new build.
>
> However, submitting pull requests is one of the suggested ways to
> convince somebody to sponsor you. So please do open a pull request. It
> helps you get sponsored, and as a bonus, when you eventually get
> sponsored, you can merge the pull request and proceed to build the package.
>
> Regards,
> Otto
>
> [1]:
>
> https://docs.fedoraproject.org/en-US/package-maintainers/Package_Orphaning_Process/#claiming_ownership_of_an_orphaned_package
> [2]:
>
> https://docs.fedoraproject.org/en-US/package-maintainers/How_to_Get_Sponsored_into_the_Packager_Group/
> [3]: https://pagure.io/packager-sponsors/
> ___
> 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
>


-- 
LinkedIn   |  Quora
  |  Github

“If you want to go fast, go alone. If you want to go far, go
together.” --African
proverb
___
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: Add a game grou;p to https://src.fedoraproject.org/groups

[Kevin Fenzi]

On Thu, Nov 18, 2021 at 03:48:55AM -, Reon Beon via devel wrote:
> https://src.fedoraproject.org/groups
> 
> Thoughts?

If there is a active group of games packagers that would like to
coordinate, then sure. :) AFAIK, the games sig is pretty quiet these
days... but someone could revive them.

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

[Nikolay Nikolov]

On 11/18/21 00:27, Kevin Fenzi wrote:

On Wed, Nov 17, 2021 at 05:58:43PM +, Peter Robinson wrote:

What else is there that people care about in Fedora that's only i686?

Well, wine? I don't know how much 32bit wine is used these days.

And not 'in fedora', but people always bring up steam when these
disccussions happen. I wonder why they are sticking with 32bit?


Pretty much all Windows applications (including 64-bit ones) are usually 
distributed as a self-installing 32-bit .exe, using one of the popular 
installer packages, such as InnoSetup, the Nullsoft installer, etc. 
That's why 64-bit Windows will probably never drop support for their 
win32 compatibility layer.


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

[Kevin Fenzi]

I still like Seth's system-autodeath, but it's been retired for a while
now. 

From the summary: 

system-autodeath is a cron job that runs daily, checking the current  
time versus a configured death date for the machine. Within one week
of this date the system will emit log notices to syslog.alert notifying
that the system will remove its default network route on a specific date. 
On the date the system will have its default route deleted. It 
will continue to do this every day until someone does something about it.

really anything we do though is going to be invasive and unwelcome to
some.

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

[Neal Gompa]

On Thu, Nov 18, 2021 at 2:41 PM Josh Stone  wrote:
>
>
>
> On 11/18/21 10:15 AM, Neal Gompa wrote:
> > On Thu, Nov 18, 2021 at 12:27 PM Josh Stone  wrote:
> >>
> >> On 11/17/21 2:27 PM, Kevin Fenzi wrote:
> >>> And not 'in fedora', but people always bring up steam when these
> >>> disccussions happen. I wonder why they are sticking with 32bit?
> >>
> >> Is that just for the steam client, or also for its many legacy games?
> >> ISTR it provides its own platform libraries for games, only relying on
> >> system libs for stuff like mesa, but I'm not sure how the rpm is really
> >> packaged. Personally, I've moved to the flatpak.
> >
> > All of it is 32-bit (client, games, runtime). Steam also offers a
> > 64-bit runtime, but not many games I own use it.
>
> Sure, but with a private runtime they can run whatever 32-bit code they
> want, as long as our kernel has CONFIG_COMPAT_32=y. But I'm wondering
> how much of Fedora's 32-bit userspace is used by that stuff.
>
> The question "why they are sticking with 32bit?" is easily answered for
> games, because they simply aren't under active development. That doesn't
> mean we're still providing libraries for all of those.
>

I usually gut the Steam runtime and have it use the Fedora libraries,
since they're *better* in a lot of cases.


-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: RFC: Reduce number of packages that are built for i686

[Josh Stone]

On 11/18/21 10:15 AM, Neal Gompa wrote:
> On Thu, Nov 18, 2021 at 12:27 PM Josh Stone  wrote:
>>
>> On 11/17/21 2:27 PM, Kevin Fenzi wrote:
>>> And not 'in fedora', but people always bring up steam when these
>>> disccussions happen. I wonder why they are sticking with 32bit?
>>
>> Is that just for the steam client, or also for its many legacy games?
>> ISTR it provides its own platform libraries for games, only relying on
>> system libs for stuff like mesa, but I'm not sure how the rpm is really
>> packaged. Personally, I've moved to the flatpak.
> 
> All of it is 32-bit (client, games, runtime). Steam also offers a
> 64-bit runtime, but not many games I own use it.

Sure, but with a private runtime they can run whatever 32-bit code they
want, as long as our kernel has CONFIG_COMPAT_32=y. But I'm wondering
how much of Fedora's 32-bit userspace is used by that stuff.

The question "why they are sticking with 32bit?" is easily answered for
games, because they simply aren't under active development. That doesn't
mean we're still providing libraries for all of those.
___
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 Developer Portal Update

[Jarek Prokop]

Hello,

Fedora Developer Portal just got an update.

Notable changes:
  * Added Redis page [1]
  * Added Fortran page [2]
  * Added Virtualization pages [3]

Any feedback is welcome!

[1] https://developer.fedoraproject.org/tech/database/redis/about.html
[2] 
https://developer.fedoraproject.org/tech/languages/fortran/fortran-installation.html

[3] https://developer.fedoraproject.org/tools/virtualization/about.html

Regards,
Jarek Prokop
Intern, Red Hat
Brno, Czech Republic
___
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: I will take orphaned plantUML

[Otto Urpelainen]

Hello Blaise,

I am not familiar with this particular package, but about becoming a 
packager and unorphaning packages in general:


Blaise Pabon kirjoitti 18.11.2021 klo 16.35:

This is my first fedora package.
(I have tried before, but not made it this far.)


Good luck, I hope you make it this time!


In the spirit of begging forgiveness rather than permission, I opened:
https://pagure.io/releng/issue/10393


There is no need involve releng when unorphaning packages. Packagers can 
do that themselves, with the Take button that you are already familiar with.


I assume you filed the ticket because of section Claiming Ownership of 
an Orphaned Package [1] in the Package Maintainer Docs. That section 
needs to be clarified a bit. In your case releng cannot (or perhaps 
should not?) help you — you just have to gain access to the packager so 
that you can help yourself.



Is the next step for me to:

- get added to the packagers group so that I can "take" ownership


Yes. Instructions are at How to Get Sponsored into the Packager Group [2].

Also this page needs to be improved, the instructions are not very clear 
for your case. I would say a good way to proceed would be to first do 
enough of the things listed in "Convincing someone to sponsor you", then 
submit a ticket to the sponsors ticketing system [3], listing all those 
things.



- use my fork to update the broken dependencies and submit a PR?


That will not directly help. The package is orphaned, so there is no 
maintainer to merge your pull request and issue a new build.


However, submitting pull requests is one of the suggested ways to 
convince somebody to sponsor you. So please do open a pull request. It 
helps you get sponsored, and as a bonus, when you eventually get 
sponsored, you can merge the pull request and proceed to build the package.


Regards,
Otto

[1]: 
https://docs.fedoraproject.org/en-US/package-maintainers/Package_Orphaning_Process/#claiming_ownership_of_an_orphaned_package
[2]: 
https://docs.fedoraproject.org/en-US/package-maintainers/How_to_Get_Sponsored_into_the_Packager_Group/

[3]: https://pagure.io/packager-sponsors/
___
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)

[Jason L Tibbitts III]

> Gary Buhrmaster  writes:

> I have occasionally conjectured that there should be a "last gasp"
> version of some core package released into updates for a version going
> unsupported that drops a file into /etc/motd.d that is, essentially:

I've thought about it as well, but I still wonder good it would really
do.  For a random example, I run a full Fedora mirror including the
archive module.  There is a number of hosts hosts still pulling repodata
for Fedora 7 and one lone host that checks for updates for Fedora Core 5
that will obviously never come.

People will update when they want, or not.

Plus force-modifying MOTD, or doing anything that's so invasive that
someone is guaranteed to notice, is pretty antisocial.  At best anything
that you would use to do updates (like dnf or one of the graphical
applications) could complain about the release being EOL, and I suspect
that some of them already do.  That's really the only proper way to do
this.

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

[Hans de Goede]

Hi,

On 11/18/21 16:27, Fabio Valentini wrote:
> On Thu, Nov 18, 2021 at 1:14 PM Sérgio Basto  wrote:
>>
>> Hi,
>> another subject that can be related
>>
>> In thread "I think we should stop building i686 packages we're not
>> shipping" we are alerted for builds for i686 that aren't publish .
>> Following the tip , I found some packages that we aren't shipped are
>> needed to allow mock start the buildroot for example tar-1.34-
>> 2.fc35.i686.rpm, tar is only available on koji local repo (1).
>>
>> I think we should have all i686 packages, that are needed to start a
>> buildrooot, published. i.e. available on x86_64 repos. To allow mock
>> build i686 packages without need to access to internal koji local repo
>> (which may not be public) .
> 
> This would break all sorts of things.
> 
> It's also not compatible with the current packaging guidelines,
> because packages must not conflict with each other unless they have an
> explicit Conflicts tag and a good reason to do so. in this case,
> tar.x86_64 and tar.i686 would conflict with each other (both providing
> /usr/bin/tar, among other files)

Ah, I see it has been so long ago since we made the switch that
some people no longer know the intricate details of how multilib
works :) Elf binaries are treated specially by rpm and are what
rpm calls colored IIRC. Not sure why it is called that, but the way
it works is that you can install both an i686 and x86_64 /usr/bin/tar
file with rpm and if you install i686 first then it will get replaced
with the x86_64 binary when you install that and if you install x86_64
first then that binary will stay in place (*).

This is done so that some package containing mainly a few .so.x libs
but also some small utils can be installed in multi-lib form without
need to split out the /usr/bin/utils into a separate package.

> so that's out of the question.

Not necessarily, note some files under e.g. /usr/share could still
conflict, but typically they do not.

Regards,

Hans



*) And I must admit I have no idea what happens if you remove the
x86_64 pkg while you still have the i686 pkg installed, maybe an
error ?

___
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: rawhide build root broken by redhat-rpm-config clash

[Daniel P . Berrangé]

On Thu, Nov 18, 2021 at 10:14:33AM -0800, Kevin Fenzi wrote:
> On Thu, Nov 18, 2021 at 05:56:01PM +, Daniel P. Berrangé wrote:
> > The rawhide build root appears to be broken when installing the
> > srpm-build group:
> > 
> > https://kojipkgs.fedoraproject.org//work/tasks/8923/79028923/root.log
> > 
> > DEBUG util.py:446:  Installing group/module packages:
> > DEBUG util.py:446:   bash  s390x  5.1.8-3.fc36  
> > build 1.6 M
> > DEBUG util.py:446:   fedora-releasenoarch 36-0.9
> > build  11 k
> > DEBUG util.py:446:   fedpkg-minimalnoarch 1.2.0-4.fc36  
> > build  17 k
> > DEBUG util.py:446:   glibc-minimal-langpacks390x  2.34.9000-21.fc36 
> > build 146 k
> > DEBUG util.py:446:   gnupg2s390x  2.3.3-1.fc36  
> > build 2.4 M
> > DEBUG util.py:446:   redhat-rpm-config noarch 204-1.fc36
> > build  67 k
> > DEBUG util.py:446:   rpm-build s390x  4.17.0-1.fc36.1   
> > build  60 k
> > DEBUG util.py:446:   shadow-utils  s390x  2:4.9-7.fc36  
> > build 1.1 M
> > 
> > snip...
> > 
> > DEBUG util.py:444:  Error: Transaction test error:
> > DEBUG util.py:444:file /usr/lib/rpm/fileattrs/kmod.attr conflicts 
> > between attempted installs of redhat-rpm-config-204-1.fc36.noarch and 
> > kernel-srpm-macros-1.0-10.fc36.noarch
> > 
> > 
> > kernel-srpm-macros was rebuilt today containing the kmod.attr file
> > before redhat-rpm-config was modified to remove it. AFAICT, this
> > means nothing more can be rebuilt until kernel-srpm-macros is
> > untagged and then redhat-rpm-config needs to remove the file before
> > kernel-srpm-macros re-adds it.
> > 
> > redhat-rpm-config bug: https://bugzilla.redhat.com/show_bug.cgi?id=2024696
> > kernel-srpm-macros bug: https://bugzilla.redhat.com/show_bug.cgi?id=2024694
> 
> FYI, I have untagged kernel-srpm-macros-1.0-10.fc36 from f36 and eln.

Thanks for the quick response !

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

Re: RFC: Reduce number of packages that are built for i686

[Neal Gompa]

On Thu, Nov 18, 2021 at 12:27 PM Josh Stone  wrote:
>
> On 11/17/21 2:27 PM, Kevin Fenzi wrote:
> > And not 'in fedora', but people always bring up steam when these
> > disccussions happen. I wonder why they are sticking with 32bit?
>
> Is that just for the steam client, or also for its many legacy games?
> ISTR it provides its own platform libraries for games, only relying on
> system libs for stuff like mesa, but I'm not sure how the rpm is really
> packaged. Personally, I've moved to the flatpak.

All of it is 32-bit (client, games, runtime). Steam also offers a
64-bit runtime, but not many games I own use it.




--
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: rawhide build root broken by redhat-rpm-config clash

[Kevin Fenzi]

On Thu, Nov 18, 2021 at 05:56:01PM +, Daniel P. Berrangé wrote:
> The rawhide build root appears to be broken when installing the
> srpm-build group:
> 
> https://kojipkgs.fedoraproject.org//work/tasks/8923/79028923/root.log
> 
> DEBUG util.py:446:  Installing group/module packages:
> DEBUG util.py:446:   bash  s390x  5.1.8-3.fc36
>   build 1.6 M
> DEBUG util.py:446:   fedora-releasenoarch 36-0.9  
>   build  11 k
> DEBUG util.py:446:   fedpkg-minimalnoarch 1.2.0-4.fc36
>   build  17 k
> DEBUG util.py:446:   glibc-minimal-langpacks390x  2.34.9000-21.fc36   
>   build 146 k
> DEBUG util.py:446:   gnupg2s390x  2.3.3-1.fc36
>   build 2.4 M
> DEBUG util.py:446:   redhat-rpm-config noarch 204-1.fc36  
>   build  67 k
> DEBUG util.py:446:   rpm-build s390x  4.17.0-1.fc36.1 
>   build  60 k
> DEBUG util.py:446:   shadow-utils  s390x  2:4.9-7.fc36
>   build 1.1 M
> 
> snip...
> 
> DEBUG util.py:444:  Error: Transaction test error:
> DEBUG util.py:444:file /usr/lib/rpm/fileattrs/kmod.attr conflicts between 
> attempted installs of redhat-rpm-config-204-1.fc36.noarch and 
> kernel-srpm-macros-1.0-10.fc36.noarch
> 
> 
> kernel-srpm-macros was rebuilt today containing the kmod.attr file
> before redhat-rpm-config was modified to remove it. AFAICT, this
> means nothing more can be rebuilt until kernel-srpm-macros is
> untagged and then redhat-rpm-config needs to remove the file before
> kernel-srpm-macros re-adds it.
> 
> redhat-rpm-config bug: https://bugzilla.redhat.com/show_bug.cgi?id=2024696
> kernel-srpm-macros bug: https://bugzilla.redhat.com/show_bug.cgi?id=2024694

FYI, I have untagged kernel-srpm-macros-1.0-10.fc36 from f36 and eln. 

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: ceph's builds started to fail in Fedora 35

[Fabio Valentini]

On Thu, Nov 18, 2021 at 7:07 PM Kaleb Keithley  wrote:
>
>
> On Wed, Nov 17, 2021 at 10:20 PM  wrote:
>>
>> Notification time stamped 2021-11-18 01:07:11 UTC
>>
>> ceph's builds started to fail in Fedora 35
>> https://apps.fedoraproject.org/koschei/package/ceph?collection=f35
>>
>
> Not sure what I'm supposed to see here. The ceph builds are all green.

That happened to a few of my packages recently as well. I assumed it's
a bug in koschei (or cosmic rays flipping the result from "good" to
"bad" ...).
The next koschei build should succeed again (which you can make happen
sooner by giving it high manual priority).

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

[Zebediah Figura]

On 11/17/21 16:27, Kevin Fenzi wrote:

On Wed, Nov 17, 2021 at 05:58:43PM +, Peter Robinson wrote:


What else is there that people care about in Fedora that's only i686?


Well, wine? I don't know how much 32bit wine is used these days.


Quite a lot. In fact, it's best to think of Windows programs as being 
exclusively 32-bit. Even 64-bit Windows programs usually ship with 
32-bit installers, because otherwise they'd have no way to control what 
happens on a 32-bit machine.


For what it's worth, we are trying to avoid depending on 32-bit host 
libraries (except for some 32-bit MinGW libraries), but it's a long and 
difficult process.

___
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: ceph's builds started to fail in Fedora 35

[Kaleb Keithley]

On Wed, Nov 17, 2021 at 10:20 PM  wrote:

> Notification time stamped 2021-11-18 01:07:11 UTC
>
> ceph's builds started to fail in Fedora 35
> https://apps.fedoraproject.org/koschei/package/ceph?collection=f35
>
>
Not sure what I'm supposed to see here. The ceph builds are all green.

But I did a couple of x86_64 scratch builds of the last updates. The F36
build[1] failed due to a compiler internal error. huh? Same ceph sources,
same gcc and annobin.

The F35 build[2] went past where the F36 build failed and is still running.

[1] https://koji.fedoraproject.org/koji/taskinfo?taskID=79025337
[2] https://koji.fedoraproject.org/koji/taskinfo?taskID=79027279









> --
> You received this message due to your preference settings at
>
> https://apps.fedoraproject.org/notifications/kkeithle.id.fedoraproject.org/email/26014



-- 

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

[Nicolas Chauvet]

Le jeu. 18 nov. 2021 à 03:33, Fabio Valentini  a écrit :
>

> Additionally, the steam RPM (as provided by the opt-in third-party
> repository that comes installed by default with Fedora Workstation) is
> a i686-only package (sad face), and hence also pulls in i686
The RPM Fusion package is built as a i686 library despite been
"mainly" noarch scripts (bash, python3).
The "mainly" is because there is a 32bit bootstrap client that really
is about to download the fuller stream client from upstream.
Not having any 32bit runtime capability is going to break here (but
it's certainly fixable if upstream would also bundle a 64bit bootstrap
client).

Then most processes from stream {before} running any program show
steamwebhelper are using a 64bit ubuntu 12.04 userspace.
But we likely assume some program are 32bit only and because of that
the our package assume the 32bit capabilities {can} be needed, it
justs assume to install the needed libraries (specially the system
libGL.i686 and others)

It seems to me that assuming 64bit only userspace with steam is wrong
and will lead some users to crash.

If any additional question, please report an issue to
https://bugzilla.rpmfusion.org. Simone will be able to answer or
forward/ask upstream.

Thanks in advance.

> libraries:
> $ sudo dnf repoquery --requires steam --resolve --recursive | grep i686 | wc 
> -l
> 221
___
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

rawhide build root broken by redhat-rpm-config clash

[Daniel P . Berrangé]

The rawhide build root appears to be broken when installing the
srpm-build group:

https://kojipkgs.fedoraproject.org//work/tasks/8923/79028923/root.log

DEBUG util.py:446:  Installing group/module packages:
DEBUG util.py:446:   bash  s390x  5.1.8-3.fc36  
build 1.6 M
DEBUG util.py:446:   fedora-releasenoarch 36-0.9
build  11 k
DEBUG util.py:446:   fedpkg-minimalnoarch 1.2.0-4.fc36  
build  17 k
DEBUG util.py:446:   glibc-minimal-langpacks390x  2.34.9000-21.fc36 
build 146 k
DEBUG util.py:446:   gnupg2s390x  2.3.3-1.fc36  
build 2.4 M
DEBUG util.py:446:   redhat-rpm-config noarch 204-1.fc36
build  67 k
DEBUG util.py:446:   rpm-build s390x  4.17.0-1.fc36.1   
build  60 k
DEBUG util.py:446:   shadow-utils  s390x  2:4.9-7.fc36  
build 1.1 M

snip...

DEBUG util.py:444:  Error: Transaction test error:
DEBUG util.py:444:file /usr/lib/rpm/fileattrs/kmod.attr conflicts between 
attempted installs of redhat-rpm-config-204-1.fc36.noarch and 
kernel-srpm-macros-1.0-10.fc36.noarch


kernel-srpm-macros was rebuilt today containing the kmod.attr file
before redhat-rpm-config was modified to remove it. AFAICT, this
means nothing more can be rebuilt until kernel-srpm-macros is
untagged and then redhat-rpm-config needs to remove the file before
kernel-srpm-macros re-adds it.

redhat-rpm-config bug: https://bugzilla.redhat.com/show_bug.cgi?id=2024696
kernel-srpm-macros bug: https://bugzilla.redhat.com/show_bug.cgi?id=2024694

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

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

[Gary Buhrmaster]

On Thu, Nov 18, 2021 at 2:32 AM Josh Stone  wrote:
>
> On 11/16/21 7:05 PM, Kevin Kofler via devel wrote:
> > 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.
>
> Maybe so, but what can we do?
>
> We already did this for i686 hosts, and I'll bet there are still folks
> running F30 for that, or even EOL versions of currently supported
> arches. They may exist, but they "go away" from the perspective of what
> we choose to support.

I have occasionally conjectured that there
should be a "last gasp" version of some
core package released into updates for a
version going unsupported that drops a file
into /etc/motd.d that is, essentially:

  "This version of Fedora is no longer supported"

(and an equivalent banner for desktop login screen)

That would not mean everyone would see
the message, nor would it stop people using
that version (I would think we do not want
to do so), but it might make it clear(er) to
some that there will be no further updates
in case the individual is not paying close
attention to the Fedora lifecycle.
___
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

[Josh Stone]

On 11/17/21 2:27 PM, Kevin Fenzi wrote:
> And not 'in fedora', but people always bring up steam when these
> disccussions happen. I wonder why they are sticking with 32bit?

Is that just for the steam client, or also for its many legacy games?
ISTR it provides its own platform libraries for games, only relying on
system libs for stuff like mesa, but I'm not sure how the rpm is really
packaged. Personally, I've moved to the flatpak.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Heads up: moving some content from wiki to docs

[Ben Cotton]

Hi everyone,

Just wanted to let you know I'm going to start moving some
release-related content out of the wiki and into docs. It's largely
things that are static and copy/pasted forward like release-blocking
images, spins/labs, etc. I will setup automatic redirects as I move
pages, but if you're linking to specific anchors, that will likely
break. I'll continue to create wiki pages for the next release or two,
but if you have anything generating links to the wiki pages for
spins/labs or blocking images, you'll want to start updating those.

You can see the basic structure starting to take place at:
https://docs.fedoraproject.org/en-US/releases/

Note that ChangeSet pages and schedules are not moving, at least for now.


Thanks,
BC

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

Re: RFC: Reduce number of packages that are built for i686

[Sérgio Basto]

On Thu, 2021-11-18 at 16:27 +0100, Fabio Valentini wrote:
> On Thu, Nov 18, 2021 at 1:14 PM Sérgio Basto 
> wrote:
> > 
> > Hi,
> > another subject that can be related
> > 
> > In thread "I think we should stop building i686 packages we're not
> > shipping" we are alerted for builds for i686 that aren't publish .
> > Following the tip , I found some packages that we aren't shipped
> > are
> > needed to allow mock start the buildroot for example tar-1.34-
> > 2.fc35.i686.rpm, tar is only available on koji local repo (1).
> > 
> > I think we should have all i686 packages, that are needed to start
> > a
> > buildrooot, published. i.e. available on x86_64 repos. To allow
> > mock
> > build i686 packages without need to access to internal koji local
> > repo
> > (which may not be public) .
> 
> This would break all sorts of things.
> 
> It's also not compatible with the current packaging guidelines,
> because packages must not conflict with each other unless they have
> an
> explicit Conflicts tag and a good reason to do so. in this case,
> tar.x86_64 and tar.i686 would conflict with each other (both
> providing
> /usr/bin/tar, among other files), so that's out of the question.

no it want , we just can't install tar.i686 and tar.x86_64

and `dnf install tar` just install tar.x86_64



> That's exactly the reason why complex heuristics are applied to which
> i686 packages are allowed into the x86_64 repositories as "multilib"
> packages.
> 
> > But for packages that aren't shipped , I agree not build for i686,
> > we
> > already got the concept of multilib package and only multilib
> > packages
> > should be build for i686 , I think.
> 
> 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

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

Re: RFC: Reduce number of packages that are built for i686

[Fabio Valentini]

On Thu, Nov 18, 2021 at 5:59 AM Maxwell G (@gotmax23)  wrote:
>
>
> Nov 17, 2021 4:56:36 AM Zbigniew Jędrzejewski-Szmek :
>
> > On Wed, Nov 17, 2021 at 10:53:30AM +, Zbigniew Jędrzejewski-Szmek wrote:
>
> > [...]
> >>
> >> And obviously the advantage is that this can be done now, and doesn't
> >> require any new infra or maintenance. The only trick would be how to
> >> figure out the transitive BR tree, but apparently there are some scripts
> >> that people have.
> >
> > s/people/Fabio/ ;)
>
> Fabio,
>
> Can you please provide a link to your script?

Not yet. I still need to fix it up and verify that it actually
provides correct results.

However, consider it to be the "inverse" process that I usef for
determining (SIG) leaf packages for the stewardship-sig,
java-maint-sig, and rust-sig, so in theory the algorithm used *should*
be sound and complete (albeit not very fast).

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

[Fabio Valentini]

On Thu, Nov 18, 2021 at 1:14 PM Sérgio Basto  wrote:
>
> Hi,
> another subject that can be related
>
> In thread "I think we should stop building i686 packages we're not
> shipping" we are alerted for builds for i686 that aren't publish .
> Following the tip , I found some packages that we aren't shipped are
> needed to allow mock start the buildroot for example tar-1.34-
> 2.fc35.i686.rpm, tar is only available on koji local repo (1).
>
> I think we should have all i686 packages, that are needed to start a
> buildrooot, published. i.e. available on x86_64 repos. To allow mock
> build i686 packages without need to access to internal koji local repo
> (which may not be public) .

This would break all sorts of things.

It's also not compatible with the current packaging guidelines,
because packages must not conflict with each other unless they have an
explicit Conflicts tag and a good reason to do so. in this case,
tar.x86_64 and tar.i686 would conflict with each other (both providing
/usr/bin/tar, among other files), so that's out of the question.

That's exactly the reason why complex heuristics are applied to which
i686 packages are allowed into the x86_64 repositories as "multilib"
packages.

> But for packages that aren't shipped , I agree not build for i686, we
> already got the concept of multilib package and only multilib packages
> should be build for i686 , I think.

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: [Fedocal] Reminder meeting : ELN SIG

[Stephen Gallagher]

On Thu, Nov 18, 2021 at 7:02 AM  wrote:
>
> Dear all,
>
> You are kindly invited to the meeting:
>ELN SIG on 2021-11-19 from 12:00:00 to 13:00:00 US/Eastern
>At fedora-meet...@irc.libera.chat
>
> The meeting will be about:


* Python requesting permission to use the %{eln} macro in
python-rpm-macros - https://github.com/fedora-eln/eln/issues/73
* Status of ELN Compose outage

Anyone have other topics?
___
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

I will take orphaned plantUML

[Blaise Pabon]

This is my first fedora package.
(I have tried before, but not made it this far.)

In the spirit of begging forgiveness rather than permission, I opened:
https://pagure.io/releng/issue/10393

Is the next step for me to:

- get added to the packagers group so that I can "take" ownership

or

- use my fork to update the broken dependencies and submit a PR?


Be ruthless and unforgiving in your feedback.

-Blaise

-- 
LinkedIn   |  Quora
  |  Github

“If you want to go fast, go alone. If you want to go far, go
together.” --African
proverb
___
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: Add a game grou;p to https://src.fedoraproject.org/groups

[Jan K]

I see no reason not to do so.

Jan


From: Reon Beon via devel 
Sent: Thursday, November 18, 2021 5:48 AM
To: devel@lists.fedoraproject.org 
Cc: Reon Beon 
Subject: Add a game grou;p to https://src.fedoraproject.org/groups

https://src.fedoraproject.org/groups

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

[Sérgio Basto]

Hi, 
another subject that can be related

In thread "I think we should stop building i686 packages we're not
shipping" we are alerted for builds for i686 that aren't publish .
Following the tip , I found some packages that we aren't shipped are
needed to allow mock start the buildroot for example tar-1.34-
2.fc35.i686.rpm, tar is only available on koji local repo (1).

I think we should have all i686 packages, that are needed to start a
buildrooot, published. i.e. available on x86_64 repos. To allow mock
build i686 packages without need to access to internal koji local repo
(which may not be public) . 

But for packages that aren't shipped , I agree not build for i686, we
already got the concept of multilib package and only multilib packages
should be build for i686 , I think. 



(1)
https://kojipkgs.fedoraproject.org/repos/f35-build/latest/i386/pkglist




On Tue, 2021-11-16 at 20:47 +0100, 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.
> 
> 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

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

[Fedocal] Reminder meeting : ELN SIG

[sgallagh]

Dear all,

You are kindly invited to the meeting:
   ELN SIG on 2021-11-19 from 12:00:00 to 13:00:00 US/Eastern
   At fedora-meet...@irc.libera.chat

The meeting will be about:



Source: https://calendar.fedoraproject.org//meeting/10108/

___
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 packages looking for new maintainers​

[Didik Supriadi]

On 11/8/21 22:52, Miro Hrončok wrote:


jacoco jvanek, kdaniel, lef, orphan 1 weeks ago

I'd like to take this package.

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

Re: RFC: Reduce number of packages that are built for i686

[Dominik 'Rathann' Mierzejewski]

On Wednesday, 17 November 2021 at 22:06, Dominik 'Rathann' Mierzejewski wrote:
> On Wednesday, 17 November 2021 at 18:58, Peter Robinson wrote:
> [...]
> > What else is there that people care about in Fedora that's only i686?
> 
> There are some old proprietary games with i686-only binaries. I'll check
> which packages are required by the ones I have.

So, for example, Tetrobot & Co and ABC Murders are both distributed as
i686 binaries only and they seem to have the following direct
dependencies:
glibc
libX11
libXcursor
libXext
libgcc
libglvnd-glx
libstdc++
mesa-dri-drivers
mesa-libGLU
pulseaudio-libs

Regards,
-- 
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: Announcing LLVM Snapshot Packages for Fedora Linux

[Dominique Martinet]

Hi Jonathan,

Jonathan Wakely wrote on Wed, Nov 03, 2021 at 01:47:22PM +:
> And I'll shamelessly plug my copr with weekly GCC snapshots  ;-)
> https://copr.fedorainfracloud.org/coprs/jwakely/gcc-latest/

I cannot seem to be able to install gcc-latest, do you know what
provides libasan/libtsan in the versions it expects?

 Problem: cannot install the best candidate for the job
  - nothing provides libasan.so.8()(64bit) needed by 
gcc-latest-12.0.0-1.2024git3057f1ab7375.fc34.x86_64
  - nothing provides libtsan.so.2()(64bit) needed by 
gcc-latest-12.0.0-1.2024git3057f1ab7375.fc34.x86_64

Respective versions on the fedora 34 package are libasan.so.6 and
libtsan.so.0
(I'll probably upgrade to fedora 35 over the next few weeks, but
fedora35 rpms for the two seem to provide the same versions so I'm
probably missing something)




Hi Konrad,

Konrad Kleine wrote on Fri, Oct 08, 2021 at 12:13:35PM +0200:
> You can grab them here:
>
> https://copr.fedorainfracloud.org/coprs/g/fedora-llvm-team/llvm-snapshots/


Thanks! I was able to install these.
I see the system's llvm (12) got installed as the copr's llvm12 instead,
and llvm became the snapshot -- would it make sense to keep llvm as the
system's llvm (12), and install the lvm snapshot as llvm14 instead?

That would let people keep using the system's trusted llvm by default,
and only use the snapshot when they explicitely require it.


Cheers,
-- 
Dominique Martinet
___
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] PyDrive2 and dependency backporting

[Mikel Olasagasti]

Hi all,

Hau idatzi du Mikel Olasagasti (mi...@olasagasti.info) erabiltzaileak
(2021 aza. 10, az. (11:34)):
> My plan would be:
>
> 1) Notify maintainers of those 5 packages about
> python3-google-api-client update.
> 2) Backport python3-google-auth-httplib2 and python3-google-api-client
> to F35 and F34.
> 3) Add PyDrive2 to F35 and F34.
> 4) Ask deja-dup maintainers to switch to PyDrive2.
> 5) Deprecate PyDrive in rawhide. Adding Obsolete to PyDrive2 may not
> be required?.

I sent two mails to the maintainers of affected packages. fence-agents
maintainer confirmed that works with 2.30 and
python3-certbot-dns-google maintainer confirmed upstream is testing
with 2.20 so it should safe with a later release.

Unless the other maintainers say something, tomorrow I'll create a
side-tag for steps 2, 3 and 4.

Kind regards,
Mikel Olasagasti (mikelo2)
___
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: Add a game grou;p to https://src.fedoraproject.org/groups

[Ankur Sinha]

On Thu, Nov 18, 2021 03:48:55 -, Reon Beon via devel wrote:
> https://src.fedoraproject.org/groups

It's up to each packaging SIG really. If the Games SIG think that a
packaging group would help them share access over the packages they
collectively maintain, they should request the infra team to help them
set one up.

We did it for the SciTech SIG recently:
https://pagure.io/fedora-infrastructure/issue/8413

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


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

Fedora-Cloud-35-20211118.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-35-2023.0):

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

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

[Zbigniew Jędrzejewski-Szmek]

On Wed, Nov 17, 2021 at 10:44:25PM +0100, Fabio Valentini wrote:
> On Wed, Nov 17, 2021 at 10:07 PM Dominik 'Rathann' Mierzejewski
>  wrote:
> >
> > On Wednesday, 17 November 2021 at 18:58, Peter Robinson wrote:
> > [...]
> > > What else is there that people care about in Fedora that's only i686?
> >
> > There are some old proprietary games with i686-only binaries. I'll check
> > which packages are required by the ones I have.
> 
> I think the easy answer here is, indeed, "games". And for some Fedora
> users, that might not be an important use case.

(snip)

I'm not much of a gamer myself, but I think this *is* an important use
case that we simply have to cater to, if we want to be more than a niche
distro. We already take a big hit on not having patent-encumbered codecs
by default, and not being able to run Wine or Steam would be a bad label
to have.

I'll share my own use case too: I use the 32 bit libs to test compilation
of programs. Most often systemd, but others too on occasion. It works like
this: after installing i686 versions of the build deps,
PKG_CONFIG_LIBDIR=/usr/lib/pkgconfig meson build-32 -Dc_args=-m32 \
  -Dc_link_args=-m32 -Dcpp_args=-m32 -Dcpp_link_args=-m32 && \
  ninja -C build-32

I will also use armv7-*.fedorainfracloud.org as another 32-bit arch, but
it's better to test for i686 too.

If Fedora drops i686 multilib, it'll be much harder to do this kind of
upstream development of C projects.

> Two Hundred (or even make it 300) packages - that's around 1% of the
> whole corpus of Fedora packages (with almost 23000 source packages in
> rawhide).
> Which I think confirms my suspicion that just building *everything*
> for i686 is 99% wasteful ...

+1.

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