Re: jpeg8 vs jpeg-turbo
On Fri, Apr 26, 2013 at 11:50 PM, Bill Allombert wrote: > On Wed, Apr 24, 2013 at 10:10:42PM +0800, Aron Xu wrote: >> On Wed, Apr 24, 2013 at 9:19 PM, Bill Allombert >> wrote: >> > >> > As IJG libjpeg maintainer, my plan is to move to libjpeg9 which has more >> > feature. >> > >> >> From a user's prospective, I don't think adding bunches of not widely >> used features is that useful (I mean it's useful but not that >> important), but speed does matter a lot, especially on slower hardware >> like ARM-boards. > > I think there are some misunderstanding about what offer libjpeg8: > > 1) by default, libjpeg8 creates JFIF files which are compatible with > libjpeg62. > > 2) by default, libjpeg8 uses a different subsampling which lead to higher > quality output than libjpeg62. > > However this leads to files which are not byte per byte indentical to what > libjpeg62 would produce, but this is in no way required by the JPEG standard. > Indeed the standard explicitely allow for different DCT implementation. No this is not the case. It was just this initial issue which raise my attention to what is happening with libjpeg in Debian. > 3) libjpeg8 implements a larger part of the JPEG standard, so it can read and > write > JFIF files that are standard compliant but not supported by libjpeg62. This is too much generic. Could you please list those differences in the JPEG standard implementation between IJG libjpeg and libjpeg-turbo. > 4) it also provides a number of extension to the standard, which are well > documented. Again, could you please list that? If you are speaking about SmartScale, then I really don't think that non-(ISO)-standard extensions are usefull for anything. Or is there anything else? > So I do not think it is fair to restrict JPEG support in Debian to 1998 image > processing technology. Nobody is saying that. Bill, please stop being holed up in your position. Most of the Open Source world (as already proven and cited) has moved to libjpeg-turbo and I don't think this is the case where Debian should stand out. O. P.S.: You still haven't answered my questions in the previous email. I don't think they are unreasonable. -- Ondřej Surý -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CALjhHG92k=s4vbzjnlr2vskkwuae+vfpovhmh8wgkzr69qh...@mail.gmail.com
Re: not co-installable Multi-Arch:same packages
On 2013-04-25 22:09, Jakub Wilk wrote: > * Andreas Beckmann , 2013-04-25, 21:27: >> trying to overwrite shared '/usr/lib/debug/usr/lib/libffi.so.5.0.10', >> which is different from other instances of package libffi5-dbg:i386 > > #650106 > >> Maybe this shouldn't have been MA:same. > > There's no problem with -dbg packages being MA:same. They just need to > use build-id-based paths. dh_strip does it for you in compat >= 9. So "maybe libffi5-dbg shouldn't have been M-A:same for wheezy since it was too late to bump debhelper compat to 9". Should we try to fix this for wheezy (by temporarily dropping MA:same on the -dbg package)? Fix can go via unstable. >> trying to overwrite shared >> '/usr/share/doc/libdmtx-dev/examples/net/Libdmtx.Net.Test/DmtxTest.cs.gz', >> which is different from other instances of package libdmtx-dev:i386 > > I can't reproduce this in unstable. it's a gzip problem ... the uncompressed files are identical 5211e14d78f209547869f5f0511e8962 DmtxTest.cs.gz:i386 50d26e0c550cd9c99223abf2dbe7b408 DmtxTest.cs.gz:amd64 107f0f804c01fc96697554b44403da17 DmtxTest.cs:amd64 107f0f804c01fc96697554b44403da17 DmtxTest.cs:i386 If I rebuild the wheezy package in sid for amd64, I get the following md5sum: 5211e14d78f209547869f5f0511e8962, so maybe there was something badly configured or outdated on the buildd? https://buildd.debian.org/status/logs.php?pkg=libdmtx&arch=amd64 0.7.2-2+b1 (sid) Maybe-Successful 2012-04-03 18:36:35 brahms 6m 9.36 MB Anyway, libdmtx was binNMUed, so this "problem" might clear automatically for a no-change rebuild. Jakub, thanks for filing / looking up the other bugs. Maybe some of them are affected by some gzip problem, too, as the problematic files were compressed ones. Andreas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/517b2943.7020...@debian.org
Re: Bug#706160: general: it should be easier for ordinary developers to work with Debian packages
[James Cloos] > And where does one find dh_make? > > Searching on goog suggests it would be part of debhelper. But it isn't: Someone suggested 'apt-file', but in this case the simpler thing is: apt-cache search dh_make -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130427010928.gc4...@p12n.org
Re: Bug#706160: general: it should be easier for ordinary developers to work with Debian packages
On 27/04/13 01:46, James Cloos wrote: >> "CALP" == Carlos Alberto Lopez Perez writes: > > CALP> This can be even more simple: > > CALP> dh_make -f ../foo-1.tar.gz > CALP> dpkg-buildpackage > > And where does one find dh_make? > > Searching on goog suggests it would be part of debhelper. But it isn't: > > :; dpkg -L debhelper|grep dh_make > /usr/bin/dh_makeshlibs > /usr/share/man/de/man1/dh_makeshlibs.1.gz > /usr/share/man/fr/man1/dh_makeshlibs.1.gz > /usr/share/man/man1/dh_makeshlibs.1.gz > /usr/share/man/es/man1/dh_makeshlibs.1.gz > > :; dpkg -l|grep debhelp|perl -pe 's/ +/ /g' > ii debhelper 9.20120909 all helper programs for debian/rules > > -JimC > Use apt-file to search which package contains a given file: $ apt-file search dh_make | grep /dh_make$ dh-make: /usr/bin/dh_make signature.asc Description: OpenPGP digital signature
Re: not co-installable Multi-Arch:same packages
[adding -release@] Hi, a few Multi-Arch: same packages have all their dependencies satisfied, but are not co-installable because they got binNMUs. A sourceful no-change upload to rebuild them should restore co-installability. I've identified 8 source packages where this would help: bogl clutter-gst libdmtx libftdi libopenraw libpano13 lua-sql myodbc Note: I only tested co-installing amd64 + i386 packages. Perhaps there are some more binNMUs hidden in other architectures. On 2013-04-25 21:27, Andreas Beckmann wrote: > On 2013-04-22 21:38, Andreas Beckmann wrote: >> On 2013-04-22 07:31, Guillem Jover wrote: >>> I guess a way to detect those could be piuparts runs that install >>> multiple instances of Multi-Arch:same packages, purge just one of > ... >> Actually I already tried something similar some time ago, although I >> only focussed on co-installability problems. I didn't look into this > ... > > I just reran these tests (host: amd64, installing the foreign i386 packages) > on current wheezy and will provide a short report here: > > Many packages marked M-A:same are not co-installable due to unsatisfied > dependencies (usually not all deps are properly multiarchified). > That's not a problem right now, apt will take care of this. > > But there are some packages that qualify as "co-installable", but fail to do > so: > > Uninstallable due to binNMU: >trying to overwrite shared '/usr/share/doc/libbogl0/changelog.Debian.gz', > which is different from other instances of package libbogl0:i386 >trying to overwrite shared > '/usr/share/doc/libclutter-gst-1.0-0/changelog.Debian.gz', which is different > from other instances of package libclutter-gst-1.0-0:i386 >trying to overwrite shared > '/usr/share/doc/libclutter-gst-1.0-dbg/changelog.Debian.gz', which is > different from other instances of package libclutter-gst-1.0-dbg:i386 >trying to overwrite shared '/usr/share/doc/libdmtx0a/changelog.Debian.gz', > which is different from other instances of package libdmtx0a:i386 >trying to overwrite shared > '/usr/share/doc/libftdi1-dbg/changelog.Debian.gz', which is different from > other instances of package libftdi1-dbg:i386 >trying to overwrite shared '/usr/share/doc/libftdi1/changelog.Debian.gz', > which is different from other instances of package libftdi1:i386 >trying to overwrite shared > '/usr/share/doc/libftdipp1-dbg/changelog.Debian.gz', which is different from > other instances of package libftdipp1-dbg:i386 >trying to overwrite shared > '/usr/share/doc/libftdipp1/changelog.Debian.gz', which is different from > other instances of package libftdipp1:i386 >trying to overwrite shared '/usr/share/doc/libmyodbc/changelog.Debian.gz', > which is different from other instances of package libmyodbc:i386 >trying to overwrite shared > '/usr/share/doc/libopenraw1/changelog.Debian.gz', which is different from > other instances of package libopenraw1:i386 >trying to overwrite shared > '/usr/share/doc/libopenrawgnome1/changelog.Debian.gz', which is different > from other instances of package libopenrawgnome1:i386 >trying to overwrite shared > '/usr/share/doc/libpano13-2/changelog.Debian.gz', which is different from > other instances of package libpano13-2:i386 >trying to overwrite shared > '/usr/share/doc/lua-sql-mysql-dev/changelog.Debian.gz', which is different > from other instances of package lua-sql-mysql-dev:i386 >trying to overwrite shared > '/usr/share/doc/lua-sql-mysql/changelog.Debian.gz', which is different from > other instances of package lua-sql-mysql:i386 >trying to overwrite shared > '/usr/share/doc/lua-sql-sqlite3-dev/changelog.Debian.gz', which is different > from other instances of package lua-sql-sqlite3-dev:i386 >trying to overwrite shared > '/usr/share/doc/lua-sql-sqlite3/changelog.Debian.gz', which is different from > other instances of package lua-sql-sqlite3:i386 > but otherwise dependencies are satisfied, so these might be candidates for > no-change rebuilds to make them co-installable in wheezy. > Looks like this is a manageable amount of source packages: > bogl clutter-gst libdmtx libftdi libopenraw libpano13 lua-sql myodbc Andreas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/517b119e.70...@debian.org
Re: Bug#706160: general: it should be easier for ordinary developers to work with Debian packages
> "CALP" == Carlos Alberto Lopez Perez writes: CALP> This can be even more simple: CALP> dh_make -f ../foo-1.tar.gz CALP> dpkg-buildpackage And where does one find dh_make? Searching on goog suggests it would be part of debhelper. But it isn't: :; dpkg -L debhelper|grep dh_make /usr/bin/dh_makeshlibs /usr/share/man/de/man1/dh_makeshlibs.1.gz /usr/share/man/fr/man1/dh_makeshlibs.1.gz /usr/share/man/man1/dh_makeshlibs.1.gz /usr/share/man/es/man1/dh_makeshlibs.1.gz :; dpkg -l|grep debhelp|perl -pe 's/ +/ /g' ii debhelper 9.20120909 all helper programs for debian/rules -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/m361z8dfdr@carbon.jhcloos.org
Re: jpeg8 vs jpeg-turbo
On Fri, Apr 26, 2013 at 11:50 PM, Bill Allombert < bill.allomb...@math.u-bordeaux1.fr> wrote: > So I do not think it is fair to restrict JPEG support in Debian to 1998 > image > processing technology. > > According to this mail by the Fedora KDE maintainer, ISO rejected the latest changes introduced by libjpeg8: http://mail.kde.org/pipermail/digikam-devel/2013-January/066256.html Why should Debian use a library which generates non-standard JPEG files? And it's even worse for libjpeg9, IIUC from that discussion in the Digikam mailing list. -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer)
Re: [Debian-med-packaging] Question about proper archive area for packages that require big data for operation
On Fri, Apr 26, 2013 at 03:21:43PM +0200, Laszlo Kajan wrote: > Dear FTP Masters! > > On 23/04/13 15:13, Benjamin Drung wrote: > [...] > > You can use xz for the source and binary package to reduce the size. The > > default compression level for xz reduces the size of the source tarball > > from 415 MB to 272 MB: > > > > $ ls -1s --si metastudent-data_1.0.0.tar* > > 823M metastudent-data_1.0.0.tar > > 381M metastudent-data_1.0.0.tar.bz2 > > 415M metastudent-data_1.0.0.tar.gz > > 272M metastudent-data_1.0.0.tar.xz > > $ ls -1sh metastudent-data_1.0.0.tar* > > 784M metastudent-data_1.0.0.tar > > 363M metastudent-data_1.0.0.tar.bz2 > > 396M metastudent-data_1.0.0.tar.gz > > 259M metastudent-data_1.0.0.tar.xz > > Following Benjamin's suggestion and the data.debian.org document [1], we have > prepared a 'metastudent-data' arch:all package that is ~130MB (xz > compressed). > The package builds required architecture dependent databases in the postinst > script. The purpose of this is to save space in the archive that > each architecture dependent version would take up. [...] Does this mean that installing the package results in having two uncompressed copies of the data on disk? If so, wouldn't it be better to do: 1. Compress the database (with xz). 2. Build the package without compression (contents are already compressed so re-compressing would be a waste of time). 3. In postinst, decompress and convert the database to native. However, I would expect the vast majority of installations to be on amd64, so if you always generate a 64-bit little-endian database and avoid duplicating when installing on such a machine then it would be better for most users (not so nice for others). (Incidentally, arch:all packages generating arch-specific data have interesting interactions with multi-arch. I doubt many people with multi-arch systems would want this package to generate multiple versions of the database, but you never know...) Ben. -- Ben Hutchings We get into the habit of living before acquiring the habit of thinking. - Albert Camus -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130426224644.gf2...@decadent.org.uk
Re: jpeg8 vs jpeg-turbo
+++ Bill Allombert [2013-04-26 23:50 +0200]: > > So I do not think it is fair to restrict JPEG support in Debian to 1998 image > processing technology. Neither does anyone else, which is why they want to be able to use the SIMD features in their CPUs for (much) faster JPEG processing. So far a good case seems to be being made that that is more useful and more requested than the relatively minor image quality improvements you mentioned. (And they can be had without any issues with incompatible image formats.) Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130426221316.gh2...@stoneboat.aleph1.co.uk
Re: Bug#706160: general: it should be easier for ordinary developers to work with Debian packages
On 26-04-13 21:43, Ben Longbons wrote: > From: Christian PERRIER >> I'm definitely sure that a bug report is not the way to achieve >> anything here. > Okay, continuing this on-list instead of in the bug report. Everyone, > please keep me on the CC list, I missed half of these replies. > > As Wouter mentioned, coming up to $DISTRO and saying >> that "you guys are doing things wrong and here is how you should do" >> is like saying "please throw away 20 years of accumulated experience >> and restart from scratch". I very much doubt it will ever happen. > I am NOT trying to suggest that you throw away 20 years of work. > I AM trying to suggest that even after 20 years, there are still > some issues, which affect Ordinary Developers more than you. I realize (and agree!) that in some cases, Debian is more complex than it could be. However, you seem to have fallen in the fallacy to believe the familiar is easier than the unknown. That's just not true. [...] > My point for doing it as a bug was so that it would stay open instead > of ending up lost in the archives of a list. I guess your motive is the > exact opposite. You'll need to convince people that there actually is a problem. Thousands of people make Debian packages every day, and certainly not all of them are Debian Developers. It's not *that* hard. [...] >> If you want an >> example for how to really do things in practice, you should look at >> hello-debhelper. Its debian/rules and debian/rules-dh files are much >> simpler. >>From my experience at looking at debian/rules for packages I've tried > to patch or upgrade, 'hello' is more typical than 'hello-debhelper'. That doesn't match my experience. > Perhaps Debian should automatically file a bunch of bugs against > packages with overly-complicated debian/rules? Or add a lintian warning > or something. I don't think that's possible. How are you going to define "overly-complicated"? How are you going to write code to decide that this other code is too complicated? That doesn't sound like it's even possible. >> dpkg-scansources ... dpkg-scanpackages > Good to know, but it's still more complicated than shipping ebuilds. You can also just ship packages and install them with "dpkg -i". The dpkg-scan* thingies is just extra infrastructure, similar to what you'd call "portage overlays", if my understanding is correct. >> all you need to do is ship the debian/ directory. This Just Works(TM). > Not with dpkg-buildpackage, Yes it does. I've done it. You need to make sure you're building as a native package, but other than that, there's no problem. > which everything I read seemed to indicate > was the preferred way. That's correct. >> - Run "apt-get -d source package", fetch the new upstream source, run >> "uupdate" with the right arguments (read the manpage for the details). >> Unless it's something very complex, that will almost certainly work. > Good to know. Not obvious at all. > > Of course, for a distressing number of packages, .orig.tar.gz is a repack, > not the upstream's vanilla tarball. Would that make uupdate fail? It shouldn't, unless the .orig.tar.gz is laid out completely different. I've not seen that much in practice (if at all) [...] > I'm not saying I expect to read no documentation. I'm saying that > the documentation I read was not intuitive. Then perhaps the documentation you read wasn't the right documentation. For the benefit of improving that, could you let us know how you searched for it, and what you found? We should look into what went wrong there. [...] > From: "Bernhard R. Link" >>> - Because of the above, debian/rules tries to know about backwards steps. >> What are "backwards steps"? > The clean and unpatch targets Doing these manually is just asking for > trouble, and you can't depend on the upstream makefile either. Sure you can. "unpatch" is just patch -R. It's pretty hard to make that fail. As to upstream build systems, you can actually depend on them to have "make clean" or a "make distclean" working right--provided they're not using some home-rolled system, but are using something standard, like autotools or cmake or similar. There are certainly cases where that doesn't work, but those are bugs like any other, and most upstreams will take patches then. In the case where it's so bad that "make clean" doesn't work, you can always do a VPATH build, or simulate that with a symlink farm. That's not too hard. >>> - It's not obvious how to modify the patch set directly. >> modify upstream files, call dpkg-source --commit > Not what I call "directly". Your patch management system seems optimized > for changing things yourselves, rather than backporting upstream fixes. You can also just drop a patch file in the right directory and add its name to the series file... >>> - There is no attempt at managing multiple source versions. >> First you say things are too complicated, then you complain about >> some obscure missing option I never found any use ca
Re: jpeg8 vs jpeg-turbo
On Wed, Apr 24, 2013 at 10:10:42PM +0800, Aron Xu wrote: > On Wed, Apr 24, 2013 at 9:19 PM, Bill Allombert > wrote: > > > > As IJG libjpeg maintainer, my plan is to move to libjpeg9 which has more > > feature. > > > > From a user's prospective, I don't think adding bunches of not widely > used features is that useful (I mean it's useful but not that > important), but speed does matter a lot, especially on slower hardware > like ARM-boards. I think there are some misunderstanding about what offer libjpeg8: 1) by default, libjpeg8 creates JFIF files which are compatible with libjpeg62. 2) by default, libjpeg8 uses a different subsampling which lead to higher quality output than libjpeg62. However this leads to files which are not byte per byte indentical to what libjpeg62 would produce, but this is in no way required by the JPEG standard. Indeed the standard explicitely allow for different DCT implementation. 3) libjpeg8 implements a larger part of the JPEG standard, so it can read and write JFIF files that are standard compliant but not supported by libjpeg62. 4) it also provides a number of extension to the standard, which are well documented. So I do not think it is fair to restrict JPEG support in Debian to 1998 image processing technology. Cheers, -- Bill. Imagine a large red swirl here. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130426215054.GB19734@yellowpig
Bug#706240: ITP: node-read-package-json -- Read package.json for npm module for Node.js
Package: wnpp Severity: wishlist Owner: "Jérémy Lal" * Package name: node-read-package-json Version : 0.3.1 Upstream Author : Isaac Z. Schlueter * URL : https://github.com/isaacs/read-package-json * License : BSD-2-clause Programming Lang: JavaScript Description : Read package.json for npm module for Node.js This module reads package.json files with semantics, defaults, and validation for npm consumption. . Node.js is an event-based server-side javascript engine. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130426214922.7146.3842.reportbug@imac.chaumes
Re: GSoC/debian.org SIP/XMPP infrastructure
]] Daniel Pocock > I'd also be keen to know how different teams (e.g. DSA) would want to > interact with students proposing such projects, as it is inevitable that > this would involve some server resources and technical changes. DSA is reachable at debian-ad...@lists.debian.org, so inquries should be sent there. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87a9ol6ncz@xoog.err.no
Re: Bug#706160: general: it should be easier for ordinary developers to work with Debian packages
From: Christian PERRIER >I'm definitely sure that a bug report is not the way to achieve >anything here. Okay, continuing this on-list instead of in the bug report. Everyone, please keep me on the CC list, I missed half of these replies. As Wouter mentioned, coming up to $DISTRO and saying >that "you guys are doing things wrong and here is how you should do" >is like saying "please throw away 20 years of accumulated experience >and restart from scratch". I very much doubt it will ever happen. I am NOT trying to suggest that you throw away 20 years of work. I AM trying to suggest that even after 20 years, there are still some issues, which affect Ordinary Developers more than you. >I'm not particularly interested in the following thread but I'm >interested in keeping our BTS as clean as possible. > >Soclosing the bug report. My point for doing it as a bug was so that it would stay open instead of ending up lost in the archives of a list. I guess your motive is the exact opposite. From: Jonathan Dowland >I think one valid point the OP makes which each of these suggestions — in > isolation — seem to miss, is there are *too many ways to do it*. The > suggestions you (and others) make are great, but how discoverable are they to > a > newbie packager? Conversely, how (non-)discoverable are the myriad bad ways to > do things (the hello package is a good example of this.) That is *exactly* my point. I have no doubt that someone familiar with the Debian infrastructure is capable of handling all of my use cases. The point is that not everyone is familiar with the Debian infrastructure, and people will give up if they have to look too hard. For example, I hadn't discovered dh_make; it's not in http://wiki.debian.org/IntroDebianPackaging From: Wouter Verhelst > Put otherwise, going to one distribution and saying "you guys are doing > it all wrong, look at how $OTHER distribution is doing it, you should do > it their way!!1!" isn't very convincing. I was hoping the focus would not be on the fact that I mentioned a specific other distro. Is that why people are so hostile? >That's a misconception. The "hello" package shows how to build a Debian >package *without using any helper programs*. Almost nobody ever does >that anymore; I'm not sure why that package still exists. Then remove it. >If you want an >example for how to really do things in practice, you should look at >hello-debhelper. Its debian/rules and debian/rules-dh files are much >simpler. >From my experience at looking at debian/rules for packages I've tried to patch or upgrade, 'hello' is more typical than 'hello-debhelper'. Perhaps Debian should automatically file a bunch of bugs against packages with overly-complicated debian/rules? Or add a lintian warning or something. >dpkg-scansources ... dpkg-scanpackages Good to know, but it's still more complicated than shipping ebuilds. >all you need to do is ship the debian/ directory. This Just Works(TM). Not with dpkg-buildpackage, which everything I read seemed to indicate was the preferred way. >- Run "apt-get -d source package", fetch the new upstream source, run >"uupdate" with the right arguments (read the manpage for the details). >Unless it's something very complex, that will almost certainly work. Good to know. Not obvious at all. Of course, for a distressing number of packages, .orig.tar.gz is a repack, not the upstream's vanilla tarball. Would that make uupdate fail? >If, OTOH, it *is* something very complex, then this... >... won't work either. Granted. From: Philip Hands >the deep joy of having >users who patch packages into a state of uselessness, and then report >bugs against the result without mentioning that they broke the package >themselves. > >If those that expect to be able to do this sort of thing without >consulting any documentation I'm not saying I expect to read no documentation. I'm saying that the documentation I read was not intuitive. And I'm certainly not stupid enough to expect support for something I broke on my own. I have enough of that from trying to support my own software. But the fact is: software as packaged by Debian *is* buggy and sometimes needs to be patched. Sometimes the bug is in the upstream version; sometimes it is in the Debian patches. From: "Bernhard R. Link" >> - Because of the above, debian/rules tries to know about backwards steps. >What are "backwards steps"? The clean and unpatch targets Doing these manually is just asking for trouble, and you can't depend on the upstream makefile either. In Gentoo, 'ebuild foo-1.ebuild clean' just does rm -r /var/tmp/whatever/, and there is no explicit way to unpatch - just clean and extract without patching (ebuild foo-1.ebuild unpack for no patching; ebuild foo-1.ebuild prepare to also patch) >> - There are too many arcane commands that have to be called. >./debian/rules build >fakeroot ./debian/rules binary > >Everything else is mostly convenience wrappers. I was also talking about the
GSoC/debian.org SIP/XMPP infrastructure
Several students have inquired about the possibility of doing a real-time communication (RTC) project for GSoC, one has already started his application[1] and a few others have been corresponding with me by email. Rather than letting the students guess what we need or want, I'm hoping some people might be keen to suggest requirements or challenges for this to go ahead. It could be used to develop some solutions for debian.org, debian.net and/or alioth users There are some discussion points on my blog[2] but they are only the most essential points. I'm sure there are more innovative ideas that will come from some of the students or the community - please feel free to suggest things I'd also be keen to know how different teams (e.g. DSA) would want to interact with students proposing such projects, as it is inevitable that this would involve some server resources and technical changes. 1. http://wiki.debian.org/SummerOfCode2013/StudentApplications 2. http://danielpocock.com/an-rtc-infrastructure-for-debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/517acb4e.5080...@pocock.com.au
Re: Bug#706160: general: it should be easier for ordinary developers to work with Debian packages
On Fri, Apr 26, 2013 at 02:20:53PM +0200, Carlos Alberto Lopez Perez wrote: > dh_make -f ../foo-1.tar.gz > dpkg-buildpackage I think one valid point the OP makes which each of these suggestions — in isolation — seem to miss, is there are *too many ways to do it*. The suggestions you (and others) make are great, but how discoverable are they to a newbie packager? Conversely, how (non-)discoverable are the myriad bad ways to do things (the hello package is a good example of this.) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130426140452.GA18128@debian
Re: [Debian-med-packaging] Question about proper archive area for packages that require big data for operation
Dear FTP Masters! On 23/04/13 15:13, Benjamin Drung wrote: [...] > You can use xz for the source and binary package to reduce the size. The > default compression level for xz reduces the size of the source tarball > from 415 MB to 272 MB: > > $ ls -1s --si metastudent-data_1.0.0.tar* > 823M metastudent-data_1.0.0.tar > 381M metastudent-data_1.0.0.tar.bz2 > 415M metastudent-data_1.0.0.tar.gz > 272M metastudent-data_1.0.0.tar.xz > $ ls -1sh metastudent-data_1.0.0.tar* > 784M metastudent-data_1.0.0.tar > 363M metastudent-data_1.0.0.tar.bz2 > 396M metastudent-data_1.0.0.tar.gz > 259M metastudent-data_1.0.0.tar.xz Following Benjamin's suggestion and the data.debian.org document [1], we have prepared a 'metastudent-data' arch:all package that is ~130MB (xz compressed). The package builds required architecture dependent databases in the postinst script. The purpose of this is to save space in the archive that each architecture dependent version would take up. The arch:all package is almost identical to the source package. * Please comment on this solution. If you like it, we will upload it (targeting the 'main' area), and have 'metastudent' (also in main) depend on it. [1] http://ftp-master.debian.org/wiki/projects/data/ Thank you for commenting. Best regards, Laszlo -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/517a7f67.3070...@rostlab.org
Re: Bug#602034: jpeg8 vs jpeg-turbo
On Fri, Apr 26, 2013 at 02:27:47PM +0200, Adam Borowski wrote: > > > It boils down to "jpeg6-2 is the only important thing. Forget about > > > jpeg8 and jpeg9, which bring incompatible changes". > > There are other features in newer libjpeg that packages do need, even > > when not using exotic JPEG-like formats. For instance, ioquake3 uses the > > jpeg_mem_src() (ability to load JPEGs from a memory buffer, not just > > from a file on disk) and previously carried it as a local patch to its > > embeddded copy of IJG jpeg6b. (It now embeds IJG jpeg8c instead, and is > > built against the system libjpeg8-dev in Debian.) > > > > I believe that means that ioquake3 can be built unpatched against either > > IJG libjpeg8 or a sufficiently new libjpeg-turbo, but not against IJG > ^ > > libjpeg6b (although if there was libjpeg6b2 release with jpeg_mem_src(), > > I think that'd also work). > > If it works with libjpeg-turbo, what's the problem? That was an answer to a different statement. -- WBR, wRAR -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130426130626.ga23...@belkar.wrar.name
Re: Bug#602034: jpeg8 vs jpeg-turbo
On Fri, Apr 26, 2013 at 12:29:27PM +0100, Simon McVittie wrote: > On 25/04/13 20:39, Pau Garcia i Quiles wrote: > > It boils down to "jpeg6-2 is the only important thing. Forget about > > jpeg8 and jpeg9, which bring incompatible changes". > > There are other features in newer libjpeg that packages do need, even > when not using exotic JPEG-like formats. For instance, ioquake3 uses the > jpeg_mem_src() (ability to load JPEGs from a memory buffer, not just > from a file on disk) and previously carried it as a local patch to its > embeddded copy of IJG jpeg6b. (It now embeds IJG jpeg8c instead, and is > built against the system libjpeg8-dev in Debian.) > > I believe that means that ioquake3 can be built unpatched against either > IJG libjpeg8 or a sufficiently new libjpeg-turbo, but not against IJG ^ > libjpeg6b (although if there was libjpeg6b2 release with jpeg_mem_src(), > I think that'd also work). If it works with libjpeg-turbo, what's the problem? -- ᛊᚨᚾᛁᛏᚣ᛫ᛁᛊ᛫ᚠᛟᚱ᛫ᚦᛖ᛫ᚹᛖᚨᚲ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130426122747.ga7...@angband.pl
Re: Bug#706160: general: it should be easier for ordinary developers to work with Debian packages
On 25/04/13 19:18, Wouter Verhelst wrote: >> Gentoo: >> > - vim foo-1.ebuild; ebuild foo-1.ebuild manifest; emerge foo >> > - That may look like oversimplification, but the contents of >> > foo-1.ebuild really are very simple. > By that rationale, building a Debian package simply requires "mkdir > debian; vim debian/rules; vim debian/control; dch --create; touch > debian/copyright; dpkg-buildpackage". The contents of debian/rules and > debian/control is really simple, dch helps you when creating a > changelog, and an *empty* debian/copyright file is syntactically valid > (though not semantically, of course). > This can be even more simple: dh_make -f ../foo-1.tar.gz dpkg-buildpackage signature.asc Description: OpenPGP digital signature
Re: Bug#602034: jpeg8 vs jpeg-turbo
On Fri, 2013-04-26 at 12:29 +0100, Simon McVittie wrote: > On 25/04/13 20:39, Pau Garcia i Quiles wrote: > > It boils down to "jpeg6-2 is the only important thing. Forget about > > jpeg8 and jpeg9, which bring incompatible changes". > > There are other features in newer libjpeg that packages do need, even > when not using exotic JPEG-like formats. For instance, ioquake3 uses the > jpeg_mem_src() (ability to load JPEGs from a memory buffer, not just > from a file on disk) [...] That seems to be a pretty simple convenience function which could easily be added in either libjpeg-turbo or the applications that want it. Ben. -- Ben Hutchings Klipstein's 4th Law of Prototyping and Production: A fail-safe circuit will destroy others. signature.asc Description: This is a digitally signed message part
Re: Bug#602034: jpeg8 vs jpeg-turbo
On 25/04/13 20:39, Pau Garcia i Quiles wrote: > It boils down to "jpeg6-2 is the only important thing. Forget about > jpeg8 and jpeg9, which bring incompatible changes". There are other features in newer libjpeg that packages do need, even when not using exotic JPEG-like formats. For instance, ioquake3 uses the jpeg_mem_src() (ability to load JPEGs from a memory buffer, not just from a file on disk) and previously carried it as a local patch to its embeddded copy of IJG jpeg6b. (It now embeds IJG jpeg8c instead, and is built against the system libjpeg8-dev in Debian.) I believe that means that ioquake3 can be built unpatched against either IJG libjpeg8 or a sufficiently new libjpeg-turbo, but not against IJG libjpeg6b (although if there was libjpeg6b2 release with jpeg_mem_src(), I think that'd also work). S -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/517a6517.5080...@debian.org
Re: Bug#602034: jpeg8 vs jpeg-turbo
Hi all, On Do 25 Apr 2013 22:29:53 CEST Michael Biebl wrote: Am 25.04.2013 20:49, schrieb Mike Gabriel: Can this be a proposal? Package libjpeg and libjpeg-turbo using an alternatives setup and thus, making both libs installable in parallel. Packagers can then build-depend on one or the other libjpeg implementations. Please no. If libjpeg-turbo is the saner implementation, which reading through the messages posted so far it seems like, let's switch to it fully. +1 from me, as well. I have been using the drop-in replacement packages that we provide via the upstream X2Go Debian-compatible package archive for months now and have not found any restraints, so far. How can a consensus on this issue be reached? Mike -- DAS-NETZWERKTEAM mike gabriel, rothenstein 5, 24214 neudorf-bornstein fon: +49 (1520) 1976 148 GnuPG Key ID 0x25771B31 mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb pgpchqwWbU3L9.pgp Description: Digitale PGP-Unterschrift
Bug#706204: ITP: sgabios -- A bios option rom to provide legacy serial console for x86
Package: wnpp Severity: wishlist Owner: Daniel Beyer * Package name: sgabios Version : 2010.04.22 Upstream Author : Nathan Laredo * URL : https://code.google.com/p/sgabios/ * License : Apache-2.0 Programming Lang: C Description : A bios option rom to provide legacy serial console for x86 The Google Serial Graphics Adapter BIOS or SGABIOS provides a means for legacy x86 software to communicate with an attached serial console as if a video card were attached. SGABIOS is designed to be inserted into a BIOS as an option rom to provide over a serial port the display and input capabilities normally handled by a VGA adapter and a keyboard. SGABIOS can be used to feature OS independent serial console redirection in Qemu. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130426094109.22381.75148.reportbug@d1-t20.cluster
Re: GSoC project: fedmsg for the Debian infrastructure
Hi. Daniel Pocock writes: > > Red Hat promotes a number of messaging solutions, I've used several of > these things commercially - they publish a very interesting roadmap[1]: > - - HornetQ "new ultra high performance enterprise grade messaging" > - - MRG Messaging (based on Qpid) "Exploits Linux-specific optimizations > for performance" > - - Fuse MQ (based on ActiveMQ) > - - JBoss XQ Messaging > > and I'm surprised that they ruled them all out and went for ZeroMQ > > OpenStack is working with RabbitMQ, it is based on a broker paradigm too > > My own feeling is that brokers do scale to some extent: if reliable > delivery is a requirement, then you just have to buy the right > hardware to run the broker at scale. > I'm not at all an expert in Message Queuing middleware, but I noticed that Aapache Allura [0], the infrastructure running SF.net/SourceForge (or at least, part of it), seems to have been built around a similar architecture. Maybe there's interesting feedback to draw from there, in addition to FedMsg in Fedora. Hope this helps. Best regards, [0] http://sourceforge.net/p/allura/wiki/ -- Olivier BERGER http://www-public.telecom-sudparis.eu/~berger_o/ - OpenPGP-Id: 2048R/5819D7E8 Ingenieur Recherche - Dept INF Institut Mines-Telecom, Telecom SudParis, Evry (France) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87fvydk6qa@inf-8657.int-evry.fr
Re: [Soc-coordination] GSoC project: fedmsg for the Debian infrastructure
This one time, at band camp, Simon Chopin said: > Quoting Stephen Gran (2013-04-25 21:17:29) > > This one time, at band camp, Simon Chopin said: > > > The thing itself is based on the ZeroMQ protocol. > > > > One of the principles, up to now, of system design for the debian.org > > infrastructure has been that it can tolerate single nodes being off line > > for periods of time. My understanding of ZeroMQ is that it doesn't do > > very well when the sender and the receiver aren't on line at the same > > time. I have not used ZeroMQ in any serious way, so I'm only repeating > > what I've heard. Please correct me if I'm wrong. > > Well, as I understand it, when sender or receiver are not online, there > is simply no message passing. If your concern is about what happens to > the backlog when the consumer comes back online, then I've already > written about that earlier today :-) OK, that's fairly straight forward, then. I'm not convinced yet that this is going to work out as a debian.org service. But, that being said, I think we need something like this, and no one else appears to be working on it at the moment. Go on and make it easily installable and make people interested in it. If there are architectural problems we can't live with for our needs, we'll still benefit from your work. Thanks for doing this. Cheers, -- - | ,''`.Stephen Gran | | : :' :sg...@debian.org | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
