Re: Unretiring itpp
Hi, my two pence.
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
Not required.
%cmake -DBLA_VENDOR=ATLAS -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=/usr
make %{?_smp_mflags}
May be you want to do:
mkdir -p %{_target_platform}
pushd %{_target_platform}
%cmake -DBLA_VENDOR=ATLAS -DCMAKE_BUILD_TYPE=Release ..
popd
make -C %{_target_platform} %{?_smp_mflags}
and later
make -C %{_target_platform} install DESTDIR=$RPM_BUILD_ROOT
mv $RPM_BUILD_ROOT/usr/lib $RPM_BUILD_ROOT/%{_libdir}
That wouldn't work on systems with /usr/lib dir.
Anyway lib_64_ must be handled in another way.
You are missing %doc and %licence in %files still.
Dmitrij
Is this version better ? I think I incorporated all your suggestions +
some more that are in the same vein to what you suggested.
Theo.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Headsup: Xserver update switching Intel GPUs from xorg-x11-drv-intel to -modesetting by default coming to rawhide
Hi, On 20-01-17 02:05, Kevin Kofler wrote: Hans de Goede wrote: most tools simply write directly to /sys/class/backlight, but xbacklight relies on the xrandr property (and is the only tool do so AFAICT). KDE's PowerDevil supports both and prefers XRandR where supported: https://cgit.kde.org/powerdevil.git/tree/daemon/backends/upower As you pointed out, the nice thing about the XRandR property is that it does not require root access, whereas the sysfs interface requires going through a KAuth/PolicyKit helper to get root (which PowerDevil sets up with a default policy of "yes" so that all users can use it without a PolicyKit password prompt). It is sad that most drivers did not bother implementing it. Actually since the xserver no longer runs as root now a days, the xf86-video-* drivers need to go through the same hoops, which is why xorg-x11-drv-intel has: /usr/libexec/xf86-video-intel-backlight-helper which it starts through pkexec ... Note that systemd already has some backlight handling for save / restore of backlight settings over a reboot. I believe the real solution here might be to have a systemd-backlightd or some such, rather then have all DEs invent their own wheel. Regards, Hans ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Unretiring itpp
On 01/20/2017 07:50 AM, Zbigniew Jędrzejewski-Szmek wrote: > On Fri, Jan 20, 2017 at 02:32:22AM +0100, Kevin Kofler wrote: >> Theodore Papadopoulo wrote: >>> The only problem is that libraries got installed (as usual with cmake) in >>> /usr/lib and not in /usr/lib64, >> >> Only if the CMakeLists.txt is broken. It should use LIB_INSTALL_DIR and/or >> LIB_SUFFIX. In this case, it was fixed back in 2014 (!): >> https://sourceforge.net/p/itpp/git/ci/8ff787c218c31ad90c51c2da54085e79bb7fd1b3/ >> (The last release is from 2013!) >> >>> which I worked around with a mv (not sure this is teh best solution, but >>> it works). >> >> Please fix CMakeLists.txt (just backport the upstream fix) instead. > > Without looking at the repo, it sounds like packaging a git snapshot would > be easier and better. Is this allowed ??? I know that in many cases this is discouraged. That would be even simpler for me. Of course, Correcting the build with a patch is also easy. I just tried to be the less invasive. Anyway, thank's for all the feedbacks, I'll make another version of the spec incorporating all the comments. Theo. signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Unretiring itpp
On Fri, Jan 20, 2017 at 11:02 AM, Theodore Papadopoulo wrote: > On 01/20/2017 07:50 AM, Zbigniew Jędrzejewski-Szmek wrote: [snip] >> Without looking at the repo, it sounds like packaging a git snapshot would >> be easier and better. > > Is this allowed ??? I know that in many cases this is discouraged. > That would be even simpler for me. Of course, Correcting the build with > a patch is also easy. I just tried to be the less invasive. You may also want to take a look here (if you haven't already): https://fedoraproject.org/wiki/Packaging:Versioning#NonNumericRelease ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
F26 Self Contained Change: Making sudo pip Safe (Again)
= Proposed Self Contained Change: Making sudo pip Safe (Again) =
https://fedoraproject.org/wiki/Changes/Making_sudo_pip_safe
Change owner(s):
* Michal Cyprian
* Petr Viktorin
* Tomas Orsava
* Miro Hroncok
At the present time, running sudo pip3 in Fedora is not safe. Pip
shares its installation directory with dnf, can remove dnf-managed
files and generally break the Python 3 interpreter. We propose a
series of measures that will make it safe to use.
== Detailed Description ==
The danger of using sudo pip3 stems from the fact that both Python dnf
packages and sudo pip3 install modules to the same location, namely
/usr/lib/pythonX.Y/site-packages.
We aim to move the working directory for sudo pip3 to a more
appropriate location: /usr/local/lib/pythonX.Y/site-packages, and
modify the Python 3 interpreter in Fedora to scan both above mentioned
locations when importing modules. In addition, system-python—a
stripped down version of Python 3 for use by system tools—will not
read the sudo pip3 install location, making it more secure by being
less susceptible to interference by user-downloaded modules.
From the technical standpoint, this will be accomplished by changing
the sys.prefix setting in the /usr/bin/python3 executable from /usr/
to /usr/local. pip3 will thereafter use this prefix when determining
where to install modules. In addition, the original path
/usr/lib/pythonX.Y/site-packages will be added to the sys.path
variable (so that modules at that location are still processed when
importing), because this path will not be automatically scanned
anymore as it no longer lies inside the sys.prefix path. These
settings, however, will not be modified for the system-python binary,
and the %{__python3} macro will be changed from /usr/bin/python3 to
/usr/libexec/system-python. Therefore, Python dnf packages will
continue to be built with the correct installation path for system
modules.
Note that using sudo pip3 is not strictly necessary, as using pip3
install --user would satisfy the vast majority of use cases.
Nevertheless, sudo pip is far too prevalent an instruction in various
guides and installation notes throughout the Internet that there is
little hope of changing users' behaviour in this regard.
== Scope ==
* Proposal owners:
Modify the Python 3 executable as described above.
Modify the %{__python3} macro so that it points to /usr/libexec/system-python
* Other developers:
Spec files that use pip3 install without the use of a macro will need
to be modified accordingly. Only 3 like packages were identified
(python-flit, python-entrypoints, python-setuptools).
* Release engineering:
A rebuild of all Python packages will be necessary.
* List of deliverables:
All Fedora deliverables will be affected in a minor way that does not
jeopardize their delivery.
* Policies and guidelines:
The definition of the %{__python3} macro will be updated as mentioned above.
* Trademark approval:
Not needed for this Change
--
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Unretiring itpp
On Fri, 20 Jan 2017 15:04:56 +0700, Dmitrij S. Kryzhevich wrote:
> Anyway lib_64_ must be handled in another way.
The two new Perl based subst expressions added to %install also are
specific to lib64 build targets and won't be correct where %_libdir expands
to /usr/lib.
> Group: System Environment/Libraries
> Group: Development/Libraries
The Group tag has been optional for a long time. As such I would really
remove it everywhere.
> %files
> %dir %{_docdir}/%{name}
> %{_docdir}/%{name}/[A-Z]*
> %files doc
> %{_docdir}/%{name}/html
The -doc subpackage needs to include the directory entry, too.
Plus, rather than the non-flexible [A-Z]* you could take this opportunity
and use %exclude:
%files
%dir %{_docdir}/%{name}
%{_docdir}/%{name}/*
%exclude %{_docdir}/%{name}/html
%files doc
%dir %{_docdir}/%{name}
%{_docdir}/%{name}/html/
Or the slightly shorter tree inclusion:
%files
%{_docdir}/%{name}/
%exclude %{_docdir}/%{name}/html
%files doc
%dir %{_docdir}/%{name}
%{_docdir}/%{name}/html/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
[Test-Announce] Fedora 26 Rawhide 20170120.n.0 nightly compose nominated for testing
Announcing the creation of a new nightly release validation test event for Fedora 26 Rawhide 20170120.n.0. Please help run some tests for this nightly compose if you have time. For more information on nightly release validation testing, see: https://fedoraproject.org/wiki/QA:Release_validation_test_plan Notable package version changes: pungi - 20170117.n.0: pungi-4.1.11-4.fc26.src, 20170120.n.0: pungi-4.1.12-3.fc26.src Test coverage information for the current release can be seen at: https://www.happyassassin.net/testcase_stats/26 You can see all results, find testing instructions and image download locations, and enter results on the Summary page: https://fedoraproject.org/wiki/Test_Results:Fedora_26_Rawhide_20170120.n.0_Summary The individual test result pages are: https://fedoraproject.org/wiki/Test_Results:Fedora_26_Rawhide_20170120.n.0_Installation https://fedoraproject.org/wiki/Test_Results:Fedora_26_Rawhide_20170120.n.0_Base https://fedoraproject.org/wiki/Test_Results:Fedora_26_Rawhide_20170120.n.0_Server https://fedoraproject.org/wiki/Test_Results:Fedora_26_Rawhide_20170120.n.0_Cloud https://fedoraproject.org/wiki/Test_Results:Fedora_26_Rawhide_20170120.n.0_Desktop https://fedoraproject.org/wiki/Test_Results:Fedora_26_Rawhide_20170120.n.0_Security_Lab Thank you for testing! -- Mail generated by relval: https://www.happyassassin.net/relval/ ___ test-announce mailing list -- test-annou...@lists.fedoraproject.org To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora rawhide compose report: 20170120.n.0 changes
OLD: Fedora-Rawhide-20170119.n.0
NEW: Fedora-Rawhide-20170120.n.0
= SUMMARY =
Added images:0
Dropped images: 3
Added packages: 2
Dropped packages:0
Upgraded packages: 130
Downgraded packages: 1
Size of added packages: 116.06 KiB
Size of dropped packages:0.00 B
Size of upgraded packages: 2.46 GiB
Size of downgraded packages: 30.80 MiB
Size change of upgraded packages: -203.36 MiB
Size change of downgraded packages: 14.58 KiB
= ADDED IMAGES =
= DROPPED IMAGES =
Image: Robotics live i386
Path: Labs/i386/iso/Fedora-Robotics-Live-i386-Rawhide-20170119.n.0.iso
Image: Xfce raw-xz armhfp
Path: Spins/armhfp/images/Fedora-Xfce-armhfp-Rawhide-20170119.n.0-sda.raw.xz
Image: Robotics live x86_64
Path: Labs/x86_64/iso/Fedora-Robotics-Live-x86_64-Rawhide-20170119.n.0.iso
= ADDED PACKAGES =
Package: python-glusterfs-api-1.1-2.fc26
Summary: Python bindings for GlusterFS libgfapi
RPMs:python2-glusterfs-api
Size:49002 bytes
Package: python-piexif-1.0.8-1.fc26
Summary: Pure Python library to simplify exif manipulations with python.
RPMs:python2-piexif python3-piexif
Size:69840 bytes
= DROPPED PACKAGES =
= UPGRADED PACKAGES =
Package: abcde-2.8.1-1.fc26
Old package: abcde-2.8-1.fc26
Summary: A Better CD Encoder
RPMs: abcde
Size: 127870 bytes
Size change: 208 bytes
Changelog:
* Thu Jan 19 2017 Dominik Mierzejewski - 2.8.1-1
- Update to 2.8.1
Package: brightnessctl-0.2.1-1.fc26
Old package: brightnessctl-0.2-1.fc26
Summary: Read and control device brightness
RPMs: brightnessctl
Size: 98352 bytes
Size change: 548 bytes
Changelog:
* Thu Jan 19 2017 Fabio Alessandro Locati - 0.2.1-1
- Update to 0.2.1
Package: calamares-3.0-0.1.beta2.fc26
Old package: calamares-2.5-0.2.beta1.fc26
Summary: Installer from a live CD/DVD/USB to disk
RPMs: calamares calamares-devel calamares-interactiveterminal
calamares-libs calamares-webview
Size: 4635032 bytes
Size change: 1736 bytes
Package: calcurse-4.2.1-3.fc26
Old package: calcurse-4.2.1-2.fc26
Summary: Text-based personal organizer
RPMs: calcurse
Size: 1280216 bytes
Size change: -318560 bytes
Changelog:
* Thu Jan 19 2017 Jon Ciesla - 4.2.1-3
- Fix doc installation.
Package: cassandra-3.9-2.fc26
Old package: cassandra-3.9-1.fc26
Summary: OpenSource database for high-scale application
RPMs: cassandra cassandra-clientutil cassandra-javadoc cassandra-parent
cassandra-python2-cqlshlib cassandra-stress cassandra-thrift
Size: 76060268 bytes
Size change: 154956 bytes
Changelog:
* Wed Jan 18 2017 Tomas Repik - 3.9-2
- fix paths so that one could run the server
Package: container-selinux-2:2.4-1.fc26
Old package: container-selinux-2:2.3-1.fc26
Summary: SELinux policies for container runtimes
RPMs: container-selinux
Size: 29510 bytes
Size change: 192 bytes
Changelog:
* Thu Jan 19 2017 Dan Walsh - 2:4.1-1
- Add typebounds statement for container_t from container_runtime_t
- We should only label runc not runc*
Package: cups-1:2.2.2-1.fc26
Old package: cups-1:2.2.1-4.fc26
Summary: CUPS printing system
RPMs: cups cups-client cups-devel cups-filesystem cups-ipptool
cups-libs cups-lpd
Size: 49948790 bytes
Size change: 27596 bytes
Changelog:
* Thu Jan 19 2017 Zdenek Dohnal - 1:2.2.2-1
- rebase to 2.2.2
Package: cups-filters-1.13.3-1.fc26
Old package: cups-filters-1.13.2-1.fc26
Summary: OpenPrinting CUPS filters and backends
RPMs: cups-filters cups-filters-devel cups-filters-libs
Size: 5283680 bytes
Size change: 7188 bytes
Changelog:
* Thu Jan 19 2017 Zdenek Dohnal - 1.13.3-1
- rebase to 1.13.3
Package: cyphesis-0.6.2-11.fc26
Old package: cyphesis-0.6.2-10.fc26
Summary: WorldForge game server
RPMs: cyphesis cyphesis-logwatch
Size: 9725992 bytes
Size change: 7412 bytes
Changelog:
* Sat Jan 14 2017 Ville Skytt?? - 0.6.2-11
- Move tmpfiles.d config to %{_tmpfilesdir}
Package: diffoscope-69-1.fc26
Old package: diffoscope-62-2.fc26
Summary: In-depth comparison of files, archives, and directories
RPMs: diffoscope
Size: 204546 bytes
Size change: 41536 bytes
Changelog:
* Thu Jan 19 2017 Zbigniew J??drzejewski-Szmek - 69-1
- Update to latest version (upstream dropped trydiffoscope)
- Add more dependendencies, and pull them in as Recommends
Package: doxygen-1:1.8.13-3.fc26
Old package: doxygen-1:1.8.13-2.fc26
Summary: A documentation system for C/C++
RPMs: doxygen doxygen-doxywizard doxygen-latex
Size: 43397592 bytes
Size change: 16948 bytes
Changelog:
* Thu Jan 19 2017 Than Ngo - 1:1.8.13-3
- Bug 775493 - Usage of underscore's in parameter names
Package: elementary-icon-theme-4.0.2-1.fc26
Old package: elementary-icon-
gssproxy: server localhost not responding, timed out
Hello, Does anybody know what $subject means? I'm seeing it with the latest rawhide while doing secure NFS testing. tia, steved. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Unretiring itpp
On Fri, Jan 20, 2017 at 12:15:14PM +0200, Alexander Ploumistos wrote: > On Fri, Jan 20, 2017 at 11:02 AM, Theodore Papadopoulo > wrote: > > On 01/20/2017 07:50 AM, Zbigniew Jędrzejewski-Szmek wrote: > [snip] > >> Without looking at the repo, it sounds like packaging a git snapshot would > >> be easier and better. > > > > Is this allowed ??? I know that in many cases this is discouraged. > > That would be even simpler for me. Of course, Correcting the build with > > a patch is also easy. I just tried to be the less invasive. It's allowed. Most of the time released versions are preferred to snapshots, but you can do whatever you think works best for the users of your package. > You may also want to take a look here (if you haven't already): > https://fedoraproject.org/wiki/Packaging:Versioning#NonNumericRelease Exactly. The whole point of those guidelines is too a) make it clear which version of the code the package has, b) make package versions rise monotonically. Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: bex represents pagure emails in hyperkitty
FYI, I disabled the auto-update feature because it could be exploited. Sender names are now fixed to the one in the last email sent to a list, the full fix is more complex and requires a SQL schema change, so it's going to take some more time. Thanks for letting me know about this issue. Aurélien ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Important: NSS + Firefox + Thunderbird + Seamonkey + Icecat + Xulrunner
Hello, we are currently dealing with a tricky situation, that the NSS and Mozilla package maintainers have been discussing, and I'd like to publish our plan. The most recent NSS update, version 3.28.1, is required to ship to the Firefox 51 update planned for January 24. Unfortunately, NSS 3.28.1 is incompatible with Mozilla applications version 50 and older. If Mozilla 50 or older is used together with NSS 3.28 or newer, and the application attempts to use HTTP v2, the connections to some servers may fail (including connections to Google servers). The fix is simple, it's possible to apply a small patch to the older Mozilla applications, to make it compatible with NSS 3.28.1 The difficulty here is the timing, and it's a conflict between "don't break applications in Fedora" and "ship new Firefox security update as soon as possible". If we start by shipping NSS 3.28.1 first, without yet having fixed the Mozilla applications, then we allow Firefox 51 to be shipped, but we risk that the other applications aren't fixed in time, and that users might see regressions, caused by the upgrade to NSS 3.28.1 Alternatively, if we wait until all affected Mozilla packages have been updated to fixed versions, it might delay the January 24 Firefox 51 update. After discussing this, we have a preference to avoid the breakage in Fedora, and try to ship all required updates as soon as possible. In order to avoid the breakage, we want to add "Conflicts:" statements to the NSS 3.28.1 package, that makes it conflict with all known Mozilla packages that don't contain the required fix yet. The packages we have identified are: - firefox - thunderbird - seamonkey - xulrunner - icecat I see that for all the above packages, build attempts that include the fix are already ongoing in koji, so there's hope that we might be able to resolve the situation in time. However, if ANY of the above build cannot be completed soon, or, if ANY of the updates cannot move to the stable Fedora updates, it can block users from upgrading to the Firefox 51 update on Jan 24. Is that acceptable? Do you agree that we make NSS conflict with any known incompatible packages mentioned above, and thereby may inhibit a subset of Fedora users from upgrading to Firefox 51 immediately? If we can get all the above builds done quickly, and all of them pushed to Fedora stable updates quickly, we're good. Note that we have the remaining risk that we haven't identified all Mozilla packages that might be affected. The relevant code isn't in NSS, but in Mozilla's network code. That means, if the above list of packages isn't the complete set of affected Mozilla based applications, other packages might still experience the connectivity regression. But as soon as another package is identified, it can rebuild to pick up the mentioned fix. Thanks Kai PS: Tracking bug is here: https://bugzilla.redhat.com/show_bug.cgi?id=1381400 (Don't get confused with the separate, unrelated discussion on TLS 1.3) An example of the regression is here: https://bugzilla.redhat.com/show_bug.cgi?id=1414929 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Important: NSS + Firefox + Thunderbird + Seamonkey + Icecat + Xulrunner
On Fri, Jan 20, 2017 at 9:52 AM, Kai Engert wrote: > Hello, > > we are currently dealing with a tricky situation, that the NSS and Mozilla > package maintainers have been discussing, and I'd like to publish our plan. > > The most recent NSS update, version 3.28.1, is required to ship to the Firefox > 51 update planned for January 24. > > Unfortunately, NSS 3.28.1 is incompatible with Mozilla applications version 50 > and older. > > If Mozilla 50 or older is used together with NSS 3.28 or newer, and the > application attempts to use HTTP v2, the connections to some servers may fail > (including connections to Google servers). > > The fix is simple, it's possible to apply a small patch to the older Mozilla > applications, to make it compatible with NSS 3.28.1 > > The difficulty here is the timing, and it's a conflict between "don't break > applications in Fedora" and "ship new Firefox security update as soon as > possible". > > If we start by shipping NSS 3.28.1 first, without yet having fixed the Mozilla > applications, then we allow Firefox 51 to be shipped, but we risk that the > other > applications aren't fixed in time, and that users might see regressions, > caused > by the upgrade to NSS 3.28.1 > > Alternatively, if we wait until all affected Mozilla packages have been > updated > to fixed versions, it might delay the January 24 Firefox 51 update. > > After discussing this, we have a preference to avoid the breakage in Fedora, > and > try to ship all required updates as soon as possible. > > In order to avoid the breakage, we want to add "Conflicts:" statements to the > NSS 3.28.1 package, that makes it conflict with all known Mozilla packages > that > don't contain the required fix yet. > > The packages we have identified are: > - firefox > - thunderbird > - seamonkey > - xulrunner > - icecat > > I see that for all the above packages, build attempts that include the fix are > already ongoing in koji, so there's hope that we might be able to resolve the > situation in time. > > However, if ANY of the above build cannot be completed soon, or, if ANY of the > updates cannot move to the stable Fedora updates, it can block users from > upgrading to the Firefox 51 update on Jan 24. > > Is that acceptable? > > Do you agree that we make NSS conflict with any known incompatible packages > mentioned above, and thereby may inhibit a subset of Fedora users from > upgrading > to Firefox 51 immediately? > > If we can get all the above builds done quickly, and all of them pushed to > Fedora stable updates quickly, we're good. > > > Note that we have the remaining risk that we haven't identified all Mozilla > packages that might be affected. The relevant code isn't in NSS, but in > Mozilla's network code. That means, if the above list of packages isn't the > complete set of affected Mozilla based applications, other packages might > still > experience the connectivity regression. But as soon as another package is > identified, it can rebuild to pick up the mentioned fix. Is bundling the newer NSS release inside of firefox itself an option? While it may not be the best long-term solution and we all know the downsides of bundling, it is at least pragmatic in the short-term. That would allow firefox to ship and time for the remaining packages to be updated. Once they're ready, the bundling in firefox could be dropped and an update with all the packages could be done. josh ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Important: NSS + Firefox + Thunderbird + Seamonkey + Icecat + Xulrunner
On 01/20/2017 04:13 PM, Josh Boyer wrote: On Fri, Jan 20, 2017 at 9:52 AM, Kai Engert wrote: Hello, we are currently dealing with a tricky situation, that the NSS and Mozilla package maintainers have been discussing, and I'd like to publish our plan. The most recent NSS update, version 3.28.1, is required to ship to the Firefox 51 update planned for January 24. Unfortunately, NSS 3.28.1 is incompatible with Mozilla applications version 50 and older. If Mozilla 50 or older is used together with NSS 3.28 or newer, and the application attempts to use HTTP v2, the connections to some servers may fail (including connections to Google servers). The fix is simple, it's possible to apply a small patch to the older Mozilla applications, to make it compatible with NSS 3.28.1 The difficulty here is the timing, and it's a conflict between "don't break applications in Fedora" and "ship new Firefox security update as soon as possible". If we start by shipping NSS 3.28.1 first, without yet having fixed the Mozilla applications, then we allow Firefox 51 to be shipped, but we risk that the other applications aren't fixed in time, and that users might see regressions, caused by the upgrade to NSS 3.28.1 Alternatively, if we wait until all affected Mozilla packages have been updated to fixed versions, it might delay the January 24 Firefox 51 update. After discussing this, we have a preference to avoid the breakage in Fedora, and try to ship all required updates as soon as possible. In order to avoid the breakage, we want to add "Conflicts:" statements to the NSS 3.28.1 package, that makes it conflict with all known Mozilla packages that don't contain the required fix yet. The packages we have identified are: - firefox - thunderbird - seamonkey - xulrunner - icecat I see that for all the above packages, build attempts that include the fix are already ongoing in koji, so there's hope that we might be able to resolve the situation in time. However, if ANY of the above build cannot be completed soon, or, if ANY of the updates cannot move to the stable Fedora updates, it can block users from upgrading to the Firefox 51 update on Jan 24. Is that acceptable? Do you agree that we make NSS conflict with any known incompatible packages mentioned above, and thereby may inhibit a subset of Fedora users from upgrading to Firefox 51 immediately? If we can get all the above builds done quickly, and all of them pushed to Fedora stable updates quickly, we're good. Note that we have the remaining risk that we haven't identified all Mozilla packages that might be affected. The relevant code isn't in NSS, but in Mozilla's network code. That means, if the above list of packages isn't the complete set of affected Mozilla based applications, other packages might still experience the connectivity regression. But as soon as another package is identified, it can rebuild to pick up the mentioned fix. Is bundling the newer NSS release inside of firefox itself an option? While it may not be the best long-term solution and we all know the downsides of bundling, it is at least pragmatic in the short-term. That would allow firefox to ship and time for the remaining packages to be updated. Once they're ready, the bundling in firefox could be dropped and an update with all the packages could be done. All builds are ready except TB on arm. I'm sure we make that in time. Martin josh ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
[Bug 1406558] build perl-Coro for EPEL7
https://bugzilla.redhat.com/show_bug.cgi?id=1406558 Bug 1406558 depends on bug 1408625, which changed state. Bug 1408625 Summary: build perl-BDB for EPEL7 https://bugzilla.redhat.com/show_bug.cgi?id=1408625 What|Removed |Added Status|ON_QA |CLOSED Resolution|--- |ERRATA -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-de...@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
[Bug 1408623] build perl-AnyEvent-AIO for EPEL7
https://bugzilla.redhat.com/show_bug.cgi?id=1408623 Fedora Update System changed: What|Removed |Added Status|ON_QA |CLOSED Fixed In Version||perl-AnyEvent-AIO-1.1-20.el ||7 Resolution|--- |ERRATA Last Closed||2017-01-20 10:20:28 --- Comment #5 from Fedora Update System --- perl-AnyEvent-AIO-1.1-20.el7 has been pushed to the Fedora EPEL 7 stable repository. If problems still persist, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-de...@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
ClipIt
Hi, somebody do not take the package ClipIt . ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Important: NSS + Firefox + Thunderbird + Seamonkey + Icecat + Xulrunner
On Fri, 2017-01-20 at 16:17 +0100, Martin Stransky wrote: > All builds are ready except TB on arm. I'm sure we make that in time. > > Martin Please just make sure they all get released in the same Bodhi update to avoid breakage. Michael ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F26 Self Contained Change: Transdiff
Hello, Sundeep. On Thursday, 12 January 2017 at 08:03, pravin@gmail.com wrote: > On 10 January 2017 at 16:31, Dominik 'Rathann' Mierzejewski < > domi...@greysector.net> wrote: > > > On Tuesday, 10 January 2017 at 09:39, Jan Kurik wrote: > > > = Proposed Self Contained Change: Transdiff = > > > https://fedoraproject.org/wiki/Changes/Transdiff > > > > > > Change owner(s): > > > *Sundeep Anand > > > > > > Often even after 100% translation in Zanata, few packages do not get > > > build with latest translations in Fedora. This result in poor > > > localization experience. Transdiff is a python program to run on > > > products installations for tracking translations with project upstream > > > and generate diff reports. > > > > Nice. On the wiki page, you (Sundeep) also mention automation. > > Where do you see this in our packaging pipeline? > > > > As a taskotron check? A regular report mailed to the devel list? > > Good point. While discussing on string breakage monitoring we discussed > this idea as well. > Yeah, taskotron is good fit for uses of transdiff, so rather than post > installation of translation, we will have this check in Bodhi itself. Could you update the proposal with the conclusions from this thread and also, more importantly, answer my question? Why does this need to be a Change? Regards, Dominik -- Fedora http://fedoraproject.org/wiki/User:Rathann RPMFusion http://rpmfusion.org "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: ClipIt
On Fri, 2017-01-20 at 15:50 +, mastaiza wrote: > Hi, somebody do not take the package ClipIt . de...@lists.deforaproject.org is not appropriate place for such messages. -- -Igor Gnatenko ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Important: NSS + Firefox + Thunderbird + Seamonkey + Icecat + Xulrunner
On pe, 20 tammi 2017, Kai Engert wrote: Hello, we are currently dealing with a tricky situation, that the NSS and Mozilla package maintainers have been discussing, and I'd like to publish our plan. The most recent NSS update, version 3.28.1, is required to ship to the Firefox 51 update planned for January 24. Unfortunately, NSS 3.28.1 is incompatible with Mozilla applications version 50 and older. If Mozilla 50 or older is used together with NSS 3.28 or newer, and the application attempts to use HTTP v2, the connections to some servers may fail (including connections to Google servers). The fix is simple, it's possible to apply a small patch to the older Mozilla applications, to make it compatible with NSS 3.28.1 The difficulty here is the timing, and it's a conflict between "don't break applications in Fedora" and "ship new Firefox security update as soon as possible". If we start by shipping NSS 3.28.1 first, without yet having fixed the Mozilla applications, then we allow Firefox 51 to be shipped, but we risk that the other applications aren't fixed in time, and that users might see regressions, caused by the upgrade to NSS 3.28.1 Alternatively, if we wait until all affected Mozilla packages have been updated to fixed versions, it might delay the January 24 Firefox 51 update. After discussing this, we have a preference to avoid the breakage in Fedora, and try to ship all required updates as soon as possible. In order to avoid the breakage, we want to add "Conflicts:" statements to the NSS 3.28.1 package, that makes it conflict with all known Mozilla packages that don't contain the required fix yet. The packages we have identified are: - firefox - thunderbird - seamonkey - xulrunner - icecat I see that for all the above packages, build attempts that include the fix are already ongoing in koji, so there's hope that we might be able to resolve the situation in time. FreeIPA is broken when trying to install with nss 3.28.1. We reliably reproduce this issue with https://bodhi.fedoraproject.org/updates/FEDORA-2017-e42b513012 It seems that new nss also breaks 389-ds LDAP server's selection of available ciphers. As result, ldapsearch does not work against the 389-ds LDAP server configured as part of FreeIPA deployment. However, if ANY of the above build cannot be completed soon, or, if ANY of the updates cannot move to the stable Fedora updates, it can block users from upgrading to the Firefox 51 update on Jan 24. Is that acceptable? I think failing server applications is unacceptable. Do you agree that we make NSS conflict with any known incompatible packages mentioned above, and thereby may inhibit a subset of Fedora users from upgrading to Firefox 51 immediately? If we can get all the above builds done quickly, and all of them pushed to Fedora stable updates quickly, we're good. Note that we have the remaining risk that we haven't identified all Mozilla packages that might be affected. The relevant code isn't in NSS, but in Mozilla's network code. That means, if the above list of packages isn't the complete set of affected Mozilla based applications, other packages might still experience the connectivity regression. But as soon as another package is identified, it can rebuild to pick up the mentioned fix. Thanks Kai PS: Tracking bug is here: https://bugzilla.redhat.com/show_bug.cgi?id=1381400 (Don't get confused with the separate, unrelated discussion on TLS 1.3) An example of the regression is here: https://bugzilla.redhat.com/show_bug.cgi?id=1414929 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org -- / Alexander Bokovoy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Summary/Minutes from today's FESCo Meeting (2017-01-20)
=== #fedora-meeting: FESCO (2017-01-20) === Meeting started by nirik at 16:00:05 UTC. The full logs are available at https://meetbot.fedoraproject.org/fedora-meeting/2017-01-20/fesco.2017-01-20-16.00.log.html . Meeting summary --- * init process (nirik, 16:00:05) * #1635 F26 Self Contained Changes (nirik, 16:04:33) * LINK: https://pagure.io/fesco/issue/1635 (nirik, 16:04:33) * AGREED: Fontconfig cache directory change approved (+7,0,0) (nirik, 16:10:54) * AGREED: Automated AMI test and release change is approved (+8,0,0) (nirik, 16:21:05) * AGREED: will wait a week for more discussion on Transdiff. (+7,0,0) (nirik, 16:24:25) * #1665 Unresponsive maintainer: affix (nirik, 16:24:37) * LINK: https://pagure.io/fesco/issue/1665 (nirik, 16:24:37) * LINK: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/XOX7WLYKUY2LZ6H7M3WPEUF7ZON3HU2K/ (dgilmore, 16:26:40) * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=1145830 (dgilmore, 16:27:42) * LINK: https://pagure.io/fesco/issue/1479 (dgilmore, 16:28:04) * AGREED: will orphan affixes packages (+7,0,0) (nirik, 16:29:24) * #1668 F26 System Wide Change: GCC7 (nirik, 16:29:38) * LINK: https://pagure.io/fesco/issue/1668 (nirik, 16:29:38) * AGREED: GCC7 change is approved (+7,0,0) (nirik, 16:32:14) * #1669 F26 System Wide Change: Parallel Installable Debuginfo (nirik, 16:32:22) * LINK: https://pagure.io/fesco/issue/1669 (nirik, 16:32:22) * AGREED: Parallel Installable Debuginfo Change is approved (+7,0,0) (nirik, 16:35:27) * Next week's chair (nirik, 16:37:12) * people traveling next week so no meeting on 2017-01-27 (nirik, 16:40:03) * sgallagh will chair the 2017-02-03 meeting (nirik, 16:40:17) * LINK: https://pagure.io/fesco/issues (nirik, 16:41:05) * Open Floor (nirik, 16:42:20) Meeting ended at 16:45:26 UTC. Action Items Action Items, by person --- * **UNASSIGNED** * (none) People Present (lines said) --- * nirik (79) * dgilmore (40) * sgallagh (22) * Rathann (20) * kalev (16) * zodbot (15) * jsmith (14) * jforbes (9) * maxamillion (9) * ignatenkobrain (4) * jwb (0) -- 16:00:05 #startmeeting FESCO (2017-01-20) 16:00:05 Meeting started Fri Jan 20 16:00:05 2017 UTC. The chair is nirik. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:00:05 Useful Commands: #action #agreed #halp #info #idea #link #topic. 16:00:05 The meeting name has been set to 'fesco_(2017-01-20)' 16:00:05 #meetingname fesco 16:00:05 The meeting name has been set to 'fesco' 16:00:05 #chair maxamillion dgilmore jwb nirik jforbes jsmith kalev sgallagh Rathann 16:00:05 Current chairs: Rathann dgilmore jforbes jsmith jwb kalev maxamillion nirik sgallagh 16:00:05 #topic init process 16:00:11 hi 16:00:19 who all is around? :) 16:00:20 .hello maxamillion 16:00:21 maxamillion: maxamillion 'Adam Miller' 16:00:25 .hello jforbes 16:00:27 jforbes: jforbes 'Justin M. Forbes' 16:00:28 hi everyone 16:00:49 sgallagh said he would be a few min late. 16:02:10 .hello rathann 16:02:10 * nirik waits for at least one more 16:02:11 Rathann: rathann 'Dominik Mierzejewski' 16:04:05 .hello sgallagh 16:04:06 sgallagh: sgallagh 'Stephen Gallagher' 16:04:24 alrighty. Thats 5, so lets go ahead and start. ;) 16:04:33 #topic #1635 F26 Self Contained Changes 16:04:33 .fesco 1635 16:04:33 https://pagure.io/fesco/issue/1635 16:04:35 nirik: Issue #1635: F26 Self Contained Changes - fesco - Pagure - https://pagure.io/fesco/issue/1635 16:04:40 .hello jsmith 16:04:41 jsmith: jsmith 'Jared Smith' 16:04:42 Sorry I'm late 16:04:43 there's several of these, shall we do them one at a time? 16:04:47 no worries 16:04:53 hola 16:04:58 Do we want to cover the fontconfig one separately? 16:05:02 (First, or later?) 16:05:06 sure, lets do it first 16:05:15 sgallagh: you talked with folks about that? 16:05:22 Yes, see the comment in the ticket 16:05:28 yeah. 16:05:28 I can summarize here, though. 16:05:57 if you like. I'm +1 at this point 16:06:00 The short version is that I think the primary confusion in the debate is the word "cache" and the different participants' definitions thereof. 16:06:12 * kalev appears in a poof of magic. 16:06:14 sorry guys, a bit late here 16:06:15 I read the summary in the ticket, +1 here as well 16:06:16 yes, it makes sense now 16:06:33 +1 from me too, makes a lot of sense now 16:06:36 thanks sgallagh for checking it 16:06:37 +1 to the fontconfig index from me 16:06:40 is the index portable between arches? 16:06:42 +1 here as well 16:06:53 if yes, then perhaps /usr/share/fontconfig would be a better location 16:07:15 while not ideal ostree could run fc-cache on boot for changes 16:07:23 but that data can be moved 16:07:41 dgilmore: I suggested that as well, but t
Re: ClipIt
where to write ? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Important: NSS + Firefox + Thunderbird + Seamonkey + Icecat + Xulrunner
On pe, 20 tammi 2017, Hubert Kario wrote: On Friday, 20 January 2017 18:40:13 CET Alexander Bokovoy wrote: On pe, 20 tammi 2017, Kai Engert wrote: >Hello, > >we are currently dealing with a tricky situation, that the NSS and Mozilla >package maintainers have been discussing, and I'd like to publish our plan. > >The most recent NSS update, version 3.28.1, is required to ship to the >Firefox 51 update planned for January 24. > >Unfortunately, NSS 3.28.1 is incompatible with Mozilla applications version >50 and older. > >If Mozilla 50 or older is used together with NSS 3.28 or newer, and the >application attempts to use HTTP v2, the connections to some servers may >fail (including connections to Google servers). > >The fix is simple, it's possible to apply a small patch to the older >Mozilla applications, to make it compatible with NSS 3.28.1 > >The difficulty here is the timing, and it's a conflict between "don't break >applications in Fedora" and "ship new Firefox security update as soon as >possible". > >If we start by shipping NSS 3.28.1 first, without yet having fixed the >Mozilla applications, then we allow Firefox 51 to be shipped, but we risk >that the other> > applications aren't fixed in time, and that users might see regressions, > caused> >by the upgrade to NSS 3.28.1 > >Alternatively, if we wait until all affected Mozilla packages have been >updated to fixed versions, it might delay the January 24 Firefox 51 >update. > >After discussing this, we have a preference to avoid the breakage in >Fedora, and try to ship all required updates as soon as possible. > >In order to avoid the breakage, we want to add "Conflicts:" statements to >the NSS 3.28.1 package, that makes it conflict with all known Mozilla >packages that don't contain the required fix yet. > >The packages we have identified are: >- firefox >- thunderbird >- seamonkey >- xulrunner >- icecat > >I see that for all the above packages, build attempts that include the fix >are already ongoing in koji, so there's hope that we might be able to >resolve the situation in time. FreeIPA is broken when trying to install with nss 3.28.1. We reliably reproduce this issue with https://bodhi.fedoraproject.org/updates/FEDORA-2017-e42b513012 It seems that new nss also breaks 389-ds LDAP server's selection of available ciphers. As result, ldapsearch does not work against the 389-ds LDAP server configured as part of FreeIPA deployment. openldap issue is different than Firefox issue, the former is caused by combination of buggy code in openldap and draft version of TLSv1.3 being available in NSS while the latter is caused by addition of X25519 curve for ECDHE. We've already discussed the issues in openldap with Christian Heimes, Marin Babinsky and Matus Honek. We will also be temporarily disabling TLSv1.3 in NSS. The particulars bugs are: https://bugzilla.redhat.com/show_bug.cgi?id=1243517 https://bugzilla.redhat.com/show_bug.cgi?id=1387868 Thanks, Hubert. I assume these fixes will be part of the 3.28.1 you are preparing for Firefox 51? -- / Alexander Bokovoy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F26 Self Contained Change: Making sudo pip Safe (Again)
On Fri, 2017-01-20 at 12:07 +0100, Jan Kurik wrote:
> = Proposed Self Contained Change: Making sudo pip Safe (Again) =
> https://fedoraproject.org/wiki/Changes/Making_sudo_pip_safe
>
> Change owner(s):
> * Michal Cyprian
> * Petr Viktorin
> * Tomas Orsava
> * Miro Hroncok
>
>
> At the present time, running sudo pip3 in Fedora is not safe. Pip
> shares its installation directory with dnf, can remove dnf-managed
> files and generally break the Python 3 interpreter. We propose a
> series of measures that will make it safe to use.
>
>
> == Detailed Description ==
> The danger of using sudo pip3 stems from the fact that both Python dnf
> packages and sudo pip3 install modules to the same location, namely
> /usr/lib/pythonX.Y/site-packages.
>
> We aim to move the working directory for sudo pip3 to a more
> appropriate location: /usr/local/lib/pythonX.Y/site-packages, and
> modify the Python 3 interpreter in Fedora to scan both above mentioned
> locations when importing modules.
This might also mean that we start using Python modules installed from
self-compiled applications, which might not be intended (we do not
include /usr/local/lib(64) in the default ldconfig path, AFAIK).
> In addition, system-python—a
> stripped down version of Python 3 for use by system tools—will not
> read the sudo pip3 install location, making it more secure by being
> less susceptible to interference by user-downloaded modules.
>
> From the technical standpoint, this will be accomplished by changing
> the sys.prefix setting in the /usr/bin/python3 executable from /usr/
> to /usr/local. pip3 will thereafter use this prefix when determining
> where to install modules.
This seems like quite a significant change. Have you investigated any
potential unexpected consequences of this? Do setuptools etc. use this
setting in any way? Have you checked for existing code reading it for
any reason? Have you checked what else Python itself uses it for, and
if any of that could be negatively affected?
> In addition, the original path
> /usr/lib/pythonX.Y/site-packages will be added to the sys.path
> variable (so that modules at that location are still processed when
> importing), because this path will not be automatically scanned
> anymore as it no longer lies inside the sys.prefix path. These
> settings, however, will not be modified for the system-python binary,
> and the %{__python3} macro will be changed from /usr/bin/python3 to
> /usr/libexec/system-python. Therefore, Python dnf packages will
> continue to be built with the correct installation path for system
> modules.
> Note that using sudo pip3 is not strictly necessary, as using pip3
> install --user would satisfy the vast majority of use cases.
> Nevertheless, sudo pip is far too prevalent an instruction in various
> guides and installation notes throughout the Internet that there is
> little hope of changing users' behaviour in this regard.
Presumably this change is applied only to Python 3 because there is no
'system-python-2'?
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F26 Self Contained Change: Making sudo pip Safe (Again)
On Fri, 2017-01-20 at 09:12 -0800, Adam Williamson wrote: > On Fri, 2017-01-20 at 12:07 +0100, Jan Kurik wrote: > > = Proposed Self Contained Change: Making sudo pip Safe (Again) = > > https://fedoraproject.org/wiki/Changes/Making_sudo_pip_safe > > > > Change owner(s): > > * Michal Cyprian > > * Petr Viktorin > > * Tomas Orsava > > * Miro Hroncok > > > > > > At the present time, running sudo pip3 in Fedora is not safe. Pip > > shares its installation directory with dnf, can remove dnf-managed > > files and generally break the Python 3 interpreter. We propose a > > series of measures that will make it safe to use. > > > > > > == Detailed Description == > > The danger of using sudo pip3 stems from the fact that both Python > > dnf packages and sudo pip3 install modules to the same location, > > namely /usr/lib/pythonX.Y/site-packages. > > > > We aim to move the working directory for sudo pip3 to a more > > appropriate location: /usr/local/lib/pythonX.Y/site-packages, and > > modify the Python 3 interpreter in Fedora to scan both above > > mentioned locations when importing modules. > > This might also mean that we start using Python modules installed > from self-compiled applications, which might not be intended (we do > not include /usr/local/lib(64) in the default ldconfig path, AFAIK). In addition to that, if someone compiles and installs their own Python, it goes into /usr/local by default. (with the typical ./configure && make && make install) Which means that its modules would go into /usr/local/lib/pythonX.Y/site-packages. The suggested change means that the system Python would use the modules intended for that local Python. (if they are the same version) -- Mathieu ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Is there something wrong with the Koji builders?
On 01/16/2017 09:16 AM, Kevin Fenzi wrote: > > Yes, there's been ongoing issues since last week: > > * This issue (which seems new in the last few days) where srpm isn't > unpacking correctly. > https://pagure.io/fedora-infrastructure/issue/5694 Still seeing this: https://koji.fedoraproject.org/koji/taskinfo?taskID=17332860 -- Orion Poplawski Technical Manager 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F26 Self Contained Change: Making sudo pip Safe (Again)
> "JK" == Jan Kurik writes: JK> We aim to move the working directory for sudo pip3 to a more JK> appropriate location: /usr/local/lib/pythonX.Y/site-packages, and JK> modify the Python 3 interpreter in Fedora to scan both above JK> mentioned locations when importing modules. I wanted to point out a potential caveat with using /usr/local for things; some sites manage things under there in ways you can't really predict. For example, all of my machines used to rsync the entire /usr/local tree from a master host. Before that, it was an NFS mount. However, I no longer do that and I don't think Fedora would ever actually ship anything under /usr/local besides the few directories that the filesystem package creates, so I'm certainly not going to object. I did, however, want make sure folks were aware that we should be careful not to assume too much about the structure of /usr/local. - J< ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Rawhide-20170120.n.0 compose check report
Missing expected images: Cloud_base qcow2 x86_64 Atomic qcow2 x86_64 Cloud_base raw-xz x86_64 Xfce raw-xz armhfp Atomic raw-xz x86_64 Failed openQA tests: 21/107 (x86_64), 18/18 (i386), 1/2 (arm) New failures (same test did not fail in Rawhide-20170119.n.0): ID: 55308 Test: x86_64 Everything-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/55308 ID: 55314 Test: x86_64 Workstation-live-iso base_services_start URL: https://openqa.fedoraproject.org/tests/55314 ID: 55317 Test: x86_64 Workstation-live-iso desktop_update_graphical URL: https://openqa.fedoraproject.org/tests/55317 ID: 55319 Test: x86_64 Workstation-live-iso desktop_browser URL: https://openqa.fedoraproject.org/tests/55319 ID: 55321 Test: x86_64 Workstation-live-iso desktop_notifications_postinstall URL: https://openqa.fedoraproject.org/tests/55321 ID: 55327 Test: i386 Workstation-boot-iso memory_check URL: https://openqa.fedoraproject.org/tests/55327 ID: 55337 Test: x86_64 KDE-live-iso desktop_browser URL: https://openqa.fedoraproject.org/tests/55337 Old failures (same test failed in Rawhide-20170119.n.0): ID: 55290 Test: x86_64 Server-dvd-iso install_repository_nfs_variation URL: https://openqa.fedoraproject.org/tests/55290 ID: 55292 Test: x86_64 Server-dvd-iso server_role_deploy_domain_controller URL: https://openqa.fedoraproject.org/tests/55292 ID: 55294 Test: x86_64 Server-dvd-iso server_cockpit_default URL: https://openqa.fedoraproject.org/tests/55294 ID: 55298 Test: x86_64 Server-dvd-iso server_role_deploy_database_server URL: https://openqa.fedoraproject.org/tests/55298 ID: 55302 Test: x86_64 Server-dvd-iso base_services_start URL: https://openqa.fedoraproject.org/tests/55302 ID: 55306 Test: i386 Server-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/55306 ID: 55307 Test: i386 Server-dvd-iso install_default URL: https://openqa.fedoraproject.org/tests/55307 ID: 55310 Test: i386 Everything-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/55310 ID: 55322 Test: x86_64 Workstation-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/55322 ID: 55325 Test: x86_64 Workstation-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/55325 ID: 55326 Test: i386 Workstation-live-iso install_default URL: https://openqa.fedoraproject.org/tests/55326 ID: 55328 Test: i386 Workstation-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/55328 ID: 55332 Test: x86_64 KDE-live-iso base_services_start URL: https://openqa.fedoraproject.org/tests/55332 ID: 55335 Test: x86_64 KDE-live-iso desktop_update_graphical URL: https://openqa.fedoraproject.org/tests/55335 ID: 55339 Test: x86_64 KDE-live-iso desktop_notifications_postinstall URL: https://openqa.fedoraproject.org/tests/55339 ID: 55340 Test: i386 KDE-live-iso install_default URL: https://openqa.fedoraproject.org/tests/55340 ID: 55341 Test: arm Minimal-raw_xz-raw.xz install_arm_image_deployment_upload URL: https://openqa.fedoraproject.org/tests/55341 ID: 55383 Test: x86_64 universal upgrade_kde_64bit URL: https://openqa.fedoraproject.org/tests/55383 ID: 55394 Test: x86_64 universal install_cyrillic_language URL: https://openqa.fedoraproject.org/tests/55394 ID: 55395 Test: x86_64 universal install_asian_language URL: https://openqa.fedoraproject.org/tests/55395 ID: 55400 Test: x86_64 universal install_rescue_encrypted@uefi URL: https://openqa.fedoraproject.org/tests/55400 ID: 55401 Test: i386 universal install_package_set_minimal URL: https://openqa.fedoraproject.org/tests/55401 ID: 55402 Test: i386 universal install_repository_http_graphical URL: https://openqa.fedoraproject.org/tests/55402 ID: 55403 Test: i386 universal install_scsi_updates_img URL: https://openqa.fedoraproject.org/tests/55403 ID: 55404 Test: i386 universal install_simple_encrypted URL: https://openqa.fedoraproject.org/tests/55404 ID: 55405 Test: i386 universal install_software_raid URL: https://openqa.fedoraproject.org/tests/55405 ID: 55406 Test: i386 universal install_btrfs URL: https://openqa.fedoraproject.org/tests/55406 ID: 55407 Test: i386 universal install_ext3 URL: https://openqa.fedoraproject.org/tests/55407 ID: 55408 Test: i386 universal install_lvmthin URL: https://openqa.fedoraproject.org/tests/55408 ID: 55409 Test: i386 universal upgrade_desktop_32bit URL: https://openqa.fedoraproject.org/tests/55409 ID: 55411 Test: i386 universal install_package_set_kde URL: https://openqa.fedoraproject.org/tests/55411 ID: 55413 Test: i386 universal upgrade_2_desktop_32bit URL: https://openqa.fedoraproject.org/tests/55413 ID: 55414 Test: x86_64 universal upgrade_2_kde_64bit URL: https://openqa.fedoraproject.org/tests/55414 Soft failed openQA tests: 52/107 (x86_64) (Tests completed, but using a
Re: Is there something wrong with the Koji builders?
On Fri, 20 Jan 2017 10:22:01 -0700 Orion Poplawski wrote: > On 01/16/2017 09:16 AM, Kevin Fenzi wrote: > > > > Yes, there's been ongoing issues since last week: > > > > * This issue (which seems new in the last few days) where srpm isn't > > unpacking correctly. > > https://pagure.io/fedora-infrastructure/issue/5694 > > Still seeing this: > https://koji.fedoraproject.org/koji/taskinfo?taskID=17332860 You mean you were seeing it back before I fixed it. ;) Please retry any builds that were before 2017-01-20 00:00 UTC. Thats about when the last fix went out, so anything before then wasn't subject to that. kevin pgpCHhTtZ2Myg.pgp Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Important: NSS + Firefox + Thunderbird + Seamonkey + Icecat + Xulrunner
On Fri, 2017-01-20 at 18:40 +0200, Alexander Bokovoy wrote: > > FreeIPA is broken when trying to install with nss 3.28.1. We reliably > reproduce this issue with > https://bodhi.fedoraproject.org/updates/FEDORA-2017-e42b513012 > > It seems that new nss also breaks 389-ds LDAP server's selection of > available ciphers. As result, ldapsearch does not work against the > 389-ds LDAP server configured as part of FreeIPA deployment. > > > However, if ANY of the above build cannot be completed soon, or, if ANY of > > the > > updates cannot move to the stable Fedora updates, it can block users from > > upgrading to the Firefox 51 update on Jan 24. > > > > Is that acceptable? > > I think failing server applications is unacceptable. Alexander, the test of NSS 3.28.1 in Fedora has uncovered multiple issues, and the issue with FreeIPA is a different issue than the one I had explained in this thread. We'll prevent the FreeIPA issue, by disabling the experimental TLS 1.3 support at compile time in the Fedora NSS build, until the FreeIPA team is able to adjust their code to be compatible with TLS 1.3 support being enabled in NSS. Thanks Kai ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Important: NSS + Firefox + Thunderbird + Seamonkey + Icecat + Xulrunner
On Fri, 2017-01-20 at 10:22 -0600, Michael Catanzaro wrote: > On Fri, 2017-01-20 at 16:17 +0100, Martin Stransky wrote: > > All builds are ready except TB on arm. I'm sure we make that in time. > > > > Martin > > Please just make sure they all get released in the same Bodhi update to > avoid breakage. Yes, that's our intention. I see that the Icecat maintainer has already built updated packages for F24 and F25 that include the required patch. In order to create the combined update, I need commit access for all involved packages. The remaining piece are the commit privileges for Icecat. I've requested them, but haven't received them yet. Thanks Kai ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: RFH: Annotating ELF binaries
On 01/20/2017 11:55 AM, H.J. Lu wrote: > We can classify properties into 2 categories: used by run-time loader, > not used by run-time loader. We put properties for run-time loader into > .note.gnu.property section and the rest into GNU attribute section. Agreed. Can we use the same noun/adjective for our names? Is there any reason to use property over attribute? As a Friday bikeshed I suggest: .note.gnu.attributes - GNU Attributes optimized for the dynamic loader. -- New. Follows H.J's proposal. Bit-level, packed, and optimized for the dynamic loader processing. .gnu.attributes - GNU Attributes optimized for offline and static linker processing. -- Existing section. Discussions with Nick ongoing if we can continue to use existing infrastructure e.g. Tag_Range to extend this data. -- Cheers, Carlos. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Important: NSS + Firefox + Thunderbird + Seamonkey + Icecat + Xulrunner
On 01/20/2017 12:15 PM, Kai Engert wrote: In order to create the combined update, I need commit access for all involved packages. The remaining piece are the commit privileges for Icecat. I've requested them, but haven't received them yet. If we're under a time constraint I'm sure a provenpackager would be willing to create the update for you. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Important: NSS + Firefox + Thunderbird + Seamonkey + Icecat + Xulrunner
On Fri, 2017-01-20 at 13:12 -0600, Michael Cronenworth wrote: > On 01/20/2017 12:15 PM, Kai Engert wrote: > > In order to create the combined update, I need commit access for all > > involved > > packages. The remaining piece are the commit privileges for Icecat. I've > > requested them, but haven't received them yet. > > If we're under a time constraint I'm sure a provenpackager would be willing > to > create the update for you. I've been granted the required permissions. (Note that provenpackagers don't have access to firefox, I've been told, so their powers wouldn't have been sufficient.) Thanks! Kai ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Important: NSS + Firefox + Thunderbird + Seamonkey + Icecat + Xulrunner
On 01/20/2017 01:16 PM, Kai Engert wrote: I've been granted the required permissions. Good. (Note that provenpackagers don't have access to firefox, I've been told, so their powers wouldn't have been sufficient.) I'm not aware of that. I pulled up the current Firefox update that is unpushed and I am seeing buttons to push to testing or push to stable. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Important: NSS + Firefox + Thunderbird + Seamonkey + Icecat + Xulrunner
On pe, 20 tammi 2017, Kai Engert wrote: On Fri, 2017-01-20 at 18:40 +0200, Alexander Bokovoy wrote: FreeIPA is broken when trying to install with nss 3.28.1. We reliably reproduce this issue with https://bodhi.fedoraproject.org/updates/FEDORA-2017-e42b513012 It seems that new nss also breaks 389-ds LDAP server's selection of available ciphers. As result, ldapsearch does not work against the 389-ds LDAP server configured as part of FreeIPA deployment. > However, if ANY of the above build cannot be completed soon, or, if ANY of > the > updates cannot move to the stable Fedora updates, it can block users from > upgrading to the Firefox 51 update on Jan 24. > > Is that acceptable? I think failing server applications is unacceptable. Alexander, the test of NSS 3.28.1 in Fedora has uncovered multiple issues, and the issue with FreeIPA is a different issue than the one I had explained in this thread. We'll prevent the FreeIPA issue, by disabling the experimental TLS 1.3 support at compile time in the Fedora NSS build, until the FreeIPA team is able to adjust their code to be compatible with TLS 1.3 support being enabled in NSS. Thanks, Kai. -- / Alexander Bokovoy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
License change in quasselc
Hello, As per policy [1] I'm notifying devel@ that the license of quasselc, a C library implementing the quassel protocol, has changed from GPL v3+ to LGPL v3 [2]. This should only affect the GPLv3+-licensed quassel-irssi (an irssi plugin that uses quasselc), which is by the same upstream author and still compatible with the new license, as quassel-irssi is the only Fedora package depending on quasselc at this time. Ben Rosser [1] https://fedoraproject.org/wiki/Licensing:Main?rd=Licensing#License_Changes [2] https://github.com/phhusson/QuasselC/commit/389419eb1210f13be40bee2d5f3d084473ea4d48 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Fedora Rawhide-20170120.n.0 compose check report
On Fri, 2017-01-20 at 17:33 +, Fedora compose checker wrote: > x86_64 Workstation-boot-iso memory_check peak memory: 717MiB > x86_64 Workstation-boot-iso memory_check@uefi peak memory: 715MiB So this is another shiny new openQA / check-compose feature: there's now a test which just runs an install with the `debug` kernel param, which triggers anaconda to record memory usage throughout the install process, then uploads the usage data file. check-compose then notices jobs which do this, grabs the memory usage data file, and includes the peak usage during installation in the report. Tomorrow, it should include a comparison to today's usage (we don't get the comparison today, because today's the first compose we have the data for). If the usage changes significantly and we want to know why, we can go check the raw data file for more information (I guess I should enhance check-compose to link to it). For the moment we're just running this test on the Workstation boot ISO, as it's likely to be the most memory-intensive install in openQA's set (network installs use more memory than DVD installs, and the Workstation network install has more packages than the Server network install). As for the test results, there is a whole bunch of stuff going on, too much to break out test-by-test. Here are the highlights: 1) There is some kind of systemd bug which essentially means that occasionally, the system boots to emergency mode instead of booting properly. This affects about a half dozen tests every day, on average - never the same ones, the bug is quasi-random, it just...happens sometimes. That's https://bugzilla.redhat.com/show_bug.cgi?id=1414904 . I'm currently trying to pin that one down. 2) There is an AVC that appears on boot on just about all installs of Rawhide at present: https://bugzilla.redhat.com/show_bug.cgi?id=1392161 this causes the large number of soft failures, because many openQA tests now run a check for any AVCs or crash notifications after installation, and if any are found, it's considered a soft failure. 3) All i686 installs (and live image boots...really, Rawhide is just entirely broken on i686) are broken and have been since (IIRC) systemd v232. I think someone pointed me to a bug which may be the cause of this, but I've lost the reference. It's on my list to figure out soon. 4) KDE upgrades are running into a dependency issue: 'kde-runtime- drkonqi-16.08.3-3.fc24.x86_64 requires kde-runtime = 16.08.3-3.fc24, but none of the providers can be installed'. I haven't reported this properly yet, sorry, I should. 5) Russian installs are failing because of an anaconda bug: https://bugzilla.redhat.com/show_bug.cgi?id=1413813 6) The desktop_browser test needs a needle update, I'll take care of that. 7) All the 'check if all services start correctly' tests for various images fail because of this SELinux/systemd issue: https://bugzilla.redhat.com/show_bug.cgi?id=1412750 It occurs to me that we have kind of a recurring story: 'new systemd release lands in Rawhide, stuff breaks because it does stuff SELinux doesn't expect it to'. It might be nice if we could organize some kind of co-ordination between systemd and SELinux folks such that the appropriate SELinux permissions get added *before* the new systemd release lands. Of course, it would make things easier if we could provide upstream systemd with a nice easy way to test their git master on Fedora Rawhide, I guess. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Fedora Rawhide-20170120.n.0 compose check report
Adam Williamson wrote: > 2) There is an AVC that appears on boot on just about all installs of > Rawhide at present: > https://bugzilla.redhat.com/show_bug.cgi?id=1392161 > this causes the large number of soft failures, because many openQA > tests now run a check for any AVCs or crash notifications after > installation, and if any are found, it's considered a soft failure. [snip] > 7) All the 'check if all services start correctly' tests for various > images fail because of this SELinux/systemd issue: > https://bugzilla.redhat.com/show_bug.cgi?id=1412750 > > It occurs to me that we have kind of a recurring story: 'new systemd > release lands in Rawhide, stuff breaks because it does stuff SELinux > doesn't expect it to'. It might be nice if we could organize some kind > of co-ordination between systemd and SELinux folks such that the > appropriate SELinux permissions get added *before* the new systemd > release lands. Of course, it would make things easier if we could > provide upstream systemd with a nice easy way to test their git master > on Fedora Rawhide, I guess. Or, you know, we might actually SOLVE this issue once and for all, by dropping SELinux. SELinux by design keeps second-guessing what programs may want to do, which necessarily breaks when things change. (Only the NSA can think that duplicating knowledge about ALL programs in the distribution in a single central database (single point of failure) can ever scale.) And since patronizing other programs is the only "feature" SELinux is even DESIGNED to provide, we are best off dropping that DoS tool entirely. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Fedora Rawhide-20170120.n.0 compose check report
On Sat, 2017-01-21 at 01:13 +0100, Kevin Kofler wrote: > Adam Williamson wrote: > > 2) There is an AVC that appears on boot on just about all installs of > > Rawhide at present: > > https://bugzilla.redhat.com/show_bug.cgi?id=1392161 > > this causes the large number of soft failures, because many openQA > > tests now run a check for any AVCs or crash notifications after > > installation, and if any are found, it's considered a soft failure. > > [snip] > > 7) All the 'check if all services start correctly' tests for various > > images fail because of this SELinux/systemd issue: > > https://bugzilla.redhat.com/show_bug.cgi?id=1412750 > > > > It occurs to me that we have kind of a recurring story: 'new systemd > > release lands in Rawhide, stuff breaks because it does stuff SELinux > > doesn't expect it to'. It might be nice if we could organize some kind > > of co-ordination between systemd and SELinux folks such that the > > appropriate SELinux permissions get added *before* the new systemd > > release lands. Of course, it would make things easier if we could > > provide upstream systemd with a nice easy way to test their git master > > on Fedora Rawhide, I guess. > > Or, you know, we might actually SOLVE this issue once and for all, by > dropping SELinux. Sorry, I forgot to include a paragraph at the end of my mail: -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Fedora Rawhide-20170120.n.0 compose check report
On Sat, 2017-01-21 at 01:13 +0100, Kevin Kofler wrote: > Only the NSA can think that > duplicating knowledge about ALL programs in the distribution in a single > central database (single point of failure) can ever scale. By the way, this isn't true at all. Most packages can and, these days, are encouraged to ship their own SELinux policies. In Fedora currently, I see: copr-selinux cockpit-selinux drraw-selinux gcl-selinux websvn-selinux totpcgi-selinux vfrnav-selinux dist-git-selinux etc, etc, etc. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: SELinux policy packaging
On 01/20/2017 05:18 PM, Adam Williamson wrote: On Sat, 2017-01-21 at 01:13 +0100, Kevin Kofler wrote: Only the NSA can think that duplicating knowledge about ALL programs in the distribution in a single central database (single point of failure) can ever scale. By the way, this isn't true at all. Most packages can and, these days, are encouraged to ship their own SELinux policies. In Fedora currently, I see: copr-selinux cockpit-selinux drraw-selinux gcl-selinux websvn-selinux totpcgi-selinux vfrnav-selinux dist-git-selinux etc, etc, etc. Really? This is news to me (and I'm on the FPC). I see these drafts: https://fedoraproject.org/wiki/PackagingDrafts/SELinux https://fedoraproject.org/wiki/SELinux_Policy_Modules_Packaging_Draft but that's it. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA DivisionFAX: 303-415-9702 3380 Mitchell Lane or...@cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: SELinux policy packaging
On Fri, 2017-01-20 at 19:48 -0700, Orion Poplawski wrote: > On 01/20/2017 05:18 PM, Adam Williamson wrote: > > On Sat, 2017-01-21 at 01:13 +0100, Kevin Kofler wrote: > > > Only the NSA can think that > > > duplicating knowledge about ALL programs in the distribution in a single > > > central database (single point of failure) can ever scale. > > > > By the way, this isn't true at all. Most packages can and, these days, > > are encouraged to ship their own SELinux policies. In Fedora currently, > > I see: > > > > copr-selinux > > cockpit-selinux > > drraw-selinux > > gcl-selinux > > websvn-selinux > > totpcgi-selinux > > vfrnav-selinux > > dist-git-selinux > > > > etc, etc, etc. > > > > Really? This is news to me (and I'm on the FPC). > > I see these drafts: > https://fedoraproject.org/wiki/PackagingDrafts/SELinux > https://fedoraproject.org/wiki/SELinux_Policy_Modules_Packaging_Draft > > but that's it. Well, I dunno about policy. I was just talking about what I've heard from SELinux maintainers. Last few times I've asked about getting policy extended to cover new things, the suggestion was just to include a policy with the thing. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: SELinux policy packaging
On Jan 20, 2017 21:57, "Adam Williamson" wrote: On Fri, 2017-01-20 at 19:48 -0700, Orion Poplawski wrote: > On 01/20/2017 05:18 PM, Adam Williamson wrote: > > On Sat, 2017-01-21 at 01:13 +0100, Kevin Kofler wrote: > > > Only the NSA can think that > > > duplicating knowledge about ALL programs in the distribution in a single > > > central database (single point of failure) can ever scale. > > > > By the way, this isn't true at all. Most packages can and, these days, > > are encouraged to ship their own SELinux policies. In Fedora currently, > > I see: > > > > copr-selinux > > cockpit-selinux > > drraw-selinux > > gcl-selinux > > websvn-selinux > > totpcgi-selinux > > vfrnav-selinux > > dist-git-selinux > > > > etc, etc, etc. > > > > Really? This is news to me (and I'm on the FPC). > > I see these drafts: > https://fedoraproject.org/wiki/PackagingDrafts/SELinux > https://fedoraproject.org/wiki/SELinux_Policy_Modules_Packaging_Draft > > but that's it. Well, I dunno about policy. I was just talking about what I've heard from SELinux maintainers. Last few times I've asked about getting policy extended to cover new things, the suggestion was just to include a policy with the thing. -- Yes, every app should be self sufficient. Carry your own log rotation rules, SELinux policy, firewall rules, init files. Have a to depend on the merge to central policy file is just not scalable for an ecosystem. Subhendu ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
