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

2016-09-19 Thread Matthew Miller
On Mon, Sep 19, 2016 at 10:22:40AM +0100, Richard Hughes wrote:
> I still thing the preferred option is "just use openjpeg" but this at
> least gets things moving in the right direction.

Thanks Richard — that's excellent.

-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


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

2016-09-19 Thread Florian Weimer

On 09/18/2016 04:01 AM, Kevin Kofler wrote:

Michael Catanzaro wrote:

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.


Actually, int → ssize_t is an ABI change only on 64-bit architectures. On
32-bit architectures, the size is not going to change. But, as our main
architecture is x86_64, this sounds like a recipe for crashes indeed.


It can change C++ name mangling even on 32-bit architectures because 
some use long for ssize_t.


Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


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

2016-09-19 Thread Richard Hughes
On 14 September 2016 at 20:50, 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?

Sorry to drag up an old thread, and also for replying to myself. I've
been talking to upstream about the current state of upstream
maintenance over the last few days. The team at University of Victoria
have created an official upstream git repo:
https://github.com/mdadams/jasper where the maintainer will review
open patches and merge them with master, cutting a new release when
required. I've opened up pull requests for all the patches in Fedora
that still apply.

I still thing the preferred option is "just use openjpeg" but this at
least gets things moving in the right direction.

Richard.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


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

2016-09-18 Thread Pierre-Yves Chibon
On Sun, Sep 18, 2016 at 01:52:05PM +0100, Jonathan Wakely wrote:
> On 18/09/16 13:48 +0100, Jonathan Wakely wrote:
> > On 17/09/16 08:46 -0600, Kevin Fenzi wrote:
> > > On Sat, 17 Sep 2016 15:30:34 +0100
> > > Jonathan Wakely  wrote:
> > > 
> > > > On 16/09/16 12:55 -0600, Kevin Fenzi wrote:
> > > > > On Fri, 16 Sep 2016 10:54:57 -0500
> > > > > Michael Catanzaro  wrote:
> > > > > 
> > > > > > On Fri, 2016-09-16 at 10:33 +0100, Jonathan Wakely wrote:
> > > > > > > Given how hard it is to enable those notifications correctly, we
> > > > > > > should just enable them by default for everyone. Or at least for
> > > > > > > anyone maintaining a critpath package (which are the only ones
> > > > > > > being abichecked today anyway).
> > > > > > 
> > > > > > FWIW gave up trying to configure my notifications and just turned
> > > > > > them all off. Last time I checked, I couldn't find a way to
> > > > > > configure notifications on a package-specific basis. The flood of
> > > > > > notifications from packages I have commit access to but don't want
> > > > > > to receive notifications for was pretty overwhelming.
> > > > > 
> > > > > I know a lot of folks find it difficult to configure.
> > > > > 
> > > > > I proposed some docs changes that might (I hope) help people:
> > > > > 
> > > > > https://github.com/fedora-infra/fmn.web/pull/76/commits/93bbe73e514b86c59403d9362920e53c38033c8e
> > > > > 
> > > > > Other suggestions to make it easier welcome.
> > > > 
> > > > Fixing the 404 for the taskotron docs would help :-)
> > > 
> > > Can you be more specific? "The taskotron docs" ?
> > > 
> > > kevin
> > 
> > See the specifics I gave in
> > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/J4IBLB3PMBCN4J4EQQCBEQZ4HSADMRIY/
> > 
> > The "Particular taskotron task outcome" rule has a link to "the
> > libtaskotron documentation" which links to
> > https://docs.qadevel.cloud.fedoraproject.org/libtaskotron/latest/resultyaml.html#minimal-version
> > which gives a 404.
> > 
> > It appears that the link is missing "docs/" as this looks like the
> > relevant documentation:
> > https://docs.qadevel.cloud.fedoraproject.org/libtaskotron/latest/docs/resultyaml.html#minimal-version
> 
> I tried looking in fmn.web for that link, but it doesn't seem to come
> from there, so I can't send a github pull request with a fix.

The links are most likely generated by fedmsg_meta_fedora_infrastructure which
is the library in charge of converting a fedmsg message to a human readable
format (links, list of users, list of packages, single-line description,
multi-lines description...)


Pierre
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


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

2016-09-18 Thread Jonathan Wakely

On 18/09/16 13:48 +0100, Jonathan Wakely wrote:

On 17/09/16 08:46 -0600, Kevin Fenzi wrote:

On Sat, 17 Sep 2016 15:30:34 +0100
Jonathan Wakely  wrote:


On 16/09/16 12:55 -0600, Kevin Fenzi wrote:

On Fri, 16 Sep 2016 10:54:57 -0500
Michael Catanzaro  wrote:


On Fri, 2016-09-16 at 10:33 +0100, Jonathan Wakely wrote:
> Given how hard it is to enable those notifications correctly, we
> should just enable them by default for everyone. Or at least for
> anyone maintaining a critpath package (which are the only ones
> being abichecked today anyway).

FWIW gave up trying to configure my notifications and just turned
them all off. Last time I checked, I couldn't find a way to
configure notifications on a package-specific basis. The flood of
notifications from packages I have commit access to but don't want
to receive notifications for was pretty overwhelming.


I know a lot of folks find it difficult to configure.

I proposed some docs changes that might (I hope) help people:

https://github.com/fedora-infra/fmn.web/pull/76/commits/93bbe73e514b86c59403d9362920e53c38033c8e

Other suggestions to make it easier welcome.


Fixing the 404 for the taskotron docs would help :-)


Can you be more specific? "The taskotron docs" ?

kevin


See the specifics I gave in
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/J4IBLB3PMBCN4J4EQQCBEQZ4HSADMRIY/

The "Particular taskotron task outcome" rule has a link to "the
libtaskotron documentation" which links to
https://docs.qadevel.cloud.fedoraproject.org/libtaskotron/latest/resultyaml.html#minimal-version
which gives a 404.

It appears that the link is missing "docs/" as this looks like the
relevant documentation:
https://docs.qadevel.cloud.fedoraproject.org/libtaskotron/latest/docs/resultyaml.html#minimal-version


I tried looking in fmn.web for that link, but it doesn't seem to come
from there, so I can't send a github pull request with a fix.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


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

2016-09-18 Thread Jonathan Wakely

On 17/09/16 08:46 -0600, Kevin Fenzi wrote:

On Sat, 17 Sep 2016 15:30:34 +0100
Jonathan Wakely  wrote:


On 16/09/16 12:55 -0600, Kevin Fenzi wrote:
>On Fri, 16 Sep 2016 10:54:57 -0500
>Michael Catanzaro  wrote:
>
>> On Fri, 2016-09-16 at 10:33 +0100, Jonathan Wakely wrote:
>> > Given how hard it is to enable those notifications correctly, we
>> > should just enable them by default for everyone. Or at least for
>> > anyone maintaining a critpath package (which are the only ones
>> > being abichecked today anyway).
>>
>> FWIW gave up trying to configure my notifications and just turned
>> them all off. Last time I checked, I couldn't find a way to
>> configure notifications on a package-specific basis. The flood of
>> notifications from packages I have commit access to but don't want
>> to receive notifications for was pretty overwhelming.
>
>I know a lot of folks find it difficult to configure.
>
>I proposed some docs changes that might (I hope) help people:
>
>https://github.com/fedora-infra/fmn.web/pull/76/commits/93bbe73e514b86c59403d9362920e53c38033c8e
>
>Other suggestions to make it easier welcome.

Fixing the 404 for the taskotron docs would help :-)


Can you be more specific? "The taskotron docs" ?

kevin


See the specifics I gave in
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/J4IBLB3PMBCN4J4EQQCBEQZ4HSADMRIY/

The "Particular taskotron task outcome" rule has a link to "the
libtaskotron documentation" which links to
https://docs.qadevel.cloud.fedoraproject.org/libtaskotron/latest/resultyaml.html#minimal-version
which gives a 404.

It appears that the link is missing "docs/" as this looks like the
relevant documentation:
https://docs.qadevel.cloud.fedoraproject.org/libtaskotron/latest/docs/resultyaml.html#minimal-version
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


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

2016-09-17 Thread Kevin Kofler
Michael Catanzaro wrote:
> 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.

Actually, int → ssize_t is an ABI change only on 64-bit architectures. On 
32-bit architectures, the size is not going to change. But, as our main 
architecture is x86_64, this sounds like a recipe for crashes indeed.

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


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

2016-09-17 Thread Kevin Fenzi
On Sat, 17 Sep 2016 15:30:34 +0100
Jonathan Wakely  wrote:

> On 16/09/16 12:55 -0600, Kevin Fenzi wrote:
> >On Fri, 16 Sep 2016 10:54:57 -0500
> >Michael Catanzaro  wrote:
> >  
> >> On Fri, 2016-09-16 at 10:33 +0100, Jonathan Wakely wrote:  
> >> > Given how hard it is to enable those notifications correctly, we
> >> > should just enable them by default for everyone. Or at least for
> >> > anyone maintaining a critpath package (which are the only ones
> >> > being abichecked today anyway).  
> >>
> >> FWIW gave up trying to configure my notifications and just turned
> >> them all off. Last time I checked, I couldn't find a way to
> >> configure notifications on a package-specific basis. The flood of
> >> notifications from packages I have commit access to but don't want
> >> to receive notifications for was pretty overwhelming.  
> >
> >I know a lot of folks find it difficult to configure.
> >
> >I proposed some docs changes that might (I hope) help people:
> >
> >https://github.com/fedora-infra/fmn.web/pull/76/commits/93bbe73e514b86c59403d9362920e53c38033c8e
> >
> >Other suggestions to make it easier welcome.  
> 
> Fixing the 404 for the taskotron docs would help :-)

Can you be more specific? "The taskotron docs" ?

kevin


pgpG408_bDrR2.pgp
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


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

2016-09-17 Thread Jonathan Wakely

On 16/09/16 12:55 -0600, Kevin Fenzi wrote:

On Fri, 16 Sep 2016 10:54:57 -0500
Michael Catanzaro  wrote:


On Fri, 2016-09-16 at 10:33 +0100, Jonathan Wakely wrote:
> Given how hard it is to enable those notifications correctly, we
> should just enable them by default for everyone. Or at least for
> anyone maintaining a critpath package (which are the only ones being
> abichecked today anyway).

FWIW gave up trying to configure my notifications and just turned them
all off. Last time I checked, I couldn't find a way to configure
notifications on a package-specific basis. The flood of notifications
from packages I have commit access to but don't want to receive
notifications for was pretty overwhelming.


I know a lot of folks find it difficult to configure.

I proposed some docs changes that might (I hope) help people:

https://github.com/fedora-infra/fmn.web/pull/76/commits/93bbe73e514b86c59403d9362920e53c38033c8e

Other suggestions to make it easier welcome.


Fixing the 404 for the taskotron docs would help :-)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


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

2016-09-16 Thread Kevin Fenzi
On Fri, 16 Sep 2016 10:54:57 -0500
Michael Catanzaro  wrote:

> On Fri, 2016-09-16 at 10:33 +0100, Jonathan Wakely wrote:
> > Given how hard it is to enable those notifications correctly, we
> > should just enable them by default for everyone. Or at least for
> > anyone maintaining a critpath package (which are the only ones being
> > abichecked today anyway).  
> 
> FWIW gave up trying to configure my notifications and just turned them
> all off. Last time I checked, I couldn't find a way to configure
> notifications on a package-specific basis. The flood of notifications
> from packages I have commit access to but don't want to receive
> notifications for was pretty overwhelming.

I know a lot of folks find it difficult to configure. 

I proposed some docs changes that might (I hope) help people:

https://github.com/fedora-infra/fmn.web/pull/76/commits/93bbe73e514b86c59403d9362920e53c38033c8e

Other suggestions to make it easier welcome. 

kevin


pgpL870oltzHc.pgp
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


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

2016-09-16 Thread Michael Catanzaro
On Fri, 2016-09-16 at 10:33 +0100, Jonathan Wakely wrote:
> Given how hard it is to enable those notifications correctly, we
> should just enable them by default for everyone. Or at least for
> anyone maintaining a critpath package (which are the only ones being
> abichecked today anyway).

FWIW gave up trying to configure my notifications and just turned them
all off. Last time I checked, I couldn't find a way to configure
notifications on a package-specific basis. The flood of notifications
from packages I have commit access to but don't want to receive
notifications for was pretty overwhelming.

Michael
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


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

2016-09-16 Thread Jonathan Wakely

On 15/09/16 14:53 +0200, Dodji Seketeli wrote:

Right, as I said in another message, the Taskotron's task-abicheck task
actually caught it at Koji build time, asking the maintainer to review
the change at:

https://taskotron.fedoraproject.org/artifacts/all/532e5e32-6055-11e6-b56f-525400120b80/task_output/jasper-1.900.1-33.fc24.log

Normally, the maintainer received a notification *if* the notification
was enabled in her/his settings.


I've just gone to https://apps.fedoraproject.org/notifications/ to
make sure I have the relevant Taskotron notifcations enabled. I
didn't.

It's not at all simple to figure out what needs to be enabled. I found
the "Particular taskotron task outcome" rule which says:


The full list of supported outcomes can be found in the libtaskotron
documentation.


but the link gives a 404. Great. So I guessed that FAILED is what I
want. But Dodji tells me that's wrong and I need
FAILED,NEED_INSPECTION.

The inline text for the rule should be updated to mention
NEED_INSPECTION and/or the link to the docs should be fixed so we can
actually read the docs.

Given how hard it is to enable those notifications correctly, we
should just enable them by default for everyone. Or at least for
anyone maintaining a critpath package (which are the only ones being
abichecked today anyway).
--
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

2016-09-15 Thread Dodji Seketeli
Adam Williamson  a écrit:

>> Though, we also need to sort out how maintainers can do to say "I
>> reviewed the ABI change, and it's OK" -- a kind of waiving mechanism for
>> cases where the ABI change is harmless.
>
> If we only make it so failed automated tests disable *autopush* for
> now, we have an 'override mechanism' for free - if the result is bogus,
> the maintainer can just manually push the update stable.

Right.  This is cool.

I guess we'd just need to encourage maintainers to document *why* they
pushed the update despite the (potentially) different Taskotron test
results that were supposed to block it.

Cheers,

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

2016-09-15 Thread Michael Cronenworth

On 09/15/2016 12:00 PM, Matthew Miller wrote:

I like that. What about having failed tests also provide negative
karma?


As long as it doesn't automatically unpush either. Can it be classified the same as 
anonymous karma? The downtime from having to re-push an un-pushed update is irritating.

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

2016-09-15 Thread Matthew Miller
On Thu, Sep 15, 2016 at 09:32:37AM -0700, Adam Williamson wrote:
> > Though, we also need to sort out how maintainers can do to say "I
> > reviewed the ABI change, and it's OK" -- a kind of waiving mechanism for
> > cases where the ABI change is harmless.
> If we only make it so failed automated tests disable *autopush* for
> now, we have an 'override mechanism' for free - if the result is bogus,
> the maintainer can just manually push the update stable.

I like that. What about having failed tests also provide negative
karma?

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

2016-09-15 Thread Adam Williamson
On Thu, 2016-09-15 at 15:10 +0200, Dodji Seketeli wrote:
> Josh Boyer  a écrit:
> 
> 
> [...]
> 
> 
> > > At the moment, the ABI changes that are reported do not trigger the
> > > blocking of the build, so we need collaboration from critpath package
> > > maintainers.  Whenever Taskotron says "please review this ABI change",
> > > the review is needed.
> > 
> > 
> > 
> > 
> > Perhaps it would make sense to submit a Change for Fedora 26 to get
> > this in front of FESCo and enabled as blocking.  This is at least the
> > 3rd time we've had an incompatible ABI change and given that we have
> > the tools to prevent it, it might be time to do so.
> 
> 
> 
> 
> Agreed.
> 
> 
> Though, we also need to sort out how maintainers can do to say "I
> reviewed the ABI change, and it's OK" -- a kind of waiving mechanism for
> cases where the ABI change is harmless.

If we only make it so failed automated tests disable *autopush* for
now, we have an 'override mechanism' for free - if the result is bogus,
the maintainer can just manually push the update stable.
> 
-- 
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

2016-09-15 Thread Dodji Seketeli
Dodji Seketeli  a écrit:

> I'll file a Bodhi ticket asap.

There you go:

https://github.com/fedora-infra/bodhi/issues/932
https://github.com/fedora-infra/bodhi/issues/933

Cheers,

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

2016-09-15 Thread Dodji Seketeli
Josh Boyer  a écrit:

> No.  However, bodhi maintenance is changing to a new owner and now
> would be a good time to start filing tickets/issues for function adds
> like this.

Right.

I have thus filed two issues for this:

https://github.com/fedora-infra/bodhi/issues/932
https://github.com/fedora-infra/bodhi/issues/933

I hope this helps.

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

2016-09-15 Thread Dodji Seketeli
Matthew Miller  a écrit:

> On Thu, Sep 15, 2016 at 05:03:40PM +0530, Sinny Kumari wrote:
>> >> one more case for enabling libabigail tests in bodhi ...
>> > I agree.  This would have been caught by libabigail/abicheck as far as I 
>> > know.
> ...
>> > Does anyone know what the blockers are for enabling it in production?
>> Right now abichecks already run in production on set of packages which are
>> listed in critpath[1] and can be viewed [2] or subscribed[3] to. For initial
>
> So, jasper _was_ in the critpath list, and indeed shows up as
> "NEEDS_INSPECTION" in the results list. 

Right.

> Should that information have automatically gotten into bodhi somehow,
> and if so, how?

As we started to discuss in the sub-thread [1], we now need to discuss
how to make that information surface into Bodhi.

I'll file a Bodhi ticket asap.

[1] 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/ZDRC4AHWJYEPCRLLMIA5UHHIWQ7DB6ZF/
 

Cheers,

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

2016-09-15 Thread Matthew Miller
On Thu, Sep 15, 2016 at 05:03:40PM +0530, Sinny Kumari wrote:
> >> one more case for enabling libabigail tests in bodhi ...
> > I agree.  This would have been caught by libabigail/abicheck as far as I 
> > know.
...
> > Does anyone know what the blockers are for enabling it in production?
> Right now abichecks already run in production on set of packages which are
> listed in critpath[1] and can be viewed [2] or subscribed[3] to. For initial

So, jasper _was_ in the critpath list, and indeed shows up as
"NEEDS_INSPECTION" in the results list. Should that information
have automatically gotten into bodhi somehow, and if so, how? 

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

2016-09-15 Thread Josh Boyer
On Thu, Sep 15, 2016 at 9:10 AM, Dodji Seketeli  wrote:
> Josh Boyer  a écrit:
>
> [...]
>
>>> At the moment, the ABI changes that are reported do not trigger the
>>> blocking of the build, so we need collaboration from critpath package
>>> maintainers.  Whenever Taskotron says "please review this ABI change",
>>> the review is needed.
>>
>> Perhaps it would make sense to submit a Change for Fedora 26 to get
>> this in front of FESCo and enabled as blocking.  This is at least the
>> 3rd time we've had an incompatible ABI change and given that we have
>> the tools to prevent it, it might be time to do so.
>
> Agreed.
>
> Though, we also need to sort out how maintainers can do to say "I
> reviewed the ABI change, and it's OK" -- a kind of waiving mechanism for
> cases where the ABI change is harmless.

Yes.

> With time, we try to improve libabigail itself so that the number of
> harmless changes that are reported goes toward zero.  There are also
> ways for package maintainers to tell libabigail to avoid showing them
> classes of ABI changes that are deemed harmless; a suppression mechanism
> like what the Valgrind tool has.
>
> But ultimately, I believe maintainers need to be able to waive a
> Taskotron task result that blocks an update.
>
> Do Bodhi hackers have something in their pipeline to address this?

No.  However, bodhi maintenance is changing to a new owner and now
would be a good time to start filing tickets/issues for function adds
like this.  That can also be part of the Change itself, as this would
clearly be classified as a system wide change needing attention from
lots of different parts of the project.

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

2016-09-15 Thread Dodji Seketeli
Josh Boyer  a écrit:

[...]

>> At the moment, the ABI changes that are reported do not trigger the
>> blocking of the build, so we need collaboration from critpath package
>> maintainers.  Whenever Taskotron says "please review this ABI change",
>> the review is needed.
>
> Perhaps it would make sense to submit a Change for Fedora 26 to get
> this in front of FESCo and enabled as blocking.  This is at least the
> 3rd time we've had an incompatible ABI change and given that we have
> the tools to prevent it, it might be time to do so.

Agreed.

Though, we also need to sort out how maintainers can do to say "I
reviewed the ABI change, and it's OK" -- a kind of waiving mechanism for
cases where the ABI change is harmless.

With time, we try to improve libabigail itself so that the number of
harmless changes that are reported goes toward zero.  There are also
ways for package maintainers to tell libabigail to avoid showing them
classes of ABI changes that are deemed harmless; a suppression mechanism
like what the Valgrind tool has.

But ultimately, I believe maintainers need to be able to waive a
Taskotron task result that blocks an update.

Do Bodhi hackers have something in their pipeline to address this?

Cheers,

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

2016-09-15 Thread Dodji Seketeli
Josh Boyer  a écrit:

> I agree.  This would have been caught by libabigail/abicheck as far as
> I know.

Right, as I said in another message, the Taskotron's task-abicheck task
actually caught it at Koji build time, asking the maintainer to review
the change at:

https://taskotron.fedoraproject.org/artifacts/all/532e5e32-6055-11e6-b56f-525400120b80/task_output/jasper-1.900.1-33.fc24.log

Normally, the maintainer received a notification *if* the notification
was enabled in her/his settings.

That being said, I guess it would be better if Bodhi could take the ABI
verification results into account and refuse to auto-update until
maintainers reviewed the reported ABI changes.  Or a variation around
that that theme.

> Does anyone know what the blockers are for enabling it in production?

We didn't really discuss what needs to be done on the Bodhi side to take
the results of task-abicheck into account.  Until now, we were polishing
things up to the level of task-abicheck.

I guess we should now start the discussion around the Bodhi side of the
equation.

Cheers,

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

2016-09-15 Thread Josh Boyer
On Thu, Sep 15, 2016 at 8:38 AM, Dodji Seketeli  wrote:
> Hello,
>
> Dan Horák  a écrit:
>
>> one more case for enabling libabigail tests in bodhi ...
>
> Well, task-abicheck that is automatically run on all koji builds
> actually *caught* this issue.  I can see that in the taskotron logs from
> 2016-08-12 at:
> https://taskotron.fedoraproject.org/resultsdb/results?page=25_name=dist.abicheck.
>
> It says for libjasper that are changes that need inspection:
>
> 8650382 | 2016-08-12 | 06:32:26.472247 | dist.abicheck | NEEDS_INSPECTION | 
> Time taken: 4.26 second(s) | jasper-1.900.1-33.fc23
>
> When I look in the logs themselves at
> https://taskotron.fedoraproject.org/artifacts/all/532e5e32-6055-11e6-b56f-525400120b80/task_output/jasper-1.900.1-33.fc24.log,
> I can see this lines in particular:
>
> * ABI changes found between jasper-libs-1.900.1-32.fc24.x86_64.rpm and
> jasper-libs-1.900.1-33.fc24.x86_64.rpm. ABI comparison took 1.10
> second(s). Please review them.
>
> [...]
>
> [C]'function char* jas_stream_gets(jas_stream_t*, char*, int)' at
> jas_stream.c:573:1 has some indirect sub-type changes:
>   parameter 3 of type 'int' changed:
> entity changed from 'int' to compatible type 'typedef size_t' at 
> stddef.h:216:1
>
> At the moment, the ABI changes that are reported do not trigger the
> blocking of the build, so we need collaboration from critpath package
> maintainers.  Whenever Taskotron says "please review this ABI change",
> the review is needed.

Perhaps it would make sense to submit a Change for Fedora 26 to get
this in front of FESCo and enabled as blocking.  This is at least the
3rd time we've had an incompatible ABI change and given that we have
the tools to prevent it, it might be time to do so.

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

2016-09-15 Thread Richard Hughes
On 15 September 2016 at 12:08, Matthew Miller  wrote:
> Huh. Does Steam use JPEG2000 for its screenshot or icons or
> something?

Some of the ICNS icons have embedded JPEG-2000 images.

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

2016-09-15 Thread Dodji Seketeli
Hello,

Dan Horák  a écrit:

> one more case for enabling libabigail tests in bodhi ...

Well, task-abicheck that is automatically run on all koji builds
actually *caught* this issue.  I can see that in the taskotron logs from
2016-08-12 at:
https://taskotron.fedoraproject.org/resultsdb/results?page=25_name=dist.abicheck.

It says for libjasper that are changes that need inspection:

8650382 | 2016-08-12 | 06:32:26.472247 | dist.abicheck | NEEDS_INSPECTION | 
Time taken: 4.26 second(s) | jasper-1.900.1-33.fc23

When I look in the logs themselves at
https://taskotron.fedoraproject.org/artifacts/all/532e5e32-6055-11e6-b56f-525400120b80/task_output/jasper-1.900.1-33.fc24.log,
I can see this lines in particular:

* ABI changes found between jasper-libs-1.900.1-32.fc24.x86_64.rpm and
jasper-libs-1.900.1-33.fc24.x86_64.rpm. ABI comparison took 1.10
second(s). Please review them.

[...]

[C]'function char* jas_stream_gets(jas_stream_t*, char*, int)' at
jas_stream.c:573:1 has some indirect sub-type changes:
  parameter 3 of type 'int' changed:
entity changed from 'int' to compatible type 'typedef size_t' at 
stddef.h:216:1

At the moment, the ABI changes that are reported do not trigger the
blocking of the build, so we need collaboration from critpath package
maintainers.  Whenever Taskotron says "please review this ABI change",
the review is needed.

I hope this helps.

Cheers,

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

2016-09-15 Thread Sinny Kumari
On Thu, Sep 15, 2016 at 4:20 PM, Josh Boyer  wrote:
> On Thu, Sep 15, 2016 at 3:42 AM, Dan Horák  wrote:
>> On Wed, 14 Sep 2016 20:50:49 +0100
>> Richard Hughes  wrote:
>>
>>> 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.
>>
>> one more case for enabling libabigail tests in bodhi ...
>
> I agree.  This would have been caught by libabigail/abicheck as far as I know.

Yes, see my previous comment for more detail.

> Does anyone know what the blockers are for enabling it in production?

Right now abichecks already run in production on set of packages which are
listed in critpath[1] and can be viewed [2] or subscribed[3] to. For initial
phase, it has been kept as informational and no packages get blocked if
incompatible ABI changes found. There is already ticket [4] for
enabling abicheck
on all c/c++ package updates which I believe will be worked on soon.

[1] https://admin.fedoraproject.org/pkgdb/api/critpath
[2] 
https://taskotron.fedoraproject.org/resultsdb/results?testcase_name=dist.abicheck
[3] https://apps.fedoraproject.org/notifications/
[4] https://phab.qadevel.cloud.fedoraproject.org/T823
--
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

2016-09-15 Thread Sinny Kumari
On Thu, Sep 15, 2016 at 1:12 PM, Dan Horák  wrote:
> On Wed, 14 Sep 2016 20:50:49 +0100
> Richard Hughes  wrote:
>
>> 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.
>
> one more case for enabling libabigail tests in bodhi ...

Indeed, I can clearly see that there are incompatible ABI changes [1]
with this update
on running libabigail tool. Right now, abichecks run [2] only on
sub-set of packages
but testers and developers can use libabigail tools [3] locally to see
possible ABI changes
which may occur with the package update. After reviewing ABI changes, action can
be taken accordingly.


[1] https://paste.fedoraproject.org/428310/
[2] 
https://taskotron.fedoraproject.org/resultsdb/results?testcase_name=dist.abicheck
[3] https://sourceware.org/libabigail/manual/libabigail-tools.html#tools-manuals
--
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

2016-09-15 Thread Matthew Miller
On Wed, Sep 14, 2016 at 06:32:16PM -0500, Michael Catanzaro 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.

Huh. Does Steam use JPEG2000 for its screenshot or icons or
something?


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

2016-09-15 Thread Josh Boyer
On Thu, Sep 15, 2016 at 3:42 AM, Dan Horák  wrote:
> On Wed, 14 Sep 2016 20:50:49 +0100
> Richard Hughes  wrote:
>
>> 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.
>
> one more case for enabling libabigail tests in bodhi ...

I agree.  This would have been caught by libabigail/abicheck as far as I know.

Does anyone know what the blockers are for enabling it in production?

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

2016-09-15 Thread Richard Hughes
On 15 September 2016 at 00:32, Michael Catanzaro  wrote:
> Richard said on IRC it only crashes if you also have steam installed.

Agree; when you have steam installed the gnome-software steam plugin
is auto-enabled which tries to download icons for steam apps when
idle. It just so happens some of the steam apps use JPEG-2000 encoding
inside the ICNS wrapper. For instance, try this:

$ wget 
https://steamcdn-a.akamaihd.net/steamcommunity/public/images/apps/219/18380bfdc004844c918de769de298bac5c21ca33.icns
$ eog 18380bfdc004844c918de769de298bac5c21ca33.icns
eog: jas_stream.c:1044: mem_write: Assertion `ret == cnt' failed.
Aborted (core dumped)

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

2016-09-15 Thread Dan Horák
On Wed, 14 Sep 2016 20:50:49 +0100
Richard Hughes  wrote:

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

one more case for enabling libabigail tests in bodhi ...


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

2016-09-15 Thread Debarshi Ray
On Wed, Sep 14, 2016 at 02:53:54PM -0700, Thomas Daede wrote:
> 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.

That's right. Bugs exist to port gdk-pixbuf and gegl to OpenJPEG, but,
sadly, progress is slow:
 * https://bugzilla.gnome.org/show_bug.cgi?id=739392
 * https://bugzilla.gnome.org/show_bug.cgi?id=764746

pgpKL5YnQJoO3.pgp
Description: PGP signature
--
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

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


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

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

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

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

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


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

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

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

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

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

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

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


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

> 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