devel November 2020

devel@lists.fedoraproject.org

244 participants
344 discussions

libcap-ng update coming to rawhide
by Steve Grubb 20 Nov '20

20 Nov '20

Hello, A new version of libcap-ng is going to be released next week. Normally this isn't newsworthy, nor is this a soname version bump. But it is important to let the broader community know something about it. The behaviour of capng_apply is changing slightly. In the past, capng_apply would silently eat errors when the bounding set could not be changed. In order to change the bounding set, you have to have CAP_SETPCAP. A developer reported an issue in github where their project needed to know that capng_apply was completely successful changing the bounding set. Meaning that they need an error returned. I didn't think too much of it and made the change. Then one day I noticed that I could not update a package against Fedora's git or push a change. Looking into this, I found gnome-keyring was not working. [1] I dug into the source code and found that it was trying to change the bounding set when it had partial capabilities. The fix is to simply verify that you have CAP_SETPCAP before attempting this. I don't know of any other software that is affected. But I wanted to give everyone a heads up before I push it out. I always dogfood libraries I work on, so maybe this is the only issue. Eventually libcap-ng needs to get pushed over to F33 because there is a problem with ambient capailities that the new release fixes. And speaking of ambient capabilities, the new version of libcap-ng contains a new library libdrop_ambient.so. You can use it with LD_PRELOAD to force an app to drop ambient capabilities leaving the other capabilities intact. All the work is done in the constructor, so no function calls are needed. Best Regards, -Steve 1 - https://bugzilla.redhat.com/show_bug.cgi?id=1888978

2 3

Schedule for Wednesday's FESCo Meeting (2020-11-11)
by David Cantrell 20 Nov '20

20 Nov '20

Following is the list of topics that will be discussed in the FESCo meeting Wednesday at 15:00UTC in #fedora-meeting-2 on irc.freenode.net. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/UTCHowto or run: date -d '2020-11-11 15:00 UTC' Links to all issues to be discussed can be found at: https://pagure.io/fesco/report/meeting_agenda = Discussed and Voted in the Ticket = Move the FESCo meeting +1 hour (to 15:00 UTC) when DST is not in action https://pagure.io/fesco/issue/2496 APPROVED (+6, 2, -0) F35 System-Wide Change: Python 3.10 https://pagure.io/fesco/issue/2494 APPROVED (+8, 0, -0) Nonresponsive maintainer: Mark Chappell (tremble) https://pagure.io/fesco/issue/2492 APPROVED (+4, 0, -0) Nonresponsive maintainer: Marek Cermak macermak https://pagure.io/fesco/issue/2491 APPROVED (+3, 0, -0) = New business = #2495 Election Interview Questions — FESCo (Fedora 33) https://pagure.io/fesco/issue/2495 #2475 proposal: let's develop the idea of a new repo for lightly-maintained packages https://pagure.io/fesco/issue/2475 #2473 updates policy is out of date https://pagure.io/fesco/issue/2473 = Open Floor = For more complete details, please visit each individual issue. The report of the agenda items can be found at https://pagure.io/fesco/report/meeting_agenda If you would like to add something to this agenda, you can reply to this e-mail, file a new issue at https://pagure.io/fesco, e-mail me directly, or bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting. -- David Cantrell <dcantrell(a)redhat.com> Red Hat, Inc. | Boston, MA | EST5EDT

19 43

Mock needs more space
by Brandon Nielsen 20 Nov '20

20 Nov '20

I'm attempting an armhfp build with mock and it insists it needs "At least 243MB more space needed on the / filesystem." I have 1.1 TB free on /, so I'm assuming there's some kind of limit set somehow, but I can't figure out how to adjust it. I don't see anything that looks promising in the config files, or the manpage. Anybody have a clue for me?

3 3

systemd-resolved in a container
by Nikos Mavrogiannopoulos 20 Nov '20

20 Nov '20

Hi, I realized my fedora-based containers have an /etc/resolv.conf which claims it is managed by resolved, and nsswitch.conf has "resolve" in hosts. However, doing something like # systemd-resolve --status results to: sd_bus_open_system: No such file or directory Trying to start dbus claims that systemd is not the init: # systemctl start dbus System has not been booted with systemd as init system (PID 1). Can't operate. Failed to connect to bus: Host is down Is there a way to use systemd resolved in a container? regards, Nikos

4 8

Fedora-Cloud-31-20201120.0 compose check report
by Fedora compose checker 20 Nov '20

20 Nov '20

No missing expected images. Passed openQA tests: 7/7 (x86_64), 7/7 (aarch64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose

1 0

Fedora-Cloud-32-20201120.0 compose check report
by Fedora compose checker 20 Nov '20

20 Nov '20

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-20201119.0): ID: 726232 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/726232 ID: 726239 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/726239 Passed openQA tests: 6/7 (x86_64), 6/7 (aarch64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose

1 0

Fedora-Cloud-33-20201120.0 compose check report
by Fedora compose checker 20 Nov '20

20 Nov '20

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-20201119.0): ID: 726218 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/726218 ID: 726225 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/726225 Passed openQA tests: 6/7 (x86_64), 6/7 (aarch64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose

1 0

Python dependency missing during RPM build
by Richard W.M. Jones 19 Nov '20

19 Nov '20

It's not a big deal because I added the Python Requires: line by hand, but I want to make sure I understand why it happens and whether there's an easy fix. https://koji.fedoraproject.org/koji/taskinfo?taskID=55889416 https://src.fedoraproject.org/rpms/nbdkit/blob/master/f/nbdkit.spec#_475 This subpackage contains a Python file: $ rpm -qlp ./nbdkit-S3-plugin-1.23.9-1.fc34.x86_64.rpm /usr/lib64/nbdkit/plugins/nbdkit-S3-plugin <--- this one /usr/share/doc/nbdkit-S3-plugin /usr/share/doc/nbdkit-S3-plugin/README /usr/share/licenses/nbdkit-S3-plugin /usr/share/licenses/nbdkit-S3-plugin/LICENSE /usr/share/man/man1/nbdkit-S3-plugin.1.gz The automatically generated dependencies don't pick up the need for python3-boto3. $ grep ^import nbdkit-S3-plugin import nbdkit import boto3 $ rpm -qRp ./nbdkit-S3-plugin-1.23.9-1.fc34.x86_64.rpm /usr/sbin/nbdkit nbdkit-python-plugin >= 1.22 rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(FileDigests) <= 4.6.0-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 rpmlib(PayloadIsZstd) <= 5.4.18-1 (As I said above, I added it explicitly, which is why the RPM built in Koji above _does_ contain the boto3 dependency). Now admittedly the Python file doesn't end in .py and doesn't have a python shebang at the top. But: $ file nbdkit-S3-plugin nbdkit-S3-plugin: Python script, ASCII text executable which seems as if it matches the %__python_magic regexp in /usr/lib/rpm/fileattrs/python.attr. So perhaps it _ought_ to work and something is wrong on the machine I'm using to reproduce this? Alternatively is there another way to tell the dependency generator to take a special look at this file? Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://people.redhat.com/~rjones/virt-top

2 2

Fedora-IoT-33-20201119.0 compose check report
by Fedora compose checker 19 Nov '20

19 Nov '20

No missing expected images. Failed openQA tests: 1/16 (x86_64), 1/15 (aarch64) Old failures (same test failed in Fedora-IoT-33-20201117.0): ID: 725719 Test: x86_64 IoT-dvd_ostree-iso iot_clevis URL: https://openqa.fedoraproject.org/tests/725719 ID: 725735 Test: aarch64 IoT-dvd_ostree-iso iot_clevis@uefi URL: https://openqa.fedoraproject.org/tests/725735 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.18 to 0.37 Previous test data: https://openqa.fedoraproject.org/tests/723990#downloads Current test data: https://openqa.fedoraproject.org/tests/725736#downloads -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose

1 0

Fedora-IoT-34-20201119.0 compose check report
by Fedora compose checker 19 Nov '20

19 Nov '20

No missing expected images. Failed openQA tests: 2/16 (x86_64), 5/15 (aarch64) Old failures (same test failed in Fedora-IoT-34-20201118.0): ID: 725582 Test: x86_64 IoT-dvd_ostree-iso iot_clevis URL: https://openqa.fedoraproject.org/tests/725582 ID: 725594 Test: x86_64 IoT-dvd_ostree-iso base_services_start URL: https://openqa.fedoraproject.org/tests/725594 ID: 725598 Test: aarch64 IoT-dvd_ostree-iso iot_clevis@uefi URL: https://openqa.fedoraproject.org/tests/725598 ID: 725600 Test: aarch64 IoT-dvd_ostree-iso base_services_start@uefi URL: https://openqa.fedoraproject.org/tests/725600 ID: 725602 Test: aarch64 IoT-dvd_ostree-iso podman@uefi URL: https://openqa.fedoraproject.org/tests/725602 ID: 725603 Test: aarch64 IoT-dvd_ostree-iso podman_client@uefi URL: https://openqa.fedoraproject.org/tests/725603 ID: 725606 Test: aarch64 IoT-dvd_ostree-iso iot_rpmostree_overlay@uefi URL: https://openqa.fedoraproject.org/tests/725606 Passed openQA tests: 14/16 (x86_64), 10/15 (aarch64) New passes (same test not passed in Fedora-IoT-34-20201118.0): ID: 725590 Test: x86_64 IoT-dvd_ostree-iso iot_zezere_server URL: https://openqa.fedoraproject.org/tests/725590 ID: 725597 Test: x86_64 IoT-dvd_ostree-iso iot_zezere_ignition URL: https://openqa.fedoraproject.org/tests/725597 ID: 725601 Test: aarch64 IoT-dvd_ostree-iso release_identification@uefi URL: https://openqa.fedoraproject.org/tests/725601 ID: 725608 Test: aarch64 IoT-dvd_ostree-iso iot_zezere_server@uefi URL: https://openqa.fedoraproject.org/tests/725608 ID: 725612 Test: aarch64 IoT-dvd_ostree-iso iot_zezere_ignition@uefi URL: https://openqa.fedoraproject.org/tests/725612 Installed system changes in test aarch64 IoT-dvd_ostree-iso install_default_upload@uefi: 1 services(s) added since previous compose: systemd-homed-activate.service Previous test data: https://openqa.fedoraproject.org/tests/724950#downloads Current test data: https://openqa.fedoraproject.org/tests/725599#downloads -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose

1 0

← Newer
1
...
11
12
13
14
15
16
17
...
35
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

devel November 2020