On Wed, Apr 24, 2013 at 03:19:59PM +0200, Bill Allombert wrote:
> As IJG libjpeg maintainer, my plan is to move to libjpeg9 which has more
> feature.
Only the applications that actually want to experiment with libjpeg8/9 ABI
should be using it -
The 100% of current applications that work just l
On Wed, Apr 24, 2013 at 03:11:53PM -0700, Russ Allbery wrote:
> >> We have a plenty of libraries (and other packages) who do conflict
> >> between themselves, so we know the drill.
> >>
> >> Also Debian no longer ships libjpeg62, so there's not conflict there
> >> at least for baseline implementati
On 23/04/2013 23:15, Thorsten Glaser wrote:
> Joachim Breitner debian.org> writes:
>
>> The (luxury) problem is that I got used to it and began uploading the
>> new (and NEW) dependency bar of package foo along with the new version
>> of foo (instead of uploading bar first, wait for NEW processin
Le Wed, Apr 24, 2013 at 01:52:36PM -0400, Neil McGovern a écrit :
>
> 1: deliberate obfuscation for no benefit:
Hi everybody,
Can everybody please avoid to guess or propagate guesses on other persons
motivations ?
I think that a discussion can not be constructive if it contains statements
that
On 04/25/2013 01:52 AM, Neil McGovern wrote:
> Perhaps you should go read the bug report first. As you seem to be
> unwilling to actually do research, I'll include the relevant section for
> your benefit:
> -
> 1: deliberate obfuscation for no benefit:
> echo .nr g 2 | cat - cpio.1 | \
>
Package: wnpp
Severity: wishlist
Owner: Thomas Bechtold
* Package name: libgit2-glib
Version : 0.0.2
Upstream Author : Ignacio Casal Quinteiro
* URL : http://ftp.gnome.org/pub/GNOME/sources/libgit2-glib
* License : LGPL
Programming Lang: C
Description
Vincent Bernat writes:
> ❦ 24 avril 2013 13:08 CEST, Ondřej Surý :
>> We have a plenty of libraries (and other packages) who do conflict
>> between themselves, so we know the drill.
>>
>> Also Debian no longer ships libjpeg62, so there's not conflict there
>> at least for baseline implementatio
❦ 24 avril 2013 13:08 CEST, Ondřej Surý :
> We have a plenty of libraries (and other packages) who do conflict
> between themselves, so we know the drill.
>
> Also Debian no longer ships libjpeg62, so there's not conflict there
> at least for baseline implementation (libjpeg62 API/ABI). Remember
Hi Alexandre,
Am Dienstag, den 23.04.2013, 20:09 -0300 schrieb Alexandre Dantas:
> Package: wnpp
> Severity: wishlist
> Owner: Alexandre Dantas
>
>
> * Package name: nsnake
> Version : 1.6
> Upstream Author : Alexandre Dantas
> * URL : http://www.alexdantas.net/proj
+1 to everything Guillem said. I particularly want to emphasize this
part:
Guillem Jover writes:
> On Sat, 2013-04-20 at 11:05:29 -0700, Clint Byrum wrote:
>> Where Debian's efforts should be focused is on things like license
>> verification and helping bug reports and fixes get to upstream.
>
Lars Wirzenius writes:
> On Wed, Apr 24, 2013 at 12:05:30PM -0700, Russ Allbery wrote:
>> For the record, I completely disagree with this packaging advice. Why
>> carry an upstream patch when you can handle this easily during build
>> time?
> As much as I dislike quilt, at least it makes it eas
Hi!
On Sat, 2013-04-20 at 11:05:29 -0700, Clint Byrum wrote:
> [...]. IMO this is why upstream packaging should be
> embraced and enhanced rather than focusing on dpkg.
I'm not sure if you refer to the tool here, or to the packaging work,
doesn't change much anyway.
> I once worked on the 'pkgme
On Wed, Apr 24, 2013 at 12:05:30PM -0700, Russ Allbery wrote:
> For the record, I completely disagree with this packaging advice. Why
> carry an upstream patch when you can handle this easily during build time?
As much as I dislike quilt, at least it makes it easy to see what
change Debian is mak
Neil McGovern writes:
> Perhaps you should go read the bug report first. As you seem to be
> unwilling to actually do research, I'll include the relevant section for
> your benefit:
> -
> 1: deliberate obfuscation for no benefit:
> echo .nr g 2 | cat - cpio.1 | \
> gzip -n9 >debi
Neil McGovern writes:
> On Wed, Apr 24, 2013 at 11:19:48PM +0800, Thomas Goirand wrote:
>> If you are scared by "echo x | cat - y", that it prevents you from
>> understanding the rules files, then you shouldn't touch the package
>> anyway.
> If you're deliberately obfuscating debian/rules when t
Hi!
On Mon, 2013-04-22 at 09:38:14 +, Thorsten Glaser wrote:
> Adam Borowski angband.pl> writes:
> > It can be done
>
> Well yes, but if you do even small things such as generate the
> package manually instead of using debhelper, prepare to be shouted
> at by the British Cabal with threats o
Thomas Goirand writes:
> Agreed. Especially when I see that this:
> echo .nr g 2 | cat - cpio.1 | \
> gzip -n9 >debian/pax/usr/share/man/man1/paxcpio.1.gz
> is called "obfuscation", then doom it as unacceptable for the archive.
I'm generally in favor of using standardized packaging
On Thu, Apr 25, 2013 at 01:25:00AM +0800, Thomas Goirand wrote:
> On 04/25/2013 12:10 AM, Neil McGovern wrote:
> > If you're deliberately obfuscating debian/rules when there's no or very
> > little advantage, then you shouldn't be producing the package.
> I'm not the one claiming that using echo an
On 04/25/2013 12:10 AM, Neil McGovern wrote:
> If you're deliberately obfuscating debian/rules when there's no or very
> little advantage, then you shouldn't be producing the package.
I'm not the one claiming that using echo and cat is obfuscation!
Thomas
--
To UNSUBSCRIBE, email to debian-deve
On Wed, Apr 24, 2013 at 11:19:48PM +0800, Thomas Goirand wrote:
> On 04/24/2013 10:39 PM, Neil McGovern wrote:
> > I'm sorry, but can I just clarify: do you think that it's an advantage
> > that your custom debian/rules prevents others from understanding your
> > package?
> >
> I don't think anyone
Hello Simon!
Thank you for these suggestions.
On 24/04/13 13:06, Simon McVittie wrote:
> On 23/04/13 10:48, Laszlo Kajan wrote:
>> free packages that depend on big (e.g. >400MB) free data outside 'main'
>
> This comes up in the Games Team, too.
>
> Here are some possibilities you might not have
On Wed, Apr 24, 2013 at 11:12:33PM +0800, Thomas Goirand wrote:
> Just being curious... Is the -turbo called this was because it's faster?
> How much faster is it then?
Hi, Thomas,
The very first hit on the duckduckgo.com search engine for search
expression "libjpeg-turbo" (not including the quot
On 04/24/2013 10:39 PM, Neil McGovern wrote:
> I'm sorry, but can I just clarify: do you think that it's an advantage
> that your custom debian/rules prevents others from understanding your
> package?
>
> Neil
I don't think anyone ever wrote that. Jakub was quite clear, IMO.
If you are scared by "
On 04/24/2013 05:23 PM, Ondřej Surý wrote:
> Hi Bill and Debian Developers,
>
> while doing work on GD Library 2.1.0 it was discovered there's
> encoding incompatibility introduced by libjpeg8/9 [1]. While doing
> further research I have found that Fedora has switched to
> libjpeg-turbo[2] (for rea
On Wed, Apr 24, 2013 at 05:01:50PM +0300, Riku Voipio wrote:
> Libjpeg-turbo website [3] has all the signs of an healthy open source
> project - A SVN repo with many commiters, bug tracker, a mailing list
> with open discussion etc.
libjpeg-turbo is also used by webkit, blink, and gecko.
Mike
-
On Wed, Apr 24, 2013 at 04:25:42PM +0200, Jakub Wilk wrote:
> * Timo Juhani Lindfors , 2013-04-22, 13:22:
> >>Thorsten, you should have kept your custom debian/rules. If it
> >>prevented incompetent developers from NMUing the package, then
> >>all good for you and for Debian.
> >Was there perhaps s
On 04/24/2013 04:02 PM, Laszlo Kajan wrote:
> Hello Didier!
>
> On 24/04/13 09:32, Didier 'OdyX' Raboud wrote:
>> Le mardi, 23 avril 2013 12.23:23, Andreas Tille a écrit :
>>> I would even go that far that it might make sense to package these data
>>> and upload it to demonstrate that we should *r
* Timo Juhani Lindfors , 2013-04-22, 13:22:
Thorsten, you should have kept your custom debian/rules. If it
prevented incompetent developers from NMUing the package, then all
good for you and for Debian.
Was there perhaps some emoticon missing?
Sorry, yes, this one:
:/
Uncommon debian/rules s
On Wed, Apr 24, 2013 at 01:48:48PM +0200, Mike Gabriel wrote:
> >C. Decide which package should provide default libjpeg-dev library
> Last statement from Bill: libjpeg by IJG
The current IJG has nothing to do with the IJG that originally created JPEG.
The last activity of original IJG was in 19
On Wed, Apr 24, 2013 at 9:19 PM, Bill Allombert
wrote:
> On Wed, Apr 24, 2013 at 11:23:04AM +0200, Ondřej Surý wrote:
>> Hi Bill and Debian Developers,
>>
>> My proposal is:
>> A. Add libjpeg-turbo to Debian archive (that's easy)
>> B. Add required provides/alternatives for libjpeg62-dev and
>> li
Hello Didier!
On 24/04/13 09:32, Didier 'OdyX' Raboud wrote:
> Le mardi, 23 avril 2013 12.23:23, Andreas Tille a écrit :
>> I would even go that far that it might make sense to package these data
>> and upload it to demonstrate that we should *really* create a solution
>> for such cases if they wi
Package: wnpp
Severity: wishlist
Owner: Franck Routier
* Package name: base91
Version : 0.6.0
Upstream Author : Joachim Henke
* URL : http://base91.sourceforge.net/
* License : BSD
Programming Lang: C
Description : base91 encoder/decoder
basE91 is an
Hi Olivier!
On 24/04/13 08:20, Olivier Sallou wrote:
>
> On 04/23/2013 11:48 AM, Laszlo Kajan wrote:
>> Dear Russ, Debian Med Team, Charles!
>>
>> (Please keep Tobias Hamp in replies.)
>>
>> @Russ: Please allow me to include you in a discussion about a few
>> bioinformatics packages that depend
Package: wnpp
Severity: wishlist
Owner: Alexandre Dantas
* Package name: yetris
Version : 1.6
Upstream Author : Alexandre Dantas
* URL : http://www.alexdantas.net/projects/yetris/
* License : GPL3
Programming Lang: C
Description : customizable Tetris(
On Wed, Apr 24, 2013 at 11:23:04AM +0200, Ondřej Surý wrote:
> Hi Bill and Debian Developers,
>
> My proposal is:
> A. Add libjpeg-turbo to Debian archive (that's easy)
> B. Add required provides/alternatives for libjpeg62-dev and
> libjpeg8-dev (where API/ABI match)
> C. Decide which package shou
Package: wnpp
Severity: wishlist
Owner: "HIGUCHI Daisuke (VDR dai)"
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
* Package name: ruby-memoize
Version : 1.3.1
Upstream Author : Daniel J. Berger
* URL : http://www.rubyforge.org/projects/shards
* License : Ar
Hi Ondřej,
I have just uploaded libjpeg-turbo to Debian and it still hovers in NEW [1].
On Mi 24 Apr 2013 11:23:04 CEST Ondřej Surý wrote:
Debian has already open ITP[3] #602034 for libjpeg-turbo, which
support libjpeg62 API/ABI and also some important bits of libjpeg8. As
libjpeg is one of th
On 04/22/2013 06:09 PM, Jakub Wilk wrote:
> #690381
Gosh, what a shocking thread...
I didn't read until end, but nearly at half of it, it felt bad already.
> Thorsten, you should have kept your custom debian/rules. If it
> prevented incompetent developers from NMUing the package, then all
> good
Package: wnpp
Severity: wishlist
* Package name: sqlworkbenchj
Version : 114
Upstream Author : Thomas Kellerer
* URL : http://www.sql-workbench.net
* License : Apache License, Version 2.0
Programming Lang: Java
Description : A free, DBMS-independent, cr
On Wed, 24 Apr 2013 15:30:46 +0600, Andrey Rahmatullin wrote:
> On Wed, Apr 24, 2013 at 11:23:04AM +0200, Ondřej Surý wrote:
> > A. Add libjpeg-turbo to Debian archive (that's easy)
> Not really (especially if you want it to ship libjpeg.so.* too).
We have a plenty of libraries (and other packages
On 23/04/13 10:48, Laszlo Kajan wrote:
> free packages that depend on big (e.g. >400MB) free data outside 'main'
This comes up in the Games Team, too.
Here are some possibilities you might not have considered:
* Package a small "demo" data-set (enough to test that the package is
working correc
On Wed, Apr 24, 2013 at 11:23:04AM +0200, Ondřej Surý wrote:
> A. Add libjpeg-turbo to Debian archive (that's easy)
Not really (especially if you want it to ship libjpeg.so.* too).
--
WBR, wRAR
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Tr
Hi Bill and Debian Developers,
while doing work on GD Library 2.1.0 it was discovered there's
encoding incompatibility introduced by libjpeg8/9 [1]. While doing
further research I have found that Fedora has switched to
libjpeg-turbo[2] (for reasoning please read the referred email).
Ubuntu (and St
On Mon, Apr 22, 2013 at 09:38:14AM +, Thorsten Glaser wrote:
> Well yes, but if you do even small things such as generate the
> package manually instead of using debhelper, prepare to be shouted
> at by the British Cabal with threats of using superpowers to remove
> such packages from Debian.
On Wed, Apr 24, 2013 at 09:32:52AM +0200, Didier 'OdyX' Raboud wrote:
> Le mardi, 23 avril 2013 12.23:23, Andreas Tille a écrit :
> > I would even go that far that it might make sense to package these data
> > and upload it to demonstrate that we should *really* create a solution
> > for such cases
Le mardi, 23 avril 2013 12.23:23, Andreas Tille a écrit :
> I would even go that far that it might make sense to package these data
> and upload it to demonstrate that we should *really* create a solution
> for such cases if they will increase in the number and size of data
> packages.
Isn't that
Olivier Sallou writes:
> Indeed, many bioinformatics programs relies on external data. But I am afraid
> that if we start to add some data packages, we will open an endless open
> door BioInformatics datasets are large, and becoming huge and numerous.
> This size will be an issue for Debian mi
47 matches
Mail list logo
