[EPEL-devel] Fedora EPEL 7 updates-testing report

[updates]

The following Fedora EPEL 7 Security updates need testing:
 Age  URL
 556  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-1087   
dokuwiki-0-0.24.20140929c.el7
 318  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-dac7ed832f   
mcollective-2.8.4-1.el7
  81  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-e0c08a1414   
php-PHPMailer-5.2.16-2.el7
  37  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-23fa04bf1c   
redis-3.2.3-1.el7
  35  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-4b8dd3488d   
knot-1.6.8-1.el7
  20  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-e8f4ff76b3   
chicken-4.11.0-3.el7
   8  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-2a2061ee5f   
php-adodb-5.15-10.el7
   5  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-7e2d0ee701   
wordpress-4.6.1-1.el7
   5  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-12c4b7b928   
php-horde-Horde-Core-2.26.1-1.el7
   5  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-c7c4c1e885   
php-horde-Horde-Mime-Viewer-2.2.1-1.el7
   5  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-175e2d3d7c   
php-horde-Horde-Text-Filter-2.3.5-1.el7
   5  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-f71c0650c3   
php-horde-horde-5.2.12-1.el7
   5  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-77f23b948f   
GraphicsMagick-1.3.25-1.el7
   4  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-0e40142bd3   
pdns-3.4.10-1.el7
   2  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-24caa7d205   
drupal7-google_analytics-2.3-1.el7
   1  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-f1d880ae22   
distribution-gpg-keys-1.7-1.el7 mock-1.2.21-1.el7


The following builds have been pushed to Fedora EPEL 7 updates-testing

csdiff-1.3.1-1.el7
csmock-2.0.1-1.el7
dcap-2.47.10-4.el7
gnome-shell-extension-panel-osd-1-0.19.20160914git42eeb7e.el7

Details about builds:



 csdiff-1.3.1-1.el7 (FEDORA-EPEL-2016-2b916937df)
 Non-interactive tools for processing code scan results in plain-text

Update Information:

- update to latest upstream bugfix release




 csmock-2.0.1-1.el7 (FEDORA-EPEL-2016-2b916937df)
 A mock wrapper for Static Analysis tools

Update Information:

- update to latest upstream bugfix release




 dcap-2.47.10-4.el7 (FEDORA-EPEL-2016-78dde32605)
 Client Tools for dCache

Update Information:

Backport of upstream fixes.




 gnome-shell-extension-panel-osd-1-0.19.20160914git42eeb7e.el7 
(FEDORA-EPEL-2016-b30c253cf5)
 Configure the place where notifications are shown

Update Information:

Fix an error, that only occurs, when the extension gets disabled while a
notification is shown.  Support newest version of gnome-shell.

___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org

[EPEL-devel] Fedora EPEL 6 updates-testing report

[updates]

The following Fedora EPEL 6 Security updates need testing:
 Age  URL
 434  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-7031   
python-virtualenv-12.0.7-1.el6
 428  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-7168   
rubygem-crack-0.3.2-2.el6
 360  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-8156   
nagios-4.0.8-1.el6
 318  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-e2b4b5b2fb   
mcollective-2.8.4-1.el6
 290  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-35e240edd9   
thttpd-2.25b-24.el6
 176  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-30a8346813   
vtun-3.0.1-10.el6
  81  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-db7e78fac7   
php-PHPMailer-5.2.16-2.el6
  74  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-d0e444c5f2   
pypy-5.0.1-4.el6
  35  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-a1450d7fe0   
knot-1.6.8-1.el6
  20  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-8594ed3a53   
chicken-4.11.0-3.el6
   5  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-eb5607d339   
wordpress-4.6.1-1.el6
   5  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-0e948eb4e8   
php-horde-Horde-Core-2.26.1-1.el6
   5  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-e2038f5db3   
php-horde-Horde-Mime-Viewer-2.2.1-1.el6
   5  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-d4f645229a   
php-horde-Horde-Text-Filter-2.3.5-1.el6
   5  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-665fb50899   
php-horde-horde-5.2.12-1.el6
   5  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-4b16af69a6   
varnish-2.1.5-6.el6
   5  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-f2d60f53f3   
GraphicsMagick-1.3.25-1.el6
   2  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-bcc7555c8a   
drupal7-google_analytics-2.3-1.el6
   2  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-204f2f07aa   
drupal7-panels-3.7-1.el6
   1  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-e079d167e3   
distribution-gpg-keys-1.7-1.el6 mock-1.2.21-1.el6


The following builds have been pushed to Fedora EPEL 6 updates-testing

csdiff-1.3.1-1.el6
csmock-2.0.1-1.el6
dcap-2.47.10-4.el6
gnutls30-3.5.4-1.el6
ocserv-0.11.4-1.el6
pcllib-1.12-1.el6

Details about builds:



 csdiff-1.3.1-1.el6 (FEDORA-EPEL-2016-34708df9e0)
 Non-interactive tools for processing code scan results in plain-text

Update Information:

- update to latest upstream bugfix release




 csmock-2.0.1-1.el6 (FEDORA-EPEL-2016-34708df9e0)
 A mock wrapper for Static Analysis tools

Update Information:

- update to latest upstream bugfix release




 dcap-2.47.10-4.el6 (FEDORA-EPEL-2016-d13d51869b)
 Client Tools for dCache

Update Information:

Backport of upstream fixes.




 gnutls30-3.5.4-1.el6 (FEDORA-EPEL-2016-62ed1d7108)
 A TLS protocol implementation

Update Information:

Initial version of the library. Bundled with ocserv which is its user. ocserv
requires gnutls 3.5.4 due to some bugs in previous version, so also bundled on
this update.




 ocserv-0.11.4-1.el6 (FEDORA-EPEL-2016-62ed1d7108)
 OpenConnect SSL VPN server

Update Information:

Initial version of the library. Bundled with ocserv which is its user. ocserv
requires gnutls 3.5.4 due to some bugs in previous version, so also bundled on
this update.




 pcllib-1.12-1.el6 (FEDORA-EPEL-2016-62ed1d7108)
 Portable Coroutine Library (PCL)

Update Information:

Initial version of the library. Bundled with ocserv which is its user. ocserv
requires gnutls 3.5.4 due to some bugs in 

[EPEL-devel] Fedora EPEL 5 updates-testing report

[updates]

The following Fedora EPEL 5 Security updates need testing:
 Age  URL
 826  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2014-1626   
puppet-2.7.26-1.el5
 675  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2014-3849   
sblim-sfcb-1.3.8-2.el5
 318  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-edbea40516   
mcollective-2.8.4-1.el5
 290  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-582c8075e6   
thttpd-2.25b-24.el5
   6  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-b0f7448ed8   
wordpress-4.6.1-1.el5
   6  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-5ae964c48a   
varnish-2.0.6-5.el5
   6  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-a7ac2a3dd8   
GraphicsMagick-1.3.25-1.el5


The following builds have been pushed to Fedora EPEL 5 updates-testing

dcap-2.47.10-4.el5

Details about builds:



 dcap-2.47.10-4.el5 (FEDORA-EPEL-2016-769f111cc3)
 Client Tools for dCache

Update Information:

Backport of upstream fixes.

___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org

[Bug 1376309] New: perl-Tree-1.09 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1376309

Bug ID: 1376309
   Summary: perl-Tree-1.09 is available
   Product: Fedora
   Version: rawhide
 Component: perl-Tree
  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: 1.09
Current version/release in rawhide: 1.08-2.fc25
URL: http://search.cpan.org/dist/Tree/

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

Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.

Based on the information from anitya: 
https://release-monitoring.org/project/10580/

-- 
You are receiving this mail because:
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

[Bug 1375239] perl-Pegex-0.61-1.fc26 FTBFS: Failed test ' Whitespace Tokens (bootstrap compile)'

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1375239



--- Comment #4 from Gerd Pokorra  ---
In the meantime there is YAML-LibYAML-0.73 from rurban. It causes the same
errors in the Pegex tests.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

Re: Please unpush FEDORA-2016-7776983633 on all releases or drop support for libjasper

[Ben Rosser]

On Wed, Sep 14, 2016 at 4:11 PM, Michael Catanzaro 
wrote:

> On Wed, 2016-09-14 at 20:50 +0100, Richard Hughes wrote:
> > Three people gave the update positive
> > karma and I can't believe all three did so without actually opening a
> > JPEG-2000 image in any GTK-using or KDE-using app so there might be
> > something more subtle going on.
>
> I can believe it.
>
> I repeat my call that packages should spend more time in testing. This
> is very far from the first time we've had an update fly past without
> sufficient time for testing. Serious proposal: +3 karma and the update
> can be pushed after one week in testing, otherwise it has to wait two
> weeks. Packages maintainers could still be able to push an update
> through faster, but would be expected to do so only in exceptional
> circumstances, like to respond to a serious regression.
>
> This isn't a very extreme idea.
>
> Michael


Updates to existing packages, perhaps, but I don't think this is a good
idea for *new* packages. My experience is that new package updates rarely
get tested (unless they're something extremely popular), and new packages
have theoretically just been tested by both the maintainer (when packaging
them) and the reviewer (when reviewing them), so there is likely less need
for further testing than there would be for other updates. And also, it
should be significantly less likely for a new package to break things than
it would be for updates to existing packages.

Ben Rosser
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

[Bug 1375239] perl-Pegex-0.61-1.fc26 FTBFS: Failed test ' Whitespace Tokens (bootstrap compile)'

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1375239



--- Comment #3 from Gerd Pokorra  ---
As a workaraund I removed the three tests that fails in build:

https://koji.fedoraproject.org/koji/taskinfo?taskID=15632436

If I use YAML-LibYAML-0.71 on Fedora 24 then I can reproduce the error there.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

Schedule for Thursday's FPC Meeting (2016-09-15 16:00 UTC)

[James Antill]

 Following is the list of topics that will be discussed in the FPC
meeting Thursday at 2016-09-15 16:00 UTC in #fedora-meeting-1 on
irc.freenode.net.

 Local time information (via. rktime):

2016-09-15 09:00 Thu US/Pacific PDT
2016-09-15 12:00 Thu US/Eastern EDT
2016-09-15 16:00 Thu UTC <-
2016-09-15 17:00 Thu Europe/London  BST
2016-09-15 18:00 Thu Europe/Paris  CEST
2016-09-15 18:00 Thu Europe/Berlin CEST
2016-09-15 21:30 Thu Asia/Calcutta  IST
--new day--
2016-09-16 00:00 Fri Asia/Singapore SGT
2016-09-16 00:00 Fri Asia/Hong_Kong HKT
2016-09-16 01:00 Fri Asia/Tokyo JST
2016-09-16 02:00 Fri Australia/BrisbaneAEST

 Links to all tickets below can be found at: 

https://fedorahosted.org/fpc/report/13

= Followups =

#topic #398 Tilde in version
.fpc 398
https://fedorahosted.org/fpc/ticket/398

#topic #558 Application/Library distinction and package
splitting
.fpc 558
https://fedorahosted.org/fpc/ticket/558

#topic #610 Packaging guidelines: Check upstream tarball
signatures
.fpc 610
https://fedorahosted.org/fpc/ticket/610

#topic #645 Clarify policy on obsoleting non-directly-replaced packages
.fpc 645
https://fedorahosted.org/fpc/ticket/645

= New business =

#topic #628 Reserve UID/GID for cassandra (allocation process)
.fpc NNN
https://fedorahosted.org/fpc/ticket/NNN

#topic #646 Versioning the Packaging Guidelines
.fpc 646
https://fedorahosted.org/fpc/ticket/646

= Open Floor = 

 For more complete details, please visit each individual ticket.  The
report of the agenda items can be found at:

https://fedorahosted.org/fpc/report/13

 If you would like to add something to this agenda, you can reply to
this e-mail, file a new ticket at https://fedorahosted.org/fpc,
e-mail me directly, or bring it up at the end of the meeting, during
the open floor topic. Note that added topics may be deferred until
the following meeting. 
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

[Bug 1376269] New: perl-Perl-Critic-Moose-1.05 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1376269

Bug ID: 1376269
   Summary: perl-Perl-Critic-Moose-1.05 is available
   Product: Fedora
   Version: rawhide
 Component: perl-Perl-Critic-Moose
  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: 1.05
Current version/release in rawhide: 1.04-3.fc25
URL: http://search.cpan.org/dist/Perl-Critic-Moose/

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

Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.

Based on the information from anitya: 
https://release-monitoring.org/project/6577/

-- 
You are receiving this mail because:
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

[Bug 1376249] New: perl-Captcha-reCAPTCHA-0.98 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1376249

Bug ID: 1376249
   Summary: perl-Captcha-reCAPTCHA-0.98 is available
   Product: Fedora
   Version: rawhide
 Component: perl-Captcha-reCAPTCHA
  Keywords: FutureFeature, Triaged
  Assignee: ppi...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: iarn...@gmail.com, perl-devel@lists.fedoraproject.org,
ppi...@redhat.com



Latest upstream release: 0.98
Current version/release in rawhide: 0.97-11.fc25
URL: http://search.cpan.org/dist/Captcha-reCAPTCHA/

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

Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.

Based on the information from anitya: 
https://release-monitoring.org/project/6743/

-- 
You are receiving this mail because:
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

[389-devel] Jenkins build is back to normal : 389-DS-NIGHTLY #80

[Jenkins]

See 

--
389-devel mailing list
389-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/389-devel@lists.fedoraproject.org

Re: How to obsolete a subpackage?

[Orion Poplawski]

On 09/14/2016 09:46 AM, David Howells wrote:

Florian Weimer  wrote:


I think if you want silent deletion, you'll have to add “Obsoletes:
binutils-sh64-linux-gnu” to the cross-binutils-common package.


Yeah, the following worked:

@@ -129,6 +133,9 @@ converting addresses to file and line).
 Summary: Cross-build binary utility documentation and translation files
 Group: Development/Tools
 BuildArch: noarch
+%if !%{build_sh64}
+Obsoletes: binutils-sh64-linux-gnu
+%endif
 %description -n %{cross}-binutils-common
 Documentation, manual pages and translation files for cross-build binary image
 generation, manipulation and query tools.

I forgot to put the '!' in the %if condition, which didn't help.

David
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org



Be sure to properly version the obsoletes - something like

Obsoletes: binutils-sh64-linux-gnu < VERSION-RELEASE

Where VERSION-RELEASE is the version-release where you dropped the package.

--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA DivisionFAX: 303-415-9702
3380 Mitchell Lane  or...@cora.nwra.com
Boulder, CO 80301  http://www.cora.nwra.com
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Please unpush FEDORA-2016-7776983633 on all releases or drop support for libjasper

[Michael Catanzaro]

On Wed, 2016-09-14 at 15:11 -0700, Adam Williamson wrote:
> Also...I have the 'affected' jasper-libs on my F24 machine (a
> laptop),
> and I just ran gnome-software on it, and it ran perfectly fine? It
> runs, I can look at app pages (the screenshots render fine)...

Richard said on IRC it only crashes if you also have steam installed.

Michael
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Please unpush FEDORA-2016-7776983633 on all releases or drop support for libjasper

[David Airlie]

I've rebuilt all the jasper packages with the offending patch removed because 
it breaks a lot
of stuff.

I'll see if the owner shows up, and files the errata, otherwise I'll get to it 
in next couple of days,
unless someone wants it done more urgently.

Dave.

- Original Message -
> From: "Matthew Miller" 
> To: "Development discussions related to Fedora" 
> 
> Sent: Thursday, 15 September, 2016 8:46:27 AM
> Subject: Re: Please unpush FEDORA-2016-7776983633 on all releases or drop 
> support for libjasper
> 
> On Wed, Sep 14, 2016 at 03:11:35PM -0700, Adam Williamson wrote:
> > > If I recall correctly, we need libjasper for opencv for openqa, so I'm
> > > not sure we can drop this?
> > yeah, please don't just drop it. if anyone wants to work with me/openQA
> > upstream/both to port it to something else, great, but we do need to
> > cover that usage.
> 
> OpenCV can definitely be built _without_ JPEG 2000 support. I'm not
> sure how much of a loss that would be. I see that Debian is dropping
> JasPer — and looks like that's what they decided to do. (See
> https://release.debian.org/transitions/html/jasper-rm.html and
> https://anonscm.debian.org/git/debian-science/packages/opencv.git/tree/debian/changelog)
> 
> 
> > note, we do have this update installed on all the openQA boxes, and
> > they're all working perfectly fine.
> 
> Probably because openQA is unlikely to use JPEG 2000.
> 
> 
> --
> Matthew Miller
> 
> Fedora Project Leader
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
> 
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Please unpush FEDORA-2016-7776983633 on all releases or drop support for libjasper

[Matthew Miller]

On Wed, Sep 14, 2016 at 03:11:35PM -0700, Adam Williamson wrote:
> > If I recall correctly, we need libjasper for opencv for openqa, so I'm
> > not sure we can drop this?
> yeah, please don't just drop it. if anyone wants to work with me/openQA
> upstream/both to port it to something else, great, but we do need to
> cover that usage.

OpenCV can definitely be built _without_ JPEG 2000 support. I'm not
sure how much of a loss that would be. I see that Debian is dropping
JasPer — and looks like that's what they decided to do. (See 
https://release.debian.org/transitions/html/jasper-rm.html and
https://anonscm.debian.org/git/debian-science/packages/opencv.git/tree/debian/changelog)


> note, we do have this update installed on all the openQA boxes, and
> they're all working perfectly fine.

Probably because openQA is unlikely to use JPEG 2000.


-- 
Matthew Miller

Fedora Project Leader
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Please unpush FEDORA-2016-7776983633 on all releases or drop support for libjasper

[Adam Williamson]

On Wed, 2016-09-14 at 15:53 -0400, Neal Gompa wrote:
> On Wed, Sep 14, 2016 at 3:50 PM, Richard Hughes  wrote:
> Although, perhaps given upstream has not had a release since 2006 and
> we've acquired 14 out-of-tree security patches (and countless others
> for various fixes) perhaps we should drop dep this from applications
> completely?
> 
> 
> 
> 
> ... snip ...
> 
> 
> > libjasper.so.1()(64bit) is needed by (installed) 
> > opencv-2.4.12.3-3.fc24.x86_64
> 
> 
> 
> 
> If I recall correctly, we need libjasper for opencv for openqa, so I'm
> not sure we can drop this?

yeah, please don't just drop it. if anyone wants to work with me/openQA
upstream/both to port it to something else, great, but we do need to
cover that usage.

note, we do have this update installed on all the openQA boxes, and
they're all working perfectly fine.

I generally agree with Matthew on the wider issue here; the update
process isn't really meant to catch every issue ever, and this bug
clearly doesn't break *all* jasper usage (see note about openQA being
fine), so the feedback could well be perfectly legit.

There really *is* an onus on developers as well as testers to provide
appropriate test instructions and to configure updates appropriately.
The autokarma threshold of 3 is only a *default*. Maintainers can make
the number larger or turn autopush off entirely for sensitive updates.

Also...I have the 'affected' jasper-libs on my F24 machine (a laptop),
and I just ran gnome-software on it, and it ran perfectly fine? It
runs, I can look at app pages (the screenshots render fine)...
-- 
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://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Please unpush FEDORA-2016-7776983633 on all releases or drop support for libjasper

[Thomas Daede]

On 09/14/2016 12:50 PM, Richard Hughes wrote:
> Although, perhaps given upstream has not had a release since 2006 and
> we've acquired 14 out-of-tree security patches (and countless others
> for various fixes) perhaps we should drop dep this from applications
> completely?

OpenJPEG has long replaced Jasper as the implementation of choice for
JPEG2000. I think it would be reasonable to drop Jasper and ask
upstreams to port to a different implementation if they still want
JPEG2000 support.
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Fedora Rawhide-20160914.n.0 compose check report

[Fedora compose checker]

Missing expected images:

Cloud_base raw-xz i386
Atomic raw-xz x86_64

Failed openQA tests: 10/92 (x86_64), 4/17 (i386), 1/2 (arm)

Old failures (same test failed in Rawhide-20160913.n.2):

ID: 34358   Test: x86_64 Workstation-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/34358
ID: 34359   Test: x86_64 Workstation-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/34359
ID: 34365   Test: x86_64 Workstation-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/34365
ID: 34366   Test: x86_64 Workstation-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/34366
ID: 34367   Test: i386 Workstation-live-iso install_default
URL: https://openqa.fedoraproject.org/tests/34367
ID: 34368   Test: i386 Workstation-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/34368
ID: 34369   Test: x86_64 Atomic-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/34369
ID: 34378   Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/34378
ID: 34424   Test: x86_64 universal install_iscsi
URL: https://openqa.fedoraproject.org/tests/34424
ID: 34438   Test: x86_64 universal upgrade_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/34438
ID: 34441   Test: x86_64 universal upgrade_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/34441
ID: 34443   Test: x86_64 universal upgrade_2_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/34443
ID: 34446   Test: x86_64 universal upgrade_2_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/34446
ID: 34463   Test: i386 universal upgrade_desktop_32bit
URL: https://openqa.fedoraproject.org/tests/34463
ID: 34464   Test: i386 universal upgrade_2_desktop_32bit
URL: https://openqa.fedoraproject.org/tests/34464

Soft failed openQA tests: 1/92 (x86_64)
(Tests completed, but using a workaround for a known bug)

Old soft failures (same test softfailed in Rawhide-20160913.n.2):

ID: 34370   Test: x86_64 KDE-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/34370

Passed openQA tests: 76/92 (x86_64), 13/17 (i386)

Skipped openQA tests: 6 of 111
-- 
Mail generated by check-compose:
https://git.fedorahosted.org/cgit/fedora-qa.git/tree/check-compose
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

[Bug 1370461] perl-DBIx-Class: FTBFS in rawhide

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1370461

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #2 from Fedora Update System  ---
perl-DBIx-Class-0.082840-2.fc25 has been pushed to the Fedora 25 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2016-9d99d0e000

-- 
You are receiving this mail because:
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

Re: Please unpush FEDORA-2016-7776983633 on all releases or drop support for libjasper

[Bill Nottingham]

Matthew Miller (mat...@fedoraproject.org) said: 
> On Wed, Sep 14, 2016 at 08:50:49PM +0100, Richard Hughes wrote:
> > before pushing the next update? Three people gave the update positive
> > karma and I can't believe all three did so without actually opening a
> > JPEG-2000 image in any GTK-using or KDE-using app so there might be
> > something more subtle going on.
> 
> The update note says this fixes a bunch of CVEs, and there's no test
> plan (https://fedoraproject.org/wiki/QA:SOP_package_test_plan_creation),
> so testers have no guidance. The included conversion command works, and I
> can use `display` to verify that the converted file looks okay.
> 
> I'm not saying this update should have been pushed — but I don't think
> it's _necessarily_ that the testers were hitting +1 without doing
> anything.

I honestly think this is as much of a developer issue as a tester issue.  If
the CVE fix was to silently change the API/ABI of the library, that's on
either upstream or downstream, depending on where the fix came from.  Yes,
you'd like testers to catch that, but it's the sort of update that ideally
doesn't happen to begin with.

Bill
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Please unpush FEDORA-2016-7776983633 on all releases or drop support for libjasper

[Michael Catanzaro]

On Wed, 2016-09-14 at 16:36 -0400, Matthew Miller wrote:
> I'm not saying this update should have been pushed — but I don't
> think
> it's _necessarily_ that the testers were hitting +1 without doing
> anything.

I agree. Time in testing is required to catch such issues.

Honestly, one week in testing probably wouldn't have caught this --
Richard didn't notice until three weeks later -- but there's no chance
if updates keep flying by in just a day or two. I believe Ubuntu
requires all updates wait two weeks to mitigate this risk.

Michael
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Please unpush FEDORA-2016-7776983633 on all releases or drop support for libjasper

[Matthew Miller]

On Wed, Sep 14, 2016 at 09:33:12PM +0100, Richard Hughes wrote:
> > I can believe it.
> Maybe requiring the tester to say *how* they tested it, rather than
> just "LGTM" which means basically nothing.

We do have this technology. :)

However, if we put the burden of figuring out what all needs to be
tested completely on the testers, the net result is going to be more
updates with no feedback at all, and then packagers/developers
complaining that it's too onerous to get an update through — in this
case, one which has a dozen security fixes.

> > I repeat my call that packages should spend more time in testing.
> Totally agree here.

Probably, although just sitting there longer and not getting tested
doesn't actually help.


-- 
Matthew Miller

Fedora Project Leader
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Please unpush FEDORA-2016-7776983633 on all releases or drop support for libjasper

[Matthew Miller]

On Wed, Sep 14, 2016 at 08:50:49PM +0100, Richard Hughes wrote:
> before pushing the next update? Three people gave the update positive
> karma and I can't believe all three did so without actually opening a
> JPEG-2000 image in any GTK-using or KDE-using app so there might be
> something more subtle going on.

The update note says this fixes a bunch of CVEs, and there's no test
plan (https://fedoraproject.org/wiki/QA:SOP_package_test_plan_creation),
so testers have no guidance. The included conversion command works, and I
can use `display` to verify that the converted file looks okay.

I'm not saying this update should have been pushed — but I don't think
it's _necessarily_ that the testers were hitting +1 without doing
anything.


> libjasper.so.1()(64bit) is needed by (installed) LibRaw-0.17.2-1.fc24.x86_64
> libjasper.so.1()(64bit) is needed by (installed)
> gdk-pixbuf2-modules-2.34.0-1.fc24.x86_64
> libjasper.so.1()(64bit) is needed by (installed) dcraw-9.27.0-1.fc24.x86_64
> libjasper.so.1()(64bit) is needed by (installed) gegl-0.2.0-29.fc24.x86_64
> libjasper.so.1()(64bit) is needed by (installed) gimp-2:2.8.18-1.fc24.x86_64
> libjasper.so.1()(64bit) is needed by (installed)
> jasper-devel-1.900.1-33.fc24.x86_64
> libjasper.so.1()(64bit) is needed by (installed) 
> kdelibs-6:4.14.22-1.fc24.x86_64
> libjasper.so.1()(64bit) is needed by (installed) opencv-2.4.12.3-3.fc24.x86_64
> libjasper.so.1()(64bit) is needed by (installed) DevIL-1.7.8-23.fc24.x86_64

Can any of these use OpenJPEG instead? It is a) actively maintained and
b) the official reference standard as of a year ago.

-- 
Matthew Miller

Fedora Project Leader
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Please unpush FEDORA-2016-7776983633 on all releases or drop support for libjasper

[Richard Hughes]

On 14 September 2016 at 21:11, Michael Catanzaro  wrote:
>> I can't believe all three did so without actually opening a
>> JPEG-2000 image in any GTK-using or KDE-using app.
>
> I can believe it.

Maybe requiring the tester to say *how* they tested it, rather than
just "LGTM" which means basically nothing.

> I repeat my call that packages should spend more time in testing.

Totally agree here.

Richard
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Please unpush FEDORA-2016-7776983633 on all releases or drop support for libjasper

[Michael Catanzaro]

On Wed, 2016-09-14 at 20:50 +0100, Richard Hughes wrote:
> -jas_stream_t *jas_stream_memopen(char *buf, int bufsize);
> +jas_stream_t *jas_stream_memopen(char *buf, size_t bufsize);

I should add: it probably needs to use ssize_t (signed size_t) here.
But this function is part of the API, so every dependent app will need
to be rebuilt and packaged into the same bodhi update.

Michael
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Please unpush FEDORA-2016-7776983633 on all releases or drop support for libjasper

[Michael Catanzaro]

On Wed, 2016-09-14 at 20:50 +0100, Richard Hughes wrote:
> Three people gave the update positive
> karma and I can't believe all three did so without actually opening a
> JPEG-2000 image in any GTK-using or KDE-using app so there might be
> something more subtle going on.

I can believe it.

I repeat my call that packages should spend more time in testing. This
is very far from the first time we've had an update fly past without
sufficient time for testing. Serious proposal: +3 karma and the update
can be pushed after one week in testing, otherwise it has to wait two
weeks. Packages maintainers could still be able to push an update
through faster, but would be expected to do so only in exceptional
circumstances, like to respond to a serious regression.

This isn't a very extreme idea.

Michael
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Broken dependencies: perl-Alien-ROOT

[buildsys]

perl-Alien-ROOT has broken dependencies in the rawhide tree:
On aarch64:
perl-Alien-ROOT-5.34.36.1-1.fc26.noarch requires root-core
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://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

Broken dependencies: perl-Data-Alias

[buildsys]

perl-Data-Alias has broken dependencies in the rawhide tree:
On aarch64:
perl-Data-Alias-1.20-2.fc24.aarch64 requires libperl.so.5.22()(64bit)
perl-Data-Alias-1.20-2.fc24.aarch64 requires perl(:MODULE_COMPAT_5.22.1)
On x86_64:
perl-Data-Alias-1.20-2.fc24.x86_64 requires libperl.so.5.22()(64bit)
perl-Data-Alias-1.20-2.fc24.x86_64 requires perl(:MODULE_COMPAT_5.22.1)
On i386:
perl-Data-Alias-1.20-2.fc24.i686 requires libperl.so.5.22
perl-Data-Alias-1.20-2.fc24.i686 requires perl(:MODULE_COMPAT_5.22.1)
On armhfp:
perl-Data-Alias-1.20-2.fc24.armv7hl requires libperl.so.5.22
perl-Data-Alias-1.20-2.fc24.armv7hl requires perl(:MODULE_COMPAT_5.22.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://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

Re: Please unpush FEDORA-2016-7776983633 on all releases or drop support for libjasper

[Neal Gompa]

On Wed, Sep 14, 2016 at 3:50 PM, Richard Hughes  wrote:
> Although, perhaps given upstream has not had a release since 2006 and
> we've acquired 14 out-of-tree security patches (and countless others
> for various fixes) perhaps we should drop dep this from applications
> completely?

... snip ...

> libjasper.so.1()(64bit) is needed by (installed) opencv-2.4.12.3-3.fc24.x86_64

If I recall correctly, we need libjasper for opencv for openqa, so I'm
not sure we can drop this?


-- 
真実はいつも一つ！/ Always, there's only one truth!
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Please unpush FEDORA-2016-7776983633 on all releases or drop support for libjasper

[Richard Hughes]

Can we get somebody to revert
https://bodhi.fedoraproject.org/updates/FEDORA-2016-7776983633 please.
The update was built to fix CVE-2015-5203 which fixes a double free
when opening corrupt JPEG-2000 files but in doing-so breaks quite a
few apps in the desktop spin causing them to exit with an assert deep
in libjasper.

In the update the function jas_stream_memopen has been changed:

-jas_stream_t *jas_stream_memopen(char *buf, int bufsize);
+jas_stream_t *jas_stream_memopen(char *buf, size_t bufsize);

Unless I'm misunderstood things dramatically, size_t is basically
*unsigned* long integer, but this function offers a feature where if
the bufsize is -1 the buffer is realloc'd as needed. gdk-pixbuf2 uses
this feature for JPEG-2000 files. However, as size_t represents only
positive numbers, a conversion takes place to some very high number
and the allocation fails.

This affects any GNOME application that uses GTK, so for me causes
nautilus to crash when looking at my Downloads folder and GNOME
Software when enabling the Steam plugin functionality. If you see
"jas_stream.c:1044: mem_write: Assertion `ret == cnt' failed." then
you're affected too. Can we get someone to actually test the build
before pushing the next update? Three people gave the update positive
karma and I can't believe all three did so without actually opening a
JPEG-2000 image in any GTK-using or KDE-using app so there might be
something more subtle going on.

Although, perhaps given upstream has not had a release since 2006 and
we've acquired 14 out-of-tree security patches (and countless others
for various fixes) perhaps we should drop dep this from applications
completely?

libjasper.so.1()(64bit) is needed by (installed) LibRaw-0.17.2-1.fc24.x86_64
libjasper.so.1()(64bit) is needed by (installed)
gdk-pixbuf2-modules-2.34.0-1.fc24.x86_64
libjasper.so.1()(64bit) is needed by (installed) dcraw-9.27.0-1.fc24.x86_64
libjasper.so.1()(64bit) is needed by (installed) gegl-0.2.0-29.fc24.x86_64
libjasper.so.1()(64bit) is needed by (installed) gimp-2:2.8.18-1.fc24.x86_64
libjasper.so.1()(64bit) is needed by (installed)
jasper-devel-1.900.1-33.fc24.x86_64
libjasper.so.1()(64bit) is needed by (installed) kdelibs-6:4.14.22-1.fc24.x86_64
libjasper.so.1()(64bit) is needed by (installed) opencv-2.4.12.3-3.fc24.x86_64
libjasper.so.1()(64bit) is needed by (installed) DevIL-1.7.8-23.fc24.x86_64

Richard
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

[Bug 1372492] perl-Config-Model-Tester-2.057 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1372492

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-Config-Model-Tester-2. |perl-Config-Model-Tester-2.
   |057-1.fc26  |057-1.fc26
   |perl-Config-Model-Tester-2. |perl-Config-Model-Tester-2.
   |057-1.fc25  |057-1.fc25
   ||perl-Config-Model-Tester-2.
   ||057-1.fc24



-- 
You are receiving this mail because:
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

[Bug 1372492] perl-Config-Model-Tester-2.057 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1372492



--- Comment #7 from Fedora Update System  ---
perl-Config-Model-Tester-2.057-1.fc24 has been pushed to the Fedora 24 stable
repository. If problems still persist, please make note of it in this bug
report.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

Re: How to handle "weakly maintained packages" [was Re: F24, small backward steps]

[Neal Gompa]

On Wed, Sep 14, 2016 at 2:35 PM, Josh Boyer  wrote:
> On Wed, Sep 14, 2016 at 2:25 PM, Neal Gompa  wrote:
>> On Wed, Sep 14, 2016 at 1:52 PM, Matthew Miller
>>  wrote:
>>> On Wed, Sep 14, 2016 at 01:27:45PM -0400, Josh Boyer wrote:
 > Yes, THIS. Our current model does not really allow us to express this
 > at all -- there's "orphaned", but that's not user-visible.
 Our current model actually could express this though.  We could put
 the weakly maintained packages in COPRs, and editions that wish to
 include them can do so in their default repos.  There is also the
 previous idea of the curated COPR playground.
 We have the tools, we just need to use them.
>>>
>>> One problem is that weakly maintained packages are often dependencies
>>> and libraries. They're weakly maintained because the person packaging
>>> them never really cared about them for their own sake, only for some
>>> other application which needs them. That application may be strongly
>>> maintained, but the various deps only updated when some issue affects
>>> that app. I guess the whole thing could go into a COPR in this kind of
>>> case, but I'm not sure that's quite right.
>>>
>>>
>>
>> The fundamental problem with this in COPR is that COPR doesn't know
>> how to do automatic rebuilds based on changes in the repos it uses.
>> For example, with my OBS projects, when the Rawhide repodata is
>> updated, OBS automatically properly bumps the Release and rebuilds the
>> package so that it works properly with whatever changed in the
>> repositories. COPR lacks this capability, but it is needed for
>> something like that to work.
>
> Koji doesn't do this either, yet we seem to get by.  I'm not sure I
> follow why auto-rebuild is a requirement versus a (very) nice to have.
>

Koji doesn't do it, because packagers are supposed to rebuild things
when they update stuff. When everything is in one place (a single Koji
instance), it's easy enough to pull off. And Bodhi catches dep errors
on submission of updates if the checks are enabled.
Once things are scattered across different systems or instances of
systems, it gets really messy and broken.


-- 
真実はいつも一つ！/ Always, there's only one truth!
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Handling bugs which are fixed in upstream, but not released yet

[Stephen Gallagher]

On 09/14/2016 08:41 AM, Igor Gnatenko wrote:
> Hi,
> 
> I have question, how you handle bugs where fix already available in
> upstream, but you don't want to backport that fix yet. What you do
> with bug in our trash-box (bugzilla.redhat.com)?
> 
> Probably you use whiteboard to indicate where it was fixed, close bug
> and write into comment that it will be fixed in next upstream release
> or ...?
> 

Many projects use the POST state for this. What it means in that context is that
a patch exists and is waiting to be added to a package. Ideally, a comment or
See Also link would be added to the BZ to let any interested party know where it
could be found if they needed to.

A comment to the effect of "patch is available upstream, but due to the
complexity it won't hit Fedora until the next upstream release" would be useful
as well.

This allows the bug to also stay open, so when you go to submit a Bodhi update,
it's going to show up in the list of possible BZs to close with this update,
which will remind you to mark it or pull it in if you haven't done so yet.



signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Triaging RH Bugzilla and forwarding bugs upstream (Was: F24, small backward steps)

[Jóhann B . Guðmundsson]

On 09/14/2016 05:46 PM, Matthew Miller wrote:


What I'd_really_  love to see is a layer separating bug trackers from
end users.


That layer already exist in the form of irc forum and askbot does it not?
( someone from the support sub-community can provide information how 
successful these are )


And from my former QA days I cant recall that end users issues being 
mistakenly reported in bugzilla existed in the first place or was a 
problem for that matter.
( The steps that are necessary to file a report to begin with, act as a 
natural filter that prevents that from happening )
I'm only aware of one bug ( arguably misfiled ) against systemd in the 
distribution that might fall under that category but that is entirely 
due to the fact those changes slipped through the distribution 
documentation and announcement radar ( which arguably should have been 
covered in Gnome ) so end users/administrators simply dont know how they 
are custom to configure things does not work in certain scenarios with 
certain components.


JBG
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: How to handle "weakly maintained packages" [was Re: F24, small backward steps]

[Josh Boyer]

On Wed, Sep 14, 2016 at 2:25 PM, Neal Gompa  wrote:
> On Wed, Sep 14, 2016 at 1:52 PM, Matthew Miller
>  wrote:
>> On Wed, Sep 14, 2016 at 01:27:45PM -0400, Josh Boyer wrote:
>>> > Yes, THIS. Our current model does not really allow us to express this
>>> > at all -- there's "orphaned", but that's not user-visible.
>>> Our current model actually could express this though.  We could put
>>> the weakly maintained packages in COPRs, and editions that wish to
>>> include them can do so in their default repos.  There is also the
>>> previous idea of the curated COPR playground.
>>> We have the tools, we just need to use them.
>>
>> One problem is that weakly maintained packages are often dependencies
>> and libraries. They're weakly maintained because the person packaging
>> them never really cared about them for their own sake, only for some
>> other application which needs them. That application may be strongly
>> maintained, but the various deps only updated when some issue affects
>> that app. I guess the whole thing could go into a COPR in this kind of
>> case, but I'm not sure that's quite right.
>>
>>
>
> The fundamental problem with this in COPR is that COPR doesn't know
> how to do automatic rebuilds based on changes in the repos it uses.
> For example, with my OBS projects, when the Rawhide repodata is
> updated, OBS automatically properly bumps the Release and rebuilds the
> package so that it works properly with whatever changed in the
> repositories. COPR lacks this capability, but it is needed for
> something like that to work.

Koji doesn't do this either, yet we seem to get by.  I'm not sure I
follow why auto-rebuild is a requirement versus a (very) nice to have.

josh
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Handling bugs which are fixed in upstream, but not released yet

[Matěj Cepl]

On 2016-09-14, 12:41 GMT, Igor Gnatenko wrote:
> Probably you use whiteboard to indicate where it was fixed, 
> close bug and write into comment that it will be fixed in next 
> upstream release or ...?

Either External Trackers (if the tracker is defined), or "See 
Also" with URL of the ticket.

Matěj

-- 
https://matej.ceplovi.cz/blog/, Jabber: mc...@ceplovi.cz
GPG Finger: 3C76 A027 CA45 AD70 98B5  BC1D 7920 5802 880B C9D8
  
Pain is inevitable, but misery is optional. We cannot avoid pain,
but we can avoid joy.
 -- Tim Hansel


pgpxcmkDw3T_E.pgp
Description: PGP signature
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: How to handle "weakly maintained packages" [was Re: F24, small backward steps]

[Neal Gompa]

On Wed, Sep 14, 2016 at 1:52 PM, Matthew Miller
 wrote:
> On Wed, Sep 14, 2016 at 01:27:45PM -0400, Josh Boyer wrote:
>> > Yes, THIS. Our current model does not really allow us to express this
>> > at all -- there's "orphaned", but that's not user-visible.
>> Our current model actually could express this though.  We could put
>> the weakly maintained packages in COPRs, and editions that wish to
>> include them can do so in their default repos.  There is also the
>> previous idea of the curated COPR playground.
>> We have the tools, we just need to use them.
>
> One problem is that weakly maintained packages are often dependencies
> and libraries. They're weakly maintained because the person packaging
> them never really cared about them for their own sake, only for some
> other application which needs them. That application may be strongly
> maintained, but the various deps only updated when some issue affects
> that app. I guess the whole thing could go into a COPR in this kind of
> case, but I'm not sure that's quite right.
>
>

The fundamental problem with this in COPR is that COPR doesn't know
how to do automatic rebuilds based on changes in the repos it uses.
For example, with my OBS projects, when the Rawhide repodata is
updated, OBS automatically properly bumps the Release and rebuilds the
package so that it works properly with whatever changed in the
repositories. COPR lacks this capability, but it is needed for
something like that to work.


-- 
真実はいつも一つ！/ Always, there's only one truth!
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Triaging RH Bugzilla and forwarding bugs upstream

[Jóhann B . Guðmundsson]

On 09/14/2016 05:03 PM, Jason L Tibbitts III wrote:


"RC" == Ralf Corsepius  writes:

RC> - A package triggering too many BZs.
RC> IMO, this should question the package's quality.

A package with a million users is going to get more bugs than a package
with ten regardless of the package quality.  I have a feeling that a
rather large number of people use Gnome.


Most of them would be duplicates ( otherwise Gnome is in serious trouble 
maintenance wise )


When I was exclusively triaging reports against a single components 
systemd for couple of years the report classification was roughly one 
third real bugs, one third RFE's and one third misfiles.
With my former QA hat on and thus involved in the triage process from 
it's inception as well as being the last person along with Mike Ruckman 
( afaik no one else has done it since then)  looking into if the triage 
process could be revived for what the fourth time  I think I can say 
without a shadow of doubt that triaging will never work in the 
distribution due to wide variety of reasons which I will not go into 
details in this response. ( Triaging can be made to work to certain 
extent but not here in Fedora )


In the end of the day it's packager maintainer(s) responsibility to act 
as the liaison between upstream and downstream, triage, test and forward 
bugs upstream if they are not distribution specific and solve them 
downstream if they are.


If the package maintainer does not have the time to do that he or she 
needs to find more co-maintainers to distribute the load of him or 
herself or drop the maintenance of the package in the distribution 
altogether and hope that someone else that has the required time steps 
up to maintain it but that is unlikely if he or she could not find 
co-maintainer(s) to begin with in the distribution to distribute the load.


If the above as in package maintainer(s) for whatever reasons will not 
perform their due maintenance diligence then there is but two 
alternative and that's to drop the poorly maintained packaged ( since 
it's doing the distribution end user disservice ) or redirect reporters 
directly upstream but that has it's own set of pros and cons.


JBG
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

How to handle "weakly maintained packages" [was Re: F24, small backward steps]

[Matthew Miller]

On Wed, Sep 14, 2016 at 01:27:45PM -0400, Josh Boyer wrote:
> > Yes, THIS. Our current model does not really allow us to express this
> > at all -- there's "orphaned", but that's not user-visible.
> Our current model actually could express this though.  We could put
> the weakly maintained packages in COPRs, and editions that wish to
> include them can do so in their default repos.  There is also the
> previous idea of the curated COPR playground.
> We have the tools, we just need to use them.

One problem is that weakly maintained packages are often dependencies
and libraries. They're weakly maintained because the person packaging
them never really cared about them for their own sake, only for some
other application which needs them. That application may be strongly
maintained, but the various deps only updated when some issue affects
that app. I guess the whole thing could go into a COPR in this kind of
case, but I'm not sure that's quite right.


-- 
Matthew Miller

Fedora Project Leader
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Triaging RH Bugzilla and forwarding bugs upstream (Was: F24, small backward steps)

[Matthew Miller]

On Wed, Sep 14, 2016 at 09:44:06AM -0500, Jason L Tibbitts III wrote:
> I disagree in general; when the bug volume exceeds a certain amount
> bugzilla basically becomes useless.  However, it would be really nice if
> _someone_ looked at RH bugzilla for those packages and did something
> with them.
> 
> We used to have "bugzappers".  What we really need is someone to do
> triage and to forward bugs on to upstream when appropriate.  This
> obviously requires volunteers.

What I'd _really_ love to see is a layer separating bug trackers from
end users. In IT, there's often a distinction made between "incidents"
and "problems"¹. An incident is Something Bad That Happened to A User;
this may be caused by one or more problems. (And a single problem may
cause multiple incidents.) In big IT shops, it's common to have
helpdesk tickets for incidents, and those may then get linked to bug
tickets on the backend. (Either user-visible or not, depending on the
culture.)

So, what if we steer end users away from Bugzilla and bug-trackers
completely² and to Ask Fedora³ instead? The triage team could
supplement the people already working there to help people with their
questions, and rather than linking bug trackers, we could create a tool
where high-rep users could push a button to 1) create a bug in the
appropriate one and 2) add an answer like:

  "This looks like it's caused by a bug in $whatever. I've created a
   ticket in the tracking system for that project, which you can see at
   $link. If this is sufficient, feel free to mark this as accepted.
   Otherwise, this will be updated as the underlying bug is worked on."




1. http://www.itskeptic.org/content/how-itil-gets-incident-vs-problem-wrong

2. To be more nuanced: we wouldn't shut it down for technical users,
   which for this purpose I will definie as "users able to identify the
   right bugzilla for a particular problem", but we would change all of
   our end-user-facing documentation to recommend the help system
   instead.

3. Or something like it. Ask Fedora could use some development work,
   but that's another story :)
-- 
Matthew Miller

Fedora Project Leader
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: _unitdir macro

[gil]

Il 14/09/2016 19:27, Kevin Fenzi ha scritto:

On Wed, 14 Sep 2016 19:11:43 +0200
gil  wrote:


hi

_unitdir is no more a vaild rpm macros?

i get:

RPM build errors:
  File must begin with "/": %{_unitdir}/wildfly.service

Task info: http://koji.fedoraproject.org/koji/taskinfo?taskID=15632734

thanks in advance

You are missing a:

BuildRequires: systemd

(the systemd package contains that macro definition).

kevin


yes thanks! ... i missing my mind also ...
regards
.g



--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org


--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Triaging RH Bugzilla and forwarding bugs upstream (Was: F24, small backward steps)

[Ralf Corsepius]

On 09/14/2016 07:01 PM, Josh Boyer wrote:


My impression is, in many cases, it's ego, which prevents to acknowledge
they need "to divert".


I'm not sure what you mean by divert.


This is a Dinglish "politically correct" phrase to describe "to 
partially give up/step down", "make room to others" and "hire more people".


What I mean, if you feel being overloaded, be honest to your self and 
"downsize" your tasks/duties.


Ralf
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24, small backward steps

[Josh Boyer]

On Wed, Sep 14, 2016 at 1:23 PM, Matthew Miller
 wrote:
> On Wed, Sep 14, 2016 at 04:44:38PM +, Debarshi Ray wrote:
>> (a) The maintenance status of a package is not a binary variable. It
>> is easy to imagine a third state - weakly maintained.
>
> Yes, THIS. Our current model does not really allow us to express this
> at all -- there's "orphaned", but that's not user-visible.

Our current model actually could express this though.  We could put
the weakly maintained packages in COPRs, and editions that wish to
include them can do so in their default repos.  There is also the
previous idea of the curated COPR playground.

We have the tools, we just need to use them.

josh
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: _unitdir macro

[Kevin Fenzi]

On Wed, 14 Sep 2016 19:11:43 +0200
gil  wrote:

> hi
> 
> _unitdir is no more a vaild rpm macros?
> 
> i get:
> 
> RPM build errors:
>  File must begin with "/": %{_unitdir}/wildfly.service
> 
> Task info: http://koji.fedoraproject.org/koji/taskinfo?taskID=15632734
> 
> thanks in advance

You are missing a:

BuildRequires: systemd

(the systemd package contains that macro definition). 

kevin


pgp21N3Bq7SE3.pgp
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24, small backward steps

[Matthew Miller]

On Wed, Sep 14, 2016 at 04:44:38PM +, Debarshi Ray wrote:
> (a) The maintenance status of a package is not a binary variable. It
> is easy to imagine a third state - weakly maintained.

Yes, THIS. Our current model does not really allow us to express this
at all -- there's "orphaned", but that's not user-visible. 




-- 
Matthew Miller

Fedora Project Leader
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Triaging RH Bugzilla and forwarding bugs upstream

[Ralf Corsepius]

On 09/14/2016 07:03 PM, Jason L Tibbitts III wrote:

"RC" == Ralf Corsepius  writes:

RC> - A package triggering too many BZs.
RC> IMO, this should question the package's quality.

A package with a million users is going to get more bugs than a package
with ten regardless of the package quality.

Not necessarily.

Certainly, a package with a large user group is likely to receive more 
bug reports than a package with a small user group, but ...

... should be identical
... if this amount of reports doesn't decrease over time, it questions 
this package as whole and upstream's course.



   I have a feeling that a
rather large number of people use Gnome.
Whether this is true or not, I don't know. The last figure I saw, Gnome 
was at 30% of all Fedora users.


Ralf
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Triaging RH Bugzilla and forwarding bugs upstream (Was: F24, small backward steps)

[Kevin Fenzi]

On Wed, 14 Sep 2016 13:01:14 -0400
Josh Boyer  wrote:

> Quite simply, there are valid cases where a maintainer, or a group of
> maintainers, cannot scale to the number of bugs a package can
> generate.  The larger and more complex a package, the more likely that
> is.  That isn't anyone's fault or anyone's ego getting in the way.

Agreed. Additionally, there's packages we have that have 0 bugs
actually filed against them, but don't work or have serious problems. 

So, IMHO all this boils down to 'It depends', 'we should try and
improve tools for maintainers' and 'we should try and do the best we
can with the tools and processes we have'.

I think this post (from 6 years ago now) could be helpful: 

http://www.rants.org/2010/01/bugs-users-and-tech-debt/

If you don't want to click through (but you should, it's a good read),
the author posits two things: You shouldn't be worried that you have
more bugs and bugs are not actually technical debt so you shouldn't
think of them that way. 

kevin


pgpONvSmtv6it.pgp
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

_unitdir macro

[gil]

hi

_unitdir is no more a vaild rpm macros?

i get:

RPM build errors:
File must begin with "/": %{_unitdir}/wildfly.service

Task info: http://koji.fedoraproject.org/koji/taskinfo?taskID=15632734

thanks in advance

regards

.g
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Triaging RH Bugzilla and forwarding bugs upstream

[Jason L Tibbitts III]

> "RC" == Ralf Corsepius  writes:

RC> - A package triggering too many BZs.
RC> IMO, this should question the package's quality.

A package with a million users is going to get more bugs than a package
with ten regardless of the package quality.  I have a feeling that a
rather large number of people use Gnome.

 - J<
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Triaging RH Bugzilla and forwarding bugs upstream (Was: F24, small backward steps)

[Josh Boyer]

On Wed, Sep 14, 2016 at 12:47 PM, Ralf Corsepius  wrote:
> On 09/14/2016 06:24 PM, Josh Boyer wrote:
>>
>> On Wed, Sep 14, 2016 at 11:50 AM, Ralf Corsepius 
>> wrote:
>
>
>>> In this areas I primarily see 2 groups:
>>> - Maintainers, who are overloaded with BZs.
>>> IMO, this primarily is an ego problem and partially a project
>>> management/leadership problem.
>>
>>
>> I mostly disagree, but even in the small amount I do agree I believe
>> you have the order reversed in terms of the primary cause.
>
>
> Well, openly said, if maintainers complain and excuse with "overload" they
> in first place should ask themselves, why they can't do better.

That is indeed a fair question to ask.

> My impression is, in many cases, it's ego, which prevents to acknowledge
> they need "to divert".

I'm not sure what you mean by divert.  If you mean ask for help, then
sure.  However, help is in very short supply already.

Quite simply, there are valid cases where a maintainer, or a group of
maintainers, cannot scale to the number of bugs a package can
generate.  The larger and more complex a package, the more likely that
is.  That isn't anyone's fault or anyone's ego getting in the way.

>>> - A package triggering too many BZs.
>>> IMO, this should question the package's quality.
>>
>>
>> We have no bar for software quality, only for initial packaging of
>> said software.  We rely on package maintainers to ensure things work.
>> Sometimes that isn't really known until a wider audience starts using
>> the package.  That essentially makes this a subset of your original
>> problem group of too many BZs.
>
>
> I was primarily referring to ABRT, here. If the reports it generates can not
> be processed in reasonable manners, ABRT is useless.

I disagree with that.  It's rather useful, particularly the retrace
side of things.  That gives you measurable data on which bugs are
being hit the most for a particular package.

The generation of reports, whether done by ABRT or a large number of
users, is not the problem.  The problem is the ratio of people able to
process vs. the number overall.

josh
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24, small backward steps

[Kevin Fenzi]

On Wed, 14 Sep 2016 11:43:31 -0500
Michael Catanzaro  wrote:

> On Wed, 2016-09-14 at 08:33 +0200, Jakub Filak wrote:
> > Does GNOME Bugzilla support XMLRPC? Is there any testing instance
> > ABRT team
> > can play with?  
> 
> Yes and yes, but is XMLRPC being removed from upstream Bugzilla? I
> think I read that somewhere (but can't find a reference now when I
> search). It'd be a bad idea to use it if so.

They added a REST api in 5.0 and want people to move to that. 

"One big addition is a new REST-like endpoint alongside the existing
XML-RPC and JSON-RPC endpoints. This will allow clients to access
Bugzilla data using standard HTTP calls for easy development. Note:
XML-RPC and JSON-RPC are deprecated in favor of REST and will likely be
removed in the Bugzilla 7.0 release. "

> > One problem I can see is that Fedora users will have to register to
> > every
> > single upstream bug tracking tool. Using Red Hat Bugzilla as a proxy
> > to
> > upstream bug tracking tools is pretty convenient.  
> 
> I guess Launchpad-style comment proxying is probably too ambitious.

Note that hopefully with 5.0 we will have SAML auth, so if
bugzilla.gnome.org also picked that up (and other places) people could
just login with their Fedora account to all of them. 

kevin


pgpmnj29Nlssg.pgp
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Triaging RH Bugzilla and forwarding bugs upstream (Was: F24, small backward steps)

[Ralf Corsepius]

On 09/14/2016 06:24 PM, Josh Boyer wrote:

On Wed, Sep 14, 2016 at 11:50 AM, Ralf Corsepius  wrote:



In this areas I primarily see 2 groups:
- Maintainers, who are overloaded with BZs.
IMO, this primarily is an ego problem and partially a project
management/leadership problem.


I mostly disagree, but even in the small amount I do agree I believe
you have the order reversed in terms of the primary cause.


Well, openly said, if maintainers complain and excuse with "overload" 
they in first place should ask themselves, why they can't do better.


My impression is, in many cases, it's ego, which prevents to acknowledge 
they need "to divert".



- A package triggering too many BZs.
IMO, this should question the package's quality.


We have no bar for software quality, only for initial packaging of
said software.  We rely on package maintainers to ensure things work.
Sometimes that isn't really known until a wider audience starts using
the package.  That essentially makes this a subset of your original
problem group of too many BZs.


I was primarily referring to ABRT, here. If the reports it generates can 
not be processed in reasonable manners, ABRT is useless.


Ralf

--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24, small backward steps

[Michael Catanzaro]

On Wed, 2016-09-14 at 09:51 +0200, Pierre-Yves Chibon wrote:
> So, I'm going for the crazy idea front here, now that RHBZ is hooked
> onto
> fedmsg, should we try to write a tool creating bugs on GBZ for each
> gnome bugs
> created on RHBZ and sync comments between both instances? (well, we
> would have
> to see if we can get the GBZ onto a message bus of any sort)

This would be awesome, but someone has to implement it.

Michael
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24, small backward steps

[Debarshi Ray]

On Tue, Sep 13, 2016 at 04:24:02PM -0400, Stephen John Smoogen wrote:
> OK this is the most frustrating of a TON of frustrating parts of this
> conversation.
> 
> 1. WHY DO WE SHIP PACKAGES THAT WE 'KNOW' AREN'T MAINTAINED?
> 2. Why are people 'maintainers' of such packages if they know upstream
> is dead and they aren't going to maintain things.
> 3. If someone isn't going to read the bugzillas why do we even have
> them in bugzilla or the distribution?

Because:

(a) The maintenance status of a package is not a binary variable. It
is easy to imagine a third state - weakly maintained.

(b) The maintenance activity can ebb and flow.

(c) Just because a package is unmaintained and has unattended bugs, it
doesn't mean that it isn't working in the majority of cases.

Sometimes I own a package (let's say) FOO simply because it is in the
dependency chain of something else that I am actively interested
in. At some point in the past, FOO was actively maintained, but that
changed over time. Now, I see the bugs accumulate, and every once in a
couple of cycles when I get some free time I try to go through some of
them. Sometimes somebody else steps up. And if we are lucky, then
things might again pick up in the future.

Yes, strictly speaking, we should remove FOO but that is often not
practical unless the functionality offered by FOO is not interesting
anymore, or there is a suitable replacement. Even if there is a
replacement, it might take a while to do the port (webkitgtk3/WebKit1
comes to mind).


pgpYkf9BBLaUb.pgp
Description: PGP signature
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

dist.upgradepath FAILED for FEDORA-2016-d83b8432cd

[notifications]

dist.upgradepath FAILED for FEDORA-2016-d83b8432cd

https://taskotron.fedoraproject.org/artifacts/all/a36c305a-7a99-11e6-8bf9-525400120b80/task_output/FEDORA-2016-d83b8432cd.log
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

dist.upgradepath FAILED for perl-Fsdb-2.61-1.fc23

[notifications]

dist.upgradepath FAILED for perl-Fsdb-2.61-1.fc23

https://taskotron.fedoraproject.org/artifacts/all/a36c305a-7a99-11e6-8bf9-525400120b80/task_output/perl-Fsdb-2.61-1.fc23.log
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

Re: Triaging RH Bugzilla and forwarding bugs upstream (Was: F24, small backward steps)

[Jóhann B . Guðmundsson]

On 09/14/2016 02:44 PM, Jason L Tibbitts III wrote:


I disagree in general; when the bug volume exceeds a certain amount
bugzilla basically becomes useless.  However, it would be really nice if
_someone_  looked at RH bugzilla for those packages and did something
with them.


This responsibility falls under those individuals that have signed 
themselves up with maintaining the component(s) in question in the 
distribution and call themselves "package maintainers"...


JBG
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Triaging RH Bugzilla and forwarding bugs upstream (Was: F24, small backward steps)

[Josh Boyer]

On Wed, Sep 14, 2016 at 11:50 AM, Ralf Corsepius  wrote:
> On 09/14/2016 04:44 PM, Jason L Tibbitts III wrote:
>>>
>>> "RC" == Ralf Corsepius  writes:
>>
>>
>> RC> IMO, it should be mandatory for Fedora maintainers to look into RH
>> RC> Bugzilla, because that's the product they are "maintaining" and what
>> RC> users are using.
>>
>> I disagree in general;
>
> Whom do you report problems with HW to in real life? To the manufacturer or
> to a component's manufacturer?
>
> Almost certainly the manufacturer and not to a component's manufacturer.
>
>> when the bug volume exceeds a certain amount
>> bugzilla basically becomes useless.
>
>
> When the bug volume becomes too large, the causes for this should be
> analysed and be addressed.
>
> In this areas I primarily see 2 groups:
> - Maintainers, who are overloaded with BZs.
> IMO, this primarily is an ego problem and partially a project
> management/leadership problem.

I mostly disagree, but even in the small amount I do agree I believe
you have the order reversed in terms of the primary cause.

> - A package triggering too many BZs.
> IMO, this should question the package's quality.

We have no bar for software quality, only for initial packaging of
said software.  We rely on package maintainers to ensure things work.
Sometimes that isn't really known until a wider audience starts using
the package.  That essentially makes this a subset of your original
problem group of too many BZs.

josh
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24, small backward steps

[Ian Malone]

On 13 September 2016 at 21:24, Stephen John Smoogen  wrote:
> On 13 September 2016 at 16:03, Michael Catanzaro  wrote:

> OK this is the most frustrating of a TON of frustrating parts of this
> conversation.
>
> 1. WHY DO WE SHIP PACKAGES THAT WE 'KNOW' AREN'T MAINTAINED?
> 2. Why are people 'maintainers' of such packages if they know upstream
> is dead and they aren't going to maintain things.

Sometimes an application can be working though upstream is dead and
keeping it going on a best-effort basis can provide some functionality
that wouldn't exist otherwise. Of course library churn and general
moving on of other technology will eventually kill it despite a
maintainer's best efforts. This doesn't apply for security issues
where providing software with known unpatched problems may be actively
harmful.



-- 
imalone
http://ibmalone.blogspot.co.uk
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

gerd pushed to perl-Pegex (master). "remove tests that fails"

[notifications]

From 040a088ea08a737995f4f17ea407eef20bc08654 Mon Sep 17 00:00:00 2001
From: gerd 
Date: Wed, 14 Sep 2016 18:08:13 +0200
Subject: remove tests that fails

---
 perl-Pegex.spec | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/perl-Pegex.spec b/perl-Pegex.spec
index 9ed4ed0..8cef8bb 100644
--- a/perl-Pegex.spec
+++ b/perl-Pegex.spec
@@ -1,6 +1,6 @@
 Name:   perl-Pegex
 Version:0.61
-Release:1%{?dist}
+Release:2%{?dist}
 Summary:Pegex Parser Generator
 License:GPL+ or Artistic
 Group:  Development/Libraries
@@ -68,6 +68,7 @@ find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} \;
 make test TEST_FILES="$(find t -name '*.t' \
 \! -exec grep -q -e 'use TestML' {} \; -print | tr \"\\n\" ' ')"
 %else
+rm -f t/testml-compiler-checks.t t/testml-tree-pegex.t t/testml-tree.t
 make test
 %endif
 
@@ -77,6 +78,9 @@ make test
 %{_mandir}/man3/*
 
 %changelog
+* Wed Sep 14 2016 Gerd Pokorra  0.61-2
+- remove tests that fails
+
 * Thu Jun 16 2016 Gerd Pokorra  0.61-1
 - Update to 0.61
 
-- 
cgit v0.12



http://pkgs.fedoraproject.org/cgit/perl-Pegex.git/commit/?h=master=040a088ea08a737995f4f17ea407eef20bc08654
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

Re: Triaging RH Bugzilla and forwarding bugs upstream (Was: F24, small backward steps)

[Ralf Corsepius]

On 09/14/2016 04:44 PM, Jason L Tibbitts III wrote:

"RC" == Ralf Corsepius  writes:


RC> IMO, it should be mandatory for Fedora maintainers to look into RH
RC> Bugzilla, because that's the product they are "maintaining" and what
RC> users are using.

I disagree in general;
Whom do you report problems with HW to in real life? To the manufacturer 
or to a component's manufacturer?


Almost certainly the manufacturer and not to a component's manufacturer.


when the bug volume exceeds a certain amount
bugzilla basically becomes useless.


When the bug volume becomes too large, the causes for this should be 
analysed and be addressed.


In this areas I primarily see 2 groups:
- Maintainers, who are overloaded with BZs.
IMO, this primarily is an ego problem and partially a project 
management/leadership problem.


- A package triggering too many BZs.
IMO, this should question the package's quality.


Ralf
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: How to obsolete a subpackage?

[David Howells]

Florian Weimer  wrote:

> I think if you want silent deletion, you'll have to add “Obsoletes:
> binutils-sh64-linux-gnu” to the cross-binutils-common package.

Yeah, the following worked:

@@ -129,6 +133,9 @@ converting addresses to file and line).
 Summary: Cross-build binary utility documentation and translation files
 Group: Development/Tools
 BuildArch: noarch
+%if !%{build_sh64}
+Obsoletes: binutils-sh64-linux-gnu
+%endif
 %description -n %{cross}-binutils-common
 Documentation, manual pages and translation files for cross-build binary image
 generation, manipulation and query tools.

I forgot to put the '!' in the %if condition, which didn't help.

David
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: How to obsolete a subpackage?

[Jason L Tibbitts III]

I would suggest everyone interested follow the relevant FPC ticket.
I've just added https://fedorahosted.org/fpc/ticket/645#comment:11 which
probably isn't complete but at least gives us a start.

 - J<
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Triaging RH Bugzilla and forwarding bugs upstream (Was: F24, small backward steps)

[Stephen John Smoogen]

On 14 September 2016 at 10:44, Jason L Tibbitts III  wrote:
>> "RC" == Ralf Corsepius  writes:
>
> RC> IMO, it should be mandatory for Fedora maintainers to look into RH
> RC> Bugzilla, because that's the product they are "maintaining" and what
> RC> users are using.
>
> I disagree in general; when the bug volume exceeds a certain amount
> bugzilla basically becomes useless.  However, it would be really nice if
> _someone_ looked at RH bugzilla for those packages and did something
> with them.
>
> We used to have "bugzappers".  What we really need is someone to do
> triage and to forward bugs on to upstream when appropriate.  This
> obviously requires volunteers.
>
> I think this is an excellent job for someone who wants to help out.
> Does Gnome have documentation on performing bug triage like our kernel
> team does?  https://fedoraproject.org/wiki/KernelBugTriage
>
> All volunteers would really need is accounts at the upstream trackers,
> the will to search for duplicate bugs there, and some basic knowledge of
> when to ask for more information and how to properly select components
> upstream.  I would imagine that a large number of the bugs that are
> filed are duplicates of existing bugs anyway.
>
> Note that I sadly don't have any free time to actually help with this.
> I've tried to do kernel bug triage, and it's very, very difficult and
> time consuming.  But that's the kernel; I would hope that just sorting
> out Gnome bugs wouldn't be quite so bad.
>

It is just as bad for pretty much the same reasons:
1) Do you have access to that system.
2) Is the problem in the app or in X or in the kernel or the hardware.
3) If it is in the hardware is it a monitor/video card/motherboard issue
4) If you think it is in the kernel go to kernel triage
5) If you thinking it is in X follow the kernel triage but use s/kernel/X/
6) If it is in the app can you even figure out what configuration caused it?
7) Is the bug really in the app or in some side app which it talks to?

Normally you work backwards down the list but you have to cover all
the bases as a good many crashes are from something you have nothing
to control. Which is why various people find that they go to XYZ
bugtracker and get told it isn't the distributions problem because it
isn't the OS they used and they can't duplicate. [I am using XYZ
because this problem can be generalized to
Gnome/KDE/XFCE/Libreoffice/etc.] One of the reasons that bugzappers
seemed to fall apart was it was a slog of work that burned out people
without much in the way of reward because it never ends. The remaining
bugzappers then took more of the load over and over again until you
ended up with 1-2 people?

Which is also happening with package maintainers. You get packagers
with piles of packages burning out and the remaining people taking
more and more packages over time. This ends up with people with
hundreds of packages that they have under their belt and no way to
actually keep track of the bugs on them.

On the other hand, we have this conversation every (or every other)
mid release cycle... so maybe we should just do the play one more
time. Some drama about how Gnome sucks, gets special treatment, or
isn't as special as systemd, is always put upon.. then a dramatic
quitting around beta and general agreement that we will all do better
for the next release. It's just like Shakespeare without iambic
pentameter.

>  - J<
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org



-- 
Stephen J Smoogen.
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

[389-devel] Build failed in Jenkins: 389-DS-NIGHTLY #79

[Jenkins]

See 


--
[...truncated 3597 lines...]
suites/password/pwdPolicy_inherit_global_test.py::test_entry_has_no_restrictions[off-off]
 PASSED
suites/password/pwdPolicy_inherit_global_test.py::test_entry_has_no_restrictions[on-off]
 PASSED
suites/password/pwdPolicy_inherit_global_test.py::test_entry_has_no_restrictions[off-on]
 PASSED
suites/password/pwdPolicy_inherit_global_test.py::test_entry_has_restrictions[cn=config]
 PASSED
suites/password/pwdPolicy_inherit_global_test.py::test_entry_has_restrictions[cn="cn=nsPwPolicyEntry,ou=People,dc=example,dc=com",cn=nsPwPolicyContainer,ou=People,dc=example,dc=com]
 PASSED
suites/password/pwdPolicy_syntax_test.py::test_pwdPolicy_syntax PASSED
suites/password/pwdPolicy_warning_test.py::test_different_values[ ] PASSED
suites/password/pwdPolicy_warning_test.py::test_different_values[junk123] PASSED
suites/password/pwdPolicy_warning_test.py::test_different_values[on] PASSED
suites/password/pwdPolicy_warning_test.py::test_different_values[off] PASSED
suites/password/pwdPolicy_warning_test.py::test_expiry_time PASSED
suites/password/pwdPolicy_warning_test.py::test_password_warning[passwordSendExpiringTime-off]
 PASSED
suites/password/pwdPolicy_warning_test.py::test_password_warning[passwordWarning-3600]
 PASSED
suites/password/pwdPolicy_warning_test.py::test_with_different_password_states 
PASSED
suites/password/pwdPolicy_warning_test.py::test_default_behavior PASSED
suites/password/pwdPolicy_warning_test.py::test_with_local_policy PASSED
suites/password/pwp_history_test.py::test_pwp_history_test PASSED
suites/posix_winsync_plugin/posix_winsync_test.py::test_posix_winsync_init 
PASSED
suites/posix_winsync_plugin/posix_winsync_test.py::test_posix_winsync_ PASSED
suites/psearch/psearch_test.py::test_psearch_init PASSED
suites/psearch/psearch_test.py::test_psearch_ PASSED
suites/referint_plugin/referint_test.py::test_referint_init PASSED
suites/referint_plugin/referint_test.py::test_referint_ PASSED
suites/replication/cleanallruv_test.py::test_cleanallruv_init PASSED
suites/replication/cleanallruv_test.py::test_cleanallruv_clean PASSED
suites/replication/cleanallruv_test.py::test_cleanallruv_clean_restart PASSED
suites/replication/cleanallruv_test.py::test_cleanallruv_clean_force PASSED
suites/replication/cleanallruv_test.py::test_cleanallruv_abort PASSED
suites/replication/cleanallruv_test.py::test_cleanallruv_abort_restart PASSED
suites/replication/cleanallruv_test.py::test_cleanallruv_abort_certify PASSED
suites/replication/cleanallruv_test.py::test_cleanallruv_stress_clean PASSED
suites/replication/wait_for_async_feature_test.py::test_not_int_value PASSED
suites/replication/wait_for_async_feature_test.py::test_multi_value PASSED
suites/replication/wait_for_async_feature_test.py::test_value_check[waitfor_async_attr0]
 PASSED
suites/replication/wait_for_async_feature_test.py::test_value_check[waitfor_async_attr1]
 PASSED
suites/replication/wait_for_async_feature_test.py::test_value_check[waitfor_async_attr2]
 PASSED
suites/replication/wait_for_async_feature_test.py::test_value_check[waitfor_async_attr3]
 PASSED
suites/replication/wait_for_async_feature_test.py::test_behavior_with_value[waitfor_async_attr0]
 PASSED
suites/replication/wait_for_async_feature_test.py::test_behavior_with_value[waitfor_async_attr1]
 PASSED
suites/replication/wait_for_async_feature_test.py::test_behavior_with_value[waitfor_async_attr2]
 PASSED
suites/replication/wait_for_async_feature_test.py::test_behavior_with_value[waitfor_async_attr3]
 PASSED
suites/replsync_plugin/repl_sync_test.py::test_repl_sync_init PASSED
suites/replsync_plugin/repl_sync_test.py::test_repl_sync_ PASSED
suites/resource_limits/res_limits_test.py::test_res_limits_init PASSED
suites/resource_limits/res_limits_test.py::test_res_limits_ PASSED
suites/retrocl_plugin/retrocl_test.py::test_retrocl_init PASSED
suites/retrocl_plugin/retrocl_test.py::test_retrocl_ PASSED
suites/reverpwd_plugin/reverpwd_test.py::test_reverpwd_init PASSED
suites/reverpwd_plugin/reverpwd_test.py::test_reverpwd_ PASSED
suites/roles_plugin/roles_test.py::test_roles_init PASSED
suites/roles_plugin/roles_test.py::test_roles_ PASSED
suites/rootdn_plugin/rootdn_plugin_test.py::test_rootdn_init PASSED
suites/rootdn_plugin/rootdn_plugin_test.py::test_rootdn_access_specific_time 
PASSED
suites/rootdn_plugin/rootdn_plugin_test.py::test_rootdn_access_day_of_week 
PASSED
suites/rootdn_plugin/rootdn_plugin_test.py::test_rootdn_access_denied_ip PASSED
suites/rootdn_plugin/rootdn_plugin_test.py::test_rootdn_access_denied_host 
PASSED
suites/rootdn_plugin/rootdn_plugin_test.py::test_rootdn_access_allowed_ip PASSED
suites/rootdn_plugin/rootdn_plugin_test.py::test_rootdn_access_allowed_host 
PASSED
suites/rootdn_plugin/rootdn_plugin_test.py::test_rootdn_config_validate PASSED
suites/sasl/sasl_test.py::test_sasl_init PASSED

Triaging RH Bugzilla and forwarding bugs upstream (Was: F24, small backward steps)

[Jason L Tibbitts III]

> "RC" == Ralf Corsepius  writes:

RC> IMO, it should be mandatory for Fedora maintainers to look into RH
RC> Bugzilla, because that's the product they are "maintaining" and what
RC> users are using.

I disagree in general; when the bug volume exceeds a certain amount
bugzilla basically becomes useless.  However, it would be really nice if
_someone_ looked at RH bugzilla for those packages and did something
with them.

We used to have "bugzappers".  What we really need is someone to do
triage and to forward bugs on to upstream when appropriate.  This
obviously requires volunteers.

I think this is an excellent job for someone who wants to help out.
Does Gnome have documentation on performing bug triage like our kernel
team does?  https://fedoraproject.org/wiki/KernelBugTriage

All volunteers would really need is accounts at the upstream trackers,
the will to search for duplicate bugs there, and some basic knowledge of
when to ask for more information and how to properly select components
upstream.  I would imagine that a large number of the bugs that are
filed are duplicates of existing bugs anyway.

Note that I sadly don't have any free time to actually help with this.
I've tried to do kernel bug triage, and it's very, very difficult and
time consuming.  But that's the kernel; I would hope that just sorting
out Gnome bugs wouldn't be quite so bad.

 - J<
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: How to obsolete a subpackage?

[Vít Ondruch]

Dne 14.9.2016 v 16:32 Florian Weimer napsal(a):
> On 09/14/2016 04:28 PM, David Howells wrote:
>> I need to obsolete one of the arch subpackages in the cross-binutils
>> rpm (and
>> also in the cross-gcc rpm) because binutils no longer supports that arch
>> (sh64).
>>
>> Just marking the appropriate subpackage as obsoleted in the specfile
>> for the
>
> How do you do that?
>
>> cross-binutils-common subpackage causes dnf to complain:
>>
>> warthog>sudo dnf upgrade
>> ./noarch/cross-binutils-common-2.27-1.fc26.noarch.rpm
>> ./x86_64/binutils-*
>> Last metadata expiration check: 0:20:38 ago on Wed Sep 14 15:06:27 2016.
>> Error: package binutils-sh64-linux-gnu-2.26.1-1.fc24.x86_64 requires
>> cross-binutils-common = 2.26.1-1.fc24, but none of the providers can
>> be installed
>> (try to add '--allowerasing' to command line to replace conflicting
>> packages)
>>
>> Is this the right way to do things?
>
> I think if you want silent deletion, you'll have to add “Obsoletes:
> binutils-sh64-linux-gnu” to the cross-binutils-common package.
>
> I'm not sure if this is a good idea, though.

This seems to be hot topic recently. I faced the similar issue yesterday
and there is FPC ticket [1] trying to figure out what to do with such
packages.


Vít


[1] https://fedorahosted.org/fpc/ticket/645#comment:10
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: How to obsolete a subpackage?

[Igor Gnatenko]

On Wed, Sep 14, 2016 at 4:28 PM, David Howells  wrote:
> I need to obsolete one of the arch subpackages in the cross-binutils rpm (and
> also in the cross-gcc rpm) because binutils no longer supports that arch
> (sh64).
>
> Just marking the appropriate subpackage as obsoleted in the specfile for the
> cross-binutils-common subpackage causes dnf to complain:
>
> warthog>sudo dnf upgrade 
> ./noarch/cross-binutils-common-2.27-1.fc26.noarch.rpm ./x86_64/binutils-*
> Last metadata expiration check: 0:20:38 ago on Wed Sep 14 15:06:27 2016.
> Error: package binutils-sh64-linux-gnu-2.26.1-1.fc24.x86_64 requires 
> cross-binutils-common = 2.26.1-1.fc24, but none of the providers can be 
> installed
> (try to add '--allowerasing' to command line to replace conflicting packages)
>
> Is this the right way to do things?
Can you show diff what you did?
>
> David
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org



-- 
-Igor Gnatenko
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: How to obsolete a subpackage?

[Florian Weimer]

On 09/14/2016 04:28 PM, David Howells wrote:

I need to obsolete one of the arch subpackages in the cross-binutils rpm (and
also in the cross-gcc rpm) because binutils no longer supports that arch
(sh64).

Just marking the appropriate subpackage as obsoleted in the specfile for the


How do you do that?


cross-binutils-common subpackage causes dnf to complain:

warthog>sudo dnf upgrade ./noarch/cross-binutils-common-2.27-1.fc26.noarch.rpm 
./x86_64/binutils-*
Last metadata expiration check: 0:20:38 ago on Wed Sep 14 15:06:27 2016.
Error: package binutils-sh64-linux-gnu-2.26.1-1.fc24.x86_64 requires 
cross-binutils-common = 2.26.1-1.fc24, but none of the providers can be 
installed
(try to add '--allowerasing' to command line to replace conflicting packages)

Is this the right way to do things?


I think if you want silent deletion, you'll have to add “Obsoletes: 
binutils-sh64-linux-gnu” to the cross-binutils-common package.


I'm not sure if this is a good idea, though.

Florian
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

How to obsolete a subpackage?

[David Howells]

I need to obsolete one of the arch subpackages in the cross-binutils rpm (and
also in the cross-gcc rpm) because binutils no longer supports that arch
(sh64).

Just marking the appropriate subpackage as obsoleted in the specfile for the
cross-binutils-common subpackage causes dnf to complain:

warthog>sudo dnf upgrade ./noarch/cross-binutils-common-2.27-1.fc26.noarch.rpm 
./x86_64/binutils-*
Last metadata expiration check: 0:20:38 ago on Wed Sep 14 15:06:27 2016.
Error: package binutils-sh64-linux-gnu-2.26.1-1.fc24.x86_64 requires 
cross-binutils-common = 2.26.1-1.fc24, but none of the providers can be 
installed
(try to add '--allowerasing' to command line to replace conflicting packages)

Is this the right way to do things?

David
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: RFR: New Dist-Git Task Storage Proposal

[Tim Flink]

On Wed, 14 Sep 2016 10:28:17 +0200
Vít Ondruch  wrote:

> Why do you prefer to have the "taskotron" directory instead of
> "taskotron" namespace (the same as for docker files)? TBH, this will
> make synchronization between RHEL and Fedora much harder, because I
> can't see any internal use for "taskotron" directory.

One of the things that we're prioritizing is ease of use for packagers.
The feedback we've received thus far is that keeping everything in the
same git repo is the preferred way to store checks.

I'm of the belief that if this isn't as easy to use as falling off a
horse, we're not going to see as much adoption as we could. Moving all
the checks into a separate git repository is another barrier to entry.

Is adding a directory to dist-git that big of a deal? I'm not sure I
understand how a few more directories will make synchronization that
much more difficult - RHEL can just ignore the "taskotron" directory if
they're not using it, no?

Tim

> Dne 12.9.2016 v 22:44 Tim Flink napsal(a):
> > I wrote up a quick draft of the new dist-git task storage proposal
> > that was discussed in Brno after Flock.
> >
> > https://phab.qadevel.cloud.fedoraproject.org/w/taskotron/new_distgit_task_storage_proposal/
> >
> > Please review the document and either let me know (or fix in the
> > wiki page) things which aren't clear or bits that I forgot.
> >
> > Tim
> >
> >
> > ___
> > qa-devel mailing list
> > qa-devel@lists.fedoraproject.org
> > https://lists.fedoraproject.org/admin/lists/qa-devel@lists.fedoraproject.org
> >   
> 



pgpsmMHdEUkAG.pgp
Description: OpenPGP digital signature
___
qa-devel mailing list
qa-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/qa-devel@lists.fedoraproject.org

Re: Handling bugs which are fixed in upstream, but not released yet

[Josh Boyer]

On Wed, Sep 14, 2016 at 9:12 AM, Florian Weimer  wrote:
> On 09/14/2016 02:41 PM, Igor Gnatenko wrote:
>
>> I have question, how you handle bugs where fix already available in
>> upstream, but you don't want to backport that fix yet. What you do
>> with bug in our trash-box (bugzilla.redhat.com)?
>>
>> Probably you use whiteboard to indicate where it was fixed, close bug
>> and write into comment that it will be fixed in next upstream release
>> or ...?
>
>
> I tend to upload the fixed version to rawhide and resolve the bug as
> CLOSED/RAWHIDE.

Also a fine alternative and less error prone in forgetting to actually fix it.

I think all of these solutions simply illustrate that there is no
fixed process for Fedora bugs, so common sense to the situation needs
to be used.

josh
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Proposed mass bug filing for webkitgtk/webkitgtk3 package removal

[Scott Talbert]

On Wed, 14 Sep 2016, Michael Catanzaro wrote:


On Tue, 2016-09-13 at 23:26 -0500, Michael Catanzaro wrote:

I've started filing bugs and will continue throughout the week.

Michael


Well nevermind that, I'm (mostly) finished:

https://bugzilla.redhat.com/show_bug.cgi?id=1375784

The one thing I did not do was file individual bugs for all of the
dependencies of wxGTK3. There are quite a few. Anyone know if this
package will be ported to WebKit2? If it's likely to happen, then we
probably don't need to file bugs for its dependencies as most of them
won't need to change anything. But if it's not likely to happen in
time, then I will file bugs for its dependencies to let them know they
are in trouble and should look into helping wxGTK3.


Yes, it's in progress:
http://trac.wxwidgets.org/ticket/17650

Scott
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Handling bugs which are fixed in upstream, but not released yet

[Florian Weimer]

On 09/14/2016 02:41 PM, Igor Gnatenko wrote:


I have question, how you handle bugs where fix already available in
upstream, but you don't want to backport that fix yet. What you do
with bug in our trash-box (bugzilla.redhat.com)?

Probably you use whiteboard to indicate where it was fixed, close bug
and write into comment that it will be fixed in next upstream release
or ...?


I tend to upload the fixed version to rawhide and resolve the bug as 
CLOSED/RAWHIDE.


Florian
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Handling bugs which are fixed in upstream, but not released yet

[Igor Gnatenko]

On Wed, Sep 14, 2016 at 2:45 PM, Josh Boyer  wrote:
> On Wed, Sep 14, 2016 at 8:41 AM, Igor Gnatenko  wrote:
>> Hi,
>>
>> I have question, how you handle bugs where fix already available in
>> upstream, but you don't want to backport that fix yet. What you do
>> with bug in our trash-box (bugzilla.redhat.com)?
>
> Why don't you want to backport it?
Sometimes it's too much work to backport if there are merge conflicts.
>
>> Probably you use whiteboard to indicate where it was fixed, close bug
>> and write into comment that it will be fixed in next upstream release
>> or ...?
>
> CLOSED->UPSTREAM or CLOSED->NEXTRELEASE both exist, but honestly I
> would probably put the bug in DEFERRED if you plan to fix it but can't
> yet for some reason.  A comment describing the timeline for when the
> fix will hit Fedora is probably sufficient.  The key for any of these
> states is to remember to actually do the fix.
>
> josh
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org



-- 
-Igor Gnatenko
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Handling bugs which are fixed in upstream, but not released yet

[Josh Boyer]

On Wed, Sep 14, 2016 at 8:41 AM, Igor Gnatenko  wrote:
> Hi,
>
> I have question, how you handle bugs where fix already available in
> upstream, but you don't want to backport that fix yet. What you do
> with bug in our trash-box (bugzilla.redhat.com)?

Why don't you want to backport it?

> Probably you use whiteboard to indicate where it was fixed, close bug
> and write into comment that it will be fixed in next upstream release
> or ...?

CLOSED->UPSTREAM or CLOSED->NEXTRELEASE both exist, but honestly I
would probably put the bug in DEFERRED if you plan to fix it but can't
yet for some reason.  A comment describing the timeline for when the
fix will hit Fedora is probably sufficient.  The key for any of these
states is to remember to actually do the fix.

josh
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Handling bugs which are fixed in upstream, but not released yet

[Igor Gnatenko]

Hi,

I have question, how you handle bugs where fix already available in
upstream, but you don't want to backport that fix yet. What you do
with bug in our trash-box (bugzilla.redhat.com)?

Probably you use whiteboard to indicate where it was fixed, close bug
and write into comment that it will be fixed in next upstream release
or ...?
-- 
-Igor Gnatenko
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: 2016-09-14 @ 14:00 UTC - QA Tools Video "Standup" Meeting

[Kamil Paral]

> # QA Tools Video "Standup" Meeting
> # Date: 2016-09-14
> # Time: 14:00 UTC
> (https://fedoraproject.org/wiki/Infrastructure/UTCHowto)
> # Location: https://bluejeans.com/2509415264
> 
> One discussion that came up after Flock was that doing a video meeting
> would be worth trying to see how it works for us in terms of
> collaborating.
> 
> In that vein, we're going to try this and see how well it works. This
> will be in bluejeans which does require flash and/or plugins to work.
> I'm not overly tied to it, this is just the easiest option for now :)
> 
> https://bluejeans.com/2509415264
> 
> The agenda is pretty simple: everyone takes a turn saying what they're
> working on this week and what, if anything, is keeping them from making
> progress.
> 
> Hope to see people there.
> 
> Tim

Hi Tim,

please add this to fedocal next time, I noticed the email only today (and only 
because others told me).

Thanks.
___
qa-devel mailing list
qa-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/qa-devel@lists.fedoraproject.org

[Bug 1370461] perl-DBIx-Class: FTBFS in rawhide

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1370461



--- Comment #1 from Fedora Update System  ---
perl-DBIx-Class-0.082840-2.fc25 has been submitted as an update to Fedora 25.
https://bodhi.fedoraproject.org/updates/FEDORA-2016-9d99d0e000

-- 
You are receiving this mail because:
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

Re: Proposed mass bug filing for webkitgtk/webkitgtk3 package removal

[jens]

Am 14.09.2016 05:26, schrieb Michael Catanzaro:

On Tue, 2016-09-13 at 23:26 -0500, Michael Catanzaro wrote:

I've started filing bugs and will continue throughout the week.

Michael


Well nevermind that, I'm (mostly) finished:

https://bugzilla.redhat.com/show_bug.cgi?id=1375784

The one thing I did not do was file individual bugs for all of the
dependencies of wxGTK3. There are quite a few. Anyone know if this
package will be ported to WebKit2? If it's likely to happen, then we
probably don't need to file bugs for its dependencies as most of them
won't need to change anything. But if it's not likely to happen in
time, then I will file bugs for its dependencies to let them know they
are in trouble and should look into helping wxGTK3.


The wxWidgets devs are aware of the change:
http://trac.wxwidgets.org/ticket/17650
but the bug was tagged as "gsoc", so it will probably take some time 
until the change is really done.


Michael


Jens
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

jplesnik pushed to perl-DBIx-Class (f25). "Fix test failures of t/prefetch/grouped.t (BZ#1370461)"

[notifications]

From 8a615c40e200406b985715a32564fa0a30e33dc3 Mon Sep 17 00:00:00 2001
From: Jitka Plesnikova 
Date: Wed, 14 Sep 2016 10:54:54 +0200
Subject: Fix test failures of t/prefetch/grouped.t (BZ#1370461)

---
 DBIx-Class-0.082840-Fix-test-RT117271.patch | 37 +
 perl-DBIx-Class.spec|  9 ++-
 2 files changed, 45 insertions(+), 1 deletion(-)
 create mode 100644 DBIx-Class-0.082840-Fix-test-RT117271.patch

diff --git a/DBIx-Class-0.082840-Fix-test-RT117271.patch 
b/DBIx-Class-0.082840-Fix-test-RT117271.patch
new file mode 100644
index 000..0edf1a0
--- /dev/null
+++ b/DBIx-Class-0.082840-Fix-test-RT117271.patch
@@ -0,0 +1,37 @@
+From adcc1df0049e0093cb94c867bd2be8c9fe242a61 Mon Sep 17 00:00:00 2001
+From: Peter Rabbitson 
+Date: Tue, 13 Sep 2016 17:15:48 +0200
+Subject: [PATCH] Fix for upcoming (not yet available via DBD::SQLite)
+ libsqlite version
+
+---
+ Changes  | 2 ++
+ t/prefetch/grouped.t | 2 +-
+ 2 files changed, 3 insertions(+), 1 deletion(-)
+
+#diff --git a/Changes b/Changes
+#index 72d7647..e402e5a 100644
+#--- a/Changes
+#+++ b/Changes
+#@@ -73,6 +73,8 @@ Revision history for DBIx::Class
+#   working with copy() in t/icdt/engine_specific/sybase.t (GH#84)
+# - Fix t/54taint.t failing on local::lib's with upgraded Carp on 5.8.*
+# - Fix invalid variable names in ResultSource::View examples
+#+- Fix missing ORDER BY leading to failures of t/prefetch/grouped.t
+#+  under upcoming libsqlite (RT#117271)
+# - Skip tests in a way more intelligent and speedy manner when 
optional
+#   dependencies are missing
+# - Make the Optional::Dependencies error messages cpanm-friendly
+diff --git a/t/prefetch/grouped.t b/t/prefetch/grouped.t
+index 4aad6b1..c0d2224 100644
+--- a/t/prefetch/grouped.t
 b/t/prefetch/grouped.t
+@@ -100,7 +100,7 @@ my @cdids = sort $cd_rs->get_column ('cdid')->all;
+ 
+   # add an extra track to one of the cds, and then make sure we can get it on 
top
+   # (check if limit works)
+-  my $top_cd = $cd_rs->slice (1,1)->next;
++  my $top_cd = $cd_rs->search({}, { order_by => 'cdid' })->slice (1,1)->next;
+   $top_cd->create_related ('tracks', {
+ title => 'over the top',
+   });
diff --git a/perl-DBIx-Class.spec b/perl-DBIx-Class.spec
index 51fd9c4..fbbe972 100644
--- a/perl-DBIx-Class.spec
+++ b/perl-DBIx-Class.spec
@@ -1,11 +1,14 @@
 Name:   perl-DBIx-Class
 Summary:Extensible and flexible object <-> relational mapper
 Version:0.082840
-Release:1%{?dist}
+Release:2%{?dist}
 License:GPL+ or Artistic
 Group:  Development/Libraries
 Source0:
http://search.cpan.org/CPAN/authors/id/R/RI/RIBASUSHI/DBIx-Class-%{version}.tar.gz
 URL:http://search.cpan.org/dist/DBIx-Class/
+# Fix missing ORDER BY leading to failures of t/prefetch/grouped.t under
+# upcoming libsqlite (RT#117271)
+Patch0: DBIx-Class-0.082840-Fix-test-RT117271.patch
 BuildArch:  noarch
 # Build
 BuildRequires:  coreutils
@@ -267,6 +270,7 @@ DISTINCT, GROUP BY and HAVING support.
 
 %prep
 %setup -q -n DBIx-Class-%{version}
+%patch0 -p1
 chmod -c +x script/*
 # skip dbic_pretty.t when bootstrapping
 %if 0%{?perl_bootstrap}
@@ -297,6 +301,9 @@ make test
 %{_mandir}/man[13]/*
 
 %changelog
+* Wed Sep 14 2016 Jitka Plesnikova  - 0.082840-2
+- Fix test failures of t/prefetch/grouped.t (BZ#1370461)
+
 * Mon Jun 20 2016 Jitka Plesnikova  - 0.082840-1
 - 0.082840 bump
 
-- 
cgit v0.12



http://pkgs.fedoraproject.org/cgit/perl-DBIx-Class.git/commit/?h=f25=8a615c40e200406b985715a32564fa0a30e33dc3
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

[Bug 1370461] perl-DBIx-Class: FTBFS in rawhide

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1370461

Jitka Plesnikova  changed:

   What|Removed |Added

   Fixed In Version||perl-DBIx-Class-0.082840-2.
   ||fc26



-- 
You are receiving this mail because:
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

Re: RFR: New Dist-Git Task Storage Proposal

[Josef Skladanka]

On Tue, Sep 13, 2016 at 4:20 PM, Tim Flink  wrote:

> On Mon, 12 Sep 2016 14:44:27 -0600
> Tim Flink  wrote:
>
> > I wrote up a quick draft of the new dist-git task storage proposal
> > that was discussed in Brno after Flock.
> >
> > https://phab.qadevel.cloud.fedoraproject.org/w/taskotron/
> new_distgit_task_storage_proposal/
> >
> > Please review the document and either let me know (or fix in the wiki
> > page) things which aren't clear or bits that I forgot.
>
> I added more information to the wiki page about the default, or bare
> executable case which we discussed during/after flock.
>
> Tim
>

LGTM - I'd just add a link to documentation for the results.yaml format, if
we have any (if we don't then we'd better write one :D)
___
qa-devel mailing list
qa-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/qa-devel@lists.fedoraproject.org

[EPEL-devel] Re: Requirements for SRPM names

[Peter Robinson]

On Wed, Sep 14, 2016 at 3:51 AM, Dennis Gilmore  wrote:
> On Tuesday, September 13, 2016 11:54:41 PM CDT Peter Robinson wrote:
>> >> I'm looking for some clarification on the naming requirements for
>> >> SRPMs.
>> >>
>> >> In the EPEL 7 in Python 3 Plan Draft [1], it specifies that SRPM names
>> >> can't conflict with RHEL SRPM names, but in the Limited Arch Packages
>> >> [2]section of EPEL: Packaging, it seems to imply the SRPM name would
>> >> be the same, but the release number would be pretended with "0.".
>> >>
>> >> Could someone please clarify?
>> >>
>> >> If, in fact, the name can be the same, it will make it much easier to
>> >> provide Python 3 packages for EPEL since a separate package would not
>> >> be required in the Fedora Package DB.
>> >
>> > So, here's the thing (at least as I understand it):
>> >
>> > koji operates on source packages.
>> >
>> > If there's a package in RHEL called 'foo' and also one in EPEL called
>> > 'foo' it will use the epel one in all cases for everything that foo
>> > makes.
>>
>> Is that the case with external repos? I didn't think it was that smart
>> in that case, but I'm tired so might be mis-remembering.
> It 100% is the case. Koji treats external repos exactly the same as internal.
> it even taks special care to ensure that all binary rpms for a given srpm are
> included even if the binary rpms are spread acorss different external repos
>
>> > So, with the limited arch packages this means that _ALL_ things
>> > building in koji will use the epel package. The reason for the
>> > prepended 0 is so that users don't install the epel package and instead
>> > get the newer rhel version. The limited arch guideline also says you
>> > should try and keep the package as close as possible to the rhel
>> > version.
>>
>> For el7, and even in some of the big (java*) use cases in el6 the
>> delta in packages between the arches is getting a lot less, and I
>> believe this will be more so as we move forward in el7.
> I honestly am not sure there is any limited arch packages in epel7

There most definitely are, at least in what is shipped, it depends on
the arch and is lessening/changing with each dot release and is much
less of a problem with el7 than earlier releases. The big one that
comes to mind in extras is golang/docker stack.
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org

[Bug 1375929] perl-Encode-JISX0213-0.04-3.fc26 FTBFS: t/ JISX0213.t requires too much memory

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1375929

Petr Pisar  changed:

   What|Removed |Added

External Bug ID||CPAN 117158



-- 
You are receiving this mail because:
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

[Bug 1375929] New: perl-Encode-JISX0213-0.04-3.fc26 FTBFS: t/ JISX0213.t requires too much memory

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1375929

Bug ID: 1375929
   Summary: perl-Encode-JISX0213-0.04-3.fc26 FTBFS: t/JISX0213.t
requires too much memory
   Product: Fedora
   Version: rawhide
 Component: perl-Encode-JISX0213
  Assignee: ppi...@redhat.com
  Reporter: ppi...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: jples...@redhat.com,
perl-devel@lists.fedoraproject.org, ppi...@redhat.com



perl-Encode-JISX0213-0.04-3.fc26 fails to build in F26 because a test fails:

+ make test
"/usr/bin/perl" -MExtUtils::Command::MM -e 'cp_nonempty' -- JISX0213.bs
blib/arch/auto/Encode/JISX0213/JISX0213.bs 644
PERL_DL_NONLAZY=1 "/usr/bin/perl" "-MExtUtils::Command::MM" "-MTest::Harness"
"-e" "undef *Test::Harness::Switches; test_harness(0, 'blib/lib', 'blib/arch')"
t/*.t
Out of memory!
# Looks like your test exited with 1 just after 33.
t/JISX0213.t .. 
Dubious, test returned 1 (wstat 256, 0x100)
Failed 12/45 subtests 

This is caused by upgrading perl-Encode from 4:2.84-11.fc26 to 4:2.85-1.fc26.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

[Bug 1375919] perl-Net-Pcap-0.18-1.fc26 FTBFS: t/08-filter.t fails

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1375919

Petr Pisar  changed:

   What|Removed |Added

External Bug ID||CPAN 117831



-- 
You are receiving this mail because:
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

[Bug 1375919] New: perl-Net-Pcap-0.18-1.fc26 FTBFS: t/08-filter.t fails

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1375919

Bug ID: 1375919
   Summary: perl-Net-Pcap-0.18-1.fc26 FTBFS: t/08-filter.t fails
   Product: Fedora
   Version: rawhide
 Component: perl-Net-Pcap
  Assignee: jples...@redhat.com
  Reporter: ppi...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: iarn...@gmail.com, jples...@redhat.com,
perl-devel@lists.fedoraproject.org



perl-Net-Pcap-0.18-1.fc26 fails to build in F26 because a test fails:

t/08-filter.t .. ok
#   Failed test ' - $err must not be null: syntax error in filter expression:
syntax error'
#   at t/09-error.t line 25.
#   'syntax error in filter expression: syntax error'
# doesn't match '/^(?:parse|syntax) error$/'
# Looks like you failed 1 test of 10.
t/09-error.t ... 
Dubious, test returned 1 (wstat 256, 0x100)
Failed 1/10 subtests 

This is cause by upgrading libpcap from 14:1.7.4-2.fc24 to 14:1.8.0-1.fc26. It
looks like libpcap changed the error message wording.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

Re: Resultsdb v2.0 - API docs

[Josef Skladanka]

On Tue, Sep 13, 2016 at 8:19 PM, Randy Barlow 
wrote:

> Will the api/v1.0/ endpoint continue to function as-is for a while, to
> give integrators time to adjust to the new API? That would be ideal for
> Bodhi, so we can adjust our code to work with v2.0 after it is already in
> production. If not, we will need to coordinate bodhi and resultsdb releases
> at the same time.
>

Hey! There is a plan for the  v1.0 endpoint to work, even though being a
bit limited in features, but from what I remember about Bodhi, that will
not affect it at all.
___
qa-devel mailing list
qa-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/qa-devel@lists.fedoraproject.org

jplesnik pushed to perl-DBIx-Class (master). "Fix test failures of t/prefetch/grouped.t (BZ#1370461)"

[notifications]

From 9fa7d3fd91830d1a700a474a2e69f9f817147c13 Mon Sep 17 00:00:00 2001
From: Jitka Plesnikova 
Date: Wed, 14 Sep 2016 10:54:54 +0200
Subject: Fix test failures of t/prefetch/grouped.t (BZ#1370461)

---
 DBIx-Class-0.082840-Fix-test-RT117271.patch | 37 +
 perl-DBIx-Class.spec|  9 ++-
 2 files changed, 45 insertions(+), 1 deletion(-)
 create mode 100644 DBIx-Class-0.082840-Fix-test-RT117271.patch

diff --git a/DBIx-Class-0.082840-Fix-test-RT117271.patch 
b/DBIx-Class-0.082840-Fix-test-RT117271.patch
new file mode 100644
index 000..0edf1a0
--- /dev/null
+++ b/DBIx-Class-0.082840-Fix-test-RT117271.patch
@@ -0,0 +1,37 @@
+From adcc1df0049e0093cb94c867bd2be8c9fe242a61 Mon Sep 17 00:00:00 2001
+From: Peter Rabbitson 
+Date: Tue, 13 Sep 2016 17:15:48 +0200
+Subject: [PATCH] Fix for upcoming (not yet available via DBD::SQLite)
+ libsqlite version
+
+---
+ Changes  | 2 ++
+ t/prefetch/grouped.t | 2 +-
+ 2 files changed, 3 insertions(+), 1 deletion(-)
+
+#diff --git a/Changes b/Changes
+#index 72d7647..e402e5a 100644
+#--- a/Changes
+#+++ b/Changes
+#@@ -73,6 +73,8 @@ Revision history for DBIx::Class
+#   working with copy() in t/icdt/engine_specific/sybase.t (GH#84)
+# - Fix t/54taint.t failing on local::lib's with upgraded Carp on 5.8.*
+# - Fix invalid variable names in ResultSource::View examples
+#+- Fix missing ORDER BY leading to failures of t/prefetch/grouped.t
+#+  under upcoming libsqlite (RT#117271)
+# - Skip tests in a way more intelligent and speedy manner when 
optional
+#   dependencies are missing
+# - Make the Optional::Dependencies error messages cpanm-friendly
+diff --git a/t/prefetch/grouped.t b/t/prefetch/grouped.t
+index 4aad6b1..c0d2224 100644
+--- a/t/prefetch/grouped.t
 b/t/prefetch/grouped.t
+@@ -100,7 +100,7 @@ my @cdids = sort $cd_rs->get_column ('cdid')->all;
+ 
+   # add an extra track to one of the cds, and then make sure we can get it on 
top
+   # (check if limit works)
+-  my $top_cd = $cd_rs->slice (1,1)->next;
++  my $top_cd = $cd_rs->search({}, { order_by => 'cdid' })->slice (1,1)->next;
+   $top_cd->create_related ('tracks', {
+ title => 'over the top',
+   });
diff --git a/perl-DBIx-Class.spec b/perl-DBIx-Class.spec
index 51fd9c4..fbbe972 100644
--- a/perl-DBIx-Class.spec
+++ b/perl-DBIx-Class.spec
@@ -1,11 +1,14 @@
 Name:   perl-DBIx-Class
 Summary:Extensible and flexible object <-> relational mapper
 Version:0.082840
-Release:1%{?dist}
+Release:2%{?dist}
 License:GPL+ or Artistic
 Group:  Development/Libraries
 Source0:
http://search.cpan.org/CPAN/authors/id/R/RI/RIBASUSHI/DBIx-Class-%{version}.tar.gz
 URL:http://search.cpan.org/dist/DBIx-Class/
+# Fix missing ORDER BY leading to failures of t/prefetch/grouped.t under
+# upcoming libsqlite (RT#117271)
+Patch0: DBIx-Class-0.082840-Fix-test-RT117271.patch
 BuildArch:  noarch
 # Build
 BuildRequires:  coreutils
@@ -267,6 +270,7 @@ DISTINCT, GROUP BY and HAVING support.
 
 %prep
 %setup -q -n DBIx-Class-%{version}
+%patch0 -p1
 chmod -c +x script/*
 # skip dbic_pretty.t when bootstrapping
 %if 0%{?perl_bootstrap}
@@ -297,6 +301,9 @@ make test
 %{_mandir}/man[13]/*
 
 %changelog
+* Wed Sep 14 2016 Jitka Plesnikova  - 0.082840-2
+- Fix test failures of t/prefetch/grouped.t (BZ#1370461)
+
 * Mon Jun 20 2016 Jitka Plesnikova  - 0.082840-1
 - 0.082840 bump
 
-- 
cgit v0.12



http://pkgs.fedoraproject.org/cgit/perl-DBIx-Class.git/commit/?h=master=9fa7d3fd91830d1a700a474a2e69f9f817147c13
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

[EPEL-devel] Re: Requirements for SRPM names

[Paul Howarth]

On 14/09/16 03:51, Dennis Gilmore wrote:

So, with the limited arch packages this means that _ALL_ things
building in koji will use the epel package. The reason for the
prepended 0 is so that users don't install the epel package and instead
get the newer rhel version. The limited arch guideline also says you
should try and keep the package as close as possible to the rhel
version.


For el7, and even in some of the big (java*) use cases in el6 the
delta in packages between the arches is getting a lot less, and I
believe this will be more so as we move forward in el7.

I honestly am not sure there is any limited arch packages in epel7


I think po4a may be one:

https://bugzilla.redhat.com/show_bug.cgi?id=1134624

Paul.
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org

Re: Python SIG on-boarding issue

[Charalampos Stratakis]

+1 on everything

Charalampos Stratakis
Associate Software Engineer
Python Maintenance Team, Red Hat


- Original Message -
From: "Dhanesh Bhalchandra Sabane" 
To: python-devel@lists.fedoraproject.org
Sent: Tuesday, September 13, 2016 7:27:48 PM
Subject: Re: Python SIG on-boarding issue

Aloha Python-SIG!
I was wondering whether it is a good time to make the new pages official. Also, 
I would like to know whether the idea of splitting the SIG into two FAS groups 
is acceptable so that we can start taking necessary actions. 

> CommOps is currently working on the Python SIG On-Boarding ticket [1] and one 
> of the tasks
> we have identified is re-writing the Python SIG wiki page to make it more
> beginner-friendly. I was assigned with this particular task which is now 
> complete [2] [3].
>  We received some feedback from mhroncok today during the CommOps meeting and 
> following
> points were discussed:
> 
> 1. Splitting Python SIG in two FAS groups: 
> 1.1 *python-sig* for newcomers and interested members who hang out and help 
> with Python on
> Fedora
> 1.2 *python-packagers* for proven members of the community / packagers who 
> will also
> receive security-related bugs. Promising members from *python-sig* group can 
> be promoted
> to *python-packagers* given that they have contributed to the package's git. 
> 
> 2. Python Features section on the wiki page needs some love.
> 
> 3.  Targeting specific information for newcomers to include in their 
> self-introductions
> that would be helpful for SIG members to know where someone fits in the 
> Python community
> and what their expertise is.
> 
> We would like to hear your feedback on the draft and also on the 
> aforementioned points.
> Everyone is welcome to leave a comment on the ticket[1].
> 
> [1] https://pagure.io/fedora-commops/issue/84
> [2] https://fedoraproject.org/wiki/User:Dhanesh95/SIGs/Python
> [3] https://fedoraproject.org/wiki/User:Dhanesh95/SIGs/Python/Join

---
Dhanesh B. Sabane
___
python-devel mailing list
python-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/python-devel@lists.fedoraproject.org
___
python-devel mailing list
python-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/python-devel@lists.fedoraproject.org

Re: F24, small backward steps

[Florian Weimer]

On 09/13/2016 07:44 PM, Josh Boyer wrote:


That is the crux of the problem with this approach.  It is impossible
for a user to determine which packages have maintainers that look in
RH Bugzilla and which do not.


We could have a “Tire Fire” product besides the “Fedora” product in 
bugzilla.redhat.com, and move the GNOME components to this product, to 
make clear that these components are treated differently.


Florian
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24, small backward steps

[Pierre-Yves Chibon]

On Tue, Sep 13, 2016 at 01:20:06PM -0500, Michael Catanzaro wrote:
> On Tue, 2016-09-13 at 18:49 +0200, Pierre-Yves Chibon wrote:
> > If ABRT is a firehose of bugs flying to RH's bugzilla, would the
> > situation be
> > really better if the reports were sent to gnome's BZ?
> 
> Yes, it would. Keep in mind that upstream maintainers are responsible
> for far fewer packages than Fedora maintainers. A busy GNOME maintainer
> might maintain 2-5 packages upstream, but 20-50 Fedora packages (not
> counting comaintainence, then we're talking hundreds). It's a lot
> easier to look at crashes for 2-5 packages than 20-50 packages.

So, I'm going for the crazy idea front here, now that RHBZ is hooked onto
fedmsg, should we try to write a tool creating bugs on GBZ for each gnome bugs
created on RHBZ and sync comments between both instances? (well, we would have
to see if we can get the GBZ onto a message bus of any sort)

This would:
* allow bugs to be reported upstream where more people can look at them
* allow bugs to be reported upstream without the need for the original reporter
  to create yet another account on yet another BZ
* keep the discussion in both places
* eventually allow us to tweak things so that we try to report only bugs that
  are of interest
  (for example, we could start by reporting all the user-reported bugs, as
  opposed to those opened by automated tools (ABRT & others))

Call me crazy, but that was in essence my idea behind the question: `would 
things
be really better if the bugs were opened on GBZ?` and you replied `yes` :)


Pierre
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24, small backward steps

[Ralf Corsepius]

On 09/13/2016 07:19 PM, Paul Wouters wrote:

On Tue, 13 Sep 2016, Ralf Corsepius wrote:


 This is a truly awful experiance from POV of a Fedora user filing
bugs :-(
 We've set a silent trap for them with no warning of the fact that their
 bug reports are going to be ignored until Fedora EOL procedure closes
 them :-(


One lesson I have learnt in Fedora, is that filing bugs reports
against packages owned by certain people equals to sending bugs to
/dev/null.

IMHO, Fedora should consider to take disciplinary measures against
these people.


And get less packagers?


Yes, why not? A non-responsive maintainer, who is systematically not 
processing the bugs having been filed against his packages in RHBZ is 
cheating himself, Fedora's users and the Fedora project. He is not doing 
his Fedora job.


To cut a long story short: Such a person is harmful to everyone being 
involved and therefore should be facing sanctions.



It would be useful if package co-owners would automatically get added to
the bugzilla bug, instead of only the package owner. Most packages don't
have dedicated aliases for that.

Urgh? I thought this was the case?

Ralf


--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24, small backward steps

[Jakub Filak]

On 09/13/2016 05:00 PM, Michael Catanzaro wrote:
> Hi,
> 
> To be clear, the problem is that a small handful of package maintainers
> (including Bastien) are collectively "responsible" for all of the GNOME
> and freedesktop components in Fedora (including fprintd), and it's
> simply not reasonable to expect them to read all the bugs that are
> assigned to them, let alone take the time to forward them upstream. 

That's why https://retrace.fedoraproject.org/faf/ exists.
Overloaded developers can focus on the hottest problems.

This link points to F24 and F25 hottest problems in components where Bastien
is in charge of maintenance:

https://retrace.fedoraproject.org/faf/problems/?opsysreleases=122=123=51


Jakub
ABRT
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24, small backward steps

[Ralf Corsepius]

On 09/13/2016 07:44 PM, Josh Boyer wrote:


That is the crux of the problem with this approach.  It is impossible
for a user to determine which packages have maintainers that look in
RH Bugzilla and which do not.


IMO, it should be mandatory for Fedora maintainers to look into RH 
Bugzilla, because that's the product they are "maintaining" and what 
users are using.


Them not looking into RHBZ to me qualifies as them not doing their job 
as package maintainer.


Ralf


--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24, small backward steps

[Jakub Filak]

On 09/13/2016 06:32 PM, Bastien Nocera wrote:
> 
> 
> - Original Message -
> 
> 
> A couple of things could be done to help with that:
> - Bring back the x-bugzilla .desktop metadata, and have ABRT file upstream 
> bugs

Does GNOME Bugzilla support XMLRPC? Is there any testing instance ABRT team
can play with?

One problem I can see is that Fedora users will have to register to every
single upstream bug tracking tool. Using Red Hat Bugzilla as a proxy to
upstream bug tracking tools is pretty convenient.

> - Make ABRT reports more useful (right now it's attaches a *lot* of extra
>   information, basically everything it can, as files). It's not possible
>   to search for parts of backtraces in the query tool.

Every ABRT report includes either 10 most relevant frames (so called
truncated backtrace) or entire backtrace if it's short enough.

We would love to make ABRT reports more useful. I am keen to hear
suggestions and ideas.


Jakub
ABRT
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Fedora 25-20160911.n.0 compose check report

[Adam Williamson]

On Tue, 2016-09-13 at 21:37 -0700, Adam Williamson wrote:
> 
> I'll talk to upstream and see if we can identify the bug and get it
> fixed. I could teach the compose check report sender to keep a record
> of what composes it's sent mails for and refuse to duplicate reports
> without a manual override, but it'd make it a bit messier so I'll only
> do that if we can't fix the openQA bug soon...

OK, OK, I know, five duplicates is too many. You can put your
pitchforks down now!

https://git.fedorahosted.org/cgit/fedora-qa.git/commit/?id=2634cdac734e620086b6b330e111b6068102c581
-- 
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://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org