Should we have a release manager for each release? (or, "who owns
rawhide"?)
by Matthew Miller
As shown at https://www.happyassassin.net/nightlies.html, we haven't
had a successful compose for almost two weeks. AIUI this is mostly
worked out now, but it raises the question: who should be keeping track
of this and coordinating fixes? For the releases, the blocker bug
process basically handles this, so functionally the ownership ends up
with QA (and the various heroes of QA who then track down all the
problems). For rawhide, we don't have any such thing. Is it rel-eng? Is
it FESCo? Is it the FPgM? Is it QA after all?
I suspect that right now, the answer is kind of "It's all of us
together", which unfortunately practically speaking often comes down to
0.02% per person and rounds down to 0.
Or if the answer is: "Matthew, you are the FPL. It's you!" … then fine,
but I'm going to then have to find some way to turn around and
delegate. :)
I was chatting with Kevin Fenzi and he suggested naming a release
manager for each release — someone who would keep track of stuff
starting at branch, and help coordinate things like this.
This would help with more than just Rawhide — I'm sure everyone
involved in the blocker bug process would be grateful for more help. At
least, if it was someone who isn't already deeply involved in that. I'm
thinking probably someone selected from FESCo — but it also could be a
way for people with the particular set of skills required here to get
involved in a way that's different from FESCo membership.
What do you think?
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
6 years, 2 months
Test gating enabled in Bodhi
by Pierre-Yves Chibon
Good Morning Fedorans!
On Thursday, a new version of Bodhi was deployed that enabled Bodhi to
gate updates based on test results. You may notice a "Test Gating
Status" message in the right have side of the page.
One thing to know about this is that there is currently a confusing
issue where Bodhi will say that the tests have failed when the tests
haven't finished running[0]. We are working on solving that issue, but
for now you can just wait a while and it should report the result once
all the tests have finished.
There are three tests that must pass in order for updates to go to stable:
0. dist.depcheck - to make sure the update's dependencies are available.
1. dist.abicheck - to make sure the update's ABI remains stable in a
given Fedora release.
2. AtomicCI pipeline - packages that are part of the Atomic Host *and* include
in their dist-git tests, must have these tests passed in the AtomicCI pipeline
This last requirement only concern packages that are in the Atomic Host while
the first two is enforced for all packages.
We are also working on another CI pipeline that will allow running tests stored
in dist-git for all packages without discrimination.
You are in control of these three tests. The first two can be fixed by
making changes in the spec file, and the latter test is controlled via
the tests in your repo.
Finally, if it turns out you need to push an update through despite of the test
results, you can do so using waiver-cli (dnf install waiverdb-cli). We are
working on integrating this into Bodhi itself, making this easier.
We have started a wiki page to store all of this information and that we will
keep up to date as improvements are done or for any frequent questions coming up:
https://fedoraproject.org/wiki/CI/gating_updates
Please accept my apology in the delay in writing this message. It should
have been sent last week when it was enabled, and it got lost.
Thanks for your attention,
Pierre
[0] https://github.com/fedora-infra/bodhi/issues/2124
_______________________________________________
devel-announce mailing list -- devel-announce(a)lists.fedoraproject.org
To unsubscribe send an email to devel-announce-leave(a)lists.fedoraproject.org
6 years, 2 months
News in net-snmp package
by Josef Ridky
Hi folks,
I would like to inform you, that net-snmp package will use Python3 package instead of Python2.
With this change, python2-net-snmp package will be renamed to python3-net-snmp package.
This change will be applied in Fedora Rawhide and Fedora 28.
I would be glad for any feedback.
Regards
Josef Ridky
Associate Software Engineer
Core Services Team
Red Hat Czech, s.r.o.
6 years, 2 months
Exclude paths for elfdeps dependency generator
by Till Hofmann
Hi all,
I have a question regarding the the RPM dependency generator scripts.
I'm working on packaging the ROS stack [1,2] and I'm currently dealing
with the dependency generation. My goal is to wrap all Provides and
Requires for sonames because ROS does not use proper sonames (and
therefore they shouldn't be in the ld cache), but I still want to use
the information for ROS packages. This means I want to replace:
Provides: librosconsole.so()(64bit)
=>
Provides: ros(librosconsole.so()(64bit))
[or possibly ros-kinetic(librosconsole.so()(64bit))]
and similarly for Requires.
I have a working solution [3] that wraps all ROS Provides and Requires
and generates other Provides and Requirest just as elfdeps does, but it
uses an (imho ugly) hack: As I don't want to have the normal Provides
generated by elfdeps, I have:
%__ros_path ^/usr/lib.*/ros/.*$
%__elf_exclude_path %__ros_path
in /usr/lib/rpm/fileattrs/ros.attr. I see two problems: If
%__elf_exclude_path is set by something else, it is overridden, because
I couldn't figure out how to append to the exclude path. Second,
%__elf_exclude_path should not be set at all in ros.attr, the doc [4] says:
"NAME needs to be replaced by the name choosen for the file attribute
and needs to be the same as the file name of the macro file itself"
It still works, but shouldn't according to the documentation.
So my question: Is there any other way to exclude the ROS dir to be
checked by elfdeps? I cannot just use %__requires_exclude_from because I
want my dependency generator to run on the directory.
Thanks for any hints.
Kind regards,
Till
[1] https://pagure.io/ros
[2] https://copr.fedorainfracloud.org/coprs/thofmann/ros/
[3] https://pagure.io/ros-rpm-macros
[4] http://rpm.org/user_doc/dependency_generators.html
6 years, 2 months
march VFAD for the atomic working group
by Dusty Mabe
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
https://pagure.io/atomic-wg/issue/429
In the Atomic working group in Fedora we have occasionally used virtual
Fedora Activity Days (VFADs) to get the community together to discuss
in a high bandwidth setting (video conference) some techical issues we're
having or some direction of where we're going.
We have scheduled a VFAD for next Friday (march 9th). We'd like to get
some input on some topics to discuss during this VFAD. Please discuss
and add topics to the ticket.
It would be preferable if we keep discussion in one place so please add
responses to the ticket.
Thanks!
Atomic Working Group
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCAAdFiEEPb6zG5c6sV89tRYPMwLb1zlS5nEFAlqW4BkACgkQMwLb1zlS
5nFk+g/+MInPWyUZcBt1ZmBHgPxkyaaE3vDkNIB2upt4nzABVmiOQIFvijnPie37
pN6jRhTChCSFxgDD2NIklNvoJN9CEwSWogD/IFHsr3Ty2p2+5RDHDHaGQVNsEn0a
nD9Ye6E05C0A/iQ3QFbTS+Fin4go+P5Z/ZekCrnaC+6VE12MNf6L1v3y3hXplepo
HuYVf9nfrQr+pw4m/4E1zcWDbxWkDVWv3l76HsVMMzCevgWoj/I6/GGzl0oIgnfy
oMmw9wgpWst72EKMP5bTEpLl1VfG6UU0MVquv4sWpoP3eM7zSjXbwZ1DFuf3gWHS
R4yjWN9vk+haRbyDnfLDZ6/a1hvqXd91rGA9XSNaMVSpSx2ePjBPAj9zO/i4b9ZI
0/04NM3A4ru0jxzDljZmHSolkPh3qmNK9TYFF1Vl3c0ukOAjE1g3JoGHeHCbpyp9
uks1ImatgkhWduV3OyrtpblmxUfZLbn2GxkGKZIavK7z9sN8mStI6Ids4WYMO2PC
Z8k5TYge9lQpUOUQYOSQEEiCxtzuwEJGAzWI7JMW6hECO7xd6XFCqPcrYDChgkAr
PIHJH9/puurhLUmP/3MUpx3nK1V6g26mgs5oeYwYdu7SmSz9RvrlhH5lihWO6njM
6J9A0Pwh8pSgmymXnrBtYZAIgFGmH8ZCuRdgkLDTeJ+GD4aiWy4=
=1Vdx
-----END PGP SIGNATURE-----
6 years, 2 months
packmol license change
by Susi Lehtola
Hi,
I've updated packmol to version 18.013. This carries a license change
from GPLv2+ to MIT. No other packages are affected, since packmol is
executable only.
--
Susi Lehtola
Fedora Project Contributor
jussilehtola(a)fedoraproject.org
6 years, 2 months
runroot changing during the course of a rawhide pungi run
by Dusty Mabe
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
If I understand correctly there was a new lorax build [1] that completed
at 01:11 UTC (02/23) that then made it into the runroot of a task [2] that
was part of a pungi compose [3] that started at 14:54 UTC (02/22).
I think this caused problems with the build, but that isn't really
important. The real question is: if our runroot changes during the run then
we could have some tasks (lorax imagebuild etc) that run with some versions
of software and other tasks that run with others. This is probably especially
maddening when trying to debug why one failed when others didn't.
Is my understanding correct?
Dusty
[1] https://koji.fedoraproject.org/koji/buildinfo?buildID=1048851
[2] https://koji.fedoraproject.org/koji/taskinfo?taskID=25243479
[3] https://kojipkgs.fedoraproject.org/compose/rawhide/Fedora-Rawhide-2018022...
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCAAdFiEEPb6zG5c6sV89tRYPMwLb1zlS5nEFAlqPi74ACgkQMwLb1zlS
5nGSwg/9HIHUVvCTZiU/3tNT1zskuJZNUtiuefWFsVQTQfgLulLz+L/Fw8KxtmLO
zVKXKF7Aqs5xHxkAle+VZq6HNmhU6lB6DUpLpxnhXhBw8fBB8TpEbxaHBQtE9mPS
90zrYNTYXB7vMLkM+FnenpELF2XYe80/O6iz34ZUCMqYdavw1G7s8MI6cS36CV0m
ZpOTdYpIRtVFgv4NSy8hFDs91XPXE3hp4jP/ffU0rnA0Aq1tW3r67EyDT26LSRk1
CfKewnLNCXN329PukFAA1xYOjT9JxjZJAswCXsgx+Vr5vjI6AGCq+773Iz2PgX4H
ZPcGWrZDeILtCPARjAqfUx22ldPF38MSfL3v0GHy9NgC683yLaLUqm08Zl7l4Ujh
xg/wPbvvYt/VmwhCY+MQLf1XrYylLvCdVJyI7yrum8QhfWieTzH2OizejyddT6dE
2NEqdNsh1BIrsh/9kw8s7XdE3dZ6UyfxYwwcdMC6XtJT633IlJiXq2HfqtlRLipp
H1rqz+1+Qp7bQAIQqH8sn2FpgW2IBr9csb/vxWq3ZcePeukRe4q/SRFa+xDvg8gF
yuLrBa+Ovkh8KZvVeH34OAyf8AFRCjHCz1YtKThCfELzDWRFwOfzWmbA80+8rKQN
JcapBDyqHJDeL86O/HuTXNE770EtzeglA0YDO+a/G4Of2ngedP4=
=/fUr
-----END PGP SIGNATURE-----
6 years, 2 months
Multilib issue: apitrace-libs.i686 version mismatches
apitrace-libs.x86_64 on F27
by Sandro Mani
Hi
I've received a bug report from a user reporting broken dependencies
when updating apitrace in F27. Upon closer investigation I found out
that on F27
# dnf install --refresh apitrace-libs.i686
will give you apitrace-libs-7.1-7.fc27.i686, whereas
# dnf install --refresh apitrace-libs
will give you apitrace-libs-7.1-9.fc27.x86_64. This means that a user
with currently installed apitrace-7.1-7.x84_64,
apitrace-libs-7.1-7.x86_64 and apitrace-libs-7.1-7.i686 is currently
getting broken dependencies when updating:
# dnf update
[...]
Problem 1: package apitrace-libs-7.1-7.fc27.i686 requires apitrace =
7.1-7.fc27, but none of the providers can be installed
- cannot install both apitrace-7.1-9.fc27.x86_64 and
apitrace-7.1-7.fc27.x86_64
- cannot install both apitrace-7.1-7.fc27.x86_64 and
apitrace-7.1-9.fc27.x86_64
- cannot install the best update candidate for package
apitrace-libs-7.1-7.fc27.i686
- cannot install the best update candidate for package
apitrace-7.1-7.fc27.x86_64
Problem 2: problem with installed package apitrace-libs-7.1-7.fc27.i686
- apitrace-libs-7.1-7.fc27.i686 has inferior architecture
- cannot install both apitrace-libs-7.1-9.fc27.x86_64 and
apitrace-libs-7.1-7.fc27.x86_64
- cannot install both apitrace-libs-7.1-7.fc27.x86_64 and
apitrace-libs-7.1-9.fc27.x86_64
- cannot install the best update candidate for package
apitrace-libs-7.1-7.fc27.x86_64
[...]
Where should I submit a ticket for this?
Thanks
Sandro
6 years, 2 months
