Policy proposal (draft): Don't push knowingly broken or
work-in-progress work to dist git
by Miro Hrončok
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
3 years, 1 month
Self Introduction: Phil
by Phil Dibowitz
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
3 years, 1 month
Dilemma: -source repository data randomized by koji builder arch
by Fabio Valentini
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
3 years, 1 month
Logs from Open NeuroFedora Meeting: 1300 UTC on Monday, 1st March
by Aniket Pradhan
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.202...
Log: https://meetbot.fedoraproject.org/fedora-neuro/2021-03-01/neurofedora.202...
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.202...
.
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.202...
(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...
(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-c...
(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
3 years, 1 month
shigofumi-0.9 license change
by Petr Pisar
shigofumi-0.9 changed license from "GPLv3+ and GPLv2+" to
"GPLv3+ and LGPLv2+" because of a bundled gettext.h.
-- Petr
3 years, 1 month
Non-responsive maintainer: sabbaka
by Pierre-Yves Chibon
Good Morning Everyone,
Since February 7th the packager sabbaka has been receiving a daily email asking
them to either adjust their bugzilla or their FAS account so the email address
in FAS matches an existing bugzilla account.
Having a bugzilla account is mandatory per:
https://fedoraproject.org/wiki/Join_the_package_collection_maintainers#Cr...
sabbaka is maintainer of rpms/tlog
Does anyone know how to contact sabbaka?
Thanks,
Pierre
PS: the users dkaspar, kir and leogallego having been receiving the same email
since February 24th. Their attention to that email would be appreciated.
3 years, 1 month
