Re: FF builds

[Dominik 'Rathann' Mierzejewski]

On Friday, 10 September 2021 at 15:32, Miroslav Suchý wrote:
> Dne 09. 09. 21 v 18:54 Demi Marie Obenour napsal(a):
> > Can the Firefox build be distributed among multiple machines?
> 
> I would love to see a benchmark how much it speed up big packages and how it
> slow downs smaller packages. Whole rpmbuild part.
> 
> 
> FYI
> 
> Mock has CCache plugin, which speeds the thing a bit, but can be easily 
> exploited. So on build systems it is switched off.
> 
> Years ago I wrote blogpost about building in memory using tmpfs. That can 
> give you up to 70% gain.
> 
> http://miroslav.suchy.cz/blog/archives/2015/05/28/increase_mock_performance_-_build_packages_in_memory/index.html
> 
> We use this in Copr. AFAIK Koji does not use it. You can join Fedora infra to 
> change it :)

Nowadays, you can mount /var/lib/mock on zram, too:
$ cat /etc/systemd/zram-generator.conf 
[zram0]
zram-fraction = 0.5
max-zram-size = 4096

[zram1]
mount-point = /var/lib/mock
zram-fraction = 0.75
max-zram-size = 12288

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

Re: Heads-Up: Matrix clients need urgent update

[Vitaly Zaitsev via devel]

On 10/09/2021 19:03, Marius Schwarz wrote:
Fedora is offering a range of different native Matrix clients. I suggest 
to have an eye open on monday for related maintainers:


I'm a Fedora package maintainer for the following Matrix clients and 
libraries: neochat, nheko, spectral, purple-matrix, libquotient, libolm 
and still haven't received any information from the Matrix security team.


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

Re: FF builds

[Ken Dreyer]

On Fri, Sep 10, 2021 at 2:11 PM Stephen John Smoogen  wrote:
> Small correction. Miroslav didn't say COPR uses ccache. He said COPR
> uses ramdisk for mock.

Oh, whoops. Got it.
___
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: FF builds

[Stephen John Smoogen]

On Fri, 10 Sept 2021 at 14:05, Ken Dreyer  wrote:
>
> On Fri, Sep 10, 2021 at 9:33 AM Miroslav Suchý  wrote:
> > We use this in Copr. AFAIK Koji does not use it. You can join Fedora infra 
> > to change it :)
>
> Is there more documentation about how Copr uses ccache? I was grepping
> around https://pagure.io/copr/copr for "ccache" and I see the
> "ccache_enable" plugin config is set to "False".
>

Small correction. Miroslav didn't say COPR uses ccache. He said COPR
uses ramdisk for mock.

Using ccache in mock is  exploitable so that a bad build can interfere
with other packages and items.

> The reason I'm asking is that I'm considering testing mock's ccache
> plugin within Koji for Ceph.
>
> I'm wondering about management, specifically whether we must track and
> maintain per-ceph-version ccaches.
>
> Do you have utilities for examining the caches, clearing them, etc? Do
> you distribute caches across builders? Anything else we should think
> about?
>
> - Ken
> ___
> 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.
I've seen things you people wouldn't believe. Flame wars in
sci.astro.orion. I have seen SPAM filters overload because of Godwin's
Law. All those moments will be lost in time... like posts on a BBS...
time to shutdown -h now.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fedora Linux 35 Beta blocker status summary

[Ben Cotton]

The Go/No-Go meeting for the target date #1 is Thursday!

Action summary


Accepted blockers
-
1. mesa — gnome-shell: cogl_texture_get_gl_texture(): gnome-shell
killed by SIGSEGV — NEW
ACTION: Maintainers to diagnose and fix issue

2. freeipa — DNS often stops resolving properly after FreeIPA server
upgrade to Fedora 35 or 36 — NEW
ACTION: Maintainers to diagnose and fix issue

3. bcm283x-firmware — sdhci_setup_cfg: Hardware does not specify base
clock frequency — ASSIGNED
ACTION: Maintainers to diagnose and fix issue

4. gdm — Cannot reboot/poweroff on login screen — NEW
ACTION: Maintainers to remove extra capabilities

5. PackageKit — Fedora34 cannot be upgraded to 35 using Software and
PackageKit — NEW
ACTION: Maintainers to partially revert upstream commit 9b7e083
NEEDINFO: rhughes

6. selinux-policy — gnome-initial-setup slow to start up, missing
Online Accounts page when SELinux in enforcing mode — ASSIGNED
ACTION: Maintainers to diagnose and fix issue

Bug-by-bug detail
=

Accepted blockers
-
1. mesa — https://bugzilla.redhat.com/show_bug.cgi?id=1989726 — NEW
gnome-shell: cogl_texture_get_gl_texture(): gnome-shell killed by SIGSEGV

gnome-shell gets SIGSEGV on the Jetson Nano, which is blocking
hardware for the aarch64 architecture. Upstream MR 1979 contained a
candidate fix, but either the issue persists or a new one (BZ 1999681)
arises. It appears to be a driver issue.

2. freeipa — https://bugzilla.redhat.com/show_bug.cgi?id=1999321 — NEW
DNS often stops resolving properly after FreeIPA server upgrade to
Fedora 35 or 36

After upgrade from F33/34, the server stops returning correct DNS
responses (empty when they should not be) about 50% of the time. Adam
wrote a patch that makes the ignore exceptions go away but doesn't fix
the actual bug. This only happens with upgrades. It also appears to be
limited to cases where the server is upgraded but the client is not.
Disabling systemd-resolved does not change the behavior.

3. bcm283x-firmware —
https://bugzilla.redhat.com/show_bug.cgi?id=1999180 — ASSIGNED
sdhci_setup_cfg: Hardware does not specify base clock frequency

Booting a Raspberry Pi 3 has a 10–12 minute wait time after GRUB. It
may be dependent on the microSD card used.

4. gdm — https://bugzilla.redhat.com/show_bug.cgi?id=1996998 — NEW
Cannot reboot/poweroff on login screen

Restart or power off fails from the login screen because gnome-shell
is sending messages on the wrong user bus. This results from Fedora
making use of  extended capabilities; we are apparently the only
distribution that does. Disabling the capabilities may be the best
approach for the Beta release, with a better fix for Final or future
releases.

5. PackageKit — https://bugzilla.redhat.com/show_bug.cgi?id=2002609 — NEW
Fedora34 cannot be upgraded to 35 using Software and PackageKit

An upstream commit prevents prompting for credentials, which results
in PackageKit failing to perform upgrades. Reverting the commit allows
upgrades to work.

6. selinux-policy —
https://bugzilla.redhat.com/show_bug.cgi?id=1997310 — ASSIGNED
gnome-initial-setup slow to start up, missing Online Accounts page
when SELinux in enforcing mode

gnome-initial-setup skips the Online Accounts page and boots slowly
affter selinux-policy-34.16-1.fc35 landed.
selinux-policy-34.18-1.fc36.noarch does not fix it.


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

Re: FF builds

[Ken Dreyer]

On Fri, Sep 10, 2021 at 9:33 AM Miroslav Suchý  wrote:
> We use this in Copr. AFAIK Koji does not use it. You can join Fedora infra to 
> change it :)

Is there more documentation about how Copr uses ccache? I was grepping
around https://pagure.io/copr/copr for "ccache" and I see the
"ccache_enable" plugin config is set to "False".

The reason I'm asking is that I'm considering testing mock's ccache
plugin within Koji for Ceph.

I'm wondering about management, specifically whether we must track and
maintain per-ceph-version ccaches.

Do you have utilities for examining the caches, clearing them, etc? Do
you distribute caches across builders? Anything else we should think
about?

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

Heads-Up: Matrix clients need urgent update

[Marius Schwarz]

Hi,

Fedora is offering a range of different native Matrix clients. I suggest 
to have an eye open on monday for related maintainers:



2021-09-10 — Security  
— Matrix Security


Hi all,

A critical security vulnerability impacting several popular Matrix 
clients and libraries was recently discovered. A coordinated security 
release of the affected components will be happening in the afternoon 
(from an UTC perspective) of *Monday, Sept 13th*.


We will be reaching out to downstream packagers to ensure they can 
prepare patched versions of affected packages at the time of the 
release. The details of the vulnerability will be disclosed in a blog 
post on the day of the release. There is so far no evidence of the 
vulnerability being exploited in the wild.


*Please be prepared to upgrade as soon as the patched versions are 
released.*


Thank you for your patience while we work to resolve this issue.


Source: 
https://matrix.org/blog/2021/09/10/pre-disclosure-upcoming-critical-fix-for-several-popular-matrix-clients



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

Re: [Fedocal] Reminder meeting : ELN SIG

[Stephen Gallagher]

#fedora-meeting: Fedora ELN SIG (2021-09-10)



Meeting started by sgallagh at 16:00:58 UTC. The full logs are available
at fedora-meeting/2021-09-10/eln.2021-09-10-16.00.log.html .



Meeting summary
---
* Init Process  (sgallagh, 16:01:18)

* Agenda  (sgallagh, 16:07:09)
  * Agenda Item: s390x container images  (sgallagh, 16:07:40)
  * Agenda Item: DistroBuildSync updates  (sgallagh, 16:07:56)
  * Agenda Item: Content Resolver and ELN-Extras  (sgallagh, 16:08:03)

* Agenda Item: Status Update on Alternative Composes  (sgallagh,
  16:08:47)

* Status Update on Alternative Composes  (sgallagh, 16:09:11)

* s390x Container Images  (sgallagh, 16:22:28)

* DistroBuildSync update  (sgallagh, 16:37:13)
  * LINK: https://pagure.io/fedora-infrastructure/issue/10200
(sgallagh, 16:42:45)

* Open Floor  (sgallagh, 16:48:00)

* Content Resolver and ELN-Extras  (sgallagh, 16:49:01)
  * LINK: https://github.com/minimization/content-resolver/   (sgallagh,
16:58:24)
  * LINK: https://github.com/minimization/content-resolver   (tdawson,
16:58:39)
  * LINK: https://github.com/minimization/content-resolver/issues/31
(Eighth_Doctor, 17:00:59)

Meeting ended at 17:01:20 UTC.




Action Items






Action Items, by person
---
* **UNASSIGNED**
  * (none)




People Present (lines said)
---
* sgallagh (78)
* Eighth_Doctor (37)
* tdawson (27)
* jforbes (15)
* tstellar (14)
* zodbot (13)
* copperi[m] (2)
* sharkcz (1)




Generated by `MeetBot`_ 0.3

.. _`MeetBot`: http://wiki.debian.org/MeetBot
___
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: RH Bugzilla extrem slow loading at enter_bug.cgi for Fedora

[Stephen John Smoogen]

On Fri, 10 Sept 2021 at 12:50, Marius Schwarz  wrote:
>
> Hi,
>
> since a few days, loading the enter_bug.cgi for "Product=Fedora" on RH
> BZ takes very long.
> It's quite possible, that it's happening for any other product too ;)
>
> It's over a minute ATM.
>
> Can someone take a look at this, or do i need to contact rh's adminteam?
>

It is best to contact the RH bugzilla admins for several reasons:
1. they will need information about when, where, how you are
connecting, and probably other items
2. no one in Fedora has login, debug or any other access to bugzilla
so we will have to go talk to them, they will ask us all of the items
and we will then have to find you to answer them.


> best regards,
> Marius Schwarz
>
> ___
> 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.
I've seen things you people wouldn't believe. Flame wars in
sci.astro.orion. I have seen SPAM filters overload because of Godwin's
Law. All those moments will be lost in time... like posts on a BBS...
time to shutdown -h now.
___
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

RH Bugzilla extrem slow loading at enter_bug.cgi for Fedora

[Marius Schwarz]

Hi,

since a few days, loading the enter_bug.cgi for "Product=Fedora" on RH 
BZ takes very long.

It's quite possible, that it's happening for any other product too ;)

It's over a minute ATM.

Can someone take a look at this, or do i need to contact rh's adminteam?

best regards,
Marius Schwarz

___
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-35-20210910.n.0 compose check report

[Fedora compose checker]

No missing expected images.

Failed openQA tests: 8/141 (aarch64), 7/205 (x86_64)

New failures (same test not failed in Fedora-35-20210909.n.0):

ID: 976005  Test: aarch64 Server-dvd-iso 
install_repository_hd_variation@uefi
URL: https://openqa.fedoraproject.org/tests/976005
ID: 976122  Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/976122
ID: 976147  Test: x86_64 universal upgrade_realmd_client
URL: https://openqa.fedoraproject.org/tests/976147
ID: 976159  Test: aarch64 universal upgrade_server_domain_controller@uefi
URL: https://openqa.fedoraproject.org/tests/976159
ID: 976182  Test: aarch64 universal upgrade_realmd_client@uefi
URL: https://openqa.fedoraproject.org/tests/976182

Old failures (same test failed in Fedora-35-20210909.n.0):

ID: 975886  Test: x86_64 Server-dvd-iso modularity_tests
URL: https://openqa.fedoraproject.org/tests/975886
ID: 975932  Test: x86_64 Workstation-live-iso desktop_login
URL: https://openqa.fedoraproject.org/tests/975932
ID: 975944  Test: x86_64 KDE-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/975944
ID: 975949  Test: x86_64 KDE-live-iso desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/975949
ID: 975998  Test: aarch64 Server-dvd-iso anaconda_help@uefi
URL: https://openqa.fedoraproject.org/tests/975998
ID: 976017  Test: aarch64 Server-dvd-iso modularity_tests@uefi
URL: https://openqa.fedoraproject.org/tests/976017
ID: 976031  Test: aarch64 Server-dvd-iso server_cockpit_basic@uefi
URL: https://openqa.fedoraproject.org/tests/976031
ID: 976050  Test: aarch64 Workstation-raw_xz-raw.xz gedit@uefi
URL: https://openqa.fedoraproject.org/tests/976050
ID: 976130  Test: x86_64 universal memtest
URL: https://openqa.fedoraproject.org/tests/976130
ID: 976149  Test: aarch64 universal install_asian_language@uefi
URL: https://openqa.fedoraproject.org/tests/976149

Soft failed openQA tests: 13/141 (aarch64), 19/205 (x86_64)
(Tests completed, but using a workaround for a known bug)

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

ID: 975989  Test: aarch64 Server-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/975989

Old soft failures (same test soft failed in Fedora-35-20210909.n.0):

ID: 975853  Test: x86_64 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/975853
ID: 975854  Test: x86_64 Server-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/975854
ID: 975855  Test: x86_64 Server-dvd-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/975855
ID: 975868  Test: x86_64 Server-dvd-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/975868
ID: 975905  Test: x86_64 Server-dvd-iso server_realmd_join_kickstart
URL: https://openqa.fedoraproject.org/tests/975905
ID: 975913  Test: x86_64 Workstation-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/975913
ID: 975919  Test: x86_64 Workstation-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/975919
ID: 975928  Test: x86_64 Workstation-live-iso gedit
URL: https://openqa.fedoraproject.org/tests/975928
ID: 975959  Test: x86_64 Silverblue-dvd_ostree-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/975959
ID: 975960  Test: x86_64 Silverblue-dvd_ostree-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/975960
ID: 975962  Test: x86_64 Silverblue-dvd_ostree-iso evince
URL: https://openqa.fedoraproject.org/tests/975962
ID: 975963  Test: x86_64 Silverblue-dvd_ostree-iso gedit
URL: https://openqa.fedoraproject.org/tests/975963
ID: 975976  Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproject.org/tests/975976
ID: 975990  Test: aarch64 Server-dvd-iso install_default_upload@uefi
URL: https://openqa.fedoraproject.org/tests/975990
ID: 976011  Test: aarch64 Server-dvd-iso server_realmd_join_kickstart@uefi
URL: https://openqa.fedoraproject.org/tests/976011
ID: 976037  Test: aarch64 Server-raw_xz-raw.xz 
install_arm_image_deployment_upload@uefi
URL: https://openqa.fedoraproject.org/tests/976037
ID: 976046  Test: aarch64 Workstation-raw_xz-raw.xz 
install_arm_image_deployment_upload@uefi
URL: https://openqa.fedoraproject.org/tests/976046
ID: 976065  Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi
URL: https://openqa.fedoraproject.org/tests/976065
ID: 976082  Test: x86_64 universal install_anaconda_text
URL: https://openqa.fedoraproject.org/tests/976082
ID: 976095  Test: x86_64 universal install_serial_console
URL: https://openqa.fedoraproject.org/tests/976095
ID: 976102  Test: x86_64 universal upgrade_server_64bit
URL: https://openqa.fedoraproject.org/tests/976102
ID: 976108  Test: x86_64 universal upgrade_2_server_64bit
URL: 

Re: F35 3x slower boot than F34

[Chris Murphy]

On Fri, Sep 10, 2021 at 2:11 AM Marius Schwarz  wrote:
>
> Am 03.09.21 um 18:51 schrieb Chris Murphy:
> > Bug 2001057 - F35 boots 3x slower than F34, large time gaps in systemd 
> > journal
> > https://bugzilla.redhat.com/show_bug.cgi?id=2001057
> >
> >
> > This one really has gotten my goat. I'm not finding any reason why
> > it's taking this long to boot. Usually the critica-chain or svg plot
> > exposes the culprit but not in this case, I just have multiple 10s+
> > gaps in the journal.
> >
> > I might have to do some tedious regression testing by doing a clean
> > install of 35 to see if it's some artifact of upgrading from 34. But
> > it'd be nicer if I can just directly expose the culprit(s).
> >
> >
> Any updates on this?

It's an selinux issue. Fixed in Rawhide, waiting for an F35 build and
then testing it. Interesting to note that there's such a thing as user
AVCs and I guess (?) those don't show up in the journal with system
AVCs. That might be why I never saw why the problem work around was
enforcing=0.


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

[EPEL-devel] Fedora EPEL 7 updates-testing report

[updates]

The following Fedora EPEL 7 Security updates need testing:
 Age  URL
   3  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-7f33ec2b58   
proftpd-1.3.5e-11.el7


The following builds have been pushed to Fedora EPEL 7 updates-testing

drupal7-7.82-1.el7
python-rpm-head-signing-1.4.1-1.el7

Details about builds:



 drupal7-7.82-1.el7 (FEDORA-EPEL-2021-8f7f2eda61)
 An open-source content-management platform

Update Information:

- https://www.drupal.org/project/drupal/releases/7.82 -
https://www.drupal.org/sa-core-2021-004 (CVE-2021-32610) -
https://www.drupal.org/project/drupal/releases/7.81 -
https://www.drupal.org/project/drupal/releases/7.80 -
https://www.drupal.org/sa-core-2021-002 (CVE-2020-13672) -
https://www.drupal.org/project/drupal/releases/7.79 -
https://www.drupal.org/project/drupal/releases/7.78 -
https://www.drupal.org/sa-core-2021-001 (CVE-2020-36193) -
https://www.drupal.org/project/drupal/releases/7.77 -
https://www.drupal.org/project/drupal/releases/7.76 -
https://www.drupal.org/project/drupal/releases/7.75 -
https://www.drupal.org/sa-core-2020-013 (CVE-2020-28949, CVE-2020-28948)

ChangeLog:

* Wed Sep  8 2021 Shawn Iwinski  - 7.82-1
- Update to 7.82
- SA-CORE-2020-013 / CVE-2020-28948 / CVE-2020-28949
- SA-CORE-2021-001 / CVE-2020-36193
- SA-CORE-2021-002 / CVE-2020-13672 (RHBZ #1953010, #1953011)
- SA-CORE-2021-004 / CVE-2021-32610
* Wed Jul 21 2021 Fedora Release Engineering  - 7.74-3
- Rebuilt for https://fedoraproject.org/wiki/Fedora_35_Mass_Rebuild
* Tue Jan 26 2021 Fedora Release Engineering  - 7.74-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_34_Mass_Rebuild

References:

  [ 1 ] Bug #1953010 - drupal7: drupal: Cross-site scripting - SA-CORE-2021-002 
[fedora-all]
https://bugzilla.redhat.com/show_bug.cgi?id=1953010
  [ 2 ] Bug #1953011 - drupal7: drupal: Cross-site scripting - SA-CORE-2021-002 
[epel-7]
https://bugzilla.redhat.com/show_bug.cgi?id=1953011




 python-rpm-head-signing-1.4.1-1.el7 (FEDORA-EPEL-2021-a463ea5717)
 Small python module to extract RPM header and file digests

Update Information:

Ensure xattrs are passed in as bytes

ChangeLog:

* Fri Sep 10 2021 Patrick Uiterwijk  - 1.4.1-1
- Ensure xattrs are passed in as bytes


___
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: FF builds

[Stephen John Smoogen]

On Fri, 10 Sept 2021 at 09:33, Miroslav Suchý  wrote:
>
> Dne 09. 09. 21 v 18:54 Demi Marie Obenour napsal(a):
> > Can the Firefox build be distributed among multiple machines?
>
> I would love to see a benchmark how much it speed up big packages and how it 
> slow downs smaller packages. Whole rpmbuild
> part.
>
>
> FYI
>
> Mock has CCache plugin, which speeds the thing a bit, but can be easily 
> exploited. So on build systems it is switched off.
>
> Years ago I wrote blogpost about building in memory using tmpfs. That can 
> give you up to 70% gain.
>
> http://miroslav.suchy.cz/blog/archives/2015/05/28/increase_mock_performance_-_build_packages_in_memory/index.html
>
> We use this in Copr. AFAIK Koji does not use it. You can join Fedora infra to 
> change it :)
>

Uhm, let us not set up unreal expectations on what Fedora Infrastructure can do.
1. Koji needs to be able to support it and Fedora Infrastructure
doesn't/maintain work on that code.
2. Fedora Infrastructure would need either newer hardware or cut down
the number of builders to allow for more memory per system to do the
builds in ramdisk.
3. There are a long list of 'higher' priority items which the koji
developers have on their list to do all the time. This needs to be
weighed against the other needs of trying to make builds reproducible,
trying to make koji work better in a cloud evironment, etc.
4. If all of that would make it look like Fedora Infrastructure should
move to a different build system... then it isn't going to happen
soon.


-- 
Stephen J Smoogen.
I've seen things you people wouldn't believe. Flame wars in
sci.astro.orion. I have seen SPAM filters overload because of Godwin's
Law. All those moments will be lost in time... like posts on a BBS...
time to shutdown -h now.
___
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

[EPEL-devel] Fedora EPEL 8 updates-testing report

[updates]

The following Fedora EPEL 8 Security updates need testing:
 Age  URL
   4  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-303db869be   
chromium-93.0.4577.63-1.el8
   3  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-0123b5931c   
proftpd-1.3.6e-4.el8


The following builds have been pushed to Fedora EPEL 8 updates-testing

libnxz-0.62-1.el8
libtpms-0.8.6-0.20210910git7a4d46a119.el8.0
python-rpm-head-signing-1.4.1-1.el8

Details about builds:



 libnxz-0.62-1.el8 (FEDORA-EPEL-2021-0f1648920e)
 Zlib implementation for POWER processors

Update Information:

Get bug fixes from upstream

ChangeLog:

* Mon Aug 16 2021 Raphael Moreira Zinsly  - 0.62-1
- Update version.




 libtpms-0.8.6-0.20210910git7a4d46a119.el8.0 (FEDORA-EPEL-2021-cc21ff72bd)
 Library providing Trusted Platform Module (TPM) functionality

Update Information:

tpm2: Marshal event sequence objects' hash state

ChangeLog:

* Fri Sep 10 2021 Stefan Berger  - 
0.8.6-1.20210910git7a4d46a119
- tpm2: Marshal event sequence objects' hash state
* Wed Sep  1 2021 Stefan Berger  - 
0.8.5-1.20210901git18ba4c0206
- Build of libtpms 0.8.5




 python-rpm-head-signing-1.4.1-1.el8 (FEDORA-EPEL-2021-b00bfa1f88)
 Small python module to extract RPM header and file digests

Update Information:

Ensure xattrs are passed in as bytes

ChangeLog:

* Fri Sep 10 2021 Patrick Uiterwijk  - 1.4.1-1
- Ensure xattrs are passed in as bytes


___
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

[Bug 2003159] perl-Prima-1.63 is available

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED
   Fixed In Version||perl-Prima-1.63-1.fc36




-- 
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 2003159] perl-Prima-1.63 is available

[bugzilla]

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



--- Comment #1 from Petr Pisar  ---
Many new changes. A Drawable alpha renamed to bar_alpha. Suitable for Rawhide
only.


-- 
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: libvirt and systemd-resolved integration?

[Daniel P . Berrangé]

On Fri, Sep 10, 2021 at 04:57:56PM +0200, Peter Boy wrote:
> Hi all, 
> 
> I’m working on an update of the Fedora Server virtlib documentation 
> (https://docs.fedoraproject.org/en-US/fedora-server/virtualization-install/), 
> specifically the part about the DNS configration.
> 
> I would like to include and integrate the solutions presented in this thread 
> by Daniel Berrange and by Juan Alcaine. But unfortunately none of the 
> solutions worked in my test installations. I would be grateful if I could get 
> some hints on what I might have missed.
> 
> The main challenge is to enable the host to resolve the internal name of the 
> VMs. For this purpose, the DNS server provided by libvirt must be included in 
> the search path (default virbr0 192.168.122.1). The server itself works fine. 
> If you use dig or nsloookup to assign the servers, the names of the VMs are 
> resolved correctly.
> 
> 
> 
> (a) === Installing libvirt-nss. (Daniel Berrange)  ===
> 
> I did the following
> 
> 1. dnf install libvirt-nss
> 
> 2. Modified following the libvirt documentation and the docs included with 
> the files /etc/authselect/user-nsswitch.conf and edited the hosts item to 
> "hosts:  files myhostname libvirt resolve [!UNAVAIL=return] dns“
> 
> 3. executed:  authselect apply-changes
> 
> 4. reboot
> 
> Neither using standard DNS without systems-resolved activated  nor using 
> systemd-resolved could resolve the internal names of the VM

I think you possibly mis-interpret what the libvirt-nss module is going
to be doing here.

Applications on the host will use glibc APIs for resolving host names
into IP addresses. GLibc will use the nsswitch config to determine 
what data sources to use for the host -> IP translation.

Adding "libvirt" to the nsswitch config for "hosts:" simply tells
GLibc to talk to the libvirt-nss module to try to resolve a hostname.
This doesn't involve DNS at all. libvirt-nss will be queried before
GLibc even gets to trying DNS. It also won't affect results reported
by systemd-resolved AFAICT.

You don't mention what VM configuration you're using for networking,
but basically if you "virsh dumpxlm $guest", then the 
element *must* be configured for type=network. If it is using 
type=bridge or any other option, then the libvirt-nss module has
no effect.

Finally, libvirt-nss provides two modules. 

  - "libvirt" does lookups against the hostname configured by
the guest OS when acquiring its DHCP lease. This hostname
is either set by the guest OS admin, or can be the hostname
in the libvirt network XML config (virsh net-dumpxml default)
if you're using fixed host<->ip<->mac mappings.

  - "libvirt_guest" does lookups against the guest name known
to libvirt in the host. (ie name reported by 'virsh list')

If you want to debug libvirt-nss problems there are two things
to try

  "virsh domifaddr $GUEST"

if that doesn't report any IP addresses, then the libvirt-nss
module won't do anything.

 "virsh net-dhcp-leases default"

will meanwhile report all IP addresses known the libvirt's dnsmasq
instance currently - domifaddr is just filtering those to extract
a specific guest.

Personally I always use the "libvirt_guest" NSS module, so get
host lookups using the libvirt guest name, but either NSS module
is valid based on your desired outcome.

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

[Bug 2003159] perl-Prima-1.63 is available

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

   Doc Type|--- |If docs needed, set a value
 Status|NEW |ASSIGNED
 CC|ppi...@redhat.com   |




-- 
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: Modularity: New modulemd-packager format for building modules

[Petr Pisar]

V Fri, Sep 10, 2021 at 08:50:44AM -0400, Neal Gompa napsal(a):
> On Fri, Sep 10, 2021 at 8:26 AM Petr Pisar  wrote:
> >
> > Good news, module maintainers.
> >
> > I'm relieved to announce an availability of the new module packaging format,
> > modulemd-packager, version 3.
> >
> 
> So this certainly solves a lot of issues, but it's still frustrating
> to see that we *need* to declare the platform and that we couldn't
> inherit the platform from the build environment. This means that at
> branching time, we need to make a commit to change the requested
> platform.
>
I confirm it is so and I fully agree with you that it's unpleasant.

The problem is that if you want to have the context invariant, then you need
to store a mapping between a context and its build-dependencies somewhere. And
naturally as new Fedora releases are added, and end-of-live releases removed,
the mapping must be updated because platform is one of the dependencies.

> That being said, does the platform value influence how the final
> modulemd is generated? That is, if I made a system that accepted this
> YAML file as input but *ignored* the platform value

It would end up like this : The
build service would mix contexts for different platforms and the module
wouldn't probably build at all like in the referred issue.

> (and the platform was forced by other means)

For example? The information has to be somewhere stored, somehow retrieved,
and delivered to a build and compose systems.

In non-modular world the information is stored in dist-git branch name,
delivered to Koji as a build target, and stored in Koji build as tag. The
information is updated with each Fedora release. The process of updating is
called branching and package retirement.

I was thinking about possible solutions:

One was omitting platform from the context. You would not specify any platform
in the module input format.

- context: A

You would submit the module for building. MBS would expand the build for all
platforms (= currently supported Fedoras). The result would be four module
builds:

Build   Dependencies
---
perl:5.32:362021:A  platform:36:0:0
perl:5.32:352021:A  platform:35:0:0
perl:5.32:342021:A  platform:34:0:0
perl:5.32:332021:A  platform:33:0:0

But somewhere would have to be stored for which platform was the build done.
We can guess it from the version prefix (36..., 35...) now. (ELN has no
prefix.)

Then when you build perl-DBI:1.643 which build- and run-requires perl:5.32:

- context: A
  buildrequires:
perl: [5.32]
  requires:
perl: [5.32]

the same way without platforms, MBS would expand a matrix of the platforms and
perls:

perl-DBI:1.643:362022:A platform:36:0:0 perl:5.32:362021:A
perl-DBI:1.643:352022:A platform:35:0:0 perl:5.32:352021:A
perl-DBI:1.643:342022:A platform:34:0:0 perl:5.32:342021:A
perl-DBI:1.643:332022:A platform:33:0:0 perl:5.32:332021:A

That would work. But how would a packager specify that he does not want to
build for all plaforms? E.g. he adds a module to Fedora 36 and is not
interested in the older ones. Or e.g. he stops maintaining the module and the
last supported is Fedora 35.

Maybe we could add a new field into the input file:

- platforms: [f33, f34, f35]
- context: A
  buildrequires:
perl: [5.32]
  requires:
perl: [5.32]

and default to all platforms if not specified.

When I shared this idea I was told that a context must change with a platform.
That everything (MBS?) assumes it. I believe I was also told another,
reasonable reason. But I cannot recall now. I'm sorry I cannot provide better
explanation now.

However, it's true that it does matter much whether the platform is encoded
into the version or into the context (perl:5.32:362021:A vs.
perl:5.32:2021:36A). If we hadn't it encoded anywhere, we could not store the
builds into Koji, and MBS:

perl:5.32:2021:A  platform:36:0:0
perl:5.32:2021:A  platform:35:0:0
perl:5.32:2021:A  platform:34:0:0
perl:5.32:2021:A  platform:33:0:0

And it's true that we would only special-case platform. It wouldn't be fair to
other modules. There must a stroger reason.

-- Petr


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

Re: libvirt and systemd-resolved integration?

[Peter Boy]

Hi all, 

I’m working on an update of the Fedora Server virtlib documentation 
(https://docs.fedoraproject.org/en-US/fedora-server/virtualization-install/), 
specifically the part about the DNS configration.

I would like to include and integrate the solutions presented in this thread by 
Daniel Berrange and by Juan Alcaine. But unfortunately none of the solutions 
worked in my test installations. I would be grateful if I could get some hints 
on what I might have missed.

The main challenge is to enable the host to resolve the internal name of the 
VMs. For this purpose, the DNS server provided by libvirt must be included in 
the search path (default virbr0 192.168.122.1). The server itself works fine. 
If you use dig or nsloookup to assign the servers, the names of the VMs are 
resolved correctly.



(a) === Installing libvirt-nss. (Daniel Berrange)  ===

I did the following

1. dnf install libvirt-nss

2. Modified following the libvirt documentation and the docs included with the 
files /etc/authselect/user-nsswitch.conf and edited the hosts item to "hosts:   
   files myhostname libvirt resolve [!UNAVAIL=return] dns“

3. executed:  authselect apply-changes

4. reboot

Neither using standard DNS without systems-resolved activated  nor using 
systemd-resolved could resolve the internal names of the VM



(b) === using libvirt hook dir to modify systemd-resolved configuration ===

I followed Juan Alcaine's instructions and after booting I got:

(for my homelab domain, served as public here)
Link 2 (enp1s0)
Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6
 Protocols: +DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 192.168.158.1
   DNS Servers: 192.168.158.1 fd00::3681:c4ff:fe14:21b4
DNS Domain: fritz.box

(for my internal domain via libvirt ipv4 only)
Link 5 (virbr0)
Current Scopes: DNS LLMNR/IPv4
 Protocols: +DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 192.168.122.1
   DNS Servers: 192.168.122.1
DNS Domain: fritz.lan 

The internal names could be resolved, but with such a long delay that the 
solution is practically unusable. The „host“ utility provided the internal IPv4 
name immediately, but continued searching for several seconds and finally the 
process was terminated with 2 times of the message ";; connection timed out; no 
servers could be reached“.  

In the systemd-resolved log I found a lot of entries like

Firing regular transaction 50808 for  scope dns on 
virbr0/* (validate=yes). 

But virbr0 is ipv4 only.


Any advice greatly  appreciated. 


Peter





> Am 08.10.2020 um 09:33 schrieb Juan Orti Alcaine :
> 
> 
> 
> El mié., 7 oct. 2020 a las 10:35, Petr Menšík () 
> escribió:
> 
> 
> On 10/7/20 6:44 AM, Pavel Zhukov wrote:
> > 
> > I don't think it's a good idea.
> > dnsmasq is not dns resolver but acts as DHCP and DNS server. It provides
> > VMs with IP
> > address/lease and create corresponding dns record for it. In case of
> > resolved ip addresses and dns records must be managed either manually
> > or... with dnsmasq.
> 
> That is not true. Any query sent to @192.168.122.1 would get reply. I
> use for example unbound on localhost and all my machines use .vm. domain
> suffix. rhel7.vm. is machine with rhel7. Dnsmasq manages automatically
> lease names of all its dhcp clients, it works as dynamic DNS connected
> with DHCP just out of the box.
> 
> I've created a libvirt hook to do the integration I was looking for. This 
> works for me:
> 
> /etc/libvirt/hooks/network.d/laptop-lab.sh
> 
> #!/bin/bash
> set -o nounset
> 
> object="$1"
> operation="$2"
> suboperation="$3"
> extra="$4"
> 
> if [ "$object" == "laptop-lab" ]; then
> if [ "$operation" == "started" ] && [ "$suboperation" == "begin" ]; then
> /usr/bin/resolvectl dns laptop-lab 192.168.100.1
> /usr/bin/resolvectl domain laptop-lab laptop.lab
> /usr/bin/resolvectl dnssec laptop-lab no
> fi
> fi
> ___
> 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
___
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: FF builds

[stan via devel]

On Thu, 9 Sep 2021 12:42:09 -0400
Demi Marie Obenour  wrote:

> On 9/8/21 10:49 PM, Bojan Smojver via devel wrote:
> > Just being devil's advocate for a second here...
> > 
> > Two days to build FF in koji? Has it gotten that big or are the
> > builds that slow?
> > 
> >  :-)  
> 
> This is also a security problem: consider a 0day exploit found in the
> wild.
> 
> Should the FF builds be given more resources?  Does Mozilla provide a
> signed Flatpak that could be used instead?

If you absolutely required a security fix, you could get the latest
nightly build from mozilla.org and run it from outside the system
directories.  If you always want the latest firefox you could build
the latest nightly from a source repository locally (takes about 90
minutes here on a not very powerful machine) and install it in
usr/local. Needs lots of development packages installed.

For integration and no worry, the fedora package is the way to go for
most people.  The issue here is rare in fedora in my experience (that
an exploit is revealed before fedora has it fixed in its repositories).
___
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: Disable locale forwarding in OpenSSH

[Yanko Kaneti]

On Thu, 2021-09-09 at 12:07 +0200, Florian Weimer wrote:
> There is a movement towards C.UTF-8 for small images (containers and
> VMs).  C.UTF-8 has both size and performance improvements over the more
> traditional en_US.UTF-8 locale.  (The performance improvement is
> currently in upstream glibc only, but we plan to bring it to rawhide and
> Fedora 35 shortly.)
> 
> However, in a world where glibc-langpack-en (or glibc-all-langpacks) is
> not installed on target systems, logging in over SSH does not result in
> a viable locale if the client use en_US.UTF-8 (or any other locale
> except C or C.UTF-8).  This causes a severe degradation in user
> experience.  It's not only that UTF-8 output does not work, there are
> also frequent warning messages from various tools.  Some may even refuse
> to run completely.
> 
> I tried to bring up this topic on the OpenSSH list to get some
> cross-distribution consensus, but the discussion didn't actually go
> anywhere:
> 
>   Phasing out forwarding of locale settings
>   
> 
> 
> I think Fedora should do this unilaterally, dropping the downstream
> additions that enable locale forwarding in both the default client and
> server configurations.  If we do that, the OpenSSH server will use the
> locale as configured with localectl for new interactive and
> non-interactive sessions, which is C.UTF-8 in many cases.  At least
> that's what my testing on Fedora 33 suggests.
> 
> Comments?

Wouldn't it be less disruptive to add only to the C.UTF-8-only
environments:

Match *
SetEnv LC_xxx=C.UTF-8 .. 


In a sshd_config_d snippet or something... ?

- Yanko
___
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-20210910.n.0 compose check report

[Fedora compose checker]

Missing expected images:

Xfce raw-xz armhfp

Compose FAILS proposed Rawhide gating check!
1 of 43 required test results missing
Unsatisfied gating requirements that could not be mapped to openQA tests:
MISSING: fedora.Cloud_Base-qcow2-qcow2.x86_64.64bit - compose.cloud_autocloud

Failed openQA tests: 11/207 (x86_64), 12/141 (aarch64)

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

ID: 975580  Test: x86_64 KDE-live-iso desktop_notifications_live
URL: https://openqa.fedoraproject.org/tests/975580
ID: 975589  Test: x86_64 KDE-live-iso desktop_login
URL: https://openqa.fedoraproject.org/tests/975589
ID: 975623  Test: aarch64 Server-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/975623
ID: 975632  Test: aarch64 Server-dvd-iso anaconda_help@uefi
URL: https://openqa.fedoraproject.org/tests/975632
ID: 975708  Test: x86_64 universal install_cyrillic_language
URL: https://openqa.fedoraproject.org/tests/975708
ID: 975714  Test: x86_64 universal install_delete_partial
URL: https://openqa.fedoraproject.org/tests/975714
ID: 975747  Test: x86_64 universal install_european_language
URL: https://openqa.fedoraproject.org/tests/975747
ID: 975767  Test: x86_64 universal upgrade_minimal_uefi@uefi
URL: https://openqa.fedoraproject.org/tests/975767
ID: 975835  Test: aarch64 Workstation-raw_xz-raw.xz 
install_arm_image_deployment_upload@uefi
URL: https://openqa.fedoraproject.org/tests/975835
ID: 975852  Test: aarch64 universal install_mirrorlist_graphical@uefi
URL: https://openqa.fedoraproject.org/tests/975852

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

ID: 975549  Test: x86_64 Workstation-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/975549
ID: 975576  Test: x86_64 KDE-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/975576
ID: 975581  Test: x86_64 KDE-live-iso desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/975581
ID: 975636  Test: aarch64 Server-dvd-iso support_server@uefi
URL: https://openqa.fedoraproject.org/tests/975636
ID: 975665  Test: aarch64 Server-dvd-iso server_cockpit_basic@uefi
URL: https://openqa.fedoraproject.org/tests/975665
ID: 975667  Test: aarch64 Server-dvd-iso 
install_repository_nfs_variation@uefi
URL: https://openqa.fedoraproject.org/tests/975667
ID: 975668  Test: aarch64 Server-dvd-iso 
install_repository_nfsiso_variation@uefi
URL: https://openqa.fedoraproject.org/tests/975668
ID: 975738  Test: x86_64 universal install_asian_language
URL: https://openqa.fedoraproject.org/tests/975738
ID: 975764  Test: x86_64 universal memtest
URL: https://openqa.fedoraproject.org/tests/975764
ID: 975783  Test: aarch64 universal install_asian_language@uefi
URL: https://openqa.fedoraproject.org/tests/975783
ID: 975803  Test: aarch64 universal install_arabic_language@uefi
URL: https://openqa.fedoraproject.org/tests/975803
ID: 975815  Test: aarch64 universal upgrade_minimal_64bit@uefi
URL: https://openqa.fedoraproject.org/tests/975815
ID: 975822  Test: aarch64 universal install_cyrillic_language@uefi
URL: https://openqa.fedoraproject.org/tests/975822

Soft failed openQA tests: 13/207 (x86_64), 6/141 (aarch64)
(Tests completed, but using a workaround for a known bug)

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

ID: 975545  Test: x86_64 Workstation-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/975545
ID: 975551  Test: x86_64 Workstation-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/975551
ID: 975560  Test: x86_64 Workstation-live-iso gedit
URL: https://openqa.fedoraproject.org/tests/975560
ID: 975591  Test: x86_64 Silverblue-dvd_ostree-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/975591
ID: 975592  Test: x86_64 Silverblue-dvd_ostree-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/975592
ID: 975594  Test: x86_64 Silverblue-dvd_ostree-iso evince
URL: https://openqa.fedoraproject.org/tests/975594
ID: 975595  Test: x86_64 Silverblue-dvd_ostree-iso gedit
URL: https://openqa.fedoraproject.org/tests/975595
ID: 975610  Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi
URL: https://openqa.fedoraproject.org/tests/975610
ID: 975614  Test: aarch64 Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload@uefi
URL: https://openqa.fedoraproject.org/tests/975614
ID: 975671  Test: aarch64 Server-raw_xz-raw.xz 
install_arm_image_deployment_upload@uefi
URL: https://openqa.fedoraproject.org/tests/975671
ID: 975699  Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi
URL: https://openqa.fedoraproject.org/tests/975699
ID: 975736  Test: x86_64 universal upgrade_server_64bit
URL: https://openqa.fedoraproject.org/tests/975736
ID: 975743  Test: x86_64 universal upgrade_2_server_domain_controller
URL: 

Fedora 35 compose report: 20210910.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-35-20210909.n.0
NEW: Fedora-35-20210910.n.0

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

Size of added packages:  0 B
Size of dropped packages:32.51 KiB
Size of upgraded packages:   0 B
Size of downgraded packages: 0 B

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

= ADDED IMAGES =

= DROPPED IMAGES =

= ADDED PACKAGES =

= DROPPED PACKAGES =
Package: php-pear-Text-Diff-1.2.2-10.fc34
Summary: Engine for performing and rendering text diffs
RPMs:php-pear-Text-Diff
Size:32.51 KiB


= UPGRADED PACKAGES =

= DOWNGRADED PACKAGES =
___
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 2003159] New: perl-Prima-1.63 is available

[bugzilla]

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

Bug ID: 2003159
   Summary: perl-Prima-1.63 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Prima
  Keywords: FutureFeature, Triaged
  Assignee: ppi...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: lkund...@v3.sk, perl-devel@lists.fedoraproject.org,
ppi...@redhat.com
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 1.63
Current version/release in rawhide: 1.62-2.fc35
URL: http://search.cpan.org/dist/Prima/

Please consult the package updates policy before you issue an update to a
stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/


More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring


Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.


Based on the information from anitya:
https://release-monitoring.org/project/3289/


-- 
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: FF builds

[Miroslav Suchý]

Dne 09. 09. 21 v 18:54 Demi Marie Obenour napsal(a):

Can the Firefox build be distributed among multiple machines?


I would love to see a benchmark how much it speed up big packages and how it slow downs smaller packages. Whole rpmbuild 
part.



FYI

Mock has CCache plugin, which speeds the thing a bit, but can be easily 
exploited. So on build systems it is switched off.

Years ago I wrote blogpost about building in memory using tmpfs. That can give 
you up to 70% gain.

http://miroslav.suchy.cz/blog/archives/2015/05/28/increase_mock_performance_-_build_packages_in_memory/index.html

We use this in Copr. AFAIK Koji does not use it. You can join Fedora infra to 
change it :)

Miroslav

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

Re: Modularity: New modulemd-packager format for building modules

[Neal Gompa]

On Fri, Sep 10, 2021 at 8:26 AM Petr Pisar  wrote:
>
> Good news, module maintainers.
>
> I'm relieved to announce an availability of the new module packaging format,
> modulemd-packager, version 3.
>

So this certainly solves a lot of issues, but it's still frustrating
to see that we *need* to declare the platform and that we couldn't
inherit the platform from the build environment. This means that at
branching time, we need to make a commit to change the requested
platform.

That being said, does the platform value influence how the final
modulemd is generated? That is, if I made a system that accepted this
YAML file as input but *ignored* the platform value (and the platform
was forced by other means), would a module build still produce working modules?




--
真実はいつも一つ！/ 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

Modularity: New modulemd-packager format for building modules

[Petr Pisar]

Good news, module maintainers.

I'm relieved to announce an availability of the new module packaging format,
modulemd-packager, version 3.

Skip to "WHAT IS CHANGING" section to see the main message.


HISTORY
===

Up to now, you wrote a YAML document in modulemd-v2 format
:

document: modulemd
version: 2
data:
name: perl-DBI
stream: '1.643'
license:
module:
- MIT
dependencies:
- buildrequires:
platform: []
perl: []
  requires:
platform: []
perl: []
buildopts:
rpms:
macros: |
%this_is_my_module 1
components:
rpms:
perl-DBI:
rationale: API
ref: f34

You built it and an output were multiple module builds, one for each
combination of a Fedora release and a perl stream. E.g. this matrix:

buildrequires:
  platform: [f35, f34]
  perl: [5.30, 5.32]
requires:
  platform: [f35, f34]
  perl: [5.30, 5.32]

was expaned into 4 unique builds by MBS, Module Build Service. Observe the
last, "random" value, context:

perl-DBI:1.643:3420210211145152:7f057cb7
perl-DBI:1.643:3420210211145152:a450835c
perl-DBI:1.643:3520210211145152:2c956793
perl-DBI:1.643:3520210211145152:e12b6f3a

These output modules used the same modulemd-v2 format. It was deemed that
having the same input and output format is a benefit.


WHY
===

But it turned out that DNF had difficulties to upgrade from an older version of
a module to a newer one. The problem was that DNF could not identify which
build upgrades which one. E.g. having a Fedora 35 system with these builds in
a repository:

1  perl-DBI:1.643:3520210211145152:2c956793 * this one is installed
2  perl-DBI:1.643:3520210211145152:e12b6f3a

3  perl-DBI:1.643:3520210212105947:ab395794
4  perl-DBI:1.643:3520210212105947:c39b3af3

DNF did not know whether to upgrade to the 3rd build or the 4th one. Both of
them have the highest version. But which one to use? Context value is no clue
here because it differs from the older builds. This happens when a module is
changing its build-requires. (Actually first we observed this on RHEL where
the platform changes with each minor RHEL release.) Run-time dependencies are
also of no help because they could also change. (We also observed this on
RHEL. Original design used run-time dependencies for the selection.)

Therefore DNF maintainers declared that this problem is undecidable and
requested a change in Modularity.

Modularity team together with DNF maintainers identified that a culprit is the
random nature of the context and decided to sacrifice a stream expansion for
making the context static and predictable. It was designed that the context
value will be fully in hands of the module maintainers who will be able freely
add, remove, and maintain a module upgrade path by the means of the context:

Context Context Context
A   B   
↓   ↓   
Version 35202102111451523520210211145152
requires: perl:5.30 requires: perl:5.32 C (perl:5.34 added)
↓   ↓   ↓
Version 352021021210594735202102121059473520210212105947
(a new dep. requires: perl:5.30 requires: perl:5.32 requires: perl:5.34
 added) requires: nginx:1.20requires: nginx:1.20requires: nginx:1.20
(perl:5.30 ended)   ↓   ↓
Version 35202109302109433520210930210943
(nginx not  requires: perl:5.32 requires: perl:5.34
 req. anymore)  ↓   ↓


WHAT IS CHANGING


Since there was no place for the contexts in the old module format, a new,
input-only format "modulemd-packager", version 3, was designed and implemented
in MBS and other tools. At the opportunity of the format change, some other
pet peeves of the old format were solved.

Changes in the format include:

New document type and version:

document: modulemd-packager
version: 3

A "module" middle-field removed from the "license" section:

license:
- MIT

A "dependencies" section replaced with a "configurations" section:

configurations:
- context: A
  platform: f34
  buildrequires:
  perl: ['5.30']
  requires:
  perl: ['5.30']
- context: B
  platform: f34
  buildrequires:
  perl: ['5.32']
  requires:
  perl: ['5.32']
- context: C
  platform: f35
  buildrequires:
  perl: ['5.30']
  requires:
  perl: 

Fedora rawhide compose report: 20210910.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20210909.n.0
NEW: Fedora-Rawhide-20210910.n.0

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

Size of added packages:  113.62 MiB
Size of dropped packages:600.41 KiB
Size of upgraded packages:   2.95 GiB
Size of downgraded packages: 0 B

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

= ADDED IMAGES =

= DROPPED IMAGES =

= ADDED PACKAGES =
Package: stargz-snapshotter-0.8.0-1.fc36
Summary: Fast container image distribution plugin with lazy pulling
RPMs:stargz-snapshotter
Size:113.62 MiB


= DROPPED PACKAGES =
Package: php-pear-Text-Diff-1.2.2-10.fc34
Summary: Engine for performing and rendering text diffs
RPMs:php-pear-Text-Diff
Size:32.51 KiB

Package: vmem-1.8-7.fc35
Summary: Volatile Memory Development Kit
RPMs:libvmem libvmem-debug libvmem-devel libvmmalloc libvmmalloc-debug 
libvmmalloc-devel
Size:567.89 KiB


= UPGRADED PACKAGES =
Package:  anaconda-36.2-1.fc36
Old package:  anaconda-36.1-1.fc36
Summary:  Graphical system installer
RPMs: anaconda anaconda-core anaconda-dracut anaconda-gui 
anaconda-install-env-deps anaconda-install-img-deps anaconda-live anaconda-tui 
anaconda-widgets anaconda-widgets-devel
Size: 20.55 MiB
Size change:  -591.18 KiB
Changelog:
  * Thu Sep 09 2021 Martin Kolman  - 36.2-1
  - Add missing apostrophe to suggestion (rffontenelle)
  - Add test for new "nosave" config members (vslavik)
  - Remove nosave flags, use conf instead (vslavik)
  - Add (no)save options to Anaconda section of config (vslavik)
  - Define a unique id in the main spokes and hubs (vponcova)
  - Add the Screen class (vponcova)
  - Print progress dots on one line in TUI (honza.stodola)
  - Cleanup unneeded NFS repo with rd.live.ram parameter (mmatsuya)
  - Include the anaconda-generator script in the updates image (vponcova)
  - Don't run shell on every found virtualization console (vponcova)


Package:  awf-gtk2-2.6.0-1.fc36
Old package:  awf-gtk2-2.5.0-2.fc35
Summary:  Theme preview application for GTK
RPMs: awf-gtk2
Size: 266.11 KiB
Size change:  -3.67 KiB
Changelog:
  * Thu Sep 09 2021 Fabrice Creuzot  - 2.6.0-1
  - New upstream version


Package:  awf-gtk3-2.6.0-1.fc36
Old package:  awf-gtk3-2.5.0-2.fc35
Summary:  Theme preview application for GTK
RPMs: awf-gtk3
Size: 272.63 KiB
Size change:  -3.12 KiB
Changelog:
  * Thu Sep 09 2021 Fabrice Creuzot  - 2.6.0-1
  - New upstream version


Package:  awf-gtk4-2.6.0-1.fc36
Old package:  awf-gtk4-2.5.0-2.fc35
Summary:  Theme preview application for GTK
RPMs: awf-gtk4
Size: 269.29 KiB
Size change:  -2.67 KiB
Changelog:
  * Thu Sep 09 2021 Fabrice Creuzot  - 2.6.0-1
  - New upstream version


Package:  awscli-1.20.39-1.fc36
Old package:  awscli-1.20.38-1.fc36
Summary:  Universal Command Line Environment for AWS
RPMs: awscli
Size: 2.10 MiB
Size change:  -513 B
Changelog:
  * Thu Sep 09 2021 Gwyn Ciesla  - 1.20.39-1
  - 1.20.39


Package:  cabal-install-3.2.0.0-2.fc36
Old package:  cabal-install-3.2.0.0-1.fc35
Summary:  The command-line interface for Cabal and Hackage
RPMs: cabal-install
Size: 37.62 MiB
Size change:  2.49 KiB
Changelog:
  * Thu Sep 09 2021 Jens Petersen  - 3.2.0.0-2
  - recommends zlib-devel for convenience
  - fix the sdist file permissions patch to compile in 3.2


Package:  dnsmasq-2.86-1.fc36
Old package:  dnsmasq-2.85-6.fc35
Summary:  A lightweight DHCP/caching DNS server
RPMs: dnsmasq dnsmasq-utils
Size: 1.81 MiB
Size change:  43.01 KiB
Changelog:
  * Thu Sep 09 2021 Petr Menk  - 2.86-1
  - Update to 2.86 (#2002475)
  - Apply coverity detected issues patches


Package:  drupal7-views-3.24-5.fc36
Old package:  drupal7-views-3.24-4.fc34
Summary:  Create customized lists and queries from your database
RPMs: drupal7-views
Size: 1.53 MiB
Size change:  940 B
Changelog:
  * Wed Jul 21 2021 Fedora Release Engineering  - 
3.24-5
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_35_Mass_Rebuild


Package:  fedora-obsolete-packages-36-3
Old package:  fedora-obsolete-packages-36-2
Summary:  A package to obsolete retired packages
RPMs: fedora-obsolete-packages
Size: 27.58 KiB
Size change:  -547 B
Changelog:
  * Thu Sep 09 2021 Petr Pisar  - 36-3
  - Obsolete perl-Mozilla-LDAP


Package:  fio-3.28-1.fc36
Old package:  fio-3.27-3.fc36
Summary:  Multithreaded IO generation tool
RPMs: fio fio-engine-dev-dax fio-engine-http fio-engine-libaio 
fio-engine-libpmem fio-engine-nbd fio-engine-pmemblk fio-engine-rados 
fio-engine-rbd fio-engine-rdma
Size: 26.33 MiB
Size change:  23.08 MiB

Package:  firefox-92.0-2.fc36
Old package:  firefox-91.0.2-1.fc36
Summary:   

Fedora-IoT-34-20210910.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-34-20210820.0):

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

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-20210820.0):

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

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

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

Re: [Fedocal] Reminder meeting : ELN SIG

[Stephen Gallagher]

ELN Agenda for this meeting:

* s390x container images
* DistroBuildSync update
* Content Resolver and ELN-Extras
___
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

Review swap request: python-datalad

[Ankur Sinha]

Hi folks,

The deps are all packaged so datalad is also up for review now:
https://bugzilla.redhat.com/show_bug.cgi?id=2002848

Happy to swap reviews, as always :)

It's an awesome tool for use in scientific (and other) work. Here's the
handbook for a quick glance:
http://handbook.datalad.org/en/latest/

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


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

Fedora-Cloud-34-20210910.0 compose check report

[Fedora compose checker]

No missing expected images.

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

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

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

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

Re: F35 3x slower boot than F34

[Marius Schwarz]

Am 03.09.21 um 18:51 schrieb Chris Murphy:

Bug 2001057 - F35 boots 3x slower than F34, large time gaps in systemd journal
https://bugzilla.redhat.com/show_bug.cgi?id=2001057


This one really has gotten my goat. I'm not finding any reason why
it's taking this long to boot. Usually the critica-chain or svg plot
exposes the culprit but not in this case, I just have multiple 10s+
gaps in the journal.

I might have to do some tedious regression testing by doing a clean
install of 35 to see if it's some artifact of upgrading from 34. But
it'd be nicer if I can just directly expose the culprit(s).



Any updates on this?

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

Fedora-Cloud-33-20210910.0 compose check report

[Fedora compose checker]

No missing expected images.

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

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

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

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