epel8: BuildrootError: could not init mock buildroot
by Jiri Kucera
Hello,
when doing `fedpkg scratch-build --target epel8-candidate --srpm sox-14.4.2.0-29.el8.src.rpm`, I get:
<snip>
[====================================] 100% 00:00:01 1.02 MiB 773.06 KiB/sec
Building sox-14.4.2.0-29.el8.src.rpm for epel8-candidate
Created task: 41245726
Task info: https://koji.fedoraproject.org/koji/taskinfo?taskID=41245726
Watching tasks (this may be safely interrupted)...
41245726 build (epel8-candidate, sox-14.4.2.0-29.el8.src.rpm): free
41245726 build (epel8-candidate, sox-14.4.2.0-29.el8.src.rpm): free -> FAILED: BuildrootError: could not init mock buildroot, mock exited with status 30; see root.log for more information
0 free 0 open 0 done 1 failed
41245727 rebuildSRPM (noarch): FAILED: BuildrootError: could not init mock buildroot, mock exited with status 30; see root.log for more information
41245726 build (epel8-candidate, sox-14.4.2.0-29.el8.src.rpm) failed
</snip>
When I investigating the logs (both `root.log` and `mock_output.log`), I found that `dnf` has problem with package downloading:
<snip>
Downloading Packages:
Error: Error downloading packages:
Status code: 404 for https://infrastructure.fedoraproject.org/repo/rhel/rhel8/koji/latest/x86_... (IP: 10.5.126.23)
</snip>
I get the same result also with `--target epel8`.
Any ideas how to resolve this issue?
Regards
Jiri
2 years, 3 months
[Retired] gstreamer & gstreamer-plugins-base
by Tom Callaway
Since I've moved my last dependent package off of this old stack, I've
retired gstreamer & gstreamer-plugins-base in rawhide (again).
Before reviving these poor and tired packages, please consider the
following:
* Upstream is not maintaining this code branch anymore.
* There are significant improvements in the gstreamer0.10 branch (which is
separately packaged and maintained in Fedora)
Thanks,
Tom
2 years, 3 months
fedora-gpg-keys not updated yet again
by Zbigniew Jędrzejewski-Szmek
This seems to repeat every 6 months: rawhide mock is broken on stable
Fedora, people are scrambling to install the right gpg keys, dnf reports
unsigned packages.
Looking at https://bodhi.fedoraproject.org/updates/?packages=fedora-repos,
there is still no F30 package with the right keys.
Can we *please* send out the FN+1 and FN+2 keys a month before branching,
to *all* releases of Fedora, so we can avoid this pointless scramble?
Zbyszek
2 years, 3 months
RFC: Security policy adjustments to make it easier to implement and
more friendly to maintainers
by Miro Hrončok
Hello, Fedora has an approved security policy since September 2018 [0]:
> If a CRITICAL or IMPORTANT security issue is currently open
> against a package, or a security issue of lower severity has been
> open for at least 6 months, four weeks before the branch point a
> procedure similar to long-standing FTBFS will be triggered
> immediately, with 8 weeks of weekly notifications to maintainers and
> subsequent orphaning and then subsequent removal from distribution.
> This applies to all packages, not just leaf.
I have decided to have a look into this, since this has been approved more than
a year ago and nothing ever happened since. Fedora has a very big pile of open
CVE bugzillas [2].
There are several things I'd like us to consider based on the experience from
the FTBFS policy adjustments [1] before I go implement stuff:
A. It's easier to **orphan** packages soon, retire later -- this allows the
dependent package owners to notice the breakage and possibly adopt the packages
themselves if needed while gives very little room for "cheating".
B. Getting this done on a certain point in the release schedule is complicated
and requires a lot of planning and focus -- if we miss the window, nothing can
change until the next release. We have missed the window 3 times already.
C. Also because of the fixed date, the CRITICAL or IMPORTANT security issues
have no response time, if you get a new one at a certain point, the package is
immediately treated as problematic, while getting it 1 day later, there is a 6
month period where no action is required.
I'd like to adjust the policy before I go implement some tooling around this.
This is vague proposal of what I think would work easier for both "the
executioner" and the affected maintainers:
1. We automatically send reminders to NEW security bugzillas (as with FTBFS)
2. BZs that remain in NEW state for X reminders: pkg is orphaned
3. BZs that remain not CLOSED for Y months: pkg is retired (with notifications)
Point 2 makes it so that only a couple remaining packages actually need to
survive unfixed to point 3. Hence, point 3 can happen at a certain point in the
schedule with less severe impact of points B and C -- and if we miss the window,
we still have point 1 happening.
The bugzilla reminders are sent every third calendar week (every week is too
disturbing).
Here is an initial (albeit randomly generated) proposal of X and Y:
severity CRITICAL/HIGH MEDIUM LOW
X 2 4 6
Y 2 4 6
Note that X=1 effectively means anything from 1 second to 3 weeks, X=2 means
anything from 3 weeks (+1 second) to 6 weeks. Hence, we cannot orphan packages
after just 1 reminder.
I've made it so that X always equals to Y and every lower level is +2, to make
it easier to document, understand and remember, however this is not required.
For this example a critical/high CVE would get a reminder every third calendar
week. After two reminders (that is after 3-6 weeks), if still in NEW state,
package is orphaned. The maintainer (and others) still have extra 6 weeks to
claim it.
If the bug is ASSIGNED, MODIFIED, etc., the package may be retired after 2
months, but that only happens regularly at a certain point in the schedule.
Similarly, a package with a medium CVE NEW bugzilla would be orphaned after 4
reminders (after 9-12 weeks), retired at a point if still not CLOSED after 4 months.
With low severity, that is 6 reminders (after 15-18 weeks), retired at a point
if still not CLOSED after 6 months (similarly to the current policy).
Please share your feedback, before I proceed with this to FESCo.
If somebody would be interested in maintaining this procedure, I'd be happy to
hand over that responsibility to anybody who is willing to help.
The idea is to start with semi-automation and have something -- currently we had
hoped for fully automated and we have nothing.
[0] https://pagure.io/fesco/issue/1935
[1] https://pagure.io/fesco/issue/2244
[2] https://mivehind.net/2020/01/28/Fedora-has-too-many-security-bugs/
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
2 years, 3 months
Co-Maintainers wanted for Pantheon / elementary apps (Vala / GObject
/ GTK+)
by Fabio Valentini
Hi everybody,
With more responsibilities (FPC, Stewardship SIG, FESCo) and the
ever-growing number of packages I maintain, I don't have as much time
for the things I originally started my contributions to fedora with -
the Pantheon desktop and the accompanying elementary applications.
What makes things worse is that I am not particularly proficient with
Vala or C/GObject, other than including upstream patches or doing
simple backports. That means some issues are punted until upstream
projects get around to fixing them (and if these issues are only
affecting "third-party" distros like fedora, that can take a while).
Also, the fact that GNOME frequently (almost with every new major
stable release, which means with almost every fedora release) breaks
something - either subtly or not - does not help.
gnome-settings-daemon changes its DBus interfaces almost every
release. mutter makes sweeping API changes almost every release. Both
gala and the elementary LightDM greeter can't keep up with upstream
mutter, and are basically still stuck on mutter 3.28 support (which is
why there is a mutter328 compat package) ...
Overall, this results in the quality of all these packages not being
as high as I would like it to be (though it's still pretty good, all
things considered). In particular, there are some components that are
more "crashy" than the rest, and I don't have the time and skill to
get deep into debugging the issue in most cases:
- wingpanel (the panel for Pantheon); issues in individual indicators
also crash the whole app because they are just dlopen()ed
- switchboard (the settings application); issues in individual
settings panels also crash the whole app because they are just
dlopen()ed
- gala (the window manager): obviously bad if the WM crashes, though
not as bad because it's still an Xorg session
- plank (the dock); also optionally used on XFCE (I think)
- sequeler (third-party SQL client developed for Pantheon)
I would greatly appreciate if somebody who knows their GObject-fu
could help me out here.
The elementaryOS upstream developers are usually helpful and accept
patches - even for things that are not a problem on elementaryOS, so
long as they can be switched on/off with e.g. conditional compilation.
But reported issues - that only affect fedora - without attached
patches / PRs are obviously low priority for them, and often sit
untouched for months or years.
In general, I manage to keep the packages for Pantheon / elementary
projects up-to-date. Having set up "nightly" builds on COPR a few
years ago really helps to catch potential issues early.
If anybody is interested, here are some pointers:
- all packages are tracked in koschei, in the decathorpe/elementary group:
https://koschei.fedoraproject.org/groups/decathorpe/elementary
- nightly builds are done on COPR:
https://copr.fedorainfracloud.org/coprs/decathorpe/elementary-nightly/
Thanks,
Fabio
2 years, 3 months
Announcing multi-builds updates gating
by Pierre-Yves Chibon
Good Morning Everyone,
We are pleased to announce that the work to gate rawhide packages has leveled
up!
Back in July we announced the first phase where bodhi got the support to gate
single-build updates. We can now officially announce that bodhi can gate
multi-builds updates. This is achieved through the use of side-tags, which can
be created on demand via ``fedpkg request-side-tag``. The package can then be
built using ``fedpkg build --target=<your side-tag>`` or via ``fepdkg
chain-build --target=<your side-tag>``. Once all your packages are built, you
can create a bodhi update from this side-tag using either the ``Use Side-Tag``
drop-down or in the CLI by using the ``--from-tag`` argument to the ``bodhi
updates new`` command.
Every build in the update will then be tested by the CI system which will report
the outcome. Bodhi will then query greenwave which will rely on the collection
of these individual results to make a decision about whether to gate the update
or not.
More detailed documentation is available at:
- https://fedoraproject.org/wiki/Package_update_HOWTO
- https://docs.fedoraproject.org/en-US/rawhide-gating/
Note: this is not the end of rawhide-gating. We still have some changes planned
to make it easier for greenwave to make a decision about an update containing
multiple builds, we want to improve the documentation for on-boarding new CI
systems and make them matter for rawhide as well as for stable releases.
We then have all the work ahead to improving our tests, including enabling some
of them distribution-wide, looking at the reverse dependencies or testing for
the impact of an update on our composes.
Looking forward for your feedback!
Pierre
For the rawhide gating team
_______________________________________________
devel-announce mailing list -- devel-announce(a)lists.fedoraproject.org
To unsubscribe send an email to devel-announce-leave(a)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-announce@lists.fedora...
2 years, 3 months
Please, IMHO, resolve in some way the Samba MIT kerberos problem.
by Dario Lesca
Too many people (like also me) try to use samba-dc on fedora for deploy
a production AD DC controller, without know that MIT kerberos is
experimental and some useful things cannot work (es. win to win
access).
An recent last example:
https://lists.samba.org/archive/samba/2019-November/226845.html
> On 01/11/2019 22:23, Vex Mage wrote:
> > The script is expecting dpkg however this is a Red Hat
> > derived distro (Fedora Server.)
>
> Where did you get the Samba packages from ?
>
> If they are the default OS packages, then you should stop using
> them, they use MIT kerberos and are experimental.
There is many approach for resolve this issue:
a) Stop use MIT kerberos and rebuild samba with Heimdal Kerberos.
b) Produce a samba alternative package version (like, for example,
firefox-x11) build it with Heimdal Kerberos (es samba-hk-*)
c) Stop enable DC on Fedora, like RH/Centos do.
d) Notify users at the end of the installation that Fedora Samba DC is
experimental.
e) Solve the problems that make MIT kerberos experimental and put us in
a position to ask for help on the samba team.
f) ... some other proposal ?
What is the best approach chosen by Fedora ?
Many thanks
--
Dario Lesca
(inviato dal mio Linux Fedora 31 Workstation)
2 years, 3 months
Copr Build System - review of 2019 and vote for features in 2020
by Miroslav Suchý
I want to sum up what happened in Copr during 2019. At the end of this email, you can see our TODO list and cast your
vote on what we should focus on.
During the year 2019:
* we added native AARCH64 builders
* we added emulated ARMhfp builders
* released eight new versions of Mock including features as Jinja templates in configs, Dynamic BuildRequires,
subscription-manager support, which enables us to build on top of RHEL, Fedora Toolbox support, and container image
support which allows building using incompatible RPM.
https://github.com/rpm-software-management/mock/wiki#release-notes
To give credit - some of these Mock's features were contributed by community members.
* We removed outdated chroots, which allowed us to reclaim terabytes of disk space. At the same time, we give you the
option to keep those old repos if you want them.
http://frostyx.cz/posts/copr-removing-outdated-chroots
* we provided RSS feed
https://fedora-copr.github.io/posts/Copr-new-rss-feed
* we added project discussions by integration with https://discussion.fedoraproject.org
* your project can be marked as temporary, and we delete it automatically after a specified amount of days. This is
great for CI projects.
* we migrated from fedmsg to fedora-messaging
https://pavel.raiskup.cz/blog/copr-messsaging.html
* we provide anonymized DB dump so that you can play with our data
https://copr.fedorainfracloud.org/db_dumps/
* you can pin your favorite projects now
http://frostyx.cz/posts/create-your-portfolio-with-pinned-projects
* thanks to Amazon, we can use AWS for builders for free, which allowed us to use more builders.
* user Iucan rebuilds all R packages from CRAN for Fedora
https://copr.fedorainfracloud.org/coprs/iucar/cran/
* we are contributing to speed up createrepo_c, because that one is our biggest bottleneck. For projects like Cran or
python rebuilds, the createrepo task runs longer than the build of package and cannot be parallelized.
* Many interesting projects appeared in Copr and we wrote about them
https://fedoramagazine.org/?s=cool+new+projects+to+try+in+COPR
* Added per-package config option to blacklist the package from building against particular chroots
* Added support for multilib projects https://pagure.io/copr/copr/issue/1181
* Refined modularity support, module dependency, module_hotfixes flags, ...
* Copr permissions can now be set via API and CLI.
* Removing old builds automatically, per option that only keeps a maximum number of builds per given package.
What are our plans for 2020? We have some mandatory tasks:
* migrate to new datacenter together with the whole fedora-infrastructure
* install and use new and bigger storage
Yet we have quite a long list of RFEs and tasks to do. As **you** are our customers, I would like to hear your opinion
on what is crucial for you.
Please cast your vote here:
https://forms.gle/GXWaZ1yzmkPJmeQw9
Options:
* allow more parallel builds - everyone wants faster builds. I am afraid we cannot speed up the build itself, but we
can focus on allowing us to run more builds in parallel to handle peaks.
* Mock development - we spend a lot of time on Mock development. We utilize those new features in Copr, but they are
useful even for your local workflow with Mock. Should we spend more time on longstanding RFEs?
* build Flatpak application from your project - we have a viable idea how to build Flatpak app from your project with
just a few clicks, and we can upload the result to some registry. E.g., to https://quay.io/
* new commands for our API and copr-cli
* run lints like rpmlint or rpm-inspect after each build and give you hints on how to improve your spec files
* automatically rebuild PyPI and Rubygems - we already did this in the past, but we did not rebuild it for new Fedoras
* allow you to vote for quality of the project with thumbs up/down and high quality repos automatically promote and
will enable them as one big repo of "editors pick".
* focus on rpm spec generators - See https://docs.pagure.org/copr.copr/user_documentation.html#scm what we support
right now.
* add emulated architecture s390x - while we would like to add native architecture, it will likely not happen next
year, but we can do builds using QEMU.
* add RHEL as a target - right now you can build on top of CentOS, but we can allow you to build on top of RHEL
* better automatic builds triggered by GitHub, Gitlab, aka mimic the Copr CI we have for Pagure - git server sends
request - copr replies back with build status
* runtime dependency config between copr projects, so `dnf copr enable <user/foo>` enables other projects transitively
* something else - is something blocking you from using Copr? Please share it with us.
Please cast your vote here:
https://forms.gle/GXWaZ1yzmkPJmeQw9
--
Miroslav Suchy, RHCA
Red Hat, Associate Manager ABRT/Copr, #brno, #fedora-buildsys
2 years, 3 months
Self Introduction: Erich Eickmeyer
by Erich Eickmeyer
Hello all!
I'm Erich, the current project leader of Ubuntu Studio, the creativity-oriented flavor of Ubuntu. I've been leading that project for the past two years.
In that time, my team and I have taken Ubuntu Studio strides from where it was. However, due to some circumstances I will not mention here, we are looking for an alternative, and Fedora, with the Fedora Jam lab and with CCRMA's attention, seemed to be the perfect place to land. That said, it seems as though the Jam lab is dead, so I am here to revive it with mattdm's blessing.
We revamped a tool called Ubuntu Studio Controls (https://help.ubuntu.com/community/UbuntuStudio/UbuntuStudioControls), which makes audio configuration for Jack super simple. We wish to port that tool to Fedora, so I, with the help of another, will be working on packaging that, possibly naming it Studio Controls or Jam Controls.
I bring with me a team of people, including the primary developer of Ubuntu Studio Controls. We intend to make Jam a great project for musicians and audio engineers alike. I've been doing audio engineering for nearly 26 years, so this is an area that's completely within my wheelhouse.
In order to do the Self-Contained Change Request required, I need to be CLA+1, so that's the motivation behind joining the packaging group or whatever other group anyone feels is relevant to this project.
Thanks for reading!
Erich Eickmeyer
2 years, 3 months
