Release criteria proposal: drop kickstart package criterion
by Adam Williamson
Hi, folks!
We currently have a Final release criterion that reads as follows:
"A spin-kickstarts package which contains the exact kickstart files
used to build the release must be present in the release repository.
The included kickstarts must define the correct set of release
repositories.
Why?
This is considered part of Fedora's duty to be 'self-hosting': the
kickstarts used to produce the release images are a vital piece of
information required to duplicate that release, so they must be
preserved along with the release."
Lately this requirement has been fairly annoying in practice. Updating
the package prior to release does not appear to be in anyone's regular
schedule, so invariably what happens is shortly before the release
deadline I realize we haven't built a 'release' spin-kickstarts package
and have to file a blocker bug and ping people with the necessary
permissions (of which there are only a few) to build one in a tearing
hurry. Then we have to approve the blocker bug and push the updated
package through the freeze, all wasting time we could be spending on
more important fixes.
The benefit here is really fairly tiny, as well. It's arguable whether
anyone cares particularly whether a Fedora release, as a frozen
artifact, is 100% internally reproducible (and I'm not sure whether our
releases actually *are* reproducible in any case, these days, I'm not
at all sure we ship all the necessary metadata and so on for *every
single deliverable* within the distribution).
These days I'd suggest it should be quite acceptable to simply use git
tags for this purpose. It should be quite easy for rel-eng to adjust
the release scripts to create a tag in the fedora-kickstarts repo (and
why not fedora-comps too, while we're at it) for each 'candidate'
compose, named for the compose ID. That would make it very easy to
access the correct kickstarts for any Fedora candidate compose just by
a 'git checkout', with no need for the cumbersome work of getting the
package into the compose.
Naturally this would go along with updates to any relevant docs or wiki
pages, recommending to use the git repository instead of the RPM
packages, and explaining the tagging scheme. As for the package, we
could either keep it but not sweat about updating it for each release,
retire it entirely, or change it to contain only a text file pointing
to the git repository (or to the doc / wiki page that explains the git
repo location and tagging strategy).
Thoughts? Thanks!
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
5 years, 10 months
Re: Heads up: Python 3.7 rebuild in progress
by Patrick Monnerat
On 06/25/2018 09:11 PM, Miro Hrončok wrote:
> I'm now mass rebuilding everything. Will do a couple of rounds before
> I will look at the logs. If you see you package failing for a
> non-dependencies related reason, please try to fix it and rebuild it
> with:
>> fedpkg build --target=f29-python
>>
> The list of packages that FTBFS for non dependency reasons:
>
> insight lkundrak monnerat
Done, OK: https://koji.fedoraproject.org/koji/taskinfo?taskID=27895889
Thanks for heads-up.
5 years, 10 months
[copr] follow Fedora branching by default?
by Pavel Raiskup
Hi, there was an idea to turn on the "Follow Fedora branching" feature in Copr
by default (for newly created copr projects). That feature automatically
creates new fedora-NN-* chroots from fedora-rawhide-* chroots (at Fedora
branching time), and "forks" the related builds (so the packages don't have to
be re-built manually).
If you are concerned about this topic, consider looking at/voting in
https://pagure.io/copr/copr/issue/332 .
Pavel
5 years, 10 months
Prioritizing ~/.local/bin over /usr/bin on the PATH
by Tomas Orsava
Hi!
I'd like to propose putting the ~/.local/bin in front of the /usr/bin on
the PATH.
Currently /usr/bin has priority over ~/.local/bin, which causes a [bug]
where the old system-installed executable written in Python (from
/usr/bin) is launched, but it finds new Python sources (installed into
$HOME) which it doesn't work with and crashes.
[bug] https://bugzilla.redhat.com/show_bug.cgi?id=1571650
I believe the current configuration breaks the intuitive expectation
that things installed closer to the user should take priority. That's
for example how it works with Python.
Interestingly, ubuntu and opensuse do not have ~/.local/bin on their
PATH (though Ubuntu has ~/bin) so we can't take guidance there.
Does anyone see a reason not to prioritize ~/.local/bin over /usr/bin?
Regards,
Tomas
5 years, 10 months
Unannounced soname bump: toxcore
by Robert-André Mauchin
Hello,
I accidentally soname bumped toxcore from libtoxcore.so.2.2.0 to
libtoxcore.so.2.3.0. It was a minor patch release and I didn't anticipate the
soname change.
Affected package are utox and qtox (rpmfusion). They will be rebuilt shortly.
I don't expect anyone to be affected by it, since I'm the only maintainer of
the affected packages, but if you are please contact me.
Best regards,
Robert-André
5 years, 10 months