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
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
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
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
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
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
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
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
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.
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
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
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)?
>
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
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
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
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
> "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
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;
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/
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
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
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
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
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
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
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
>
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
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
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
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
> "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
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
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
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.
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'
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
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
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"
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
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.
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
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.
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
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
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
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 )
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
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
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
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 ...
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
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
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
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
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
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
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
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
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
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
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
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:
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
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
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
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
66 matches
Mail list logo
