Processed: Re: Bug#705982: Wireless connection drops and will NOT re-connect -- Debian/Wheezy RC1 64 bit

[Debian Bug Tracking System]

Processing control commands:

> reassign -1 general
Bug #705982 [unknown] Wireless connection drops and will NOT re-connect -- 
Debian/Wheezy RC1 64 bit
Warning: Unknown package 'unknown'
Bug reassigned from package 'unknown' to 'general'.
Ignoring request to alter found versions of bug #705982 to the same values 
previously set
Ignoring request to alter fixed versions of bug #705982 to the same values 
previously set

-- 
705982: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=705982
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems


--
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/handler.s.b705982.136670895332276.transcr...@bugs.debian.org

Question about proper archive area for packages that require big data for operation

[Laszlo Kajan]

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 on big, but free data [2]. I have cited
your opinion [3] in this discussion before. You are on the technical committee 
and on the policy team, so you, together with Charles, can help
substantially here.

[2] 
http://lists.alioth.debian.org/pipermail/debian-med-packaging/2013-April/thread.html
[3] https://lists.debian.org/debian-vote/2013/03/msg00279.html

This email is to continue the discussion about free packages that depend on big 
(e.g. >400MB) free data outside 'main'. These packages
apparently violate policy 2.2.1 [0] for inclusion in 'main' because they 
require software outside the 'main' area to function. They do not
violate point #1 of the social contract [1], which requires non-dependency on 
non-free components. For these big data packages, policy seems to
be overly restrictive compared to the social contract, leading to seemingly 
unfounded rejection from 'main'.

[0] http://www.debian.org/doc/debian-policy/ch-archive.html
[1] http://www.debian.org/social_contract

* In case the social contract indeed allows such packages to be in 'main' (and 
policy is overly restrictive), how could it be ensured that the
packages are accepted?

* What is the procedure within Debian to elicit a decision about the handling 
of such packages in terms of archive area? Discussion on d-devel,
followed by policy change? Asking the policy team to clarify policy for such 
packages? Technical committee?

 + Charles suggested such packages could go into 'main' [4], with a clear 
indication of the large data dependency of the package in the long
description.
   When possible, providing the scripts for generating the large data as well.

 [4] 
http://lists.alioth.debian.org/pipermail/debian-med-packaging/2013-April/019292.html

My goal as a Debian Developer and a packager is to get packages into Debian (so 
'main') that are allowed in there, in reasonably short time. I
would like to resolve this issue properly, because I believe it may pop up more 
often in bioinformatics software. For example, imagine a protein
folding tool that would require a very large database to search for homologues 
for contact prediction, and using the contacts it would predict
protein three-dimensional structure. This has been done before [5], and such a 
tool would be (is) immensely useful for bioinformatics. This tool
would depend on gigabytes of data we would not package. Yet, by all means, I 
would want the tool to be part of the distribution.

[5] http://www.plosone.org/article/info%3Adoi%2F10.1371%2Fjournal.pone.0028766

Thank you for your opinion and advice.

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/517658d5.9040...@debian.org

Re: Question about proper archive area for packages that require big data for operation

[Andreas Tille]

On Tue, Apr 23, 2013 at 11:48:05AM +0200, Laszlo Kajan wrote:
> 
> This email is to continue the discussion about free packages that depend on 
> big (e.g. >400MB) free data outside 'main'.

In your practical case is this data say <500MB?  Are we talking about
compressed or uncompressed data (= >400MB on users harddisk or on all
Debian mirrors world-wide)?

We do actually have examples of >500MB binary packages:

udd@ullmann:/srv/mirrors/debian$ find . -type f -size +500M -name "*.deb"
./pool/main/f/freefoam/freefoam-dev-doc_0.1.0+dfsg-1_all.deb
./pool/main/libr/libreoffice/libreoffice-dbg_4.0.3~rc1-3_amd64.deb
./pool/main/libr/libreoffice/libreoffice-dbg_4.0.3~rc1-3_kfreebsd-amd64.deb
./pool/main/libr/libreoffice/libreoffice-dbg_4.0.3~rc1-2_amd64.deb
./pool/main/libr/libreoffice/libreoffice-dbg_4.0.3~rc1-2_kfreebsd-amd64.deb
./pool/main/n/ns3/ns3-doc_3.16+dfsg1-1_all.deb
./pool/main/n/ns3/ns3-doc_3.15+dfsg-1_all.deb
./pool/main/w/webkitgtk/libwebkit2gtk-3.0-0-dbg_1.11.91-1_amd64.deb
./pool/non-free/r/redeclipse-data/redeclipse-data_1.4-1_all.deb

Even if the topic should be clarified in general because we will
certainly have larger data sets than this in the future I could imagine
that packaging this very data in your case should not be the main
problem under the current circumstances as long there is no better
solution found.

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.

Kind regards

   Andreas.

-- 
http://fam-tille.de


-- 
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/20130423102323.ge31...@an3as.eu

Re: Derivatives, MongoDB and freezes

[Neil McGovern]

On Mon, Apr 22, 2013 at 11:58:33PM -0700, Jonathan Nieder wrote:
> Steve Langasek wrote:
> > But for new packages, where Canonical is striking out on its own
> > to deliver significant new functionality and the folks working on these
> > packages are not DDs, there's a clear pragmatic argument for doing the work
> > directly in Ubuntu rather than blocking the work on finding folks able to
> > upload to Debian and willing to maintain the packages there.
> 
> To be a devil's advocate: when the Debian Developers that a company
> has been able to contact (inside or outside the company) do not
> consider a package to be ready for upload, it is not hard to
> contribute the packaging to Debian in an RFP bug to avoid duplication
> of effort.
> 

Indeed, this answers the first point, but the second is more significant
- willing to maintian the packages there.

Neil
-- 


signature.asc
Description: Digital signature

Re: [Debian-med-packaging] Question about proper archive area for packages that require big data for operation

[Laszlo Kajan]

Hello Andreas!

On 23/04/13 12:23, Andreas Tille wrote:
> On Tue, Apr 23, 2013 at 11:48:05AM +0200, Laszlo Kajan wrote:
>>
>> This email is to continue the discussion about free packages that depend on 
>> big (e.g. >400MB) free data outside 'main'.
> 
> In your practical case is this data say <500MB?  Are we talking about
> compressed or uncompressed data (= >400MB on users harddisk or on all
> Debian mirrors world-wide)?

It is around 404MB, gzip compressed [1]. I think it is not arch independent. I 
think BLAST databases (the main bulk in the tar.gz) are sensitive
to the size of int, and endian-ness.

[1] ftp://rostlab.org/metastudent/metastudent-data_1.0.0.tar.gz

> We do actually have examples of >500MB binary packages:
> 
> udd@ullmann:/srv/mirrors/debian$ find . -type f -size +500M -name "*.deb"
> ./pool/main/f/freefoam/freefoam-dev-doc_0.1.0+dfsg-1_all.deb
> ./pool/main/libr/libreoffice/libreoffice-dbg_4.0.3~rc1-3_amd64.deb
> ./pool/main/libr/libreoffice/libreoffice-dbg_4.0.3~rc1-3_kfreebsd-amd64.deb
> ./pool/main/libr/libreoffice/libreoffice-dbg_4.0.3~rc1-2_amd64.deb
> ./pool/main/libr/libreoffice/libreoffice-dbg_4.0.3~rc1-2_kfreebsd-amd64.deb
> ./pool/main/n/ns3/ns3-doc_3.16+dfsg1-1_all.deb
> ./pool/main/n/ns3/ns3-doc_3.15+dfsg-1_all.deb
> ./pool/main/w/webkitgtk/libwebkit2gtk-3.0-0-dbg_1.11.91-1_amd64.deb
> ./pool/non-free/r/redeclipse-data/redeclipse-data_1.4-1_all.deb
> 
> Even if the topic should be clarified in general because we will
> certainly have larger data sets than this in the future I could imagine
> that packaging this very data in your case should not be the main
> problem under the current circumstances as long there is no better
> solution found.
> 
> 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.

All right, we will package and upload the big data in case no one thinks of a 
better solution and discussion dies in, say, a week.

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/517675d3.3030...@rostlab.org

Re: R 3.0.0 and required rebuilds of all reverse Depends: of R

[Goswin von Brederlow]

On Fri, Apr 19, 2013 at 12:16:11PM +0300, Niko Tyni wrote:
> On Thu, Apr 18, 2013 at 10:56:34AM +0200, Goswin von Brederlow wrote:
> > On Tue, Apr 02, 2013 at 02:28:23PM -0700, Russ Allbery wrote:
> > > Niko Tyni  writes:
> > > 
> > > > FWIW, I've done ABI-incompatible uploads of perl to experimental in the
> > > > past without changing the perlapi-* virtual package name or the libperl
> > > > SONAME.  The aim was to experiment with different configuration options,
> > > > particularly 64-bit integers and 128-bit long doubles.
> > > 
> > > > I certainly didn't support upgrades from those versions to the same
> > > > extent as I'd have done for unstable. OTOH, the packages were pretty
> > > > close to uninstallable on any non-minimal systems anyway, as we didn't
> > > > offer corresponding rebuilt XS modules in experimental.
> > > 
> > > Oh, that's a good point.  Yes, I hadn't thought about that specific case
> > > for testing ABI breakage in experimental.
> > 
> > But then that simply is a broken upload. It will break horribly if you
> > install the experimental perl but keep other perl packages from sid.
> 
> Well, it wasn't installable with perl packages in sid at the time due to a
> major version upgrade, which is why I was experimenting with incompatible
> ABI changes in the first place. (This was around perl/5.12.0-1 or so.)

That was OK then. Just in general one should think about such things.

Note: This isn't an attack of you or that upload. You/perl just have
the horrible luck of being used as an example.
 
> > You should have set the perlapi-* to include -experimental or
> > something to make it differ from sid. Having the perlapi-* provides
> > and depends makes this simple.
> 
> First, this was against the policy at the time (since fixed with
> #579457.) Second, the ABI changes would also have required an extra
> libperl SONAME change with the implied NEW processing. That's
> too much overhead IMO.

Yeah, NEW queue processing can be bad. But if it realy is just
experimenting and the dependencies prevent mixed setups then I
wouldn't take the SONAME so serious. The SONAME change is there so old
and new stuff can coexist and migrate over time. That isn't applicable
to such an experimental situation.
 
> > Imho experimental packages should be made with the hope that they
> > could enter sid in the future. Sure they are for experimenting. But
> > say the experiment is successfull shouldn't the package go to sid? If
> > you have to redesign them at that point you will just introduce new
> > bugs at that point and restart the testing process again.
> 
> The experiment in this case was seeing if the test suite passes on
> all architectures or not. It did not because long doubles are weird on
> powerpc, so I reverted the change. I then uploaded the next try (again,
> to experimental of course) without changing the perlapi-* or the SONAME.
> 
> I still think that expecting full-blown ABI change handling for iterations
> like this in experimental is too much.

Totaly. Not for every iteration anyway. As long as mixing/breaking sid
is prevented with an SONAME change or dependencies that is fine. I
think ftp-master would kill you if every experimental upload had to go
through NEW.


As a side note: What you did probably shouldn't have been using
experimental at all. This should have gone to the long proposed "build
me this package" buildd extension. All you wanted (it sounds like) was
to compile the package and see the results of the built time test
suite. It would be nice if someone would work on implementing this
idea. That way maintainers could upload sources for test builds on
selective archs.

MfG
Goswin


-- 
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/20130423122218.GA26534@frosties

Re: R 3.0.0 and required rebuilds of all reverse Depends: of R

[Goswin von Brederlow]

On Fri, Apr 19, 2013 at 09:53:05AM +, Sune Vuorela wrote:
> On 2013-04-18, Goswin von Brederlow  wrote:
> >> Oh, that's a good point.  Yes, I hadn't thought about that specific case
> >> for testing ABI breakage in experimental.
> >
> > But then that simply is a broken upload. It will break horribly if you
> > install the experimental perl but keep other perl packages from sid.
> 
> Welcome to experimental. Stuff might break, stuff might be deliberately
> broken, ... 
> 
> I might also not properly manage abi changes in libraries in
> experimental, especially when it is me packaging snapshots.
> 
> /Sune

I sure hope you mean breakages between different experimental
versions. Not breakages compared to stable/testing/unstable versions.

MfG
Goswin


-- 
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/20130423122357.GB26534@frosties

Re: alternative debian/rules

[Goswin von Brederlow]

On Mon, Apr 22, 2013 at 11:23:51AM +0100, Jonathan Dowland wrote:
> On Tue, Apr 16, 2013 at 01:46:20PM -0700, Steve Langasek wrote:
> > On Tue, Apr 16, 2013 at 02:28:18PM +0200, Goswin von Brederlow wrote:
> > > % ls -lh debian/rules
> > > lrwxrwxrwx 1 mrvn users  1 Apr 16 12:27 debian/rules -> /usr/bin/dh
> > 
> > I don't understand your point, other than to demonstrate that you're doing
> > something which doesn't conform to policy?
> 
> And running something like csh. Both seem like bad ideas!

Huh? That's zsh and there was no point besides the comedic value.

MfG
Goswin


-- 
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/20130423124935.GC26534@frosties

Re: Bug#705879: moreinfo

[Goswin von Brederlow]

On Tue, Apr 23, 2013 at 12:09:49AM +1000, Dmitry Smirnov wrote:
> On Mon, 22 Apr 2013 17:50:37 Holger Levsen wrote:
> > ah! thanks for summarizing why this is not a bug, but rather a feature 
> > (UUIDs 
> > for partitions) made for this situation not being used!
> 
> For the record about a year ago when I tried to use UUID for
> external journal on ext4 it didn't work because (I think) it was not
> implemented.
> Probably it still doesn't work although I could miss something in recent
> changelogs.
> 
> Although UUID is very useful for partitions I didn't mention UUID because I
> knew it wouldn't work for ext4 external journal.
> 
> 
> > see eg http://wiki.debian.org/Part-UUID or debian-u...@lists.debian.org for 
> > more info.
> 
> Thanks for the link.
> 
> Cheers,
>  Dmitry Smirnov
>  GPG key : 4096R/53968D1B

If UUID doesn't work then I think you are left with LVM as the only
option to get a reliable device name.

MfG
Goswin


-- 
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/20130423125219.GD26534@frosties

Re: R 3.0.0 and required rebuilds of all reverse Depends: of R

[Vincent Lefevre]

On 2013-04-23 14:23:57 +0200, Goswin von Brederlow wrote:
> On Fri, Apr 19, 2013 at 09:53:05AM +, Sune Vuorela wrote:
> > On 2013-04-18, Goswin von Brederlow  wrote:
> > >> Oh, that's a good point.  Yes, I hadn't thought about that specific case
> > >> for testing ABI breakage in experimental.
> > >
> > > But then that simply is a broken upload. It will break horribly if you
> > > install the experimental perl but keep other perl packages from sid.
> > 
> > Welcome to experimental. Stuff might break, stuff might be deliberately
> > broken, ... 
> > 
> > I might also not properly manage abi changes in libraries in
> > experimental, especially when it is me packaging snapshots.
> > 
> > /Sune
> 
> I sure hope you mean breakages between different experimental
> versions. Not breakages compared to stable/testing/unstable versions.

You should also consider breakage between an experimental version
and a future unstable version.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
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/20130423125918.gb1...@xvii.vinc17.org

Re: [Debian-med-packaging] Question about proper archive area for packages that require big data for operation

[Benjamin Drung]

Am Dienstag, den 23.04.2013, 13:51 +0200 schrieb Laszlo Kajan:
> Hello Andreas!
> 
> On 23/04/13 12:23, Andreas Tille wrote:
> > On Tue, Apr 23, 2013 at 11:48:05AM +0200, Laszlo Kajan wrote:
> >>
> >> This email is to continue the discussion about free packages that
> >> depend on big (e.g. >400MB) free data outside 'main'.
> > 
> > In your practical case is this data say <500MB?  Are we talking about
> > compressed or uncompressed data (= >400MB on users harddisk or on all
> > Debian mirrors world-wide)?
> 
> It is around 404MB, gzip compressed [1]. I think it is not arch
> independent. I think BLAST databases (the main bulk in the tar.gz) are
> sensitive
> to the size of int, and endian-ness.
> 
> [1] ftp://rostlab.org/metastudent/metastudent-data_1.0.0.tar.gz

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

-- 
Benjamin Drung
Debian & Ubuntu Developer


-- 
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/1366722785.3022.4.camel@deep-thought

Bug#706009: ITP: grr -- web-based resource reservation system

[Georges Khaznadar]

Package: wnpp
Severity: wishlist
Owner: Georges Khaznadar 

* Package name: grr
  Version : 1.9.7e
  Upstream Author : Laurent Delineau 
* URL : http://grr.mutualibre.org/
* License : GPL-2.0
  Programming Lang: PHP
  Description : web-based resource reservation system
 GRR is designed to manage the shared usage of physical resources among
 a community of users. Resources may be rooms, vehicles, beamers, etc.
 .
 GRR allows you to manage fine-grained reservation rights to shared resources,
 enventually divided into separate domains.


-- 
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/20130423140756.28791.37336.report...@georges.khaznadar.fr

Bug#706014: ITP: re-name -- mass rename tool using regular expression

[Joao Eriberto Mota Filho]

Package: wnpp
Severity: wishlist
Owner: Joao Eriberto Mota Filho 

* Package name: re-name
  Version : 1.99.2
  Upstream Author : Andy Xuming 
* URL : http://rename.sf.net
* License : GPL3
  Programming Lang: C
  Description : mass rename tool using regular expression

 Re-name (regular expression (re)name) is a tool to rename files. It can
 change, lowercase and uppercase a batch of files, or modify their ownership.
 It is a small and quick tool  written in C so it's quicker than most rename
 tools written in shell scripts.
 .
 Rename is powered by the extended regular expression for searching and
 substituting string patterns in the file names.
 .
 The main features of rename are:
 .
   * Substitue strings in filenames.
   * Search and substitue strings in filenames by POSIX regular expressions.
   * Uppercase or lowercase filenames.
   * Support batch mode rename.
   * Recursively processing directories and subdirectories.
   * Support to read the filename list from a file.
   * Change ownership of files.
   * Safe mode: test before you go.


-- 
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/20130423142735.25967.52187.report...@libra.gabcmt.eb.mil.br

Re: Bug#706014: ITP: re-name -- mass rename tool using regular expression

[Simon McVittie]

On 23/04/13 15:27, Joao Eriberto Mota Filho wrote:
>  Re-name (regular expression (re)name) is a tool to rename files. It can
>  change, lowercase and uppercase a batch of files, or modify their ownership.

Is this significantly better than the rename(1) (aka prename(1)) tool
that's supplied with Perl, which is Priority:standard on Debian?

(rename(1) uses Perl, not POSIX, regular expressions - but Perl regular
expressions are somewhat more internally-consistent than POSIX regular
expressions, and closely resemble the "Perl-compatible" regular
expressions used by Python, Javascript, GLib, Exim, etc.)

Changing ownership and built-in recursion look like features that
rename(1) doesn't have, but find + xargs + rename provide those.

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/5176a088.7070...@debian.org

Re: NEW processing during freezes

[Thorsten Glaser]

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 processing and only

I think you shouldn’t do that anyway.

After all, to do that, you’d have to manually install the new version
of bar in the chroot you used to build foo, which is a violation of the
“clean, minimal chroot” rule if read strictly (and, from experience with
bad non-buildd uploads, I tend to read it strictly).

So, normally, you can only upload a new version of foo after bar gets
available on your regular mirror. (Making it temporarily available
locally for development is, of course, okay – just don’t upload that.)

bye,
//mirabilos (who sees the m68k buildds build many NEW packages now)


-- 
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/loom.20130423t171311-...@post.gmane.org

Re: Question about proper archive area for packages that require big data for operation

[Russ Allbery]

Laszlo Kajan  writes:

> This email is to continue the discussion about free packages that depend
> on big (e.g. >400MB) free data outside 'main'. These packages apparently
> violate policy 2.2.1 [0] for inclusion in 'main' because they require
> software outside the 'main' area to function. They do not violate point
> #1 of the social contract [1], which requires non-dependency on non-free
> components. For these big data packages, policy seems to be overly
> restrictive compared to the social contract, leading to seemingly
> unfounded rejection from 'main'.

> * In case the social contract indeed allows such packages to be in
> 'main' (and policy is overly restrictive), how could it be ensured that
> the packages are accepted?

Yes, I agree.  Although we should probably talk with ftp-master about
whether they would like the data to just be packaged and uploaded as a
regular package.

> * What is the procedure within Debian to elicit a decision about the
> handling of such packages in terms of archive area? Discussion on
> d-devel, followed by policy change? Asking the policy team to clarify
> policy for such packages? Technical committee?

Discussing it on debian-devel seems right, but I would also draw it to
ftp-master's attention, since they're the people who have to worry about
archive size).  We can easily move on to modifying Policy if there's a
consensus to let packages like that pull the data down from some external
source.

-- 
Russ Allbery (r...@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/8738uhb3ba@windlord.stanford.edu

Bug#706029: ITP: libxxx-perl -- debug viewer for Perl data structure

[Dominique Dumont]

Package: wnpp
Owner: Dominique Dumont 
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org

* Package name: libxxx-perl
  Version : 0.18
  Upstream Author : Ingy d�t Net 
* URL : http://search.cpan.org/dist/XXX/
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : debug viewer for Perl data structure

XXX.pm exports a function called XXX that you can put just about anywhere in
your Perl code to make it die with a YAML dump of the arguments to its right.

The charm of XXX-debugging is that it is easy to type, rarely requires parens
and stands out visually so that you remember to remove it.

XXX.pm also exports WWW, YYY and ZZZ which do similar debugging things.


-- 
 https://github.com/dod38fr/   -o- http://search.cpan.org/~ddumont/
http://ddumont.wordpress.com/  -o-   irc: dod at irc.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/201304231930.22300@debian.org

Bug#706030: ITP: libstring-diff-perl -- simple diff for strings

[Jonas Smedegaard]

Package: wnpp
Severity: wishlist
Owner: Jonas Smedegaard 

* Package name: libstring-diff-perl
  Version : 0.06
  Upstream Author : Kazuhiro Osawa 
* URL : https://github.com/yappo/p5-String-Diff/tree
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : simple diff for strings

 String::Diff compares two strings, and emphasizes changed hunks within
 the resulting diff.
 .
 The markup of the addition and the deletion can be freely changed, e.g.
 coloring for the terminal with ANSI, or using HTML for web usage.


-- 
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/20130423180005.15294.26838.report...@auryn.jones.dk

Re: RFC: initramfs-tools support for early firmware loading

[Julien Cristau]

On Mon, Apr 22, 2013 at 19:23:50 -0300, Henrique de Moraes Holschuh wrote:

> As of Linux kernel 3.9, support for supplying early firmware data to the
> kernel has been added.  Currently, it is used for early microcode updates
> for Intel processors, and ACPI table overrides.
> 
> This is a very important feature, that we should support as soon as
> practical.  ACPI table overrides can massage less-than-stellar firmware into
> something usable, and early CPU microcode update are the only way (other
> than a BIOS upgrade) to avoid certain CPU defects.
> 
> To supply early firmware data to the kernel, we have to *prepend* an
> uncompressed cpio archive to the initramfs image.  The initramfs image
> itself can be compressed as usual.
> 
> Currently, initramfs-tools has undocumented support for appending data to
> the initramfs image.  This is now useless.  We need to enhance
> initramfs-tools to support adding arbritary files to a cpio archive that
> needs to be prepended to the initramfs image.
> 
Seems a bit odd that you're sending a mail about initramfs-tools to two
mailing lists, none of which are the initramfs-tools maintainer?  (Hint:
that would be initramfs-to...@packages.debian.org, aka
debian-ker...@lists.debian.org)

Cheers,
Julien


signature.asc
Description: Digital signature

Bug#706042: ITP: grapefruit -- Python module to manipulate color information easily

[Simon Chopin]

Package: wnpp
Severity: wishlist
Owner: Simon Chopin 
Control: block 705947 by -1

* Package name: grapefruit
  Version : 0.1~a3
  Upstream Author : Xavier Basty
* URL : https://github.com/xav/Grapefruit
* License : Apache 2.0
  Programming Lang: Python
  Description : Python module to manipulate color information easily

GrapeFruit is a pure Python module that let you easily manipulate and
convert color information. Its Primary goal is to be natural and
flexible.

It is one of the multiple dependencies of fedmsg, and will be packaged
inside the DPMT.


-- 
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/20130423202516.30105.92049.reportbug@mithrandir

Re: [Debian-med-packaging] Question about proper archive area for packages that require big data for operation

[Laszlo Kajan]

Hello Benjamin!

On 23/04/13 15:13, Benjamin Drung wrote:
> Am Dienstag, den 23.04.2013, 13:51 +0200 schrieb Laszlo Kajan:
>> Hello Andreas!
>>
>> On 23/04/13 12:23, Andreas Tille wrote:
>>> On Tue, Apr 23, 2013 at 11:48:05AM +0200, Laszlo Kajan wrote:

 This email is to continue the discussion about free packages that
 depend on big (e.g. >400MB) free data outside 'main'.
>>>
>>> In your practical case is this data say <500MB?  Are we talking about
>>> compressed or uncompressed data (= >400MB on users harddisk or on all
>>> Debian mirrors world-wide)?
>>
>> It is around 404MB, gzip compressed [1]. I think it is not arch
>> independent. I think BLAST databases (the main bulk in the tar.gz) are
>> sensitive
>> to the size of int, and endian-ness.
>>
>> [1] ftp://rostlab.org/metastudent/metastudent-data_1.0.0.tar.gz
> 
> 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

Ah great! Thanks for checking this. A lesson for the future. We will switch to 
xz. 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/5176f4e6.2000...@rostlab.org

Re: NEW processing during freezes

[Joachim Breitner]

Hi,

Am Dienstag, den 23.04.2013, 15:15 + schrieb Thorsten Glaser:
> So, normally, you can only upload a new version of foo after bar gets
> available on your regular mirror. (Making it temporarily available
> locally for development is, of course, okay – just don’t upload that.)

sounds good in theory, but in practice, when I want to upgrade foo,
which happens to have a new dependency on bar, which needs baz, which
needs qux, then I really want to get this done in one rush, and not wait
for three NEW processings in between.

Luckily, a permanent reject in NEW is rare enough that this process is,
at least after NEW processing, fine.

Greetings,
Joachim

-- 
Joachim "nomeata" Breitner
Debian Developer
  nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C
  JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata



signature.asc
Description: This is a digitally signed message part

Re: [Debian-med-packaging] Question about proper archive area for packages that require big data for operation

[Laszlo Kajan]

Dear Russ!

Thank you for getting back to me.

On 23/04/13 18:48, Russ Allbery wrote:
> Laszlo Kajan  writes:
> 
>> This email is to continue the discussion about free packages that depend
>> on big (e.g. >400MB) free data outside 'main'. These packages apparently
>> violate policy 2.2.1 [0] for inclusion in 'main' because they require
>> software outside the 'main' area to function. They do not violate point
>> #1 of the social contract [1], which requires non-dependency on non-free
>> components. For these big data packages, policy seems to be overly
>> restrictive compared to the social contract, leading to seemingly
>> unfounded rejection from 'main'.
> 
>> * In case the social contract indeed allows such packages to be in
>> 'main' (and policy is overly restrictive), how could it be ensured that
>> the packages are accepted?
> 
> Yes, I agree.  Although we should probably talk with ftp-master about
> whether they would like the data to just be packaged and uploaded as a
> regular package.

Ftp-master was included in the initial thread [1], but they did not (yet) 
respond, and I started to feel that it may be impolite to flood their
inbox with an issue like this. Since perhaps they alone can not decide about 
it. So yes, ftp-master is included in the mail once again.

[1] 
http://lists.alioth.debian.org/pipermail/debian-med-packaging/2013-April/019282.html

>> * What is the procedure within Debian to elicit a decision about the
>> handling of such packages in terms of archive area? Discussion on
>> d-devel, followed by policy change? Asking the policy team to clarify
>> policy for such packages? Technical committee?
> 
> Discussing it on debian-devel seems right, but I would also draw it to
> ftp-master's attention, since they're the people who have to worry about
> archive size).  We can easily move on to modifying Policy if there's a
> consensus to let packages like that pull the data down from some external
> source.

How to gauge that consensus?

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/5176f5f5.5040...@debian.org

Re: [Debian-med-packaging] Question about proper archive area for packages that require big data for operation

[Russ Allbery]

Laszlo Kajan  writes:
> On 23/04/13 18:48, Russ Allbery wrote:

>> Discussing it on debian-devel seems right, but I would also draw it to
>> ftp-master's attention, since they're the people who have to worry
>> about archive size).  We can easily move on to modifying Policy if
>> there's a consensus to let packages like that pull the data down from
>> some external source.

> How to gauge that consensus?

Generally the way it works is that if no one objects to the idea, we bring
it up on the Policy list, where we have a somewhat more formal process
that involves seconds or objections.

I think the ideal from a usability standpoint would be to just upload the
data directly to the Debian archive, though.  It's just a question of how
big of packages we want to handle through the mirror network, or whether
it's worth the effort to create a separate archive of huge data packages.

-- 
Russ Allbery (r...@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/878v487vrc@windlord.stanford.edu

Re: NEW processing during freezes

[Russ Allbery]

Joachim Breitner  writes:

> sounds good in theory, but in practice, when I want to upgrade foo,
> which happens to have a new dependency on bar, which needs baz, which
> needs qux, then I really want to get this done in one rush, and not wait
> for three NEW processings in between.

I go through this process with Shibboleth routinely, and it really doesn't
seem that bad to me.  There were some delays with NEW recently during the
work on the release, but normally the turnaround for a simple SONAME
change in an existing library is <2 days, which doesn't hold me up that
much.  I prepare all the packages in advance, and then just build and
upload the next one as I get the acceptance for the previous one.

-- 
Russ Allbery (r...@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/874new7vol@windlord.stanford.edu

Re: Bug#705954: ITP: ms-sys -- writes Microsoft compatible boot records

[Michael Prokop]

* Joao Eriberto Mota Filho [Mon Apr 22, 2013 at 01:57:16PM -0300]:

> * Package name: ms-sys
>   Version : 2.3.0
>   Upstream Author : Henrik Carlqvist 
> * URL : http://ms-sys.sf.net
> * License : GPL2
>   Programming Lang: C
>   Description : writes Microsoft compatible boot records

> Does the same as Microsoft "fdisk /mbr" to a hard disk or "sys d:" to a floppy
> or FAT32 partition except that it does not copy any system files, only the 
> boot
> record is written.

> The current version supports up to Windows 7.

We've had this package already in Debian once but it was removed
because of copyright issues as noted in #470678, JFYI.

regards,
-mika-


signature.asc
Description: Digital signature

Bug#706048: ITP: nsnake -- classic snake game with textual interface

[Alexandre Dantas]

Package: wnpp
Severity: wishlist
Owner: Alexandre Dantas 


* Package name: nsnake
  Version : 1.6
  Upstream Author : Alexandre Dantas 
* URL : http://www.alexdantas.net/projects/nsnake/
* License : GPL3
  Programming Lang: C
  Description : classic snake game with textual interface

 nsnake is an implementation of the classic snake game with textual
 interface. It is playable at command-line with ncurses-like graphics.
 .
 Features high-scores and two game modes - with and without borders.
 .
 Screenshot: http://alexdantas.net/nsnake-screenshot.png


-- 
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/20130423230905.8002.97388.reportbug@terminus

Re: RFC: initramfs-tools support for early firmware loading

[Henrique de Moraes Holschuh]

On Tue, 23 Apr 2013, Julien Cristau wrote:
> On Mon, Apr 22, 2013 at 19:23:50 -0300, Henrique de Moraes Holschuh wrote:
> > As of Linux kernel 3.9, support for supplying early firmware data to the
> > kernel has been added.  Currently, it is used for early microcode updates
> > for Intel processors, and ACPI table overrides.
> > 
> > This is a very important feature, that we should support as soon as
> > practical.  ACPI table overrides can massage less-than-stellar firmware into
> > something usable, and early CPU microcode update are the only way (other
> > than a BIOS upgrade) to avoid certain CPU defects.
> > 
> > To supply early firmware data to the kernel, we have to *prepend* an
> > uncompressed cpio archive to the initramfs image.  The initramfs image
> > itself can be compressed as usual.
> > 
> > Currently, initramfs-tools has undocumented support for appending data to
> > the initramfs image.  This is now useless.  We need to enhance
> > initramfs-tools to support adding arbritary files to a cpio archive that
> > needs to be prepended to the initramfs image.
> > 
> Seems a bit odd that you're sending a mail about initramfs-tools to two
> mailing lists, none of which are the initramfs-tools maintainer?  (Hint:
> that would be initramfs-to...@packages.debian.org, aka
> debian-ker...@lists.debian.org)

Meh, my bad.

I will repost there, and drop debian-boot.

Thanks!

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
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/20130423232637.ga13...@khazad-dum.debian.net

Bug#706060: ITP: lxc-docker -- the Linux container runtime

[Daniel Mizyrycki]

Package: wnpp
Version: N/A; reported 2013-04-23
Severity: wishlist
Owner: Daniel Mizyrycki 
X-Debbugs-CC: debian-devel@lists.debian.org

* Package name : lxc-docker
Version : 0.1.8
Upstream Author : dotCloud Inc 
* URL : http://github.com/dotcloud/docker
* License : Apache-2.0
Description : Docker: the Linux container runtime

Docker complements LXC with a high-level API which operates at the
process level. It runs unix processes with strong guarantees of
isolation and repeatability across servers.
Docker is a great building block for automating distributed systems:
large-scale web deployments, database clusters, continuous deployment
systems, private PaaS, service-oriented architectures, etc.


-- 
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/51776e0c.9020...@dotcloud.com

Re: [Debian-med-packaging] Question about proper archive area for packages that require big data for operation

[Olivier Sallou]

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 on big, but free data [2]. I have cited
> your opinion [3] in this discussion before. You are on the technical 
> committee and on the policy team, so you, together with Charles, can help
> substantially here.
>
> [2] 
> http://lists.alioth.debian.org/pipermail/debian-med-packaging/2013-April/thread.html
> [3] https://lists.debian.org/debian-vote/2013/03/msg00279.html
>
> This email is to continue the discussion about free packages that depend on 
> big (e.g. >400MB) free data outside 'main'. These packages
> apparently violate policy 2.2.1 [0] for inclusion in 'main' because they 
> require software outside the 'main' area to function. They do not
> violate point #1 of the social contract [1], which requires non-dependency on 
> non-free components. For these big data packages, policy seems to
> be overly restrictive compared to the social contract, leading to seemingly 
> unfounded rejection from 'main'.
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 mirrors (mainly if some indexed
data are system dependent) but will also be a pain for the user if, when
installing a program (to have a look), it downloads GBs of dependent
packaged data. It may be really slow and fill the user disk (and I do
not talk of package updates).

Should not those data dependency clearly stated somewhere with the
software package, with a script to get them ?

Olivier
>
> [0] http://www.debian.org/doc/debian-policy/ch-archive.html
> [1] http://www.debian.org/social_contract
>
> * In case the social contract indeed allows such packages to be in 'main' 
> (and policy is overly restrictive), how could it be ensured that the
> packages are accepted?
>
> * What is the procedure within Debian to elicit a decision about the handling 
> of such packages in terms of archive area? Discussion on d-devel,
> followed by policy change? Asking the policy team to clarify policy for such 
> packages? Technical committee?
>
>  + Charles suggested such packages could go into 'main' [4], with a clear 
> indication of the large data dependency of the package in the long
> description.
>When possible, providing the scripts for generating the large data as well.
>
>  [4] 
> http://lists.alioth.debian.org/pipermail/debian-med-packaging/2013-April/019292.html
>
> My goal as a Debian Developer and a packager is to get packages into Debian 
> (so 'main') that are allowed in there, in reasonably short time. I
> would like to resolve this issue properly, because I believe it may pop up 
> more often in bioinformatics software. For example, imagine a protein
> folding tool that would require a very large database to search for 
> homologues for contact prediction, and using the contacts it would predict
> protein three-dimensional structure. This has been done before [5], and such 
> a tool would be (is) immensely useful for bioinformatics. This tool
> would depend on gigabytes of data we would not package. Yet, by all means, I 
> would want the tool to be part of the distribution.
>
> [5] http://www.plosone.org/article/info%3Adoi%2F10.1371%2Fjournal.pone.0028766
>
> Thank you for your opinion and advice.
>
> Best regards,
> Laszlo
>
> ___
> Debian-med-packaging mailing list
> debian-med-packag...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-med-packaging

-- 
Olivier Sallou
IRISA / University of Rennes 1
Campus de Beaulieu, 35000 RENNES - FRANCE
Tel: 02.99.84.71.95

gpg key id: 4096R/326D8438  (keyring.debian.org)
Key fingerprint = 5FB4 6F83 D3B9 5204 6335  D26D 78DC 68DB 326D 8438


-- 
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/51777990.60...@irisa.fr