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

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

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

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

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

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

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

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

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

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.

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

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

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

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

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

 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

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

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

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

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

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

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?

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

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

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

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

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 - >

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,

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

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)

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

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

Fedora Rawhide-20160914.n.0 compose check report

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:

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

https://bugzilla.redhat.com/show_bug.cgi?id=1370461 Fedora Update System changed: What|Removed |Added Status|MODIFIED|ON_QA

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

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

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

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

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

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

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

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

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

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"

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

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

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

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

Broken dependencies: perl-Alien-ROOT

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

Broken dependencies: perl-Data-Alias

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

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

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 >

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

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

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

https://bugzilla.redhat.com/show_bug.cgi?id=1372492 Fedora Update System changed: What|Removed |Added Fixed In Version|perl-Config-Model-Tester-2.

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

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

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

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

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

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

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

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 )

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

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

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

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.

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

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

Re: Triaging RH Bugzilla and forwarding bugs upstream

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

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

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

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

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.

Re: _unitdir macro

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:

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

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

Re: F24, small backward steps

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

Re: _unitdir macro

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 > >

Re: F24, small backward steps

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

Re: Triaging RH Bugzilla and forwarding bugs upstream

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

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

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.

_unitdir macro

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

Re: Triaging RH Bugzilla and forwarding bugs upstream

> "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

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

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

Re: F24, small backward steps

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

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

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

Re: F24, small backward steps

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 >

Re: F24, small backward steps

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 >

dist.upgradepath FAILED for FEDORA-2016-d83b8432cd

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

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

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

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

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

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

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,

Re: F24, small backward steps

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'

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

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

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

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;

Re: How to obsolete a subpackage?

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

Re: How to obsolete a subpackage?

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

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

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>

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

See -- [...truncated 3597 lines...] suites/password/pwdPolicy_inherit_global_test.py::test_entry_has_no_restrictions[off-off] PASSED

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

> "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

Re: How to obsolete a subpackage?

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

Re: How to obsolete a subpackage?

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

Re: How to obsolete a subpackage?

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

How to obsolete a subpackage?

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:

Re: RFR: New Dist-Git Task Storage Proposal

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

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

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

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

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

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

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

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

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.

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

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

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

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

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

> # 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

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

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

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

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

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

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

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

https://bugzilla.redhat.com/show_bug.cgi?id=1370461 Jitka Plesnikova changed: What|Removed |Added Fixed In Version|

Re: RFR: New Dist-Git Task Storage Proposal

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. > > > >

[EPEL-devel] Re: Requirements for SRPM names

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

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

https://bugzilla.redhat.com/show_bug.cgi?id=1375929 Petr Pisar changed: What|Removed |Added External Bug ID||CPAN 117158 -- You

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

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

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

https://bugzilla.redhat.com/show_bug.cgi?id=1375919 Petr Pisar changed: What|Removed |Added External Bug ID||CPAN 117831 -- You

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

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

Re: Resultsdb v2.0 - API docs

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

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

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

[EPEL-devel] Re: Requirements for SRPM names

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

Re: Python SIG on-boarding issue

+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:

Re: F24, small backward steps

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

Re: F24, small backward steps

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

Re: F24, small backward steps

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

Re: F24, small backward steps

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

Re: F24, small backward steps

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,

Re: F24, small backward steps

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

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

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

  1   2   >