LD_LIBRARY_PATH vs rpath and libtool
by Ingvar Hagelund
Fedora prohibits the use of rpath, ref
https://docs.fedoraproject.org/en-US/packaging-guidelines/#_beware_of_rpath
When compiling varnish with litbool, I ensure this by the usual
sed -i 's|^hardcode_libdir_flag_spec=.*|hardcode_libdir_flag_spec=""|g;
s|^runpath_var=LD_RUN_PATH|runpath_var=DIE_RPATH_DIE|g' libtool
However, during build and check, I need access to a library in the
build. For example, the test suite uses the binary varnishtest to
access libvarnishapi.so.2, which is not visible as the package is not
installed yet.
I have gotten around this by putting in LD_LIBRARY_PATH where I need,
but rpmlint gives me a warning on that.
Are there other possibilities to solve this?
Ingvar
5 years
Add internationalization support to "Command completed." string.
by Peter Pan
The patch is for the vte.sh of "vte-profile" package, I extracted
the vte.sh from the vte-profile RPM package.
Its gettext TEXTDOMAIN is vte-profile, 2 strings is able to translate
and the patch has been tested with no problems.
--- Below is the patch ---
--- vte_original.sh 2019-03-05 05:49:30.000000000 +0800
+++ vte.sh 2019-03-08 21:40:39.535164773 +0800
@@ -1,5 +1,6 @@
# Copyright © 2006 Shaun McCance <shaunm(a)gnome.org>
# Copyright © 2013 Peter De Wachter <pdewacht(a)gmail.com>
+# Copyright © 2018 Yi-Jyun Pan <pan93412(a)gmail.com>
#
# This program is free software: you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
@@ -14,6 +15,10 @@
# You should have received a copy of the GNU General Public License
# along with this program. If not, see <http://www.gnu.org/licenses/>.
+# Let's load gettext!
+export TEXTDOMAIN="vte-profile"
+. gettext.sh
+
# Not bash or zsh?
[ -n "$BASH_VERSION" -o -n "$ZSH_VERSION" ] || return 0
@@ -42,7 +47,7 @@
# Print a warning so that anyone who's added this manually to his PS1 can adapt.
# The function will be removed in a later version.
__vte_ps1() {
- echo -n "(__vte_ps1 is obsolete)"
+ echo -n $(eval_gettext "(__vte_ps1 is obsolete)")
}
__vte_osc7 () {
@@ -54,7 +59,7 @@
command="${command//;/ }"
local pwd='~'
[ "$PWD" != "$HOME" ] && pwd=${PWD/#$HOME\//\~\/}
- printf '\033]777;notify;Command completed;%s\033\\\033]0;%s@%s:%s\033\\%s' "${command}" "${USER}" "${HOSTNAME%%.*}" "${pwd}" "$(__vte_osc7)"
+ printf '\033]777;notify;%s;%s\033\\\033]0;%s@%s:%s\033\\%s' $(eval_gettext "Command completed.") "${command}" "${USER}" "${HOSTNAME%%.*}" "${pwd}" "$(__vte_osc7)"
}
case "$TERM" in
5 years
"Basic graphics mode" feature and criterion discussion
by Adam Williamson
Hi folks!
So at last week's Fedora 30 Beta Go/No-Go meeting, it was decided that
the Basic release criterion:
"Boot menu contents
The boot menu for all supported installer and live images should
include an entry which causes both installation and the installed
system to use a generic, highly compatible video driver (such as
'vesa'). This mechanism should work correctly, launching the installer
or desktop and attempting to use the generic driver."
should no longer apply to Beta - i.e. that it should no longer be a
Basic or Beta criterion.
The justification for this is, I hope I am correctly representing all
views here (please say so if not), that this mechanism is both less
necessary (due to a general reduction in the amount of 'weird' graphics
hardware out there, and general improvement in the reliability and
coverage of the major drivers for the major graphics hardware
manufacturers) and inherently less likely to work (due to the general
trend of work on kernel modesetting and Wayland) than it used to be.
For context, it is worth noting that the *feature* predates the
introduction of both kernel modesetting *and* Wayland to Fedora. What
the feature initially did was tell anaconda to write an X config file
specifying the 'vesa' driver (instead of working out the correct
'native' driver for the adapter and writing a config file specifying
that). After KMS was introduced in Fedora 10, the mechanism was tweaked
to also pass the 'nomodeset' kernel parameter to disable KMS. Around
2012 (https://bugzilla.redhat.com/show_bug.cgi?id=858270) we noticed
that the X config file mechanism was a bit superfluous as 'nomodeset'
alone could basically be relied on to force some sort of 'fallback
mechanism', and so the feature was simplified to *only* specify the
'nomodeset' kernel parameter (this is all it does now).
The *criterion* dates to 2010, in the Fedora 15 release cycle: it
appears in the Fedora 15 Alpha criteria but not the Fedora 14 Alpha
criteria. It was added on 2010-08-16:
https://fedoraproject.org/w/index.php?title=Fedora_15_Alpha_Release_Crite...
The group at the meeting did not, however, make any further decisions,
so this leaves us with some open questions:
0) Do we generally agree with the decision made at the meeting? If
anyone (especially a subject matter expert) strongly believes the
decision was wrong and this should still be a Basic/Beta requirement,
please say so.
1) Should the criterion be modified somehow, but some requirement in
relation to some kind of fallback graphical mode be kept at Basic or
Beta?
2) Should the criterion be moved to Final, unchanged or changed
somehow?
3) Should the requirement just basically be dropped entirely as no
longer useful?
4) (This one mainly for ajax and airlied) to what extent does the
concept of a 'fallback option' for our supported desktop environments
and graphical servers still actually make sense? Could a different
implementation of the same basic idea be envisaged, and would it be
useful? If so, should we do that, and what would be the consequences
for the criteria?
I realize this is quite a big and fuzzy topic, but I'm hoping the
responses to this mail will clarify our path :) So if you have any kind
of useful information or strong opinions on the general area here,
please do contribute them, and hopefully a clearer way forward will
emerge.
Thanks everyone!
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
5 years
Stewardship SIG: Initial report and plans for the future
by Fabio Valentini
Hi everybody,
It looks like the first round of orphans has been taken in by our SIG - this
seemed to be a good time to do inventory and think about how to proceed.
Status Report
-------------
First of all, I've written a small script [0] that produces a simple HTML page
of the current status of the stewardship-SIG packager group. Pull Requests to
improve the report are welcome.
The current status is available at [1]. I will try to update that page
regularly.
Dependency Checks
-----------------
Also, I've tried to run some repoqueries to determine which of our packages are
leaf packages that could be retired eventually. However, running repoqueries on
f29 against the rawhide repos crashed dnf for some reason ... so I can't
automate that easily, yet.
I've tried coming up with a repoquery call that lists all packages that
(Build)Require some given argument package, which we could then use to prune the
list of packages maintained by this SIG. Can somebody please sanity-check what I
did here [2] and here [3]? It would be good if we had a "correct" version of
those dependency checks. PRs to fix/improve those scripts are very welcome.
Pagure Project
--------------
Since I'm already talking about Pull Requests, I've created a pagure project [4]
for our group, where we can have a ticketing system (for example, where change
of ownership for packages or retirement of leaf packages can be tracked), and
a collection of shared scripts and tools which can automate some of our
recurring tasks. The three scripts I mentioned will be moved there, as well.
That's all for now.
Fabio
[0]: https://github.com/decathorpe/miscripts/blob/master/stewardship-sig-repor...
[1]: https://decathorpe.fedorapeople.org/stewardship-sig.html
[2]: https://github.com/decathorpe/miscripts/blob/master/whatrequires.sh
[3]: https://github.com/decathorpe/miscripts/blob/master/whatbuildrequires.sh
[4]: https://www.pagure.io/stewardship-sig
5 years
clang segmentation fault on armv7hf
by Richard Shaw
I'm working on building PySide2 for Fedora and have a problem with clang
segfaulting only on armv7hf[1]...
The source package has shiboken2, pyside2, and pyside2-tools in one big
archive but I am building shiboken2 and pyside2-tools with GCC and only
pyside2 with clang because if makes use of something clang specific.
[ 1%] Building CXX object
libpyside/CMakeFiles/pyside2.dir/pysidesignal.cpp.o
cd
/builddir/build/BUILD/pyside-setup-everywhere-src-5.12.1/armv7hl-linux/pyside2/libpyside
&& /usr/bin/clang++ -DPYSIDE_EXPORTS -DPYSIDE_QML_PRIVATE_API_SUPPORT=1
-DPYSIDE_QML_SUPPORT=1 -DQT_CORE_LIB -DQT_NETWORK_LIB -DQT_NO_DEBUG
-DQT_QML_LIB
-I/builddir/build/BUILD/pyside-setup-everywhere-src-5.12.1/sources/pyside2/libpyside
-I/builddir/build/BUILD/python-pyside2_5.12.1/include/shiboken2
-I/usr/include/python3.7m -I/usr/include/qt5/QtQml/5.12.1
-I/usr/include/qt5/QtQml/5.12.1/QtQml -I/usr/include/qt5/QtNetwork/5.12.1
-I/usr/include/qt5/QtNetwork/5.12.1/QtNetwork
-I/usr/include/qt5/QtCore/5.12.1 -I/usr/include/qt5/QtCore/5.12.1/QtCore
-isystem /usr/include/qt5 -isystem /usr/include/qt5/QtQml -isystem
/usr/include/qt5/QtNetwork -isystem /usr/include/qt5/QtCore -isystem
/usr/lib/qt5/mkspecs/linux-g++ -O2 -g -pipe -Wall -Werror=format-security
-Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions
-fstack-protector-strong -grecord-gcc-switches
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -march=armv7-a
-mfpu=vfpv3-d16 -mtune=generic-armv7-a -mabi=aapcs-linux -mfloat-abi=hard
-Wall -fvisibility=hidden -Wno-strict-aliasing -D QT_NO_CAST_FROM_ASCII -D
QT_NO_CAST_TO_ASCII -fPIC -fPIC -std=gnu++11 -o
CMakeFiles/pyside2.dir/pysidesignal.cpp.o -c
/builddir/build/BUILD/pyside-setup-everywhere-src-5.12.1/sources/pyside2/libpyside/pysidesignal.cpp
make[2]: Leaving directory
'/builddir/build/BUILD/pyside-setup-everywhere-src-5.12.1/armv7hl-linux/pyside2'
clang-8: warning: argument unused during compilation:
'-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1'
[-Wunused-command-line-argument]
clang-8: warning: argument unused during compilation:
'-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1'
[-Wunused-command-line-argument]
Stack dump:
0. Program arguments: /usr/bin/clang-8 -cc1 -triple
armv7-unknown-linux-gnueabihf -emit-obj -disable-free
-disable-llvm-verifier -discard-value-names -main-file-name
pysidesignal.cpp -mrelocation-model pic -pic-level 2 -mthread-model posix
-mdisable-fp-elim -fmath-errno -masm-verbose -mconstructor-aliases
-fuse-init-array -target-cpu generic -target-feature -fp-only-sp
-target-feature +d16 -target-feature +vfp3 -target-feature -fp16
-target-feature -vfp4 -target-feature -fp-armv8 -target-feature -neon
-target-feature -crypto -target-abi aapcs-linux -mfloat-abi hard
-fallow-half-arguments-and-returns -dwarf-column-info
-debug-info-kind=limited -dwarf-version=4 -debugger-tuning=gdb
-coverage-notes-file
/builddir/build/BUILD/pyside-setup-everywhere-src-5.12.1/armv7hl-linux/pyside2/libpyside/CMakeFiles/pyside2.dir/pysidesignal.cpp.gcno
-resource-dir /usr/lib/clang/8.0.0 -isystem /usr/include/qt5 -isystem
/usr/include/qt5/QtQml -isystem /usr/include/qt5/QtNetwork -isystem
/usr/include/qt5/QtCore -isystem /usr/lib/qt5/mkspecs/linux-g++ -D
PYSIDE_EXPORTS -D PYSIDE_QML_PRIVATE_API_SUPPORT=1 -D PYSIDE_QML_SUPPORT=1
-D QT_CORE_LIB -D QT_NETWORK_LIB -D QT_NO_DEBUG -D QT_QML_LIB -I
/builddir/build/BUILD/pyside-setup-everywhere-src-5.12.1/sources/pyside2/libpyside
-I /builddir/build/BUILD/python-pyside2_5.12.1/include/shiboken2 -I
/usr/include/python3.7m -I /usr/include/qt5/QtQml/5.12.1 -I
/usr/include/qt5/QtQml/5.12.1/QtQml -I /usr/include/qt5/QtNetwork/5.12.1 -I
/usr/include/qt5/QtNetwork/5.12.1/QtNetwork -I
/usr/include/qt5/QtCore/5.12.1 -I /usr/include/qt5/QtCore/5.12.1/QtCore -D
QT_NO_CAST_FROM_ASCII -D QT_NO_CAST_TO_ASCII -D_FORTIFY_SOURCE=2
-D_GLIBCXX_ASSERTIONS -internal-isystem
/usr/bin/../lib/gcc/armv7hl-redhat-linux-gnueabi/9/../../../../include/c++/9
-internal-isystem
/usr/bin/../lib/gcc/armv7hl-redhat-linux-gnueabi/9/../../../../include/c++/9/armv7hl-redhat-linux-gnueabi
-internal-isystem
/usr/bin/../lib/gcc/armv7hl-redhat-linux-gnueabi/9/../../../../include/c++/9/backward
-internal-isystem /usr/local/include -internal-isystem
/usr/lib/clang/8.0.0/include -internal-externc-isystem /include
-internal-externc-isystem /usr/include -O2 -Wall -Werror=format-security
-Wall -Wno-strict-aliasing -std=gnu++11 -fdeprecated-macro
-fdebug-compilation-dir
/builddir/build/BUILD/pyside-setup-everywhere-src-5.12.1/armv7hl-linux/pyside2/libpyside
-ferror-limit 19 -fmessage-length 0 -fvisibility hidden -stack-protector 2
-fno-signed-char -fobjc-runtime=gcc -fcxx-exceptions -fexceptions
-fdiagnostics-show-option -vectorize-loops -vectorize-slp -o
CMakeFiles/pyside2.dir/pysidesignal.cpp.o -x c++
/builddir/build/BUILD/pyside-setup-everywhere-src-5.12.1/sources/pyside2/libpyside/pysidesignal.cpp
-dwarf-debug-flags /usr/bin/clang-8 --driver-mode=g++ -D PYSIDE_EXPORTS -D
PYSIDE_QML_PRIVATE_API_SUPPORT=1 -D PYSIDE_QML_SUPPORT=1 -D QT_CORE_LIB -D
QT_NETWORK_LIB -D QT_NO_DEBUG -D QT_QML_LIB -I
/builddir/build/BUILD/pyside-setup-everywhere-src-5.12.1/sources/pyside2/libpyside
-I /builddir/build/BUILD/python-pyside2_5.12.1/include/shiboken2 -I
/usr/include/python3.7m -I /usr/include/qt5/QtQml/5.12.1 -I
/usr/include/qt5/QtQml/5.12.1/QtQml -I /usr/include/qt5/QtNetwork/5.12.1 -I
/usr/include/qt5/QtNetwork/5.12.1/QtNetwork -I
/usr/include/qt5/QtCore/5.12.1 -I /usr/include/qt5/QtCore/5.12.1/QtCore
-isystem /usr/include/qt5 -isystem /usr/include/qt5/QtQml -isystem
/usr/include/qt5/QtNetwork -isystem /usr/include/qt5/QtCore -isystem
/usr/lib/qt5/mkspecs/linux-g++ -O2 -g -pipe -Wall -Werror=format-security
-Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions
-fstack-protector-strong -grecord-command-line
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -march=armv7-a
-mfpu=vfpv3-d16 -mtune=generic-armv7-a -mabi=aapcs-linux -mfloat-abi=hard
-Wall -fvisibility=hidden -Wno-strict-aliasing -D QT_NO_CAST_FROM_ASCII -D
QT_NO_CAST_TO_ASCII -fPIC -fPIC -std=gnu++11 -o
CMakeFiles/pyside2.dir/pysidesignal.cpp.o -c
/builddir/build/BUILD/pyside-setup-everywhere-src-5.12.1/sources/pyside2/libpyside/pysidesignal.cpp
-faddrsig
1. <eof> parser at end of file
2. /builddir/build/BUILD/pyside-setup-everywhere-src-5.12.1/sources/pyside2/libpyside/pysidesignal.cpp:596:11:
LLVM IR generation of declaration 'PySide'
3. /builddir/build/BUILD/pyside-setup-everywhere-src-5.12.1/sources/pyside2/libpyside/pysidesignal.cpp:970:9:
Generating code for declaration 'PySide::Signal::getCallbackSignature'
4. /builddir/build/BUILD/pyside-setup-everywhere-src-5.12.1/sources/pyside2/libpyside/pysidesignal.cpp:984:45:
LLVM IR generation of compound statement ('{}')
5. /builddir/build/BUILD/pyside-setup-everywhere-src-5.12.1/sources/pyside2/libpyside/pysidesignal.cpp:990:23:
LLVM IR generation of compound statement ('{}')
6. /builddir/build/BUILD/pyside-setup-everywhere-src-5.12.1/sources/pyside2/libpyside/pysidesignal.cpp:995:57:
LLVM IR generation of compound statement ('{}')
clang-8: error: unable to execute command: Segmentation fault (core dumped)
clang-8: error: clang frontend command failed due to signal (use -v to see
invocation)
clang version 8.0.0 (Fedora 8.0.0-1.fc31)
Target: armv7l-unknown-linux-gnueabihf
Thread model: posix
InstalledDir: /usr/bin
clang-8: note: diagnostic msg: PLEASE submit a bug report to and include
the crash backtrace, preprocessed source, and associated run script.
clang-8: note: diagnostic msg:
********************
PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
Preprocessed source(s) and associated run script(s) are located at:
clang-8: note: diagnostic msg: /tmp/pysidesignal-058743.cpp
clang-8: note: diagnostic msg: /tmp/pysidesignal-058743.sh
clang-8: note: diagnostic msg:
********************
Thanks,
Richard
[1] https://kojipkgs.fedoraproject.org//work/tasks/4670/33794670/build.log
5 years
Fedora 31 System-Wide Change proposal: Gating Rawhide - Single
package updates
by Ben Cotton
https://fedoraproject.org/wiki/Changes/GatingRawhideSinglePackageUpdates
== Summary ==
We want to gate packages on test results before they can land in
rawhide. This will reduce the amount of broken dependency,
uninstallable packages and broken composes leading to a more stable
rawhide as well as less work on the infrastructure and rel-eng teams
to keep composes working.
This project will be split in two phases, at first only single package
updates will be supported, in a second stage, we will add support for
multi-packages updates.
This proposal is about the phase 1 of this project.
== Owner ==
* Name: [[User:pingou|Pierre-Yves Chibon]]
* Email: pingou - pingoured.fr
People who are/will be involved in this:
* Coordinator: [[User:pingou|Pierre-Yves Chibon]]
* Bodhi: [[User:bowlofeggs|Randy Barlow]] and [[User:abompard|Aurélien Bompard]]
* Fedora CI: [[User:dperpeet|Dominik Perpeet]]
== Detailed Description ==
Querying the Bodhi database, it was revealed that 95% of all our
updates involve a single package.
To be exhaustive, here are the exact number found by Randy:
Of all time:
Single build updates: 123,657 (94.1%)
Multi build updates: 7,766 ( 5.9%)
Total: 131,423
Per release:
Fedora 29:
Single: 4,675 (93.7%)
Multi: 316 ( 6.3%)
Fedora 28:
Single: 9,153 (94.5%)
Multi: 536 ( 5.5%)
EPEL 7:
Single: 12,664 (94.0%)
Multi: 814 ( 6.0%)
When considering gating rawhide package updates on test results, we
need to consider two workflows: single package updates, multi-package
updates. This proposal only considers the single package updates
workflow. [[Changes/GatingRawhideMultiPackagesUpdates|Another
proposal]] will be submitted in the future to support the multi
package updates workflow.
At first we want to build the system allowing to gating rawhide,
packagers will '''opt-in into gating'''
[https://docs.pagure.org/greenwave/package-specific-policies.html
using greenwave's opt-in gating mechanism] as they want. We will also
offer a way to '''opt-out''' so packages depending on other packages
can still be built without issues.
We do not aim at making any tests mandatory as part of these
proposals. Once the two proposals have been deployed it will be up to
the community and likely FESCo to decide if they would like to enforce
some rules on all packages and which ones.
Note that this proposal completes previous initiative such as
[[Changes/NoMoreAlpha]]
=== Workflows ===
<gallery>
Single_package_GatingRawhide_bodhi.png|Single package update with gating
</gallery>
== Benefit to Fedora ==
* As more packagers opt-into gating and add tests to their packages,
rawhide becomes more stable
* More stable rawhide will lead to easier composes and a smoother
release process
* Ability to use chain-build in rawhide and stable releases
== Scope ==
The scope of this work is adding a mechanism to gate single package
updates before they enter the rawhide buildroot (and thus become
accessible to others) so broken packages are kept out and cannot
affect other packages or the compose until they are fixed by their
maintainers.
'''The CI system, the tests and the decision on which tests are used
to gate upon are out of scope for the present document.'''
* Proposal owners: pingou will be coordinating the work among the
different stack holder
* Other developers:
** Bodhi developers: Implement the needed changes
** infrastructure: deploy the new version of bodhi and the new koji plugin
* Release engineering: https://pagure.io/releng/issue/8183
* Policies and guidelines: Once the entire system is in place, FESCo
may want to set a policy on distribution-wide gating (ie: tests that
would be enforced for all packages in the distributions). This is
however out of scope of this proposal.
* Trademark approval: N/A (not needed for this Change)
=== Application impacted ===
==== Bodhi ====
* Single package update
** We will need to write a message-bus listener that will
automatically create a bodhi update for each package built in the
rawhide-gated tag.
** We will need to write a message-bus listener to automatically push
bodhi updates created for rawhide that have passed CI (the decision
being announced by Greenwave).
* Bodhi will comment on the updates when greenwave's decision about an
update is known
** This will notify users about the test results and the corresponding
gating status.
==== Greenwave / WaiverDB ====
Nothing should change for these tools but we will have to confirm this
and test in staging that they behave as expected.
==== CI system ====
Nothing should change for the CI system but we will have to confirm
this and test in staging that they behave as expected.
== Upgrade/compatibility impact ==
N/A
== How To Test ==
# Add tests to a package you maintain in Fedora using the [[
CI/Quick_Start_Guide ]] documentation (see the full [[CI|CI
documentation ]] for more information).
# Update your package in rawhide
# Ensure that the bodhi update is automatically created
# Check that the tests have properly ran (see the Tests tab in the bodhi update)
# Ensure that the bodhi update went through to rawhide once the tests passed
== User Experience ==
=== Single package update ===
fedpkg clone rpms/foobar
cd foobar/
vim foobar.spec
git commit -am "Git commit message"
fedpkg build
If the CI tests pass, the package will land in rawhide, if they fail the user
will be able to go to bodhi to see what failed and why as well as waiving the
failed tests if needed.
=== Multi package update with single package update gating ===
fedpkg clone rpms/foobar
cd foobar/
vim foobar.spec
git commit -am "Update of foobar to update foo to 1.2"
fedpkg push
fedpkg build --target=rawhide-candidate
cd ..
fedpkg clone rpms/foobaz
cd foobaz
vim foobaz.spec
git commit -am "Update of foobaz to update foo to 1.2"
fedpkg push
fedpkg build --target=rawhide-candidate
cd ..
fedpkg clone rpms/foo
cd foo
vim foo.spec
git commit -am "Update foo to 1.2"
fedpkg push
fedpkg build --target=rawhide-candidate
Users are practically by-passing the gating process by specifying a
specific build target.
== Dependencies ==
* Bodhi
** bus listener to automatically create updates when a build happens in rawhide
** bus listener to automatically push updates who passed gating
according to greenwave
** comment on updates about gating status change/announce to notify
packagers about it
== Contingency Plan ==
We can keep doing rawhide as we are doing it today.
== Documentation ==
To be written/updated
List of documentation pages to update:
* https://fedoraproject.org/wiki/Updates_Policy
* https://fedoraproject.org/wiki/Package_maintenance_guide
* https://fedoraproject.org/wiki/Package_update_HOWTO
* https://docs.fedoraproject.org/en-US/packaging-guidelines/
--
Ben Cotton
Fedora Program Manager
TZ=America/Indiana/Indianapolis
5 years
Blocking criteria proposal for F30+: Printing
by Stephen Gallagher
There was a bug[1] filed recently that indicated that printing was
broken on certain printers. As a result of that discussion, it became
apparent that there was no criteria for printing to work at all, which
seems like an oversight.
I discussed this briefly with Matthias Clasen this morning and he
agreed that this should be treated as blocking for Workstation.
I'd like to propose that we add the following criteria to Beta for Fedora 30+:
* Printing must work on at least one printer available to Fedora QA.
"Work" is defined as the output from the device matching a preview
shown on the GNOME print preview display. (Note that differences in
color reproduction are not considered "non-working".)
and this to Final for Fedora 30+:
* Printing must work on at least one printer using each of the
following drivers:
(I don't know which ones to specify here, but we ought to try to
figure out a cross-section that covers a large swath of our expected
user base).
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1628255
5 years
dnf crashes make fedpkg / mock unusable
by Fabio Valentini
Hi everybody,
Since about one or two days, I am completely unable to build any
packages with fedpkg locally, and even running dnf on the host system
is really crashy.
It looks like dnf crashes while it's refreshing repository metadata.
ABRT won't let me report the issue due to "low informational value" of
the backtrace, but it looks like SEGFAULT in libcurl:
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x00007fad55077f22 in ?? () from /lib64/libcurl.so.4
(...)
However, there's not been any recent curl update for f29 AFAICT. I
tried cleaning up the dnf cache, but it doesn't help.
Does anybody have an idea what's causing this? I'm unable to work on
my packages until I can solve this ....
Fabio
5 years
