Hello all,
I've just created https://fedoraproject.org/wiki/Features/libjpeg-turbo-jpeg8-ABI page which contains plan how to successfully move from current jpeg6 API/ABI to more recent jpeg8 API/ABI for Fedora 19.
All packages which depends on libjpeg.so will have to be rebuilt. Since I have provenpackager privileges, I will cook some script which will rebuild all pkgs automatically so no action will be required from maintainers.
If there are no objections against this approach, I will start with this task next week.
Regards, Adam
Adam Tkac (atkac@redhat.com) said:
I've just created https://fedoraproject.org/wiki/Features/libjpeg-turbo-jpeg8-ABI page which contains plan how to successfully move from current jpeg6 API/ABI to more recent jpeg8 API/ABI for Fedora 19.
All packages which depends on libjpeg.so will have to be rebuilt. Since I have provenpackager privileges, I will cook some script which will rebuild all pkgs automatically so no action will be required from maintainers.
If there are no objections against this approach, I will start with this task next week.
Ouch. I can see a need for a compat library for some period of time here - the jpeg6 API has certainly been around for quite a long while.
Bill
On Thu, Oct 18, 2012 at 10:35:56AM -0400, Bill Nottingham wrote:
Adam Tkac (atkac@redhat.com) said:
I've just created https://fedoraproject.org/wiki/Features/libjpeg-turbo-jpeg8-ABI page which contains plan how to successfully move from current jpeg6 API/ABI to more recent jpeg8 API/ABI for Fedora 19.
All packages which depends on libjpeg.so will have to be rebuilt. Since I have provenpackager privileges, I will cook some script which will rebuild all pkgs automatically so no action will be required from maintainers.
If there are no objections against this approach, I will start with this task next week.
Ouch. I can see a need for a compat library for some period of time here - the jpeg6 API has certainly been around for quite a long while.
Hm, you are probably right. Since libjpeg is widely used, there might be some proprietary apps which require it.
In my opinion we can just ship compat libjpeg.so.* without development files for some time. Or do we need devel files as well?
Regards, Adam
Adam Tkac (atkac@redhat.com) said:
On Thu, Oct 18, 2012 at 10:35:56AM -0400, Bill Nottingham wrote:
Adam Tkac (atkac@redhat.com) said:
I've just created https://fedoraproject.org/wiki/Features/libjpeg-turbo-jpeg8-ABI page which contains plan how to successfully move from current jpeg6 API/ABI to more recent jpeg8 API/ABI for Fedora 19.
All packages which depends on libjpeg.so will have to be rebuilt. Since I have provenpackager privileges, I will cook some script which will rebuild all pkgs automatically so no action will be required from maintainers.
If there are no objections against this approach, I will start with this task next week.
Ouch. I can see a need for a compat library for some period of time here - the jpeg6 API has certainly been around for quite a long while.
Hm, you are probably right. Since libjpeg is widely used, there might be some proprietary apps which require it.
In my opinion we can just ship compat libjpeg.so.* without development files for some time. Or do we need devel files as well?
Just the .so should be fine.
Bill
On Thu, 2012-10-18 at 16:43 +0200, Adam Tkac wrote:
On Thu, Oct 18, 2012 at 10:35:56AM -0400, Bill Nottingham wrote:
Adam Tkac (atkac@redhat.com) said:
I've just created https://fedoraproject.org/wiki/Features/libjpeg-turbo-jpeg8-ABI page which contains plan how to successfully move from current jpeg6 API/ABI to more recent jpeg8 API/ABI for Fedora 19.
All packages which depends on libjpeg.so will have to be rebuilt. Since I have provenpackager privileges, I will cook some script which will rebuild all pkgs automatically so no action will be required from maintainers.
If there are no objections against this approach, I will start with this task next week.
Ouch. I can see a need for a compat library for some period of time here - the jpeg6 API has certainly been around for quite a long while.
Hm, you are probably right. Since libjpeg is widely used, there might be some proprietary apps which require it.
Yeah, I'm with Bill. I note you listed this as the 'contingency plan' for the feature:
Contingency Plan
Create libjpeg-turbo-compat and libjpeg-turbo-compat-devel libraries with jpeg6 API/ABI and ship them in distro.
I'd suggest you should just make it a plan from the start to have the -compat library available as part of the feature (so, really, just drop step 4 of 'scope'), and have the 'contingency plan' be 'abandon ship and go back to building with the jpeg6 API'.
On 19 Oct 2012 00:51, "Adam Williamson" awilliam@redhat.com wrote:
On Thu, 2012-10-18 at 16:43 +0200, Adam Tkac wrote:
On Thu, Oct 18, 2012 at 10:35:56AM -0400, Bill Nottingham wrote:
Adam Tkac (atkac@redhat.com) said:
I've just created https://fedoraproject.org/wiki/Features/libjpeg-turbo-jpeg8-ABIpage which contains plan how to successfully move from current jpeg6 API/ABI
to more recent
jpeg8 API/ABI for Fedora 19.
All packages which depends on libjpeg.so will have to be rebuilt.
Since I have
provenpackager privileges, I will cook some script which will
rebuild all
pkgs automatically so no action will be required from maintainers.
If there are no objections against this approach, I will start with
this task
next week.
Ouch. I can see a need for a compat library for some period of time
here -
the jpeg6 API has certainly been around for quite a long while.
Hm, you are probably right. Since libjpeg is widely used, there might
be some proprietary
apps which require it.
Yeah, I'm with Bill. I note you listed this as the 'contingency plan' for the feature:
Contingency Plan
Create libjpeg-turbo-compat and libjpeg-turbo-compat-devel libraries with jpeg6 API/ABI and ship them in distro.
I'd suggest you should just make it a plan from the start to have the -compat library available as part of the feature (so, really, just drop step 4 of 'scope'), and have the 'contingency plan' be 'abandon ship and go back to building with the jpeg6 API'.
You have to have the compat option to build everything as otherwise the build root breaks from the outset similar to what we saw with the recent libpng update to 1.5.
Peter
On Thu, Oct 18, 2012 at 02:51:01PM -0700, Adam Williamson wrote:
On Thu, 2012-10-18 at 16:43 +0200, Adam Tkac wrote:
On Thu, Oct 18, 2012 at 10:35:56AM -0400, Bill Nottingham wrote:
Adam Tkac (atkac@redhat.com) said:
I've just created https://fedoraproject.org/wiki/Features/libjpeg-turbo-jpeg8-ABI page which contains plan how to successfully move from current jpeg6 API/ABI to more recent jpeg8 API/ABI for Fedora 19.
All packages which depends on libjpeg.so will have to be rebuilt. Since I have provenpackager privileges, I will cook some script which will rebuild all pkgs automatically so no action will be required from maintainers.
If there are no objections against this approach, I will start with this task next week.
Ouch. I can see a need for a compat library for some period of time here - the jpeg6 API has certainly been around for quite a long while.
Hm, you are probably right. Since libjpeg is widely used, there might be some proprietary apps which require it.
Yeah, I'm with Bill. I note you listed this as the 'contingency plan' for the feature:
Contingency Plan
Create libjpeg-turbo-compat and libjpeg-turbo-compat-devel libraries with jpeg6 API/ABI and ship them in distro.
I'd suggest you should just make it a plan from the start to have the -compat library available as part of the feature (so, really, just drop step 4 of 'scope'), and have the 'contingency plan' be 'abandon ship and go back to building with the jpeg6 API'.
I agree with this plan and modified the feature page appropriately.
Regards, Adam
On Thu, Oct 18, 2012 at 9:13 AM, Adam Tkac atkac@redhat.com wrote:
All packages which depends on libjpeg.so will have to be rebuilt. Since I have provenpackager privileges, I will cook some script which will rebuild all pkgs automatically so no action will be required from maintainers.
Currently, new Rawhide builds of programs that use both libjpeg and libtiff/ImageMagick/gdk-pixbuf/etc. will load jpeg8 (direct dependency) *and* jpeg62 (indirect). This is somewhat sub-optimal. When do you expect to start the mass rebuild?
Thanks, --Benjamin Gilbert
On 10/18/2012 07:13 AM, Adam Tkac wrote:
Hello all,
I've just created https://fedoraproject.org/wiki/Features/libjpeg-turbo-jpeg8-ABI page which contains plan how to successfully move from current jpeg6 API/ABI to more recent jpeg8 API/ABI for Fedora 19.
All packages which depends on libjpeg.so will have to be rebuilt. Since I have provenpackager privileges, I will cook some script which will rebuild all pkgs automatically so no action will be required from maintainers.
If there are no objections against this approach, I will start with this task next week.
Regards, Adam
BR of libjpeg-devel now pulls in libjpeg-turbo-compat-devel, but this doesn't really work as a drop in replacement because those headers are in /usr/include/libjpeg-turbo-compat/. Shouldn't libjpeb-turbo-devel provide libjpeg-devel and not libjpeg-turbo-compat-devel?
On Thu, Dec 13, 2012 at 2:08 PM, Orion Poplawski orion@cora.nwra.com wrote:
BR of libjpeg-devel now pulls in libjpeg-turbo-compat-devel, but this doesn't really work as a drop in replacement because those headers are in /usr/include/libjpeg-turbo-compat/. Shouldn't libjpeb-turbo-devel provide libjpeg-devel and not libjpeg-turbo-compat-devel?
For xbmc I ended up switching the BR to libjpeg-turbo-devel. This works on all supported Fedora releases, and I conditionalized it with a disttag for EPEL.
- Ken
Orion Poplawski orion@cora.nwra.com writes:
BR of libjpeg-devel now pulls in libjpeg-turbo-compat-devel, but this doesn't really work as a drop in replacement because those headers are in /usr/include/libjpeg-turbo-compat/.
Yeah, I just whinged about that at bz #887013.
Shouldn't libjpeb-turbo-devel provide libjpeg-devel and not libjpeg-turbo-compat-devel?
Only if jpeg8 is a drop-in (source code compatible) replacement. Otherwise you're only moving the point at which failures will occur.
regards, tom lane
devel@lists.stg.fedoraproject.org
-
Adam Tkac -
Adam Williamson -
Benjamin Gilbert -
Bill Nottingham -
Ken Dreyer -
Orion Poplawski -
Peter Robinson -
Tom Lane