Bug#612341: bumblebee, libjpeg-turbo: Wheezy does not work well with modern notebook PCs.
Hi all, On Sa 02 Jun 2012 20:53:10 CEST Osamu Aoki wrote: We would have to import latest upstream on top of that Well, unless we all agree to reset git repo, this is impossible to do. I like to do it +1 from me. However, as Fathi is ITP holder, he may have the last word. I know. But it is easy to have another repo with everything :-) Alioth can host it: http://anonscm.debian.org/gitweb/?p=users/osamu/libjpeg-turbo.git just for the record... I have adopted my and osamu's approach of libjpeg-turbo.git to http://anonscm.debian.org/gitweb/?p=collab-maint/libjpeg-turbo.git Mike -- DAS-NETZWERKTEAM mike gabriel, rothenstein 5, 24214 neudorf-bornstein fon: +49 (1520) 1976 148 GnuPG Key ID 0xB588399B mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb pgp7ZRCO5Trwm.pgp Description: Digitale PGP-Unterschrift
Bug#612341: bumblebee, libjpeg-turbo: Wheezy does not work well with modern notebook PCs.
Hi Osamu, hi all, On Sa 02 Jun 2012 20:53:10 CEST Osamu Aoki wrote: Hi, On Sat, Jun 02, 2012 at 06:58:51AM +0200, Mike Gabriel wrote: Hi Osamu, Hi, On Thu, May 31, 2012 at 11:50:19PM +0200, Mike Gabriel wrote: ... you may want to have a very little bit more history... (and a packaging folder) http://code.x2go.org/gitweb?p=libjpeg-turbo.git;a=summary This is one of them. Ubuntu package history is another one. Sure. We would have to import latest upstream on top of that Well, unless we all agree to reset git repo, this is impossible to do. I like to do it +1 from me. However, as Fathi is ITP holder, he may have the last word. I know. But it is easy to have another repo with everything :-) Alioth can host it: http://anonscm.debian.org/gitweb/?p=users/osamu/libjpeg-turbo.git I see you had some revert implimented. Some package splits are a bit different. You get better picture from gitk screen. Looks good to me. I have cloned a working copy where I can write to on my own git server (and already did some work): http://code.das-netzwerkteam.de/gitweb?p=debian/libjpeg-turbo.git;a=summary @Fathi: will the above named vcs on code.x2go.org work for you as starting point? Osamu could clone that on collab-maint. Are you ok with co- aintenance? Shall we create a team-context for maintenance? One possibility could be that we place the development of the LJT package under the roof of the pkx-x2go-devel@a.l.d.o packaging team(easy for me :-) ). Any other context is fine as well. I an with you. Fathi? There also is a pkg-tigervnc project on Alioth, that would be an even better context, I guess. So we need to make the assignment of works who does what. Once Fathi gave his go, I will be happy to extract the diversion stuff from the library stuff. I can help general simple packaging based on Ubuntu work but I can not be competent on complicated library packaging with ABI compatibility etc. I guess the QA has to be done by Fathi, Doko or someone with similar experience. However, we can give them our work and together the package may evolve. Yes. As I read the source, I can see why Independent JPEG Group is bitter. Modified file by non-IJG people are identifies as if they were done by IJG people. I am sure it is upsetting when code is broken from IJG people's view. I think no malice but just sloppiness ... Not getting what you mean exactly here. Can anything be done about it? Anything that we can do? Mike -- DAS-NETZWERKTEAM mike gabriel, rothenstein 5, 24214 neudorf-bornstein fon: +49 (1520) 1976 148 GnuPG Key ID 0xB588399B mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb pgpRvALzHn6su.pgp Description: Digitale PGP-Unterschrift
Bug#612341: bumblebee, libjpeg-turbo: Wheezy does not work well with modern notebook PCs.
On Sun, Jun 03, 2012 at 10:51:13AM +0200, Mike Gabriel wrote: Hi Osamu, hi all, On Sa 02 Jun 2012 20:53:10 CEST Osamu Aoki wrote: Hi, On Sat, Jun 02, 2012 at 06:58:51AM +0200, Mike Gabriel wrote: Hi Osamu, Hi, On Thu, May 31, 2012 at 11:50:19PM +0200, Mike Gabriel wrote: ... you may want to have a very little bit more history... (and a packaging folder) http://code.x2go.org/gitweb?p=libjpeg-turbo.git;a=summary This is one of them. Ubuntu package history is another one. Sure. We would have to import latest upstream on top of that Well, unless we all agree to reset git repo, this is impossible to do. I like to do it +1 from me. However, as Fathi is ITP holder, he may have the last word. I know. But it is easy to have another repo with everything :-) Alioth can host it: http://anonscm.debian.org/gitweb/?p=users/osamu/libjpeg-turbo.git I see you had some revert implimented. Some package splits are a bit different. You get better picture from gitk screen. Looks good to me. I have cloned a working copy where I can write to on my own git server (and already did some work): http://code.das-netzwerkteam.de/gitweb?p=debian/libjpeg-turbo.git;a=summary @Fathi: will the above named vcs on code.x2go.org work for you as starting point? Osamu could clone that on collab-maint. Are you ok with co- aintenance? Shall we create a team-context for maintenance? One possibility could be that we place the development of the LJT package under the roof of the pkx-x2go-devel@a.l.d.o packaging team(easy for me :-) ). Any other context is fine as well. I an with you. Fathi? There also is a pkg-tigervnc project on Alioth, that would be an even better context, I guess. So we need to make the assignment of works who does what. Once Fathi gave his go, I will be happy to extract the diversion stuff from the library stuff. I can help general simple packaging based on Ubuntu work but I can not be competent on complicated library packaging with ABI compatibility etc. I guess the QA has to be done by Fathi, Doko or someone with similar experience. However, we can give them our work and together the package may evolve. Yes. As I read the source, I can see why Independent JPEG Group is bitter. Modified file by non-IJG people are identifies as if they were done by IJG people. I am sure it is upsetting when code is broken from IJG people's view. I think no malice but just sloppiness ... Not getting what you mean exactly here. Can anything be done about it? Anything that we can do? I assume that Osamu refer to this line of the IJG license: (1) If any part of the source code for this software is distributed, then this README file must be included, with this copyright and no-warranty notice unaltered; and any additions, deletions, or changes to the original files must be clearly indicated in accompanying documentation. For example, when I released libjpeg 6b1, I added a file README.6b1 with the complete list of modified files (in attachment). (I am not especially fond of this requirement, but it is not really onerous). Cheers, -- Bill. ballo...@debian.org Imagine a large red swirl here. Extra README for release 6b1 of 1-Jun-2010 == This release is identical to release 6b with the exception of the build system, and of library symbols versioning on platforms that support them. This release is only intended as a transition help toward the upgrade to libjpeg8. If you can upgrade directly to libjpeg8, you do not need libjpeg6b1. This release was prepared by Bill Allombert ballo...@debian.org from release 6b and the build system of release 8 by Guido Vollbeding and Bob Friesenhahn. Files changed: config.guess (updated from automake) config.sub (updated from automake) configure(autogenerated) ltmain.sh(updated from libtool) Files added: aclocal.m4 (from libjpeg8) configure.ac (from libjpeg8) depcomp (from automake) libjpeg.map (from libjpeg8, modified) Makefile.am (from libjpeg8, modified) Makefile.in (autogenerated) missing (from automake) README.6b1 (this file) File removed: ltconfig (obsoleted)
Bug#612341: bumblebee, libjpeg-turbo: Wheezy does not work well with modern notebook PCs.
Hi, On Sat, Jun 02, 2012 at 06:58:51AM +0200, Mike Gabriel wrote: Hi Osamu, Hi, On Thu, May 31, 2012 at 11:50:19PM +0200, Mike Gabriel wrote: ... you may want to have a very little bit more history... (and a packaging folder) http://code.x2go.org/gitweb?p=libjpeg-turbo.git;a=summary This is one of them. Ubuntu package history is another one. Sure. We would have to import latest upstream on top of that Well, unless we all agree to reset git repo, this is impossible to do. I like to do it +1 from me. However, as Fathi is ITP holder, he may have the last word. I know. But it is easy to have another repo with everything :-) Alioth can host it: http://anonscm.debian.org/gitweb/?p=users/osamu/libjpeg-turbo.git I see you had some revert implimented. Some package splits are a bit different. You get better picture from gitk screen. @Fathi: will the above named vcs on code.x2go.org work for you as starting point? Osamu could clone that on collab-maint. Are you ok with co- aintenance? Shall we create a team-context for maintenance? One possibility could be that we place the development of the LJT package under the roof of the pkx-x2go-devel@a.l.d.o packaging team(easy for me :-) ). Any other context is fine as well. I an with you. So we need to make the assignment of works who does what. Once Fathi gave his go, I will be happy to extract the diversion stuff from the library stuff. I can help general simple packaging based on Ubuntu work but I can not be competent on complicated library packaging with ABI compatibility etc. I guess the QA has to be done by Fathi, Doko or someone with similar experience. However, we can give them our work and together the package may evolve. Yes. As I read the source, I can see why Independent JPEG Group is bitter. Modified file by non-IJG people are identifies as if they were done by IJG people. I am sure it is upsetting when code is broken from IJG people's view. I think no malice but just sloppiness ... Osamu -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#612341: bumblebee, libjpeg-turbo: Wheezy does not work well with modern notebook PCs.
Hi, On Thu, May 31, 2012 at 11:50:19PM +0200, Mike Gabriel wrote: ... you may want to have a very little bit more history... (and a packaging folder) http://code.x2go.org/gitweb?p=libjpeg-turbo.git;a=summary This is one of them. Ubuntu package history is another one. We would have to import latest upstream on top of that Well, unless we all agree to reset git repo, this is impossible to do. I like to do it but the packaging works fine for libjpeg8 emulation mode. Sure, what I commited is something like this plus new upstream. It should work fine for libjpeg8 emulation mode. However, I really think that we should put the dpkg-divert stuff into an extra bin:package (in the same libjpeg-turbo src:package, of course). I agree. So we need to make the assignment of works who does what. I can help general simple packaging based on Ubuntu work but I can not be competent on complicated library packaging with ABI compatibility etc. Osamu -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#612341: bumblebee, libjpeg-turbo: Wheezy does not work well with modern notebook PCs.
On Fri, Jun 01, 2012 at 11:57:54PM +0900, Osamu Aoki wrote: Hi, On Thu, May 31, 2012 at 11:50:19PM +0200, Mike Gabriel wrote: ... you may want to have a very little bit more history... (and a packaging folder) http://code.x2go.org/gitweb?p=libjpeg-turbo.git;a=summary This is one of them. Ubuntu package history is another one. We would have to import latest upstream on top of that Well, unless we all agree to reset git repo, this is impossible to do. I like to do it but the packaging works fine for libjpeg8 emulation mode. Sure, what I commited is something like this plus new upstream. It should work fine for libjpeg8 emulation mode. However, I really think that we should put the dpkg-divert stuff into an extra bin:package (in the same libjpeg-turbo src:package, of course). It is not reasonnable for libjpeg-turbo to dpkg-divert libjpeg8, since it does not provide the same features set and break libjpeg-progs at least. (there is a lot of features that are missing in libjpeg-turbo and some file created by libjpeg8 cannot be rendered correctly by libjpeg-turbo). Instead the set of application that need libjpeg-turbo could use LD_LIBRARY_PATH etc. (put libjpeg-turbo in /usr/lib/libjpeg-turbo/libjpeg8 and do LD_LIBRARY_PATH=/usr/lib/libjpeg-turbo/libjpeg8:$LD_LIBRARY_PATH in a wrapper script) Cheers, -- Bill. ballo...@debian.org Imagine a large red swirl here. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#612341: bumblebee, libjpeg-turbo: Wheezy does not work well with modern notebook PCs.
Hi all, On Fri, Jun 01, 2012 at 11:57:54PM +0900, Osamu Aoki wrote: Hi, On Thu, May 31, 2012 at 11:50:19PM +0200, Mike Gabriel wrote: ... you may want to have a very little bit more history... (and a packaging folder) http://code.x2go.org/gitweb?p=libjpeg-turbo.git;a=summary This is one of them. Ubuntu package history is another one. We would have to import latest upstream on top of that Well, unless we all agree to reset git repo, this is impossible to do. I like to do it but the packaging works fine for libjpeg8 emulation mode. Sure, what I commited is something like this plus new upstream. It should work fine for libjpeg8 emulation mode. However, I really think that we should put the dpkg-divert stuff into an extra bin:package (in the same libjpeg-turbo src:package, of course). It is not reasonnable for libjpeg-turbo to dpkg-divert libjpeg8, since it does not provide the same features set and break libjpeg-progs at least. (there is a lot of features that are missing in libjpeg-turbo and some file created by libjpeg8 cannot be rendered correctly by libjpeg-turbo). As said before, I agree with bill that the diversion stuff has to stay out of the base LJT package. However, I would like to give people in wheezy the chance to drop in replace LJ by LJT with installation of an extra package that handles the versions. This package I would not even mention in Suggests:... The drop-in replacement has to be reversible with uninstallation for the diversion package. People have to remove the diversions without removing LJT. Our (and LJT upstream's) gain then is that we have a package/forum in BTS where all the incompatibility reports can be assigned to. This is usefull for further discussions. If people urge on replacing LJ by LJT somepost-wheezy-time later, then we can say: hey, take a look at all those bugs filed against the LJT diversion package... Or maybe there won't be many bugs being reported. Who knows. Instead the set of application that need libjpeg-turbo could use LD_LIBRARY_PATH etc. (put libjpeg-turbo in /usr/lib/libjpeg-turbo/libjpeg8 and do LD_LIBRARY_PATH=/usr/lib/libjpeg-turbo/libjpeg8:$LD_LIBRARY_PATH in a wrapper script) As the native LJT library names do not interfere with Libjpeg8 lib so names, the LD_LIB_NAME thing is not even necessary, I think. Only the file/link names in the LJT diversion package will raise the naming interference (which is wanted with that package) Greets Mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#612341: bumblebee, libjpeg-turbo: Wheezy does not work well with modern notebook PCs.
Hi Osamu, Hi, On Thu, May 31, 2012 at 11:50:19PM +0200, Mike Gabriel wrote: ... you may want to have a very little bit more history... (and a packaging folder) http://code.x2go.org/gitweb?p=libjpeg-turbo.git;a=summary This is one of them. Ubuntu package history is another one. Sure. We would have to import latest upstream on top of that Well, unless we all agree to reset git repo, this is impossible to do. I like to do it +1 from me. However, as Fathi is ITP holder, he may have the last word. @Fathi: will the above named vcs on code.x2go.org work for you as starting point? Osamu could clone that on collab-maint. Are you ok with co- aintenance? Shall we create a team-context for maintenance? One possibility could be that we place the development of the LJT package under the roof of the pkx-x2go-devel@a.l.d.o packaging team(easy for me :-) ). Any other context is fine as well. So we need to make the assignment of works who does what. Once Fathi gave his go, I will be happy to extract the diversion stuff from the library stuff. I can help general simple packaging based on Ubuntu work but I can not be competent on complicated library packaging with ABI compatibility etc. I guess the QA has to be done by Fathi, Doko or someone with similar experience. However, we can give them our work and together the package may evolve. Greets, Mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#612341: bumblebee, libjpeg-turbo: Wheezy does not work well with modern notebook PCs.
Hi, On Tue, May 29, 2012 at 07:36:12PM +0300, Fathi Boudra wrote: On Sat, May 26, 2012 at 9:34 PM, Osamu Aoki os...@debian.org wrote: Also, Mike Gabriel's work seems to have done somethings interesting on old Fathi's version and made many improvements. thanks for pinging us! I agree, libjpeg-turbo has to be in Wheezy!!! Fathi, please send us a notice what you plan on this package. I see Fathi being quite active. Yes, I am. Apologies, I've been quite busy on other front and put LJT as a low prio. AFAIR, current Ubuntu package wasn't suitable to be uploaded as-is. I'm at Linaro Connect this week with Tom Gall and Doko, I'll sync up with them and upload the package if everything alright. Sounds like many people are interested. LJT is a good candidate for collab-maint on git.debian.org :) You only commited upstream tar ... that is not interesting for us to dig into license issue etc. For the moment, I added a buildable content as master=debian branch. [remote origin] fetch = +refs/heads/*:refs/remotes/origin/* url = ssh://git.debian.org/git/collab-maint/libjpeg-turbo (I thought putting history including branching point from libjpeg may be more interesing ... but that can be done later if all agree ...) It is practically Ubuntu package shape as done by Matthias Klose d...@debian.org. I have not included suggestions on this bug by Matthias Klose d...@debian.org. Question is his package is tracking 8c on Ubuntu while the current Debian libjpeg is 8d version. I did not put any thought on it yet. By the way, is there active mailing list? vasks repo had some hook :-) Osamu -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#612341: bumblebee, libjpeg-turbo: Wheezy does not work well with modern notebook PCs.
Hi, On Do 31 Mai 2012 15:55:28 CEST Osamu Aoki wrote: Hi, On Tue, May 29, 2012 at 07:36:12PM +0300, Fathi Boudra wrote: On Sat, May 26, 2012 at 9:34 PM, Osamu Aoki os...@debian.org wrote: Also, Mike Gabriel's work seems to have done somethings interesting on old Fathi's version and made many improvements. thanks for pinging us! I agree, libjpeg-turbo has to be in Wheezy!!! Fathi, please send us a notice what you plan on this package. I see Fathi being quite active. Yes, I am. Apologies, I've been quite busy on other front and put LJT as a low prio. AFAIR, current Ubuntu package wasn't suitable to be uploaded as-is. I'm at Linaro Connect this week with Tom Gall and Doko, I'll sync up with them and upload the package if everything alright. Sounds like many people are interested. LJT is a good candidate for collab-maint on git.debian.org :) You only commited upstream tar ... that is not interesting for us to dig into license issue etc. For the moment, I added a buildable content as master=debian branch. [remote origin] fetch = +refs/heads/*:refs/remotes/origin/* url = ssh://git.debian.org/git/collab-maint/libjpeg-turbo (I thought putting history including branching point from libjpeg may be more interesing ... but that can be done later if all agree ...) you may want to have a very little bit more history... (and a packaging folder) http://code.x2go.org/gitweb?p=libjpeg-turbo.git;a=summary We would have to import latest upstream on top of that but the packaging works fine for libjpeg8 emulation mode. However, I really think that we should put the dpkg-divert stuff into an extra bin:package (in the same libjpeg-turbo src:package, of course). Mike -- DAS-NETZWERKTEAM mike gabriel, rothenstein 5, 24214 neudorf-bornstein fon: +49 (1520) 1976 148 GnuPG Key ID 0xB588399B mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb pgpBNrrH4S6YI.pgp Description: Digitale PGP-Unterschrift
Bug#612341: bumblebee, libjpeg-turbo: Wheezy does not work well with modern notebook PCs.
Dear Fathi Boudra What they agree or not agree is not relevant, but the facts are relevant! To give you a few real examples: You won't be able to access the following image with your browsers, because they use obsolete and illegal derivations of libjpeg: http://filmicgames.com/Images/Patents/bedroom_arithmetic.jpg from the article The greatest failure of our patent system wasÂ… http://filmicgames.com/archives/778 And here you can see the ignorance of the browser developers: https://bugzilla.mozilla.org/show_bug.cgi?id=680385 You will not be able to access the following images with your browsers, because they use obsolete and illegal derivations of libjpeg: http://jpegclub.org/kodaksuite/ Compare this with http://www.r0k.us/graphics/kodak/ This of course requires the latest development version of libjpeg (v9 as mentioned) which you can find here: http://www.infai.org/jpeg/ And if you are interested in how this works you can read this: http://jpegclub.org/temp/ http://jpegclub.org/temp/JPEG_9_Lossless_Coding.doc Please be aware that there are certain circles which want to PREVENT that any advance in JPEG image coding reaches you. And their means is this obsolete and illegal derivation of libjpeg. They rely on the ignorance of people, and since many people are ignorant, they can actually reach their goal. But notice the famous saying of Abraham Lincoln: You can fool some of the people all of the time, and all of the people some of the time, but you cannot fool all of the people all the time. You apparently belong to that camp which promotes obsolete and illegal derivations of libjpeg. Notice that I have actually no plans to take legal action against the deceivers and their circles (which include such companies like Google, Red Hat, Ubuntu, and others, as can be seen on http://www.libjpeg-turbo.org/About/Software), but the organizations and companies that I am working with may see this different one day. Regards Guido Vollbeding Organizer Independent JPEG Group -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#612341: bumblebee, libjpeg-turbo: Wheezy does not work well with modern notebook PCs.
For information, it looks like not all of libjpeg8 is actually implemented in libjpeg-turbo, ref: http://libjpeg-turbo.svn.sourceforge.net/viewvc/libjpeg-turbo/trunk/README-turbo.txt In particular: libjpeg v7 and v8 Features: --- Fully supported: -- cjpeg: Separate quality settings for luminance and chrominance Note that the libpjeg v7+ API was extended to accommodate this feature only for convenience purposes. It has always been possible to implement this feature with libjpeg v6b (see rdswitch.c for an example.) -- libjpeg: IDCT scaling extensions in decompressor libjpeg-turbo supports IDCT scaling with scaling factors of 1/8, 1/4, 3/8, 1/2, 5/8, 3/4, 7/8, 9/8, 5/4, 11/8, 3/2, 13/8, 7/4, 15/8, and 2/1 (only 1/4 and 1/2 are SIMD-accelerated.) -- cjpeg: 32-bit BMP support -- jpegtran: lossless cropping -- jpegtran: -perfect option -- rdjpgcom: -raw option -- rdjpgcom: locale awareness Fully supported when using libjpeg v7/v8 emulation: -- libjpeg: In-memory source and destination managers Not supported: -- libjpeg: DCT scaling in compressor cinfo.scale_num and cinfo.scale_denom are silently ignored. There is no technical reason why DCT scaling cannot be supported, but without the SmartScale extension (see below), it would only be able to down-scale using ratios of 1/2, 8/15, 4/7, 8/13, 2/3, 8/11, 4/5, and 8/9, which is of limited usefulness. -- libjpeg: SmartScale cinfo.block_size is silently ignored. SmartScale is an extension to the JPEG format that allows for DCT block sizes other than 8x8. It would be difficult to support this feature while retaining backward compatibility with libjpeg v6b. -- libjpeg: Fancy downsampling in compressor cinfo.do_fancy_downsampling is silently ignored. This requires the DCT scaling feature, which is not supported. -- jpegtran: Scaling This requires both the DCT scaling and SmartScale features, which are not supported. -- Lossless RGB JPEG files This requires the SmartScale feature, which is not supported. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#612341: bumblebee, libjpeg-turbo: Wheezy does not work well with modern notebook PCs.
Hi Fathi, On Mi 30 Mai 2012 06:06:07 CEST Fathi Boudra wrote: On Wed, May 30, 2012 at 1:15 AM, Guido Vollbeding gu...@jpegclub.org wrote: Hello Mathieu Thank you for question. libjpeg is reference code, not faulty patchwork. Everything is said in the README: There are currently distributions in circulation containing the name libjpeg which claim to be a derivative or fork of the original libjpeg, but don't have the features and are incompatible with formats supported by actual IJG libjpeg distributions. Furthermore, they violate the license conditions as described under LEGAL ISSUES above. We have no sympathy for the release of misleading and illegal distributions derived from obsolete code bases. Don't use an obsolete code base! I mean, the original README in libjpeg, not that in the patchwork you are talking about, which is one of the license violations. It seems that Bill Allombert is still one of the few sane people out there, many others have apparently gone mad. I don't care for the ignorant people. You may of course make a turbo version, I have nothing against it, but NOT in the way mentioned. Take libjpeg with its current features and make it turbo - that would be wonderful! For reference: http://www.libjpeg-turbo.org/About/FUD As we can see, the other camp doesn't agree. I would like to avoid political/legal/off-topic discussions that doesn't belong to this bug report or LJT ITP. Thanks. I fully agree with Fathi, no political discussion via an Debian ITP in BTS. My suggestion for Debian packaging of libjpeg-turbo is: o split up the package as currently pre-packaged into - libjpeg-turbo - libjpeg-turbo-dev - libjpeg-turbo-libjpeg8-diversion (the name may not be optimal) - libjpeg-turbo-libjpeg8-diversion-dev People who need libjpeg-turbo for other projects (TigerVNC, VirtualGL, etc.) may have it in Debian. People who choose to fully replace libjpeg by libjpeg-turbo in v8 compat mode can install the libjpeg-turbo-libjpeg8-diversion (or similar name). This package replaces libjpeg8 by libjpeg-turbo via dpkg-divert. Without this package installed the two libraries can co-exist and be used either or by other packages. I love choice! And with this approach we let the user choose whether to keep libjpeg8 or drop-in replace it by libjpeg-turbo with v8 compat mode. Debian maintainers of applications that run with libjpeg8, but fail with libjpeg-turbo, may file BTS reports against libjpeg-turbo that we can forward to libjpeg-turbo upstream. How is that? Mike -- DAS-NETZWERKTEAM mike gabriel, rothenstein 5, 24214 neudorf-bornstein fon: +49 (1520) 1976 148 GnuPG Key ID 0xB588399B mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb pgpuIB8ibYBEM.pgp Description: Digitale PGP-Unterschrift
Bug#612341: bumblebee, libjpeg-turbo: Wheezy does not work well with modern notebook PCs.
Hi all, On Wed, May 30, 2012 at 11:09 AM, Mike Gabriel mike.gabr...@das-netzwerkteam.de wrote: Hi Fathi, On Mi 30 Mai 2012 06:06:07 CEST Fathi Boudra wrote: On Wed, May 30, 2012 at 1:15 AM, Guido Vollbeding gu...@jpegclub.org wrote: Hello Mathieu Thank you for question. libjpeg is reference code, not faulty patchwork. Everything is said in the README: There are currently distributions in circulation containing the name libjpeg which claim to be a derivative or fork of the original libjpeg, but don't have the features and are incompatible with formats supported by actual IJG libjpeg distributions. Furthermore, they violate the license conditions as described under LEGAL ISSUES above. We have no sympathy for the release of misleading and illegal distributions derived from obsolete code bases. Don't use an obsolete code base! I mean, the original README in libjpeg, not that in the patchwork you are talking about, which is one of the license violations. It seems that Bill Allombert is still one of the few sane people out there, many others have apparently gone mad. I don't care for the ignorant people. You may of course make a turbo version, I have nothing against it, but NOT in the way mentioned. Take libjpeg with its current features and make it turbo - that would be wonderful! For reference: http://www.libjpeg-turbo.org/About/FUD As we can see, the other camp doesn't agree. I would like to avoid political/legal/off-topic discussions that doesn't belong to this bug report or LJT ITP. Thanks. I fully agree with Fathi, no political discussion via an Debian ITP in BTS. Well the issues were about: 1. legal issues 2. ABI compatibility For (1), I read the original copyright 3 times [1], but I failed to see where exactly the issue is. The most probable issue is : [...] (1) If any part of the source code for this software is distributed, then this README file must be included, with this copyright and no-warranty notice unaltered; and any additions, deletions, or changes to the original files must be clearly indicated in accompanying documentation. [...] However looking at [2] I can check that the original README is still there. The modifications from the original libjpeg seems to be indicated quite clearly in section libjpeg v7 and v8 Features, of [3]. So I am not clear what the issue really is... Maybe it depends on what you call [...] be clearly indicated [...] Guido, could you precisely outline what you call [...] they violate the license conditions [...]. As for (2), I explained what the differences are at: http://bugs.debian.org/612341#136 I guess I am being picky here, but if a lib claims to have a SONAME of libjpeg8, then it should *actually* implements all of libjpeg8 ABI. dpkg-divert should really be clear about that if libjpeg-turbo ever tries to replace libjpeg[8|9]. 2cts [1] http://packages.debian.org/changelogs/pool/main/libj/libjpeg8/current/copyright [2] http://sourceforge.net/projects/libjpeg-turbo/files/1.2.0/libjpeg-turbo-1.2.0.tar.gz [3] http://libjpeg-turbo.svn.sourceforge.net/viewvc/libjpeg-turbo/trunk/README-turbo.txt -- Mathieu -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#612341: bumblebee, libjpeg-turbo: Wheezy does not work well with modern notebook PCs.
On Wed, May 30, 2012 at 06:58:40AM +0300, Fathi Boudra wrote: On Tue, May 29, 2012 at 10:53 PM, Bill Allombert bill.allomb...@math.u-bordeaux1.fr wrote: I am surprised you do not count Debian as a major distro. Does libjpeg-progs works correctly with LJT ? That's my point. Debian is the only one that haven't switched yet :) Yes, LJT works with libjpeg-progs. This post form Mathieu http://bugs.debian.org/612341#136 clearly show it does not works with libjpeg-progs. Is it outdated, or are you misinformed ? Cheers, -- Bill. ballo...@debian.org Imagine a large red swirl here. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#612341: bumblebee, libjpeg-turbo: Wheezy does not work well with modern notebook PCs.
Hello Mathieu I fully agree with Fathi, no political discussion via an Debian ITP in BTS. Well the issues were about: 1. legal issues 2. ABI compatibility You are right, these are more substantial than just political issues. (1) If any part of the source code for this software is distributed, then this README file must be included, with this copyright and no-warranty notice unaltered; and any additions, deletions, or changes to the original files must be clearly indicated in accompanying documentation. [...] Guido, could you precisely outline what you call [...] they violate the license conditions [...]. Yes, compare the README file that is contained in this derivative with the one in the original package. Their version is crippled and garbled to a degree which I call misleading. And neither on their web page nor on the Wikipedia libjpeg entry which they obviously control (which shows that the Wikipedia principles do not work here) is there any mention of the defects, which again is misleading. Notice that even commercial companies contact me to ask for satisfying the license conditions properly, but this derivative maintainer has never contacted IJG for resolving such issues. And I have other things to do than go out to every of the zillions of libjpeg users to check if they obey the license conditions. Obviously in this case we have a deliberate infringement of the conditions, which is explained with the fraudulent intent of those people as mentioned. I guess I am being picky here, but if a lib claims to have a SONAME of libjpeg8, then it should *actually* implements all of libjpeg8 ABI. That is a MAJOR issue! I cannot believe that you folks accept the fact that a lib PRETENDS compatibility with a certain INTERFACE, but WITHOUT actually IMPLEMENTING it! Anyone who does or accepts such action cannot be taken seriously, sorry, and I will certainly recommend anyone to stay away from organizations or companies which do or accept such practice. Regards Guido Vollbeding Organizer Independent JPEG Group -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#612341: bumblebee, libjpeg-turbo: Wheezy does not work well with modern notebook PCs.
On Wed, May 30, 2012 at 11:09:12AM +0200, Mike Gabriel wrote: Hi Fathi, On Mi 30 Mai 2012 06:06:07 CEST Fathi Boudra wrote: On Wed, May 30, 2012 at 1:15 AM, Guido Vollbeding gu...@jpegclub.org wrote: Hello Mathieu Thank you for question. libjpeg is reference code, not faulty patchwork. Everything is said in the README: There are currently distributions in circulation containing the name libjpeg which claim to be a derivative or fork of the original libjpeg, but don't have the features and are incompatible with formats supported by actual IJG libjpeg distributions. Furthermore, they violate the license conditions as described under LEGAL ISSUES above. We have no sympathy for the release of misleading and illegal distributions derived from obsolete code bases. Don't use an obsolete code base! I mean, the original README in libjpeg, not that in the patchwork you are talking about, which is one of the license violations. It seems that Bill Allombert is still one of the few sane people out there, many others have apparently gone mad. I don't care for the ignorant people. You may of course make a turbo version, I have nothing against it, but NOT in the way mentioned. Take libjpeg with its current features and make it turbo - that would be wonderful! For reference: http://www.libjpeg-turbo.org/About/FUD As we can see, the other camp doesn't agree. I would like to avoid political/legal/off-topic discussions that doesn't belong to this bug report or LJT ITP. Thanks. I fully agree with Fathi, no political discussion via an Debian ITP in BTS. Guido and me have been dragged in this bug log against our will. You can hardly blame us for answering. Whether a package is correctly licensed is certainly relevant to an ITP. libjpeg-turbo is released with a different license than libjpeg, so it is not possible to port code from libjpeg-turbo to libjpeg. So you can see why Guido consider libjpeg-turbo with some hostility. Cheers, -- Bill. ballo...@debian.org Imagine a large red swirl here. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#612341: bumblebee, libjpeg-turbo: Wheezy does not work well with modern notebook PCs.
Hi, On Mi 30 Mai 2012 11:21:18 CEST Bill Allombert wrote: I fully agree with Fathi, no political discussion via an Debian ITP in BTS. Guido and me have been dragged in this bug log against our will. You can hardly blame us for answering. Not blaming anyone... Whether a package is correctly licensed is certainly relevant to an ITP. libjpeg-turbo is released with a different license than libjpeg, so it is not possible to port code from libjpeg-turbo to libjpeg. So you can see why Guido consider libjpeg-turbo with some hostility. Ok, the license mismatch is a bummer... License issues surely are subject of an ITP. Agreed. Thanks for giving the extra info on the license, Mike -- DAS-NETZWERKTEAM mike gabriel, rothenstein 5, 24214 neudorf-bornstein fon: +49 (1520) 1976 148 GnuPG Key ID 0xB588399B mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb pgphi0kITnGTF.pgp Description: Digitale PGP-Unterschrift
Bug#612341: bumblebee, libjpeg-turbo: Wheezy does not work well with modern notebook PCs.
Hi, On Wed, May 30, 2012 at 12:20:21PM +0200, Mike Gabriel wrote: Hi, On Mi 30 Mai 2012 11:21:18 CEST Bill Allombert wrote: ... Let's focus on topic: ITP = Intent_To_Package for libjpeg-turbo Whether a package is correctly licensed is certainly relevant to an ITP. libjpeg-turbo is released with a different license than libjpeg, so it is not possible to port code from libjpeg-turbo to libjpeg. So you can see why Guido consider libjpeg-turbo with some hostility. Understanding hostility: YES. (We are not discussing replacing libjpeg based packages with libjpeg-turbo based packages, now. We are discussing providing alternative if and only if user wish to use it. Practically at this point in release cycle, no sane person wish to replace such a basic package. The only package using is VirtualGL and TurboVNC and looks like they are statically linked.) Agreeing licensing issue raised by libjpeg developer: NO. As I understand, * libjpeg-turbo is a derivative work based on libjpeg * libjpeg is BSD style license without the advertising clause requirement so making derivative work (including making a patchwork of codes) is explicitly allowed and it is GPL compatible. * libjpeg-turbo is said to have some lack of features but that can not be the base for rejecting ITP. * libjpeg-turbo is not presenting itself as libjpg. README-turbo.txt clearly states: | libjpeg-turbo is a derivative of libjpeg which uses SIMD instructions (MMX, | SSE2, etc.) to accelerate baseline JPEG compression and decompression on x86 | and x86-64 systems. On such systems, libjpeg-turbo is generally 2-4x as fast | as the unmodified version of libjpeg, all else being equal. | | libjpeg-turbo was originally based on libjpeg/SIMD by Miyasaka Masaru, but | the TigerVNC and VirtualGL projects made numerous enhancements to the codec in | 2009, including improved support for Mac OS X, 64-bit support, support for | 32-bit and big endian pixel formats (RGBX, XBGR, etc.), accelerated Huffman | encoding/decoding, and various bug fixes. The goal was to produce a fully open | source codec that could replace the partially closed source TurboJPEG/IPP codec | used by VirtualGL and TurboVNC. libjpeg-turbo generally performs in the range | of 80-120% of TurboJPEG/IPP. It is faster in some areas but slower in others. | | In early 2010, libjpeg-turbo spun off into its own independent project, with | the goal of making high-speed JPEG compression/decompression technology | available to a broader range of users and developers. The libjpeg-turbo shared | libraries can be used as drop-in replacements for libjpeg on most systems. The only thing one can think as problematic is the correctness of statement all else being equal since libjpeg-turbo is said to have dropped support for the arithmetic encoding scheme. We could ask upstream to fix it by replacing it with all else being practically equal. (Or we can patch it when we distribute so no misrepresentation claim can be used against this package.) I have not checked this claim of correctness myself, though. (Besides, this does not hinder actual usefulness as long as ABI compatible for other functions.) As for patent issues discussed elsewhere, as usual with Debian, we do not dig deep and package it. http://www.debian.org/legal/patent Ok, the license mismatch is a bummer... I do not see the license mismatch like GPL/BSD incompatibility nor anyone made any clear case of it. Please be explicit on the problem. License issues surely are subject of an ITP. Agreed. Since no license mismatch exists, packaging is allowed. Regards, Osamu -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#612341: bumblebee, libjpeg-turbo: Wheezy does not work well with modern notebook PCs.
Hi Bill, On Sun, May 27, 2012 at 5:40 PM, Bill Allombert wrote: Does libjpeg-turbo8 implement the full v8 API ? As far as I understand some functions are stub. I'm not sure it's relevant anymore. All major distro have switched to LJT. Ubuntu is using it by default and no issues were found that can prove v8 API incompatibility. Cheers, Fathi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#612341: bumblebee, libjpeg-turbo: Wheezy does not work well with modern notebook PCs.
On Sat, May 26, 2012 at 9:34 PM, Osamu Aoki os...@debian.org wrote: Also, Mike Gabriel's work seems to have done somethings interesting on old Fathi's version and made many improvements. thanks for pinging us! I agree, libjpeg-turbo has to be in Wheezy!!! Fathi, please send us a notice what you plan on this package. I see Fathi being quite active. Yes, I am. Apologies, I've been quite busy on other front and put LJT as a low prio. AFAIR, current Ubuntu package wasn't suitable to be uploaded as-is. I'm at Linaro Connect this week with Tom Gall and Doko, I'll sync up with them and upload the package if everything alright. Sounds like many people are interested. LJT is a good candidate for collab-maint on git.debian.org :) Cheers, Fathi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#612341: bumblebee, libjpeg-turbo: Wheezy does not work well with modern notebook PCs.
Hi Fathi, On Di 29 Mai 2012 18:36:12 CEST Fathi Boudra wrote: Sounds like many people are interested. LJT is a good candidate for collab-maint on git.debian.org :) Good idea. Please relocate the packaging Git so that we can work together on this. Greets, Mike -- DAS-NETZWERKTEAM mike gabriel, rothenstein 5, 24214 neudorf-bornstein fon: +49 (1520) 1976 148 GnuPG Key ID 0xB588399B mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb pgpZxg8KfU43t.pgp Description: Digitale PGP-Unterschrift
Bug#612341: bumblebee, libjpeg-turbo: Wheezy does not work well with modern notebook PCs.
Guido, Sorry to make you jump in the middle of this thread. We are discussing compatibilities issues in between LJT (lib JPEG Turbo) and the official IJG distribution. The whole thread can be seen here: http://bugs.debian.org/612341 Do you have any particular comments on LJT ? From a pure debian point of view, I believe the vast majority of people are still only looking for 8bits implementation of ITU-T T.81, ISO/IEC IS 10918-1. Thanks for your comments, On Tue, May 29, 2012 at 9:53 PM, Bill Allombert bill.allomb...@math.u-bordeaux1.fr wrote: On Tue, May 29, 2012 at 07:27:35PM +0300, Fathi Boudra wrote: Hi Bill, On Sun, May 27, 2012 at 5:40 PM, Bill Allombert wrote: Does libjpeg-turbo8 implement the full v8 API ? As far as I understand some functions are stub. I'm not sure it's relevant anymore. All major distro have switched to LJT. Ubuntu is using it by default and no issues were found that can prove v8 API incompatibility. I am surprised you do not count Debian as a major distro. Does libjpeg-progs works correctly with LJT ? Cheers, -- Bill. ballo...@debian.org Imagine a large red swirl here. -- Mathieu -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#612341: bumblebee, libjpeg-turbo: Wheezy does not work well with modern notebook PCs.
On Tue, May 29, 2012 at 07:27:35PM +0300, Fathi Boudra wrote: Hi Bill, On Sun, May 27, 2012 at 5:40 PM, Bill Allombert wrote: Does libjpeg-turbo8 implement the full v8 API ? As far as I understand some functions are stub. I'm not sure it's relevant anymore. All major distro have switched to LJT. Ubuntu is using it by default and no issues were found that can prove v8 API incompatibility. I am surprised you do not count Debian as a major distro. Does libjpeg-progs works correctly with LJT ? Cheers, -- Bill. ballo...@debian.org Imagine a large red swirl here. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#612341: bumblebee, libjpeg-turbo: Wheezy does not work well with modern notebook PCs.
Hello Mathieu Thank you for question. libjpeg is reference code, not faulty patchwork. Everything is said in the README: There are currently distributions in circulation containing the name libjpeg which claim to be a derivative or fork of the original libjpeg, but don't have the features and are incompatible with formats supported by actual IJG libjpeg distributions. Furthermore, they violate the license conditions as described under LEGAL ISSUES above. We have no sympathy for the release of misleading and illegal distributions derived from obsolete code bases. Don't use an obsolete code base! I mean, the original README in libjpeg, not that in the patchwork you are talking about, which is one of the license violations. It seems that Bill Allombert is still one of the few sane people out there, many others have apparently gone mad. I don't care for the ignorant people. You may of course make a turbo version, I have nothing against it, but NOT in the way mentioned. Take libjpeg with its current features and make it turbo - that would be wonderful! From a pure debian point of view, I believe the vast majority of people are still only looking for 8bits implementation of ITU-T T.81, ISO/IEC IS 10918-1. That is not the point. libjpeg is still 8bits only in its default configuration, as it always was. Nothing was changed there. But I'm working on ADDING features, not REMOVING ones. We are now on the way to release 9, and T.81/10918-1 is far left behind already, for those who care. Regards Guido Vollbeding Organizer Independent JPEG Group -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#612341: bumblebee, libjpeg-turbo: Wheezy does not work well with modern notebook PCs.
On Tue, May 29, 2012 at 10:53 PM, Bill Allombert bill.allomb...@math.u-bordeaux1.fr wrote: I am surprised you do not count Debian as a major distro. Does libjpeg-progs works correctly with LJT ? That's my point. Debian is the only one that haven't switched yet :) Yes, LJT works with libjpeg-progs. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#612341: bumblebee, libjpeg-turbo: Wheezy does not work well with modern notebook PCs.
On Wed, May 30, 2012 at 1:15 AM, Guido Vollbeding gu...@jpegclub.org wrote: Hello Mathieu Thank you for question. libjpeg is reference code, not faulty patchwork. Everything is said in the README: There are currently distributions in circulation containing the name libjpeg which claim to be a derivative or fork of the original libjpeg, but don't have the features and are incompatible with formats supported by actual IJG libjpeg distributions. Furthermore, they violate the license conditions as described under LEGAL ISSUES above. We have no sympathy for the release of misleading and illegal distributions derived from obsolete code bases. Don't use an obsolete code base! I mean, the original README in libjpeg, not that in the patchwork you are talking about, which is one of the license violations. It seems that Bill Allombert is still one of the few sane people out there, many others have apparently gone mad. I don't care for the ignorant people. You may of course make a turbo version, I have nothing against it, but NOT in the way mentioned. Take libjpeg with its current features and make it turbo - that would be wonderful! For reference: http://www.libjpeg-turbo.org/About/FUD As we can see, the other camp doesn't agree. I would like to avoid political/legal/off-topic discussions that doesn't belong to this bug report or LJT ITP. Thanks. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#612341: bumblebee, libjpeg-turbo: Wheezy does not work well with modern notebook PCs.
Hi there, On Sat, May 26, 2012 at 8:34 PM, Osamu Aoki os...@debian.org wrote: Hi, On Sat, May 26, 2012 at 06:31:46PM +0200, Mike Gabriel wrote: Hi all, On Sa 26 Mai 2012 17:11:02 CEST Osamu Aoki wrote: This ITP Bug #612341 was supposed to be closed by Fathi sometime early January. Nothing happened. http://bugs.debian.org/612341 In the meantime, Ubuntu package was updated to generate -dev etc. https://launchpad.net/ubuntu/+source/libjpeg-turbo libjpeg-turbo (1.1.90+svn733-0ubuntu4) precise; urgency=low * Install jpegint.h in the -dev package. * Install jconfig.h in the multiarch include directory. -- Matthias Klose email address hidden Fri, 13 Jan 2012 12:02:38 +0100 This package can be build on sid (under pbuilder) nicely practically as is and also makes libjpeg-turbo8. So ABI of version 8 is taken care as I understand. Also, Mike Gabriel's work seems to have done somethings interesting on old Fathi's version and made many improvements. thanks for pinging us! I agree, libjpeg-turbo has to be in Wheezy!!! Fathi, please send us a notice what you plan on this package. I see Fathi being quite active. I have made packages for libjpeg-turbo 1.2.0. It builds OK. (Not much useful to replace current libjpeg due to conflicts caused with many packages. But who cares if it is used in the chroot to build virtualgl :-) But I am not really up to maintaining this complicated package. My build result and git record are here as tar: http://people.debian.org/~osamu/libjpeg-turbo-1.2.0-osamu.tar.gz Since -dev package is the only ones desparatedly needed, ... This is the most important thing to get now. Maybe in post-wheezy, people can discuss transition from libjpeg to libjpeg-turbo. This package is very tricky since it tries to replace libjpeg. Regards, Osamu CCed: Bill who is libjpeg maintainer. As far as I know libjpeg is not really concerned here. virtualgl only links to libturbojpeg. So there really are two issues in a single report: 1. optimized jpeg lib, as a replacement for libjpeg8 2. getting bumblebeed/virtualgl/turbojpeg(only) in debian Maybe it would be easier to only focus on (2) ? 2cts -M -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#612341: bumblebee, libjpeg-turbo: Wheezy does not work well with modern notebook PCs.
On Sun, May 27, 2012 at 03:34:39AM +0900, Osamu Aoki wrote: Hi, On Sat, May 26, 2012 at 06:31:46PM +0200, Mike Gabriel wrote: Hi all, On Sa 26 Mai 2012 17:11:02 CEST Osamu Aoki wrote: This ITP Bug #612341 was supposed to be closed by Fathi sometime early January. Nothing happened. http://bugs.debian.org/612341 In the meantime, Ubuntu package was updated to generate -dev etc. https://launchpad.net/ubuntu/+source/libjpeg-turbo libjpeg-turbo (1.1.90+svn733-0ubuntu4) precise; urgency=low * Install jpegint.h in the -dev package. * Install jconfig.h in the multiarch include directory. -- Matthias Klose email address hidden Fri, 13 Jan 2012 12:02:38 +0100 This package can be build on sid (under pbuilder) nicely practically as is and also makes libjpeg-turbo8. So ABI of version 8 is taken care as I understand. Does libjpeg-turbo8 implement the full v8 API ? As far as I understand some functions are stub. Cheers, -- Bill. ballo...@debian.org Imagine a large red swirl here. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#612341: bumblebee, libjpeg-turbo: Wheezy does not work well with modern notebook PCs.
Hi, On Sun, May 27, 2012 at 10:43:39AM +0200, Mathieu Malaterre wrote: Hi there, ... CCed: Bill who is libjpeg maintainer. As far as I know libjpeg is not really concerned here. virtualgl only links to libturbojpeg. So there really are two issues in a single report: 1. optimized jpeg lib, as a replacement for libjpeg8 2. getting bumblebeed/virtualgl/turbojpeg(only) in debian Maybe it would be easier to only focus on (2) ? YES. If you are more capable than me, you can copy required sources to virtualgl via debian/* and build it without requiring non-exisiong packahes. Do you have patch to address this in a short notice? For a person like me with less capability, uploads this package to provide required packages seems to be the easiest thing to do. build-depens on static library is not so complicated for binary image. I know it is not so useful for most wheesy system but this is useful in chroot. Does libjpeg-turbo8 implement the full v8 API ? As far as I understand some functions are stub. I do not know. For now, we only nned -dev package for building package with static library and *.h files. Fow wheesy, no one here, I expect to remove old libjpeg8. We just need to build virtualgl. Regards, Osamu -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#612341: bumblebee, libjpeg-turbo: Wheezy does not work well with modern notebook PCs.
Hi, This ITP Bug #612341 was supposed to be closed by Fathi sometime early January. Nothing happened. http://bugs.debian.org/612341 In the meantime, Ubuntu package was updated to generate -dev etc. https://launchpad.net/ubuntu/+source/libjpeg-turbo libjpeg-turbo (1.1.90+svn733-0ubuntu4) precise; urgency=low * Install jpegint.h in the -dev package. * Install jconfig.h in the multiarch include directory. -- Matthias Klose email address hidden Fri, 13 Jan 2012 12:02:38 +0100 This package can be build on sid (under pbuilder) nicely practically as is and also makes libjpeg-turbo8. So ABI of version 8 is taken care as I understand. Also, Mike Gabriel's work seems to have done somethings interesting on old Fathi's version and made many improvements. Concurrently, upstream has released newer libjpeg-turbo-1.2.0.tar.gz So I do not understand why this is not uploaded. This is blocking bumblebee support for wheezy. This makes the next Debian Wheezy non-optimal for many modern notebook PC users since this is blocking bumblebee upload. https://github.com/Bumblebee-Project/Bumblebee/wiki/FAQ It seems touching up Ubuntu package seems to be the simplest thing to get this package into Debian before FREEZE (JUNE!). Once this is done, all other required pieces are in Ubuntu https://launchpad.net/~bumblebee https://launchpad.net/~bumblebee/+archive/stable/+packages?field.name_filter=field.status_filter=publishedfield.series_filter=precise For Debian, http://suwako.nomanga.net/ is good archive. It works. (I can not find source package for the virtualgl package here but above Ubuntu site has it anyway.) I am using this package but wish to get it into Debian. Since no action has been taken for many months and FREEZE is coming, I hope Fathi does not mind someone else uploading this package and get things moving. Any thoughts? Regards, Osamu -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#612341: bumblebee, libjpeg-turbo: Wheezy does not work well with modern notebook PCs.
Hi all, On Sa 26 Mai 2012 17:11:02 CEST Osamu Aoki wrote: This ITP Bug #612341 was supposed to be closed by Fathi sometime early January. Nothing happened. http://bugs.debian.org/612341 In the meantime, Ubuntu package was updated to generate -dev etc. https://launchpad.net/ubuntu/+source/libjpeg-turbo libjpeg-turbo (1.1.90+svn733-0ubuntu4) precise; urgency=low * Install jpegint.h in the -dev package. * Install jconfig.h in the multiarch include directory. -- Matthias Klose email address hidden Fri, 13 Jan 2012 12:02:38 +0100 This package can be build on sid (under pbuilder) nicely practically as is and also makes libjpeg-turbo8. So ABI of version 8 is taken care as I understand. Also, Mike Gabriel's work seems to have done somethings interesting on old Fathi's version and made many improvements. thanks for pinging us! I agree, libjpeg-turbo has to be in Wheezy!!! Fathi, please send us a notice what you plan on this package. Thanks, Mike -- DAS-NETZWERKTEAM mike gabriel, rothenstein 5, 24214 neudorf-bornstein fon: +49 (1520) 1976 148 GnuPG Key ID 0xB588399B mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb pgpbjx2bcC6XH.pgp Description: Digitale PGP-Unterschrift
Bug#612341: bumblebee, libjpeg-turbo: Wheezy does not work well with modern notebook PCs.
Hi, On Sat, May 26, 2012 at 06:31:46PM +0200, Mike Gabriel wrote: Hi all, On Sa 26 Mai 2012 17:11:02 CEST Osamu Aoki wrote: This ITP Bug #612341 was supposed to be closed by Fathi sometime early January. Nothing happened. http://bugs.debian.org/612341 In the meantime, Ubuntu package was updated to generate -dev etc. https://launchpad.net/ubuntu/+source/libjpeg-turbo libjpeg-turbo (1.1.90+svn733-0ubuntu4) precise; urgency=low * Install jpegint.h in the -dev package. * Install jconfig.h in the multiarch include directory. -- Matthias Klose email address hidden Fri, 13 Jan 2012 12:02:38 +0100 This package can be build on sid (under pbuilder) nicely practically as is and also makes libjpeg-turbo8. So ABI of version 8 is taken care as I understand. Also, Mike Gabriel's work seems to have done somethings interesting on old Fathi's version and made many improvements. thanks for pinging us! I agree, libjpeg-turbo has to be in Wheezy!!! Fathi, please send us a notice what you plan on this package. I see Fathi being quite active. I have made packages for libjpeg-turbo 1.2.0. It builds OK. (Not much useful to replace current libjpeg due to conflicts caused with many packages. But who cares if it is used in the chroot to build virtualgl :-) But I am not really up to maintaining this complicated package. My build result and git record are here as tar: http://people.debian.org/~osamu/libjpeg-turbo-1.2.0-osamu.tar.gz Since -dev package is the only ones desparatedly needed, ... This is the most important thing to get now. Maybe in post-wheezy, people can discuss transition from libjpeg to libjpeg-turbo. This package is very tricky since it tries to replace libjpeg. Regards, Osamu CCed: Bill who is libjpeg maintainer. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
