[EPEL-devel] Re: python39 in EPEL7

[Carl George]

What do you mean by support?  The only thing EPEL supports (using the
term loosely) is enabling Fedora packagers to branch and build their
packages for EPEL.  Any maintainer of the Fedora python3.9 package (or
any related package necessary for bootstrapping) can request an epel7
branch and start building.  The main thing to be aware of is to comply
with EPEL policy [0], especially the part about not
replacing/disturbing the base distribution.  RHEL7 includes python3,
so an epel7 python3.9 build would need to ensure it doesn't conflict
with any filesystem paths from that package.

[0] https://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies#Policy

On Tue, Mar 30, 2021 at 8:38 AM Pim Rupert  wrote:
>
> Hello,
>
> I am posting to gather if there is enough support to provide python39 in EPEL.
>
> Currently, EL7 users wanting to run modern python apps under uwsgi can only 
> use uwsgi-plugin-pyton36@epel. New Django releases are expected to require 
> 3.8 or higher. There is a rh-python38 SCL, but this version does not have a 
> compatible uwsgi-plugin.
>
> From https://bugzilla.redhat.com/show_bug.cgi?id=1781940 I gather that there 
> is interest in getting python39 in EPEL. I talked to Miro Hrončok, who was 
> willing to work on packaging, if there would be sufficient support from EPEL.
>
> Thanks,
>
> Pim
> ___
> epel-devel mailing list -- epel-devel@lists.fedoraproject.org
> To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it: 
> https://pagure.io/fedora-infrastructure



-- 
Carl George
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: can't login FAS

[Otto Urpelainen]

Honggang LI kirjoitti 6.4.2021 klo 16.03:

On Tue, Apr 06, 2021 at 08:54:42PM +0800, Honggang LI wrote:

On Tue, Apr 06, 2021 at 08:27:52AM -0400, Stephen John Smoogen wrote:

On Mon, 5 Apr 2021 at 22:26, Honggang LI  wrote:

  Hi,
  After input my FAS accout and password, I got this error message.

After input where? What place did you get this error?


https://bodhi.fedoraproject.org/updates/FEDORA-2021-141f8facf2

There is a 'login' button in the web page. Press 'login' button, the
login web page will show up. After input my account and password, the error
message will be displayed in the middle of page.



Sorry, it is my bad. I input my account with the email suffix. But this
error message is really misleading. Maybe a simple message, like "Wrong
account or password", will be helpful.


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

Fedora-IoT-33-20210406.0 compose check report

[Fedora compose checker]

No missing expected images.

Failed openQA tests: 1/15 (aarch64)

Old failures (same test failed in Fedora-IoT-33-20210315.0):

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

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

Old soft failures (same test soft failed in Fedora-IoT-33-20210315.0):

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

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

Installed system changes in test x86_64 IoT-dvd_ostree-iso 
install_default_upload: 
System load changed from 0.11 to 0.29
Previous test data: https://openqa.fedoraproject.org/tests/814746#downloads
Current test data: https://openqa.fedoraproject.org/tests/845893#downloads

Installed system changes in test aarch64 IoT-dvd_ostree-iso 
install_default_upload@uefi: 
System load changed from 0.35 to 0.16
Previous test data: https://openqa.fedoraproject.org/tests/814761#downloads
Current test data: https://openqa.fedoraproject.org/tests/845907#downloads
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[389-devel] please review: PR 4718 - UI - Migrate database tables to Patternfly 4

[Mark Reynolds]

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

--

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

Re: Looking for users of userfaultfd(2) syscall in Fedora

[Florian Weimer]

* Ondrej Mosnacek:

> Kernel 5.12 added support to SELinux for controlling access to the
> userfaultfd interface [1][2] and we'd like to implement this in
> Fedora's selinux-policy. However, once we add the corresponding class
> to the policy, all SELinux domains for which we don't add the
> appropriate rules will have any usage of userfaultfd(2) denied.

What's special about this system call that this is necessary?

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: Looking for users of userfaultfd(2) syscall in Fedora

[Florian Weimer]

* Zbigniew Jędrzejewski-Szmek:

> The code is available. From what I remember, they had a fairly beefy
> server dedicated to the indexing... But if somebody provides that, it
> should be fairly easy to duplicate.

Michael even expressed interest about setting up an instance, if I
recall correctly, but that was quite some time ago.

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: questions about "Fedora Localization Statistics"

[Zbigniew Jędrzejewski-Szmek]

On Tue, Apr 06, 2021 at 05:16:59PM +0100, Tom Hughes wrote:
> On 06/04/2021 16:19, Zbigniew Jędrzejewski-Szmek wrote:
> >On Tue, Apr 06, 2021 at 03:21:26PM +0100, Tom Hughes wrote:
> 
> >>>Specifically those numbers are from the languagePopulation elements
> >>>in the most recent CLDR release.
> >>
> >>The data for DE in PL in CLDR specifically references a source:
> >>
> >> >>uri="http://en.wikipedia.org/wiki/German_minority_in_Poland;>regional-official
> >>in part of Opole Voivodeship; in Poland 325 schools with primary
> >>instr in German, estimate 37000 students. Real figure probably
> >>higher.
> >>
> >>Though the numbers on that page don't get near the 7 million
> >>that is being claimed.
> >
> >Yeah, that seems widely off. Wikipedia says "0.38%" which is in
> >approximate agreement with "0.5%" that I cited above.
> >
> >I wonder how good the data is for other territories.
> 
> There's a big chart of the data, with links for reporting bugs here:
> 
> https://unicode-org.github.io/cldr-staging/charts/38/supplemental/territory_language_information.html

https://unicode-org.atlassian.net/browse/CLDR-14648

I wonder when the urge to file bugs can be classified as pathological ;)

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

Fedora-IoT-34-20210406.0 compose check report

[Fedora compose checker]

No missing expected images.

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

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

ID: 845798  Test: x86_64 IoT-dvd_ostree-iso iot_zezere_server
URL: https://openqa.fedoraproject.org/tests/845798
ID: 845807  Test: x86_64 IoT-dvd_ostree-iso iot_zezere_ignition
URL: https://openqa.fedoraproject.org/tests/845807
ID: 845814  Test: aarch64 IoT-dvd_ostree-iso iot_zezere_server@uefi
URL: https://openqa.fedoraproject.org/tests/845814
ID: 845822  Test: aarch64 IoT-dvd_ostree-iso iot_zezere_ignition@uefi
URL: https://openqa.fedoraproject.org/tests/845822

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

ID: 845804  Test: x86_64 IoT-dvd_ostree-iso base_services_start
URL: https://openqa.fedoraproject.org/tests/845804
ID: 845810  Test: aarch64 IoT-dvd_ostree-iso iot_clevis@uefi
URL: https://openqa.fedoraproject.org/tests/845810
ID: 845815  Test: aarch64 IoT-dvd_ostree-iso base_services_start@uefi
URL: https://openqa.fedoraproject.org/tests/845815

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

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

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

Passed openQA tests: 12/16 (x86_64), 11/15 (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: Looking for users of userfaultfd(2) syscall in Fedora

[Zbigniew Jędrzejewski-Szmek]

On Tue, Apr 06, 2021 at 01:20:33PM -0400, Matthew Miller wrote:
> On Tue, Apr 06, 2021 at 05:16:52PM +, Zbigniew Jędrzejewski-Szmek wrote:
> > https://codesearch.debian.net/search?q=userfaultfd(=1
> > lists a few candidates…
> 
> You beat me to this suggestion. :)
> 
> I'd love for Fedora to someday have a similar service!

Me too ;)

The code is available. From what I remember, they had a fairly beefy
server dedicated to the indexing... But if somebody provides that, it
should be fairly easy to duplicate.

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

Re: Package downgrades from Fedora 33 -> Fedora 34 (including ostree + rpm-ostree)

[Dusty Mabe]

On 4/6/21 10:58 AM, Fabio Valentini wrote:
> On Tue, Apr 6, 2021 at 4:43 PM Colin Walters  wrote:
>>
>> Hi,
>>
>> On Tue, Apr 6, 2021, at 6:42 AM, Fabio Valentini wrote:
>>> Hi everybody,
>>>
>>> It's that time of the year again, and this time there's not that many
>>> downgrades to complain about (packages with "obvious" causes, like
>>> F34FTBFS, already excluded from the list).
>>>
>>> However, the list also includes some pretty important "critpath"
>>> packages (ostree (!), rpm-ostree, libuv, ...), which should probably
>>> be fixed before F34 is released. Shipping with old ostree packages
>>> OOTB seems like a bad idea, especially for the Editions that are built
>>> on top of it.
>>
>> Hi, thanks for raising this.  The two updates are
>> https://bodhi.fedoraproject.org/updates/FEDORA-2021-33f693d20d
>> https://bodhi.fedoraproject.org/updates/FEDORA-2021-971f672259
> 
> Thanks! It would probably be a good idea to request freeze exceptions
> for them sooner rather than later, so testing of the candidate images
> will be done with the new versions.
> 

The following two bugs have been proposed as FE:

- https://bugzilla.redhat.com/show_bug.cgi?id=1946727
- https://bugzilla.redhat.com/show_bug.cgi?id=1946731
___
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: Looking for users of userfaultfd(2) syscall in Fedora

[Matthew Miller]

On Tue, Apr 06, 2021 at 05:16:52PM +, Zbigniew Jędrzejewski-Szmek wrote:
> https://codesearch.debian.net/search?q=userfaultfd(=1
> lists a few candidates…

You beat me to this suggestion. :)

I'd love for Fedora to someday have a similar service!

-- 
Matthew Miller

Fedora Project Leader
___
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: Looking for users of userfaultfd(2) syscall in Fedora

[Daniel P . Berrangé]

On Tue, Apr 06, 2021 at 06:57:27PM +0200, Ondrej Mosnacek wrote:
> Hi all,
> 
> Kernel 5.12 added support to SELinux for controlling access to the
> userfaultfd interface [1][2] and we'd like to implement this in
> Fedora's selinux-policy. However, once we add the corresponding class
> to the policy, all SELinux domains for which we don't add the
> appropriate rules will have any usage of userfaultfd(2) denied.
> 
> Therefore, we would like to identify as many users of this syscall as
> possible before we make that change, so that we can add and test all
> the needed rules in one go, minimizing the amount of denials found
> after the fact. My understanding is that userfaultfd(2) doesn't have
> many users among system services, so it should be possible to catch
> most/all of them in advance.
> 
> So if you know that your (or any other) Fedora component uses
> userfaultfd(2), please let us know. AFAIK, at least QEMU most likely
> uses it, so we'll have that one on our radar, but we'd like to know if
> there are any other programs/services we need to cover.

Yes, QEMU, uses  userfaultfd(2) for its post-copy live migration
feature, so we'll need that allowed in the svirt_t / svirt_tcg_t
types.

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: Looking for users of userfaultfd(2) syscall in Fedora

[Zbigniew Jędrzejewski-Szmek]

On Tue, Apr 06, 2021 at 06:57:27PM +0200, Ondrej Mosnacek wrote:
> Hi all,
> 
> Kernel 5.12 added support to SELinux for controlling access to the
> userfaultfd interface [1][2] and we'd like to implement this in
> Fedora's selinux-policy. However, once we add the corresponding class
> to the policy, all SELinux domains for which we don't add the
> appropriate rules will have any usage of userfaultfd(2) denied.

https://codesearch.debian.net/search?q=userfaultfd(=1
lists a few candidates…

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

Re: Looking for users of userfaultfd(2) syscall in Fedora

[Adrian Reber]

On Tue, Apr 06, 2021 at 06:57:27PM +0200, Ondrej Mosnacek wrote:
> Hi all,
> 
> Kernel 5.12 added support to SELinux for controlling access to the
> userfaultfd interface [1][2] and we'd like to implement this in
> Fedora's selinux-policy. However, once we add the corresponding class
> to the policy, all SELinux domains for which we don't add the
> appropriate rules will have any usage of userfaultfd(2) denied.
> 
> Therefore, we would like to identify as many users of this syscall as
> possible before we make that change, so that we can add and test all
> the needed rules in one go, minimizing the amount of denials found
> after the fact. My understanding is that userfaultfd(2) doesn't have
> many users among system services, so it should be possible to catch
> most/all of them in advance.
> 
> So if you know that your (or any other) Fedora component uses
> userfaultfd(2), please let us know. AFAIK, at least QEMU most likely
> uses it, so we'll have that one on our radar, but we'd like to know if
> there are any other programs/services we need to cover.

CRIU can use userfaultfd to lazy migrate processes from one host to
another. It can be also triggered from runc when migrating containers.
As far as I know userfaultfd based container migration is not exposed in
any container engine above the level of runc.

Adrian


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

Looking for users of userfaultfd(2) syscall in Fedora

[Ondrej Mosnacek]

Hi all,

Kernel 5.12 added support to SELinux for controlling access to the
userfaultfd interface [1][2] and we'd like to implement this in
Fedora's selinux-policy. However, once we add the corresponding class
to the policy, all SELinux domains for which we don't add the
appropriate rules will have any usage of userfaultfd(2) denied.

Therefore, we would like to identify as many users of this syscall as
possible before we make that change, so that we can add and test all
the needed rules in one go, minimizing the amount of denials found
after the fact. My understanding is that userfaultfd(2) doesn't have
many users among system services, so it should be possible to catch
most/all of them in advance.

So if you know that your (or any other) Fedora component uses
userfaultfd(2), please let us know. AFAIK, at least QEMU most likely
uses it, so we'll have that one on our radar, but we'd like to know if
there are any other programs/services we need to cover.

Thanks!

[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=29cd6591ab6fee3125ea5c1bf350f5013bc615e1
[2] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b537900f1598b67bcb8acac20da73c6e26ebbf99
--
Ondrej Mosnacek
Software Engineer, Linux Security - SELinux kernel
Red Hat, Inc.
___
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: questions about "Fedora Localization Statistics"

[Tom Hughes via devel]

On 06/04/2021 16:19, Zbigniew Jędrzejewski-Szmek wrote:

On Tue, Apr 06, 2021 at 03:21:26PM +0100, Tom Hughes wrote:



Specifically those numbers are from the languagePopulation elements
in the most recent CLDR release.


The data for DE in PL in CLDR specifically references a source:

http://en.wikipedia.org/wiki/German_minority_in_Poland;>regional-official
in part of Opole Voivodeship; in Poland 325 schools with primary
instr in German, estimate 37000 students. Real figure probably
higher.

Though the numbers on that page don't get near the 7 million
that is being claimed.


Yeah, that seems widely off. Wikipedia says "0.38%" which is in
approximate agreement with "0.5%" that I cited above.

I wonder how good the data is for other territories.


There's a big chart of the data, with links for reporting bugs here:

https://unicode-org.github.io/cldr-staging/charts/38/supplemental/territory_language_information.html

Tom

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

Re: F35 Change proposal: RPM 4.17 (System-Wide Change proposal)

[Vít Ondruch]

Dne 06. 04. 21 v 16:02 Panu Matilainen napsal(a):

On 4/6/21 1:36 PM, Miro Hrončok wrote:
For example, what is common for Python "namepsace" packages, e.g. 
pkg_name.foo.


1) We want to test installed files, not what is in $PWD, so we set 
PYTHONPATH to

%{buildroot}%{python3_sitearch}:%{buildroot}%{python3_sitelib} and we
    (try hard to) exclude $PWD from it. This is crucial to ensure the 
files

    we actually ship are working and the installed file set is complete.
    Our macros do this for the packagers.

2) The %{python3_site...}/pkg_name/ directory and
    %{python3_site...}/pkg_name/__init__.py and
    %{python3_site...}/pkg_name/__pycache__/ and
    %{python3_site...}/pkg_name/__pycache__/__init__...pyc
    files must be present in %{buildroot} to successfully run the tests.

3) The files from (2) must be excluded from the package because 
*pkg_name* owns

    them, not *pkg_name.foo*.
    We Require the "toplevel" *pkg_name* package from *pkg_name.foo*.
    The files are not bit-by-bit+metadata identical,
    so both packages cannot ship them.


This seems like a fairly exotic case to me - okay, a Python-peculiar 
problem. And a problem of stepping (not saying crossing, because I'm 
not sure it is) on the boundaries of the %check use-case I suppose.


%ghost'ing the files might be one option - I don't know about the Ruby 
cache case beyond that there is one.



There is only `%{gem_cache}` (I assume it was mentioned in the context 
of `%exclude`, because that has nothing to do with testing). Not 
shipping this file is enough and we don't ship it just because we don't 
want to ship file which looks like upstream file but it is not the 
original upstream file. Moreover we don't really need it for the 
purposes it is used by upstream, which is restoring the original state 
of the library.


But since Ruby was mentioned there, we generally run test suite in 
`%{_builddir}` (and there are (unfortunately) two possible location, 
while only one is preferred). Generally, it could be run in 
`%{buildroot}` with similar results, but it should be discouraged due to 
possible `%{buildroot}` pollution.



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

Fedora-34-20210406.n.0 compose check report

[Fedora compose checker]

No missing expected images.

Failed openQA tests: 18/189 (x86_64), 19/127 (aarch64)

New failures (same test not failed in Fedora-34-20210405.n.0):

ID: 844541  Test: x86_64 KDE-live-iso desktop_notifications_live
URL: https://openqa.fedoraproject.org/tests/844541
ID: 844731  Test: aarch64 universal install_blivet_with_swap@uefi
URL: https://openqa.fedoraproject.org/tests/844731
ID: 844748  Test: aarch64 universal install_lvmthin@uefi
URL: https://openqa.fedoraproject.org/tests/844748
ID: 844765  Test: aarch64 universal upgrade_server_domain_controller@uefi
URL: https://openqa.fedoraproject.org/tests/844765
ID: 844776  Test: aarch64 universal upgrade_realmd_client@uefi
URL: https://openqa.fedoraproject.org/tests/844776
ID: 844793  Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/844793
ID: 844794  Test: x86_64 universal upgrade_realmd_client
URL: https://openqa.fedoraproject.org/tests/844794
ID: 844828  Test: aarch64 Server-dvd-iso 
server_freeipa_replication_master@uefi
URL: https://openqa.fedoraproject.org/tests/844828
ID: 844829  Test: aarch64 Server-dvd-iso 
server_freeipa_replication_replica@uefi
URL: https://openqa.fedoraproject.org/tests/844829
ID: 844832  Test: aarch64 Server-dvd-iso 
server_role_deploy_domain_controller@uefi
URL: https://openqa.fedoraproject.org/tests/844832
ID: 844837  Test: aarch64 Server-dvd-iso 
server_freeipa_replication_client@uefi
URL: https://openqa.fedoraproject.org/tests/844837
ID: 844841  Test: aarch64 Server-dvd-iso modularity_tests@uefi
URL: https://openqa.fedoraproject.org/tests/844841
ID: 844845  Test: aarch64 Server-dvd-iso realmd_join_cockpit@uefi
URL: https://openqa.fedoraproject.org/tests/844845
ID: 844847  Test: aarch64 Server-dvd-iso server_realmd_join_kickstart@uefi
URL: https://openqa.fedoraproject.org/tests/844847
ID: 844893  Test: x86_64 Server-dvd-iso server_freeipa_replication_master
URL: https://openqa.fedoraproject.org/tests/844893
ID: 844894  Test: x86_64 Server-dvd-iso server_freeipa_replication_replica
URL: https://openqa.fedoraproject.org/tests/844894
ID: 844895  Test: x86_64 Server-dvd-iso server_freeipa_replication_client
URL: https://openqa.fedoraproject.org/tests/844895
ID: 844914  Test: aarch64 universal upgrade_2_server_domain_controller@uefi
URL: https://openqa.fedoraproject.org/tests/844914
ID: 844915  Test: aarch64 universal upgrade_2_realmd_client@uefi
URL: https://openqa.fedoraproject.org/tests/844915
ID: 844917  Test: aarch64 Server-dvd-iso support_server@uefi
URL: https://openqa.fedoraproject.org/tests/844917
ID: 844919  Test: aarch64 Server-dvd-iso install_updates_nfs@uefi
URL: https://openqa.fedoraproject.org/tests/844919
ID: 844927  Test: aarch64 Server-dvd-iso 
install_repository_hd_variation@uefi
URL: https://openqa.fedoraproject.org/tests/844927
ID: 844930  Test: aarch64 universal install_repository_http_variation@uefi
URL: https://openqa.fedoraproject.org/tests/844930
ID: 844934  Test: x86_64 universal install_blivet_btrfs
URL: https://openqa.fedoraproject.org/tests/844934
ID: 844936  Test: x86_64 KDE-live-iso desktop_login
URL: https://openqa.fedoraproject.org/tests/844936
ID: 844937  Test: x86_64 KDE-live-iso desktop_browser
URL: https://openqa.fedoraproject.org/tests/844937
ID: 844939  Test: x86_64 KDE-live-iso desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/844939
ID: 844940  Test: x86_64 KDE-live-iso desktop_printing
URL: https://openqa.fedoraproject.org/tests/844940
ID: 844943  Test: x86_64 KDE-live-iso desktop_terminal
URL: https://openqa.fedoraproject.org/tests/844943
ID: 844947  Test: x86_64 KDE-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/844947
ID: 844966  Test: x86_64 Server-dvd-iso realmd_join_sssd
URL: https://openqa.fedoraproject.org/tests/844966

Old failures (same test failed in Fedora-34-20210405.n.0):

ID: 844521  Test: x86_64 Workstation-live-iso desktop_login
URL: https://openqa.fedoraproject.org/tests/844521
ID: 844527  Test: x86_64 Workstation-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/844527
ID: 844733  Test: aarch64 universal install_asian_language@uefi
URL: https://openqa.fedoraproject.org/tests/844733
ID: 844802  Test: x86_64 universal install_asian_language
URL: https://openqa.fedoraproject.org/tests/844802
ID: 844889  Test: aarch64 Workstation-raw_xz-raw.xz desktop_browser@uefi
URL: https://openqa.fedoraproject.org/tests/844889
ID: 844942  Test: x86_64 KDE-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/844942

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

Old soft failures (same test soft failed in Fedora-34-20210405.n.0):

ID: 844469  Test: x86_64 Server-dvd-iso install_vncconnect_client
URL: 

[EPEL-devel] [Fedocal] Reminder meeting : EPEL Steering Committee

[tdawson]

Dear all,

You are kindly invited to the meeting:
   EPEL Steering Committee on 2021-04-07 from 16:00:00 to 17:00:00 US/Eastern
   At fedora-meet...@irc.freenode.net

The meeting will be about:
This is the weekly EPEL Steering Committee Meeting.

A general agenda is the following:

#meetingname EPEL
#topic Intros
#topic Old Business
#topic EPEL-7
#topic EPEL-8
#topic EPEL-9
#topic Openfloor
#endmeeting




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

___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[EPEL-devel] [Fedocal] Reminder meeting : EPEL Steering Committee

[tdawson]

Dear all,

You are kindly invited to the meeting:
   EPEL Steering Committee on 2021-04-07 from 16:00:00 to 17:00:00 US/Eastern
   At fedora-meet...@irc.freenode.net

The meeting will be about:
This is the weekly EPEL Steering Committee Meeting.

A general agenda is the following:

#meetingname EPEL
#topic Intros
#topic Old Business
#topic EPEL-7
#topic EPEL-8
#topic EPEL-9
#topic Openfloor
#endmeeting




Source: https://apps.fedoraproject.org/calendar/meeting/9854/

___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: questions about "Fedora Localization Statistics"

[Zbigniew Jędrzejewski-Szmek]

On Tue, Apr 06, 2021 at 03:21:26PM +0100, Tom Hughes wrote:
> On 06/04/2021 15:16, Tom Hughes wrote:
> >On 06/04/2021 14:47, Zbigniew Jędrzejewski-Szmek wrote:
> >
> >>I'm looking at https://languages.stg.fedoraproject.org/territories/pl/,
> >>and it says:
> >>
> >>be (0.58 %)
> >>csb official_regional (0.13 %)
> >>de official_regional (19 %)
> >>en (33 %)
> >>lt official_regional (0.021 %)
> >>pl official (96 %)
> >>ru (18 %)
> >>sli (0.031 %)
> >>szl (1.3 %)
> >>uk (0.39 %)
> >>
> >>I think it's be good to order those items by percentage, rather than
> >>alphabetically.
> >>
> >>But my question is: what are those numbers supposed to _mean_?
> >
> >As the page says the data comes from CLDR and that is documented here:
> >
> >https://unicode.org/reports/tr35/tr35-info.html#Supplemental_Territory_Information

Ah, cool.

"approximate figures for the literate, functional population for each
language in each territory: that is, the population that is able to
read and write each language, and is comfortable enough to use it with
computers."

> >Specifically those numbers are from the languagePopulation elements
> >in the most recent CLDR release.
> 
> The data for DE in PL in CLDR specifically references a source:
> 
>  uri="http://en.wikipedia.org/wiki/German_minority_in_Poland;>regional-official
> in part of Opole Voivodeship; in Poland 325 schools with primary
> instr in German, estimate 37000 students. Real figure probably
> higher.
> 
> Though the numbers on that page don't get near the 7 million
> that is being claimed.

Yeah, that seems widely off. Wikipedia says "0.38%" which is in
approximate agreement with "0.5%" that I cited above.

I wonder how good the data is for other territories.

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

Re: Package downgrades from Fedora 33 -> Fedora 34 (including ostree + rpm-ostree)

[Fabio Valentini]

On Tue, Apr 6, 2021 at 1:01 PM Kalev Lember  wrote:
>
> On Tue, Apr 6, 2021 at 12:43 PM Fabio Valentini  wrote:
>>
>> - libuv-1:1.41.0-1.fc33 > libuv-1:1.40.0-2.fc34
>> - libuv-devel-1:1.41.0-1.fc33 > libuv-devel-1:1.40.0-2.fc34
>> - libuv-static-1:1.41.0-1.fc33 > libuv-static-1:1.40.0-2.fc34
>>
>> libuv 1.41.0 was built for f34, but the bodhi update is stuck (build
>> is mistagged in koji?):
>> https://bodhi.fedoraproject.org/updates/FEDORA-2021-9ab6c1ee93
>
>
> I unpushed the libuv update and queued it to stable again. Hopefully this is 
> enough to fix this.

Apparently that was enough. Thanks!

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: Package downgrades from Fedora 33 -> Fedora 34 (including ostree + rpm-ostree)

[Fabio Valentini]

On Tue, Apr 6, 2021 at 4:43 PM Colin Walters  wrote:
>
> Hi,
>
> On Tue, Apr 6, 2021, at 6:42 AM, Fabio Valentini wrote:
> > Hi everybody,
> >
> > It's that time of the year again, and this time there's not that many
> > downgrades to complain about (packages with "obvious" causes, like
> > F34FTBFS, already excluded from the list).
> >
> > However, the list also includes some pretty important "critpath"
> > packages (ostree (!), rpm-ostree, libuv, ...), which should probably
> > be fixed before F34 is released. Shipping with old ostree packages
> > OOTB seems like a bad idea, especially for the Editions that are built
> > on top of it.
>
> Hi, thanks for raising this.  The two updates are
> https://bodhi.fedoraproject.org/updates/FEDORA-2021-33f693d20d
> https://bodhi.fedoraproject.org/updates/FEDORA-2021-971f672259

Thanks! It would probably be a good idea to request freeze exceptions
for them sooner rather than later, so testing of the candidate images
will be done with the new versions.

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 : Prioritized bugs and issues

[Ben Cotton]

On Tue, Apr 6, 2021 at 7:08 AM  wrote:
>
> You are kindly invited to the meeting:
>Prioritized bugs and issues on 2021-04-07 from 11:00:00 to 12:00:00 
> America/Indiana/Indianapolis
>At fedora-meetin...@irc.freenode.net
>
> More information available at: 
> https://fedoraproject.org/wiki/Fedora_Program_Management/Prioritized_bugs_and_issues_-_the_process
>
> Source: https://apps.fedoraproject.org/calendar/meeting/9788/

There is one nominated bug:

* hangs on execute - https://bugzilla.redhat.com/show_bug.cgi?id=1943382

-- 
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to 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: Package downgrades from Fedora 33 -> Fedora 34 (including ostree + rpm-ostree)

[Colin Walters]

Hi,

On Tue, Apr 6, 2021, at 6:42 AM, Fabio Valentini wrote:
> Hi everybody,
> 
> It's that time of the year again, and this time there's not that many
> downgrades to complain about (packages with "obvious" causes, like
> F34FTBFS, already excluded from the list).
> 
> However, the list also includes some pretty important "critpath"
> packages (ostree (!), rpm-ostree, libuv, ...), which should probably
> be fixed before F34 is released. Shipping with old ostree packages
> OOTB seems like a bad idea, especially for the Editions that are built
> on top of it.

Hi, thanks for raising this.  The two updates are
https://bodhi.fedoraproject.org/updates/FEDORA-2021-33f693d20d
https://bodhi.fedoraproject.org/updates/FEDORA-2021-971f672259
___
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 34 compose report: 20210406.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-34-20210405.n.0
NEW: Fedora-34-20210406.n.0

= SUMMARY =
Added images:7
Dropped images:  0
Added packages:  2
Dropped packages:1
Upgraded packages:   45
Downgraded packages: 0

Size of added packages:  70.99 KiB
Size of dropped packages:2.89 MiB
Size of upgraded packages:   2.96 GiB
Size of downgraded packages: 0 B

Size change of upgraded packages:   -28.19 MiB
Size change of downgraded packages: 0 B

= ADDED IMAGES =
Image: Cloud_Base qcow2 s390x
Path: Cloud/s390x/images/Fedora-Cloud-Base-34-20210406.n.0.s390x.qcow2
Image: Container_Base docker s390x
Path: Container/s390x/images/Fedora-Container-Base-34-20210406.n.0.s390x.tar.xz
Image: Container_Minimal_Base docker s390x
Path: 
Container/s390x/images/Fedora-Container-Minimal-Base-34-20210406.n.0.s390x.tar.xz
Image: Server boot s390x
Path: Server/s390x/iso/Fedora-Server-netinst-s390x-34-20210406.n.0.iso
Image: Everything boot s390x
Path: Everything/s390x/iso/Fedora-Everything-netinst-s390x-34-20210406.n.0.iso
Image: Server dvd s390x
Path: Server/s390x/iso/Fedora-Server-dvd-s390x-34-20210406.n.0.iso
Image: Cloud_Base raw-xz s390x
Path: Cloud/s390x/images/Fedora-Cloud-Base-34-20210406.n.0.s390x.raw.xz

= DROPPED IMAGES =

= ADDED PACKAGES =
Package: paternoster-3.3.0-2.fc34
Summary: Allows to run ansible playbooks like ordinary python or bash scripts
RPMs:paternoster
Size:38.77 KiB

Package: python-hypothesmith-0.1.8-1.fc34
Summary: Hypothesis strategies for generating Python programs
RPMs:python3-hypothesmith
Size:32.21 KiB


= DROPPED PACKAGES =
Package: ansible-base-2.10.5-2.fc34
Summary: A radically simple IT automation system
RPMs:ansible-base ansible-base-doc
Size:2.89 MiB


= UPGRADED PACKAGES =
Package:  FlightGear-2020.3.8-1.fc34
Old package:  FlightGear-2020.3.7-1.fc34
Summary:  The FlightGear Flight Simulator
RPMs: FlightGear
Size: 34.99 MiB
Size change:  -25.27 KiB
Changelog:
  * Tue Mar 30 2021 Fabrice Bellet  - 2020.3.8-1
  - new upstream release


Package:  FlightGear-Atlas-0.5.0-0.68.cvs20141002.fc34
Old package:  FlightGear-Atlas-0.5.0-0.67.cvs20141002.fc34
Summary:  Flightgear map tools
RPMs: FlightGear-Atlas
Size: 3.52 MiB
Size change:  -122 B
Changelog:
  * Tue Mar 30 2021 Fabrice Bellet  - 
0.5.0-0.68.cvs20141002
  - rebuild with newer SimGear


Package:  FlightGear-data-2020.3.8-1.fc34
Old package:  FlightGear-data-2020.3.7-1.fc34
Summary:  FlightGear base scenery and data files
RPMs: FlightGear-data
Size: 1.71 GiB
Size change:  58.23 KiB
Changelog:
  * Tue Mar 30 2021 Fabrice Bellet  - 2020.3.8-1
  - new upstream release


Package:  SimGear-2020.3.8-1.fc34
Old package:  SimGear-2020.3.7-1.fc34
Summary:  Simulation library components
RPMs: SimGear SimGear-devel
Size: 12.07 MiB
Size change:  9.33 KiB
Changelog:
  * Tue Mar 30 2021 Fabrice Bellet  - 2020.3.8-1
  - new upstream release


Package:  abc-1.01-30.git20210328.fc34
Old package:  abc-1.01-29.git20201126.fc34
Summary:  Sequential logic synthesis and formal verification
RPMs: abc abc-devel abc-libs
Size: 31.73 MiB
Size change:  101.17 KiB
Changelog:
  * Wed Mar 31 2021 Jerry James  - 1.01-30.git20210328
  - Update to latest git snapshot
  - Add patches: -strict-aliasing, -overflow
  - Avoid bogus rpaths


Package:  ceph-2:16.2.0-1.fc34
Old package:  ceph-2:16.1.0-1.fc34
Summary:  User space components of the Ceph file system
RPMs: ceph ceph-base ceph-common ceph-fuse ceph-grafana-dashboards 
ceph-immutable-object-cache ceph-mds ceph-mgr ceph-mgr-cephadm 
ceph-mgr-dashboard ceph-mgr-diskprediction-local ceph-mgr-k8sevents 
ceph-mgr-modules-core ceph-mgr-rook ceph-mon ceph-osd ceph-prometheus-alerts 
ceph-radosgw ceph-resource-agents ceph-selinux ceph-test cephadm cephfs-java 
cephfs-mirror cephfs-shell cephfs-top libcephfs-devel libcephfs2 
libcephfs_jni-devel libcephfs_jni1 libcephsqlite libcephsqlite-devel 
librados-devel librados2 libradospp-devel libradosstriper-devel 
libradosstriper1 librbd-devel librbd1 librgw-devel librgw2 
python3-ceph-argparse python3-ceph-common python3-cephfs python3-rados 
python3-rbd python3-rgw rados-objclass-devel rbd-fuse rbd-mirror rbd-nbd
Added RPMs:   libcephsqlite libcephsqlite-devel
Size: 429.02 MiB
Size change:  3.92 MiB
Changelog:
  * Tue Mar 30 2021 Jonathan Wakely  - 2:16.1.0-2
  - Rebuilt for removed libstdc++ symbol (#1937698)

  * Wed Mar 31 2021 Kaleb S. KEITHLEY  - 2:16.2.0-1
  - 16.2.0 GA


Package:  cockpit-241-1.fc34
Old package:  cockpit-240-1.fc34
Summary:  Web Console for Linux servers
RPMs: cockpit cockpit-bridge cockpit-doc cockpit-kdump cockpit-machines 
cockpit-networkmanager cockpit-packagekit cockpit-pcp cockpit-selinux 
cockpit-sosreport cockpit-storaged cockpit-system cockpit-tests cockpit-ws
Size: 19.37 MiB
Size change:  41.48 KiB
Changelog

Re: Package downgrades from Fedora 33 -> Fedora 34 (including ostree + rpm-ostree)

[Matthew Miller]

On Tue, Apr 06, 2021 at 12:42:33PM +0200, Fabio Valentini wrote:
> - icedtea-web-0:2.0.0-pre.2.alpha13.patched1.fc33 >
> icedtea-web-0:2.0.0-pre.0.3.alpha16.patched1.fc34.3
> 
> Versioning snafu - alpha 13 should not sort higher than alpha 16, I guess.


In case it's not obvious, it's the change from "pre.2" to "pre.0.3" that is
the oops.


-- 
Matthew Miller

Fedora Project Leader
___
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: questions about "Fedora Localization Statistics"

[Tom Hughes via devel]

On 06/04/2021 15:16, Tom Hughes wrote:

On 06/04/2021 14:47, Zbigniew Jędrzejewski-Szmek wrote:


I'm looking at https://languages.stg.fedoraproject.org/territories/pl/,
and it says:

be (0.58 %)
csb official_regional (0.13 %)
de official_regional (19 %)
en (33 %)
lt official_regional (0.021 %)
pl official (96 %)
ru (18 %)
sli (0.031 %)
szl (1.3 %)
uk (0.39 %)

I think it's be good to order those items by percentage, rather than
alphabetically.

But my question is: what are those numbers supposed to _mean_?


As the page says the data comes from CLDR and that is documented here:

https://unicode.org/reports/tr35/tr35-info.html#Supplemental_Territory_Information 



Specifically those numbers are from the languagePopulation elements
in the most recent CLDR release.


The data for DE in PL in CLDR specifically references a source:

uri="http://en.wikipedia.org/wiki/German_minority_in_Poland;>regional-official 
in part of Opole Voivodeship; in Poland 325 schools with primary instr 
in German, estimate 37000 students. Real figure probably higher.


Though the numbers on that page don't get near the 7 million
that is being claimed.

Tom

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

Re: F35 Change proposal: RPM 4.17 (System-Wide Change proposal)

[Panu Matilainen]

On 4/6/21 3:01 PM, Tim Landscheidt wrote:

Miro Hrončok  wrote:


[…]



2. change %check not to rely on unpackaged files in buildroot



That one is non-trivial and depends on the reason it is needed.



For example, what is common for Python "namepsace" packages, e.g. pkg_name.foo.



1) We want to test installed files, not what is in $PWD, so we set PYTHONPATH to
%{buildroot}%{python3_sitearch}:%{buildroot}%{python3_sitelib} and we
(try hard to) exclude $PWD from it. This is crucial to ensure the files
we actually ship are working and the installed file set is complete.
Our macros do this for the packagers.



2) The %{python3_site...}/pkg_name/ directory and
%{python3_site...}/pkg_name/__init__.py and
%{python3_site...}/pkg_name/__pycache__/ and
%{python3_site...}/pkg_name/__pycache__/__init__...pyc
files must be present in %{buildroot} to successfully run the tests.



3) The files from (2) must be excluded from the package because *pkg_name* owns
them, not *pkg_name.foo*.
We Require the "toplevel" *pkg_name* package from *pkg_name.foo*.
The files are not bit-by-bit+metadata identical,
so both packages cannot ship them.



[…]


My understanding of the RPM spec sections was always that:

- "%prep" is for "./configure",
- "%build" is for "make",
- "%install" is for "make install", and
- "%check" is for "make check".

"make check" (usually executed /before/ "make install")
works in and on the working directory
(https://www.gnu.org/prep/standards/html_node/Standard-Targets.html#Standard-Targets).


Exactly. Only rpm got this sequence wrong, because %check is executed 
after %install. If it wasn't for that, we wouldn't be having this 
conversation at all because then %check would be clearly defined.


For the curious, this is how %check came to existence:
https://bugzilla.redhat.com/show_bug.cgi?id=64137

I'm kinda wondering here if there wouldn't be any solutions to in this 
direction - the existing %check is being (ab)used for things its not 
well suited to because it's positioned in the way it is, and people be 
better off with something different entirely.




To test that the resulting binary package is functional, an-
other venue is needed, and in the case of Fedora, for that
purpose Fedora CI was created
(https://docs.fedoraproject.org/en-US/ci/tests/).

That feels like a much cleaner solution than installing some
files, testing and then not shipping them because the test
environment will be the same as a user's who just installed
the package instead of being in the process of building the
package.


Indeed.

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

Re: questions about "Fedora Localization Statistics"

[Tom Hughes via devel]

On 06/04/2021 14:47, Zbigniew Jędrzejewski-Szmek wrote:


I'm looking at https://languages.stg.fedoraproject.org/territories/pl/,
and it says:

be (0.58 %)
csb official_regional (0.13 %)
de official_regional (19 %)
en (33 %)
lt official_regional (0.021 %)
pl official (96 %)
ru (18 %)
sli (0.031 %)
szl (1.3 %)
uk (0.39 %)

I think it's be good to order those items by percentage, rather than
alphabetically.

But my question is: what are those numbers supposed to _mean_?


As the page says the data comes from CLDR and that is documented here:

https://unicode.org/reports/tr35/tr35-info.html#Supplemental_Territory_Information

Specifically those numbers are from the languagePopulation elements
in the most recent CLDR release.

Tom

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

[Bug 1943227] perl-Perl-Metrics-Simple-1.0.0 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version|perl-Perl-Metrics-Simple-1. |perl-Perl-Metrics-Simple-1.
   |0.0-1.fc35  |0.0-1.fc35
   ||perl-Perl-Metrics-Simple-1.
   ||0.1-1.fc34
 Resolution|--- |ERRATA
Last Closed||2021-04-06 14:01:15



--- Comment #12 from Fedora Update System  ---
FEDORA-2021-2573e42852 has been pushed to the Fedora 34 stable repository.
If problem still persists, please make note of it in this bug report.


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

[Bug 1941319] perl-Perl-Metrics-Simple-0.19 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version|perl-Perl-Metrics-Simple-0. |perl-Perl-Metrics-Simple-0.
   |19-1.fc35   |19-1.fc35
   ||perl-Perl-Metrics-Simple-1.
   ||0.1-1.fc34
 Resolution|--- |ERRATA
Last Closed||2021-04-06 14:01:13



--- Comment #15 from Fedora Update System  ---
FEDORA-2021-2573e42852 has been pushed to the Fedora 34 stable repository.
If problem still persists, please make note of it in this bug report.


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

Re: F35 Change proposal: RPM 4.17 (System-Wide Change proposal)

[Panu Matilainen]

On 4/6/21 1:36 PM, Miro Hrončok wrote:

On 06. 04. 21 11:16, Panu Matilainen wrote:

On 4/1/21 12:45 AM, Miro Hrončok wrote:

On 31. 03. 21 21:52, Ben Cotton wrote:

* Strict checking for unpackaged content in builds

 > ...

* Many existing packages will fail to build due to the stricter
buildroot content checking. Fixing this in the packaging is always
backwards compatible. We could temporarily set
`%_unpackaged_files_terminate_build 0` in rawhide to alleviate initial
impact if necessary.


This is my main concern with this update.

tl;dr If you %exclude something and there is no other subpackage to 
own the files, the build fails:



This fails:

   %install
   ...
   touch %{buildroot}/foo %{buildroot}/bar

   %files
   /
   %exclude /foo

This still succeeds:

   %files
   /
   %exclude /foo

   %files foo
   /foo

Many packages do the former in Fedora for various different reasons, 
namely to, well... exclude files from the package (and not ship them 
at all). Sometimes a `rm` in %install can be used instead. Sometimes 
not, because the files are needed in the %{buildroot} for %check but 
not needed to be shipped.


The bottom line is that the buildroot should not contain anything that 
is not packaged. This has been the basic premise ever since the check 
for unpackaged files was added somewhere around turn of the millenium, 
but some loopholes were left around. Yes, %exclude is a loophole.

So 'rm -f' at end of %install for undesired material is the expected fix.

What %check may or may not do has probably never been designed, much 
less documented or enforced. It runs after %install yes, so one might 
assume it's ok/supposed to use what's in buildroot, but then it runs 
from the build directory, not buildroot.


It doesn't matter where does it run *from*, it needs to "see" the files 
from %{buildroot} because that is what we want to test: The files we ship.


The way I see it, %check should be able to use/access buildroot 
contents, but it certainly should not write there. That might be 
something to even enforce one day.


The packages (that I know about) don't need to actually write there in 
%check. They just need to to see the files that will be later excluded 
(e.g. because they belong to a different package that the 
soon-to-be-built package requires on runtime).



And therein lies the problem. Like many things in rpm, %check isn't 
actually defined in any meaningful way, but in practise it's kinda 
limited to standalone unit/functional testing and this steps on the 
border of integration testing.




When this change was introduced upstream in November 2020, I've 
analyzed the impact on Fedora packages. Bare in mind that the data is 
4+ months old.


https://github.com/rpm-software-management/rpm/pull/1442#issuecomment-731554917 



  - 1675 packages had %exclude in the spec file
  -  261 packages FTBFS for unrelated reason (incl. a very limited 
timeout)

  - 1414 packages actually tested
  -  537 packages built successfully, that is ~38%
  -  877 packages failed with unpackaged files, that is ~62%, list 
attached


When I extrapolate the numbers to compensate the unrelated FTBFS, 
that's likely more than 1000 affected Fedora packages.


OTOH ~500 packages are generated rubygem-* packages, automatically 
fixable.


I'd like to know how are the affected packages supposed to migrate to 
RPM 4.17 behavior, especially if they cannot remove the files in 
%install prior to %check. Are they supposed to remove the files at 
the end of %check instead? What if the package is build without %check?


In the order of preference:

1. 'rm -f ' at end of %install


That one is simple. I agree. If it is possible, let's do this. We could 
even automate it if needed. (As a side note I'd say writing such 
automation is a right thing to do when a change like this is proposed, 
but I understand that we cannot have everything.)



2. change %check not to rely on unpackaged files in buildroot


That one is non-trivial and depends on the reason it is needed.


Of course.

For example, what is common for Python "namepsace" packages, e.g. 
pkg_name.foo.


1) We want to test installed files, not what is in $PWD, so we set 
PYTHONPATH to

    %{buildroot}%{python3_sitearch}:%{buildroot}%{python3_sitelib} and we
    (try hard to) exclude $PWD from it. This is crucial to ensure the files
    we actually ship are working and the installed file set is complete.
    Our macros do this for the packagers.

2) The %{python3_site...}/pkg_name/ directory and
    %{python3_site...}/pkg_name/__init__.py and
    %{python3_site...}/pkg_name/__pycache__/ and
    %{python3_site...}/pkg_name/__pycache__/__init__...pyc
    files must be present in %{buildroot} to successfully run the tests.

3) The files from (2) must be excluded from the package because 
*pkg_name* owns

    them, not *pkg_name.foo*.
    We Require the "toplevel" *pkg_name* package from *pkg_name.foo*.
    The files are not bit-by-bit+metadata identical,
    so 

questions about "Fedora Localization Statistics"

[Zbigniew Jędrzejewski-Szmek]

I'm looking at https://languages.stg.fedoraproject.org/territories/pl/,
and it says:

be (0.58 %)
csb official_regional (0.13 %)
de official_regional (19 %)
en (33 %)
lt official_regional (0.021 %)
pl official (96 %)
ru (18 %)
sli (0.031 %)
szl (1.3 %)
uk (0.39 %)

I think it's be good to order those items by percentage, rather than
alphabetically.

But my question is: what are those numbers supposed to _mean_?

In the particular case of 'pl', I'm pretty sure that 19% of people
living within the borders of Poland do not speak German. (According
to some duckduckgoing, "5% declare they speak it well", but at the
same time "employers declare that people usually overstate their
knowledge". Approx. 40+% of school-age children _learn_ German as a
foreign language, but even if that results in some basic knowledge,
that doesn't mean that those people would ever be able to use the OS
translated into German. Also, even if 'pl' wasn't available, they'd
go for 'en'.)

I can't find data for 'ru' in Poland, and it's more complicated,
because 2% are native speakers, compared to about 0.5% for 'de'.
But according to Eurostat [0], 22% declare knowledge of 2+ two foreign
languages overall, so 'ru' cannot be even close to 18%, considering
that 'en' >> 'de' >> 'ru'.

Damn, I wanted to do just a quick check, but this is an interesting
subject and I got pulled in ;). Eurobarometer 2012 [1], says that
"proportion able to speak at loeast one foreign language has ...
decreased in Czechia (-12 points to 49%), Poland (-7 points to 50%)".
Meh, considering what I know about Poland, I really really doubt
this. Foreign language knowledge is not great in Poland, but a _drop_
seams very very unlikely, considering that ~all school age children
learn English and most also another foreign language. Also considering
the number of people temporarily migrating to UK and Germany and other
places for work within the EU, and the number of people consuming
English media, an actual drop would be hard to achieve.

Surprisingly, the same Eurobarometer table D48T shows
"Languages that you speak well enough to have a conversation"
PL: English 33%, German 19%, Russian 18%, which are the same
numbers as in the table at the top of this email! So is the the source
of those numbers?
The actual question that was asked was "And which ... language, if
any, do you speak well enough in order to be able to have a
conversation? According to the annex [2], they did 1000 f2f interviews,
leading to conf. interval ±2.5 p.p. for 20%.
There's also table SD5a, which shows "which languages do you
understand well enough to follow news on tv or radio", with
PL: English 17%, German 6%, Russian 8%.

So I think it's fair to qualify this data of "English 33%, German 19%,
Russian 18%" as a case of badly designed question: "conversation"
can mean asking for directions towards the city centre, or maybe
discussing an arbitrary subject, too nebulous. Many people declare that they
can "hold a conversation" but not "follow news", so it seems it
they interpreted it as only very basic knowledge.

OTOH, the surprising ratios between English/German/Russian, and the
fact that those ratios are rather different in the questions suggests
that they had some sample selection bias.

Either way, this doesn't seem to be very useful data for Fedora.

[0] https://ec.europa.eu/eurostat/statistics-explained/pdfscache/44913.pdf
[1] 
https://ec.europa.eu/commfrontoffice/publicopinion/archives/ebs/ebs_386_en.pdf
[2] 
https://ec.europa.eu/commfrontoffice/publicopinion/archives/ebs/ebs_386_anx_en.pdf

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

Fedora-IoT-35-20210406.0 compose check report

[Fedora compose checker]

Missing expected images:

Iot dvd x86_64
Iot dvd aarch64

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

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

ID: 82  Test: x86_64 IoT-dvd_ostree-iso base_services_start
URL: https://openqa.fedoraproject.org/tests/82
ID: 84  Test: x86_64 IoT-dvd_ostree-iso iot_rpmostree_overlay
URL: https://openqa.fedoraproject.org/tests/84
ID: 88  Test: aarch64 IoT-dvd_ostree-iso iot_clevis@uefi
URL: https://openqa.fedoraproject.org/tests/88
ID: 844453  Test: aarch64 IoT-dvd_ostree-iso base_services_start@uefi
URL: https://openqa.fedoraproject.org/tests/844453
ID: 844457  Test: aarch64 IoT-dvd_ostree-iso iot_rpmostree_overlay@uefi
URL: https://openqa.fedoraproject.org/tests/844457

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

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

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

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

New passes (same test not passed in Fedora-IoT-35-20210405.0):

ID: 87  Test: aarch64 IoT-dvd_ostree-iso podman@uefi
URL: https://openqa.fedoraproject.org/tests/87
ID: 89  Test: aarch64 IoT-dvd_ostree-iso base_service_manipulation@uefi
URL: https://openqa.fedoraproject.org/tests/89
ID: 844452  Test: aarch64 IoT-dvd_ostree-iso iot_zezere_server@uefi
URL: https://openqa.fedoraproject.org/tests/844452
ID: 844454  Test: aarch64 IoT-dvd_ostree-iso base_selinux@uefi
URL: https://openqa.fedoraproject.org/tests/844454
ID: 844455  Test: aarch64 IoT-dvd_ostree-iso release_identification@uefi
URL: https://openqa.fedoraproject.org/tests/844455
ID: 844459  Test: aarch64 IoT-dvd_ostree-iso podman_client@uefi
URL: https://openqa.fedoraproject.org/tests/844459
ID: 844460  Test: aarch64 IoT-dvd_ostree-iso iot_zezere_ignition@uefi
URL: https://openqa.fedoraproject.org/tests/844460

Installed system changes in test x86_64 IoT-dvd_ostree-iso 
install_default@uefi: 
Used mem changed from 192 MiB to 172 MiB
Previous test data: https://openqa.fedoraproject.org/tests/842958#downloads
Current test data: https://openqa.fedoraproject.org/tests/844430#downloads

Installed system changes in test aarch64 IoT-dvd_ostree-iso 
install_default_upload@uefi: 
Used mem changed from 206 MiB to 184 MiB
System load changed from 0.62 to 0.39
Previous test data: https://openqa.fedoraproject.org/tests/842974#downloads
Current test data: https://openqa.fedoraproject.org/tests/86#downloads
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Fedora-Rawhide-20210406.n.0 compose check report

[Fedora compose checker]

No missing expected images.

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

Failed openQA tests: 17/189 (x86_64), 15/127 (aarch64)

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

ID: 844157  Test: x86_64 KDE-live-iso desktop_browser **GATING**
URL: https://openqa.fedoraproject.org/tests/844157
ID: 844159  Test: x86_64 KDE-live-iso desktop_notifications_live
URL: https://openqa.fedoraproject.org/tests/844159
ID: 844160  Test: x86_64 KDE-live-iso desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/844160
ID: 844161  Test: x86_64 KDE-live-iso desktop_printing
URL: https://openqa.fedoraproject.org/tests/844161
ID: 844165  Test: x86_64 KDE-live-iso desktop_terminal **GATING**
URL: https://openqa.fedoraproject.org/tests/844165
ID: 844169  Test: x86_64 KDE-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/844169
ID: 844214  Test: aarch64 Server-dvd-iso 
server_freeipa_replication_master@uefi
URL: https://openqa.fedoraproject.org/tests/844214
ID: 844215  Test: aarch64 Server-dvd-iso 
server_freeipa_replication_replica@uefi
URL: https://openqa.fedoraproject.org/tests/844215
ID: 844219  Test: aarch64 Server-dvd-iso support_server@uefi
URL: https://openqa.fedoraproject.org/tests/844219
ID: 844228  Test: aarch64 Server-dvd-iso install_updates_nfs@uefi
URL: https://openqa.fedoraproject.org/tests/844228
ID: 844230  Test: aarch64 Server-dvd-iso 
server_freeipa_replication_client@uefi
URL: https://openqa.fedoraproject.org/tests/844230
ID: 844258  Test: aarch64 Workstation-raw_xz-raw.xz desktop_terminal@uefi
URL: https://openqa.fedoraproject.org/tests/844258
ID: 844377  Test: aarch64 universal support_server@uefi
URL: https://openqa.fedoraproject.org/tests/844377
ID: 844380  Test: aarch64 universal upgrade_2_server_domain_controller@uefi
URL: https://openqa.fedoraproject.org/tests/844380
ID: 844390  Test: aarch64 universal install_iscsi@uefi
URL: https://openqa.fedoraproject.org/tests/844390
ID: 844393  Test: aarch64 universal upgrade_2_realmd_client@uefi
URL: https://openqa.fedoraproject.org/tests/844393

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

ID: 844098  Test: x86_64 Server-dvd-iso server_freeipa_replication_master
URL: https://openqa.fedoraproject.org/tests/844098
ID: 844099  Test: x86_64 Server-dvd-iso server_freeipa_replication_replica
URL: https://openqa.fedoraproject.org/tests/844099
ID: 844102  Test: x86_64 Server-dvd-iso 
server_role_deploy_domain_controller **GATING**
URL: https://openqa.fedoraproject.org/tests/844102
ID: 844111  Test: x86_64 Server-dvd-iso realmd_join_sssd **GATING**
URL: https://openqa.fedoraproject.org/tests/844111
ID: 844116  Test: x86_64 Server-dvd-iso modularity_tests
URL: https://openqa.fedoraproject.org/tests/844116
ID: 844123  Test: x86_64 Server-dvd-iso realmd_join_cockpit
URL: https://openqa.fedoraproject.org/tests/844123
ID: 844129  Test: x86_64 Server-dvd-iso server_freeipa_replication_client
URL: https://openqa.fedoraproject.org/tests/844129
ID: 844130  Test: x86_64 Server-dvd-iso server_realmd_join_kickstart 
**GATING**
URL: https://openqa.fedoraproject.org/tests/844130
ID: 844156  Test: x86_64 KDE-live-iso desktop_login
URL: https://openqa.fedoraproject.org/tests/844156
ID: 844164  Test: x86_64 KDE-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/844164
ID: 844234  Test: aarch64 Server-dvd-iso modularity_tests@uefi
URL: https://openqa.fedoraproject.org/tests/844234
ID: 844351  Test: aarch64 universal install_asian_language@uefi
URL: https://openqa.fedoraproject.org/tests/844351
ID: 844381  Test: aarch64 universal upgrade_minimal_64bit@uefi
URL: https://openqa.fedoraproject.org/tests/844381
ID: 844383  Test: aarch64 universal upgrade_server_domain_controller@uefi
URL: https://openqa.fedoraproject.org/tests/844383
ID: 844394  Test: aarch64 universal upgrade_realmd_client@uefi
URL: https://openqa.fedoraproject.org/tests/844394
ID: 844422  Test: x86_64 universal install_asian_language
URL: https://openqa.fedoraproject.org/tests/844422

Soft failed openQA tests: 44/127 (aarch64), 68/189 (x86_64)
(Tests completed, but using a workaround for a known bug)

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

ID: 844213  Test: aarch64 Server-dvd-iso install_vnc_server@uefi
URL: https://openqa.fedoraproject.org/tests/844213
ID: 844229  Test: aarch64 Server-dvd-iso install_vnc_client@uefi
URL: https://openqa.fedoraproject.org/tests/844229
ID: 844382  Test: aarch64 universal upgrade_server_64bit@uefi
URL: https://openqa.fedoraproject.org/tests/844382

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

ID: 844079  Test: x86_64 Server-boot-iso install_default
URL: 

Re: can't login FAS

[Honggang LI]

On Tue, Apr 06, 2021 at 08:54:42PM +0800, Honggang LI wrote:
> On Tue, Apr 06, 2021 at 08:27:52AM -0400, Stephen John Smoogen wrote:
> >On Mon, 5 Apr 2021 at 22:26, Honggang LI  wrote:
> > 
> >  Hi,
> >  After input my FAS accout and password, I got this error message.
> > 
> >After input where? What place did you get this error?
> 
> https://bodhi.fedoraproject.org/updates/FEDORA-2021-141f8facf2
> 
> There is a 'login' button in the web page. Press 'login' button, the
> login web page will show up. After input my account and password, the error
> message will be displayed in the middle of page.
> 
> > 
> > 
> >  =
> > 
> >  500 Internal Server Error
> > 
> >  Could not convert return value of the view callable function
> >  pyramid_fas_openid.view.verify_openid into a response object. The value
> >  returned was None. You may have forgotten to return a value from the
> >  view callable.
> > 
> >  =

Sorry, it is my bad. I input my account with the email suffix. But this
error message is really misleading. Maybe a simple message, like "Wrong
account or password", will be helpful.
___
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: can't login FAS

[Honggang LI]

On Tue, Apr 06, 2021 at 08:27:52AM -0400, Stephen John Smoogen wrote:
>On Mon, 5 Apr 2021 at 22:26, Honggang LI  wrote:
> 
>  Hi,
>  After input my FAS accout and password, I got this error message.
> 
>After input where? What place did you get this error?

https://bodhi.fedoraproject.org/updates/FEDORA-2021-141f8facf2

There is a 'login' button in the web page. Press 'login' button, the
login web page will show up. After input my account and password, the error
message will be displayed in the middle of page.

> 
> 
>  =
> 
>  500 Internal Server Error
> 
>  Could not convert return value of the view callable function
>  pyramid_fas_openid.view.verify_openid into a response object. The value
>  returned was None. You may have forgotten to return a value from the
>  view callable.
> 
>  =
> 
>  Is there anything wrong? I can't push fabtest F34 build into stable repo
>  as I can't login.
> 
>  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
> 
>--
>Stephen J Smoogen.

> ___
> 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: can't login FAS

[Stephen John Smoogen]

On Mon, 5 Apr 2021 at 22:26, Honggang LI  wrote:

> Hi,
> After input my FAS accout and password, I got this error message.
>
>
After input where? What place did you get this error?


> =
>
> 500 Internal Server Error
>
> Could not convert return value of the view callable function
> pyramid_fas_openid.view.verify_openid into a response object. The value
> returned was None. You may have forgotten to return a value from the view
> callable.
>
> =
>
> Is there anything wrong? I can't push fabtest F34 build into stable repo
> as I can't login.
>
> 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
>


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

Fedora rawhide compose report: 20210406.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20210405.n.0
NEW: Fedora-Rawhide-20210406.n.0

= SUMMARY =
Added images:7
Dropped images:  2
Added packages:  8
Dropped packages:1
Upgraded packages:   65
Downgraded packages: 0

Size of added packages:  14.44 MiB
Size of dropped packages:2.89 MiB
Size of upgraded packages:   2.04 GiB
Size of downgraded packages: 0 B

Size change of upgraded packages:   68.16 MiB
Size change of downgraded packages: 0 B

= ADDED IMAGES =
Image: Container_Base docker s390x
Path: 
Container/s390x/images/Fedora-Container-Base-Rawhide-20210406.n.0.s390x.tar.xz
Image: Everything boot s390x
Path: 
Everything/s390x/iso/Fedora-Everything-netinst-s390x-Rawhide-20210406.n.0.iso
Image: Server dvd s390x
Path: Server/s390x/iso/Fedora-Server-dvd-s390x-Rawhide-20210406.n.0.iso
Image: Cloud_Base raw-xz s390x
Path: Cloud/s390x/images/Fedora-Cloud-Base-Rawhide-20210406.n.0.s390x.raw.xz
Image: Container_Minimal_Base docker s390x
Path: 
Container/s390x/images/Fedora-Container-Minimal-Base-Rawhide-20210406.n.0.s390x.tar.xz
Image: Cloud_Base qcow2 s390x
Path: Cloud/s390x/images/Fedora-Cloud-Base-Rawhide-20210406.n.0.s390x.qcow2
Image: Server boot s390x
Path: Server/s390x/iso/Fedora-Server-netinst-s390x-Rawhide-20210406.n.0.iso

= DROPPED IMAGES =
Image: Scientific vagrant-virtualbox x86_64
Path: 
Labs/x86_64/images/Fedora-Scientific-Vagrant-Rawhide-20210405.n.0.x86_64.vagrant-virtualbox.box
Image: Scientific vagrant-libvirt x86_64
Path: 
Labs/x86_64/images/Fedora-Scientific-Vagrant-Rawhide-20210405.n.0.x86_64.vagrant-libvirt.box

= ADDED PACKAGES =
Package: R-webfakes-1.1.1-1.fc35
Summary: Fake Web Apps for HTTP Testing
RPMs:R-webfakes
Size:2.95 MiB

Package: ansible-collection-chocolatey-chocolatey-1.0.2-1.fc35
Summary: Ansible collection for Chocolatey
RPMs:ansible-collection-chocolatey-chocolatey
Size:39.32 KiB

Package: ansible-collection-community-mysql-1.3.0-1.fc35
Summary: MySQL collection for Ansible
RPMs:ansible-collection-community-mysql
Size:61.29 KiB

Package: ansible-core-2.11.0-0.1.b4.fc35
Summary: A radically simple IT automation system
RPMs:ansible-base-doc ansible-core
Size:3.06 MiB

Package: awf-gtk4-2.3.0-1.fc35
Summary: Theme preview application for GTK
RPMs:awf-gtk4
Size:257.63 KiB

Package: cockpit-machines-242.1-1.fc35
Summary: Cockpit user interface for virtual machines
RPMs:cockpit-machines
Size:1.65 MiB

Package: cpufetch-0.94-2.fc35
Summary: Simple tool for determining CPU architecture
RPMs:cpufetch
Size:89.42 KiB

Package: rust-sevctl-0.1.0-1.fc35
Summary: Administrative utility for AMD SEV
RPMs:sevctl
Size:6.34 MiB


= DROPPED PACKAGES =
Package: ansible-base-2.10.6-1.fc35
Summary: A radically simple IT automation system
RPMs:ansible-base ansible-base-doc
Size:2.89 MiB


= UPGRADED PACKAGES =
Package:  R-arules-1.6.7-2.fc35
Old package:  R-arules-1.6.6-2.fc35
Summary:  Mining Association Rules and Frequent Itemsets
RPMs: R-arules
Size: 11.95 MiB
Size change:  -532.98 KiB
Changelog:
  * Mon Apr 05 2021 Iztok Fister Jr.  - 1.6.7-1
  - New version


Package:  R-processx-3.5.1-1.fc35
Old package:  R-processx-3.5.0-1.fc35
Summary:  Execute and Control System Processes
RPMs: R-processx
Size: 1.60 MiB
Size change:  3.65 KiB
Changelog:
  * Mon Apr 05 2021 Elliott Sales de Andrade  - 
3.5.1-1
  - Update to latest version (#1946117)


Package:  awscli-1.19.45-1.fc35
Old package:  awscli-1.19.43-1.fc35
Summary:  Universal Command Line Environment for AWS
RPMs: awscli
Size: 2.02 MiB
Size change:  10.83 KiB
Changelog:
  * Mon Apr 05 2021 Gwyn Ciesla  - 1.19.44-1
  - 1.19.44

  * Mon Apr 05 2021 Gwyn Ciesla  - 1.19.45-1
  - 1.19.45


Package:  bpftrace-0.12.0-1.fc35
Old package:  bpftrace-0.11.0-8.fc34
Summary:  High-level tracing language for Linux eBPF
RPMs: bpftrace
Size: 8.37 MiB
Size change:  656.08 KiB
Changelog:
  * Thu Apr 01 2021 Augusto Caringi  - 0.11.4-1
  - Rebased to version 0.11.4

  * Sun Apr 04 2021 Augusto Caringi  - 0.12.0-1
  - Rebased to version 0.12.0


Package:  clang-12.0.0-0.10.rc4.fc35
Old package:  clang-12.0.0-0.7.rc3.fc35
Summary:  A C language family front-end for LLVM
RPMs: clang clang-analyzer clang-devel clang-libs 
clang-resource-filesystem clang-tools-extra git-clang-format python3-clang
Size: 221.19 MiB
Size change:  45.37 KiB
Changelog:
  * Wed Mar 31 2021 Jonathan Wakely  - 12.0.0-0.8.rc3
  - Rebuilt for removed libstdc++ symbols (#1937698)

  * Fri Apr 02 2021 sguel...@redhat.com - 12.0.0-0.9.rc4
  - New upstream release candidate

  * Sat Apr 03 2021 sguel...@redhat.com - 12.0.0-0.10.rc4
  - Make pyc files from python3-clang reproducible


Package:  device-mapper-multipath-0.8.6-1.fc35
Old package:  device-mapper-multipath-0.8.5-6.fc35
Summary:  Tools to manage multipath devices using device-mapper

Re: F35 Change proposal: RPM 4.17 (System-Wide Change proposal)

[Tim Landscheidt]

Miro Hrončok  wrote:

> […]

>> 2. change %check not to rely on unpackaged files in buildroot

> That one is non-trivial and depends on the reason it is needed.

> For example, what is common for Python "namepsace" packages, e.g. 
> pkg_name.foo.

> 1) We want to test installed files, not what is in $PWD, so we set PYTHONPATH 
> to
>%{buildroot}%{python3_sitearch}:%{buildroot}%{python3_sitelib} and we
>(try hard to) exclude $PWD from it. This is crucial to ensure the files
>we actually ship are working and the installed file set is complete.
>Our macros do this for the packagers.

> 2) The %{python3_site...}/pkg_name/ directory and
>%{python3_site...}/pkg_name/__init__.py and
>%{python3_site...}/pkg_name/__pycache__/ and
>%{python3_site...}/pkg_name/__pycache__/__init__...pyc
>files must be present in %{buildroot} to successfully run the tests.

> 3) The files from (2) must be excluded from the package because *pkg_name* 
> owns
>them, not *pkg_name.foo*.
>We Require the "toplevel" *pkg_name* package from *pkg_name.foo*.
>The files are not bit-by-bit+metadata identical,
>so both packages cannot ship them.

> […]

My understanding of the RPM spec sections was always that:

- "%prep" is for "./configure",
- "%build" is for "make",
- "%install" is for "make install", and
- "%check" is for "make check".

"make check" (usually executed /before/ "make install")
works in and on the working directory
(https://www.gnu.org/prep/standards/html_node/Standard-Targets.html#Standard-Targets).

To test that the resulting binary package is functional, an-
other venue is needed, and in the case of Fedora, for that
purpose Fedora CI was created
(https://docs.fedoraproject.org/en-US/ci/tests/).

That feels like a much cleaner solution than installing some
files, testing and then not shipping them because the test
environment will be the same as a user's who just installed
the package instead of being in the process of building the
package.

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

[CANCELLED] Schedule for Tuesdays's FESCo Meeting (2021-04-06)

[Zbigniew Jędrzejewski-Szmek]

We would hold the FESCo meeting Tuesday at 17:00UTC in #fedora-meeting
on irc.freenode.net, but there is nothing on the agenda, so I'm
cancelling the meeting.


= Discussed and Voted in the Ticket =

#2582 F35 Change: rpmautospec - removing release and changelog fields from spec 
files 
https://pagure.io/fesco/issue/2582
APPROVED (+4, 1, 0) with the following modification:
Provide a release number as a macro that evaluates to an
ever-auto-incrementing integer that can inserted somewhere in the
Release tag. Only read the previous release/version and git
commit history, do not require any tags, and do not allow building
multiple builds from one commit.

#2590 F35 Change: Reduce dependencies on python3-setuptools
https://pagure.io/fesco/issue/2590
APPROVED (+7, 0, 0)


I'll chair the next meeting 2021-04-13.

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

Re: F35 Change proposal: Smaller Container Base Image (remove sssd-client, util-linux, shadow-utils) (Self-Contained Change)

[Florian Weimer]

* Neal Gompa:

> It's basically required for building containers that will work at
> runtime where OpenShift assigns an arbitrary UID.

I put something together 

  

It avoids the need to edit /etc/passwd to support dynamic user IDs for
PID 1.  Security consequences are quite unclear at present.

But perhaps those dynamic user IDs are best addressed at the container
runtime level.

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: Package downgrades from Fedora 33 -> Fedora 34 (including ostree + rpm-ostree)

[Kalev Lember]

On Tue, Apr 6, 2021 at 12:43 PM Fabio Valentini 
wrote:

> - libuv-1:1.41.0-1.fc33 > libuv-1:1.40.0-2.fc34
> - libuv-devel-1:1.41.0-1.fc33 > libuv-devel-1:1.40.0-2.fc34
> - libuv-static-1:1.41.0-1.fc33 > libuv-static-1:1.40.0-2.fc34
>
> libuv 1.41.0 was built for f34, but the bodhi update is stuck (build
> is mistagged in koji?):
> https://bodhi.fedoraproject.org/updates/FEDORA-2021-9ab6c1ee93


I unpushed the libuv update and queued it to stable again. Hopefully this
is enough to fix this.

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

Re: F35 Change proposal: Smaller Container Base Image (remove sssd-client, util-linux, shadow-utils) (Self-Contained Change)

[Peter Robinson]

On Tue, Apr 6, 2021 at 11:36 AM Neal Gompa  wrote:
>
> On Tue, Apr 6, 2021 at 3:23 AM Clement Verna  wrote:
> >
> >
> >
> > On Mon, 5 Apr 2021 at 20:30, Daniel Walsh  wrote:
> >>
> >> On 4/3/21 02:34, Tomasz Torcz wrote:
> >> > Dnia Fri, Apr 02, 2021 at 05:30:30PM -0400, Neal Gompa napisał(a):
> >> >> On Fri, Apr 2, 2021 at 5:18 PM Lars Seipel  wrote:
> >> >>> On Thu, Apr 01, 2021 at 02:36:48PM -0400, Neal Gompa wrote:
> >>  Unless OpenShift and RKE recently changed so that containers can run
> >>  as root by default (as of yesterday, they didn't), this is solidly a
> >>  bad idea, since it makes it much more unintuitive to set up secure
> >>  containers conforming with the guidelines for these Kubernetes
> >>  platforms.
> >> >>> In my experience, containers trying to run stuff from shadow-utils in
> >> >>> their entrypoint/startup scripts tend to be a reason for containers to
> >> >>> *not* run on OpenShift/OKD without additional adjustments.
> >> >>>
> >> >>> A related (and more common) issue are images that expect to run with a
> >> >>> particular named user (or UID) determined during the build process
> >> >>> (again, most likely created using shadow-utils).
> >> >>>
> >> >>> I'm not familiar with Rancher but at least for OpenShift, I don't think
> >> >>> the availability of shadow-utils is very useful. At run time, you can't
> >> >>> use the shadow-utils at all and whatever you do with it during build
> >> >>> time is unlikely to be helpful (and actively harmful more often than
> >> >>> not) at run time when OpenShift assigns you an arbitrary UID.
> >> >> It's basically required for building containers that will work at
> >> >> runtime where OpenShift assigns an arbitrary UID.
> >> >>
> >> >> For example, in my containers, I *build* and create a "runtime user"
> >> >> with the UID 1000, and then set things up to use that context at the
> >> >> end. OpenShift uses that for its dynamic UID assignment.
> >> >But you do not need shadow-utils for that. Even OpenShift
> >> > documentation shows simple echo is enough:
> >> >
> >> > if ! whoami &> /dev/null; then
> >> >if [ -w /etc/passwd ]; then
> >> >echo "${USER_NAME:-default}:x:$(id -u):0:${USER_NAME:-default} 
> >> > user:${HOME}:/sbin/nologin" >> /etc/passwd
> >> >fi
> >> > fi
> >> > https://docs.openshift.com/container-platform/3.10/creating_images/guidelines.html
> >> > (yeah, I know it's an old and obsolete version of docs)
> >> >
> >> What about all of the users of Docker and Podman who do?
> >>
> >>
> >>
> >> ```
> >>
> >> from fedora
> >>
> >> run useradd XYZ
> >>
> >> user XYZ
> >>
> >> ...
> >>
> >> ```
> >>
> >> Do you just break them out of the box?
> >
> >
> > Yes and that's the point of the Change Proposal (ie make this more widely 
> > known and allow people to change their Dockerfile). This change would only 
> > be applied starting from the Fedora 35 base image, I don't think it is 
> > unreasonable to have breaking change between major version of the container 
> > base image.
> >
>
> I think it would be unreasonable to break such a commonly established
> pattern, though. That's enough of a reason for people to stop using
> the Fedora base container.

We do have the Base container and a Base Minimal, so maybe do it in
the later and not the former?
___
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: Package downgrades from Fedora 33 -> Fedora 34 (including ostree + rpm-ostree)

[Ankur Sinha]

On Tue, Apr 06, 2021 12:42:33 +0200, Fabio Valentini wrote:
> Hi everybody,

Hello!

Thanks very much for catching this.

> - python-PyLEMS-doc-0:0.5.2-1.fc33 > python-PyLEMS-doc-0:0.5.1-2.fc34
> - python3-PyLEMS-0:0.5.2-1.fc33 > python3-PyLEMS-0:0.5.1-2.fc34
> 
> Updated to 0.5.2 for f32, f33, and rawhide, but not for f34.

Building and pushing an update to F34 now.

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

Package downgrades from Fedora 33 -> Fedora 34 (including ostree + rpm-ostree)

[Fabio Valentini]

Hi everybody,

It's that time of the year again, and this time there's not that many
downgrades to complain about (packages with "obvious" causes, like
F34FTBFS, already excluded from the list).

However, the list also includes some pretty important "critpath"
packages (ostree (!), rpm-ostree, libuv, ...), which should probably
be fixed before F34 is released. Shipping with old ostree packages
OOTB seems like a bad idea, especially for the Editions that are built
on top of it.

For the other problems: What should be done about them? Some
successful builds only need the missing bodhi update created, some
others additionally need dist-git changes merged from rawhide (?) and
a build in koji.

Full list of package downgrades below (plus my best-effort
investigation for the cause).

Fabio

---

- YafaRay-0:3.5.1-8.fc33 > YafaRay-0:3.5.1-7.fc34
- YafaRay-blender-0:3.5.1-8.fc33 > YafaRay-blender-0:3.5.1-7.fc34
- YafaRay-devel-0:3.5.1-8.fc33 > YafaRay-devel-0:3.5.1-7.fc34
- YafaRay-lib-0:3.5.1-8.fc33 > YafaRay-lib-0:3.5.1-7.fc34

YafaRay seems to have been updated on f33 but not on f34, or the
release bump was done to the "main" integer instead of appending .1
after dist if it was a stable-release-branch-only change.

- android-tools-1:30.0.5p1-1.fc33 > android-tools-0:20180828gitc7815d675-8.fc33

This package switched to a different upstream and a sane versioning
scheme, but apparently needs an Epoch to fix the upgrade path.

- charliecloud-0:0.22-2.fc33 > charliecloud-0:0.21-2.fc34
- charliecloud-doc-0:0.22-2.fc33 > charliecloud-doc-0:0.21-2.fc34
- charliecloud-test-0:0.22-2.fc33 > charliecloud-test-0:0.21-2.fc34

This package was updated for f35 and f33 but not for f34.

- compat-golang-github-git-lfs-gitobj-2-devel-1:1.4.1-1.fc33 >
compat-golang-github-git-lfs-gitobj-2-devel-0:2.0.1-2.fc34

I have seen this package before, and it looks like the versioning of
the compat package is off (or at least, the Epoch is missing on F34+).

- conky-0:1.12.1-1.fc33 > conky-0:1.11.6-2.fc34

Was successfully built for f34, but no bodhi update was submitted.

- container-selinux-2:2.160.0-1.fc33 >
container-selinux-2:2.158.0-1.gite78ac4f.fc34

Bad rhcontainerbot (built for f34, but no update created).

- cppad-devel-0:2021.3-3.fc33 > cppad-devel-0:2021.3-2.fc34
- cppad-doc-0:2021.3-3.fc33 > cppad-doc-0:2021.3-2.fc34

Update was built for f34, but no bodhi update was created.

- erfa-0:1.7.2-2.fc33 > erfa-0:1.7.2-1.fc34
- erfa-devel-0:1.7.2-2.fc33 > erfa-devel-0:1.7.2-1.fc34

Bad Release tag in F33 screwing with upgrade path.

- gecode-0:6.2.0-6.fc33 > gecode-0:6.2.0-5.fc34
- gecode-devel-0:6.2.0-6.fc33 > gecode-devel-0:6.2.0-5.fc34
- gecode-doc-0:6.2.0-6.fc33 > gecode-doc-0:6.2.0-5.fc34
- gecode-examples-0:6.2.0-6.fc33 > gecode-examples-0:6.2.0-5.fc34

Newer fc34 package has been tagged f35-only, f34 has an older fc34
package. Maybe it was built during the F34 branch point and something
screwed up.

- golang-tinygo-x-llvm-devel-0:0-0.17.20210315git435a266.fc33 >
golang-tinygo-x-llvm-devel-0:0-0.16.20201119git570e7a6.fc34

Updated for f32 and f33, but not for f34 or rawhide.

- gqrx-0:2.14.4-2.fc33 > gqrx-0:2.14.4-1.fc34

Updated for f33 and rawhide, but not for f34.

- hamlib-0:4.1-2.fc33 > hamlib-0:4.1-1.fc34
- hamlib-c++-0:4.1-2.fc33 > hamlib-c++-0:4.1-1.fc34
- hamlib-c++-devel-0:4.1-2.fc33 > hamlib-c++-devel-0:4.1-1.fc34
- hamlib-devel-0:4.1-2.fc33 > hamlib-devel-0:4.1-1.fc34
- hamlib-doc-0:4.1-2.fc33 > hamlib-doc-0:4.1-1.fc34
- perl-hamlib-0:4.1-2.fc33 > perl-hamlib-0:4.1-1.fc34
- python3-hamlib-0:4.1-2.fc33 > python3-hamlib-0:4.1-1.fc34
- tcl-hamlib-0:4.1-2.fc33 > tcl-hamlib-0:4.1-1.fc34

Rebuilt on f33 but not on f34 or rawhide.

- hyperscan-0:5.4.0-1.fc33 > hyperscan-0:5.3.0-6.fc34
- hyperscan-devel-0:5.4.0-1.fc33 > hyperscan-devel-0:5.3.0-6.fc34

Updated to 5.4.0 only on f33, but not for f34 or rawhide.

- icedtea-web-0:2.0.0-pre.2.alpha13.patched1.fc33 >
icedtea-web-0:2.0.0-pre.0.3.alpha16.patched1.fc34.3

Versioning snafu - alpha 13 should not sort higher than alpha 16, I guess.

- kata-runtime-0:1.12.1-3.fc33 > kata-runtime-0:1.12.1-2.fc34

Versioning snafu. Package also dumps half its spec file contents into
the %description tag:
https://koji.fedoraproject.org/koji/buildinfo?buildID=1718489

- klog-0:1.4.7-2.fc33 > klog-0:1.4.4-3.fc34

Updated to 1.4.7 only for f32 and f33, but not f34 or rawhide.

- libreswan-0:4.3-1.fc33 > libreswan-0:4.2-1.fc34

Version 4.3 was built for f33 and rawhide, but not for f34.

- libuv-1:1.41.0-1.fc33 > libuv-1:1.40.0-2.fc34
- libuv-devel-1:1.41.0-1.fc33 > libuv-devel-1:1.40.0-2.fc34
- libuv-static-1:1.41.0-1.fc33 > libuv-static-1:1.40.0-2.fc34

libuv 1.41.0 was built for f34, but the bodhi update is stuck (build
is mistagged in koji?):
https://bodhi.fedoraproject.org/updates/FEDORA-2021-9ab6c1ee93

- mingw32-libusbx-0:1.0.24-1.fc33 > mingw32-libusbx-0:1.0.22-7.fc34
- mingw32-libusbx-static-0:1.0.24-1.fc33 >
mingw32-libusbx-static-0:1.0.22-7.fc34
- 

Re: F35 Change proposal: RPM 4.17 (System-Wide Change proposal)

[Miro Hrončok]

On 06. 04. 21 11:16, Panu Matilainen wrote:

On 4/1/21 12:45 AM, Miro Hrončok wrote:

On 31. 03. 21 21:52, Ben Cotton wrote:

* Strict checking for unpackaged content in builds

 > ...

* Many existing packages will fail to build due to the stricter
buildroot content checking. Fixing this in the packaging is always
backwards compatible. We could temporarily set
`%_unpackaged_files_terminate_build 0` in rawhide to alleviate initial
impact if necessary.


This is my main concern with this update.

tl;dr If you %exclude something and there is no other subpackage to own the 
files, the build fails:



This fails:

   %install
   ...
   touch %{buildroot}/foo %{buildroot}/bar

   %files
   /
   %exclude /foo

This still succeeds:

   %files
   /
   %exclude /foo

   %files foo
   /foo

Many packages do the former in Fedora for various different reasons, namely 
to, well... exclude files from the package (and not ship them at all). 
Sometimes a `rm` in %install can be used instead. Sometimes not, because the 
files are needed in the %{buildroot} for %check but not needed to be shipped.


The bottom line is that the buildroot should not contain anything that is not 
packaged. This has been the basic premise ever since the check for unpackaged 
files was added somewhere around turn of the millenium, but some loopholes were 
left around. Yes, %exclude is a loophole.

So 'rm -f' at end of %install for undesired material is the expected fix.

What %check may or may not do has probably never been designed, much less 
documented or enforced. It runs after %install yes, so one might assume it's 
ok/supposed to use what's in buildroot, but then it runs from the build 
directory, not buildroot.


It doesn't matter where does it run *from*, it needs to "see" the files from 
%{buildroot} because that is what we want to test: The files we ship.


The way I see it, %check should be able to use/access buildroot contents, but it 
certainly should not write there. That might be something to even enforce one day.


The packages (that I know about) don't need to actually write there in %check. 
They just need to to see the files that will be later excluded (e.g. because 
they belong to a different package that the soon-to-be-built package requires on 
runtime).


When this change was introduced upstream in November 2020, I've analyzed the 
impact on Fedora packages. Bare in mind that the data is 4+ months old.


https://github.com/rpm-software-management/rpm/pull/1442#issuecomment-731554917

  - 1675 packages had %exclude in the spec file
  -  261 packages FTBFS for unrelated reason (incl. a very limited timeout)
  - 1414 packages actually tested
  -  537 packages built successfully, that is ~38%
  -  877 packages failed with unpackaged files, that is ~62%, list attached

When I extrapolate the numbers to compensate the unrelated FTBFS, that's 
likely more than 1000 affected Fedora packages.


OTOH ~500 packages are generated rubygem-* packages, automatically fixable.

I'd like to know how are the affected packages supposed to migrate to RPM 4.17 
behavior, especially if they cannot remove the files in %install prior to 
%check. Are they supposed to remove the files at the end of %check instead? 
What if the package is build without %check?


In the order of preference:

1. 'rm -f ' at end of %install


That one is simple. I agree. If it is possible, let's do this. We could even 
automate it if needed. (As a side note I'd say writing such automation is a 
right thing to do when a change like this is proposed, but I understand that we 
cannot have everything.)



2. change %check not to rely on unpackaged files in buildroot


That one is non-trivial and depends on the reason it is needed.

For example, what is common for Python "namepsace" packages, e.g. pkg_name.foo.

1) We want to test installed files, not what is in $PWD, so we set PYTHONPATH to
   %{buildroot}%{python3_sitearch}:%{buildroot}%{python3_sitelib} and we
   (try hard to) exclude $PWD from it. This is crucial to ensure the files
   we actually ship are working and the installed file set is complete.
   Our macros do this for the packagers.

2) The %{python3_site...}/pkg_name/ directory and
   %{python3_site...}/pkg_name/__init__.py and
   %{python3_site...}/pkg_name/__pycache__/ and
   %{python3_site...}/pkg_name/__pycache__/__init__...pyc
   files must be present in %{buildroot} to successfully run the tests.

3) The files from (2) must be excluded from the package because *pkg_name* owns
   them, not *pkg_name.foo*.
   We Require the "toplevel" *pkg_name* package from *pkg_name.foo*.
   The files are not bit-by-bit+metadata identical,
   so both packages cannot ship them.

Or, let's assume I want to package libfoo-devel for EPEL 9 because RHEL 9 only 
ships libfoo. And I want to run %check, but only ship the headers. There are 
plenty situations like this.


The case-by-case fix is also impossible to do at scale without a huge heroic 
effort.

3. short-term, 

Re: F35 Change proposal: Smaller Container Base Image (remove sssd-client, util-linux, shadow-utils) (Self-Contained Change)

[Neal Gompa]

On Tue, Apr 6, 2021 at 3:23 AM Clement Verna  wrote:
>
>
>
> On Mon, 5 Apr 2021 at 20:30, Daniel Walsh  wrote:
>>
>> On 4/3/21 02:34, Tomasz Torcz wrote:
>> > Dnia Fri, Apr 02, 2021 at 05:30:30PM -0400, Neal Gompa napisał(a):
>> >> On Fri, Apr 2, 2021 at 5:18 PM Lars Seipel  wrote:
>> >>> On Thu, Apr 01, 2021 at 02:36:48PM -0400, Neal Gompa wrote:
>>  Unless OpenShift and RKE recently changed so that containers can run
>>  as root by default (as of yesterday, they didn't), this is solidly a
>>  bad idea, since it makes it much more unintuitive to set up secure
>>  containers conforming with the guidelines for these Kubernetes
>>  platforms.
>> >>> In my experience, containers trying to run stuff from shadow-utils in
>> >>> their entrypoint/startup scripts tend to be a reason for containers to
>> >>> *not* run on OpenShift/OKD without additional adjustments.
>> >>>
>> >>> A related (and more common) issue are images that expect to run with a
>> >>> particular named user (or UID) determined during the build process
>> >>> (again, most likely created using shadow-utils).
>> >>>
>> >>> I'm not familiar with Rancher but at least for OpenShift, I don't think
>> >>> the availability of shadow-utils is very useful. At run time, you can't
>> >>> use the shadow-utils at all and whatever you do with it during build
>> >>> time is unlikely to be helpful (and actively harmful more often than
>> >>> not) at run time when OpenShift assigns you an arbitrary UID.
>> >> It's basically required for building containers that will work at
>> >> runtime where OpenShift assigns an arbitrary UID.
>> >>
>> >> For example, in my containers, I *build* and create a "runtime user"
>> >> with the UID 1000, and then set things up to use that context at the
>> >> end. OpenShift uses that for its dynamic UID assignment.
>> >But you do not need shadow-utils for that. Even OpenShift
>> > documentation shows simple echo is enough:
>> >
>> > if ! whoami &> /dev/null; then
>> >if [ -w /etc/passwd ]; then
>> >echo "${USER_NAME:-default}:x:$(id -u):0:${USER_NAME:-default} 
>> > user:${HOME}:/sbin/nologin" >> /etc/passwd
>> >fi
>> > fi
>> > https://docs.openshift.com/container-platform/3.10/creating_images/guidelines.html
>> > (yeah, I know it's an old and obsolete version of docs)
>> >
>> What about all of the users of Docker and Podman who do?
>>
>>
>>
>> ```
>>
>> from fedora
>>
>> run useradd XYZ
>>
>> user XYZ
>>
>> ...
>>
>> ```
>>
>> Do you just break them out of the box?
>
>
> Yes and that's the point of the Change Proposal (ie make this more widely 
> known and allow people to change their Dockerfile). This change would only be 
> applied starting from the Fedora 35 base image, I don't think it is 
> unreasonable to have breaking change between major version of the container 
> base image.
>

I think it would be unreasonable to break such a commonly established
pattern, though. That's enough of a reason for people to stop using
the Fedora base container.



-- 
真実はいつも一つ！/ 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: F35 Change proposal: RPM 4.17 (System-Wide Change proposal)

[Vít Ondruch]

Dne 02. 04. 21 v 12:07 Zbigniew Jędrzejewski-Szmek napsal(a):

On Thu, Apr 01, 2021 at 12:33:48AM +0200, Kalev Lember wrote:

On Thu, Apr 1, 2021 at 12:18 AM Zbigniew Jędrzejewski-Szmek <
zbys...@in.waw.pl> wrote:


On Wed, Mar 31, 2021 at 11:45:54PM +0200, Miro Hrončok wrote:

On 31. 03. 21 21:52, Ben Cotton wrote:

* Strict checking for unpackaged content in builds
...
* Many existing packages will fail to build due to the stricter
buildroot content checking. Fixing this in the packaging is always
backwards compatible. We could temporarily set
`%_unpackaged_files_terminate_build 0` in rawhide to alleviate initial
impact if necessary.

This is my main concern with this update.

tl;dr If you %exclude something and there is no other subpackage to
own the files, the build fails:

Whaaat? What is the point of %exclude if not to exclude files from the
list? Why would rpm upstream want to break this? Seems like a completely
backwards change that will make packaging harder instead of easier.


%exclude can be used for splitting up packages, so you can do

%files foo
%exclude bar.so
*.so

%files bar
bar.so


If my understanding is right, the above is what rpm upstream considers
correct use for %exclude.

Thank you for the explanation.


I believe the motivation for that change is brp scripts that would still
see the files that are %excluded in files and possibly do wrong things.
Using rm in install doesn't have that problem.

That sounds like a plausible concern. But is this something that
actually caused real problems, or just a theoretical issue?



This is one of the real issues:

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


Vít





For just not packaging some files, rm at the end of %install usually works
just fine (but people have also been using %exclude for that and this
change would break a bunch of packages that do this. I'm unsure if it's a
good thing or not).

If the system was designed like this initially, that'd be fine.
But this pattern is widely used and up-to-now there was no indication
in the packaging guidelines or rpm output that this is not the recommended
pattern. In fact, I know some people preferred the (declarative) %exclude
over the (imperative) rm.

And Miro raises another issue upthread: there might be packages which
require files in %check, and %exclude them. This change would require
removing those files at the end of %check, which is rather ugly.

Right we have ~1000 packages which will break. There is also an
unknown number of non-distro packages which may be affected.
I'm not happy about how rpm is changing in a backwards incompatible way.
E.g. this means that suddenly ~5% of F33 will not rebuild on F35. I think
we should have a strong justification for such a change.

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




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: memleax spec file and review

[Germano Massullo]

Done!
Review Request: memleax - Debugs memory leak of a running process -
https://bugzilla.redhat.com/1946499
___
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

Retiring from Perl maintenance

[Petr Pisar]

Hello,

here is as a brief announcement with a certain impact on Perl packaging in
Fedora:

I found a different role in Red Hat which is incompatible with maintaining
hundreds of packages. As a result, I will reassign my packages with a Red
Hat's interrest to Michal Spacek (mspacek) who replaces me at Red Hat. The
rest of my packages will be orphaned and available for anyone to take.

I will transfer the packages once I figure out the exact set of them, and how
to do it in Pagure without destroying my already worn-out mouse. I will also
send a list of the packages here.

It was my pleasure to cooperate with all of you over the last decade.

-- Petr


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

Re: F35 Change proposal: RPM 4.17 (System-Wide Change proposal)

[Panu Matilainen]

On 4/1/21 1:33 AM, Kalev Lember wrote:
On Thu, Apr 1, 2021 at 12:18 AM Zbigniew Jędrzejewski-Szmek 
mailto:zbys...@in.waw.pl>> wrote:


On Wed, Mar 31, 2021 at 11:45:54PM +0200, Miro Hrončok wrote:
 > On 31. 03. 21 21:52, Ben Cotton wrote:
 > >* Strict checking for unpackaged content in builds
 > > ...
 > >* Many existing packages will fail to build due to the stricter
 > >buildroot content checking. Fixing this in the packaging is always
 > >backwards compatible. We could temporarily set
 > >`%_unpackaged_files_terminate_build 0` in rawhide to alleviate
initial
 > >impact if necessary.
 >
 > This is my main concern with this update.
 >
 > tl;dr If you %exclude something and there is no other subpackage to
 > own the files, the build fails:

Whaaat? What is the point of %exclude if not to exclude files from the
list? Why would rpm upstream want to break this? Seems like a completely
backwards change that will make packaging harder instead of easier.


%exclude can be used for splitting up packages, so you can do

%files foo
%exclude bar.so
*.so

%files bar
bar.so


If my understanding is right, the above is what rpm upstream considers 
correct use for %exclude.


Indeed.



For just not packaging some files, rm at the end of %install usually 
works just fine (but people have also been using %exclude for that and 
this change would break a bunch of packages that do this. I'm unsure if 
it's a good thing or not).


I believe the motivation for that change is brp scripts that would still 
see the files that are %excluded in files and possibly do wrong things. 
Using rm in install doesn't have that problem.


More generally: what is not there can not cause unwanted side-effects.

File-level exclusion is impossible to meaningfully communicate to 
externally executed scripts, including but not limited to those shipping 
with rpm itself.


There are other benefits further down the road, such as automatic 
sub-packaging, enforcing %check will not muck with buildroot contents etc.


- Panu -


--
Kalev

___
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

Fedora-Cloud-32-20210406.0 compose check report

[Fedora compose checker]

No missing expected images.

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

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

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

Passed openQA tests: 6/7 (aarch64), 6/7 (x86_64)

New passes (same test not passed in Fedora-Cloud-32-20210405.0):

ID: 843915  Test: aarch64 Cloud_Base-qcow2-qcow2 base_services_start@uefi
URL: https://openqa.fedoraproject.org/tests/843915
-- 
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: F35 Change proposal: RPM 4.17 (System-Wide Change proposal)

[Panu Matilainen]

On 4/1/21 12:45 AM, Miro Hrončok wrote:

On 31. 03. 21 21:52, Ben Cotton wrote:

* Strict checking for unpackaged content in builds

 > ...

* Many existing packages will fail to build due to the stricter
buildroot content checking. Fixing this in the packaging is always
backwards compatible. We could temporarily set
`%_unpackaged_files_terminate_build 0` in rawhide to alleviate initial
impact if necessary.


This is my main concern with this update.

tl;dr If you %exclude something and there is no other subpackage to own 
the files, the build fails:



This fails:

   %install
   ...
   touch %{buildroot}/foo %{buildroot}/bar

   %files
   /
   %exclude /foo

This still succeeds:

   %files
   /
   %exclude /foo

   %files foo
   /foo

Many packages do the former in Fedora for various different reasons, 
namely to, well... exclude files from the package (and not ship them at 
all). Sometimes a `rm` in %install can be used instead. Sometimes not, 
because the files are needed in the %{buildroot} for %check but not 
needed to be shipped.


The bottom line is that the buildroot should not contain anything that 
is not packaged. This has been the basic premise ever since the check 
for unpackaged files was added somewhere around turn of the millenium, 
but some loopholes were left around. Yes, %exclude is a loophole.

So 'rm -f' at end of %install for undesired material is the expected fix.

What %check may or may not do has probably never been designed, much 
less documented or enforced. It runs after %install yes, so one might 
assume it's ok/supposed to use what's in buildroot, but then it runs 
from the build directory, not buildroot.


The way I see it, %check should be able to use/access buildroot 
contents, but it certainly should not write there. That might be 
something to even enforce one day.




When this change was introduced upstream in November 2020, I've analyzed 
the impact on Fedora packages. Bare in mind that the data is 4+ months old.


https://github.com/rpm-software-management/rpm/pull/1442#issuecomment-731554917 



  - 1675 packages had %exclude in the spec file
  -  261 packages FTBFS for unrelated reason (incl. a very limited timeout)
  - 1414 packages actually tested
  -  537 packages built successfully, that is ~38%
  -  877 packages failed with unpackaged files, that is ~62%, list attached

When I extrapolate the numbers to compensate the unrelated FTBFS, that's 
likely more than 1000 affected Fedora packages.


OTOH ~500 packages are generated rubygem-* packages, automatically fixable.

I'd like to know how are the affected packages supposed to migrate to 
RPM 4.17 behavior, especially if they cannot remove the files in 
%install prior to %check. Are they supposed to remove the files at the 
end of %check instead? What if the package is build without %check?


In the order of preference:

1. 'rm -f ' at end of %install
2. change %check not to rely on unpackaged files in buildroot
3. short-term, "%_unpackaged_files_terminate_build 0" in the spec with 
explanation (similar to eg unsupported architectures)


2. would be case-by-case of course, but an "universal" solution is to 
create a private install root inside %check, eg


---
%check
export CHECKROOT=${PWD}/_check
%make_install DESTDIR=${CHECKROOT}

# ...do what you normally do, just replace BUILDROOT with CHECKROOT
---

This way %check will not be messing with the precious to-be-packaged 
contents.


More light-weight options will exist on case-by-case basis, eg typically 
a cache can be diverted to some other location with environment 
variables or such.




Using `s` in entire rawhide just to 
compensate this:


  - is dangerous for other implications of the setting
  - only postpones the problem to a later time (when we will face the 
same issue)


It's hardly "dangerous", because the only content that will "leak" 
because of it is buildid links, which is what happens now. It doesn't 
affect content inclusion, just whether the message is a warning or error.


And for a more specific problem, around ~100 Python packages were 
affected when tested, many of them crucial (e.g. dnf), so this problem 
will block the upgrade to Python 3.10 if the change lands in Rawhide 
before we upgrade Python (which is the current plan) until we fix all 
the affected packages (by at least adding `%global 
_unpackaged_files_terminate_build 0` to them, which is a tad big hammer, 
but it will be our last-resort option).


Which is why suggested the global "%_unpackaged_files_terminate_build 0" 
in rawhide: just to move the impact to a less inconvenient time. No 
kittens will be killed by doing so.


- Panu -


List of affected Python packages:
   https://pagure.io/releng/issue/10072#comment-724315


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 

[rpms/perl-Net-IPv6Addr] PR #1: Tests

[Jitka Plesnikova]

jplesnik merged a pull-request against the project: `perl-Net-IPv6Addr` that 
you are following.

Merged pull-request:

``
Tests
``

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

License change: R-rvest GPLv3 -> MIT

[Elliott Sales de Andrade]

As in subject; change will be in F34+ only due to necessary dependencies.

-- 
Elliott
___
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: memleax spec file and review

[Germano Massullo]

Il 04/04/21 23:55, Ian McInerney ha scritto:
>
> On Sun, 4 Apr 2021, 21:53 Germano Massullo,
> mailto:germano.massu...@gmail.com>> wrote:
>
> Good day, I am creating a spec file [0] for memleax memory leaks
> analyzer [1], but during build [2] I am getting error "invalid option:
> --build=x86_64-redhat-linux-gnu.". Where can be the problem?
> Thank you
>
> [0]: https://pagure.io/memleax/blob/master/f/memleax.spec
> 
> [1]: https://github.com/WuBingzheng/memleax
> 
> [2]:
> https://copr.fedorainfracloud.org/coprs/germano/memleax/build/2114611/
> 
>
>
> The GitHub repo you linked at [1] doesn't seem to have any
> autotools-based build systems, so you shouldn't use the %configure
> macro. It looks like it uses CMake, so you should instead use the
> %cmake_* macros to configure/build/install.

The tar.gz only contains configure.ac, that is not included in master
branch. Also, CMakeLists.txt included in master branch, is not included
in tar.gz file.
I now added the latter as Source1 and I am working on let RPM use such
file, I just have to find out how to properly place the cp command in
the spec file

[0]: https://pagure.io/memleax/blob/master/f/memleax.spec

___
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

[rpms/perl-Net-IPv6Addr] PR #1: Tests

[Jitka Plesnikova]

jplesnik opened a new pull-request against the project: `perl-Net-IPv6Addr` 
that you are following:
``
Tests
``

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

Fedora-Cloud-33-20210406.0 compose check report

[Fedora compose checker]

No missing expected images.

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

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

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

Passed openQA tests: 6/7 (x86_64), 6/7 (aarch64)
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F35 Change proposal: Smaller Container Base Image (remove sssd-client, util-linux, shadow-utils) (Self-Contained Change)

[Clement Verna]

On Mon, 5 Apr 2021 at 20:30, Daniel Walsh  wrote:

> On 4/3/21 02:34, Tomasz Torcz wrote:
> > Dnia Fri, Apr 02, 2021 at 05:30:30PM -0400, Neal Gompa napisał(a):
> >> On Fri, Apr 2, 2021 at 5:18 PM Lars Seipel  wrote:
> >>> On Thu, Apr 01, 2021 at 02:36:48PM -0400, Neal Gompa wrote:
>  Unless OpenShift and RKE recently changed so that containers can run
>  as root by default (as of yesterday, they didn't), this is solidly a
>  bad idea, since it makes it much more unintuitive to set up secure
>  containers conforming with the guidelines for these Kubernetes
>  platforms.
> >>> In my experience, containers trying to run stuff from shadow-utils in
> >>> their entrypoint/startup scripts tend to be a reason for containers to
> >>> *not* run on OpenShift/OKD without additional adjustments.
> >>>
> >>> A related (and more common) issue are images that expect to run with a
> >>> particular named user (or UID) determined during the build process
> >>> (again, most likely created using shadow-utils).
> >>>
> >>> I'm not familiar with Rancher but at least for OpenShift, I don't think
> >>> the availability of shadow-utils is very useful. At run time, you can't
> >>> use the shadow-utils at all and whatever you do with it during build
> >>> time is unlikely to be helpful (and actively harmful more often than
> >>> not) at run time when OpenShift assigns you an arbitrary UID.
> >> It's basically required for building containers that will work at
> >> runtime where OpenShift assigns an arbitrary UID.
> >>
> >> For example, in my containers, I *build* and create a "runtime user"
> >> with the UID 1000, and then set things up to use that context at the
> >> end. OpenShift uses that for its dynamic UID assignment.
> >But you do not need shadow-utils for that. Even OpenShift
> > documentation shows simple echo is enough:
> >
> > if ! whoami &> /dev/null; then
> >if [ -w /etc/passwd ]; then
> >echo "${USER_NAME:-default}:x:$(id -u):0:${USER_NAME:-default}
> user:${HOME}:/sbin/nologin" >> /etc/passwd
> >fi
> > fi
> >
> https://docs.openshift.com/container-platform/3.10/creating_images/guidelines.html
> > (yeah, I know it's an old and obsolete version of docs)
> >
> What about all of the users of Docker and Podman who do?
>

>
> ```
>
> from fedora
>
> run useradd XYZ
>
> user XYZ
>
> ...
>
> ```
>
> Do you just break them out of the box?
>

Yes and that's the point of the Change Proposal (ie make this more widely
known and allow people to change their Dockerfile). This change would only
be applied starting from the Fedora 35 base image, I don't think it is
unreasonable to have breaking change between major version of the container
base image.


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

fedpkg push failed for main

[Ravindra Kumar]

Hi,

I have been maintaining open-vm-tools for several years, but never encountered 
this failure before. Today, I got following error for the first time:

$ fedpkg push
Enumerating objects: 5, done.
Counting objects: 100% (5/5), done.
Delta compression using up to 4 threads
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 717 bytes | 717.00 KiB/s, done.
Total 3 (delta 2), reused 0 (delta 0), pack-reused 0
remote: Unspecified ref refs/heads/main is blocked
remote: Denied push for ref 'refs/heads/main' for user 'ravindrakumar'
remote: All changes have been rejected
To ssh://pkgs.fedoraproject.org/rpms/open-vm-tools
 ! [remote rejected] main -> main (pre-receive hook declined)
error: failed to push some refs to 
'ssh://ravindraku...@pkgs.fedoraproject.org/rpms/open-vm-tools'
Could not execute push: Failed to execute command.


Could someone please help advise me what could I do differently to 
address/workaround this issue?

NOTE: I have also opened https://pagure.io/releng/issue/10078 issue for this.

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

Re: Outreachy Applicant Introduction

[Lukas Brabec]

Hi Shreya,

welcome to Fedora QA and thanks for showing interest in our project.

There shouldn't be any issues with Ubuntu - the javascript dependencies are
not distro specific.

Lukas

On Sat, Apr 3, 2021 at 11:39 AM  wrote:

> Hello everyone,
> I am Shreya Gupta, a sophomore at IIT Patna, India. I am having a keen
> interest in Open Source. I  am highly interested in your Outreachy project
> 'Improve Fedora QA dashboard'.  I am primarily interested in Web
> development. I have the knowledge and prior experience of developing
> websites in Nodejs, React, and Javascript. I have gone through the project
> Readme file and project details where there is information about system
> requirements. I am using Ubuntu and all other system requirements are
> satisfied by my PC. will I be able to set up this project on ubuntu? Kindly
> reply.
>
> Thank you.
> ___
> qa-devel mailing list -- qa-devel@lists.fedoraproject.org
> To unsubscribe send an email to qa-devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/qa-devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
>
___
qa-devel mailing list -- qa-devel@lists.fedoraproject.org
To unsubscribe send an email to qa-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/qa-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure