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
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
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
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.
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 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
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, 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
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 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
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
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
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: 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(
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: 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
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
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
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
* 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 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
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 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 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 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 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
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: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
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 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
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
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
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
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
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
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
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
+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.
>
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
❦ 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
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
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
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 | \
>
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 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
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 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
47 matches
Mail list logo
