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

[Richard Hughes]

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

In the update the function jas_stream_memopen has been changed:

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

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

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

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

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

Richard

[Neal Gompa]

On Wed, Sep 14, 2016 at 3:50 PM, Richard Hughes <hughsient(a)gmail.com&gt; 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!

[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

[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

[Richard Hughes]

On 14 September 2016 at 21:11, Michael Catanzaro <mcatanzaro(a)gnome.org&gt; 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

[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
<mattdm(a)fedoraproject.org&gt;
Fedora Project Leader

[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
<mattdm(a)fedoraproject.org&gt;
Fedora Project Leader

[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

[Bill Nottingham]

Matthew Miller (mattdm(a)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

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

[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
> <hughsient(a)gmail.com&gt; 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

[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/de...)


>  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
<mattdm(a)fedoraproject.org&gt;
Fedora Project Leader

[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" <mattdm(a)fedoraproject.org&gt;
> To: "Development discussions related to Fedora"
<devel(a)lists.fedoraproject.org&gt;
> 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/de...)
> 
> 
> > 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
> <mattdm(a)fedoraproject.org&gt;
> Fedora Project Leader
> --
> devel mailing list
> devel(a)lists.fedoraproject.org
> https://lists.fedoraproject.org/admin/lists/[e-mail]
>

[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

[Ben Rosser]

On Wed, Sep 14, 2016 at 4:11 PM, Michael Catanzaro <mcatanzaro(a)gnome.org&gt;
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

[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

[Dan Horák]

On Wed, 14 Sep 2016 20:50:49 +0100
Richard Hughes <hughsient(a)gmail.com&gt; 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

[Richard Hughes]

On 15 September 2016 at 00:32, Michael Catanzaro <mcatanzaro(a)gnome.org&gt; 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/183...
$ eog 18380bfdc004844c918de769de298bac5c21ca33.icns
eog: jas_stream.c:1044: mem_write: Assertion `ret == cnt' failed.
Aborted (core dumped)

Richard.

[Josh Boyer]

On Thu, Sep 15, 2016 at 3:42 AM, Dan Horák <dan(a)danny.cz&gt; wrote:
>  On Wed, 14 Sep 2016 20:50:49 +0100
>  Richard Hughes <hughsient(a)gmail.com&gt; 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

[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
<mattdm(a)fedoraproject.org&gt;
Fedora Project Leader

[Sinny Kumari]

On Thu, Sep 15, 2016 at 1:12 PM, Dan Horák <dan(a)danny.cz&gt; wrote:
>  On Wed, 14 Sep 2016 20:50:49 +0100
>  Richard Hughes <hughsient(a)gmail.com&gt; 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....
[3] https://sourceware.org/libabigail/manual/libabigail-tools.html#tools-manuals

[Sinny Kumari]

On Thu, Sep 15, 2016 at 4:20 PM, Josh Boyer <jwboyer(a)fedoraproject.org&gt; wrote:
>  On Thu, Sep 15, 2016 at 3:42 AM, Dan Horák <dan(a)danny.cz&gt;
> wrote:
> > On Wed, 14 Sep 2016 20:50:49 +0100
> > Richard Hughes <hughsient(a)gmail.com&gt; 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....
[3] https://apps.fedoraproject.org/notifications/
[4] https://phab.qadevel.cloud.fedoraproject.org/T823

[Dodji Seketeli]

Hello,

Dan Horák <dan(a)danny.cz&gt; 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&testcas....

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

[Richard Hughes]

On 15 September 2016 at 12:08, Matthew Miller <mattdm(a)fedoraproject.org&gt; wrote:
>  Huh. Does Steam use JPEG2000 for its screenshot or icons or
>  something? 
Some of the ICNS icons have embedded JPEG-2000 images.

Richard.

[Josh Boyer]

On Thu, Sep 15, 2016 at 8:38 AM, Dodji Seketeli <dodji(a)seketeli.org&gt; wrote:
>  Hello,
>
>  Dan Horák <dan(a)danny.cz&gt; 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&testcas....
>
>  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...,
>  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

[Dodji Seketeli]

Josh Boyer <jwboyer(a)fedoraproject.org&gt; 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...

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

[Dodji Seketeli]

Josh Boyer <jwboyer(a)fedoraproject.org&gt; 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

[Josh Boyer]

On Thu, Sep 15, 2016 at 9:10 AM, Dodji Seketeli <dodji(a)seketeli.org&gt; wrote:
>  Josh Boyer <jwboyer(a)fedoraproject.org&gt; 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

[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
<mattdm(a)fedoraproject.org&gt;
Fedora Project Leader

[Dodji Seketeli]

Matthew Miller <mattdm(a)fedoraproject.org&gt; 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/[e-mail].o...


Cheers,

-- 
		Dodji

[Dodji Seketeli]

Josh Boyer <jwboyer(a)fedoraproject.org&gt; 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

[Dodji Seketeli]

Dodji Seketeli <dodji(a)seketeli.org&gt; 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

[Adam Williamson]

On Thu, 2016-09-15 at 15:10 +0200, Dodji Seketeli wrote:
>  Josh Boyer <jwboyer(a)fedoraproject.org&gt; 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

[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
<mattdm(a)fedoraproject.org&gt;
Fedora Project Leader

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

[Dodji Seketeli]

Adam Williamson <adamwill(a)fedoraproject.org&gt; 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

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

[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

[Kevin Fenzi]

On Fri, 16 Sep 2016 10:54:57 -0500
Michael Catanzaro <mcatanzaro(a)gnome.org&gt; 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/93bbe73e514b86c59...

Other suggestions to make it easier welcome. 

kevin

[Jonathan Wakely]

On 16/09/16 12:55 -0600, Kevin Fenzi wrote:
> On Fri, 16 Sep 2016 10:54:57 -0500
> Michael Catanzaro <mcatanzaro(a)gnome.org&gt; 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/93bbe73e514b86c59...
>
> Other suggestions to make it easier welcome. 
Fixing the 404 for the taskotron docs would help :-)

[Kevin Fenzi]

On Sat, 17 Sep 2016 15:30:34 +0100
Jonathan Wakely <jwakely(a)fedoraproject.org&gt; wrote:

>  On 16/09/16 12:55 -0600, Kevin Fenzi wrote:
>  >On Fri, 16 Sep 2016 10:54:57 -0500
>  >Michael Catanzaro <mcatanzaro(a)gnome.org&gt; 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

[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

[Jonathan Wakely]

On 17/09/16 08:46 -0600, Kevin Fenzi wrote:
> On Sat, 17 Sep 2016 15:30:34 +0100
> Jonathan Wakely <jwakely(a)fedoraproject.org&gt; wrote:
>
> > On 16/09/16 12:55 -0600, Kevin Fenzi wrote:
> > >On Fri, 16 Sep 2016 10:54:57 -0500
> > >Michael Catanzaro <mcatanzaro(a)gnome.org&gt; 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/[e-mail].o...

The "Particular taskotron task outcome" rule has a link to "the
libtaskotron documentation" which links to
https://docs.qadevel.cloud.fedoraproject.org/libtaskotron/latest/resultya...
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/res...

[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 <jwakely(a)fedoraproject.org&gt; wrote:
> >
> >>On 16/09/16 12:55 -0600, Kevin Fenzi wrote:
> >>>On Fri, 16 Sep 2016 10:54:57 -0500
> >>>Michael Catanzaro <mcatanzaro(a)gnome.org&gt; 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/[e-mail].o...
>
> The "Particular taskotron task outcome" rule has a link to "the
> libtaskotron documentation" which links to
> https://docs.qadevel.cloud.fedoraproject.org/libtaskotron/latest/resultya...
> 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/res...
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.

[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 <jwakely(a)fedoraproject.org&gt; wrote:
>  > > 
>  > > > On 16/09/16 12:55 -0600, Kevin Fenzi wrote:
>  > > > > On Fri, 16 Sep 2016 10:54:57 -0500
>  > > > > Michael Catanzaro <mcatanzaro(a)gnome.org&gt; 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/93bbe73e514b86c59...
>  > > > > 
>  > > > > 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/[e-mail].o...
>  > 
>  > The "Particular taskotron task outcome" rule has a link to "the
>  > libtaskotron documentation" which links to
>  >
> https://docs.qadevel.cloud.fedoraproject.org/libtaskotron/latest/resultya...
>  > 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/res...
>  
>  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

[Richard Hughes]

On 14 September 2016 at 20:50, Richard Hughes <hughsient(a)gmail.com&gt; 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.

[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

[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
<mattdm(a)fedoraproject.org&gt;
Fedora Project Leader