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

2016-09-14 Thread 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 m

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

2016-09-14 Thread 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 1

Re: How to obsolete a subpackage?

2016-09-14 Thread 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). Summ

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

2016-09-14 Thread 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 cra

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

2016-09-14 Thread 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:

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

2016-09-14 Thread 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, b

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

2016-09-14 Thread 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 d

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

2016-09-14 Thread 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 replac

Fedora Rawhide-20160914.n.0 compose check report

2016-09-14 Thread 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.or

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

2016-09-14 Thread 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

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

2016-09-14 Thread 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 test

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

2016-09-14 Thread 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 b

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

2016-09-14 Thread 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 subt

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

2016-09-14 Thread 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

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

2016-09-14 Thread 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

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

2016-09-14 Thread 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 repe

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

2016-09-14 Thread 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 ...

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

2016-09-14 Thread 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 asse

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

2016-09-14 Thread 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 exp

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

2016-09-14 Thread 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 w

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

2016-09-14 Thread 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 )

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

2016-09-14 Thread 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 n

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

2016-09-14 Thread 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. M

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

2016-09-14 Thread 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 expres

Re: Triaging RH Bugzilla and forwarding bugs upstream

2016-09-14 Thread 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.

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

2016-09-14 Thread 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

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

2016-09-14 Thread 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.

Re: _unitdir macro

2016-09-14 Thread 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=1563273

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

2016-09-14 Thread 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"

Re: F24, small backward steps

2016-09-14 Thread 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 a

Re: _unitdir macro

2016-09-14 Thread 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 a

Re: F24, small backward steps

2016-09-14 Thread 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'

Re: Triaging RH Bugzilla and forwarding bugs upstream

2016-09-14 Thread 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.

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

2016-09-14 Thread 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

_unitdir macro

2016-09-14 Thread 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

Re: Triaging RH Bugzilla and forwarding bugs upstream

2016-09-14 Thread 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 p

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

2016-09-14 Thread 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 pr

Re: F24, small backward steps

2016-09-14 Thread 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 > th

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

2016-09-14 Thread 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 disagre

Re: F24, small backward steps

2016-09-14 Thread 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

Re: F24, small backward steps

2016-09-14 Thread 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 >

Re: F24, small backward steps

2016-09-14 Thread Michael Catanzaro
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

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

2016-09-14 Thread 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

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

2016-09-14 Thread 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 "mainta

Re: F24, small backward steps

2016-09-14 Thread 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 'maint

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

2016-09-14 Thread 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 pro

Re: How to obsolete a subpackage?

2016-09-14 Thread 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

Re: How to obsolete a subpackage?

2016-09-14 Thread 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/

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

2016-09-14 Thread 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;

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

2016-09-14 Thread 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

Re: How to obsolete a subpackage?

2016-09-14 Thread 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 appropri

Re: How to obsolete a subpackage?

2016-09-14 Thread 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 th

Re: How to obsolete a subpackage?

2016-09-14 Thread 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

How to obsolete a subpackage?

2016-09-14 Thread 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: wart

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

2016-09-14 Thread 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)? >

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

2016-09-14 Thread 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

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

2016-09-14 Thread 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

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

2016-09-14 Thread 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.

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

2016-09-14 Thread 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? > Probabl

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

2016-09-14 Thread 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

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

2016-09-14 Thread 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

Re: F24, small backward steps

2016-09-14 Thread 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.redha

Re: F24, small backward steps

2016-09-14 Thread 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

Re: F24, small backward steps

2016-09-14 Thread 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 proce

Re: F24, small backward steps

2016-09-14 Thread 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

Re: F24, small backward steps

2016-09-14 Thread 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, becau