EPEL epel beta report: 20140307 changes
Compose started at Fri Mar 7 08:15:02 UTC 2014 Broken deps for x86_64 -- 2ping-2.0-2.el7.noarch requires perl(Digest::CRC) RemoteBox-1.7-1.el7.noarch requires rdesktop RemoteBox-1.7-1.el7.noarch requires perl-Gtk2 bodhi-server-0.9.8-2.el7.noarch requires python-simplemediawiki 1:centerim-4.22.10-14.el7.x86_64 requires perl(Time::ParseDate) check-mk-1.2.2p2-2.el7.x86_64 requires mod_python chm2pdf-0.9.1-13.el7.noarch requires python-chm chm2pdf-0.9.1-13.el7.noarch requires htmldoc docker-registry-0.6.5-1.el7.noarch requires redis docker-registry-0.6.5-1.el7.noarch requires python-rsa docker-registry-0.6.5-1.el7.noarch requires python-redis docker-registry-0.6.5-1.el7.noarch requires python-keystoneclient docker-registry-0.6.5-1.el7.noarch requires python-glanceclient docker-registry-0.6.5-1.el7.noarch requires python-backports-lzma globus-gram-job-manager-pbs-1.6-7.el7.x86_64 requires torque-client globus-gram-job-manager-sge-1.7-2.el7.x86_64 requires gridengine koji-vm-1.8.0-2.el7.noarch requires python-virtinst lnst-2-1.el7.noarch requires python-pyroute2 lxc-templates-0.9.0-3.el7.x86_64 requires dpkg lxc-templates-0.9.0-3.el7.x86_64 requires debootstrap lxc-templates-0.9.0-3.el7.x86_64 requires busybox mcollective-common-2.4.1-1.el7.noarch requires rubygem(systemu) mcollective-common-2.4.1-1.el7.noarch requires rubygem(stomp) nagios-plugins-nrpe-2.15-1.el7.x86_64 requires nagios-plugins nf3d-0.8-2.el7.noarch requires python-visual openpgpkey-milter-0.3-1.el7.noarch requires python-pymilter openpgpkey-milter-0.3-1.el7.noarch requires python-gnupg phoronix-test-suite-4.8.6-1.el7.noarch requires php-fpdf php-phpseclib-crypt-aes-0.3.5-2.el7.noarch requires php-pear(phpseclib.sourceforge.net/Crypt_Rijndael) = 0:0.3.0 plowshare-0.9.4-0.46.20140112git.el7.noarch requires caca-utils postgrey-1.34-12.el7.noarch requires perl(BerkeleyDB) python-social-auth-0.1.19-1.el7.noarch requires python-requests-oauthlib = 0:0.3.0 qt4pas-2.5-3.el7.x86_64 requires fpc-src racoon2-20100526a-27.el7.x86_64 requires perl-Getopt-Simple rubygem-gssapi-1.1.2-3.el7.noarch requires rubygem(ffi) = 0:1.0.1 rubygem-mizuho-0.9.20-2.el7.noarch requires rubygem(sqlite3) rubygem-rspec-2.14.1-1.el7.noarch requires rubygem(rspec-mocks) = 0:2.14.1 rubygem-rspec-2.14.1-1.el7.noarch requires rubygem(rspec-expectations) = 0:2.14.1 rubygem-rspec-2.14.1-1.el7.noarch requires rubygem(rspec-core) = 0:2.14.1 spectrwm-2.5.0-1.el7.x86_64 requires xlockmore spectrwm-2.5.0-1.el7.x86_64 requires dmenu Broken deps for ppc64 -- 2ping-2.0-2.el7.noarch requires perl(Digest::CRC) RemoteBox-1.7-1.el7.noarch requires rdesktop RemoteBox-1.7-1.el7.noarch requires perl-Gtk2 bodhi-server-0.9.8-2.el7.noarch requires python-simplemediawiki 1:centerim-4.22.10-14.el7.ppc64 requires perl(Time::ParseDate) check-mk-1.2.2p2-2.el7.ppc64 requires mod_python chm2pdf-0.9.1-13.el7.noarch requires python-chm chm2pdf-0.9.1-13.el7.noarch requires htmldoc cloud-init-0.7.2-8.el7.noarch requires python-requests cloud-init-0.7.2-8.el7.noarch requires dmidecode docker-registry-0.6.5-1.el7.noarch requires redis docker-registry-0.6.5-1.el7.noarch requires python-rsa docker-registry-0.6.5-1.el7.noarch requires python-requests docker-registry-0.6.5-1.el7.noarch requires python-redis docker-registry-0.6.5-1.el7.noarch requires python-keystoneclient docker-registry-0.6.5-1.el7.noarch requires python-glanceclient docker-registry-0.6.5-1.el7.noarch requires python-backports-lzma fedmsg-0.7.6-2.el7.noarch requires python-requests globus-gram-job-manager-pbs-1.6-7.el7.ppc64 requires torque-client globus-gram-job-manager-sge-1.7-2.el7.ppc64 requires gridengine golang-github-guelfey-godbus-devel-0-0.1.gitf6a3a23.el7.noarch requires golang httpie-0.8.0-1.el7.noarch requires python-requests koji-vm-1.8.0-2.el7.noarch requires python-virtinst lnst-2-1.el7.noarch requires python-pyroute2 lxc-templates-0.9.0-3.el7.ppc64 requires dpkg lxc-templates-0.9.0-3.el7.ppc64 requires debootstrap lxc-templates-0.9.0-3.el7.ppc64 requires busybox mcollective-common-2.4.1-1.el7.noarch requires rubygem(systemu) mcollective-common-2.4.1-1.el7.noarch requires rubygem(stomp) nagios-plugins-nrpe-2.15-1.el7.ppc64 requires nagios-plugins nf3d-0.8-2.el7.noarch requires python-visual openpgpkey-milter-0.3-1.el7.noarch requires
EPEL Fedora 5 updates-testing report
The following Fedora EPEL 5 Security updates need testing: Age URL 684 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2012-5630/bugzilla-3.2.10-5.el5 175 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-11560/fail2ban-0.8.10-4.el5 139 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-11893/libguestfs-1.20.12-1.el5 113 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-12091/bip-0.8.9-1.el5 104 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-12169/gc-7.1-6.el5 19 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0581/augeas-1.2.0-1.el5 19 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0541/drupal7-ctools-1.4-1.el5 13 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0645/easy-rsa-2.2.2-1.el5 6 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0702/mod_auth_shadow-2.3-2.el5 1 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0745/imapsync-1.584-2.el5 1 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0752/libssh-0.5.5-2.el5 The following builds have been pushed to Fedora EPEL 5 updates-testing drupal6-link-2.11-1.el5 drupal7-domain-3.11-1.el5 drupal7-fivestar-2.0-0.8.rc1.el5 drupal7-l10n_update-1.0-0.4.rc1.el5 drupal7-path_breadcrumbs-3.0-0.8.rc2.el5 drupal7-tmgmt-1.0-0.6.rc1.el5 Details about builds: drupal6-link-2.11-1.el5 (FEDORA-EPEL-2014-0767) Defines simple link field types Update Information: Updated to 2.11 * Release notes: https://drupal.org/node/2207273 Here is where you give an explanation of your update. References: [ 1 ] Bug #1071271 - drupal6-link-2.11 is available https://bugzilla.redhat.com/show_bug.cgi?id=1071271 [ 2 ] Bug #829763 - Review Request: drupal6-link - Link module for Drupal6 https://bugzilla.redhat.com/show_bug.cgi?id=829763 drupal7-domain-3.11-1.el5 (FEDORA-EPEL-2014-0775) A domain-based access control system Update Information: Updated to 3.11 * Release notes: https://drupal.org/node/2208987 References: [ 1 ] Bug #1071895 - drupal7-domain-3.11 is available https://bugzilla.redhat.com/show_bug.cgi?id=1071895 drupal7-fivestar-2.0-0.8.rc1.el5 (FEDORA-EPEL-2014-0778) Enables fivestar ratings on content, users, etc Update Information: Updated to 2.0-rc1 * Release notes: https://drupal.org/node/2208927 ChangeLog: * Thu Mar 6 2014 Shawn Iwinski shawn.iwin...@gmail.com - 2.0-0.8.rc1 - Updated to 2.0-rc1 (BZ #1066281; release notes https://drupal.org/node/2208927) References: [ 1 ] Bug #1066281 - drupal7-fivestar-2.0-rc1 is available https://bugzilla.redhat.com/show_bug.cgi?id=1066281 drupal7-l10n_update-1.0-0.4.rc1.el5 (FEDORA-EPEL-2014-0770) Provides automatic downloads and updates for translations Update Information: Updated to 1.0-rc1 * Release notes: https://drupal.org/node/2204871 References: [ 1 ] Bug #1070105 - drupal7-l10n_update-1.0-rc1 is available https://bugzilla.redhat.com/show_bug.cgi?id=1070105 drupal7-path_breadcrumbs-3.0-0.8.rc2.el5 (FEDORA-EPEL-2014-0765) Allows creation of custom breadcrumbs for any page using contexts Update Information: Updated to 3.0-rc2 * Release notes: https://drupal.org/node/2197523 ChangeLog: * Thu Mar 6 2014 Shawn Iwinski shawn.iwin...@gmail.com - 3.0-0.8.rc2 - Updated to 3.0-rc2 (BZ #1066282; release notes
EPEL Fedora 6 updates-testing report
The following Fedora EPEL 6 Security updates need testing: Age URL 684 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2012-5620/bugzilla-3.4.14-2.el6 113 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-12079/bip-0.8.9-1.el6 31 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0440/fwsnort-1.6.4-1.el6 26 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0483/boinc-client-7.2.33-3.git1994cc8.el6 19 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0538/drupal7-ctools-1.4-1.el6 16 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0590/oath-toolkit-2.0.2-4.el6 13 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0644/easy-rsa-2.2.2-1.el6 11 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0653/perl-CGI-Application-4.50-4.el6 6 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0700/v8-3.14.5.10-6.el6 6 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0695/mod_auth_shadow-2.3-2.el6 3 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0730/php-sabre-dav-1.8.9-1.el6 1 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0747/imapsync-1.584-2.el6 1 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0751/libssh-0.5.5-2.el6 0 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0756/rubygem-rbovirt-0.0.6-2.el6 The following builds have been pushed to Fedora EPEL 6 updates-testing cube-4.2.2-1.el6 drupal6-link-2.11-1.el6 drupal7-domain-3.11-1.el6 drupal7-fivestar-2.0-0.8.rc1.el6 drupal7-l10n_update-1.0-0.4.rc1.el6 drupal7-path_breadcrumbs-3.0-0.8.rc2.el6 drupal7-tmgmt-1.0-0.6.rc1.el6 fedocal-0.5.1-1.el6 php-twig-Twig-1.15.1-1.el6 psad-2.2.3-1.el6 python-oslo-sphinx-1.1-1.el6 python-sure-1.2.5-1.el6 racoon2-20100526a-27.el6 Details about builds: cube-4.2.2-1.el6 (FEDORA-EPEL-2014-0781) CUBE Uniform Behavioral Encoding generic presentation component Update Information: CUBE (CUBE Uniform Behavioral Encoding) is a generic presentation component suitable for displaying a wide variety of performance metrics for parallel programs including MPI and OpenMP applications. CUBE allows interactive exploration of a multidimensional performance space in a scalable fashion. Scalability is achieved in two ways: hierarchical decomposition of individual dimensions and aggregation across different dimensions. All performance metrics are uniformly accommodated in the same display and thus provide the ability to easily compare the effects of different kinds of performance behavior. drupal6-link-2.11-1.el6 (FEDORA-EPEL-2014-0779) Defines simple link field types Update Information: Updated to 2.11 * Release notes: https://drupal.org/node/2207273 Here is where you give an explanation of your update. References: [ 1 ] Bug #1071271 - drupal6-link-2.11 is available https://bugzilla.redhat.com/show_bug.cgi?id=1071271 [ 2 ] Bug #829763 - Review Request: drupal6-link - Link module for Drupal6 https://bugzilla.redhat.com/show_bug.cgi?id=829763 drupal7-domain-3.11-1.el6 (FEDORA-EPEL-2014-0773) A domain-based access control system Update Information: Updated to 3.11 * Release notes: https://drupal.org/node/2208987 ChangeLog: * Thu Mar 6 2014 Shawn Iwinski shawn.iwin...@gmail.com - 3.11-1 - Updated to 3.11 (BZ #1071895; release notes https://drupal.org/node/2208987) * Sat Aug 3 2013 Fedora Release Engineering rel-...@lists.fedoraproject.org - 3.10-3 - Rebuilt for https://fedoraproject.org/wiki/Fedora_20_Mass_Rebuild References: [ 1 ] Bug #1071895 - drupal7-domain-3.11 is available https://bugzilla.redhat.com/show_bug.cgi?id=1071895 drupal7-fivestar-2.0-0.8.rc1.el6 (FEDORA-EPEL-2014-0772) Enables fivestar ratings on content, users, etc Update Information: Updated to
Re: Summary/Minutes from today's FESCo Meeting (2014-03-05)
On 03/06/2014 06:00 PM, Matthew Miller wrote: On Thu, Mar 06, 2014 at 03:50:37PM +0100, drago01 wrote: For instance we named a release beefy miracle and that might have been offensive for some people (ex. in India)., but apparently no one cared enough to officially complain. Additionally, there is a fundamental difference here. The problem isn't that someone might be offended -- people might be (and are) offended by anything. The problem is that the logo refers to a marginalized race of people using stereotyped imagery. While many people do not eat beef and hold cows sacred, the beefy miracle logo does not make any reference to those people. If it did, it too would have been a problem. It seems this tabooization of stereotypes[0] is a North American concept (though, as I was surprised to learn, apparently there are entire fields of study around this area, which I admit I'm not familiar with). I don't get how referring to a marginalized people using stereotyped imagery should be considered offensive in Fedora while sacrilege should not. I really don't see any fundamental difference. (Though -- or maybe because -- neither are offensive to me personally.) Please, consider that there are cultures other than your own. What seems inherently right for you may seem confusing or even absurd to others, and on the other hand what seems trivial to you might be a huge issue for others. -- Petr³ [0] Pardon me if this simplification is offensive. The whole concept is foreign to me. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
ANN Retiring pdftk for F20+
Hello, I have reitiered pdftk for F-20 and rawhide. The rationals for this steps are: 1.) pdftk is a C++ programm which calls methods of a Java library called iText. To do this, gcj with CNI support is required. The support of this technology is discontinued in Fedora Linux. Therefore you can't make any successfuls builds for pdftk on Fedora Linux anymore. 2.) pdftk2 may dempends of iText5 or later which is not provides on Fedora during licensing issues. Best Regards: Jochen Schmitt ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
F21 System Wide Change: jQuery
= Proposed System Wide Change: jQuery = https://fedoraproject.org/wiki/Changes/jQuery Change owner(s): T.C. Hollingsworth tchollingswo...@gmail.com jQuery is a fast, small, and feature-rich JavaScript library. It makes things like HTML document traversal and manipulation, event handling, animation, and Ajax much simpler with an easy-to-use API that works across a multitude of browsers. With a combination of versatility and extensibility, jQuery has changed the way that millions of people write JavaScript. Traditionally, a copy of jQuery has been included with every web application that requires it. This change will migrate many of those applications to a shared system copy of jQuery. Both the 1.x branch of jQuery that supports Internet Explorer 6 and the 2.x branch of jQuery that only works with modern web browsers will be provided. == Detailed description == Traditionally, a copy of jQuery has been included with every web application that requires it. This change will migrate many of those applications to a shared system copy of jQuery. The following packages will be provided: * js-jquery - The latest version of the jQuery 2.x branch, suitable for web applications that are only compatible with modern web browsers that fully support modern web standards. * js-jquery1 - The latest version of the jQuery 1.x branch, suitable for web applications that endeavor to be compatible with older web browsers such as Internet Explorer 6. * js-jquery-migrate - The jQuery migrate plugin, which is a compatibility shim that enables web applications that depend on older versions of jQuery to work with the latest version, so that they can be ported away from old, unsupported jQuery versions that may potentially have security issues. == Scope == Proposal owners: === New Packages === In addition to the new packages described above, several support packages must be introduced to enable proper building and minification of jQuery packages in Fedora. For more information, see the dependencies section. Other developers: === Migrating Web Applications === Web applications that depend on modern versions of jQuery will simply be ported to use the systemwide version instead, Web applications that use older versions of jQuery ( 1.6.4 but 1.9) will be ported to use jquery-migrate and the systemwide version of jQuery. Packagers will be encouraged to work with upstream to migrate to the latest version of jQuery without jquery-migrate, since using this plugin re-enables misfeatures rightly removed from jQuery core that are XSS holes waiting to happen. Maintainers of web applications that use extremely old versions of jQuery ( 1.6.4) will be strongly encouraged to work with upstream to migrate to the latest versions of jQuery and update their packages. However, current Fedora policy regarding bundled libraries permits these packages to be grandfathered in, so I am unable to force any action here. Preliminary repoqueries have been performed to identify potentially affected packages, see the dependencies section for more details. === Migrating documentation frameworks === Certain documentation frameworks, such as python-sphinx, ship copies of jQuery as well. These frameworks will be modified to use a symlink or other means so that they too can use the new systemwide versions. Policies and guidelines: None other than those needed for JavaScript packaging in general. Release Engineering: No special attention required. ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Summary/Minutes from today's FESCo Meeting (2014-03-05)
Hi, I don't think that worrying about perpetuating offensive stereotypes is specifc to the US, we have similar controversies in Europe: http://en.wikipedia.org/wiki/Banania#Controversy http://en.wikipedia.org/wiki/Zwarte_Piet#Controversies Anyway, the line between what is acceptable and unacceptable in Fedora should be that no one should be offended by something that directly refers to him or his origins in a negative or hurtful way. I have no opinion about the Cherokee logo, as an European citizen, it looks to me very innocent (a little child playing) but if it offends native americans, it should be fixed anyway. my 2 cts, H. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: ANN Retiring pdftk for F20+
On 03/06/2014 12:52 PM, Jochen Schmitt wrote: Hello, I have reitiered pdftk for F-20 and rawhide. The rationals for this steps are: 1.) pdftk is a C++ programm which calls methods of a Java library called iText. To do this, gcj with CNI support is required. The support of this technology is discontinued in Fedora Linux. Therefore you can't make any successfuls builds for pdftk on Fedora Linux anymore. And what about pdfchain? Joachim Backes Best Regards: Jochen Schmitt ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce -- Fedora release 20 (Heisenbug) Kernel-3.13.5-202.fc20.x86_64 Joachim Backes joachim.bac...@rhrk.uni-kl.de https://www-user.rhrk.uni-kl.de/~backes/de-index.html https://www-user.rhrk.uni-kl.de/~backes/en-index.html -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Summary/Minutes from today's FESCo Meeting (2014-03-05)
On 03/06/2014 09:11 PM, Stephen Gallagher wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/06/2014 03:02 PM, Kevin Kofler wrote: Rahul Sundaram wrote: I certainly did file a complaint against generic-logos which has a similar problem with Fedora Board which in turn dismissed my concern and failed to answer my follow up question and I gave up on it. That is of course artwork that Fedora itself is upstream of rather than merely something we package. One would hope that the new standard applies to concerns outside of U.S as well. That's the crux of the issue, offensive is really interpreted as offensive to people in the USA. That just does not make sense for a worldwide distribution, nor even for an international company. This statement is blatantly false. And I consider this to be blatantly naive. You will always find somebody who complains about something and you will always find situations, which were things are far from being clear. Just consider the F20 swastika background and a Fedora release once having been called Werewulf. As a German, both incidents caused me to raise an eye-brow, but weren't worth it to make a fuzz about. That said, it would seem common sense to me for FESCO to have contacted some official representative of the American Indian People or the Cherokee Nation/People and ask for their opinion. Did this happen? What did these representatives say? Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Summary/Minutes from today's FESCo Meeting (2014-03-05)
On Fri, Mar 7, 2014 at 11:45 AM, Ralf Corsepius rc040...@freenet.de wrote: On 03/06/2014 09:11 PM, Stephen Gallagher wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/06/2014 03:02 PM, Kevin Kofler wrote: Rahul Sundaram wrote: I certainly did file a complaint against generic-logos which has a similar problem with Fedora Board which in turn dismissed my concern and failed to answer my follow up question and I gave up on it. That is of course artwork that Fedora itself is upstream of rather than merely something we package. One would hope that the new standard applies to concerns outside of U.S as well. That's the crux of the issue, offensive is really interpreted as offensive to people in the USA. That just does not make sense for a worldwide distribution, nor even for an international company. This statement is blatantly false. And I consider this to be blatantly naive. You will always find somebody who complains about something and you will always find situations, which were things are far from being clear. Just consider the F20 swastika background and a Fedora release once having been called Werewulf. As a German, both incidents caused me to raise an eye-brow, but weren't worth it to make a fuzz about. That said, it would seem common sense to me for FESCO to have contacted some official representative of the American Indian People or the Cherokee Nation/People and ask for their opinion. Did this happen? What did these representatives say? https://bugzilla.redhat.com/show_bug.cgi?id=681339#c31 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Summary/Minutes from today's FESCo Meeting (2014-03-05)
On 03/07/2014 10:59 AM, H. Guémar wrote: Hi, I don't think that worrying about perpetuating offensive stereotypes is specifc to the US, we have similar controversies in Europe: http://en.wikipedia.org/wiki/Banania#Controversy http://en.wikipedia.org/wiki/Zwarte_Piet#Controversies Well, read the second article. 92% of the Dutch public don't perceive Zwarte Piet as racist. I'm not saying it is or is not, or that it should or should not be fixed; I'm saying that there is a culture where this is not perceived as a big deal, as opposed to USA where political correctness is a big deal. Anyway, the line between what is acceptable and unacceptable in Fedora should be that no one should be offended by something that directly refers to him or his origins in a negative or hurtful way. My point is that the list him/her and his/her origins seems rather arbitrary. Why is e.g. his/her religion not on the list? I'm not saying where the line should be drawn, that is obviously something a single person (or a single culture) shouldn't decide. (By the way, excluding females by saying he when you mean anybody is seriously offensive to some. Again, from what I can tell, this is a big issue in the American culture.) I have no opinion about the Cherokee logo, as an European citizen, it looks to me very innocent (a little child playing) but if it offends native americans, it should be fixed anyway. I also don't see how anyone could be offended by it, but I understand that there is a culture that I don't understand :) -- Petr³ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Summary/Minutes from today's FESCo Meeting (2014-03-05)
On 03/07/2014 11:53 AM, drago01 wrote: On Fri, Mar 7, 2014 at 11:45 AM, Ralf Corsepius rc040...@freenet.de wrote: On 03/06/2014 09:11 PM, Stephen Gallagher wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/06/2014 03:02 PM, Kevin Kofler wrote: Rahul Sundaram wrote: I certainly did file a complaint against generic-logos which has a similar problem with Fedora Board which in turn dismissed my concern and failed to answer my follow up question and I gave up on it. That is of course artwork that Fedora itself is upstream of rather than merely something we package. One would hope that the new standard applies to concerns outside of U.S as well. That's the crux of the issue, offensive is really interpreted as offensive to people in the USA. That just does not make sense for a worldwide distribution, nor even for an international company. This statement is blatantly false. And I consider this to be blatantly naive. You will always find somebody who complains about something and you will always find situations, which were things are far from being clear. Just consider the F20 swastika background and a Fedora release once having been called Werewulf. As a German, both incidents caused me to raise an eye-brow, but weren't worth it to make a fuzz about. That said, it would seem common sense to me for FESCO to have contacted some official representative of the American Indian People or the Cherokee Nation/People and ask for their opinion. Did this happen? What did these representatives say? https://bugzilla.redhat.com/show_bug.cgi?id=681339#c31 OK, that's better than nothing, but this still is just one individual's position and is far from being an official position. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Proposal: Don't show applications in the software center with XPM icons
On 6 March 2014 18:51, Tim Lauridsen tim.laurid...@gmail.com wrote: Not showing app, because they have bad looking icons, seems like a bad idea to me. I'm not sure anyone will be surprised in my goal of making the applications we show users have high quality content. XPM icons are a good first step, then it'll be things like missing icon transparency, AppData, translated AppData over the next few releases. The alternative is we set the bar so high that only a dozen or so apps are visible at first and the software center is useless for most users. I also hope people are noticing the *hundreds* of upstream bugs I've opened trying to raise the bar for all applications, rather than just a thou shall do X, Y, Z. I'm working at the moment on a tool that packagers and upstreams can use to find out issues and recommendations. When it's finished enough for some feedback I'll post some links. Richard -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Proposal: Don't show applications in the software center with XPM icons
On 2014-03-06, Richard Hughes hughsi...@gmail.com wrote: XPM is an old standard for icons used by a very small number of desktop packages in Fedora. The XPM icons are normally small, mostly 8 bit, and usually without an alpha channel and look very bad in the software center. I'm going to propose for F21 that we drop support for XPM in the metadata extractor and only show apps with GIF, PNG and SVG icons. The list of affected GUI applications is here: GIF is an old standard for icons used by a very small number of desktop packages in Fedora. The GIF icons are normally small, mostly 8 bit, and usually without an alpha channel and look very bad in the software center. -- Petr -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Proposal: Don't show applications in the software center with XPM icons
On Fri, Mar 7, 2014 at 6:50 AM, Satyajit Sahoo satyajit.ha...@gmail.comwrote: Apps with ugly icons and ugly design results in bad user experience IMO. They should not be displayed in the software center The quaility of an application has nothing todo, with at fancy icon, not showning the icon is ok, but don't show the application is not IMO what will be the next ? qt apps ? gtk2 apps I agree with Richard that it would be very bad to set the bar to high, no user want a software center there only shows 5% of the available apps no matter, how slick it looks Tim -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Proposal: Don't show applications in the software center with XPM icons
On 7 March 2014 11:42, Petr Pisar ppi...@redhat.com wrote: GIF is an old standard for icons used by a very small number of desktop packages in Fedora. Also valid. The *two* applications in Fedora using gif icons are asymptote and imagej. Richard -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Proposal: Don't show applications in the software center with XPM icons
Am 07.03.2014 12:57, schrieb Tim Lauridsen: On Fri, Mar 7, 2014 at 6:50 AM, Satyajit Sahoo satyajit.ha...@gmail.com mailto:satyajit.ha...@gmail.com wrote: Apps with ugly icons and ugly design results in bad user experience IMO. They should not be displayed in the software center The quaility of an application has nothing todo, with at fancy icon, not showning the icon is ok, but don't show the application is not IMO what will be the next? qt apps? gtk2 apps +1000 this new age function follows form is ridiculous, some people seems really to prefer a horrible buggy but shiny application to a perfect working one signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Proposal: Don't show applications in the software center with XPM icons
On 7 March 2014 11:57, Tim Lauridsen tim.laurid...@gmail.com wrote: what will be the next ? qt apps ? gtk2 apps No, because that would be ridiculous. Hiding applications using GTK1 would of course be okay. Richard -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[Base] Base Design WG agenda meeting 07. Mar 2014 15:00 UTC on #fedora-meeting: Proposal for cancel due to empty agenda
No agenda for today, so i'd propose to cancel the meeting today and prepare another more detailed review of the Tech Specs and a checkup of the takslist of dglimore next week. Thanks regards, Phil -- Philipp Knirsch | Tel.: +49-711-96437-470 Manager Core Services| Fax.: +49-711-96437-111 Red Hat GmbH | Email: Phil Knirsch pknir...@redhat.com Wankelstrasse 5 | Web: http://www.redhat.com/ D-70563 Stuttgart, Germany -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: pdftk retired?
On Thu, 06 Mar 2014 14:52:27 -0500 Tom Callaway tcall...@redhat.com wrote: That are the two reasons why I'm not able to support pdftk on Fedora anymore and was forced to reitred this package. I'm sorry for nayone who maintaining any package with dependencies on this package. This is why pdftk died. We can't include iText5+ because of its licensing issues. But isn't it AGPL licensed, which is a free license..? -- Susi Lehtola Fedora Project Contributor jussileht...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
qt-creator arm build timing out
Hi, I'm trying to build qt-creator [1], but the builds fail due to the arm build timing out. Is there anyway I can increase the timeout? Thanks, Sandro [1] http://koji.fedoraproject.org/koji/taskinfo?taskID=6604270 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: qt-creator arm build timing out
On Fri, 07 Mar 2014 13:53:24 +0100 Sandro Mani manisan...@gmail.com wrote: Hi, I'm trying to build qt-creator [1], but the builds fail due to the arm build timing out. Is there anyway I can increase the timeout? can you resubmit with parallel make disabled for ARM? Building heavy C++ code in parallel with only 4GB RAM leads to heavy swapping which slows down the build. Dan Thanks, Sandro [1] http://koji.fedoraproject.org/koji/taskinfo?taskID=6604270 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: pdftk retired?
On 03/07/2014 01:30 PM, Susi Lehtola wrote: On Thu, 06 Mar 2014 14:52:27 -0500 Tom Callaway tcall...@redhat.com wrote: That are the two reasons why I'm not able to support pdftk on Fedora anymore and was forced to reitred this package. I'm sorry for nayone who maintaining any package with dependencies on this package. This is why pdftk died. We can't include iText5+ because of its licensing issues. But isn't it AGPL licensed, which is a free license..? See here: https://lists.fedoraproject.org/pipermail/legal/2011-June/001656.html Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: qt-creator arm build timing out
On 07.03.2014 14:05, Dan Horák wrote: On Fri, 07 Mar 2014 13:53:24 +0100 Sandro Mani manisan...@gmail.com wrote: Hi, I'm trying to build qt-creator [1], but the builds fail due to the arm build timing out. Is there anyway I can increase the timeout? can you resubmit with parallel make disabled for ARM? Building heavy C++ code in parallel with only 4GB RAM leads to heavy swapping which slows down the build. Thanks, done. Sandro -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
ABRT 2.2 with Python 3 support heading to Fedora
Hi, ABRT 2.2 adds support for Python 3 in form of two new packages: - abrt-python3 providing an API for problem manipulation and - abrt-addon-python3 adding support for collecting unhandled exceptions in python 3 applications. Packages are now available in rawhide and will land in updates-testing for f19 and f20 soon. They will get pulled automatically by abrt-cli and abrt-desktop virtual packages in future. Please help testing these, especially if you maintain some python 3 applications. https://admin.fedoraproject.org/updates/abrt-2.2.0-1.fc20,libreport-2.2.0-1.fc20 https://admin.fedoraproject.org/updates/abrt-2.2.0-1.fc19,libreport-2.2.0-1.fc19 RFE: https://bugzilla.redhat.com/show_bug.cgi?id=1047085 Thanks, -- Richard Marko -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [Base] Base Design WG agenda meeting 07. Mar 2014 15:00 UTC on #fedora-meeting: Proposal for cancel due to empty agenda
On Fri, Mar 7, 2014 at 7:16 AM, Phil Knirsch pknir...@redhat.com wrote: No agenda for today, so i'd propose to cancel the meeting today and prepare another more detailed review of the Tech Specs and a checkup of the takslist of dglimore next week. Agreed. As an aside, I've missed this meeting the past couple of weeks because I'm inept at calendar entries. Just to make sure, we're sticking with the current UTC time it is at now for future meetings right? The US switches to DST this weekend and the EU does at the end of the month. Could get confusing. josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Summary/Minutes from today's FESCo Meeting (2014-03-05)
2014-03-07 12:16 GMT+01:00 Ralf Corsepius rc040...@freenet.de: On 03/07/2014 11:53 AM, drago01 wrote: https://bugzilla.redhat.com/show_bug.cgi?id=681339#c31 OK, that's better than nothing, but this still is just one individual's position and is far from being an official position. See https://fedorahosted.org/fesco/ticket/1230#comment:30 for a far better explanation; with that, I didn't think official position was necessary. Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [Base] Base Design WG agenda meeting 07. Mar 2014 15:00 UTC on #fedora-meeting: Proposal for cancel due to empty agenda
- Original Message - On Fri, Mar 7, 2014 at 7:16 AM, Phil Knirsch pknir...@redhat.com wrote: No agenda for today, so i'd propose to cancel the meeting today and prepare another more detailed review of the Tech Specs and a checkup of the takslist of dglimore next week. Agreed. I'm ok too. As an aside, I've missed this meeting the past couple of weeks because I'm inept at calendar entries. Just to make sure, we're sticking with the current UTC time it is at now for future meetings right? The US switches to DST this weekend and the EU does at the end of the month. Could get confusing. This month, it's going to be 5 hours difference. And as many of us has meetings scheduled in Eastern time and it means earlier meeting for EU folks, I'd say stick with current time - in the US, move EU one hour earlier. Let's take a look on the new time in the end of this month. Not could get confusing, it's always confusing... Jaroslav josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F20 Self Contained Change: Snapshot and Rollback Tool
Am 07.03.2014 14:31, schrieb Josh Boyer: On Thu, Mar 6, 2014 at 6:52 PM, Chris Murphy li...@colorremedies.com wrote: I this project dead? I'm casting about to tools to manage lvm snapshots and roller-derby sounded promising. Any other tools out there? There's a recent snapshot/rollback thread on the desktop list that relates to this. LVM thin provisioning support is in the Fedora 20 installer (it fails to produce a bootable system, the post-install fix for which is listed in Fedora 20 common bugs). However, if OSTree is used, then there isn't a hard requirement on either LVM Thin Provisioning or Btrfs. I don't think that's accurate. OSTree doesn't touch /home from what I remember. It is only concerned with /usr and to as minimal a degree as possible /etc. People likely still want snapshot and rollback for their actual _data_ as well i don't think people *really* like to restore a snapshot of /usr without /var/lib/rpm if they only know what that means at the end signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Proposal: Don't show applications in the software center with XPM icons
2014-03-07 12:35 GMT+01:00 Richard Hughes hughsi...@gmail.com: I'm not sure anyone will be surprised in my goal of making the applications we show users have high quality content. XPM icons are a good first step, then it'll be things like missing icon transparency, AppData, translated AppData over the next few releases. I don't think such technological restrictions will achieve your goal. If you really want nice screenshots and well-written descriptions, just do it and propose a manually-curated application list.[1] If you want the application packagers and upstreams to be responsible for the content so that you don't have to, with the associated pride or shame about the content falling on the individual author of that content, that's also an option. AFAICS having the application packagers and upstreams to be responsible for the content, but still reviewing it and looking for technological indications that the content is sub-par, and adding code and rules to enforce technological restrictions, has the disadvantages of both - you are still doing manual reviews and extra work complicating the software by adding technological restrictions[2], but you don't actually have the power to avoid low-quality content. Mirek [1] We haven't had a good flamewar this week :) [2] XPM is an indication of poor quality only because there's such a correlation within the current appdata collection; this correlation may go away in a month (The technological response to XPM is no longer supported is clearly to take the existing XPM picture and convert it into something else.) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Proposal: Don't show applications in the software center with XPM icons
On Fri, 2014-03-07 at 13:19 +0100, Reindl Harald wrote: says who? as long GTK1 is not forbidden in Fedora there is no valid reason for that statement - you may prefer not having a function at all if it is not beautiful enough for you *but* * beautiful is in the eye of the beholder * you should hestitate make such proposals based on your eyes Microsoft, Apple, and Google set requirements that apps must follow if they want to appear in the software center in order to ensure a good user experience. I absolutely think we need to do the same to be competitive. Ancient icons are a good heuristic that the app is unmaintained and not something the user really wants to install. signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Summary/Minutes from today's FESCo Meeting (2014-03-05)
On 03/07/2014 02:32 PM, Miloslav Trmač wrote: 2014-03-07 12:16 GMT+01:00 Ralf Corsepius rc040...@freenet.de mailto:rc040...@freenet.de: On 03/07/2014 11:53 AM, drago01 wrote: https://bugzilla.redhat.com/show_bug.cgi?id=681339#c31 OK, that's better than nothing, but this still is just one individual's position and is far from being an official position. See https://fedorahosted.org/fesco/ticket/1230#comment:30 for a far better explanation; with that, I didn't think official position was necessary. I think it is, because history tells you'll often find overzealous second-column activists, who are trying to defend or enforce positions, the first column or the broad mass never carried. Unfortunately, I am not in a position to estimate what applies, here. That said, if a Cherokee official would pronounce the negative position on the logo towards upstream, if I were upstream, I'd rename the project, because of this. If no Cherokee official would speak up, I'd not change anything about the project, but would have my very private thoughts about Fedora's and Red Hat's leadership. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Proposal: Don't show applications in the software center with XPM icons
Am 07.03.2014 15:08, schrieb Michael Catanzaro: On Fri, 2014-03-07 at 13:19 +0100, Reindl Harald wrote: says who? as long GTK1 is not forbidden in Fedora there is no valid reason for that statement - you may prefer not having a function at all if it is not beautiful enough for you *but* * beautiful is in the eye of the beholder * you should hestitate make such proposals based on your eyes Microsoft, Apple, and Google set requirements that apps must follow if they want to appear in the software center in order to ensure a good user experience. I absolutely think we need to do the same to be competitive. Ancient icons are a good heuristic that the app is unmaintained and not something the user really wants to install if i want it the Apple and Microsoft way i just install Windows or go out an buy a Mac - i am using Linux because it is *not* Windows and *not *OSX* speaking of freedom and freedom of choice and then come with restrictions here and there is somehow strange you hardly can call i do not show an app because i do not like the icon a good user expierience - where do you draw the line? that may end in there is no app for what i current need to do and so i can't use that operating system at all while the app was there but someone decided to hide it signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Proposal: Don't show applications in the software center with XPM icons
Am 07.03.2014 15:08, schrieb Michael Catanzaro: Ancient icons are a good heuristic that the app is unmaintained and not something the user really wants to install Ancient icons are a good heuristic that a app if it does what i need the next week or month does not get a complete rewrite with a total different UI and that i want to use it *because* of that to prevent my personal workflow changing all the time by random decisions signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [Base] Base Design WG agenda meeting 07. Mar 2014 15:00 UTC on #fedora-meeting: Proposal for cancel due to empty agenda
On 03/07/2014 02:29 PM, Josh Boyer wrote: On Fri, Mar 7, 2014 at 7:16 AM, Phil Knirsch pknir...@redhat.com wrote: No agenda for today, so i'd propose to cancel the meeting today and prepare another more detailed review of the Tech Specs and a checkup of the takslist of dglimore next week. Agreed. As an aside, I've missed this meeting the past couple of weeks because I'm inept at calendar entries. Just to make sure, we're sticking with the current UTC time it is at now for future meetings right? The US switches to DST this weekend and the EU does at the end of the month. Could get confusing. josh Right, i remember the month of clock switch hell. And yes, i'd propose to stick with UTC for now. Even if it doesn't work for a few folks things should settle down in 3-4 weeks. Thanks regards and have a great weekend! Phil -- Philipp Knirsch | Tel.: +49-711-96437-470 Manager Core Services| Fax.: +49-711-96437-111 Red Hat GmbH | Email: Phil Knirsch pknir...@redhat.com Wankelstrasse 5 | Web: http://www.redhat.com/ D-70563 Stuttgart, Germany -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: pdftk retired?
On Thu, Mar 6, 2014 at 2:52 PM, Tom Callaway wrote: On 03/06/2014 06:41 AM, Jochen Schmitt wrote: On Thu, Mar 06, 2014 at 12:03:46PM +0100, Florian Weimer wrote: pdftk has a hard dependency on GCJ because it's a C++ program that uses a Java library (iText) through CNI. I once tried to rewrite the C++ part in Java, but the existing command line parser is quite involved, so I didn't quite get there. Switch to pdftk version 2 doesn't change the basic architecture of the program. (We really want to get rid of GCJ.) An additional reason is the fact, that pdftk2 may depend on iText5 or later. For licensing reasons Fedora only provides iText-2.1.7 at the last release of iText wihout any known licensing issues. That are the two reasons why I'm not able to support pdftk on Fedora anymore and was forced to reitred this package. I'm sorry for nayone who maintaining any package with dependencies on this package. This is why pdftk died. We can't include iText5+ because of its licensing issues. Sorry I am missing something. Why can't we keep the old pdftk that works with itext2? Orcan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F20 Self Contained Change: Snapshot and Rollback Tool
On Fri, Mar 7, 2014 at 8:41 AM, Reindl Harald h.rei...@thelounge.net wrote: i don't think people *really* like to restore a snapshot of /usr without /var/lib/rpm if they only know what that means at the end On an rpm-ostree system, /var/lib/rpm is a symlink to /usr/share/rpm. And that's only because I wanted to avoid depending on a small patch to rpm to have it look in /usr/share/rpm automatically if /var/lib/rpm doesn't exist. If you follow this, you'll realize this also means it's immutable - rpm is not involved in the upgrade process. When you download a new tree, you also download an entire new copy of the rpmdb. And yes, it's an efficiency hit. On the other hand, every upgrade is atomic. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: pdftk retired?
- Original Message - On Thu, Mar 6, 2014 at 2:52 PM, Tom Callaway wrote: On 03/06/2014 06:41 AM, Jochen Schmitt wrote: On Thu, Mar 06, 2014 at 12:03:46PM +0100, Florian Weimer wrote: pdftk has a hard dependency on GCJ because it's a C++ program that uses a Java library (iText) through CNI. I once tried to rewrite the C++ part in Java, but the existing command line parser is quite involved, so I didn't quite get there. Switch to pdftk version 2 doesn't change the basic architecture of the program. (We really want to get rid of GCJ.) An additional reason is the fact, that pdftk2 may depend on iText5 or later. For licensing reasons Fedora only provides iText-2.1.7 at the last release of iText wihout any known licensing issues. That are the two reasons why I'm not able to support pdftk on Fedora anymore and was forced to reitred this package. I'm sorry for nayone who maintaining any package with dependencies on this package. This is why pdftk died. We can't include iText5+ because of its licensing issues. Sorry I am missing something. Why can't we keep the old pdftk that works with itext2? Check the whole thread - because of GCJ dependency. iText is second issue. The first could be fixed by rewrite of offending part of code to Java but someone would have to do it first. That's how I understand this situation. Jaroslav Orcan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [389-devel] strcasestr vs. PL_strcasestr
On 03/07/2014 07:15 AM, Carsten Grzemba wrote: Hi Nathan, is there special reason why you use /strcasestr/ in ACL plugin instead of /PL_strcasestr/. It presents me some headache to build 1.3.2 on Solaris 10. https://git.fedorahosted.org/cgit/389/ds.git/commit/ldap/servers/plugins/acl?id=95214606df95deb1cf9a30044fe64f780c030b34 No, there is no reason to use strcasestr. We should be using PL_strcasestr for portability. Carsten Am 06.03.14 schrieb *Noriko Hosoi * nho...@redhat.com: https://fedorahosted.org/389/ticket/47731 https://fedorahosted.org/389/attachment/ticket/47731/0001-Ticket-47731-A-tombstone-entry-is-deleted-by-ldapdel.patch Description: A tombstone deletion by ldapdelete op from client is supposed to fail. The failure from SLAPI_PLUGIN_BETXNPOSTOPERATION was ignored in 389-ds-base-1.2.11 plugin_call_func and it was not passed to the backend to abort. This patch added the check in the same way as in 389-ds-base-1.3.1 and newer. -- 389-devel mailing list 389-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel -- 389-devel mailing list 389-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel -- 389-devel mailing list 389-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
Re: F20 Self Contained Change: Snapshot and Rollback Tool
On Fri, Mar 7, 2014 at 8:31 AM, Josh Boyer jwbo...@fedoraproject.org wrote: I don't think that's accurate. OSTree doesn't touch /home from what I remember. It is only concerned with /usr and to as minimal a degree as possible /etc. People likely still want snapshot and rollback for their actual _data_ as well. Exactly, I think block/filesystem level storage are potential complements. Many competently-maintained systems already have backup solutions for data though. In fact, Anaconda defaults to having it on a separate partition in some configurations precisely so that one can just blow away the root partition and preserve /home. Also, remember than on an OSTree system, /home is just a symlink to /var/home - *all* local mutable state lives in /var. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
F21 System Wide Change: u-boot syslinux by default
= Proposed System Wide Change: u-boot syslinux by default = https://fedoraproject.org/wiki/Changes/u-boot_syslinux Change owner(s): Dennis Gilmore den...@ausil.us Add syslinux support to u-boot enabling both pxelinux and extlinux support. simplifying booting arm machines, making anaconda installs easy and overall providing for a better user experience. Default u-boot to using syslinux config files for booting. pxelinux for network and extlinux for local booting. == Detailed description == u-boot has support for booting using syslinux style configuration files, this change is to default to using it on all supported systems. === Benefit to Fedora === This takes away the complexity of booting arm systems. There is no need to know addresses or to wrap images with mkimage. Users will get a menu that allows them to choose which kernel to boot. making things like a boot.img will be possible. Initiating installs via anaconda will also be much more simple and straight forward. == Scope == * Proposal owners: default u-boot to loading extlinux.conf files. anaconda to write a devicetreedir line in extlinux.conf on arm systems. appliance-creator to write out a devicetreedir in extlinux.conf on arm systems * Other developers: grubby to update extlinux.conf appropriately. * Release engineering: None * Policies and guidelines: None ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: review swap: cscppc, cswrap
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/06/2014 10:30 AM, Kamil Dudka wrote: Hi, is anyone willing to review or swap reviews of the following packages? * cscppc - A compiler wrapper that runs cppcheck in background, available at https://bugzilla.redhat.com/1066026 * cswrap - Generic compiler wrapper, available at https://bugzilla.redhat.com/1066028 Basic info and motivation for adding these packages to Fedora is available at http://kdudka.fedorapeople.org/static-analysis-devconf14.pdf. Thanks in advance! Kamil Hi Kamil, I have taken cswrap for review. I will take cscppc also after finishing cswrap. Mukundan. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJTGeXFAAoJEGqtW2dEe0yGeYkQAII4O/ZxgeMmOoovWIp0nqQ5 ig8QQwfGS2sTe+VXW2HadPobVE6Wgpodn4I5chzvQRHbHu4j8wHGTSfwCy9bPLil OhxNh9cZGtGCmakkg7d5056rJ+DBlrF+1JL0EyjtypF3TZLvvSpKcFPmLvwfQc4J i1nw1m1cx+bZ9ajh3y808qPbhd6W5QrL8ZUK4MUVSZCXeNkRjTYokulE2jUZnicZ sMuI1NrhFnxN6cZq5zSYyyuOoEt9iVTpwHBwSSyuhK7WqNDBgNqHZxh07VWtbSkx fIQ4Gu0eTjpyj2q5pwW84JHgRAT5RISHHXL4BoCKPQGN4bIDyr5nEQ+UtqTVpSd9 fkkPX9yHlG+BDej981vJn6UlKYIN12fEKglNx7woo+89r+Y86qyV6pzc3p4Pgc0L Lex/Y3YW+81kcVAB2K/Alb6PAlYEkqcpzC063aAFUb96amISkCrBrBHbFlijE5kh rw8mHTb7+1K3ohSQpRs9XEpiTl+YRXJAChKuud/lyvMEwfMcV0QmClNVgPDpyCJz BWS4laVSyeVd7eVNpWhTFgG2+WDdbpXU6OK+DzXkBbxqJxJIPybymBAjBwivDjX/ kESSyZE4tnomfoTlxeTVkfQC/2nbBLPNd0MxFnksuHrfsWZisyr/3A3aFtd3tMPJ y+olNVrDHo9A1x4y9MML =sZaC -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Self Introduction: Adrien Vergé
Hi everybody, I'm a French Fedora user and I'm trying to become a package maintainer for the system I have been using for years! Usually I write C and Python for personal stuff, I am also involved in projects (currently, tracing on Linux with LTTng) and contributed to the Linux kernel. I would like to be a package maintainer for PhotoCollage [1], which I also develop upstream. I submitted the package for review [2], can someone look at it? :) Thanks! [1]: https://github.com/adrienverge/PhotoCollage [2]: https://bugzilla.redhat.com/show_bug.cgi?id=1073978 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Proposal: Don't show applications in the software center with XPM icons
On Fri, 2014-03-07 at 12:57 +0100, Tim Lauridsen wrote: The quaility of an application has nothing todo, with at fancy icon, not showning the icon is ok, but don't show the application is not IMO what will be the next ? qt apps ? gtk2 apps Consider the option of assuming good faith. - ajax -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F20 Self Contained Change: Snapshot and Rollback Tool
On Mar 7, 2014, at 6:31 AM, Josh Boyer jwbo...@fedoraproject.org wrote: On Thu, Mar 6, 2014 at 6:52 PM, Chris Murphy li...@colorremedies.com wrote: On Mar 6, 2014, at 4:27 PM, Orion Poplawski or...@cora.nwra.com wrote: Other developers: OS Installer Support for LVM Thin Provisioning Release engineering: N/A (not a System Wide Change) Policies and guidelines: N/A (not a System Wide Change) [1] https://fedoraproject.org/wiki/Changes/InstallerLVMThinProvisioningSupport I this project dead? I'm casting about to tools to manage lvm snapshots and roller-derby sounded promising. Any other tools out there? There's a recent snapshot/rollback thread on the desktop list that relates to this. LVM thin provisioning support is in the Fedora 20 installer (it fails to produce a bootable system, the post-install fix for which is listed in Fedora 20 common bugs). However, if OSTree is used, then there isn't a hard requirement on either LVM Thin Provisioning or Btrfs. I don't think that's accurate. Which part? OSTree doesn't require either LVM thinp or Btrfs. It works on plain ext4 or XFS. OSTree doesn't touch /home from what I remember. It is only concerned with /usr and to as minimal a degree as possible /etc. People likely still want snapshot and rollback for their actual _data_ as well. Orion didn't mention /home, and Roller Derby doesn't directly address it either. Both yum-plugin-fs-snapshot and snapper can, but snapshots coincide with system updates. More useful is a regularly timed snapshot of the user's home, .e.g. hourly with age based clean-up. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Proposal: Don't show applications in the software center with XPM icons
On 7 March 2014 14:08, Michael Catanzaro mcatanz...@gnome.org wrote: Microsoft, Apple, and Google set requirements that apps must follow if they want to appear in the software center in order to ensure a good user experience. This is something I absolutely want to do. We already rate the applications in GNOME 3.12 depending on how many positive attributes they have (the star ratings) and I think it's fine to set a minimum standard and slowly raise the bar over time. Showing 500 applications that hits some absolute minimum level is much better than showing an additional 500 basically crap applications. Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F20 Self Contained Change: Snapshot and Rollback Tool
On 03/07/2014 09:10 AM, Chris Murphy wrote: On Mar 7, 2014, at 6:31 AM, Josh Boyer jwbo...@fedoraproject.org wrote: On Thu, Mar 6, 2014 at 6:52 PM, Chris Murphy li...@colorremedies.com wrote: On Mar 6, 2014, at 4:27 PM, Orion Poplawski or...@cora.nwra.com wrote: Other developers: OS Installer Support for LVM Thin Provisioning Release engineering: N/A (not a System Wide Change) Policies and guidelines: N/A (not a System Wide Change) [1] https://fedoraproject.org/wiki/Changes/InstallerLVMThinProvisioningSupport I this project dead? I'm casting about to tools to manage lvm snapshots and roller-derby sounded promising. Any other tools out there? Orion didn't mention /home, and Roller Derby doesn't directly address it either. Both yum-plugin-fs-snapshot and snapper can, but snapshots coincide with system updates. More useful is a regularly timed snapshot of the user's home, .e.g. hourly with age based clean-up. I'm actually not that interested in tying in with yum updates etc. I'm just looking for a tool that might help with managing LVM snapshots in general - and specifically for managing snapshots of VMs. Something I could perhaps say have take a snapshot every X hours and keep the latest Y snapshots. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Read this if your package includes a status notifier / system tray icon
Am 07.03.2014 18:16, schrieb Dan Williams: On Fri, 2014-03-07 at 00:18 +0100, Kevin Kofler wrote: * change requests that would have broken compatibility with the existing implementations of the protocol already in wide use for little to no practical benefit, such as nitpicking about the names of some D-Bus methods. So just because something is in use, but hasn't been standardized or been through any kind of standardization discussion, it should automatically be adopted as-is? I think not... in case of changes gaining less to zero - YES you can't make vague specifications not forbid naming things in a way, wait months and years until it is widely used and then come out and say oh and now we strictly say how to use it and expect everybody out there to change any existing code that happens way too often in the open source world while in a company you get instantly fired acting that way and demand all others to sped their time for changes you enforce if you can't prove a very good reason for doing so signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F20 Self Contained Change: Snapshot and Rollback Tool
On Mar 7, 2014, at 6:51 AM, Miloslav Trmač m...@volny.cz wrote: 2014-03-07 14:31 GMT+01:00 Josh Boyer jwbo...@fedoraproject.org: remember. It is only concerned with /usr and to as minimal a degree as possible /etc. People likely still want snapshot and rollback for their actual _data_ as well. (Choosing a random point in the conversation...) I'm starting to think that snapshots are never the right tool, at best a local optimization: For the OS and application code and static data: What we really want is the ability to reinstall/redeploy this data if it became lost or corrupted. We don't really want point-in-time snapshots; snapshots are only a local optimization allowing us to redeploy the version that has been installed yesterday. An ideal technology would allow instant deployment of both old and new versions (redeploying and old version and deploying a new version have structurally the same effect on a filesystem), then snapshots wouldn't be needed. I find for my use case that snapshots are frequently the right tool. But that's because of the workflow/use case I have. Snapshots aren't inherently good. If Fedora.next is to be more stable/production oriented than previous Fedora's, then the problem Roller Derby is attempting to solve also changes. I think OSTree may eventually address the OS/application coherent updates problem better than the far less granular snapshot strategies to date, but it remains to be seen if we're going to have the same problem or concerns that initiate the desire for rollbacks in the first place. If all we're looking to do in the near term is make yum/dnf and Gnome offline updates safer, that could happen relatively quickly with existing tools. But it would require a hard dependency on either LVM thinp or Btrfs snapshots, and changes to perform the update in a chroot on the snapshots rather than the active tree. But that's still significantly easier than maintaining dozens or hundreds of snapshots which both yum-plugin-fs-snapshot and snapper do. Windows and OS X don't do atomic updates either. Windows essentially becomes unusable as updates are applied. OS X application updates require the application to be quit first, which it'll offer to do and then relaunch after the update; while system updates are applied only after user logout, and then the system reboots. But both their OS trees (system binaries minus apps) are static. They're essentially identical on every deployment. So they have a known initial quantity and quality, being updated. So they don't have nearly as much failsafe testing of the actual update process because of this. The updates themselves just don't fail. Therefore a rollback is a reinstallation. They don't even keep the old kernel around when it's updated, while our GRUB menu to fallback to the prior kernel is a kind of rollback. So it sounds to me like OSTree could enable maybe a dozen common trees (rather than almost infinite today). Since they're common, they're also relatively stable, aided by the fact their start and end states during the course of an update are known. But multiple trees are also more flexible than the Windows/OS X paradigm where they have basically one tree, the only variation of which is its version as provided by those companies. For users' data: What we really want is backups—definitely on a different disk, ideally off-site. An ideal technology would allow continuous replication of the data elsewhere. Snaphots are at best a way to quickly access a backup from the past hour, but are not at all a replacement for a backup. Right. Whether GF2 or Gluster or other, I'd like local SSD performance for my home, with a (nearly) syncronous local network replicant, and an async offsite. My preference is a time based snapshot, and that is like any other user data, it gets replicated to the network (be it a NAS or an ARM gluster cluster), and that's replicated offsite. For configuration: What we really want is a VCS, dealing with changesets, documenting who has changed what, when and why. Snapshots are a really poor VCS. Obviously we don't have all that technology that we really want, or at least not in a way that is ready to deploy, but we kind of have snapshots. Let's just not think that snapshots are right. To do VCS correctly requires application opt-in, and an API to manage it. How do I get revision control with file formats that don't support it like RTF, txt, PNG, TIFF, etc? Well it's non-trivial because when I share the document via email or copy it to a thumb drive, it necessarily contains only one version: current. Yet when it's backed up and restored, versions must present? So where and how are the versions stored, and how does the user interact with the application in an intuitive manner? One possible idea: http://arstechnica.com/apple/2011/07/mac-os-x-10-7/14/#versioning-internals This isn't using fs snapshots at all. Chris
Re: Read this if your package includes a status notifier / system tray icon
On Fri, Mar 7, 2014 at 12:22 PM, Reindl Harald wrote: in case of changes gaining less to zero - YES If a single desktop environment wants to just implement something, they can go ahead and do so but that doesn't make it a real specification. For other desktop environments to adopt it, it needs to be a collaborative and shared effort. Part of that is addressing concerns and bringing more clarity so that multiple implementations are compatible. Unstated assumptions lead precisely to the kind of problems you are talking about. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F20 Self Contained Change: Snapshot and Rollback Tool
On Mar 7, 2014, at 10:04 AM, Orion Poplawski or...@cora.nwra.com wrote: On 03/07/2014 09:10 AM, Chris Murphy wrote: On Mar 7, 2014, at 6:31 AM, Josh Boyer jwbo...@fedoraproject.org wrote: On Thu, Mar 6, 2014 at 6:52 PM, Chris Murphy li...@colorremedies.com wrote: On Mar 6, 2014, at 4:27 PM, Orion Poplawski or...@cora.nwra.com wrote: Other developers: OS Installer Support for LVM Thin Provisioning Release engineering: N/A (not a System Wide Change) Policies and guidelines: N/A (not a System Wide Change) [1] https://fedoraproject.org/wiki/Changes/InstallerLVMThinProvisioningSupport I this project dead? I'm casting about to tools to manage lvm snapshots and roller-derby sounded promising. Any other tools out there? Orion didn't mention /home, and Roller Derby doesn't directly address it either. Both yum-plugin-fs-snapshot and snapper can, but snapshots coincide with system updates. More useful is a regularly timed snapshot of the user's home, .e.g. hourly with age based clean-up. I'm actually not that interested in tying in with yum updates etc. I'm just looking for a tool that might help with managing LVM snapshots in general - and specifically for managing snapshots of VMs. Something I could perhaps say have take a snapshot every X hours and keep the latest Y snapshots. I don't think Roller Derby applies here. Virt-manager and virsh support VM snapshots. You could schedule snapshots with a script using virsh. But I don't know that it will create LVM snapshots, and even if it did you wouldn't want it to because they're slow. There soon will be LVM thinp support in libvirt but I don't think it's there yet. Instead, use qcow2 files for this. In my Fedora 20 installation as a benchmarking tool tests, the fastest installs I got were Btrfs in the guest, writing into a qcow2 file with xattr +C on a Btrfs host, with the unsafe cache setting. Even plain ext4 on an LV wasn't faster. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Read this if your package includes a status notifier / system tray icon
Am 07.03.2014 18:33, schrieb Rahul Sundaram: On Fri, Mar 7, 2014 at 12:22 PM, Reindl Harald wrote: in case of changes gaining less to zero - YES If a single desktop environment wants to just implement something, they can go ahead and do so but that doesn't make it a real specification. For other desktop environments to adopt it, it needs to be a collaborative and shared effort. Part of that is addressing concerns and bringing more clarity so that multiple implementations are compatible. Unstated assumptions lead precisely to the kind of problems you are talking about i know that all and aware that it is not perfect but if others adopt something existing and already widely used they hardly can demand to change all existing code if you take the word specification strong you need also to refuse any RFC because request for comments is not a spacification by it's meaning and at least you have to forget any draft RFC, some of them are used for decades and where never finished but nobody changes them and say and that is now the standard, anyhting out there with different behavior is no longer standard confrom honestly you should be careful in general with specification and standard because there are only a few institutions world wide in the position to define a standard at all the rest are de-facto standards signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Read this if your package includes a status notifier / system tray icon
Hi On Fri, Mar 7, 2014 at 12:59 PM, Reindl Harald wrote: i know that all and aware that it is not perfect but if others adopt something existing and already widely used they hardly can demand to change all existing code There is no need to assume that clarifying something requires changing existing code and changing existing code doesn't necessarily require breaking compatibility and if you are bothered by breakages, you should be rallying against KDE dropping XEmbed as well but that isn't really a practical viewpoint. if you take the word specification strong you need also to refuse any RFC Only if you take it out of context http://www.freedesktop.org/wiki/Specifications/ Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: review swap: cscppc, cswrap
Hi Mukundan, On Friday, March 07, 2014 09:29:09 nonamedotc wrote: I have taken cswrap for review. I will take cscppc also after finishing cswrap. thank you very much for taking the reviews! Kamil -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Proposal: Don't show applications in the software center with XPM icons
On Fri, Mar 7, 2014 at 12:53 PM, Reindl Harald h.rei...@thelounge.netwrote: Am 07.03.2014 18:16, schrieb Ryan Lerch: IMHO, the proposal was less of let's remove ugly icons and more lets hide applications that use icons in this particular format that doesn't support the features of the software application IMHO you did not read the proposal itself scroll down - i pasted it again in this message IMHO Ryan is exactly correct - and you're coming off as a bit condescending. The proposal is about a particular image format which doesn't scale well to the size we need in the software center and doesn't have an alpha channel. It's not a judgement on the design of the icon. It is still possible to have ugly icons, they just have to be in PNG, GIF or SVG format and that is why and look very bad defined by the format is flawed if you take a small bitmap and scale it up it will look bad, no matter how well it's designed otherwise. That's just a limitation of the format, and saying so is not flawed. Original-Nachricht Betreff: Proposal: Don't show applications in the software center with XPM icons Datum: Thu, 6 Mar 2014 15:41:00 + Von: Richard Hughes hughsi...@gmail.com An: Development discussions related to Fedora devel@lists.fedoraproject.org XPM is an old standard for icons used by a very small number of desktop packages in Fedora. The XPM icons are normally small, mostly 8 bit, and usually without an alpha channel and look very bad in the software center. I'm going to propose for F21 that we drop support for XPM in the metadata extractor and only show apps with GIF, PNG and SVG icons. The list of affected GUI applications is here: TeXmacs cycle flamerobin gnurobots linsmith mup pari-gp pgadmin3 qtel qucs xsensors As usual, I'd like to push packagers to get upstream to ship a more modern (and high resolution, *with* alpha channel) icon in PNG or SVG format, but packagers can also just replace the icon referenced in the .desktop file if upstream is unwilling / dead and a good replacement is available. Comments welcome, -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Proposal: Don't show applications in the software center with XPM icons
Am 07.03.2014 20:42, schrieb Przemek Klosowski: On 03/07/2014 11:21 AM, Richard Hughes wrote: On 7 March 2014 14:08, Michael Catanzaro mcatanz...@gnome.org wrote: Microsoft, Apple, and Google set requirements that apps must follow if they want to appear in the software center in order to ensure a good user experience. This is something I absolutely want to do. We already rate the applications in GNOME 3.12 depending on how many positive attributes they have (the star ratings) and I think it's fine to set a minimum standard and slowly raise the bar over time. Showing 500 applications that hits some absolute minimum level is much better than showing an additional 500 basically crap applications. This decision should belong to the user, though. It's one thing to default to showing only five-star applications (GTK2, icon with transparency, AppData with translations) while allowing the user to widen the criteria to show more applications. It is quite another thing to make an unilateral decision to take out an entire class that fails to satisfy some arbitrary requirement. I do realize that the app installer becomes more complex, with the 'number of stars' selector, and having to make up application data that the app itself failed to provide, but I think cost/benefit justifies that effort. I feel old and cranky arguing this point but the app markets for portable devices are a _counterexample_ to a thesis that pretty metadata guarantees better application quality. At least on portable devices the old-line stuff simply does not install so it is irrelevant; on Fedora it can be installed and would be useful to someone, if only they can discover its existence when using the pretty, default application installer. As another data point, I just introduced 'units' to another person that missed it in spite of being in the business of scientific data/calculations. Fedora should make it easier, not more difficult, for people to discover such useful things. *exactly* my point and even if i do not use any GUI for install/update packages i care about because others should have the same options as i had many years ago to find their *alternative* to Windows/OSX signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Summary/Minutes from today's FESCo Meeting (2014-03-05)
On Fri, 2014-03-07 at 12:17 +0100, Petr Viktorin wrote: On 03/07/2014 10:59 AM, H. Guémar wrote: Hi, I don't think that worrying about perpetuating offensive stereotypes is specifc to the US, we have similar controversies in Europe: http://en.wikipedia.org/wiki/Banania#Controversy http://en.wikipedia.org/wiki/Zwarte_Piet#Controversies Well, read the second article. 92% of the Dutch public don't perceive Zwarte Piet as racist. I'm not saying it is or is not, or that it should or should not be fixed; I'm saying that there is a culture where this is not perceived as a big deal, as opposed to USA where political correctness is a big deal. Please, keep the term 'political correctness' out of it, as it is an inherently problematic term. It was invented by one side of the meta-debate as a stick with which to beat the other side, so its use in any ostensibly unbiased evaluation is inappropriate. Anyway, the line between what is acceptable and unacceptable in Fedora should be that no one should be offended by something that directly refers to him or his origins in a negative or hurtful way. My point is that the list him/her and his/her origins seems rather arbitrary. Why is e.g. his/her religion not on the list? There is at least one starkly obvious difference there, which is that you choose your religious beliefs and affiliations; you do not choose your race/color/general genetic origin. Still, drawing a line that simple would imply we could go around joyfully insulting religions left right and centre, and mostly people tend to refrain from doing that out of politeness if nothing else. But still, it seems like an important factor to consider. -- 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 https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Summary/Minutes from today's FESCo Meeting (2014-03-05)
On Fri, Mar 7, 2014 at 10:44 PM, Adam Williamson awill...@redhat.com wrote: On Fri, 2014-03-07 at 12:17 +0100, Petr Viktorin wrote: On 03/07/2014 10:59 AM, H. Guémar wrote: Hi, I don't think that worrying about perpetuating offensive stereotypes is specifc to the US, we have similar controversies in Europe: http://en.wikipedia.org/wiki/Banania#Controversy http://en.wikipedia.org/wiki/Zwarte_Piet#Controversies Well, read the second article. 92% of the Dutch public don't perceive Zwarte Piet as racist. I'm not saying it is or is not, or that it should or should not be fixed; I'm saying that there is a culture where this is not perceived as a big deal, as opposed to USA where political correctness is a big deal. Please, keep the term 'political correctness' out of it, as it is an inherently problematic term. It was invented by one side of the meta-debate as a stick with which to beat the other side, so its use in any ostensibly unbiased evaluation is inappropriate. Anyway, the line between what is acceptable and unacceptable in Fedora should be that no one should be offended by something that directly refers to him or his origins in a negative or hurtful way. My point is that the list him/her and his/her origins seems rather arbitrary. Why is e.g. his/her religion not on the list? There is at least one starkly obvious difference there, which is that you choose your religious beliefs and affiliations; you do not choose your race/color/general genetic origin. Well people can choose to not be offended by random images / texts / whatever. There is is the option of just ignore. But unfortunatly a lot of people don't think that way. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Summary/Minutes from today's FESCo Meeting (2014-03-05)
On Fri, 2014-03-07 at 22:52 +0100, drago01 wrote: There is at least one starkly obvious difference there, which is that you choose your religious beliefs and affiliations; you do not choose your race/color/general genetic origin. Well people can choose to not be offended by random images / texts / whatever. There is is the option of just ignore. That is not a true choice. Ignoring the effect of marginalization that such offensive texts ignore is, effectively, opting into it. I'm gay. I can choose to ignore it when people yell 'faggot!' at me, but it's not a choice I should be forced, required or expected to make, and in a sense, it feels like a betrayal to the group being discriminated against to do so. Not speaking out is, in a sense, tantamount to accepting that sort of treatment as OK. (Not to criticize those in this or other commonly-discriminated-against groups who do choose to ignore offensive acts; there *are* valid reasons to make that choice in some circumstances, but it is not OK to say well, that's just what you should always do.) But unfortunatly a lot of people don't think that way. There are reasons why. -- 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 https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Summary/Minutes from today's FESCo Meeting (2014-03-05)
On Fri, Mar 7, 2014 at 11:33 PM, Adam Williamson awill...@redhat.com wrote: On Fri, 2014-03-07 at 22:52 +0100, drago01 wrote: There is at least one starkly obvious difference there, which is that you choose your religious beliefs and affiliations; you do not choose your race/color/general genetic origin. Well people can choose to not be offended by random images / texts / whatever. There is is the option of just ignore. That is not a true choice. Ignoring the effect of marginalization that such offensive texts ignore is, effectively, opting into it. I'm gay. I can choose to ignore it when people yell 'faggot!' at me, Well there is a difference between a direct attack on you and a random image somewhere. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Summary/Minutes from today's FESCo Meeting (2014-03-05)
Am 07.03.2014 23:33, schrieb Adam Williamson: On Fri, 2014-03-07 at 22:52 +0100, drago01 wrote: There is at least one starkly obvious difference there, which is that you choose your religious beliefs and affiliations; you do not choose your race/color/general genetic origin. Well people can choose to not be offended by random images / texts / whatever. There is is the option of just ignore. That is not a true choice. Ignoring the effect of marginalization that such offensive texts ignore is, effectively, opting into it. I'm gay. I can choose to ignore it when people yell 'faggot!' at me, but it's not a choice I should be forced, required or expected to make, and in a sense, it feels like a betrayal to the group being discriminated against to do so. Not speaking out is, in a sense, tantamount to accepting that sort of treatment as OK. (Not to criticize those in this or other commonly-discriminated-against groups who do choose to ignore offensive acts; there *are* valid reasons to make that choice in some circumstances, but it is not OK to say well, that's just what you should always do.) But unfortunatly a lot of people don't think that way. There are reasons why not really good ones it is indeed a amercian phenomenon always feel personally abused by anything and if there is no actual reason people feel abused because they are ignored - if i seek for a reason to feel abused i will find one - mailing lists with english speakers prove that that is the same as german people are not allowed to criticize isreal even if they are 100% right because of their history while most where even not born at that time what about people live their live and just ignore things they don't like? life would be too easy? so hwat signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Summary/Minutes from today's FESCo Meeting (2014-03-05)
On Fri, 2014-03-07 at 23:57 +0100, drago01 wrote: On Fri, Mar 7, 2014 at 11:33 PM, Adam Williamson awill...@redhat.com wrote: On Fri, 2014-03-07 at 22:52 +0100, drago01 wrote: There is at least one starkly obvious difference there, which is that you choose your religious beliefs and affiliations; you do not choose your race/color/general genetic origin. Well people can choose to not be offended by random images / texts / whatever. There is is the option of just ignore. That is not a true choice. Ignoring the effect of marginalization that such offensive texts ignore is, effectively, opting into it. I'm gay. I can choose to ignore it when people yell 'faggot!' at me, Well there is a difference between a direct attack on you and a random image somewhere. There's a difference in immediacy and degree, but not in kind. It all ultimately contributes to the same effect. -- 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 https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[Test-Announce] 2014-03-10 @ ** 15:00 ** UTC - Fedora QA Meeting
# Fedora Quality Assurance Meeting # Date: 2014-03-10 # Time: ** 15:00 UTC ** (https://fedoraproject.org/wiki/Infrastructure/UTCHowto) # Location: #fedora-meeting on irc.freenode.net Greetings testers! It's meeting time again on Monday! Note that daylight saving time begins over the weekend in North America, and we usually follow the NA changes, so this meeting will be at 15:00 UTC. If you're in North America or somewhere else the daylight savings change kicks in this weekend, the meeting will be at the same local time as usual for you. If you're somewhere where daylight saving kicks in later (or not at all), the meeting will be an hour earlier than usual until daylight saving kicks in in your region. The .next tech specs seem to be firming up, so I thought it'd be interesting to talk about plans for testing to them, and also about storage validation testing in light of the agreements we've made there. == Proposed Agenda Topics == 1. Previous meeting follow-up * adamw and cmurf and anyone else interested to keep watching and driving the product WG discussions on filesystems * adamw to ask fesco to consider KDE release blocking status * adamw to propose disabling of autokarma on depcheck fail (to FESCo) as a stopgap till more reliable depcheck with taskotron 2. Fedora.next plans * desktop technical spec: https://fedoraproject.org/wiki/Workstation/Technical_Specification * server spec: https://fedoraproject.org/wiki/Server/Technical_Specification * Storage validation plan: can we improve it now? * Testing to the specs: how far can we go? 3. Open floor -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ test-announce mailing list test-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/test-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: pdftk retired?
On Fri, Mar 7, 2014 at 9:32 AM, Jaroslav Reznik wrote: Sorry I am missing something. Why can't we keep the old pdftk that works with itext2? Check the whole thread - because of GCJ dependency. iText is second issue. The first could be fixed by rewrite of offending part of code to Java but someone would have to do it first. That's how I understand this situation. The only things I read in the thread are GCJ is abandoned and we really want to get rid of GCJ. Am I supposed to come to the conclusion that the GCJ package is dropped from Fedora? If so, where is this decision made? Why was it made without consulting GCJ users? We have so many abandoned projects packaged in Fedora. I don't understand the rush to drop one of them. If GCJ is not dropped, what is the reason for retiring pdftk then? (sorry it's Friday night, my deduction skill are at their lowest) Best, Orcan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Broken dependencies: perl-PDL
perl-PDL has broken dependencies in the epel-7 tree: On ppc64: perl-PDL-2.7.0-2.el7.1.ppc64 requires perl(PDL::Slatec) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-HTML-Mason/f19] (6 commits) ...Merge cleanup.
Summary of changes: 2206752... - Rebuilt for https://fedoraproject.org/wiki/Fedora_20_Mass (*) 4aba44b... Perl 5.18 rebuild (*) a31a458... Upstream update. (*) 6eb97de... Upstream update. (*) 60eb7fe... Upstream update. (*) 22cc415... Merge cleanup. (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-HTML-Mason/f19: 6/6] Merge cleanup.
commit 22cc415bfa4491c90a5f12e3bf64a0b1ca228a28 Author: Ralf Corsépius corse...@fedoraproject.org Date: Fri Mar 7 08:58:01 2014 +0100 Merge cleanup. perl-HTML-Mason.spec | 12 1 files changed, 0 insertions(+), 12 deletions(-) --- diff --git a/perl-HTML-Mason.spec b/perl-HTML-Mason.spec index df9a8f0..f739710 100644 --- a/perl-HTML-Mason.spec +++ b/perl-HTML-Mason.spec @@ -94,18 +94,6 @@ make test - Upstream update. - Filter duplicate Requires:. -* Tue Oct 15 2013 Ralf Corsépius corse...@fedoraproject.org - 1:1.52-1 -- Upstream update. - -* Fri Aug 16 2013 Ralf Corsépius corse...@fedoraproject.org - 1:1.51-1 -- Upstream update. - -* Fri Aug 09 2013 Petr Pisar ppi...@redhat.com - 1:1.50-3 -- Perl 5.18 rebuild - -* Sat Aug 03 2013 Fedora Release Engineering rel-...@lists.fedoraproject.org - 1:1.50-2 -- Rebuilt for https://fedoraproject.org/wiki/Fedora_20_Mass_Rebuild - * Thu Mar 21 2013 Ralf Corsépius corse...@fedoraproject.org - 1:1.50-1 - Upstream update. - Reflect Source0-URL having changed. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
File Locale-Maketext-Lexicon-1.00.tar.gz uploaded to lookaside cache by corsepiu
A file has been added to the lookaside cache for perl-Locale-Maketext-Lexicon: 51acf0cb00cc01a2c8f560d74dd6c593 Locale-Maketext-Lexicon-1.00.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Locale-Maketext-Lexicon] Upstream update.
commit 53959ba8189a399c795ca10ac6f13b14c6e0ef01
Author: Ralf Corsépius corse...@fedoraproject.org
Date: Fri Mar 7 10:05:51 2014 +0100
Upstream update.
.gitignore|2 +-
perl-Locale-Maketext-Lexicon.spec |5 -
sources |2 +-
3 files changed, 6 insertions(+), 3 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index ba92686..6f7b7a6 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1 @@
-/Locale-Maketext-Lexicon-0.99.tar.gz
+/Locale-Maketext-Lexicon-1.00.tar.gz
diff --git a/perl-Locale-Maketext-Lexicon.spec
b/perl-Locale-Maketext-Lexicon.spec
index 95d7572..ae7c8e7 100644
--- a/perl-Locale-Maketext-Lexicon.spec
+++ b/perl-Locale-Maketext-Lexicon.spec
@@ -1,5 +1,5 @@
Name: perl-Locale-Maketext-Lexicon
-Version: 0.99
+Version: 1.00
Release: 1%{?dist}
Summary: Extract translatable strings from source
License: MIT
@@ -75,6 +75,9 @@ make test
%{_mandir}/man3/*
%changelog
+* Fri Mar 07 2014 Ralf Corsépius corse...@fedoraproject.org - 1.00-1
+- Upstream update.
+
* Tue Feb 04 2014 Ralf Corsépius corse...@fedoraproject.org - 0.99-1
- Upstream update.
- Remove redundant explicit R: perl(YAML::Loader).
diff --git a/sources b/sources
index be60663..3d7effd 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-c88e75b607a424c04613765cebb5 Locale-Maketext-Lexicon-0.99.tar.gz
+51acf0cb00cc01a2c8f560d74dd6c593 Locale-Maketext-Lexicon-1.00.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Locale-Maketext-Lexicon/f20] Upstream update.
Summary of changes: 53959ba... Upstream update. (*) (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
File IO-All-0.59.tar.gz uploaded to lookaside cache by pghmcfc
A file has been added to the lookaside cache for perl-IO-All: 9273e98b35032f8a6eaff5db3681abb9 IO-All-0.59.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-IO-All] Update to 0.59
commit 677b2fe4253a32e19e7519a7fde17b54460bdd20
Author: Paul Howarth p...@city-fan.org
Date: Fri Mar 7 10:23:30 2014 +
Update to 0.59
- New upstream release 0.59
- Fix possible infinite loop in t/accept.t (GH#42)
- Fix yet another utf8 validation issue (GH#38)
- Fix warnings running t/tie.t on Windows (GH#37)
perl-IO-All.spec |8 +++-
sources |2 +-
2 files changed, 8 insertions(+), 2 deletions(-)
---
diff --git a/perl-IO-All.spec b/perl-IO-All.spec
index 73c836c..5e4200f 100644
--- a/perl-IO-All.spec
+++ b/perl-IO-All.spec
@@ -1,5 +1,5 @@
Name: perl-IO-All
-Version:0.58
+Version:0.59
Release:1%{?dist}
Summary:IO::All Perl module
License:GPL+ or Artistic
@@ -94,6 +94,12 @@ make %{?_smp_mflags} test RELEASE_TESTING=1
%{_mandir}/man3/IO::All::Temp.3pm*
%changelog
+* Fri Mar 7 2014 Paul Howarth p...@city-fan.org - 0.59-1
+- Update to 0.59
+ - Fix possible infinite loop in t/accept.t (GH#42)
+ - Fix yet another utf8 validation issue (GH#38)
+ - Fix warnings running t/tie.t on Windows (GH#37)
+
* Mon Mar 3 2014 Paul Howarth p...@city-fan.org - 0.58-1
- Update to 0.58
- Fix canonpath on MSWin32
diff --git a/sources b/sources
index 1d76298..7b88a21 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-b3b45f9b20311ddb104947dfd6615448 IO-All-0.58.tar.gz
+9273e98b35032f8a6eaff5db3681abb9 IO-All-0.59.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-IO-All/epel7] Update to 0.59
Summary of changes: 677b2fe... Update to 0.59 (*) (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-IO-All] Created tag perl-IO-All-0.59-1.fc21
The lightweight tag 'perl-IO-All-0.59-1.fc21' was created pointing to: 677b2fe... Update to 0.59 -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-IO-All] Created tag perl-IO-All-0.59-1.el7
The lightweight tag 'perl-IO-All-0.59-1.el7' was created pointing to: 677b2fe... Update to 0.59 -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1073861] New: please provide epel7 builds
https://bugzilla.redhat.com/show_bug.cgi?id=1073861 Bug ID: 1073861 Summary: please provide epel7 builds Product: Fedora Version: rawhide Component: perl-Getopt-Simple Assignee: jan.kle...@gmail.com Reporter: psime...@redhat.com QA Contact: extras...@fedoraproject.org CC: jan.kle...@gmail.com, perl-devel@lists.fedoraproject.org The racoon2 package in epel7 depends on perl-Getopt-Simple which is present in Fedora and most likely epel6 but not in epel7. Please start the epel7 branch and provide builds. See: https://fedoraproject.org/wiki/EPEL/epel7/Requests -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=dUU4dD9xwfa=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
File ExtUtils-Helpers-0.022.tar.gz uploaded to lookaside cache by pghmcfc
A file has been added to the lookaside cache for perl-ExtUtils-Helpers: cf4fd6f8caa6daac33bc9e93162b ExtUtils-Helpers-0.022.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-ExtUtils-Helpers] Update to 0.022
commit 6b99baa9c39453ee5dbdb5b5c2c015addd8e7b95
Author: Paul Howarth p...@city-fan.org
Date: Fri Mar 7 13:55:49 2014 +
Update to 0.022
- New upstream release 0.022
- Cleaned up remains of former functions
- Skip IO layers on 5.8 for 5.6 compatibility
- Don't swallow pl2bat exceptions
- Drop patch for using Text::ParseWords 3.24; even EL-5 has it
ExtUtils-Helpers-0.016-old-Text::ParseWords.patch | 11 ---
perl-ExtUtils-Helpers.spec| 30 +++-
sources |2 +-
3 files changed, 17 insertions(+), 26 deletions(-)
---
diff --git a/perl-ExtUtils-Helpers.spec b/perl-ExtUtils-Helpers.spec
index aca8e01..fb83a3a 100644
--- a/perl-ExtUtils-Helpers.spec
+++ b/perl-ExtUtils-Helpers.spec
@@ -1,18 +1,14 @@
-# We don't really need Text::ParseWords ≥ 3.24
-%global old_tpw %(perl -MText::ParseWords -e 'print
(($Text::ParseWords::VERSION) 3.24 ? 1 : 0);' 2/dev/null || echo 0)
-
# Test suite needs patching if we have Test::More 0.88
%global old_test_more %(perl -MTest::More -e 'print (($Test::More::VERSION)
0.88 ? 1 : 0);' 2/dev/null || echo 0)
Name: perl-ExtUtils-Helpers
-Version: 0.021
-Release: 4%{?dist}
+Version: 0.022
+Release: 1%{?dist}
Summary: Various portability utilities for module builders
Group: Development/Libraries
License: GPL+ or Artistic
URL: https://metacpan.org/release/ExtUtils-Helpers
Source0:
http://cpan.metacpan.org/authors/id/L/LE/LEONT/ExtUtils-Helpers-%{version}.tar.gz
-Patch2:ExtUtils-Helpers-0.016-old-Text::ParseWords.patch
Patch3:ExtUtils-Helpers-0.021-old-Test::More.patch
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(id -nu)
BuildArch: noarch
@@ -26,11 +22,15 @@ BuildRequires: perl(File::Basename)
BuildRequires: perl(File::Copy)
BuildRequires: perl(File::Spec::Functions)
BuildRequires: perl(Module::Load)
-BuildRequires: perl(Text::ParseWords) = 3.22
+BuildRequires: perl(strict)
+BuildRequires: perl(Text::ParseWords) = 3.24
+BuildRequires: perl(warnings)
# Test Suite
BuildRequires: perl(Cwd)
-BuildRequires: perl(File::Find)
-BuildRequires: perl(File::Temp)
+BuildRequires: perl(File::Spec)
+BuildRequires: perl(IO::Handle)
+BuildRequires: perl(IPC::Open3)
+BuildRequires: perl(lib)
BuildRequires: perl(Test::More)
# Release Tests
# perl-Pod-Coverage-TrustPod - perl-Pod-Eventual - perl-Mixin-Linewise -
@@ -50,11 +50,6 @@ modules.
%prep
%setup -q -n ExtUtils-Helpers-%{version}
-# We don't really need Text::ParseWords ≥ 3.24
-%if %{old_tpw}
-%patch2
-%endif
-
# Test suite needs patching if we have Test::More 0.88
%if %{old_test_more}
%patch3
@@ -85,6 +80,13 @@ rm -rf %{buildroot}
%{_mandir}/man3/ExtUtils::Helpers::Windows.3pm*
%changelog
+* Fri Mar 7 2014 Paul Howarth p...@city-fan.org - 0.022-1
+- Update to 0.022
+ - Cleaned up remains of former functions
+ - Skip IO layers on 5.8 for 5.6 compatibility
+ - Don't swallow pl2bat exceptions
+- Drop patch for using Text::ParseWords 3.24; even EL-5 has it
+
* Wed Sep 4 2013 Paul Howarth p...@city-fan.org - 0.021-4
- Skip the release tests when bootstrapping
diff --git a/sources b/sources
index 1488811..c0054e3 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-94aa8eaf92def26d9af0cb25fcb1570f ExtUtils-Helpers-0.021.tar.gz
+cf4fd6f8caa6daac33bc9e93162b ExtUtils-Helpers-0.022.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-Language-Expr
perl-Language-Expr has broken dependencies in the rawhide tree: On x86_64: perl-Language-Expr-0.19-4.fc19.noarch requires perl(:MODULE_COMPAT_5.16.2) On i386: perl-Language-Expr-0.19-4.fc19.noarch requires perl(:MODULE_COMPAT_5.16.2) On armhfp: perl-Language-Expr-0.19-4.fc19.noarch requires perl(:MODULE_COMPAT_5.16.2) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-Catalyst-Controller-HTML-FormFu
perl-Catalyst-Controller-HTML-FormFu has broken dependencies in the rawhide tree: On x86_64: perl-Catalyst-Controller-HTML-FormFu-0.09004-4.fc20.noarch requires perl(HTML::FormFu::MultiForm) On i386: perl-Catalyst-Controller-HTML-FormFu-0.09004-4.fc20.noarch requires perl(HTML::FormFu::MultiForm) On armhfp: perl-Catalyst-Controller-HTML-FormFu-0.09004-4.fc20.noarch requires perl(HTML::FormFu::MultiForm) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: mojomojo
mojomojo has broken dependencies in the rawhide tree: On x86_64: mojomojo-1.10-1.fc20.noarch requires perl(HTML::FormFu::Element::reCAPTCHA) On i386: mojomojo-1.10-1.fc20.noarch requires perl(HTML::FormFu::Element::reCAPTCHA) On armhfp: mojomojo-1.10-1.fc20.noarch requires perl(HTML::FormFu::Element::reCAPTCHA) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-Language-Prolog-Yaswi
perl-Language-Prolog-Yaswi has broken dependencies in the rawhide tree: On x86_64: perl-Language-Prolog-Yaswi-0.21-16.fc21.x86_64 requires libswipl.so.6.6.1()(64bit) On i386: perl-Language-Prolog-Yaswi-0.21-16.fc21.i686 requires libswipl.so.6.6.1 On armhfp: perl-Language-Prolog-Yaswi-0.21-16.fc21.armv7hl requires libswipl.so.6.6.1 Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Email-Abstract/epel7] Do not BR packages that are not present in el7
commit 6154c8d5bf3654510f44dce7f86edc87113acab5
Author: Lubomir Rintel lkund...@v3.sk
Date: Fri Mar 7 15:02:58 2014 +0100
Do not BR packages that are not present in el7
perl-Email-Abstract.spec | 10 --
1 files changed, 8 insertions(+), 2 deletions(-)
---
diff --git a/perl-Email-Abstract.spec b/perl-Email-Abstract.spec
index ee6f5cd..ad6336d 100644
--- a/perl-Email-Abstract.spec
+++ b/perl-Email-Abstract.spec
@@ -1,6 +1,6 @@
Name: perl-Email-Abstract
Version:3.007
-Release:1%{?dist}
+Release:1%{?dist}.1
Summary:Unified interface to mail representations
Group: Development/Libraries
License:GPL+ or Artistic
@@ -17,8 +17,11 @@ BuildRequires: perl(Test::More) = 0.96
BuildRequires: perl(lib)
BuildRequires: perl(strict)
BuildRequires: perl(warnings)
-BuildRequires: perl(Mail::Message), perl(Scalar::Util)
+BuildRequires: perl(Scalar::Util)
+%if 0%{?rhel} == 0
+BuildRequires: perl(Mail::Message)
BuildRequires: perl(Email::MIME)
+%endif
BuildArch: noarch
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo $version))
@@ -55,6 +58,9 @@ make test
%{_mandir}/man3/*.3*
%changelog
+* Fri Mar 07 2014 Lubomir Rintel (GoodData) lubo.rin...@gooddata.com -
3.007-1.1
+- Do not BR packages that are not present in el7
+
* Wed Jan 08 2014 Ralf Corsépius corse...@fedoraproject.org - 3.007-1
- Upstream update (RHBZ #1049728).
- Reflect upstream BR:-changes.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-ExtUtils-Helpers] Created tag perl-ExtUtils-Helpers-0.022-1.fc21
The lightweight tag 'perl-ExtUtils-Helpers-0.022-1.fc21' was created pointing to: 6b99baa... Update to 0.022 -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1073956] New: perl-Data-Dumper-2.151 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1073956 Bug ID: 1073956 Summary: perl-Data-Dumper-2.151 is available Product: Fedora Version: rawhide Component: perl-Data-Dumper Keywords: FutureFeature, Triaged Assignee: ppi...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: mmasl...@redhat.com, perl-devel@lists.fedoraproject.org, ppi...@redhat.com Latest upstream release: 2.151 Current version/release in Fedora Rawhide: 2.145-292.fc21 URL: http://search.cpan.org/dist/Data-Dumper/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=GsWdaF2N4Ca=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1073957] New: perl-ExtUtils-ParseXS-3.24 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1073957 Bug ID: 1073957 Summary: perl-ExtUtils-ParseXS-3.24 is available Product: Fedora Version: rawhide Component: perl-ExtUtils-ParseXS Keywords: FutureFeature, Triaged Assignee: ppi...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: perl-devel@lists.fedoraproject.org, ppi...@redhat.com Latest upstream release: 3.24 Current version/release in Fedora Rawhide: 3.22-1.fc21 URL: http://search.cpan.org/dist/ExtUtils-ParseXS/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=KKh0Wke2Kca=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: [perl-Email-Abstract/epel7] Do not BR packages that are not present in el7
On 03/07/2014 03:03 PM, Lubomir Rintel wrote:
commit 6154c8d5bf3654510f44dce7f86edc87113acab5
Author: Lubomir Rintel lkund...@v3.sk
Date: Fri Mar 7 15:02:58 2014 +0100
Do not BR packages that are not present in el7
perl-Email-Abstract.spec | 10 --
1 files changed, 8 insertions(+), 2 deletions(-)
---
diff --git a/perl-Email-Abstract.spec b/perl-Email-Abstract.spec
index ee6f5cd..ad6336d 100644
--- a/perl-Email-Abstract.spec
+++ b/perl-Email-Abstract.spec
@@ -1,6 +1,6 @@
Name: perl-Email-Abstract
Version:3.007
-Release:1%{?dist}
+Release:1%{?dist}.1
Summary:Unified interface to mail representations
Group: Development/Libraries
License:GPL+ or Artistic
@@ -17,8 +17,11 @@ BuildRequires: perl(Test::More) = 0.96
BuildRequires: perl(lib)
BuildRequires: perl(strict)
BuildRequires: perl(warnings)
-BuildRequires: perl(Mail::Message), perl(Scalar::Util)
+BuildRequires: perl(Scalar::Util)
+%if 0%{?rhel} == 0
+BuildRequires: perl(Mail::Message)
BuildRequires: perl(Email::MIME)
+%endif
Are you sure this step is helpful?
These requirements also are run-time requirements, which means all you
are doing is to remove BR: which expose runtime-requirements,
but actually are shipping a crippled package.
IMO, the correct fix would be to add the missing perl-modules to rhel
and not to remove these BRs.
Ralf
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1073958] New: perl-Net-GitHub-0.57 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1073958 Bug ID: 1073958 Summary: perl-Net-GitHub-0.57 is available Product: Fedora Version: rawhide Component: perl-Net-GitHub Keywords: FutureFeature, Triaged Assignee: psab...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: mmasl...@redhat.com, perl-devel@lists.fedoraproject.org, psab...@redhat.com Latest upstream release: 0.57 Current version/release in Fedora Rawhide: 0.56-1.fc21 URL: http://search.cpan.org/dist/Net-GitHub/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=KgRj86WBMea=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1073964] New: perl-Test-Strict-0.23 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1073964 Bug ID: 1073964 Summary: perl-Test-Strict-0.23 is available Product: Fedora Version: rawhide Component: perl-Test-Strict Keywords: FutureFeature, Triaged Assignee: psab...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: mmasl...@redhat.com, perl-devel@lists.fedoraproject.org, psab...@redhat.com Latest upstream release: 0.23 Current version/release in Fedora Rawhide: 0.22-2.fc20 URL: http://search.cpan.org/dist/Test-Strict/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=CvKra6tJXFa=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1073967] New: perl-XML-LibXML-2.0111 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1073967 Bug ID: 1073967 Summary: perl-XML-LibXML-2.0111 is available Product: Fedora Version: rawhide Component: perl-XML-LibXML Keywords: FutureFeature, Triaged Assignee: jples...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: jples...@redhat.com, mmasl...@redhat.com, perl-devel@lists.fedoraproject.org Latest upstream release: 2.0111 Current version/release in Fedora Rawhide: 2.0110-1.fc21 URL: http://search.cpan.org/dist/XML-LibXML/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=IpFb7yXN70a=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1073968] New: perl-XML-LibXSLT-1.89 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1073968 Bug ID: 1073968 Summary: perl-XML-LibXSLT-1.89 is available Product: Fedora Version: rawhide Component: perl-XML-LibXSLT Keywords: FutureFeature, Triaged Assignee: jples...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: jples...@redhat.com, perl-devel@lists.fedoraproject.org, z...@fastmail.fm Latest upstream release: 1.89 Current version/release in Fedora Rawhide: 1.88-1.fc21 URL: http://search.cpan.org/dist/XML-LibXSLT/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=sDhN91B1jMa=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1073861] please provide epel7 builds
https://bugzilla.redhat.com/show_bug.cgi?id=1073861 Jan Klepek jan.kle...@gmail.com changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #1 from Jan Klepek jan.kle...@gmail.com --- i was wondering when epel7 will be ready, this answers that. branch requested -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=0voxTEMAJ2a=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[389-devel] please review: Ticket 47729 - Directory Server crashes if shutdown during a replication initialization
https://fedorahosted.org/389/ticket/47729 https://fedorahosted.org/389/attachment/ticket/47729/0001-Ticket-47729-Directory-Server-crashes-if-shutdown-du.patch -- Mark Reynolds 389 Development Team Red Hat, Inc mreyno...@redhat.com -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
[389-devel] Please review: [389 Project] #47735: e_uniqueid fails to set if an entry is a conflict entry
https://fedorahosted.org/389/ticket/47735
https://fedorahosted.org/389/attachment/ticket/47735/0001-Ticket-47735-e_uniqueid-fails-to-set-if-an-entry-is-.patch
Bug Description:
When an entry is turned to be a conflict entry, its nsUniqueId has
a mdcsn info as a subtype like this:
nsUniqueId;mdcsn-5319136f00020001: c5e0d787-a58f11e3-b7f9dfd1-acc3d5e4
In this case, the attribute type is assigned to the berval type
as follows:
type.bv_val = nsUniqueId;mdcsn-5319136f00020001
type.bv_len = 37
The subtyped stateinfo is processed in
str2entry_state_information_from_type,
which modifies type.bv_val to nsUniqueId, but type.bv_len remains 37.
str2entry_fast has this logic to set e_uniqueid, where the nsUniqueId
with stateinfo fails to set the value to e_uniqueid.
if ( type.bv_len == 10
PL_strncasecmp (type.bv_val, nsUniqueId, type.bv_len) == 0 ){
Fix Description: This patch resets the length of the type with the
basetype length 10 before the if expression is called for setting
e_uniqueid.
--
389-devel mailing list
389-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-devel
[389-devel] Please review (take 2): [389 Project] #47735: e_uniqueid fails to set if an entry is a conflict entry
https://fedorahosted.org/389/attachment/ticket/47735/0001-Ticket-47735-e_uniqueid-fails-to-set-if-an-entry-is-.2.patch
git patch file (master; take 2) -- merged 2 args into 1 in
str2entry_state_information_from_type (Thanks to Rich for his
suggestion).
Noriko Hosoi wrote:
https://fedorahosted.org/389/ticket/47735
https://fedorahosted.org/389/attachment/ticket/47735/0001-Ticket-47735-e_uniqueid-fails-to-set-if-an-entry-is-.patch
Bug Description:
When an entry is turned to be a conflict entry, its nsUniqueId has
a mdcsn info as a subtype like this:
nsUniqueId;mdcsn-5319136f00020001:
c5e0d787-a58f11e3-b7f9dfd1-acc3d5e4
In this case, the attribute type is assigned to the berval type
as follows:
type.bv_val = nsUniqueId;mdcsn-5319136f00020001
type.bv_len = 37
The subtyped stateinfo is processed in
str2entry_state_information_from_type,
which modifies type.bv_val to nsUniqueId, but type.bv_len remains 37.
str2entry_fast has this logic to set e_uniqueid, where the nsUniqueId
with stateinfo fails to set the value to e_uniqueid.
if ( type.bv_len == 10
PL_strncasecmp (type.bv_val, nsUniqueId, type.bv_len) == 0 ){
Fix Description: This patch resets the length of the type with the
basetype length 10 before the if expression is called for setting
e_uniqueid.
--
389-devel mailing list
389-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-devel
--
389-devel mailing list
389-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-devel
[389-devel] Please review: [389 Project] #47737: Under heavy stress, failure of turning a tombstone into glue makes the server hung
https://fedorahosted.org/389/ticket/47737
https://fedorahosted.org/389/attachment/ticket/47737/0001-Ticket-47737-Under-heavy-stress-failure-of-turning-a.patch
Turning a tombstone entry to a glue entry is done in a while loop
(create_glue_entry:urp_glue.c) Unless the transformation is successful
(or LDAP_NO_SUCH_OBJECT), it cannot exit from the loop. But under a
stress, there could be a tombstone and a conflict entry coexist, and
do_create_glue_entry keeps returning LDAP_ALREADY_EXISTS. In such a case,
we need to give up greating a glue.
{{{
[..] NSMMReplicationPlugin - conn=7 op=1939 csn=531a144300070003:
Can't created glue entry
ou=test,ou=projects,o=bees,ou=organizations,dc=cvsdude,dc=com
uniqueid=ee68e001-a62811e3-bc8ab407-12c832a2, error 68
[..] NSMMReplicationPlugin - conn=7 op=1939 csn=531a144300070003:
Can't created glue entry
ou=test,ou=projects,o=bees,ou=organizations,dc=cvsdude,dc=com
uniqueid=ee68e001-a62811e3-bc8ab407-12c832a2, error 68
[..] NSMMReplicationPlugin - conn=7 op=1939 csn=531a144300070003:
Can't created glue entry
ou=test,ou=projects,o=bees,ou=organizations,dc=cvsdude,dc=com
uniqueid=ee68e001-a62811e3-bc8ab407-12c832a2, error 68
[..]
}}}
{{{
Thread 32 (Thread 0x7f6ac77fe700 (LWP 24906)):
#0 0x7f6ae4e3e74d in fsync () at ../sysdeps/unix/syscall-
template.S:81
#1 0x7f6ae5492e8b in pt_Fsync (fd=0x7f6ae81b15c0) at
../../../nspr/pr/src/pthreads/ptio.c:1530
#2 0x7f6ae6e8afe7 in vslapd_log_error (fp=0x7f6ae81b15c0,
subsystem=0x7f6adb19ad90 NSMMReplicationPlugin,
fmt=0x7f6adb1a6fa0 %s: Can't created glue entry %s uniqueid=%s, error
%d\n, ap=0x7f6ac77f7438, locked=1)
at ldap/servers/slapd/log.c:1953
#3 0x7f6ae6e8aa52 in slapd_log_error_proc_internal
(subsystem=0x7f6adb19ad90 NSMMReplicationPlugin,
fmt=0x7f6adb1a6fa0 %s: Can't created glue entry %s uniqueid=%s, error
%d\n, ap_err=0x7f6ac77f7420,
ap_file=0x7f6ac77f7438) at ldap/servers/slapd/log.c:1809
#4 0x7f6ae6e8b1d5 in slapi_log_error (severity=0,
subsystem=0x7f6adb19ad90 NSMMReplicationPlugin,
fmt=0x7f6adb1a6fa0 %s: Can't created glue entry %s uniqueid=%s, error
%d\n) at ldap/servers/slapd/log.c:1994
#5 0x7f6adb17a6b3 in create_glue_entry (pb=0x7f6aa40b7f90,
sessionid=0x7f6ac77f7690 conn=7 op=1939 csn=531a144300070003,
dn=0x7f6aa40c6370,
uniqueid=0x7f6aa40bee60 ee68e001-a62811e3-bc8ab407-12c832a2,
opcsn=0x7f6aa40bee40)
at ldap/servers/plugins/replication/urp_glue.c:257
#6 0x7f6adb1791eb in urp_add_resolve_parententry (pb=0x7f6aa40b7f90,
sessionid=0x7f6ac77f7690 conn=7 op=1939 csn=531a144300070003,
entry=0x7f6aa40badf0, parententry=0x0,
opcsn=0x7f6aa40bee40) at ldap/servers/plugins/replication/urp.c:908
#7 0x7f6adb177e29 in urp_add_operation (pb=0x7f6aa40b7f90) at
ldap/servers/plugins/replication/urp.c:165
#8 0x7f6adb15ae22 in multimaster_bepreop_add (pb=0x7f6aa40b7f90) at
ldap/servers/plugins/replication/repl5_plugins.c:711
#9 0x7f6ae6eade99 in plugin_call_func (list=0x7f6ae830fd90,
operation=450, pb=0x7f6aa40b7f90, call_one=0)
at ldap/servers/slapd/plugin.c:1453
#10 0x7f6ae6eadd59 in plugin_call_list (list=0x7f6ae830fd90,
operation=450, pb=0x7f6aa40b7f90)
at ldap/servers/slapd/plugin.c:1415
#11 0x7f6ae6eabfe1 in plugin_call_plugins (pb=0x7f6aa40b7f90,
whichfunction=450) at ldap/servers/slapd/plugin.c:398
#12 0x7f6adc085696 in ldbm_back_add (pb=0x7f6aa40b7f90) at
ldap/servers/slapd/back-ldbm/ldbm_add.c:257
#13 0x7f6ae6e478aa in op_shared_add (pb=0x7f6aa40b7f90) at
ldap/servers/slapd/add.c:681
#14 0x7f6ae6e468b4 in do_add (pb=0x7f6aa40b7f90) at
ldap/servers/slapd/add.c:258
#15 0x7f6ae7379935 in connection_dispatch_operation
(conn=0x7f6ae71e3f48, op=0x7f6aa40b6330, pb=0x7f6aa40b7f90)
at ldap/servers/slapd/connection.c:579
#16 0x7f6ae737b32c in connection_threadmain () at
ldap/servers/slapd/connection.c:2339
#17 0x7f6ae5494c86 in _pt_root (arg=0x7f6ae84eb130) at
../../../nspr/pr/src/pthreads/ptthread.c:204
#18 0x7f6ae4e37d15 in start_thread (arg=0x7f6ac77fe700) at
pthread_create.c:308
#19 0x7f6ae495453d in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:114
}}}
--
389-devel mailing list
389-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-devel
