Re: FESCo wants to know what you use i686 packages for

[Mauricio Tavares]

On Wed, Mar 16, 2022 at 9:54 AM David Cantrell  wrote:
>
> Hi,
>
> Our most recent FESCo meeting involved discussing the proposal to drop i686
> builds of jdk8,11,17 from Fedora 37 onward.  The topic quickly changed to the
> larger question of "what do people use i686 packages for?"
>
> Rather than guess, we wanted to ask the community what you use i686 packages
> for in Fedora.  There are no wrong answers here.  We are seeking information.
>
> Why?  Since the removal of the i686 kernel in Fedora, we want to reduce the
> number of i686 packages provided in the repo.  As time marches on, the ability
> to build a lot of things for i686 becomes unrealistic or even impossible.
> Remember it goes beyond providing builds...providing support, bug fixes, and
> security fixes for those packages too.  Maybe some things using i686 packages
> now can move to x86_64 packages.  We do not know yet, but a goal is to figure
> out what packages, if anything, can drop their i686 builds.
>
> NOTE: Nothing is changing now.  We are in an information gathering phase.
>   
>
> If you use i686 packages for something now, please respond to this thread.
>
  I use it because research on certain network controllers
requires it. But, I can move said research to Debian so it is not a
blocker to me.
___
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: FESCo wants to know what you use i686 packages for

[Steven Ellis]

The issue on our home systems is 3rd party printer drivers.

Eg
mfc9140cdncupswrapper-1.1.4-0.i386
dcpj4120dwlpr-3.0.1-1.i386
dcpj4120dwcupswrapper-3.0.1-1.i386
mfc9140cdnlpr-1.1.2-1.i386

These then pull in a whole load of dependencies relating to CUPs etc.
___
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-20220316.0 compose check report

[Fedora compose checker]

No missing expected images.

Failed openQA tests: 5/48 (x86_64)

ID: 1180045 Test: x86_64 Workstation-live-iso gnome_text_editor
URL: https://openqa.fedoraproject.org/tests/1180045
ID: 1180053 Test: x86_64 Workstation-live-iso desktop_login
URL: https://openqa.fedoraproject.org/tests/1180053
ID: 1180077 Test: x86_64 KDE-live-iso desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/1180077
ID: 1180083 Test: x86_64 KDE-live-iso desktop_login
URL: https://openqa.fedoraproject.org/tests/1180083
ID: 1180084 Test: x86_64 KDE-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/1180084

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

ID: 1180046 Test: x86_64 Workstation-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/1180046
ID: 1180049 Test: x86_64 Workstation-live-iso desktop_browser
URL: https://openqa.fedoraproject.org/tests/1180049
ID: 1180061 Test: x86_64 Workstation-live-iso eog
URL: https://openqa.fedoraproject.org/tests/1180061
ID: 1180080 Test: x86_64 KDE-live-iso desktop_browser
URL: https://openqa.fedoraproject.org/tests/1180080

Passed openQA tests: 39/48 (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: What has the PDC ever done for us?

[Christopher]

On Thu, Mar 17, 2022 at 12:29 PM Adam Williamson
 wrote:
> It stores the metadata of all composes that have been run, ever. (Well,
> when there isn't a bug in the sync, anyway). This is useful in several
> ways:
[snip]

I think a lot of the Fedora infrastructure complexity and difficulty
attracting new packagers is because too much of the compose processes,
which seems very opaque and relatively few people participate in, is
allowed to leak into the packaging processes, in which a lot more
Fedora folks participate.

Even if PDC is the most valuable thing to Fedora composes ever, casual
contributors who only work on packaging should never have to care
about it.

What is PDC's relevance to packagers?
___
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: What has the PDC ever done for us?

[Adam Williamson]

On Thu, 2022-03-17 at 12:34 +0100, Miro Hrončok wrote:
> 
> Where is the sanitation, medicine, education, wine, public order, irrigation, 
> roads, a fresh water system, and public health that the PDC have done for us?
> 
> 
> Serious question: Why do we need PDC? What actual problems does it solve?

It stores the metadata of all composes that have been run, ever. (Well,
when there isn't a bug in the sync, anyway). This is useful in several
ways:

1. It's the best way I know of to figure out what the "previous"
compose was. fedfind implements two ways of doing this, one based on
PDC, one not. Here they are. You judge which is less awful:

https://pagure.io/fedora-qa/fedfind/blob/main/f/src/fedfind/release.py#_1293 
(PDC)
https://pagure.io/fedora-qa/fedfind/blob/main/f/src/fedfind/release.py#_1380 
(not PDC)

2. It's useful if you want to look at the history of, e.g., what
packages were in what composes, or what size images were. The actual
nightly composes are garbage-collected after two weeks, so unless you
have your own stash of their metadata, you cannot find this information
for nightly composes that are more than two weeks old anywhere but PDC.
With the PDC metadata you can chart image sizes or package changes
between nightly composes from five years ago, if you want. Without the
PDC metadata you can only do it for composes we still have around -
final releases, maybe Beta releases - and it's painful even for those
because we don't actually keep the metadata for them in the live trees,
you have to figure out what you want to know from HTTP requests (ugh).

3. It's actually very useful for handling exactly that case of how we
screw up composes when we release them. When we take a compose and
release it as a Beta or Final release, we throw some things away and
move other things around, and because of that, we don't publish the
metadata for it in the repos because it's not exactly correct any more.
But that, well, sucks. If you ask fedfind for the metadata of a final
or Beta release, what it does is find the metadata for the source
compose of that release in PDC, then amend it in a way that reflects
how releng hacked it up, and present you with modified, accurate
metadata:
https://pagure.io/fedora-qa/fedfind/blob/main/f/src/fedfind/release.py#_1876
it's the path there where we *do* find `origmd` (the path where we
*don't* is for handling releases that were done before Pungi 4 / PDC,
and it provides much less complete, synthesized metadata). Once the
original, unmodified composes have been garbage-collected from
https://kojipkgs.fedoraproject.org/compose/ and
https://dl.fedoraproject.org/pub/alt/stage/ , PDC is the *only* place
you can get this metadata.

4. It's the only way I know of for finding out what the compose ID of a
candidate compose was if all you have is its label. For example, for
the Fedora 36 Beta candidate compose, its compose ID was "Fedora-36-
20220311.0", and its label was "Beta-1.1"; if you want to look up "what
compose was 36 Beta-1.1?" the only solid way to do it is in PDC. This
is kind of esoteric, I guess, but for boring reasons I won't go into
it's something I actually need in the release validation process
automation.

5. It's the most convenient way to look up "what version of packages X,
Y and Z were in compose foo?", which fedfind does here:
https://pagure.io/fedora-qa/fedfind/blob/main/f/src/fedfind/release.py#_1320
the only alternatives I know of are to parse HTTP requests, which is
awful and doesn't get you epochs, or grab the entire `rpms.json`
metadata for the compose and parse that, which works but it's nearly
200MB, which is a lot to download just to query five packages. And you
can only do those two if the compose hasn't been garbage-collected (see
point 2). We use this and "previous" compose discovery (point 1) in the
release validation event creation code - we query the versions of
several key packages (e.g. anaconda and gnome-shell) in the current and
'previous' composes, and if any of them has changed, we are more likely
to create a new event than if none of them has changed.
-- 
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net

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

Re: What has the PDC ever done for us?

[Petr Pisar]

V Thu, Mar 17, 2022 at 04:13:44PM +0100, Tomas Hrcka napsal(a):
> On Thu, Mar 17, 2022 at 3:09 PM Petr Pisar  wrote:
> > Having the dist-git retirement as a primary source of truth has the problem
> > that you need to clone a dist-git branch to get the data. And then for each
> > package you are interested again and again. Whereas PDC, being a database
> > underneath, have the data centralized at one place, and readily available
> > in
> > no time.
> >
> 
> distgit is basically pagure in it has a DB we were thinking about moving
> package-specific data like EOL to in information already stored in the DB
> for each repository.

I cannot parse your sentence. Does it mean there is one database which
stores all the data about all repositories, or does it mean that each
repository has its own database?

Is this Pagure/dist-git database publically accessible for reading?

> This would allow us to use specific EOL for modules.
> 
In modularity I want to deliver the EOL dates to user's YUM repositories so
that "dnf module list" can list them and alert users about EOLed module stream
they use (bug #2054662).

We already have a mechanism for delivering the data to the YUM repositories
.
But the mechanism relies on a manual input
. It's
manual because one of the purposes if the mechanism is delivering which stream
replaces which one. But the EOL dates could be filled automaticaly.

That's why I'm so obsessed with PDC.

-- Petr


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

Re: FESCo wants to know what you use i686 packages for

[Carlos "casep" Sepulveda]

On Wed, 16 Mar 2022 at 13:55, David Cantrell  wrote:

>
> If you use i686 packages for something now, please respond to this thread.
>
>
steam / wine

-- 
"Never, never, in nothing great or small, large or petty, never give in
except to convictions of honour and good sense. Never yield to force; never
yield to the apparently overwhelming might of the enemy.''
Winston Churchill
https://stackoverflow.com/users/3670118/casep
___
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-36-20220317.n.0 compose check report

[Fedora compose checker]

No missing expected images.

Failed openQA tests: 11/229 (x86_64), 10/161 (aarch64)

New failures (same test not failed in Fedora-36-20220316.n.0):

ID: 1179494 Test: x86_64 Server-dvd-iso support_server
URL: https://openqa.fedoraproject.org/tests/1179494
ID: 1179505 Test: x86_64 Server-dvd-iso install_repository_nfs_graphical
URL: https://openqa.fedoraproject.org/tests/1179505
ID: 1179562 Test: x86_64 Workstation-live-iso evince
URL: https://openqa.fedoraproject.org/tests/1179562
ID: 1179634 Test: aarch64 Server-dvd-iso 
install_standard_partition_ext4@uefi
URL: https://openqa.fedoraproject.org/tests/1179634
ID: 1179682 Test: aarch64 Workstation-raw_xz-raw.xz evince@uefi
URL: https://openqa.fedoraproject.org/tests/1179682
ID: 1179827 Test: aarch64 universal install_software_raid@uefi
URL: https://openqa.fedoraproject.org/tests/1179827

Old failures (same test failed in Fedora-36-20220316.n.0):

ID: 1179549 Test: x86_64 Workstation-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/1179549
ID: 1179587 Test: x86_64 KDE-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/1179587
ID: 1179596 Test: x86_64 Silverblue-dvd_ostree-iso evince
URL: https://openqa.fedoraproject.org/tests/1179596
ID: 1179652 Test: aarch64 Server-dvd-iso server_cockpit_basic@uefi
URL: https://openqa.fedoraproject.org/tests/1179652
ID: 1179694 Test: aarch64 Workstation-raw_xz-raw.xz gnome_text_editor@uefi
URL: https://openqa.fedoraproject.org/tests/1179694
ID: 1179696 Test: aarch64 Workstation-raw_xz-raw.xz 
desktop_update_graphical@uefi
URL: https://openqa.fedoraproject.org/tests/1179696
ID: 1179717 Test: x86_64 Workstation-upgrade gnome_text_editor
URL: https://openqa.fedoraproject.org/tests/1179717
ID: 1179718 Test: x86_64 Workstation-upgrade apps_startstop
URL: https://openqa.fedoraproject.org/tests/1179718
ID: 1179721 Test: x86_64 Workstation-upgrade desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/1179721
ID: 1179737 Test: aarch64 Workstation-upgrade gnome_text_editor@uefi
URL: https://openqa.fedoraproject.org/tests/1179737
ID: 1179740 Test: aarch64 Workstation-upgrade desktop_update_graphical@uefi
URL: https://openqa.fedoraproject.org/tests/1179740
ID: 1179771 Test: x86_64 universal install_arabic_language
URL: https://openqa.fedoraproject.org/tests/1179771
ID: 1179772 Test: x86_64 universal install_asian_language
URL: https://openqa.fedoraproject.org/tests/1179772
ID: 1179837 Test: aarch64 universal install_arabic_language@uefi
URL: https://openqa.fedoraproject.org/tests/1179837
ID: 1179845 Test: aarch64 universal install_asian_language@uefi
URL: https://openqa.fedoraproject.org/tests/1179845

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

Old soft failures (same test soft failed in Fedora-36-20220316.n.0):

ID: 1179552 Test: x86_64 Workstation-live-iso desktop_browser
URL: https://openqa.fedoraproject.org/tests/1179552
ID: 1179564 Test: x86_64 Workstation-live-iso eog
URL: https://openqa.fedoraproject.org/tests/1179564
ID: 1179583 Test: x86_64 KDE-live-iso desktop_browser
URL: https://openqa.fedoraproject.org/tests/1179583
ID: 1179594 Test: x86_64 Silverblue-dvd_ostree-iso eog
URL: https://openqa.fedoraproject.org/tests/1179594
ID: 1179599 Test: x86_64 Silverblue-dvd_ostree-iso gnome_text_editor
URL: https://openqa.fedoraproject.org/tests/1179599
ID: 1179602 Test: x86_64 Silverblue-dvd_ostree-iso desktop_browser
URL: https://openqa.fedoraproject.org/tests/1179602
ID: 1179612 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproject.org/tests/1179612
ID: 1179688 Test: aarch64 Workstation-raw_xz-raw.xz eog@uefi
URL: https://openqa.fedoraproject.org/tests/1179688
ID: 1179692 Test: aarch64 Workstation-raw_xz-raw.xz desktop_browser@uefi
URL: https://openqa.fedoraproject.org/tests/1179692
ID: 1179703 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi
URL: https://openqa.fedoraproject.org/tests/1179703
ID: 1179710 Test: x86_64 Workstation-upgrade desktop_browser
URL: https://openqa.fedoraproject.org/tests/1179710
ID: 1179731 Test: aarch64 Workstation-upgrade eog@uefi
URL: https://openqa.fedoraproject.org/tests/1179731
ID: 1179736 Test: aarch64 Workstation-upgrade desktop_browser@uefi
URL: https://openqa.fedoraproject.org/tests/1179736

Passed openQA tests: 146/161 (aarch64), 210/229 (x86_64)

New passes (same test not passed in Fedora-36-20220316.n.0):

ID: 1179614 Test: aarch64 Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload@uefi
URL: https://openqa.fedoraproject.org/tests/1179614
ID: 1179615 Test: aarch64 Minimal-raw_xz-raw.xz base_services_start@uefi
URL: https://openqa.fedoraproject.org/tests/1179615
ID: 1179616 Test: aarch64 Minimal-raw_xz-raw.xz base_update_cli@uefi
URL: https://openqa.fedoraproject.org/tests/1179616

Re: What has the PDC ever done for us?

[Tomas Hrcka]

On Thu, Mar 17, 2022 at 3:09 PM Petr Pisar  wrote:

> V Thu, Mar 17, 2022 at 12:34:52PM +0100, Miro Hrončok napsal(a):
> > What has the PDC [1] ever done for us? It only bough pain and misery to
> me
> > for no apparent benefit.
> >
> >
> > 1) When we retire packages in dist-git, PDC creates another layer of
> delay
> > between dist-git and Koji and another place when synchronization
> regularly
> > breaks.
> >
> >   dist-git retirement -> PDC retirement -> block in Koji
> >
> Maybe dist-git retirement was supposed to disappear, to unify with modules
> work flow:
>
> PDC retirement -+-> block in Koji
> +-> block in dist-git
>
> Having the dist-git retirement as a primary source of truth has the problem
> that you need to clone a dist-git branch to get the data. And then for each
> package you are interested again and again. Whereas PDC, being a database
> underneath, have the data centralized at one place, and readily available
> in
> no time.
>

distgit is basically pagure in it has a DB we were thinking about moving
package-specific data like EOL to in information already stored in the DB
for each repository.
This would allow us to use specific EOL for modules.


>
> Also dist-git retirement provides only a binary information: Is this
> specific
> branch supported, or is it retired now? In contrast, in PDC you can have
> future dates: This branch will be EOLed on that day. That's not important
> for
> packages because they inherit the dates from Fedora release, but in case of
> modules they are pretty indepenent, and unique, hence this feature is
> important. E.g. I used it last two weeks pretty heavily when I, instead of
> relents, was rebuilding all modules for Fedora 37. Without looking into PDC
> I would have no clue whether a maintain wants that module in Fedora 37, or
> not.
>
> Also don't forget that unretiring packages works differently from the
> retirement:
>
> PDC unretirement -+-> unblock in Koji
>   +-> unblock in dist-git
>
> In practise you need to file an unretirment request to relengs queue in
> Pagure. You cannot drive it from dist-git. And once the request is
> fulfilled,
> you need manually to remove the retiring commit. What will happen if
> a packager does not revert it? Will we have infrastrucutre in an
> inconsistent
> state?
>
> In the end, PDC-first work flow is symetric and does not clutter dist-git
> with
> dead_package files.
>
> > 2) Rawhide packages have arbitrary EOL dates, such as -01-01.
> >
> > 3) Even many of the modular packages have arbitrary EOL dates because
> > maintainers don't know the EOL date beforehand.
> >
> That means there is a need for un undefined/missing EOL which should be
> interpreted as "supported at any time you ask for". Once known, the EOL
> date
> can be changed. Relengs have a template for it in their Pagure queue.
>
> > 4) Packages for branched Fedoras have "epxected" EOLs, such as 2022-11-26
> > for Fedora 35. Repeatedly, this has prevented packagers from updating
> their
> > packages in soon-to-EOL Fedoras when the date of EOL was changed, but
> not in
> > PDC.
> >
> I lived under impression that package EOLs are inherited from Fedora
> prodcut
> release. Not only as work flow but also as implementation in PDC. Hence the
> date is not multiplicated for each package in PDC.
>

Package EOL is set by releng during the branching process for each package.


>
> > Serious question: Why do we need PDC? What actual problems does it solve?
> >
>

I am asking this question myself for a year, spending some time on
use-cases we have, and creating initiative for the CPE team.
https://pagure.io/cpe/initiatives-proposal/issue/5

The short answer is none and it causes some. And I didn't even start about
that last commit in the project is years ago.


> You should ask sochotni. I think he was at design of the service.
>
> I think a purpose of PDC was to handle release life cycle from the product
> top
> level to RPM components on the bottom level. But Fedora has never
> onboarded to
> that. Mainly because there was a huge migration to Pagure at the same time
> and relengs had hands full of work on it.
>
> (A sideway rant: And now when Pagure more or less caught feature parity of
> the
> previous solution, we are going to abandone it. It reminds me a plague of
> Linux desktop environments.)
>
> Maybe if don't need PDC for handling EOLs, do we actually need blocking
> retired packags from dist-git and Koji? What's the point?
>
> -- Petr
> ___
> 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:
>

Re: FESCo wants to know what you use i686 packages for

[Aaron Stern via devel]

I use wine and would need 32bit gstreamer; base, good, bad, ugly and libav for 
some Visual Novels that use MPEG for video.
___
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: FESCo wants to know what you use i686 packages for

[Marius Schwarz]

Am 16.03.22 um 14:54 schrieb David Cantrell:

If you use i686 packages for something now, please respond to this thread.


mainly for Wine 32 bit compatibility, which is still a think with 
windows-software today :(


Best regards,
Marius

___
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: FESCo wants to know what you use i686 packages for

[Tom Seewald]

The i686 packages I use are: gamemode, gperftools-devel (to provide a working 
version of libtcmalloc_minimal), SDL2, steam, and their dependencies.
___
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: What has the PDC ever done for us?

[Petr Pisar]

V Thu, Mar 17, 2022 at 12:34:52PM +0100, Miro Hrončok napsal(a):
> What has the PDC [1] ever done for us? It only bough pain and misery to me
> for no apparent benefit.
> 
> 
> 1) When we retire packages in dist-git, PDC creates another layer of delay
> between dist-git and Koji and another place when synchronization regularly
> breaks.
> 
>   dist-git retirement -> PDC retirement -> block in Koji
> 
Maybe dist-git retirement was supposed to disappear, to unify with modules
work flow:

PDC retirement -+-> block in Koji
+-> block in dist-git

Having the dist-git retirement as a primary source of truth has the problem
that you need to clone a dist-git branch to get the data. And then for each
package you are interested again and again. Whereas PDC, being a database
underneath, have the data centralized at one place, and readily available in
no time.

Also dist-git retirement provides only a binary information: Is this specific
branch supported, or is it retired now? In contrast, in PDC you can have
future dates: This branch will be EOLed on that day. That's not important for
packages because they inherit the dates from Fedora release, but in case of
modules they are pretty indepenent, and unique, hence this feature is
important. E.g. I used it last two weeks pretty heavily when I, instead of
relents, was rebuilding all modules for Fedora 37. Without looking into PDC
I would have no clue whether a maintain wants that module in Fedora 37, or
not.

Also don't forget that unretiring packages works differently from the
retirement:

PDC unretirement -+-> unblock in Koji
  +-> unblock in dist-git

In practise you need to file an unretirment request to relengs queue in
Pagure. You cannot drive it from dist-git. And once the request is fulfilled,
you need manually to remove the retiring commit. What will happen if
a packager does not revert it? Will we have infrastrucutre in an inconsistent
state?

In the end, PDC-first work flow is symetric and does not clutter dist-git with
dead_package files.

> 2) Rawhide packages have arbitrary EOL dates, such as -01-01.
> 
> 3) Even many of the modular packages have arbitrary EOL dates because
> maintainers don't know the EOL date beforehand.
> 
That means there is a need for un undefined/missing EOL which should be
interpreted as "supported at any time you ask for". Once known, the EOL date
can be changed. Relengs have a template for it in their Pagure queue.

> 4) Packages for branched Fedoras have "epxected" EOLs, such as 2022-11-26
> for Fedora 35. Repeatedly, this has prevented packagers from updating their
> packages in soon-to-EOL Fedoras when the date of EOL was changed, but not in
> PDC.
>
I lived under impression that package EOLs are inherited from Fedora prodcut
release. Not only as work flow but also as implementation in PDC. Hence the
date is not multiplicated for each package in PDC.

> Serious question: Why do we need PDC? What actual problems does it solve?
> 
You should ask sochotni. I think he was at design of the service.

I think a purpose of PDC was to handle release life cycle from the product top
level to RPM components on the bottom level. But Fedora has never onboarded to
that. Mainly because there was a huge migration to Pagure at the same time
and relengs had hands full of work on it.

(A sideway rant: And now when Pagure more or less caught feature parity of the
previous solution, we are going to abandone it. It reminds me a plague of
Linux desktop environments.)

Maybe if don't need PDC for handling EOLs, do we actually need blocking
retired packags from dist-git and Koji? What's the point?

-- Petr


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

Fedora 36 compose report: 20220317.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-36-20220316.n.0
NEW: Fedora-36-20220317.n.0

= SUMMARY =
Added images:3
Dropped images:  1
Added packages:  0
Dropped packages:0
Upgraded packages:   8
Downgraded packages: 0

Size of added packages:  0 B
Size of dropped packages:0 B
Size of upgraded packages:   21.57 MiB
Size of downgraded packages: 0 B

Size change of upgraded packages:   988.06 KiB
Size change of downgraded packages: 0 B

= ADDED IMAGES =
Image: Minimal raw-xz aarch64
Path: Spins/aarch64/images/Fedora-Minimal-36-20220317.n.0.aarch64.raw.xz
Image: Container_Minimal_Base docker ppc64le
Path: 
Container/ppc64le/images/Fedora-Container-Minimal-Base-36-20220317.n.0.ppc64le.tar.xz
Image: KDE raw-xz aarch64
Path: Spins/aarch64/images/Fedora-KDE-36-20220317.n.0.aarch64.raw.xz

= DROPPED IMAGES =
Image: Cloud_Base tar-gz x86_64
Path: Cloud/x86_64/images/Fedora-Cloud-Base-GCP-36-20220316.n.0.x86_64.tar.gz

= ADDED PACKAGES =

= DROPPED PACKAGES =

= UPGRADED PACKAGES =
Package:  NetworkManager-fortisslvpn-1.4.0-1.fc36
Old package:  NetworkManager-fortisslvpn-1.3.90-13.fc36
Summary:  NetworkManager VPN plugin for Fortinet compatible SSLVPN
RPMs: NetworkManager-fortisslvpn NetworkManager-fortisslvpn-gnome
Size: 756.34 KiB
Size change:  92.34 KiB
Changelog:
  * Fri Mar 11 2022 Lubomir Rintel  - 1.4.0-1
  - Update to 1.4.0 release


Package:  NetworkManager-libreswan-1.2.16-1.fc36
Old package:  NetworkManager-libreswan-1.2.14-4.fc36
Summary:  NetworkManager VPN plug-in for IPsec VPN
RPMs: NetworkManager-libreswan NetworkManager-libreswan-gnome
Size: 829.57 KiB
Size change:  43.04 KiB
Changelog:
  * Fri Mar 11 2022 Lubomir Rintel  - 1.2.16-4
  - Update to 1.2.16 release


Package:  NetworkManager-openconnect-1.2.8-1.fc36
Old package:  NetworkManager-openconnect-1.2.6-9.fc36
Summary:  NetworkManager VPN plugin for openconnect
RPMs: NetworkManager-openconnect NetworkManager-openconnect-gnome
Size: 2.87 MiB
Size change:  535.95 KiB
Changelog:
  * Fri Mar 11 2022 Adam Williamson  - 1.2.8-1
  - Update to 1.2.8 release


Package:  NetworkManager-openvpn-1:1.8.18-1.fc36
Old package:  NetworkManager-openvpn-1:1.8.16-1.fc36.1
Summary:  NetworkManager VPN plugin for OpenVPN
RPMs: NetworkManager-openvpn NetworkManager-openvpn-gnome
Size: 1.72 MiB
Size change:  150.29 KiB
Changelog:
  * Fri Mar 11 2022 Lubomir Rintel  - 1:1.8.18-1
  - Update to 1.8.18 release


Package:  NetworkManager-pptp-1:1.2.10-1.fc36
Old package:  NetworkManager-pptp-1:1.2.8-5.fc36
Summary:  NetworkManager VPN plugin for PPTP
RPMs: NetworkManager-pptp NetworkManager-pptp-gnome
Size: 965.74 KiB
Size change:  65.32 KiB
Changelog:
  * Fri Mar 11 2022 Lubomir Rintel  - 1.2.10-1
  - Update to 1.2.10 release


Package:  NetworkManager-vpnc-1:1.2.8-1.fc36
Old package:  NetworkManager-vpnc-1:1.2.6-9.fc36
Summary:  NetworkManager VPN plugin for vpnc
RPMs: NetworkManager-vpnc NetworkManager-vpnc-gnome
Size: 1.03 MiB
Size change:  105.49 KiB
Changelog:
  * Fri Mar 11 2022 Lubomir Rintel  - 1:1.2.8-1
  - Update to 1.2.8 release


Package:  abrt-2.15.1-1.fc36
Old package:  abrt-2.15.0-3.fc36
Summary:  Automatic bug detection and reporting tool
RPMs: abrt abrt-addon-ccpp abrt-addon-kerneloops abrt-addon-pstoreoops 
abrt-addon-upload-watch abrt-addon-vmcore abrt-addon-xorg abrt-atomic abrt-cli 
abrt-console-notification abrt-dbus abrt-desktop abrt-devel abrt-gui 
abrt-gui-devel abrt-gui-libs abrt-libs abrt-plugin-bodhi abrt-plugin-machine-id 
abrt-retrace-client abrt-tui python3-abrt python3-abrt-addon 
python3-abrt-container-addon python3-abrt-doc
Size: 6.44 MiB
Size change:  -53.76 KiB
Changelog:
  * Thu Mar 10 2022 Michal Srb  - 2.15.1-1
  - Update to 2.15.1


Package:  libreport-2.17.1-1.fc36
Old package:  libreport-2.17.0-1.fc36
Summary:  Generic library for reporting various problems
RPMs: libreport libreport-anaconda libreport-centos libreport-cli 
libreport-devel libreport-fedora libreport-filesystem libreport-gtk 
libreport-gtk-devel libreport-newt libreport-plugin-bugzilla 
libreport-plugin-kerneloops libreport-plugin-logger libreport-plugin-mailx 
libreport-plugin-mantisbt libreport-plugin-reportuploader 
libreport-plugin-systemd-journal libreport-plugin-ureport libreport-web 
libreport-web-devel python3-libreport
Size: 7.02 MiB
Size change:  49.40 KiB
Changelog:
  * Thu Mar 10 2022 Packit Service  - 
2.17.1-1
  - Release version 2.17.1 (Michal Srb)
  - reporter-bugzilla: send API key in HTTP header (Michal Srb)
  - tito: Use custom tagger that updates changelog (Mat??j Grabovsk??)
  - changelog: Fix link to release diff (Mat??j Grabovsk??)
  - reporter-bugzilla: Fix APIKey name (Michal Fabik)
  - Update translations (mgrabovsky)
  - Add missing va_end (Michal ??idek)



= DOWNGRADED PACKAGES

Re: What has the PDC ever done for us?

[Miroslav Suchý]

Dne 17. 03. 22 v 12:34 Miro Hrončok napsal(a):
Where is the sanitation, medicine, education, wine, public order, irrigation, roads, a fresh water system, and public 
health that the PDC have done for us? 


ABRT uses PDC to (automaticaly) determine which release is active, what Fedora 
versions we have.

Miroslav
___
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: Orphaning deltarpm

[Miroslav Suchý]

Dne 14. 03. 22 v 23:23 John Reiser napsal(a):

The default /etc/dnf/dnf.conf lists only a few options
with no individual documentation, and contains no explicit pointer
to more documentation.  I expect better: all reasonable attempts
should lead quickly to the relevant documentation.  This is the meaning
of "good discoverability".  If I get anywhere close, then I should
find the answer or a direct pointer to the answer.  Enable
multiple pathways (both the main manual page AND the configuration tile
should point to "man 5 dnf.conf") so as to reduce the number of steps. 


Make a wish

https://github.com/rpm-software-management/dnf/pull/1820

Miroslav
___
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: FESCo wants to know what you use i686 packages for

[Adam Jackson]

On Thu, Mar 17, 2022 at 6:25 AM Richard W.M. Jones  wrote:
>
> On Thu, Mar 17, 2022 at 11:10:12AM +0100, Florian Weimer wrote:
> > * Richard W. M. Jones:
> >
> > > On Wed, Mar 16, 2022 at 07:27:05PM -0400, Demi Marie Obenour wrote:
> > >> Native compilation on 32-bit is a dead end.
> > >
> > > And I was going to add that this is wrong - 32 bit chroots running on
> > > 64 bit hosts work fine and run at full speed.
> >
> > No, not for everyone, they don't.  Some Fedora packages need more than a
> > 32-bit address space to build, and that becomes more and more common.
>
> This is true, but what proportion of packages does this really affect?
> Also it's stuff like Firefox that we wouldn't want to compile for 32 bit
> anyway.

See my earlier comment about llvm and OpenGL.

- ajax
___
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: FESCo wants to know what you use i686 packages for

[Gerd Hoffmann]

  Hi,

> > +1 on cross-compilation.  Native compilation on 32-bit is a dead end.
> 
> Cross-compilation isn't really practical for RPMs the way we do things
> now.  We would have to go all-in the way OpenSUSE has done, but that's
> a huge change.

cross builds is a thing for kernel and firmware though and will continue
to be.  Those are freestanding though and don't need much beyond
cross-gcc and cross-binutils (and in i686 case not even that, -m32 will
do).

take care,
  Gerd
___
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: Singular soname bump and a review swap

[Paulo César Pereira de Andrade]

Em sex., 11 de mar. de 2022 às 18:42, Jerry James
 escreveu:
>
> HI Paulo,

  Hi Jerry,

> It's great to hear from you.  I hope you are well.

  Sorry for again taking a bit long to respond :( I have sagemath 9.5 built
locally for almost a month, but I will not interfere with your work right
now, and it is only in a somewhat hackish mode, it just builds :)

> On Wed, Mar 9, 2022 at 4:42 AM Paulo César Pereira de Andrade
>  wrote:
> >   If nobody takes it, I can review.
>
> Ankur took it already.  On the other hand, he doesn't seem to have
> actually started the review yet...
>
> >   I was about to ask for a review as well, as I have my own version locally 
> > :)
>
> Ah, sorry, didn't mean to duplicate effort.
>
> >   Did not double check if already done, but will need to change L-function 
> > to
> > use the sage spkg as upstream is no longer available. This will also need a
> > library major downgrade. But only sagemath uses it, so not a major issue.
> > Optionally, could work on renaming  the L-function package to lcalc, to 
> > match
> > what it is being called in the past 6+ years...
>
> Yes, that's on the list.  This is what I had lined up to do next week
> sometime, after the python-primecountpy review is completed.
>
> - Update L-function to 2.0.5.  I did not notice that this changes the
> L-function soname downwards.  Ugh.  Still, as you say, that should be
> okay since sagemath is the only consumer.  I had added a comment at
> the top of the spec file noting that we should rename it "lcalc". :-)
> - Update python-cysignals to 1.11.2
> - Update Singular to 4.2.1p3
> - Update sympy to 1.10
> - Add python-primecountpy 0.1.0
> - Rebuild polymake due to the Singular update
> - Rebuild python-pysingular due to the Singular update
> - Update sagemath to 9.5
> - Retire pynac, which has been absorbed into sagemath
>
> Is there any of that you would prefer to do yourself?  I don't want to
> step on your toes at all.  Or if you would like to see the changes I'm
> planning to make to any of those packages, I'm happy to share the spec
> files and relevant patches with you.

  Feel free to send me a message if you want me to do some of
the tasks, otherwise you can do the full update.

> And then I'm going back to trying to retire from tending mathematical
> packages in Fedora.  If you want any of the packages I currently
> maintain, let me know and I will transfer them to you.  Regards,

  Sure, no problems :)

> --
> Jerry James
> http://www.jamezone.org/

Thanks!
Paulo
___
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: only 4 packages left Re: Let's retire original glib and gtk+ (new report)

[Richard Shaw]

On Thu, Mar 17, 2022 at 12:16 AM Sérgio Basto  wrote:

> xconvers (maintained by: hobbes1069)
> xconvers-0.8.3-29.fc36.x86_64 requires libglib-1.2.so.0()(64bit)
>
> still only available on aur and Fedora
> https://repology.org/project/xconvers/versions


This can probably be retired. I'll check on the Fedora Linux Hams mailing
list and see if there's any response.

Thanks,
Richard
___
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: only 4 packages left Re: Let's retire original glib and gtk+ (new report)

[Petr Pisar]

V Thu, Mar 17, 2022 at 08:36:55AM -, Leigh Scott napsal(a):
> > On Thu, 2022-03-10 at 00:15 +0200, Otto Urpelainen wrote:
> > xvattr (maintained by: ppisar, thias)
> > gxvattr-1.3-44.fc36.x86_64 requires libgdk-1.2.so.0()(64bit), libglib-
> > 1.2.so.0()(64bit), libgtk-1.2.so.0()(64bit)
> > 
> > seems xvattr can be build with gtk2 
> > http://sophie.zarb.org/rpms/88281125c921a2cc60abf2eea23e54de/deps
> 
I disabled GTK in xvattr-1.3-45.fc37.

-- Petr


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

Re: FESCo wants to know what you use i686 packages for

[Vitaly Zaitsev via devel]

On 17/03/2022 11:24, Richard W.M. Jones wrote:

This is true, but what proportion of packages does this really affect?


Telegram Desktop (and tdlib) requires more than 16 GB of RAM.

--
Sincerely,
  Vitaly Zaitsev (vit...@easycoding.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

What has the PDC ever done for us?

[Miro Hrončok]

Hello Fedora packagers.

What has the PDC [1] ever done for us? It only bough pain and misery to me for 
no apparent benefit.



1) When we retire packages in dist-git, PDC creates another layer of delay 
between dist-git and Koji and another place when synchronization regularly breaks.


  dist-git retirement -> PDC retirement -> block in Koji


2) Rawhide packages have arbitrary EOL dates, such as -01-01.


3) Even many of the modular packages have arbitrary EOL dates because 
maintainers don't know the EOL date beforehand.



4) Packages for branched Fedoras have "epxected" EOLs, such as 2022-11-26 for 
Fedora 35. Repeatedly, this has prevented packagers from updating their 
packages in soon-to-EOL Fedoras when the date of EOL was changed, but not in PDC.



5) Many packagers don't know PDC at all, they only observe "random weirdness".



Where is the sanitation, medicine, education, wine, public order, irrigation, 
roads, a fresh water system, and public health that the PDC have done for us?



Serious question: Why do we need PDC? What actual problems does it solve?


[1] https://pdc.fedoraproject.org/
--
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: FESCo wants to know what you use i686 packages for

[Neal Gompa]

On Thu, Mar 17, 2022 at 6:25 AM Richard W.M. Jones  wrote:
>
> On Thu, Mar 17, 2022 at 11:10:12AM +0100, Florian Weimer wrote:
> > * Richard W. M. Jones:
> >
> > > On Wed, Mar 16, 2022 at 07:27:05PM -0400, Demi Marie Obenour wrote:
> > >> Native compilation on 32-bit is a dead end.
> > >
> > > And I was going to add that this is wrong - 32 bit chroots running on
> > > 64 bit hosts work fine and run at full speed.
> >
> > No, not for everyone, they don't.  Some Fedora packages need more than a
> > 32-bit address space to build, and that becomes more and more common.
>
> This is true, but what proportion of packages does this really affect?
> Also it's stuff like Firefox that we wouldn't want to compile for 32 bit
> anyway.
>

It affects three major categories:

* Go/Rust (or anything static build+linking) since they need memory to
load all sources and object code to compile
* Firefox (because of Rust)
* Chromium (because it does a unity build with gigabytes of C and C++
source code)



-- 
真実はいつも一つ！/ 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: FESCo wants to know what you use i686 packages for

[Richard W.M. Jones]

On Thu, Mar 17, 2022 at 11:10:12AM +0100, Florian Weimer wrote:
> * Richard W. M. Jones:
> 
> > On Wed, Mar 16, 2022 at 07:27:05PM -0400, Demi Marie Obenour wrote:
> >> Native compilation on 32-bit is a dead end.
> >
> > And I was going to add that this is wrong - 32 bit chroots running on
> > 64 bit hosts work fine and run at full speed.
> 
> No, not for everyone, they don't.  Some Fedora packages need more than a
> 32-bit address space to build, and that becomes more and more common.

This is true, but what proportion of packages does this really affect?
Also it's stuff like Firefox that we wouldn't want to compile for 32 bit
anyway.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/
___
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: FESCo wants to know what you use i686 packages for

[Florian Weimer]

* Daniel P. Berrangé:

> Yes, I wouldn't bother thinking about cross compilation using Fedora,
> except for mingw. For Linux cross compilation it is easier to use
> Debian in a container from your Fedora host.
>
> You can install library / devel packages from any Debian architecture
> no matter what the native arch this. This gives ability to get coverage
> of pretty much every architecture that still matters, and several that
> don't. Especially useful is that you can get big-endian build coverage.
> It isn't worth special casing the i686 arch to use Fedora if you also
> case about other archs IMHO.

I agree that the Debian approach is very nice: it reuses outputs from
native builds for cross-compilation.  That side-steps a lot of the
issues inherent to cross-compilation.

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

Re: FESCo wants to know what you use i686 packages for

[Florian Weimer]

* Richard W. M. Jones:

> On Wed, Mar 16, 2022 at 07:27:05PM -0400, Demi Marie Obenour wrote:
>> Native compilation on 32-bit is a dead end.
>
> And I was going to add that this is wrong - 32 bit chroots running on
> 64 bit hosts work fine and run at full speed.

No, not for everyone, they don't.  Some Fedora packages need more than a
32-bit address space to build, and that becomes more and more common.

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

Re: Missing 'pkgconfig(portaudiocpp) >= 12' for EPEL9

[Dominik 'Rathann' Mierzejewski]

Hello, Luya.

On Thursday, 17 March 2022 at 04:20, Luya Tshimbalanga wrote:
> Hello team, it looks like 'pkgconfig(portaudiocpp) >= 12' is missing in
> EPEL9 repository while available in EPEL8.
> 
> See https://koji.fedoraproject.org/koji/taskinfo?taskID=84302098
> 
> Could someone port that dependency and rebuild xournalpp please?

https://bugzilla.redhat.com/show_bug.cgi?id=2063423
I can't until the dependency chain is in place:
portaudio -> jack-audio-connection-kit -> libffado ->
dbus-c++ / libxml++ / libiec61883 -> libraw1394

Regards,
Dominik
-- 
Fedora   https://getfedora.org  |  RPM Fusion  http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Fedora-Cloud-34-20220317.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-20220316.0):

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

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: FESCo wants to know what you use i686 packages for

[Matyáš Kroupa]

Hi,
I use wine and steam (and some libraries which are required to run them) with 
total of 254 i686 packages.
Matyáš
___
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: FESCo wants to know what you use i686 packages for

[Daniel P . Berrangé]

On Thu, Mar 17, 2022 at 09:07:50AM +, Richard W.M. Jones wrote:
> On Wed, Mar 16, 2022 at 07:27:05PM -0400, Demi Marie Obenour wrote:
> > On 3/16/22 10:35, Robbie Harwood wrote:
> > > David Cantrell  writes:
> > > 
> > >> Why?  Since the removal of the i686 kernel in Fedora, we want to
> > >> reduce the number of i686 packages provided in the repo.  As time
> > >> marches on, the ability to build a lot of things for i686 becomes
> > >> unrealistic or even impossible.  Remember it goes beyond providing
> > >> builds...providing support, bug fixes, and security fixes for those
> > >> packages too.  Maybe some things using i686 packages now can move to
> > >> x86_64 packages.  We do not know yet, but a goal is to figure out what
> > >> packages, if anything, can drop their i686 builds.
> > >>
> > >> NOTE: Nothing is changing now.  We are in an information gathering
> > >> phase.  
> > >>
> > >> If you use i686 packages for something now, please respond to this 
> > >> thread.
> > > 
> > > Nothing that couldn't be cross-built and provided as an x86_64 package.
> > > 
> > > I use wine, which as I understand it, requires 32-bit libraries to run
> > > 32-bit Windows binaries.
> > > 
> > > Given the weakness of x86 ASLR, it makes sense to ensure most of the
> > > i686 packages aren't actually getting used (e.g., no browsers).  At that
> > > point, seems like we'd be better off not building for the arch at all,
> > > and doing cross-builds from x86_64 for the packages that need it.
> > 
> > +1 on cross-compilation.  Native compilation on 32-bit is a dead end.
> 
> Cross-compilation isn't really practical for RPMs the way we do things
> now.  We would have to go all-in the way OpenSUSE has done, but that's
> a huge change.

Yes, I wouldn't bother thinking about cross compilation using Fedora,
except for mingw. For Linux cross compilation it is easier to use
Debian in a container from your Fedora host.

You can install library / devel packages from any Debian architecture
no matter what the native arch this. This gives ability to get coverage
of pretty much every architecture that still matters, and several that
don't. Especially useful is that you can get big-endian build coverage.
It isn't worth special casing the i686 arch to use Fedora if you also
case about other archs IMHO.

Of course to actually run the unit tests, you would still need QEMU
usermode emulation, except in the x86_64:i686 combination case.

In libvirt/qemu upstream we Debian based containers to cross compile 
for aarch64, armv6, armv7, i686, mips, mipsel, mips64el, ppc64el,
s390x. Some examples:

https://gitlab.com/libvirt/libvirt/-/blob/master/ci/containers/debian-11-cross-s390x.Dockerfile
https://gitlab.com/libvirt/libvirt/-/blob/master/ci/containers/debian-11-cross-i686.Dockerfile

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

Re: VERY late notification emails

[Vít Ondruch]

Dne 07. 03. 22 v 19:12 Kevin Fenzi napsal(a):

I watched it over the weekend, and now it's only 3 days behind. ;(
Hopefully it will finish catching up... I'm continuing to watch it.



It eventually caught up and I have received the notifications on time up 
until 2022-03-16 15:49:09 UTC. After that moment, the next two 
notification were delayed ~10 minutes, and the following notification 
from 2022-03-16 16:31:13 UTC I have received on Thu, 17 Mar 2022 
01:54:03 -0700 (PDT), i.e. 2022-03-17 08:54:03 UTC.


So is 2022-03-16 15:49:09 UTC the approximate time when the service 
crashed and 2022-03-17 08:54:03 UTC the time of restart?



Vít




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: FESCo wants to know what you use i686 packages for

[Richard W.M. Jones]

On Wed, Mar 16, 2022 at 07:27:05PM -0400, Demi Marie Obenour wrote:
> Native compilation on 32-bit is a dead end.

And I was going to add that this is wrong - 32 bit chroots running on
64 bit hosts work fine and run at full speed.  (Or 32 bit VMs, but you
need to still build kernel.i686 which we don't).

Rich.

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

Re: FESCo wants to know what you use i686 packages for

[Richard W.M. Jones]

On Wed, Mar 16, 2022 at 07:27:05PM -0400, Demi Marie Obenour wrote:
> On 3/16/22 10:35, Robbie Harwood wrote:
> > David Cantrell  writes:
> > 
> >> Why?  Since the removal of the i686 kernel in Fedora, we want to
> >> reduce the number of i686 packages provided in the repo.  As time
> >> marches on, the ability to build a lot of things for i686 becomes
> >> unrealistic or even impossible.  Remember it goes beyond providing
> >> builds...providing support, bug fixes, and security fixes for those
> >> packages too.  Maybe some things using i686 packages now can move to
> >> x86_64 packages.  We do not know yet, but a goal is to figure out what
> >> packages, if anything, can drop their i686 builds.
> >>
> >> NOTE: Nothing is changing now.  We are in an information gathering
> >> phase.  
> >>
> >> If you use i686 packages for something now, please respond to this thread.
> > 
> > Nothing that couldn't be cross-built and provided as an x86_64 package.
> > 
> > I use wine, which as I understand it, requires 32-bit libraries to run
> > 32-bit Windows binaries.
> > 
> > Given the weakness of x86 ASLR, it makes sense to ensure most of the
> > i686 packages aren't actually getting used (e.g., no browsers).  At that
> > point, seems like we'd be better off not building for the arch at all,
> > and doing cross-builds from x86_64 for the packages that need it.
> 
> +1 on cross-compilation.  Native compilation on 32-bit is a dead end.

Cross-compilation isn't really practical for RPMs the way we do things
now.  We would have to go all-in the way OpenSUSE has done, but that's
a huge change.

Rich.

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

Re: FESCo wants to know what you use i686 packages for

[Richard W.M. Jones]

On Wed, Mar 16, 2022 at 09:54:12AM -0400, David Cantrell wrote:
> If you use i686 packages for something now, please respond to this thread.

(1) To compile 32 bit binaries using gcc -m32.

Note that I don't actually care about using these binaries, I use them
only to run the test suite for various projects in order to find
implicit 64 bit assumptions in code, such as incorrect use of int
instead of size_t.  One day maybe 32 bit will be completely dead (like
16 bit) and I won't care about this.

(2) To run some 32 bit binaries.

This is getting rare now since I got rid of rubbish like Webex from my
life, but happens occasionally.

(3) Needed by Wine (?)

I understand from existing conversations that 32 bit Wine needs the
*.i686 packages. I use Wine quite a bit to test Windows cross-compiled
builds, so I guess I'm using this.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top
___
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-20220317.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-20220316.0):

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

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: Curl-minimal as default (System-Wide Change proposal)

[Kamil Dudka]

On Wednesday, March 16, 2022 1:06:34 PM CET Neal Gompa wrote:
> > For completeness, here is a pull request by Miro Hrončok to change the
> > packaging of curl to something that FESCO would like to have for the
> > proposed Fedora change to be accepted:
> >
> >
> >
> > https://src.fedoraproject.org/rpms/curl/pull-request/14
> >
> >
> >
> > Advantages:
> > - libcurl-full can be automatically installed as a dependency in a dnf
> > transaction without the need to use `--allowerasing` or `dnf swap`.
> >
> >
> >
> > Disadvantages:
> > - It is incompatible with the current packaging used since RHEL-8.
> > - It allows to install both libcurl-minimal and libcurl-full together.
> > - It relies on complex RPM scriptlets to manipulate symlinks, which
> > may misbehave in some corner cases, resulting in broken dnf stack.
> >
> >
> 
> 
> Can we just not do this at all?

Yes, that sounds like a reasonable thing to do at this point.  I wanted to 
support the Fedora Minimization Objective but we do not need to do this at 
every cost:

https://docs.fedoraproject.org/en-US/minimization/

I understand the argument of FESCO that the need to use `--allowerasing`
or `dnf swap` while upgrading to libcurl-full is not user-friendly at all.

I also appreciate the effort that Miro Hrončok put to preparing the above 
mentioned pull request.  It addresses the main complaint of FESCO but the
cost of the solution is just too high in my view.

For me as a package maintainer of curl in Fedora and RHEL, not doing this 
change will save me a lot of work.  The current packaging is fairly stable
and proven to work since RHEL-8.  If we ever change it, I will have to work 
hard to make sure that upgrades to next versions of RHEL work smoothly.

We can reconsider it later in case dnf becomes more ready for such changes.
I can imagine introduction of some AllowErasing: tag in spec file that would 
make the upgrade to libcurl-full work fully transparently.  Nevertheless, I
do not have enough free time to work on this myself.

Kamil

___
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: only 4 packages left Re: Let's retire original glib and gtk+ (new report)

[Leigh Scott]

> On Thu, 2022-03-10 at 00:15 +0200, Otto Urpelainen wrote:
> 
> Continuing I brought the corrections to Fedora 36 
> https://bodhi.fedoraproject.org/updates/FEDORA-2022-db793ad26c
> 
> Now only 4 packages more gtk1+ depends on glib 
> 
> Depending packages (rawhide) (5): bubblemon gtk+ manedit xconvers
> xvattr
> 
> Depending on: glib (5), 
> 
> bubblemon (maintained by: sham1)
> bubblemon-1.46-31.fc36.x86_64 requires libglib-1.2.so.0()(64bit),
> libgmodule-1.2.so.0()(64bit)
> 
> seems that can be build with gtk2
> https://gitweb.gentoo.org/repo/gentoo.git/tree/x11-plugins/bubblemon/bubb...

Who needs a gtk1 or 2 applet, is there any gtk1 based DE'S?

> 
> xvattr (maintained by: ppisar, thias)
> gxvattr-1.3-44.fc36.x86_64 requires libgdk-1.2.so.0()(64bit), libglib-
> 1.2.so.0()(64bit), libgtk-1.2.so.0()(64bit)
> 
> seems xvattr can be build with gtk2 
> http://sophie.zarb.org/rpms/88281125c921a2cc60abf2eea23e54de/deps


Have you tried gxvattr?, it's completely broken, the gui is unusable even if 
it's ported to gtk2
___
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