Re: CMake help: "install TARGETS given no LIBRARY DESTINATION for shared library target"
Hi, filed a bug about the issue with cmake. https://bugzilla.redhat.com/show_bug.cgi?id=1667306 It seems also to affect a package review. https://bugzilla.redhat.com/show_bug.cgi?id=1563831 Regards, Raphael ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: F30 System-Wide Change proposal: Replace Comps Language Group With Langpacks
On Fri, Jan 18, 2019 at 12:49 AM Zbigniew Jędrzejewski-Szmek < zbys...@in.waw.pl> wrote: > On Wed, Jan 09, 2019 at 02:56:59PM -0500, Ben Cotton wrote: > > Congratulations to the last System-Wide Change proposal of F30! > > > > > https://fedoraproject.org/wiki/Changes/Replace_Comps_Language_Group_With_Langpacks > > > > == Summary == > > Language support groups in Comps file will get replaced by langpacks > > package. With this Change we want meta-packages like langpacks-ja to > > also install required fonts and input-methods for the given language. > > What is the actual benefit of this change? It looks like a nice > cleanup, but apart from that? This Change will benefit to install all the possible language related packages for a given language using langpacks- meta-package. First this Change is important so that once we get single package installation giving needed language support packages we can further work to use this meta-package in gnome-software or in the required Gnome package to install the language support automatically. Also, This will benefit libreoffice package to remove following from its specfile and only test the libreoffice UI rendering for the given default language font(s) using langpacks Requires: font(:lang=) > It seems that 'dnf install group @lang-foo' > is not different from 'dnf install langpack-bar'. > > Right. Currently, the dnf group install command provides more language support packages compared to langpacks- meta-package. Regards, Parag ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Fedora testing-20190118.0 compose check report
No missing expected images. Failed openQA tests: 2/2 (x86_64) ID: 346334 Test: x86_64 AtomicHost-dvd_ostree-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/346334 ID: 346335 Test: x86_64 AtomicHost-dvd_ostree-iso install_default URL: https://openqa.fedoraproject.org/tests/346335 -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Silverblue: install rpm package
On 1/17/19 6:37 AM, arnaud gaboury wrote: I want to install Notable[0]. As it is not yet packaged for fedora, I tried to install it with the rpm package. -- # rpm-ostree install notable-1.1.0.x86_64.rpm error: Importing package notable: Unsupported path: /opt/Notable/LICENSE.electron.txt; See https://github.com/projectatomic/rpm-ostree/issues/233 - Reading the 233 issue does not help me. How can I deal with this issue? How to install this application? Simple answer, you can't. ostree doesn't support packages installing to /opt. There are some workarounds mentioned in that issue, but they are somewhat complicated. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Bug 1593319] CVE-2018-12558 perl-Email-Address: Specially crafted input could cause Denial of Service due to complex parse() method [fedora-all]
https://bugzilla.redhat.com/show_bug.cgi?id=1593319 Fedora Update System changed: What|Removed |Added Fixed In Version|perl-Email-Address-1.912-1. |perl-Email-Address-1.912-1. |fc28|fc28 ||perl-Email-Address-1.912-1. ||fc29 --- Comment #7 from Fedora Update System --- perl-Email-Address-1.912-1.fc29 has been pushed to the Fedora 29 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-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1662884] Upgrade perl-Email-Address to 1.912
https://bugzilla.redhat.com/show_bug.cgi?id=1662884 Fedora Update System changed: What|Removed |Added Fixed In Version|perl-Email-Address-1.912-1. |perl-Email-Address-1.912-1. |fc28|fc28 ||perl-Email-Address-1.912-1. ||fc29 --- Comment #6 from Fedora Update System --- perl-Email-Address-1.912-1.fc29 has been pushed to the Fedora 29 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-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Fedora updates-20190118.0 compose check report
No missing expected images. Failed openQA tests: 2/2 (x86_64) Old failures (same test failed in testing-20190117.0): ID: 346332 Test: x86_64 AtomicHost-dvd_ostree-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/346332 ID: 346333 Test: x86_64 AtomicHost-dvd_ostree-iso install_default URL: https://openqa.fedoraproject.org/tests/346333 -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Bug 1662884] Upgrade perl-Email-Address to 1.912
https://bugzilla.redhat.com/show_bug.cgi?id=1662884 Fedora Update System changed: What|Removed |Added Status|ON_QA |CLOSED Fixed In Version||perl-Email-Address-1.912-1. ||fc28 Resolution|--- |ERRATA Last Closed||2019-01-18 01:37:51 --- Comment #5 from Fedora Update System --- perl-Email-Address-1.912-1.fc28 has been pushed to the Fedora 28 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-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1593319] CVE-2018-12558 perl-Email-Address: Specially crafted input could cause Denial of Service due to complex parse() method [fedora-all]
https://bugzilla.redhat.com/show_bug.cgi?id=1593319 Fedora Update System changed: What|Removed |Added Status|ON_QA |CLOSED Fixed In Version||perl-Email-Address-1.912-1. ||fc28 Resolution|--- |ERRATA Last Closed||2019-01-18 01:37:48 --- Comment #6 from Fedora Update System --- perl-Email-Address-1.912-1.fc28 has been pushed to the Fedora 28 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-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1593318] CVE-2018-12558 perl-Email-Address: Specially crafted input could cause Denial of Service due to complex parse() method
https://bugzilla.redhat.com/show_bug.cgi?id=1593318 Bug 1593318 depends on bug 1593319, which changed state. Bug 1593319 Summary: CVE-2018-12558 perl-Email-Address: Specially crafted input could cause Denial of Service due to complex parse() method [fedora-all] https://bugzilla.redhat.com/show_bug.cgi?id=1593319 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-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[EPEL-devel] Fedora EPEL 6 updates-testing report
The following Fedora EPEL 6 Security updates need testing: Age URL 33 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-b7556983e8 tomcat-7.0.92-1.el6 29 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-a0ddb153b8 game-music-emu-0.6.2-1.el6 10 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-f49d74241e php-horde-Horde-Form-2.0.19-1.el6 7 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-5fba945293 gitolite3-3.6.11-1.el6 7 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-13717fa751 golang-1.11.4-1.el6 The following builds have been pushed to Fedora EPEL 6 updates-testing R-3.5.2-2.el6 nagios-4.4.3-1.el6 Details about builds: R-3.5.2-2.el6 (FEDORA-EPEL-2019-4af4dd7943) A language for data analysis and graphics Update Information: Update R to 3.5.2, update rpy to 2.9.5, rebuild rkward. ChangeLog: * Tue Jan 8 2019 Tom Callaway - 3.5.2-2 - handle pcre2 use/detection * Mon Jan 7 2019 Tom Callaway - 3.5.2-1 - update to 3.5.2 * Fri Dec 7 2018 Tom Callaway - 3.5.1-2 - use absolute path in symlink for latex dir (bz1594102) nagios-4.4.3-1.el6 (FEDORA-EPEL-2019-17b388679b) Host/service/network monitoring program Update Information: Incorporate many fixes from Justin Paulsen THANKS!!! Updates to nagios-4.4.2 which is a major update. Fixes CVE's CVE-2018-13441 CVE-2016-8641 Remove section which unset nagios Fix BZ#1568273 ChangeLog: * Wed Jan 16 2019 Stephen Smoogen - 4.4.3-1 - Incorporate many fixes from Justin Paulsen THANKS!!! - Update to 4.4.3 for CVE fixes - BZ#1661479 - BZ#1661480 - BZ#1665200 - BZ#1665201 - BZ#1665206 - BZ#1665207 - BZ#1665209 - BZ#1665210 - Fix BZ#1666209 Add RuntimeDirectory too systemd * Fri Nov 30 2018 Stephen Smoogen - 4.4.2-3 - Remove systemd startup since built in works properly - Incorporate fixes from patch14 into patch9 * Thu Nov 29 2018 Stephen Smoogen - 4.4.2-2 - Fix init-type and initdir for systemd and sysv * Wed Nov 28 2018 Justin Paulsen 4.4.2-1 - Bumped to version 4.4.2 - Updated patches 0001,0002,0003,0006,0009,0010,0011 to reflect upstream changes - Updates to nagios.spec (this file) to cleanup un-needed elements and adjust/fix as required - As a result of the cleanup I have added a patch nagios-0014-fix-resource.cfg-path.patch * Tue Jul 24 2018 Stephen Smoogen - 4.3.4-13 - Remove section which unset nagios Fix BZ#1568273 - Remove /etc/nagios/conf.d Fix BZ#1504306 - Change perms on dir Fix BZ#1579935 - Close BZ#1273154 - Hopefully Fix BZ#1201849 - Hopefully Fix BZ#1476238 - Hopefully Fix BZ#1494292 * Fri Jul 13 2018 Fedora Release Engineering - 4.3.4-12 - Rebuilt for https://fedoraproject.org/wiki/Fedora_29_Mass_Rebuild * Thu Jun 28 2018 Jitka Plesnikova - 4.3.4-11 - Perl 5.28 rebuild * Thu Apr 26 2018 Stephen Smoogen - 4.3.4-10 - Fix systemd failures due to old versioning. * Tue Feb 20 2018 Stephen Smoogen - 4.3.4-9 - Add buildrequires for gcc * Thu Feb 8 2018 Fedora Release Engineering - 4.3.4-8 - Rebuilt for https://fedoraproject.org/wiki/Fedora_28_Mass_Rebuild References: [ 1 ] Bug #1661479 - CVE-2018-18245 nagios: Stored XSS via Plugin Output [fedora-all] https://bugzilla.redhat.com/show_bug.cgi?id=1661479 [ 2 ] Bug #1661480 - CVE-2018-18245 nagios: Stored XSS via Plugin Output [epel-all] https://bugzilla.redhat.com/show_bug.cgi?id=1661480 [ 3 ] Bug #1665200 - CVE-2018-13441 nagios: NULL pointer dereference in qh_help in base/query-handler.c [fedora-all] https://bugzilla.redhat.com/show_bug.cgi?id=1665200 [ 4 ] Bug #1665201 - CVE-2018-13441 nagios: NULL pointer dereference in qh_help in base/query-handler.c [epel-all] https://bugzilla.redhat.com/show_bug.cgi?id=1665201 [ 5 ] Bug #1665206 - CVE-2018-13457 nagios: NULL pointer dereference in qh_echo in base/query-handler.c [fedora-all] https://bugzilla.redhat.com/show_bug.cgi?id=1665206 [ 6 ] Bug #1665207 - CVE-2018-13457 nagios: NULL pointer dereference in qh_echo in base/query-handler.c [epel-all] https://bugzilla.redhat.com/show_bug.cgi?id=1665207 [ 7 ] Bug #1665209 - CVE-2018-13458 nagios: NULL pointer dereference in qh_core in base/query-handler.c [fedora-all] https://bugzilla.redhat.com/show_bug.cgi?id=1665209 [ 8 ] Bug #1665210 - CVE-2018-13458 nagios: NULL pointer
[EPEL-devel] Fedora EPEL 7 updates-testing report
The following Fedora EPEL 7 Security updates need testing: Age URL 172 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-f9d6ff695a bibutils-6.6-1.el7 ghc-hs-bibutils-6.6.0.0-1.el7 pandoc-citeproc-0.3.0.1-4.el7 156 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-3c9292b62d condor-8.6.11-1.el7 30 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-b6fa6cebc3 game-music-emu-0.6.2-1.el7 27 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-b43fdd19c3 vcftools-0.1.16-1.el7 14 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-6c3fb8b090 chromium-71.0.3578.98-2.el7 9 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-8e5fe375cf php-horde-Horde-Form-2.0.19-1.el7 9 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-01cf520c0b python-django-1.11.18-1.el7 7 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-4d365dad3c gitolite3-3.6.11-1.el7 7 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-7c5121f71d golang-1.11.4-1.el7 6 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-a6100f3df6 nodejs-6.16.0-1.el7 The following builds have been pushed to Fedora EPEL 7 updates-testing R-3.5.2-2.el7 cacti-1.2.0-1.el7 cacti-spine-1.2.0-2.el7 htop-2.2.0-3.el7 java-openjdk-11.0.1.13-11.rolling.el7 nagios-4.4.3-1.el7 python-kubernetes-8.0.0-6.el7 Details about builds: R-3.5.2-2.el7 (FEDORA-EPEL-2019-5d7bdd9b62) A language for data analysis and graphics Update Information: Update R to 3.5.2, update rpy to 2.9.5, rebuild rkward. ChangeLog: * Tue Jan 8 2019 Tom Callaway - 3.5.2-2 - handle pcre2 use/detection * Mon Jan 7 2019 Tom Callaway - 3.5.2-1 - update to 3.5.2 * Fri Dec 7 2018 Tom Callaway - 3.5.1-2 - use absolute path in symlink for latex dir (bz1594102) cacti-1.2.0-1.el7 (FEDORA-EPEL-2019-17b3c81533) An rrd based graphing tool Update Information: - Rebase to 1.2.0 Release notes: https://www.cacti.net/release_notes.php?version=1.2.0 ChangeLog: * Thu Jan 17 2019 Morten Stevens - 1.2.0-1 - Rebase to 1.2.0 - Multiple cross-site scripting vulnerabilities fixed in 1.2.0 - CVE-2018-20723, CVE-2018-20724, CVE-2018-20725, CVE-2018-20726 (#1667024) References: [ 1 ] Bug #1667024 - CVE-2018-20723 CVE-2018-20724 CVE-2018-20725 CVE-2018-20726 cacti: Multiple cross-site scripting vulnerabilities fixed in 1.2.0 version [epel-all] https://bugzilla.redhat.com/show_bug.cgi?id=1667024 cacti-spine-1.2.0-2.el7 (FEDORA-EPEL-2019-17b3c81533) Threaded poller for Cacti written in C Update Information: - Rebase to 1.2.0 Release notes: https://www.cacti.net/release_notes.php?version=1.2.0 ChangeLog: * Sun Jan 6 2019 Morten Stevens - 1.2.0-2 - Use spine.conf as default * Thu Jan 3 2019 Morten Stevens - 1.2.0-1 - Update to 1.2.0 References: [ 1 ] Bug #1667024 - CVE-2018-20723 CVE-2018-20724 CVE-2018-20725 CVE-2018-20726 cacti: Multiple cross-site scripting vulnerabilities fixed in 1.2.0 version [epel-all] https://bugzilla.redhat.com/show_bug.cgi?id=1667024 htop-2.2.0-3.el7 (FEDORA-EPEL-2019-daaed9cb91) Interactive process viewer Update Information: fix crash when launched with '-s' flag ChangeLog: * Wed Jan 16 2019 Mukundan Ragavan - 2.2.0-3 - Fix crash when launched with "-s" flag (bug# 1666551) * Fri Jul 13 2018 Fedora Release Engineering - 2.2.0-2 - Rebuilt for https://fedoraproject.org/wiki/Fedora_29_Mass_Rebuild References: [ 1 ] Bug #1666551 - htop -s is causing segmentation fault
[Bug 1593320] CVE-2018-12558 perl-Email-Address: Specially crafted input could cause Denial of Service due to complex parse() method [epel-6]
https://bugzilla.redhat.com/show_bug.cgi?id=1593320 Fedora Update System changed: What|Removed |Added Status|ON_QA |CLOSED Fixed In Version||perl-Email-Address-1.912-1. ||el6 Resolution|--- |ERRATA Last Closed||2019-01-18 00:34:58 --- Comment #4 from Fedora Update System --- perl-Email-Address-1.912-1.el6 has been pushed to the Fedora EPEL 6 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-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1268777] CVE-2015-7686 perl-Email-Address: denial of service when parsing crafted email address list
https://bugzilla.redhat.com/show_bug.cgi?id=1268777 Bug 1268777 depends on bug 1268779, which changed state. Bug 1268779 Summary: CVE-2015-7686 perl-Email-Address: denial of service when parsing crafted email address list [epel-all] https://bugzilla.redhat.com/show_bug.cgi?id=1268779 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-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1593318] CVE-2018-12558 perl-Email-Address: Specially crafted input could cause Denial of Service due to complex parse() method
https://bugzilla.redhat.com/show_bug.cgi?id=1593318 Bug 1593318 depends on bug 1593320, which changed state. Bug 1593320 Summary: CVE-2018-12558 perl-Email-Address: Specially crafted input could cause Denial of Service due to complex parse() method [epel-6] https://bugzilla.redhat.com/show_bug.cgi?id=1593320 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-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1268779] CVE-2015-7686 perl-Email-Address: denial of service when parsing crafted email address list [epel-all]
https://bugzilla.redhat.com/show_bug.cgi?id=1268779 Fedora Update System changed: What|Removed |Added Status|ON_QA |CLOSED Fixed In Version||perl-Email-Address-1.912-1. ||el6 Resolution|--- |ERRATA Last Closed||2019-01-18 00:35:01 --- Comment #4 from Fedora Update System --- perl-Email-Address-1.912-1.el6 has been pushed to the Fedora EPEL 6 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-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
soname change - libqalculate
libqalculate soname bump is happening with v2.8.2. The following packages are affected - plasma-workspace step cantor qalculate-kde I will rebuild these packages and file bug reports if needed. Mukundan. signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: CMake help: "install TARGETS given no LIBRARY DESTINATION for shared library target"
On Thu, Jan 17, 2019 16:41:42 -0700, Orion Poplawski wrote:
> On 1/17/19 7:08 AM, Ankur Sinha wrote:
> Just pass the extra options to %cmake. But be sure to use "%cmake" and not
> "%{cmake}". See
> https://src.fedoraproject.org/rpms/vtk/blob/master/f/vtk.spec#_675 for
> example.
OK--that's slightly simpler, but now I have another query:
Not all of them are "extra" options. Some of the options included in the
%cmake macro must be changed. Is this documented cmake behaviour that
options defined later in the argument list will overwrite the earlier
defined ones? Or is this something that "works" now but isn't documented
as correct/suggested usage?
For example, as you've done here:
https://src.fedoraproject.org/rpms/vtk/blob/master/f/vtk.spec#_692
--
Thanks,
Regards,
Ankur Sinha "FranciscoD"
https://fedoraproject.org/wiki/User:Ankursinha
Time zone: Europe/London
signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: CMake help: "install TARGETS given no LIBRARY DESTINATION for shared library target"
On 1/17/19 7:08 AM, Ankur Sinha wrote:
> On Thu, Jan 17, 2019 14:07:44 +0100, Kevin Kofler wrote:
>> Ankur Sinha wrote:
>>> [1] https://github.com/sanjayankur31/rpm-specs/blob/arbor/arbor.spec#L107
>>
>> Any reason why you are not using the %cmake RPM macro?
>
> I need to build the package with MPI also (mpich/openmpi) and the %cmake
> macro does not seem to take file locations set by the MPI modules into
> account (module show mpi/openmpi-x86_64 etc)
>
> Is there a version of the macro that would do so? (I haven't been able
> to find one).
>
Just pass the extra options to %cmake. But be sure to use "%cmake" and not
"%{cmake}". See
https://src.fedoraproject.org/rpms/vtk/blob/master/f/vtk.spec#_675 for example.
--
Orion Poplawski
Manager of NWRA Technical Systems 720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane or...@nwra.com
Boulder, CO 80301 https://www.nwra.com/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: CMake help: "install TARGETS given no LIBRARY DESTINATION for shared library target"
Michal Schorm wrote: > $ cmake [path] [flags] > So inyour case > $ cmake . [flags] > I suppose > > This is caused by a CMake update in rawhide. It looks like this was an accidental regression rather than an intentional change, apparently introduced by this merge: https://gitlab.kitware.com/cmake/cmake/commit/c63a19e9201474750fea6adc11d75a9bb5a21e5b or in particular, by this commit: https://gitlab.kitware.com/cmake/cmake/commit/27eb7c5bdb5bb8deefe1772675dc4819592bf036 The documented argument order in CMake has always been: cmake [options] i.e., exactly the opposite of what you wrote (but CMake has never cared either way). This ought to be fixed, also because the documented argument order is what our %cmake and %cmake_kf5 RPM macros naturally produce (because they include -D flags, but the directory name has to be specified by the packager after the macro). Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[389-devel] Re: [discuss] composable object types in lib389
> On 17 Jan 2019, at 19:40, Ludwig Krispenz wrote: > > > Maybe I do not understand how it works because of some lib389 magic, but I > think this is not how roles work. > > You are creating cn=tuser1 and cn=Anju and they will have the role > objectclasses, but the benefit of roles is that you do NOT have to touch the > useres to assign roles to them. There is a class of users and a class of role > definitions and ONLY the change in the role definition will determine if a > user has a role or not. I think lib389 probably isn’t helping, but Ludwig’s description here is correct. Maybe a good approach is to “setup” roles by hand, then once you have a process in mind, then you can make the lib389 parts? I generally approach things this way to understand them well. Would that help? — Sincerely, William Brown Software Engineer, 389 Directory Server SUSE Labs ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org
Schedule for Monday's FESCo Meeting (2019-01-21)
Following is the list of topics that will be discussed in the FESCo meeting Monday at 15:00UTC in #fedora-meeting-1 on irc.freenode.net. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/UTCHowto or run: date -d '2019-01-21 15:00 UTC' Links to all issues to be discussed can be found at: https://pagure.io/fesco/report/meeting_agenda = Discussed and Voted in the Ticket = Give Bodhi automation to push based on time in testing https://pagure.io/fesco/issue/2048 APPROVED (+5, 0, -0) F30 System-Wide Change: Fully remove deprecated and unsafe functions from libcrypt https://pagure.io/fesco/issue/2052 APPROVED (+7, 0, -0) = Followups = #topic #2044 F30 Change: krb5 crypto modernization .fesco 2044 https://pagure.io/fesco/issue/2044 #topic #2028 RFC: Stream branch ownership for packages & modules .fesco 2028 https://pagure.io/fesco/issue/2028 #topic #1970 Action needed: Orphan packages will be retired if they remain orphaned for six weeks .fesco 1970 https://pagure.io/fesco/issue/1970 #topic #1820 Adjust/Drop/Document batched updates policy .fesco 1820 https://pagure.io/fesco/issue/1820 = New business = #topic #2061 F30 System-Wide Change: Reset locale if not available .fesco 2061 https://pagure.io/fesco/issue/2061 #topic #2060 F30 System-Wide Change: DNF Better Counting .fesco 2060 https://pagure.io/fesco/issue/2060 #topic #2059 F30 System-Wide Change: Replace Comps Language Group With Langpacks .fesco 2059 https://pagure.io/fesco/issue/2059 #topic #2058 F30 System-Wide Change: GNOME 3.32 .fesco 2058 https://pagure.io/fesco/issue/2058 #topic #2057 F30 Change: Avoid Fedora-specific build flags in non-RPM Python extensions .fesco 2057 https://pagure.io/fesco/issue/2057 #topic #2056 F30 System-Wide Change: Switch cryptsetup default metadata format to LUKS2 .fesco 2056 https://pagure.io/fesco/issue/2056 #topic #2055 F30 System-Wide Change: uEFI for ARMv7 .fesco 2055 https://pagure.io/fesco/issue/2055 #topic #2054 F30 System-Wide Change: Golang 1.12 .fesco 2054 https://pagure.io/fesco/issue/2054 #topic #2053 F30 System-Wide Change: Flicker Free Boot .fesco 2053 https://pagure.io/fesco/issue/2053 = Open Floor = For more complete details, please visit each individual issue. The report of the agenda items can be found at https://pagure.io/fesco/report/meeting_agenda If you would like to add something to this agenda, you can reply to this e-mail, file a new issue at https://pagure.io/fesco, e-mail me directly, or bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: F30 Self-Contained Change proposal: krb5 crypto modernization
On Thu, Jan 17, 2019 at 05:01:45PM -0500, Robbie Harwood wrote: > Jason L Tibbitts III writes: > > >> "RH" == Robbie Harwood writes: > > > > RH> If I backport this to fc29, will that assuage people's concerns? > > > > I think it would certainly help and I wouldn't complain. In fact, I'd > > love to start running that as soon as I can. However, it wouldn't > > help anyone who does a (supposedly supported) F28->F30 update. I do > > not know if that is a significant concern. > > Nothing would break, so it's technically correct to leave out right now > I think. Since my f28 builds match f29 right now, I just did both: > > fc28: https://bodhi.fedoraproject.org/updates/FEDORA-2019-0956d60ffd > fc29: https://bodhi.fedoraproject.org/updates/FEDORA-2019-d226c3ecf1 > > I've also updated the change page to mention that these warnings are > present (and the versions they start appearing in). So that gives 4+ months of warnings (assuming the F28 and F29 updates go to stable soon), which should be enough for people to take notice. It seems it's fine to remove in F30 as originally planned. Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: F30 Self-Contained Change proposal: krb5 crypto modernization
Jason L Tibbitts III writes: >> "RH" == Robbie Harwood writes: > > RH> If I backport this to fc29, will that assuage people's concerns? > > I think it would certainly help and I wouldn't complain. In fact, I'd > love to start running that as soon as I can. However, it wouldn't > help anyone who does a (supposedly supported) F28->F30 update. I do > not know if that is a significant concern. Nothing would break, so it's technically correct to leave out right now I think. Since my f28 builds match f29 right now, I just did both: fc28: https://bodhi.fedoraproject.org/updates/FEDORA-2019-0956d60ffd fc29: https://bodhi.fedoraproject.org/updates/FEDORA-2019-d226c3ecf1 I've also updated the change page to mention that these warnings are present (and the versions they start appearing in). Thanks, --Robbie signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Can we please stop enforcing Signed-off-by commits?
On Thu, 2019-01-17 at 18:20 +0100, Miro Hrončok wrote: > On 17. 01. 19 17:26, Adam Williamson wrote: > > If a project is enforcing sign-off but doesn't have > > the DCO or any other kind of prominent statement of what the sign-off > > is*for*, that is meaningless, because there's no reasonable context > > for the sign-off text. > > Exactly. > > Also, the text sometimes is a bit weird: > > (fedpkg as an example) > "All commits must be signed-off on. Please use git commit -s to do that. This > serves as a confirmation that you have the right to submit your changes. See > Developer Certificate of Origin for details." > > This should IMHO rather say something like: > > "We require all the contributors to agree with the Developer Certificate of > Origin. To confirm that you do, sign off your commits. Please use git commit > -s > to do that." > > > What bothers me that while I understand that there is some meaning for the > signed-off commits (however snake oil legalese it really appears), the > enforcement doesn't explain it and simply says: Sign off your commits! Do it! > You have to! > > And when you do, you do it because it's a technical requirement. You are not > aware that you are performing some kind of agreement with a legal document. > > > So to make this a bit better, can we change the enforcement wording on Pagure? > > Say: > > We require all the contributors to agree with the Developer Certificate of > Origin. To confirm that you do, sign off your commits. Please use git commit > -s > to do that. We unfortunately don't accept commits without that. The problem is that git sign-off is a generic mechanism which isn't *necessarily* associated with the DCO. A project could choose to use some other similar mechanism and have sign-off be a signal of acceptance of *that* mechanism instead. Still, DCO seems to be the most popular by some way, so it might be worthwhile for Pagure to have some kind of specific support for it indeed. -- 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 Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: F30 Self-Contained Change proposal: krb5 crypto modernization
> "RH" == Robbie Harwood writes: RH> If I backport this to fc29, will that assuage people's concerns? I think it would certainly help and I wouldn't complain. In fact, I'd love to start running that as soon as I can. However, it wouldn't help anyone who does a (supposedly supported) F28->F30 update. I do not know if that is a significant concern. - J< ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: F30 System-Wide Change proposal: Replace Comps Language Group With Langpacks
On Wed, Jan 09, 2019 at 02:56:59PM -0500, Ben Cotton wrote: > Congratulations to the last System-Wide Change proposal of F30! > > https://fedoraproject.org/wiki/Changes/Replace_Comps_Language_Group_With_Langpacks > > == Summary == > Language support groups in Comps file will get replaced by langpacks > package. With this Change we want meta-packages like langpacks-ja to > also install required fonts and input-methods for the given language. What is the actual benefit of this change? It looks like a nice cleanup, but apart from that? It seems that 'dnf install group @lang-foo' is not different from 'dnf install langpack-bar'. Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: F30 Self-Contained Change proposal: krb5 crypto modernization
Jason L Tibbitts III writes: >> "RH" == Robbie Harwood writes: > > RH> Ah, I see, you're talking about the case when the enctype is already > RH> not permitted. That all makes sense then. > > Right. Basically, if any one of these: > > * Warnings in previous versions about principals without modern etypes > * Logging in the new version to say why tickets wouldn't issue for > principals with old etypes > * A checkup tool in either the old or current versions to tell me what's > gone wrong > > had existed then there would have been no confusion. Certainly I was > able to figure it out but... if someone had just done an OS update > without proper testing then they could be in a pretty bad position.i > > So basically the big issue as I see it is that there's simply nothing > to tell you that things are going to break, and after the update > there's nothing that tells you why things are broken. And I was > concerned that if some encryption routines go away completely then it > would be possible to be in a state where you can't even decrypt the > database. I have added warnings for: - deprecated enctype issuance on KDC - deprecated enctypes in klist output - deprecated enctype in stash / K/M to the latest rawhide builds (krb5-1.17-3.fc30). If I backport this to fc29, will that assuage people's concerns? Or do I need to defer the change until fc31? Thanks, --Robbie signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Call for zchunk repodata testers
On Thu, 2019-01-17 at 00:48 +0100, Björn 'besser82' Esser wrote: > Am Mittwoch, den 16.01.2019, 22:08 + schrieb Jonathan Dieter: > > Just a heads up Rawhide has had zchunked metadata for almost three > > weeks, and I'd greatly appreciate some more testing on the client side > > before we finish pushing the client changes to Rawhide. > > > > … > > > > If the second day's repository download size for Rawhide is less than > > 54MB, you'll know everything's working correctly. > > I've just tested updating from yesterday's metadata and it took me about > 2.9 MBytes (vs. about 61 MBytes without zchunk support) to download. > > Seems to be working as it should. LGTM =) Thanks for the feedback! That sounds about right for a normal day's updates. Jonathan signature.asc Description: This is a digitally signed message part ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Self Introduction - Robert Fairley
On 1/17/19 12:31 PM, Robert Fairley wrote: > Hi all, > > I'm an intern at Red Hat in Toronto, Canada. I'm working on Fedora CoreOS, > and helping bring aspects of Container Linux to Fedora. I'll be maintaining a > package upstream, console-login-helper-messages. I also help out with > ostree/rpm-ostree upstream. Looking forward to contributing further in the > Fedora space! > > Best regards, > Robert Fairley If you haven't had a chance to interact with Robert yet please do say hi to `rfairley` on freenode (in the #fedora-coreos channel). He's done some amazing work in a short amount of time. Welcome Robert! Dusty ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Self Introduction - Robert Fairley
On Thu, Jan 17, 2019 at 12:31:46PM -0500, Robert Fairley wrote: > I'm an intern at Red Hat in Toronto, Canada. I'm working on Fedora CoreOS, > and helping bring aspects of Container Linux to Fedora. I'll be maintaining > a package upstream, console-login-helper-messages. I also help out with > ostree/rpm-ostree upstream. Looking forward to contributing further in the > Fedora space! Awesome -- welcome! -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Self Introduction - Robert Fairley
Apologies for second email. The package I have under review is console-login-helper-messages, at https://bugzilla.redhat.com/show_bug.cgi?id=1667174. On Thu, Jan 17, 2019 at 12:31 PM Robert Fairley wrote: > Hi all, > > I'm an intern at Red Hat in Toronto, Canada. I'm working on Fedora CoreOS, > and helping bring aspects of Container Linux to Fedora. I'll be maintaining > a package upstream, console-login-helper-messages. I also help out with > ostree/rpm-ostree upstream. Looking forward to contributing further in the > Fedora space! > > Best regards, > Robert Fairley > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Self Introduction - Robert Fairley
Hi all, I'm an intern at Red Hat in Toronto, Canada. I'm working on Fedora CoreOS, and helping bring aspects of Container Linux to Fedora. I'll be maintaining a package upstream, console-login-helper-messages. I also help out with ostree/rpm-ostree upstream. Looking forward to contributing further in the Fedora space! Best regards, Robert Fairley ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Can we please stop enforcing Signed-off-by commits?
On 17. 01. 19 17:26, Adam Williamson wrote: If a project is enforcing sign-off but doesn't have the DCO or any other kind of prominent statement of what the sign-off is*for*, that is meaningless, because there's no reasonable context for the sign-off text. Exactly. Also, the text sometimes is a bit weird: (fedpkg as an example) "All commits must be signed-off on. Please use git commit -s to do that. This serves as a confirmation that you have the right to submit your changes. See Developer Certificate of Origin for details." This should IMHO rather say something like: "We require all the contributors to agree with the Developer Certificate of Origin. To confirm that you do, sign off your commits. Please use git commit -s to do that." What bothers me that while I understand that there is some meaning for the signed-off commits (however snake oil legalese it really appears), the enforcement doesn't explain it and simply says: Sign off your commits! Do it! You have to! And when you do, you do it because it's a technical requirement. You are not aware that you are performing some kind of agreement with a legal document. So to make this a bit better, can we change the enforcement wording on Pagure? Say: We require all the contributors to agree with the Developer Certificate of Origin. To confirm that you do, sign off your commits. Please use git commit -s to do that. We unfortunately don't accept commits without that. Instead of: Sign your commits! -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: [HEADS UP] Removal of ldconfig scriptlets
> "RG" == Raphael Groner writes: RG> Fedora packaging is becoming to get heavy magic aspects. Well, obviously we would prefer that the scriptlets just go away and not be replaced with magic. The magic macros exist to accommodate those who wish to have a single spec across Fedora and EPEL, There's a limit to how far that technique can be taken but we try to add macros like %ldconfig_scriptlets, %ldconfig_post, %ldconfig_postun and %ldconfig when possible. It's surely better than having people include needless ldconfig calls just because EPEL requires it. And this reminds me that the documentation for those needs to move to the EPEL guidelines now that F27 is EOL. - J< ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: where to put udev rules for to support cloud providers
On Thu, Jan 17, 2019 at 11:41:29AM -0500, Dusty Mabe wrote: > context: https://github.com/coreos/fedora-coreos-tracker/issues/104 > > There are some udev rules that support various hardware on different cloud > providers These rules: https://github.com/coreos/init/tree/master/udev/rules.d ? Some of them are suspicious (like 79-net-google-compat.rules or 99-azure-product-uuid.rules) but rest of them seem sensible at first glance. Why not put them in obvious place – in upstream systemd? -- Tomasz Torcz 72->| 80->| xmpp: zdzich...@chrome.pl 72->| 80->| ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
where to put udev rules for to support cloud providers
context: https://github.com/coreos/fedora-coreos-tracker/issues/104 There are some udev rules that support various hardware on different cloud providers that we'd like to provide as part of Fedora CoreOS so it can operate on those platforms as expected. In the past these udev rules could be provided by the cloud-init package or by the cloud specific agent for a particular cloud provider. In Fedora CoreOS we are attempting to not ship both cloud-init or any platform specific cloud agents. We would like to ship various bits like these udev rules. The question is: where (what package) should provide these rules? One thing to think about is that we think this work would benefit the Fedora Cloud Base image as well, so we are trying not to make it specific to Fedora CoreOS. - Should they go into a `fedora-release-coreos` and `fedora-release-cloud` package? - Both of these share the same srpm - Should they go into a `cloud-platforms` package where we could possibly put other cloud supporting bits as well? Thanks Fedora CoreOS Team signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Can we please stop enforcing Signed-off-by commits?
On Thu, 2019-01-17 at 11:13 +0100, Miro Hrončok wrote: > It happened to me almost dozen times now, so here's my rage :D > > I want to send a pull request to a Fedora project*, I clone it, fork it, push > to > the fork, open a PR and there it goes: > > ! This repo requires all commits to have the Signed-off-by whatnot in them ! > > So I have to go again, amend with -s, push force. That is tedious and at > least I > know how to do that. I assume there are people who don't. > > Can we stop this nonsense? I usually smuggle something like: > >Signed-off-by: Stop This > > And nobody ever cares! The thing is enforced only because it can be enforced. > > The line in that commit message is totally useless and doesn't provide any > benefit, just pain. I've signed the Fedora Project Contributor Agreement. > That > should be enough. > > Now a bit more serious: > > What information am I missing? Why do Fedora upstreams enforce this? If you look in any of my projects' READMEs, you'll see the 'developer certificate of origin' text available at https://developercertificate.org/ . There's a good write-up on the DCO on opensource.com: https://opensource.com/article/18/3/cla-vs-dco-whats-difference *In combination with the DCO*, the sign-off is meaningful (and yes, I do check that it's actually consistent with the person submitting it when I review PRs). If a project is enforcing sign-off but doesn't have the DCO or any other kind of prominent statement of what the sign-off is *for*, that is meaningless, because there's no reasonable context for the sign-off text. -- 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 Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: systemd unit file not updated on new package update
On Thu, Jan 17, 2019 at 05:02:59PM +0100, Germano Massullo wrote: > Hello, I am testing various changes in boinc-client systemd unit file. > At every RPM package update, it happens really often that on a machine > that installs the new RPM version, does not get the new systemd unit > file version, so it is not updated. To successfully update the file, I > have to remove the old one from > /etc/systemd/system/ > and reinstall the RPM file. First, packages should install unit files into /usr/lib/systed/systemd/. Units in /etc are for system administrators and shouldn't be touched by packages. Second, if the unit file is marked in .spec as %config(noreplace), then it won't be touched/replaced on package upgrade. Third, you need to do `systemctl daemon-reload` when changing unit files. > How can this happen? Perhaps manual edits (on localhost) can prevent > the file to be updated? Manual edits as in `systemctl edit --full`? Plain `systemctl edit` only creates addon snippets and does not copy the unit. Nevertheless, if admin placed unit in /etc, this unit has a priority over the one in /lib installed by package. This is by design. -- Tomasz Torcz 72->| 80->| xmpp: zdzich...@chrome.pl 72->| 80->| ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Guidelines change] Changes to the packaging guidelines
Here are the recent changes to the packaging guidelines.
-
We have begun to remove content from the wiki. The old pages should all
now have links to the new docs site. As we continue to work on the new
documents, the corresponding wiki pages will be emptied and left only
with the link to the new content. This is currently most visible on the
main guidelines page. The wiki history remains, of course, and all of
that history was also copied into the git repository which holds the
source of the current site.
As always, if you spot issues in the packaging guidelines, feel free to
file a ticket at https://pagure.io/packaging-committee/issues. You can
even send us a pull request.
-
The versioning guidelines have been modified to allow limited use of
RPM's tilde (~) notation when packaging upstream-tagged prereleases.
* https://docs.fedoraproject.org/en-US/packaging-guidelines/Versioning/
* https://pagure.io/packaging-committee/issue/832
*
https://pagure.io/packaging-committee/c/5113d478f5885d2338dfbdceb043da634f732e51?branch=master
-
The python packaging guidelines have been updated to indicate the
changed default in Fedora 30 for %_python_bytecompile_extra (to 0). This
setting controls whether python files outside of the regular locations
for python modules are subject to automatic byte compilation.
*
https://docs.fedoraproject.org/en-US/packaging-guidelines/Python_Appendix/#manual-bytecompilation
* https://pagure.io/packaging-committee/issue/830
*
https://pagure.io/packaging-committee/c/647454105e873c15ce0c5e10cfad37aae8a50225?branch=master
*
https://fedoraproject.org/wiki/Changes/No_more_automagic_Python_bytecompilation_phase_2
-
Due to the recent accumulation of problems caused by unannounced SONAME
bumps in rawhide, a short "Listing shared library files" section was
added to the "Shared Libraries" chapter of the Packaging Guidelines: It
is now discouraged to use globs of the form libFOO.so.* (or similar) for
listing %files entries like libFOO.so.MAJOR.MINOR.PATCH in %{_libdir},
because it can conceal SONAME changes, and may contribute to accidental
bumps. If the use of any glob is helpful in reducing maintenance burden,
using something less general - like libFOO.so.MAJOR* - is encouraged
instead.
*
https://docs.fedoraproject.org/en-US/packaging-guidelines/#_listing_shared_library_files
* https://pagure.io/packaging-committee/issue/784
*
https://pagure.io/packaging-committee/c/2051d0c7dcd7f062e2c8571f19a8cf7eea8b0ce6?branch=master
___
devel-announce mailing list -- devel-annou...@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Guidelines change] Changes to the packaging guidelines
Here are the recent changes to the packaging guidelines.
-
We have begun to remove content from the wiki. The old pages should all
now have links to the new docs site. As we continue to work on the new
documents, the corresponding wiki pages will be emptied and left only
with the link to the new content. This is currently most visible on the
main guidelines page. The wiki history remains, of course, and all of
that history was also copied into the git repository which holds the
source of the current site.
As always, if you spot issues in the packaging guidelines, feel free to
file a ticket at https://pagure.io/packaging-committee/issues. You can
even send us a pull request.
-
The versioning guidelines have been modified to allow limited use of
RPM's tilde (~) notation when packaging upstream-tagged prereleases.
* https://docs.fedoraproject.org/en-US/packaging-guidelines/Versioning/
* https://pagure.io/packaging-committee/issue/832
*
https://pagure.io/packaging-committee/c/5113d478f5885d2338dfbdceb043da634f732e51?branch=master
-
The python packaging guidelines have been updated to indicate the
changed default in Fedora 30 for %_python_bytecompile_extra (to 0). This
setting controls whether python files outside of the regular locations
for python modules are subject to automatic byte compilation.
*
https://docs.fedoraproject.org/en-US/packaging-guidelines/Python_Appendix/#manual-bytecompilation
* https://pagure.io/packaging-committee/issue/830
*
https://pagure.io/packaging-committee/c/647454105e873c15ce0c5e10cfad37aae8a50225?branch=master
*
https://fedoraproject.org/wiki/Changes/No_more_automagic_Python_bytecompilation_phase_2
-
Due to the recent accumulation of problems caused by unannounced SONAME
bumps in rawhide, a short "Listing shared library files" section was
added to the "Shared Libraries" chapter of the Packaging Guidelines: It
is now discouraged to use globs of the form libFOO.so.* (or similar) for
listing %files entries like libFOO.so.MAJOR.MINOR.PATCH in %{_libdir},
because it can conceal SONAME changes, and may contribute to accidental
bumps. If the use of any glob is helpful in reducing maintenance burden,
using something less general - like libFOO.so.MAJOR* - is encouraged
instead.
*
https://docs.fedoraproject.org/en-US/packaging-guidelines/#_listing_shared_library_files
* https://pagure.io/packaging-committee/issue/784
*
https://pagure.io/packaging-committee/c/2051d0c7dcd7f062e2c8571f19a8cf7eea8b0ce6?branch=master
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org
systemd unit file not updated on new package update
Hello, I am testing various changes in boinc-client systemd unit file. At every RPM package update, it happens really often that on a machine that installs the new RPM version, does not get the new systemd unit file version, so it is not updated. To successfully update the file, I have to remove the old one from /etc/systemd/system/ and reinstall the RPM file. How can this happen? Perhaps manual edits (on localhost) can prevent the file to be updated? Thank you ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Fedora rawhide compose report: 20190117.n.0 changes
OLD: Fedora-Rawhide-20190116.n.0 NEW: Fedora-Rawhide-20190117.n.0 = SUMMARY = Added images:2 Dropped images: 0 Added packages: 2 Dropped packages:2 Upgraded packages: 68 Downgraded packages: 9 Size of added packages: 27.70 MiB Size of dropped packages:2.16 MiB Size of upgraded packages: 3.54 GiB Size of downgraded packages: 58.23 MiB Size change of upgraded packages: 9.71 MiB Size change of downgraded packages: 15.40 MiB = ADDED IMAGES = Image: Cinnamon live i386 Path: Spins/i386/iso/Fedora-Cinnamon-Live-i386-Rawhide-20190117.n.0.iso Image: Cinnamon live x86_64 Path: Spins/x86_64/iso/Fedora-Cinnamon-Live-x86_64-Rawhide-20190117.n.0.iso = DROPPED IMAGES = = ADDED PACKAGES = Package: fish-3.0.0-1.module_f30+2703+82e92e7e Summary: Friendly interactive shell RPMs:fish Size:27.64 MiB Package: python-tomlkit-0.5.3-1.fc30 Summary: Style preserving TOML library RPMs:python3-tomlkit Size:64.67 KiB = DROPPED PACKAGES = Package: libkolab-1.0.2-9.fc27 Summary: Kolab Object Handling Library RPMs:libkolab libkolab-devel python2-kolab Size:2.15 MiB Package: python-backports-shutil_which-3.5.1-7.fc29 Summary: Backport of shutil.which from Python 3 RPMs:python2-backports-shutil_which Size:12.24 KiB = UPGRADED PACKAGES = Package: ModemManager-1.10.0-0.1.rc1.fc30 Old package: ModemManager-1.8.0-4.fc29 Summary: Mobile broadband modem management service RPMs: ModemManager ModemManager-devel ModemManager-glib ModemManager-glib-devel ModemManager-vala Size: 10.03 MiB Size change: 858.27 KiB Changelog: * Tue Jan 15 2019 Lubomir Rintel - 1.8.2-1 - Update to 1.8.2 release * Tue Jan 15 2019 Lubomir Rintel - 1.10.0-0.1.rc1 - Update to 1.10 release candidate 1 Package: bodhi-3.12.0-102.fc30 Old package: bodhi-3.12.0-101.fc30 Summary: A modular framework that facilitates publishing software updates RPMs: bodhi-client bodhi-composer bodhi-docs bodhi-server python3-bodhi python3-bodhi-client Size: 5.91 MiB Size change: -12 B Changelog: * Wed Jan 16 2019 Igor Gnatenko - 3.12.0-102 - Enable dependency generator Package: buildah-1.6-33.dev.git66ff1dd.fc30 Old package: buildah-1.6-32.dev.gitd7e530e.fc30 Summary: A command line tool used for creating OCI Images RPMs: buildah Size: 27.33 MiB Size change: -2.16 KiB Changelog: * Thu Jan 17 2019 Lokesh Mandvekar (Bot) - 1.6-33.dev.git66ff1dd - autobuilt 66ff1dd Package: classification-banner-1.7.0-2.fc30 Old package: classification-banner-1.7.0-1.fc30 Summary: Displays Classification Banner for a Graphical Session RPMs: classification-banner Size: 524.73 KiB Size change: 100 B Changelog: * Tue Jan 15 2019 Miro Hron??ok - 1.7.0-2 - Remove requirement of PyGTK2 Package: cmake-3.13.3-1.fc30 Old package: cmake-3.13.2-1.fc30 Summary: Cross-platform make system RPMs: cmake cmake-data cmake-doc cmake-filesystem cmake-gui cmake-rpm-macros Size: 60.01 MiB Size change: 5.12 KiB Changelog: * Wed Jan 16 2019 Rex Dieter - 3.13.3-1 - 3.13.3 Package: cockpit-185-2.fc30 Old package: cockpit-184-1.fc30 Summary: Web Console for Linux servers RPMs: cockpit cockpit-bridge cockpit-dashboard cockpit-doc cockpit-docker cockpit-kdump cockpit-machines cockpit-machines-ovirt cockpit-networkmanager cockpit-packagekit cockpit-pcp cockpit-selinux cockpit-sosreport cockpit-storaged cockpit-system cockpit-tests cockpit-ws Size: 16.05 MiB Size change: -1.90 MiB Changelog: * Wed Jan 09 2019 Sanne Raymaekers - 185-1 - Responsive dialogs on network, kdump and users page - Kubernetes containers included in docker graphs * Wed Jan 16 2019 Bj??rn Esser - 185-2 - Rebuilt for libcrypt.so.2 (#1666033) Package: community-mysql-8.0.13-2.fc30 Old package: community-mysql-8.0.13-1.fc30 Summary: MySQL client programs and shared libraries RPMs: community-mysql community-mysql-common community-mysql-devel community-mysql-errmsg community-mysql-libs community-mysql-server community-mysql-test Size: 541.70 MiB Size change: -234.82 KiB Changelog: * Mon Jan 14 2019 Bj??rn Esser - 8.0.13-2 - Rebuilt for libcrypt.so.2 (#1666033) Package: electrum-3.2.4-2.fc30 Old package: electrum-3.2.4-1.fc30 Summary: A lightweight Bitcoin Client RPMs: electrum Size: 3.22 MiB Size change: -588 B Changelog: * Wed Jan 16 2019 Jonny Heggheim - 3.2.4-2 - Deactiated requires for typing and qdarkstyle Package: et-5.1.9-1.fc30 Old package: et-5.1.8-3.fc30 Summary: Remote shell that survives IP roaming and disconnect RPMs: et Size: 3.26 MiB Size change: -26.52 KiB Changelog: * Wed Jan 16 2019 Jason Gauci - 5.1.9-1 - https://github.com/MisterTea/EternalTerminal/releases/tag/et-v5.1.9 Package: fedmod-0.4.4-1
Fedora Rawhide-20190117.n.0 compose check report
No missing expected images. Compose FAILS proposed Rawhide gating check! 2 of 47 required tests failed openQA tests matching unsatisfied gating requirements shown with **GATING** below Failed openQA tests: 17/132 (x86_64), 1/2 (arm) New failures (same test not failed in Rawhide-20190116.n.0): ID: 345893 Test: x86_64 Server-dvd-iso modularity_tests URL: https://openqa.fedoraproject.org/tests/345893 ID: 345908 Test: x86_64 Workstation-live-iso desktop_update_graphical URL: https://openqa.fedoraproject.org/tests/345908 ID: 345910 Test: x86_64 Workstation-live-iso desktop_browser **GATING** URL: https://openqa.fedoraproject.org/tests/345910 Old failures (same test failed in Rawhide-20190116.n.0): ID: 345878 Test: x86_64 Server-dvd-iso support_server URL: https://openqa.fedoraproject.org/tests/345878 ID: 345879 Test: x86_64 Server-dvd-iso install_repository_nfs_variation URL: https://openqa.fedoraproject.org/tests/345879 ID: 345880 Test: x86_64 Server-dvd-iso install_repository_nfs_graphical URL: https://openqa.fedoraproject.org/tests/345880 ID: 345892 Test: x86_64 Server-dvd-iso install_updates_nfs URL: https://openqa.fedoraproject.org/tests/345892 ID: 345904 Test: x86_64 Workstation-live-iso base_services_start URL: https://openqa.fedoraproject.org/tests/345904 ID: 345912 Test: x86_64 Workstation-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/345912 ID: 345923 Test: x86_64 KDE-live-iso install_no_user **GATING** URL: https://openqa.fedoraproject.org/tests/345923 ID: 345935 Test: arm Minimal-raw_xz-raw.xz install_arm_image_deployment_upload URL: https://openqa.fedoraproject.org/tests/345935 ID: 345939 Test: x86_64 universal support_server URL: https://openqa.fedoraproject.org/tests/345939 ID: 345961 Test: x86_64 universal install_iscsi URL: https://openqa.fedoraproject.org/tests/345961 ID: 345996 Test: x86_64 universal install_cyrillic_language URL: https://openqa.fedoraproject.org/tests/345996 ID: 345997 Test: x86_64 universal install_arabic_language URL: https://openqa.fedoraproject.org/tests/345997 ID: 345998 Test: x86_64 universal install_asian_language URL: https://openqa.fedoraproject.org/tests/345998 ID: 346004 Test: x86_64 universal install_kickstart_nfs URL: https://openqa.fedoraproject.org/tests/346004 ID: 346006 Test: x86_64 universal install_european_language URL: https://openqa.fedoraproject.org/tests/346006 Soft failed openQA tests: 5/24 (i386), 3/132 (x86_64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Rawhide-20190116.n.0): ID: 345896 Test: i386 Server-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/345896 ID: 345897 Test: i386 Server-dvd-iso install_default URL: https://openqa.fedoraproject.org/tests/345897 ID: 345915 Test: x86_64 Workstation-boot-iso memory_check@uefi URL: https://openqa.fedoraproject.org/tests/345915 ID: 345916 Test: x86_64 Workstation-boot-iso memory_check URL: https://openqa.fedoraproject.org/tests/345916 ID: 345920 Test: i386 Workstation-boot-iso memory_check URL: https://openqa.fedoraproject.org/tests/345920 ID: 345989 Test: x86_64 universal upgrade_server_domain_controller URL: https://openqa.fedoraproject.org/tests/345989 ID: 346013 Test: i386 universal upgrade_desktop_32bit URL: https://openqa.fedoraproject.org/tests/346013 ID: 346014 Test: i386 universal upgrade_2_desktop_32bit URL: https://openqa.fedoraproject.org/tests/346014 Passed openQA tests: 112/132 (x86_64), 19/24 (i386) New passes (same test not passed in Rawhide-20190116.n.0): ID: 345886 Test: x86_64 Server-dvd-iso realmd_join_sssd URL: https://openqa.fedoraproject.org/tests/345886 Skipped non-gating openQA tests: 1 of 158 Installed system changes in test x86_64 Server-boot-iso install_default@uefi: Used mem changed from 173 MiB to 198 MiB Previous test data: https://openqa.fedoraproject.org/tests/345387#downloads Current test data: https://openqa.fedoraproject.org/tests/345869#downloads Installed system changes in test x86_64 Server-boot-iso install_default: Used mem changed from 171 MiB to 199 MiB Previous test data: https://openqa.fedoraproject.org/tests/345388#downloads Current test data: https://openqa.fedoraproject.org/tests/345870#downloads Installed system changes in test x86_64 Server-dvd-iso install_default_upload: 1 packages(s) removed since previous compose: libxcrypt-compat Previous test data: https://openqa.fedoraproject.org/tests/345389#downloads Current test data: https://openqa.fedoraproject.org/tests/345871#downloads Installed system changes in test x86_64 Server-dvd-iso install_default@uefi: 1 packages(s) removed since previous compose: libxcrypt-compat System load changed from 0.11 to 1.27 Previous test data: https://openqa.fedoraproject.org/tests/345390#downloads Current test data:
F30 Self-Contained Change proposal: Ibus-typing-booster default for Indian languages
https://fedoraproject.org/wiki/Changes/Ibus_typing_booster_default_for_indian_languages
== Summary ==
Make ibus-typing-booster the default input method for Indian languages.
== Owner ==
* Name: [[User:Mfabian|Mike Fabian]]
* Email:
== Detailed Description ==
Currently, ibus-m17n is the default input method for Indian languages
in Fedora. ibus-typing-booster uses the same libm17n used by
ibus-m17n to support input for Indian languages and thus it can do
everything ibus-m17n can do. But on top of that, ibus-typing-booster
supports predictive input by remembering user input and by using words
from dictionaries. Therefore, ibus-typing-booster is a more useful input method
for these languages.
== Benefit to Fedora ==
A better input experience for users of Indian languages.
== Scope ==
* Proposal owners:
The langtable package has data about default input methods. Change this data.
But the data in langtable is currently apparently not used by
gnome-initial setup.
The list of default input methods used by gnome-initial-setup us stored in
libgnome-desktop/default-input-sources.h
Currently there are the following default input methods for the Indian locales:
static DefaultInputSource default_input_sources[] =
{
...
{ "as_IN","ibus", "m17n:as:phonetic" },
...
{ "bn_IN","ibus", "m17n:bn:inscript" },
...
{ "gu_IN","ibus", "m17n:gu:inscript" },
...
{ "hi_IN","ibus", "m17n:hi:inscript" },
...
{ "kn_IN","ibus", "m17n:kn:kgp" },
...
{ "mai_IN", "ibus", "m17n:mai:inscript" },
...
{ "ml_IN","ibus", "m17n:ml:inscript" },
...
{ "mr_IN","ibus", "m17n:mr:inscript" },
...
{ "or_IN","ibus", "m17n:or:inscript" },
...
{ "pa_IN","ibus", "m17n:pa:inscript" },
...
{ "sd_IN","ibus", "m17n:sd:inscript" },
...
{ "ta_IN","ibus", "m17n:ta:tamil99" },
...
{ "te_IN","ibus", "m17n:te:inscript" },
...
{ "ur_IN","ibus", "m17n:ur:phonetic" },
...
Here, "m17n:as:phonetic" would need to be replaced with "typing-booster".
And similar for the other Indian languages.
ibus-typing-booster selects the default input method to use
from the locale when it is first started. For the above Indian
locales ibus-typing-booster >= 2.4.2 has the same default
m17n input methods as libgnome-desktop/default-input-sources.h,
except that it always uses inscript2 instead of inscript by default.
* Other developers: N/A (not a System Wide Change)
* Policies and guidelines: N/A (not a System Wide Change)
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
Nothing should happen when upgrading from a previous version of Fedora.
If a user used ibus-m17n before the upgrade, he will still use it
after the upgrade.
This change proposal only changes the default input method for an
Indian language
for new installs or new user accounts.
== How To Test ==
Do a new installation of Fedora 30 in an Indian language. Log into Gnome.
See what input method is suggested by default by gnome-initial-setup.
== User Experience ==
Easier input of Indian language because of predictive input.
== Dependencies ==
gnome-initial-setup
== Contingency Plan ==
* Contingency mechanism: Leave the default input methods as they are
now and move the change to Fedora 31
* Contingency deadline: Fedora 30 Beta release
* Blocks release? No.
* Blocks product? No.
--
Ben Cotton
Fedora Program Manager
TZ=America/Indiana/Indianapolis
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org
F30 Self-Contained Change proposal: Ibus-typing-booster default for Indian languages
https://fedoraproject.org/wiki/Changes/Ibus_typing_booster_default_for_indian_languages
== Summary ==
Make ibus-typing-booster the default input method for Indian languages.
== Owner ==
* Name: [[User:Mfabian|Mike Fabian]]
* Email:
== Detailed Description ==
Currently, ibus-m17n is the default input method for Indian languages
in Fedora. ibus-typing-booster uses the same libm17n used by
ibus-m17n to support input for Indian languages and thus it can do
everything ibus-m17n can do. But on top of that, ibus-typing-booster
supports predictive input by remembering user input and by using words
from dictionaries. Therefore, ibus-typing-booster is a more useful input method
for these languages.
== Benefit to Fedora ==
A better input experience for users of Indian languages.
== Scope ==
* Proposal owners:
The langtable package has data about default input methods. Change this data.
But the data in langtable is currently apparently not used by
gnome-initial setup.
The list of default input methods used by gnome-initial-setup us stored in
libgnome-desktop/default-input-sources.h
Currently there are the following default input methods for the Indian locales:
static DefaultInputSource default_input_sources[] =
{
...
{ "as_IN","ibus", "m17n:as:phonetic" },
...
{ "bn_IN","ibus", "m17n:bn:inscript" },
...
{ "gu_IN","ibus", "m17n:gu:inscript" },
...
{ "hi_IN","ibus", "m17n:hi:inscript" },
...
{ "kn_IN","ibus", "m17n:kn:kgp" },
...
{ "mai_IN", "ibus", "m17n:mai:inscript" },
...
{ "ml_IN","ibus", "m17n:ml:inscript" },
...
{ "mr_IN","ibus", "m17n:mr:inscript" },
...
{ "or_IN","ibus", "m17n:or:inscript" },
...
{ "pa_IN","ibus", "m17n:pa:inscript" },
...
{ "sd_IN","ibus", "m17n:sd:inscript" },
...
{ "ta_IN","ibus", "m17n:ta:tamil99" },
...
{ "te_IN","ibus", "m17n:te:inscript" },
...
{ "ur_IN","ibus", "m17n:ur:phonetic" },
...
Here, "m17n:as:phonetic" would need to be replaced with "typing-booster".
And similar for the other Indian languages.
ibus-typing-booster selects the default input method to use
from the locale when it is first started. For the above Indian
locales ibus-typing-booster >= 2.4.2 has the same default
m17n input methods as libgnome-desktop/default-input-sources.h,
except that it always uses inscript2 instead of inscript by default.
* Other developers: N/A (not a System Wide Change)
* Policies and guidelines: N/A (not a System Wide Change)
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
Nothing should happen when upgrading from a previous version of Fedora.
If a user used ibus-m17n before the upgrade, he will still use it
after the upgrade.
This change proposal only changes the default input method for an
Indian language
for new installs or new user accounts.
== How To Test ==
Do a new installation of Fedora 30 in an Indian language. Log into Gnome.
See what input method is suggested by default by gnome-initial-setup.
== User Experience ==
Easier input of Indian language because of predictive input.
== Dependencies ==
gnome-initial-setup
== Contingency Plan ==
* Contingency mechanism: Leave the default input methods as they are
now and move the change to Fedora 31
* Contingency deadline: Fedora 30 Beta release
* Blocks release? No.
* Blocks product? No.
--
Ben Cotton
Fedora Program Manager
TZ=America/Indiana/Indianapolis
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Silverblue: install rpm package
I want to install Notable[0]. As it is not yet packaged for fedora, I tried to install it with the rpm package. -- # rpm-ostree install notable-1.1.0.x86_64.rpm error: Importing package notable: Unsupported path: /opt/Notable/LICENSE.electron.txt; See https://github.com/projectatomic/rpm-ostree/issues/233 - Reading the 233 issue does not help me. How can I deal with this issue? How to install this application? Thank you for help [0]https://github.com/fabiospampinato/notable ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Can we please stop enforcing Signed-off-by commits?
On 1/17/19 3:06 AM, Zbigniew Jędrzejewski-Szmek wrote: On Thu, Jan 17, 2019 at 11:13:47AM +0100, Miro Hrončok wrote: It happened to me almost dozen times now, so here's my rage :D I want to send a pull request to a Fedora project*, I clone it, fork it, push to the fork, open a PR and there it goes: ! This repo requires all commits to have the Signed-off-by whatnot in them ! Snake oil legalese? Zbyszek (maybe one day I can learn to hit the right button to reply all) I hope it's not Snake oil or else the kernel is in trouble... As others have mentioned, the DCO is basically an assertion that you have the right to make a contribution to a project. There are people in the kernel community who know the history better and probably more authoritative sources but https://www.do-not-panic.com/2014/02/developer-certificate-of-origin.html is a nice blog post summarizing some history. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: CMake help: "install TARGETS given no LIBRARY DESTINATION for shared library target"
On Thu, Jan 17, 2019 14:07:44 +0100, Kevin Kofler wrote: > Ankur Sinha wrote: > > [1] https://github.com/sanjayankur31/rpm-specs/blob/arbor/arbor.spec#L107 > > Any reason why you are not using the %cmake RPM macro? I need to build the package with MPI also (mpich/openmpi) and the %cmake macro does not seem to take file locations set by the MPI modules into account (module show mpi/openmpi-x86_64 etc) Is there a version of the macro that would do so? (I haven't been able to find one). -- Thanks, Regards, Ankur Sinha "FranciscoD" https://fedoraproject.org/wiki/User:Ankursinha Time zone: Europe/London signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: CMake help: "install TARGETS given no LIBRARY DESTINATION for shared library target"
On Thu, Jan 17, 2019 14:07:06 +0100, Kevin Kofler wrote:
> Igor Gnatenko wrote:
> > You can use include(GNUInstallDirs)
They have included this, albeit a little later:
https://github.com/arbor-sim/arbor/blob/28e45aee46eb25dd91652768a5f5d496db05ba3a/CMakeLists.txt#L250
> >and then where install() is
> > called, you need to have install(… LIBRARY DESTINATION
> > ${CMAKE_INSTALL_LIBDIR}).
>
> Right, the command in the upstream CMakeLists.txt is trying to install
> something without saying WHERE it should be installed. I don't know why it
> worked for them.
It also worked for me locally which is what confuses me. I'll patch the
CMakelists.txt file and open a PR upstream.
--
Thanks,
Regards,
Ankur Sinha "FranciscoD"
https://fedoraproject.org/wiki/User:Ankursinha
Time zone: Europe/London
signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: CMake help: "install TARGETS given no LIBRARY DESTINATION for shared library target"
Ankur Sinha wrote: > [1] https://github.com/sanjayankur31/rpm-specs/blob/arbor/arbor.spec#L107 Any reason why you are not using the %cmake RPM macro? Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: CMake help: "install TARGETS given no LIBRARY DESTINATION for shared library target"
Igor Gnatenko wrote:
> You can use include(GNUInstallDirs) and then where install() is
> called, you need to have install(… LIBRARY DESTINATION
> ${CMAKE_INSTALL_LIBDIR}).
Right, the command in the upstream CMakeLists.txt is trying to install
something without saying WHERE it should be installed. I don't know why it
worked for them.
Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Can we please stop enforcing Signed-off-by commits?
On Thu, 2019-01-17 at 13:04 +0100, Miro Hrončok wrote: > I'd be very interested to know how adding some random line to a > commit message > grants an explicit license according to something that is not even > linked from > the commit message :( I've actually wondered this myself, and agree that it does seem odd. It's not like the message says "I agree to the DCO, signed xyz." For Bodhi, I decided to document what the sign off means in the contribution guide: https://bodhi.fedoraproject.org/docs/developer/index.html#contribution-guidelines Of course, that doesn't mean that all contributors read the contribution guide, but that's the best I could think to do for now. signature.asc Description: This is a digitally signed message part ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: CMake help: "install TARGETS given no LIBRARY DESTINATION for shared library target"
You can use include(GNUInstallDirs) and then where install() is
called, you need to have install(… LIBRARY DESTINATION
${CMAKE_INSTALL_LIBDIR}).
On Thu, Jan 17, 2019 at 12:37 PM Ankur Sinha wrote:
>
> Hello,
>
> Could I have some help with CMake please?
>
> I have a WIP spec here[1] that won't build. It always fails with:
>
> > + cmake -DCMAKE_C_FLAGS_RELEASE:STRING=-DNDEBUG
> > -DCMAKE_CXX_FLAGS_RELEASE:STRING=-DNDEBUG
> > -DCMAKE_Fortran_FLAGS_RELEASE:STRING=-DNDEBUG
> > -DCMAKE_VERBOSE_MAKEFILE:BOOL=ON -DCMAKE_INSTALL_PREFIX:PATH=/usr
> > -DINCLUDE_INSTALL_DIR:PATH=/usr/include -DLIB_INSTALL_DIR:PATH=/usr/lib64
> > -DSYSCONF_INSTALL_DIR:PATH=/etc -DSHARE_INSTALL_PREFIX:PATH=/usr/share
> > -DCMAKE_SKIP_RPATH:BOOL=ON -DBUILD_SHARED_LIBS:BOOL=ON
> > -DCMAKE_BUILD_TYPE:STRING=release -DLIB_SUFFIX=64 .
> > -- The C compiler identification is GNU 8.2.1
> > -- The CXX compiler identification is GNU 8.2.1
> > -- Check for working C compiler: /usr/bin/cc
> > -- Check for working C compiler: /usr/bin/cc -- works
> > -- Detecting C compiler ABI info
> > -- Detecting C compiler ABI info - done
> > -- Detecting C compile features
> > -- Detecting C compile features - done
> > -- Check for working CXX compiler: /usr/bin/c++
> > -- Check for working CXX compiler: /usr/bin/c++ -- works
> > -- Detecting CXX compiler ABI info
> > -- Detecting CXX compiler ABI info - done
> > -- Detecting CXX compile features
> > -- Detecting CXX compile features - done
> > -- Looking for pthread.h
> > -- Looking for pthread.h - found
> > -- Looking for pthread_create
> > -- Looking for pthread_create - not found
> > -- Check if compiler accepts -pthread
> > -- Check if compiler accepts -pthread - yes
> > -- Found Threads: TRUE
> > -- Could NOT find Unwind (missing: Unwind_LIBRARIES)
> > BUILDSTDERR: CMake Error at arbor/CMakeLists.txt:107 (install):
> > BUILDSTDERR: install TARGETS given no LIBRARY DESTINATION for shared
> > library target
> > BUILDSTDERR: "arbor".
>
> (The patch in the spec fixes the Unwind_Libraries bit, but the error
> persists with or without that).
>
> When I build locally on my F29 machine, with the same tweaks as in the
> spec, it builds fine. Could someone please have a look and point out
> what I'm doing wrong?
>
> [1] https://github.com/sanjayankur31/rpm-specs/blob/arbor/arbor.spec#L107
>
> --
> Thanks,
> Regards,
>
> Ankur Sinha "FranciscoD"
> https://fedoraproject.org/wiki/User:Ankursinha
>
> Time zone: Europe/London
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Can we please stop enforcing Signed-off-by commits?
On 17. 01. 19 13:28, Sheogorath wrote: On 1/17/19 12:59 PM, Randy Barlow wrote: On Thu, 2019-01-17 at 11:13 +0100, Miro Hrončok wrote: Why do Fedora upstreams enforce this? I enforce the DCO in Bodhi. I started doing it after attended a talk by Richard Fontana where he suggested it as a way to be explicit about the license of contributions (i.e., not just the license of the project). My memory is now a bit hazy, but I think there was some discussion about how many projects work under the assumption that the license of contributions is equal to the license of the project (sometimes stated as "license in, license out", but that most do not make this explicit. The DCO explicitly states that the contribution itself is granted to the project under the same license that the project uses. Just adding a link to the talk: https://www.youtube.com/watch?v=F3OxXSirek4 Thanks! I'll definitively watch that! -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Can we please stop enforcing Signed-off-by commits?
On 1/17/19 12:59 PM, Randy Barlow wrote: > On Thu, 2019-01-17 at 11:13 +0100, Miro Hrončok wrote: >> Why do Fedora upstreams enforce this? > > I enforce the DCO in Bodhi. I started doing it after attended a talk by > Richard Fontana where he suggested it as a way to be explicit about the > license of contributions (i.e., not just the license of the project). > My memory is now a bit hazy, but I think there was some discussion > about how many projects work under the assumption that the license of > contributions is equal to the license of the project (sometimes stated > as "license in, license out", but that most do not make this explicit. > The DCO explicitly states that the contribution itself is granted to > the project under the same license that the project uses. Just adding a link to the talk: https://www.youtube.com/watch?v=F3OxXSirek4 -- Signed Sheogorath signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: CMake help: "install TARGETS given no LIBRARY DESTINATION for shared library target"
On Thu, Jan 17, 2019 13:09:38 +0100, Michal Schorm wrote: > > I get the same error when trying to build for F29 also, so that may not be > > the case. > > I thought that would be the case, since several packages I maintain > started to fail in Koschei with same symptoms after new CMake version > from 3.13.2 to 3.13.3. > I fixed them the way I advised you, so I just assumed the CMake update > is the cause. I've tried that too now. No luck, I'm afraid :( -- Thanks, Regards, Ankur Sinha "FranciscoD" https://fedoraproject.org/wiki/User:Ankursinha Time zone: Europe/London signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Test-Announce] Fedora 30 Rawhide 20190117.n.0 nightly compose nominated for testing
Announcing the creation of a new nightly release validation test event for Fedora 30 Rawhide 20190117.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: lorax - 20190114.n.0: lorax-30.10-1.fc30.src, 20190117.n.0: lorax-30.10-2.fc30.src pungi - 20190114.n.0: pungi-4.1.32-3.fc30.src, 20190117.n.0: pungi-4.1.32-4.fc30.src Test coverage information for the current release can be seen at: https://www.happyassassin.net/testcase_stats/30 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_30_Rawhide_20190117.n.0_Summary The individual test result pages are: https://fedoraproject.org/wiki/Test_Results:Fedora_30_Rawhide_20190117.n.0_Installation https://fedoraproject.org/wiki/Test_Results:Fedora_30_Rawhide_20190117.n.0_Base https://fedoraproject.org/wiki/Test_Results:Fedora_30_Rawhide_20190117.n.0_Server https://fedoraproject.org/wiki/Test_Results:Fedora_30_Rawhide_20190117.n.0_Cloud https://fedoraproject.org/wiki/Test_Results:Fedora_30_Rawhide_20190117.n.0_Desktop https://fedoraproject.org/wiki/Test_Results:Fedora_30_Rawhide_20190117.n.0_Security_Lab Thank you for testing! -- Mail generated by relvalconsumer: https://pagure.io/fedora-qa/relvalconsumer ___ test-announce mailing list -- test-annou...@lists.fedoraproject.org To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: CMake help: "install TARGETS given no LIBRARY DESTINATION for shared library target"
> I get the same error when trying to build for F29 also, so that may not be > the case. I thought that would be the case, since several packages I maintain started to fail in Koschei with same symptoms after new CMake version from 3.13.2 to 3.13.3. I fixed them the way I advised you, so I just assumed the CMake update is the cause. -- Michal Schorm Software Engineer Core Services - Databases Team Red Hat -- On Thu, Jan 17, 2019 at 1:04 PM Ankur Sinha wrote: > > On Thu, Jan 17, 2019 12:46:13 +0100, Michal Schorm wrote: > > $ cmake [path] [flags] > > So inyour case > > $ cmake . [flags] > > I suppose > > > > This is caused by a CMake update in rawhide. > > Thanks for your reply, Michal. > > The cmake command seems to run OK (as pasted in my initial e-mail). I > get the same error when trying to build for F29 also, so that may not be > the case. It seems to be related to the particular directive in > CMakelists.txt: > > https://github.com/arbor-sim/arbor/blob/28e45aee46eb25dd91652768a5f5d496db05ba3a/CMakeLists.txt#L107 > > -- > Thanks, > Regards, > > Ankur Sinha "FranciscoD" > https://fedoraproject.org/wiki/User:Ankursinha > > Time zone: Europe/London > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Can we please stop enforcing Signed-off-by commits?
On 17. 01. 19 12:59, Randy Barlow wrote: On Thu, 2019-01-17 at 11:13 +0100, Miro Hrončok wrote: Why do Fedora upstreams enforce this? I enforce the DCO in Bodhi. I started doing it after attended a talk by Richard Fontana where he suggested it as a way to be explicit about the license of contributions (i.e., not just the license of the project). My memory is now a bit hazy, but I think there was some discussion about how many projects work under the assumption that the license of contributions is equal to the license of the project (sometimes stated as "license in, license out", but that most do not make this explicit. The DCO explicitly states that the contribution itself is granted to the project under the same license that the project uses. I'd be very interested to know how adding some random line to a commit message grants an explicit license according to something that is not even linked from the commit message :( CCing legal. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: CMake help: "install TARGETS given no LIBRARY DESTINATION for shared library target"
On Thu, Jan 17, 2019 12:46:13 +0100, Michal Schorm wrote: > $ cmake [path] [flags] > So inyour case > $ cmake . [flags] > I suppose > > This is caused by a CMake update in rawhide. Thanks for your reply, Michal. The cmake command seems to run OK (as pasted in my initial e-mail). I get the same error when trying to build for F29 also, so that may not be the case. It seems to be related to the particular directive in CMakelists.txt: https://github.com/arbor-sim/arbor/blob/28e45aee46eb25dd91652768a5f5d496db05ba3a/CMakeLists.txt#L107 -- Thanks, Regards, Ankur Sinha "FranciscoD" https://fedoraproject.org/wiki/User:Ankursinha Time zone: Europe/London signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Can we please stop enforcing Signed-off-by commits?
On Thu, 2019-01-17 at 11:13 +0100, Miro Hrončok wrote: > Why do Fedora upstreams enforce this? I enforce the DCO in Bodhi. I started doing it after attended a talk by Richard Fontana where he suggested it as a way to be explicit about the license of contributions (i.e., not just the license of the project). My memory is now a bit hazy, but I think there was some discussion about how many projects work under the assumption that the license of contributions is equal to the license of the project (sometimes stated as "license in, license out", but that most do not make this explicit. The DCO explicitly states that the contribution itself is granted to the project under the same license that the project uses. signature.asc Description: This is a digitally signed message part ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: CMake help: "install TARGETS given no LIBRARY DESTINATION for shared library target"
$ cmake [path] [flags] So inyour case $ cmake . [flags] I suppose This is caused by a CMake update in rawhide. -- Michal Schorm Software Engineer Core Services - Databases Team Red Hat -- On Thu, Jan 17, 2019 at 12:31 PM Ankur Sinha wrote: > > Hello, > > Could I have some help with CMake please? > > I have a WIP spec here[1] that won't build. It always fails with: > > > + cmake -DCMAKE_C_FLAGS_RELEASE:STRING=-DNDEBUG > > -DCMAKE_CXX_FLAGS_RELEASE:STRING=-DNDEBUG > > -DCMAKE_Fortran_FLAGS_RELEASE:STRING=-DNDEBUG > > -DCMAKE_VERBOSE_MAKEFILE:BOOL=ON -DCMAKE_INSTALL_PREFIX:PATH=/usr > > -DINCLUDE_INSTALL_DIR:PATH=/usr/include -DLIB_INSTALL_DIR:PATH=/usr/lib64 > > -DSYSCONF_INSTALL_DIR:PATH=/etc -DSHARE_INSTALL_PREFIX:PATH=/usr/share > > -DCMAKE_SKIP_RPATH:BOOL=ON -DBUILD_SHARED_LIBS:BOOL=ON > > -DCMAKE_BUILD_TYPE:STRING=release -DLIB_SUFFIX=64 . > > -- The C compiler identification is GNU 8.2.1 > > -- The CXX compiler identification is GNU 8.2.1 > > -- Check for working C compiler: /usr/bin/cc > > -- Check for working C compiler: /usr/bin/cc -- works > > -- Detecting C compiler ABI info > > -- Detecting C compiler ABI info - done > > -- Detecting C compile features > > -- Detecting C compile features - done > > -- Check for working CXX compiler: /usr/bin/c++ > > -- Check for working CXX compiler: /usr/bin/c++ -- works > > -- Detecting CXX compiler ABI info > > -- Detecting CXX compiler ABI info - done > > -- Detecting CXX compile features > > -- Detecting CXX compile features - done > > -- Looking for pthread.h > > -- Looking for pthread.h - found > > -- Looking for pthread_create > > -- Looking for pthread_create - not found > > -- Check if compiler accepts -pthread > > -- Check if compiler accepts -pthread - yes > > -- Found Threads: TRUE > > -- Could NOT find Unwind (missing: Unwind_LIBRARIES) > > BUILDSTDERR: CMake Error at arbor/CMakeLists.txt:107 (install): > > BUILDSTDERR: install TARGETS given no LIBRARY DESTINATION for shared > > library target > > BUILDSTDERR: "arbor". > > (The patch in the spec fixes the Unwind_Libraries bit, but the error > persists with or without that). > > When I build locally on my F29 machine, with the same tweaks as in the > spec, it builds fine. Could someone please have a look and point out > what I'm doing wrong? > > [1] https://github.com/sanjayankur31/rpm-specs/blob/arbor/arbor.spec#L107 > > -- > Thanks, > Regards, > > Ankur Sinha "FranciscoD" > https://fedoraproject.org/wiki/User:Ankursinha > > Time zone: Europe/London > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
CMake help: "install TARGETS given no LIBRARY DESTINATION for shared library target"
Hello, Could I have some help with CMake please? I have a WIP spec here[1] that won't build. It always fails with: > + cmake -DCMAKE_C_FLAGS_RELEASE:STRING=-DNDEBUG > -DCMAKE_CXX_FLAGS_RELEASE:STRING=-DNDEBUG > -DCMAKE_Fortran_FLAGS_RELEASE:STRING=-DNDEBUG > -DCMAKE_VERBOSE_MAKEFILE:BOOL=ON -DCMAKE_INSTALL_PREFIX:PATH=/usr > -DINCLUDE_INSTALL_DIR:PATH=/usr/include -DLIB_INSTALL_DIR:PATH=/usr/lib64 > -DSYSCONF_INSTALL_DIR:PATH=/etc -DSHARE_INSTALL_PREFIX:PATH=/usr/share > -DCMAKE_SKIP_RPATH:BOOL=ON -DBUILD_SHARED_LIBS:BOOL=ON > -DCMAKE_BUILD_TYPE:STRING=release -DLIB_SUFFIX=64 . > -- The C compiler identification is GNU 8.2.1 > -- The CXX compiler identification is GNU 8.2.1 > -- Check for working C compiler: /usr/bin/cc > -- Check for working C compiler: /usr/bin/cc -- works > -- Detecting C compiler ABI info > -- Detecting C compiler ABI info - done > -- Detecting C compile features > -- Detecting C compile features - done > -- Check for working CXX compiler: /usr/bin/c++ > -- Check for working CXX compiler: /usr/bin/c++ -- works > -- Detecting CXX compiler ABI info > -- Detecting CXX compiler ABI info - done > -- Detecting CXX compile features > -- Detecting CXX compile features - done > -- Looking for pthread.h > -- Looking for pthread.h - found > -- Looking for pthread_create > -- Looking for pthread_create - not found > -- Check if compiler accepts -pthread > -- Check if compiler accepts -pthread - yes > -- Found Threads: TRUE > -- Could NOT find Unwind (missing: Unwind_LIBRARIES) > BUILDSTDERR: CMake Error at arbor/CMakeLists.txt:107 (install): > BUILDSTDERR: install TARGETS given no LIBRARY DESTINATION for shared > library target > BUILDSTDERR: "arbor". (The patch in the spec fixes the Unwind_Libraries bit, but the error persists with or without that). When I build locally on my F29 machine, with the same tweaks as in the spec, it builds fine. Could someone please have a look and point out what I'm doing wrong? [1] https://github.com/sanjayankur31/rpm-specs/blob/arbor/arbor.spec#L107 -- Thanks, Regards, Ankur Sinha "FranciscoD" https://fedoraproject.org/wiki/User:Ankursinha Time zone: Europe/London signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Can we please stop enforcing Signed-off-by commits?
On Thu, Jan 17, 2019 at 11:13:47AM +0100, Miro Hrončok wrote: > It happened to me almost dozen times now, so here's my rage :D > > I want to send a pull request to a Fedora project*, I clone it, fork it, > push to the fork, open a PR and there it goes: > > ! This repo requires all commits to have the Signed-off-by whatnot in them ! Snake oil legalese? Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Can we please stop enforcing Signed-off-by commits?
On Thu, Jan 17, 2019 at 11:13:47AM +0100, Miro Hrončok wrote: > It happened to me almost dozen times now, so here's my rage :D > > I want to send a pull request to a Fedora project*, I clone it, fork it, > push to the fork, open a PR and there it goes: ... > benefit, just pain. I've signed the Fedora Project Contributor Agreement. > That should be enough. ... > (* last time it was simple-koji-ci, but it's also fedpkg and other projects > on pagure.io) Note that pagure.io does not enforce the FPCA. Pierre ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Can we please stop enforcing Signed-off-by commits?
https://src.fedoraproject.org/rpms/ Project option -> Enforce signed-off commits in pull-request -- Michal Schorm Software Engineer Core Services - Databases Team Red Hat -- On Thu, Jan 17, 2019 at 11:15 AM Miro Hrončok wrote: > > It happened to me almost dozen times now, so here's my rage :D > > I want to send a pull request to a Fedora project*, I clone it, fork it, push > to > the fork, open a PR and there it goes: > > ! This repo requires all commits to have the Signed-off-by whatnot in them ! > > So I have to go again, amend with -s, push force. That is tedious and at > least I > know how to do that. I assume there are people who don't. > > Can we stop this nonsense? I usually smuggle something like: > >Signed-off-by: Stop This > > And nobody ever cares! The thing is enforced only because it can be enforced. > > The line in that commit message is totally useless and doesn't provide any > benefit, just pain. I've signed the Fedora Project Contributor Agreement. That > should be enough. > > Now a bit more serious: > > What information am I missing? Why do Fedora upstreams enforce this? > > Thanks > > (* last time it was simple-koji-ci, but it's also fedpkg and other projects on > pagure.io) > -- > Miro Hrončok > -- > Phone: +420777974800 > IRC: mhroncok > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Can we please stop enforcing Signed-off-by commits?
It happened to me almost dozen times now, so here's my rage :D I want to send a pull request to a Fedora project*, I clone it, fork it, push to the fork, open a PR and there it goes: ! This repo requires all commits to have the Signed-off-by whatnot in them ! So I have to go again, amend with -s, push force. That is tedious and at least I know how to do that. I assume there are people who don't. Can we stop this nonsense? I usually smuggle something like: Signed-off-by: Stop This And nobody ever cares! The thing is enforced only because it can be enforced. The line in that commit message is totally useless and doesn't provide any benefit, just pain. I've signed the Fedora Project Contributor Agreement. That should be enough. Now a bit more serious: What information am I missing? Why do Fedora upstreams enforce this? Thanks (* last time it was simple-koji-ci, but it's also fedpkg and other projects on pagure.io) -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[389-devel] Re: [discuss] composable object types in lib389
On 01/17/2019 09:57 AM, Anuj Borah wrote:
Hay William.
Here i am not using nsUserAccount in nsUserAccountRole as it
requires 'uid' which is not allowed in nsFilteredRoleDefinition and
nsRoleDefinition . Below are usages:
user=nsUserAccountRole(topo.standalone,'cn=tuser1,ou=People,dc=example,dc=com')
user_props={'cn':'Anuj', 'nsRoleFilter':'cn=*'}
user.create(properties=user_props, basedn=SUFFIX)
nsUserAccountRoles(topo.standalone, DEFAULT_SUFFIX).list()[0].dn
>> 'cn=tuser1,ou=People,dc=example,dc=com'
nsUserAccountRoles(topo.standalone,
DEFAULT_SUFFIX).create(properties=user_props)
>>>
nsUserAccountRoles(topo.standalone, DEFAULT_SUFFIX).list()[1].dn
>>> 'cn=Anuj,ou=People,dc=example,dc=com'
Let me know , what you think .
Maybe I do not understand how it works because of some lib389 magic, but
I think this is not how roles work.
You are creating cn=tuser1 and cn=Anju and they will have the role
objectclasses, but the benefit of roles is that you do NOT have to touch
the useres to assign roles to them. There is a class of users and a
class of role definitions and ONLY the change in the role definition
will determine if a user has a role or not.
Regards
Anuj Borah
On Tue, Jan 15, 2019 at 6:30 AM William Brown > wrote:
> On 14 Jan 2019, at 19:28, Anuj Borah mailto:abo...@redhat.com>> wrote:
>
> Hi William ,
>
> Just find out a way to do it .
This isn’t quite what I had in mind.
Remember, we should be able to compose nsRole types to various
other objects if required (despite my dislike of nsRoles …).
We have "nsUserAccount(Account)”, and we need to be able to extend
it with nsRole types.
One way to achieve this is:
class nsRoleDefinition(object):
def __init__(self, instance, dn=None):
if ‘_create_objectclasses’ not in self:
raise Exception ….
# So we must have been combined with a type to add roles
self._create_objectclasses.append(’nsFilteredRoleDefinition’)
class nsUserAccountRole(nsUserAccount, nsRoleDefinition):
def __init__(self, instance, dn=None):
super(nsUserAccount, self).__init__(instance, dn)
super(nsRoleDefinition, self).__init__(instance, dn)
Then you would use the nsUserAccountRole like normal. (I think we
may need a similar “nsUserAccountRoles" for the muliple search parts)
A benefit to this, is you could have role-specific functions like
setting/changing the filter, but you never loose the “account”
features like bind. Provided a method is uniquely sourced, I think
python takes the implementation that is unique, or it takes the
“first”. So this should all just work.
The main benefit here is it’s really clean, we can compose this to
other types. It also avoids any duplication of class definitions
and logic etc.
I think this is how I would like to see it created. It may be
worth making a “ticket” just for the nsRole parts and splitting
your test for nsRoles out of the mega-patch you have.
>
> class UserAccountnsRole(Account):
>
> def __init__(self, instance, dn=None):
> super(UserAccountnsRole, self).__init__(instance, dn)
> self._rdn_attribute = RDN
> self._create_objectclasses = [
> 'top',
> 'LDAPsubentry',
> 'nsRoleDefinition',
> 'nsComplexRoleDefinition',
> 'nsFilteredRoleDefinition'
> ]
> user_compare_exclude = [
> 'nsUniqueId',
> 'modifyTimestamp',
> 'createTimestamp',
> 'entrydn'
> ]
> self._compare_exclude = self._compare_exclude +
user_compare_exclude
> self._protected = False
>
> def _validate(self, rdn, properties, basedn):
> if 'ntUserDomainId' in properties and 'ntUser' not in
self._create_objectclasses:
> self._create_objectclasses.append('ntUser')
>
> return super(UserAccountnsRole, self)._validate(rdn,
properties, basedn)
>
>
> def create_test_user_nsrole(instance, cn, nsRoleFilter,
description, suffix=None):
> global test_user_id
> if cn is None:
> cn = "testuser_" + str(test_user_id)
> test_user_id += 1
> if suffix is None:
> suffix = DEFAULT_SUFFIX
> dn = "cn=" + cn + "," + suffix
> properties = {
> 'cn': cn,
> "nsRoleFilter": nsRoleFilter,
> "description": description,
> }
> user = UserAccountnsRole(instance, dn)
> user.create(properties=properties)
> return user
> Now just using create_test_user_nsrole we will be able to create
entries with nsRoles.
>
>
> Regards
> Anuj Borah
>
>
>
>
>
>
> On Mon, Jan 7, 2019 at 2:30 PM
[389-devel] Re: [discuss] composable object types in lib389
Hay William.
RDN = 'cn'
class nsUserAccountRole(Account):
def __init__(self, instance, dn=None):
super(nsUserAccountRole, self).__init__(instance, dn)
self._rdn_attribute = RDN
self._create_objectclasses = [
'top',
'LDAPsubentry',
'nsRoleDefinition',
'nsComplexRoleDefinition',
'nsFilteredRoleDefinition'
]
self._childobject = Account
user_compare_exclude = [
'nsUniqueId',
'modifyTimestamp',
'createTimestamp',
'entrydn'
]
self._compare_exclude = self._compare_exclude + user_compare_exclude
self._protected = False
class nsUserAccountRoles(DSLdapObjects):
def __init__(self, instance, basedn, rdn='ou=People'):
super(nsUserAccountRoles, self).__init__(instance)
self._objectclasses = [
'top',
'LDAPsubentry',
'nsRoleDefinition',
'nsComplexRoleDefinition',
'nsFilteredRoleDefinition'
]
self._filterattrs = [RDN, 'cn']
self._childobject = nsUserAccountRole
if rdn is None:
self._basedn = basedn
else:
self._basedn = '{},{}'.format(rdn, basedn)
Here i am not using nsUserAccount in nsUserAccountRole as it requires
'uid' which is not allowed in nsFilteredRoleDefinition and
nsRoleDefinition . Below are usages:
user=nsUserAccountRole(topo.standalone,'cn=tuser1,ou=People,dc=example,dc=com')
user_props={'cn':'Anuj', 'nsRoleFilter':'cn=*'}
user.create(properties=user_props, basedn=SUFFIX)
nsUserAccountRoles(topo.standalone, DEFAULT_SUFFIX).list()[0].dn
>> 'cn=tuser1,ou=People,dc=example,dc=com'
nsUserAccountRoles(topo.standalone,
DEFAULT_SUFFIX).create(properties=user_props)
>>>
nsUserAccountRoles(topo.standalone, DEFAULT_SUFFIX).list()[1].dn
>>> 'cn=Anuj,ou=People,dc=example,dc=com'
Let me know , what you think .
Regards
Anuj Borah
On Tue, Jan 15, 2019 at 6:30 AM William Brown wrote:
>
> > On 14 Jan 2019, at 19:28, Anuj Borah wrote:
> >
> > Hi William ,
> >
> > Just find out a way to do it .
>
>
> This isn’t quite what I had in mind.
>
> Remember, we should be able to compose nsRole types to various other
> objects if required (despite my dislike of nsRoles …).
>
> We have "nsUserAccount(Account)”, and we need to be able to extend it with
> nsRole types.
>
> One way to achieve this is:
>
> class nsRoleDefinition(object):
> def __init__(self, instance, dn=None):
> if ‘_create_objectclasses’ not in self:
> raise Exception ….
> # So we must have been combined with a type to add roles
> self._create_objectclasses.append(’nsFilteredRoleDefinition’)
>
>
> class nsUserAccountRole(nsUserAccount, nsRoleDefinition):
> def __init__(self, instance, dn=None):
> super(nsUserAccount, self).__init__(instance, dn)
> super(nsRoleDefinition, self).__init__(instance, dn)
>
>
>
> Then you would use the nsUserAccountRole like normal. (I think we may need
> a similar “nsUserAccountRoles" for the muliple search parts)
>
> A benefit to this, is you could have role-specific functions like
> setting/changing the filter, but you never loose the “account” features
> like bind. Provided a method is uniquely sourced, I think python takes the
> implementation that is unique, or it takes the “first”. So this should all
> just work.
>
> The main benefit here is it’s really clean, we can compose this to other
> types. It also avoids any duplication of class definitions and logic etc.
>
> I think this is how I would like to see it created. It may be worth making
> a “ticket” just for the nsRole parts and splitting your test for nsRoles
> out of the mega-patch you have.
>
> >
> > class UserAccountnsRole(Account):
> >
> > def __init__(self, instance, dn=None):
> > super(UserAccountnsRole, self).__init__(instance, dn)
> > self._rdn_attribute = RDN
> > self._create_objectclasses = [
> > 'top',
> > 'LDAPsubentry',
> > 'nsRoleDefinition',
> > 'nsComplexRoleDefinition',
> > 'nsFilteredRoleDefinition'
> > ]
> > user_compare_exclude = [
> > 'nsUniqueId',
> > 'modifyTimestamp',
> > 'createTimestamp',
> > 'entrydn'
> > ]
> > self._compare_exclude = self._compare_exclude +
> user_compare_exclude
> > self._protected = False
> >
> > def _validate(self, rdn, properties, basedn):
> > if 'ntUserDomainId' in properties and 'ntUser' not in
> self._create_objectclasses:
> > self._create_objectclasses.append('ntUser')
> >
> > return super(UserAccountnsRole, self)._validate(rdn, properties,
> basedn)
> >
> >
> > def create_test_user_nsrole(instance, cn, nsRoleFilter, description,
> suffix=None):
> > global test_user_id
> > if cn is None:
> > cn =
