devel March 2021

devel@lists.fedoraproject.org

208 participants
455 discussions

Fedora-Cloud-32-20210302.0 compose check report
by Fedora compose checker 02 Mar '21

02 Mar '21

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-20210301.0): ID: 794966 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/794966 ID: 794973 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/794973 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-20210302.0 compose check report
by Fedora compose checker 02 Mar '21

02 Mar '21

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

1 0

split-DNS, resolvconf on Fedora
by Petr Menšík 01 Mar '21

01 Mar '21

Hi, I have submitted new package openresolv [1], which provides resolvconf tool, similar to Debian's resolvconf package. Why? I thought about common interface to various DNS cache implementations for workstations and different VPN providers available. While I think the best place to direct, which interface resolvers should handle given domains. resolvconf handles conflicting requests from different interfaces, when multiple DNS resolver providers are configured by connection. Current Fedora 33 already has /usr/sbin/resolvconf provided by systemd-resolved. It provides split-DNS implementation in default Fedora installation[2]. Problem is this is useful only in case systemd-resolved service is running and used. When it is disabled, its resolvconf just fails. But because systemd-resolved does not have its own subpackage, the daemon can be only disabled, not uninstalled. My question is, how should dhclient or vpn provider check resolvconf is installed and enabled? It usually checks [ -x /usr/sbin/resolvconf ] in Debian from shell, but because resolvconf is always present on Fedora, it cannot work. Unlike Debian, where systemd does not provide resolvconf. How could it therefore check, how should be /etc/resolv.conf updated? How would dhclient know, when to rewrite /etc/resolv.conf itself or when to use resolvconf for coordinated changes? I think Network Manager should manage DNS domains list per connection IMO. But in cases VPN provider is not configured via NM or NM is not even used, I think resolvconf is good alternative to set and restore the system's /etc/resolv.conf, when any VPN service is started. Only systemd-resolved and dnsmasq can support split-DNS from NM. openresolv is written only in shell, has no other dependencies. It could support multiple DNS implementations as a local cache[3]. It currently breaks systemd's symlink /usr/sbin/resolvconf, it uses alternatives links. But systemd package does not use it, so after uninstallation of openresolv, resolvconf remains broken. I think this has to be solved by systemd package. Do you have any opinion, how should resolvconf be supported on Fedora? Any opinion against it? 1. https://src.fedoraproject.org/rpms/openresolv 2. https://fedoraproject.org/wiki/Changes/systemd-resolved#Split_DNS 3. https://roy.marples.name/projects/openresolv/configuration/ -- Petr Menšík Software Engineer Red Hat, http://www.redhat.com/ email: pemensik(a)redhat.com PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB

9 19

Policy proposal (draft): Don't push knowingly broken or work-in-progress work to dist git
by Miro Hrončok 01 Mar '21

01 Mar '21

Hello, When we work on rebuilding Python packages with new Python version and when other provenpackagers rebuild multiple packages at once, I've seen several problems with packages failing to build from source and/or creating unexpected breakage in rawhide when built. Usually, some of the following happens: 1. Untested changes Packager pushes a "simple update" to dist git without checking if it even builds. It doesn't. Packager has no time to fix this, so they move on for now. Or they submit a build but never check if it actually built. Provenpackagers who need to rebuild the package need to figure this out and fix the problem if it is trivial, or revert the recent commit, when the failure blocks them. IMHO Provenpackagers should not need to worry about this. Changes should be at least smoke tested by a mock/scratch build and installation check before shipping them. 2. Changes that work but are waiting on external factors Packager pushes a breaking change to dist git (such as a soname bump) before coordinating the change with the dependent packages, not intending to immediately build it. A provenpackager rebuilds the package for a different reason (such as a different soname bump), accidentally shipping the not-yet-wanted upgrade to rawhide. IMHO Provenpackagers should not need to worry about this. Commits should land in dist git only when they are intended to be built (close to) immediately. The only reasonable exception is when building the pushed changes in a side tag and even then, packagers should communicate their intentions. 3. Work-in-progress changes Packager works on a package. They have a work in progress solution to their problem, but no time to finish. They push a "WIP" commit that either breaks the build or produces a broken package. The symptoms are similar to (1) or (2). I've heard packagers saying "but this is rawhide, this is where development happens, so this is expected" - I disagree. --- I'd like to explicitly say that neither of this is considered a good behavior. I'd like to have a policy that more or less says: 1. Packagers MUST NOT push changes that are not considered ready to be built and shipped at the time of the push. Using Pull Requests (clearly marked as not ready to be merged) is a better place to present/save changes that are not ready yet. 2. Packagers SHOULD preemptively check if the changes they intend to push work. At least checking if the intended change builds and the package installs with it is strongly recommended. In cases where the check is skipped for time reasons (e.g. when a testing build takes several hours and the changes are urgent), packagers SHOULD be ready to fix the build/installation failure in timely manner after it is discovered by the actual build. Before I try to word it more carefully I'd like to hear some feedback on this. What do you think? -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok

23 69

FedoraRespin-33-updates-20210301.0 compose check report
by Fedora compose checker 01 Mar '21

01 Mar '21

No missing expected images. Failed openQA tests: 5/37 (x86_64) ID: 794467 Test: x86_64 Workstation-live-iso desktop_notifications_live URL: https://openqa.fedoraproject.org/tests/794467 ID: 794484 Test: x86_64 Workstation-live-iso desktop_login URL: https://openqa.fedoraproject.org/tests/794484 ID: 794489 Test: x86_64 KDE-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/794489 ID: 794497 Test: x86_64 KDE-live-iso release_identification URL: https://openqa.fedoraproject.org/tests/794497 ID: 794500 Test: x86_64 KDE-live-iso desktop_notifications_postinstall URL: https://openqa.fedoraproject.org/tests/794500 Passed openQA tests: 32/37 (x86_64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose

1 0

Self Introduction: Phil
by Phil Dibowitz 01 Mar '21

01 Mar '21

Hey all, Hi I'm Phil, a new Fedora packager! Some of you may know me from devconf (both CZ and US) during my time at Facebook or as one of the co-founders of the Southern California Linux Expo (SCALE) conference. For the rest of you, hi, I'm Phil, nice to meet you! :) I've been working on opensource - both my own and others - for over 2 decades now. I'm the primary author of iptstate, sugarjar, concordance, and PIUS. I'm a maintainer of Chef and Redhat's init-scripts/network-scripts. I've contributed to a bunch of other crap including the kernel. I'm primarily going through the packager process to get sugarjar packaged for Fedora. For those interested, sugarjar is a tool to help make working with github easier - especially when doing rebase or squash-based workflows which the base git tools struggle with. It is mostly just a glorified wrapper around `hub` and `git`. And as suggested, my PGP fingerprint: 121B DA2D 4ACB 6361 6B36 7A0E 58E1 1BB1 E414 D9AD If I missed anything I should have included, yell at me accordingly. ;) -- Phil Dibowitz phil(a)ipom.com Open Source software and tech docs Insanity Palace of Metallica http://www.phildev.net/ http://www.ipom.com/ "Be who you are and say what you feel, because those who mind don't matter and those who matter don't mind." - Dr. Seuss

4 3

Fedora-IoT-35-20210301.0 compose check report
by Fedora compose checker 01 Mar '21

01 Mar '21

Missing expected images: Iot dvd x86_64 Iot dvd aarch64 Failed openQA tests: 7/15 (aarch64), 1/16 (x86_64) New failures (same test not failed in Fedora-IoT-35-20210227.0): ID: 794426 Test: aarch64 IoT-dvd_ostree-iso iot_zezere_server@uefi URL: https://openqa.fedoraproject.org/tests/794426 ID: 794435 Test: aarch64 IoT-dvd_ostree-iso iot_zezere_ignition@uefi URL: https://openqa.fedoraproject.org/tests/794435 Old failures (same test failed in Fedora-IoT-35-20210227.0): ID: 794399 Test: x86_64 IoT-dvd_ostree-iso base_services_start URL: https://openqa.fedoraproject.org/tests/794399 ID: 794408 Test: aarch64 IoT-dvd_ostree-iso iot_clevis@uefi URL: https://openqa.fedoraproject.org/tests/794408 ID: 794424 Test: aarch64 IoT-dvd_ostree-iso iot_rpmostree_overlay@uefi URL: https://openqa.fedoraproject.org/tests/794424 ID: 794429 Test: aarch64 IoT-dvd_ostree-iso base_services_start@uefi URL: https://openqa.fedoraproject.org/tests/794429 ID: 794432 Test: aarch64 IoT-dvd_ostree-iso podman@uefi URL: https://openqa.fedoraproject.org/tests/794432 ID: 794433 Test: aarch64 IoT-dvd_ostree-iso podman_client@uefi URL: https://openqa.fedoraproject.org/tests/794433 Soft failed openQA tests: 3/16 (x86_64), 1/15 (aarch64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-IoT-35-20210227.0): ID: 794391 Test: x86_64 IoT-dvd_ostree-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/794391 ID: 794392 Test: x86_64 IoT-dvd_ostree-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/794392 ID: 794393 Test: x86_64 IoT-dvd_ostree-iso iot_clevis URL: https://openqa.fedoraproject.org/tests/794393 ID: 794422 Test: aarch64 IoT-dvd_ostree-iso install_default_upload@uefi URL: https://openqa.fedoraproject.org/tests/794422 Passed openQA tests: 12/16 (x86_64), 7/15 (aarch64) Installed system changes in test aarch64 IoT-dvd_ostree-iso install_default_upload@uefi: System load changed from 0.36 to 0.19 Previous test data: https://openqa.fedoraproject.org/tests/793084#downloads Current test data: https://openqa.fedoraproject.org/tests/794422#downloads -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose

1 0

Dilemma: -source repository data randomized by koji builder arch
by Fabio Valentini 01 Mar '21

01 Mar '21

Hello everybody, There's a problem that's been puzzling me for months, since I started writing the repochecker service (which provides the backend FTI/FTBFS data for the new packager-dashboard): There is no correct "source of truth" for BuildRequires / complete package dependency graphs. While SRPM *contents* are forbidden from being dependent on their environment (e.g. Sources or Patches guarded by %ifarch / %if %fedora), their metadata (RPM headers) will still potentially be architecture-dependent. For example: The most frequent case of this is packages disabling support for Qt5WebEngine on ppc64le and s390x, because it's not available on those architectures. That means %ifarch conditionals wrapping the BuildRequires for Qt5WebEngine. But that leads to the interesting problem of the SRPM file having architecture-dependent RPM headers. However, because koji only keeps *one* SRPM file from each build (even though they have potentially different metadata on different architectures), and the architecture that one SRPM is generated on is basically random, the contents of the -source repositories are, basically, randomized, and unreliable. The architecture-dependent nature of SRPM files in -source repositories affects at least those tools and Fedora services: - dnf builddep (errors when encountering foreign-arch dependencies, even if they are guarded by %ifarch in the .spec file) - dnf repoquery and repoclosure produce wrong results - koschei gets confused by architecture-dependent BuildRequires and claims "failed dependency resolution" for foreign-arch dependencies I file an issue with koji asking for a way to get correct metadata for SRPMs: https://pagure.io/koji/issue/2726 However, I agree that keeping 6 SRPM files with identical *content* and only different *metadata* is incredibly wasteful. But koji is the only place in the build pipeline at which the entire and correct dependency information is available, and it's lost afterwards, because the rebuilt SRPM files produced by mock on each architecture are discarded. I don't know if there could be a way to expose an "srpmdiff" between the SRPM files on different architectures ... But I'd argue that it's definitely not good that there's currently *no way* to query BuildRequires *correctly* and *reproducibly* (other than possibly rebuilding all fedora SRPM files for each target architecture, but I do not have the resources - nor the desire - to do that, just to get correct dependency information). For the repository data that's processed by repochecker (for the packager-dashboard data), I needed to add hard-coded overrides for those "false positives", which is definitely not scalable for the hundreds of different architecture-dependent BuildRequires that exist in Fedora, but I also don't have a way to find them other than "look at the .spec file": https://pagure.io/ironthree/repochecker/blob/master/f/overrides.json So, if anybody has an idea how we can solve this issue and actually provide correct repository data, that would be great :( Fabio

5 9

Logs from Open NeuroFedora Meeting: 1300 UTC on Monday, 1st March
by Aniket Pradhan 01 Mar '21

01 Mar '21

Hi everyone, Please find the logs from today's meeting below. We will meet again in 2 weeks. Minutes: https://meetbot.fedoraproject.org/fedora-neuro/2021-03-01/neurofedora.2021-… Log: https://meetbot.fedoraproject.org/fedora-neuro/2021-03-01/neurofedora.2021-… Minutes in text format: ===================================== #fedora-neuro: NeuroFedora 2021-03-01 ===================================== Meeting started by MeWjOr at 13:00:55 UTC. The full logs are available at https://meetbot.fedoraproject.org/fedora-neuro/2021-03-01/neurofedora.2021-… . Meeting summary --------------- * Agenda (MeWjOr, 13:03:41) * New introductions and roll call. (MeWjOr, 13:03:48) * Tasks from last week's meeting. (MeWjOr, 13:03:57) * Open Pagure tickets. (MeWjOr, 13:04:02) * Open bugs check. (MeWjOr, 13:04:06) * Open package reviews check. (MeWjOr, 13:04:13) * Koschei packages check. (MeWjOr, 13:04:18) * CompNeuro lab compose status check (MeWjOr, 13:04:23) * Neuroscience query of the week (MeWjOr, 13:04:28) * Next meeting day, and chair. (MeWjOr, 13:04:36) * Open Floor (MeWjOr, 13:04:41) * New introductions and roll call (MeWjOr, 13:05:11) * major/MeWjOr, Aniket Pradhan, (+5:30), random python stuff, packaging... (MeWjOr, 13:06:13) * omnidapps,Josh Santos, (+7:00), update python-matplotlib-scalebar (omnidapps, 13:07:24) * iztokf, Iztok Fister Jr., (+1:00), packaging (iztokf[m], 13:08:48) * Tasks from last meeting (MeWjOr, 13:09:28) * Tasks from the last meeting: https://meetbot.fedoraproject.org/fedora-neuro/2021-02-15/neurofedora.2021-… (MeWjOr, 13:09:44) * omnidapps MeWjOr : look into Venus to ascertain how much work migration from Pluto would be -- work in progress (MeWjOr, 13:11:01) * FranciscoD assign https://bugzilla.redhat.com/show_bug.cgi?id=1922612 to omnidapps -- Done (MeWjOr, 13:12:00) * omnidapps work on updating matplotlib-scalebar -- WIP (MeWjOr, 13:12:23) * FranciscoD ping https://bugzilla.redhat.com/show_bug.cgi?id=1809405 for updates (MeWjOr, 13:15:51) * MeWjOr complete https://bugzilla.redhat.com/show_bug.cgi?id=1821189 : snakemake -- WIP, more deps (MeWjOr, 13:17:24) * LINK: https://pagure.io/fedora-infrastructure/issue/9664 (FranciscoD, 13:18:13) * FranciscoD file a bug with infra about neuro-sig packages not marked in Koschei -- WIP: mizdebsk is looking into it (MeWjOr, 13:18:45) * LINK: https://pagure.io/fedora-kickstarts/pull-request/759 (FranciscoD, 13:19:30) * FranciscoD add python3-pynn to f34+ kickstarts -- Done, https://pagure.io/fedora-kickstarts/pull-request/759 (MeWjOr, 13:20:02) * ACTION: FranciscoD : Package bluepyopt: https://bugzilla.redhat.com/show_bug.cgi?id=1849706 (MeWjOr, 13:22:10) * ACTION: MeWjOr Fix deps for snakemake and proceed with the review. (MeWjOr, 13:22:35) * Open Pagure tickets. (MeWjOr, 13:22:55) * Tickets marked for discussion: https://pagure.io/neuro-sig/NeuroFedora/issues?status=Open&tags=S%3A+Next+m… (MeWjOr, 13:23:03) * NeuroFedora at INCF Neuroinformatics Assembly: https://pagure.io/neuro-sig/NeuroFedora/issue/427 (MeWjOr, 13:23:51) * Use Pluto instead of Venus: https://pagure.io/neuro-sig/NeuroFedora/issue/421 (MeWjOr, 13:25:02) * ACTION: omnidapps work on how to get started with Pluto (MeWjOr, 13:31:41) * ACTION: MeWjOr work on templates to transfer on Pluto (MeWjOr, 13:32:27) * LINK: https://src.fedoraproject.org/rpms/pluto (omnidapps, 13:32:59) * Open bugs check. (MeWjOr, 13:35:02) * NeuroFedora bugs: https://tinyurl.com/neurofedora-bugs (MeWjOr, 13:35:12) * Open package reviews check. (MeWjOr, 13:38:43) * Koschei packages check. (MeWjOr, 13:42:18) * Neuro-sig packages on Koschei: https://koschei.fedoraproject.org/groups/neuro-sig (MeWjOr, 13:42:35) * CompNeuro lab compose status check (MeWjOr, 13:44:02) * The comp neuro lab image task on Koji: https://koji.fedoraproject.org/koji/packageinfo?packageID=30691 (MeWjOr, 13:44:23) * LINK: https://pagure.io/releng/failed-composes/issue/2291 (FranciscoD, 13:45:30) * F34 comp neuro image is building correctly (MeWjOr, 13:47:00) * rawhide comp neuro image failed. Look into it if it continues to fail (MeWjOr, 13:47:53) * LINK: https://www.irccloud.com/pastebin/8cFKjSZg/ (omnidapps, 13:48:51) * rawhide comp neuro image failed. dependency issue. (MeWjOr, 13:48:52) * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=1933615 (FranciscoD, 13:49:54) * Neuroscience query of the week (MeWjOr, 13:51:20) * If you find anything interesting, add it to this ticket here: https://pagure.io/neuro-sig/NeuroFedora/issue/318 (MeWjOr, 13:52:55) * LINK: https://www.incf.org/blog/new-publication-neuroinformatics-members-incf-com… (MeWjOr, 13:54:52) * Next meeting: time/day/chair (MeWjOr, 13:58:55) * ACTION: omnidapps/nerdsville chair the next meeting on 2021/01/15 (MeWjOr, 14:01:34) * ACTION: MeWjOr send out the meeting logs (MeWjOr, 14:01:51) * open-floor (MeWjOr, 14:01:58) Meeting ended at 14:02:48 UTC. Action Items ------------ * FranciscoD : Package bluepyopt: https://bugzilla.redhat.com/show_bug.cgi?id=1849706 * MeWjOr Fix deps for snakemake and proceed with the review. * omnidapps work on how to get started with Pluto * MeWjOr work on templates to transfer on Pluto * omnidapps/nerdsville chair the next meeting on 2021/01/15 * MeWjOr send out the meeting logs Action Items, by person ----------------------- * FranciscoD * FranciscoD : Package bluepyopt: https://bugzilla.redhat.com/show_bug.cgi?id=1849706 * MeWjOr * MeWjOr Fix deps for snakemake and proceed with the review. * MeWjOr work on templates to transfer on Pluto * MeWjOr send out the meeting logs * omnidapps * omnidapps work on how to get started with Pluto * omnidapps/nerdsville chair the next meeting on 2021/01/15 * **UNASSIGNED** * (none) People Present (lines said) --------------------------- * MeWjOr (138) * FranciscoD (68) * omnidapps (46) * zodbot (18) * tg-fedneuro (7) * iztokf[m] (5) * lbazan (4) * fm-stg-neuro_ (3) * fm-neuro (3) * bt0 (0) * rachitt_shah[m] (0) * alciregi (0) * gicmo (0) * achilleas (0) * zbyszek (0) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot -- Thanks Regards Aniket Pradhan http://home.iiitd.edu.in/~aniket17133/ Aliases: MeWjOr/major () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments

1 0

shigofumi-0.9 license change
by Petr Pisar 01 Mar '21

01 Mar '21

shigofumi-0.9 changed license from "GPLv3+ and GPLv2+" to "GPLv3+ and LGPLv2+" because of a bundled gettext.h. -- Petr

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

devel March 2021