Re: Bug#688251: #688251: Built-Using description too aggressive

2013-09-23 Thread Paul Wise 
On Mon, Sep 23, 2013 at 5:33 AM, Charles Plessy wrote:

> do you think that the attached patch would solve the problem ?

There are more reasons for using Built-Using than licenses, for example:

Rebuilding against updated versions of static libraries.
Rebuilding the debian-installer-*-netboot-* packages.

I don't think we should restrict usage of Built-Using to only
license-related reasons, there are also other reasons.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


-- 
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/CAKTje6ESSNyFz=pcwkibsvobh_unhqbnhr2y5o822zu93m5...@mail.gmail.com

Re: Bug#688251: #688251: Built-Using description too aggressive

2013-09-23 Thread Charles Plessy 
Le Mon, Sep 23, 2013 at 10:56:28AM +0200, Paul Wise a écrit :
> On Mon, Sep 23, 2013 at 5:33 AM, Charles Plessy wrote:
> 
> > do you think that the attached patch would solve the problem ?
> 
> There are more reasons for using Built-Using than licenses, for example:
> 
> Rebuilding against updated versions of static libraries.
> Rebuilding the debian-installer-*-netboot-* packages.
> 
> I don't think we should restrict usage of Built-Using to only
> license-related reasons, there are also other reasons.

Hi Paul,

I agree.

The problem to solve here is to find a clear and concise way to describe how
this field is used.  The current description in the Policy has confused some
people and made them think or worry that they were asked unreasonable work.

I paste below the current wording in the Policy 3.9.4.  If you have an
improvement to propose, that would be much appreciated !

7.8 Additional source packages used to build the binary - Built-Using

Some binary packages incorporate parts of other packages when built but do 
not
have to depend on those packages. Examples include linking with static
libraries or incorporating source code from another package during the 
build.
In this case, the source packages of those other packages are a required 
part
of the complete source (the binary package is not reproducible without 
them).

A Built-Using field must list the corresponding source package for any such
binary package incorporated during the build [56], including an "exactly 
equal"
("=") version relation on the version that was used to build that binary
package[57].

A package using the source code from the gcc-4.6-source binary package built
from the gcc-4.6 source package would have this field in its control file:

 Built-Using: gcc-4.6 (= 4.6.0-11)

A package including binaries from grub2 and loadlin would have this field in
its control file:

 Built-Using: grub2 (= 1.99-9), loadlin (= 1.6e-1)

Cheers,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan


-- 
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/20130923090456.gf16...@falafel.plessy.net

Re: Bug#688251: #688251: Built-Using description too aggressive

2013-09-23 Thread Paul Wise 
On Mon, Sep 23, 2013 at 11:04 AM, Charles Plessy wrote:

> I paste below the current wording in the Policy 3.9.4.  If you have an
> improvement to propose, that would be much appreciated !

The wording doesn't appear confusing to me so I'm not the best person
to propose wording changes.

> The problem to solve here is to find a clear and concise way to describe how
> this field is used.  The current description in the Policy has confused some
> people and made them think or worry that they were asked unreasonable work.

I would suggest leaving the current wording, monitoring usage of the
field and filing bugs on any packages that use the field in an
"improper" way.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


-- 
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/caktje6gza-6fcuddyz1sb0-gx-oh_yoqaivnzf7rwwu6k4y...@mail.gmail.com

Re: packaging Postgres binary dump files

2013-09-23 Thread Cyril Brulebois 
Jonathan Dowland  (2013-09-23):
> Please don't CC me, I'm subscribed to the list.

And the list doesn't care.

“When replying to messages on the mailing list, do not send a carbon
 copy (CC) to the original poster unless they explicitly request to be
 copied.”

is followed by:

“If you want to complain to someone who sent you a carbon copy when you
 did not ask for it, do it privately.”

Especially true since you're sending the same mail multiple times.

KiBi.


-- 
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/20130923093628.gb23...@mraw.org

Bug#724280: ITP: rtax -- Rapid and accurate taxonomic classification of short paired-end sequence reads from the 16S ribosomal RNA gene

2013-09-23 Thread Simon Kainz 
Package: wnpp
Severity: wishlist
Owner: Simon Kainz 

* Package name: rtax
  Version :  0.983
  Upstream Author : David A. W. Soergel 
* URL : David A. W. Soergel
* License : BSD
  Programming Lang: Perl
  Description : Rapid and accurate taxonomic classification of short
paired-end sequence reads from the 16S ribosomal RNA gene

Short-read technologies for microbial community profiling are increasingly
popular, yet previous techniques for assigning taxonomy to paired-end reads
perform poorly. RTAX provides rapid taxonomic assignments of paired-end reads
using a consensus algorithm.

This tool is an optional dependency for qiime(which is already packaged) and it
would be great to have it
packaged for Debian.

Regards,

Simon


-- 
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/20130923095603.26061.18627.report...@zidpc9027.tu-graz.ac.at

Re: Bug#688251: #688251: Built-Using description too aggressive

2013-09-23 Thread Ansgar Burchardt 
On 09/23/2013 10:56, Paul Wise wrote:
> On Mon, Sep 23, 2013 at 5:33 AM, Charles Plessy wrote:
>> do you think that the attached patch would solve the problem ?
> 
> There are more reasons for using Built-Using than licenses, for example:
> 
> Rebuilding against updated versions of static libraries.
> Rebuilding the debian-installer-*-netboot-* packages.
> 
> I don't think we should restrict usage of Built-Using to only
> license-related reasons, there are also other reasons.

Yes, licensing isn't the only reason: if there was a clang-avr package
build-depending on clang-source (or gcc-avr built using a gcc relicensed
under a non-copyleft license), the source for the clang-avr package
should still be kept around and this would include the clang-source package.

In the end the problem comes down to defining what the "source" of a
binary package is. I doubt there are disagreements that the source for a
package X build-depending on Y-source includes Y-source or src:Y as in
the example above. In general I would also include statically linked
libraries. However I wouldn't think that language runtimes that are
added automatically by the compiler are part of the source of a binary.

There's probably no way to define "source"; in non-trivial cases there's
always some judgement involved. But if you find a clearer wording for
Policy, sure, go ahead.

Ansgar


-- 
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/52404606.6010...@debian.org

Replacing unrar-free with unar wrapper

2013-09-23 Thread Dominik George 
Hi, maintainers of unar and unrar-free,

as you might have seen on the BTS, I have today filed a bug report on
unrar-free and revisited an old bug, both of which make unrar-free
largely unusable [1][2]. I found that unrar-free seems to be umaintained
and has not had any commits by upstream for the last 6+ years, and
important bugs are open and ignored.

I found that the unar command from theunarchiver, which is even
recommended by the FSF [3], can handle multipart, modern RAR archives
just fine, only the command-line is incompatible to unrar-free and
unrar-nonfree [4].

One issue is that some tools in Debian, among which are usenet clients,
comic book readers, and others, rely on the syntax of unrar-nonfree, for
some reason I do not know, maybe because it works, in contrast to
unrar-free. I guess the command-line compatibility in unrar-free has
been added for this very reason, but it failed to become a drop-in
replacement for unrar-nonfree because it exits uncleanly on passing some
unrar-free options, and in general does not provide the functionality of
unrar-nonfree.

My proposal is to remove unrar-free from Debian, for the reasons
mentioned above, and add a patch to src:unar that include a wrapper
script that provides a command-line wrapper compatible to both
unrar-free and unrar-nonfree, so unar can become a drop-in replacement
for both.

I would like to create th ewrapper script and resulting patch, but
first, I would like to hear your thoughts about my research and
proposal.

Cheers,
Nik

[1]: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=724295
[2]: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=270751
[3]: https://www.fsf.org/blogs/licensing/free-rarv3-extraction
[4]: http://manpages.debian.net/cgi-bin/man.cgi?query=unrar-free

-- 
 Ein Jabber-Account, sie alle zu finden; ins Dunkel zu treiben
und ewig zu binden; im NaturalNet, wo die Schatten droh'n ;)!

PGP-Fingerprint: 3C9D 54A4 7575 C026 FB17  FD26 B79A 3C16 A0C4 F296


signature.asc
Description: Digital signature

Re: Bug#688251: #688251: Built-Using description too aggressive

2013-09-23 Thread Russ Allbery 
Paul Wise  writes:
> On Mon, Sep 23, 2013 at 11:04 AM, Charles Plessy wrote:

>> I paste below the current wording in the Policy 3.9.4.  If you have an
>> improvement to propose, that would be much appreciated !

> The wording doesn't appear confusing to me so I'm not the best person
> to propose wording changes.

The basic problem that we're trying to solve is that nearly every package
in Debian incorporates code from gcc and/or libc into the resulting
binary.  So, currently, Policy says that basically every package in the
archive needs Built-Using.  This obviously isn't what we want to have
happen.

The question is how to make it clear that's not the intent, which requires
figuring out how to separate the other use cases from the gcc and glibc
case.

I suppose one possible approach is to just explicitly exclude the C
library and compiler from the current wording.  (Although I'm not sure
that should be the case for every compiler; for example, do some of the
more complex compilers for languages like Haskell actually need
Built-Using?)

> I would suggest leaving the current wording, monitoring usage of the
> field and filing bugs on any packages that use the field in an
> "improper" way.

We've already had multiple complaints and multiple confused people due to
the current wording.

-- 
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/87eh8fa5bc@windlord.stanford.edu

Re: Roll call for porters of architectures in sid and testing (Status update)

2013-09-23 Thread Martin Lucina 
Hi,

b...@decadent.org.uk said:
> > I've also provided a couple of kernel patches in the past. I'm cross
> > testing with Gentoo to ensure that bugs I report are Debian-specific
> > or ia64-generic.
> > 
> > I'll continue testing/software development activity on ia64 for the
> > Jessie cycle, and more generally, until Debian drops ia64. I'm already
> > waiting for Wayland on ia64 and other big updates.
> > 
> > So please, keep ia64 in the bandwagon ;-)
> 
> But I don't think ia64 is well-supported even in wheezy.  The kernel
> doesn't boot on some common machines and no-one seems to be able to fix
> it.

I'm the most recent person to report that bug. Unfortunately I run a sole
ia64 box in a production setting and I only have physical access to it
during business hours (and no management card) which makes experimenting
with kernels difficult.

I would be more than happy to sign up as a porter for ia64 however I would
need to obtain more hardware. HP rx1620s can be had on eBay for $100 but
they are located in California and shipping + customs to Slovakia is not
worth it :-/

If someone is willing to donate hardware, or knows of a cheap source of
ia64 hardware in Europe I'm more than happy to host it here, maintain it,
provide access to developers, and time permitting test and and help
diagnose ia64-specific problems with the base system for the lifetime of
the jessie release.

I am also a long-time Debian user (>10 years, mostly x86/amd64, alpha in
the past, some arm work and ia64 from the time I've had this hardware). I
am not a DD/DM but have experience as a package maintainer via sponsorship
in the past.

Martin


signature.asc
Description: Digital signature

Re: Replacing unrar-free with unar wrapper

2013-09-23 Thread Ying-Chun Liu (PaulLiu) 
於 2013年09月23日 22:30, Dominik George 提到:
> Hi, maintainers of unar and unrar-free,
> 
> as you might have seen on the BTS, I have today filed a bug report on
> unrar-free and revisited an old bug, both of which make unrar-free
> largely unusable [1][2]. I found that unrar-free seems to be umaintained
> and has not had any commits by upstream for the last 6+ years, and
> important bugs are open and ignored.
> 
> I found that the unar command from theunarchiver, which is even
> recommended by the FSF [3], can handle multipart, modern RAR archives
> just fine, only the command-line is incompatible to unrar-free and
> unrar-nonfree [4].
> 
> One issue is that some tools in Debian, among which are usenet clients,
> comic book readers, and others, rely on the syntax of unrar-nonfree, for
> some reason I do not know, maybe because it works, in contrast to
> unrar-free. I guess the command-line compatibility in unrar-free has
> been added for this very reason, but it failed to become a drop-in
> replacement for unrar-nonfree because it exits uncleanly on passing some
> unrar-free options, and in general does not provide the functionality of
> unrar-nonfree.
> 
> My proposal is to remove unrar-free from Debian, for the reasons
> mentioned above, and add a patch to src:unar that include a wrapper
> script that provides a command-line wrapper compatible to both
> unrar-free and unrar-nonfree, so unar can become a drop-in replacement
> for both.
> 
> I would like to create th ewrapper script and resulting patch, but
> first, I would like to hear your thoughts about my research and
> proposal.
> 
> Cheers,
> Nik
> 
> [1]: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=724295
> [2]: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=270751
> [3]: https://www.fsf.org/blogs/licensing/free-rarv3-extraction
> [4]: http://manpages.debian.net/cgi-bin/man.cgi?query=unrar-free
> 

Hi,

Nice idea. The unrar-free currently only able to decompress the 2.x
format, which is the DOS-era rar files.

Please provide a patch to unar first because we currently are using
update-alternatives for /usr/bin/unrar. So actually you can work on unar
and let it has normal priority for that (unrar-free uses really low
priority). It won't be conflict to have unrar-free unar together for a
while. After we make sure that unar has a compatibility cmd-line options
with unrar-nonfree, and then I'll file a RoM of unrar-free package.

Yours,
Paul

-- 
PaulLiu (劉穎駿)
E-mail: Ying-Chun Liu (PaulLiu) 



signature.asc
Description: OpenPGP digital signature

Re: dpkg-gensymbols -- should(n't) version where symbol was introduced remain when SONAME changes?

2013-09-23 Thread Lisandro Damián Nicanor Pérez Meyer 
On Saturday 21 September 2013 22:58:15 Yaroslav Halchenko wrote:
> On Sun, 22 Sep 2013, Andreas Beckmann wrote:
> > > [-libfreenect.so.0.1 libfreenect0.1-]{+libfreenect.so.0.2
> > > libfreenect0.2+} #MINVER#[-(optional)fn_log@Base 1:0.1.1-]> > 
> >   ^
> > 
> > You need to change the soname in the first line of your symbols file,
> > otherwise what you get is the deletion of one library and the addition
> > of a different one.
> 
> Thank you Andreas for your time and the reply -- the former
> "problem" is so obvious now that it hurts ;)

While it could be considered "hitting the problem with a hammer" in this cases 
I run a recursive grep for the old stuff over the debian dir. It's of course 
not the only thing to do, but has proven useful so far :)


-- 

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

Re: Replacing unrar-free with unar wrapper

2013-09-23 Thread Nick Andrik 
I have worked in the past year a bit with unrar-nonfree, mainly
because I wanted rar (cbr) support in calibre.
I would be happy having a drop-in replacement, if this is possible,
but I don't know how easy this is for calibre.
The way it works there, is that calibre links against libunrar and
expects certain output (as in std out) in order to parse the list with
the files in the archive before reading them as the result of the
command.
I have not dug in detail in the calibre implementation, I just made
sure libunrar is available and is compiled without defining SILENT
macro
So, a compatibility layer for unrar-nonfree that could be used for
calibre, should also provide a compatible library

A final solution would be to convince the calibre developer to use
unar instead, but I don't know how easy that'd be

--
=Do-
N.AND


2013/9/23 Dominik George :
> Hi, maintainers of unar and unrar-free,
>
> as you might have seen on the BTS, I have today filed a bug report on
> unrar-free and revisited an old bug, both of which make unrar-free
> largely unusable [1][2]. I found that unrar-free seems to be umaintained
> and has not had any commits by upstream for the last 6+ years, and
> important bugs are open and ignored.
>
> I found that the unar command from theunarchiver, which is even
> recommended by the FSF [3], can handle multipart, modern RAR archives
> just fine, only the command-line is incompatible to unrar-free and
> unrar-nonfree [4].
>
> One issue is that some tools in Debian, among which are usenet clients,
> comic book readers, and others, rely on the syntax of unrar-nonfree, for
> some reason I do not know, maybe because it works, in contrast to
> unrar-free. I guess the command-line compatibility in unrar-free has
> been added for this very reason, but it failed to become a drop-in
> replacement for unrar-nonfree because it exits uncleanly on passing some
> unrar-free options, and in general does not provide the functionality of
> unrar-nonfree.
>
> My proposal is to remove unrar-free from Debian, for the reasons
> mentioned above, and add a patch to src:unar that include a wrapper
> script that provides a command-line wrapper compatible to both
> unrar-free and unrar-nonfree, so unar can become a drop-in replacement
> for both.
>
> I would like to create th ewrapper script and resulting patch, but
> first, I would like to hear your thoughts about my research and
> proposal.
>
> Cheers,
> Nik
>
> [1]: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=724295
> [2]: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=270751
> [3]: https://www.fsf.org/blogs/licensing/free-rarv3-extraction
> [4]: http://manpages.debian.net/cgi-bin/man.cgi?query=unrar-free
>
> --
>  Ein Jabber-Account, sie alle zu finden; ins Dunkel zu treiben
> und ewig zu binden; im NaturalNet, wo die Schatten droh'n ;)!
>
> PGP-Fingerprint: 3C9D 54A4 7575 C026 FB17  FD26 B79A 3C16 A0C4 F296


-- 
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/cann5kov9fohh3zvsj4-gqm-1ctjbeayjyzklh1bxnt32w-y...@mail.gmail.com

Bug#724344: ITP: bdsync -- bdsync is a fast block device synchronizing tool

2013-09-23 Thread maxigas 
Package: wnpp
Severity: wishlist
Owner: maxigas 

* Package name: bdsync
  Version : 0.5
  Upstream Author : 
* URL : 
* License : GPL
  Programming Lang: C
  Description : bdsync is a fast block device synchronizing tool

 Bdsync can be used to synchronize block devices over a network. It
 generates a "binary diff" in an efficient  way  by  comparing  MD5
 checksums  of  32k blocks of the local block device LOCDEV and the
 remote block device REMDEV.

 This binary diff can be sent to the remote machine and applied  to
 its block device DSTDEV, after which the local blockdev LOCDEV and
 the remote block device REMDEV are synchronized.

 bdsync was built to do the only thing rsync isn't able to do: syn‐
 chronize block devices.


-- 
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/20130923220154.18166.50289.reportbug@localhost

Bug#724452: ITP: ifupdown-multi -- multiple default gateway support for ifupdown

2013-09-23 Thread Robert Edmonds 
Package: wnpp
Severity: wishlist
Owner: Robert S. Edmonds 

* Package name: ifupdown-multi
  Version : 0.1.0
  Upstream Author : Farsight Security, Inc.
* URL : https://github.com/farsightsec/ifupdown-multi
* License : Apache-2.0
  Programming Lang: Python
  Description : multiple default gateway support for ifupdown

 This package integrates support for multiple default gateways on
 independent network connections into the Debian ifupdown network
 interface configuration system. It adds new "multi_*" options to the
 /etc/network/interface file format in order to more easily configure
 Linux's policy based routing.
 .
 The policy information used to configure each network interface using
 ifupdown-multi is saved when ifup is run. This allows network
 interfaces using ifupdown-multi to be brought up or down cleanly as
 needed.

-- 
Robert Edmonds
edmo...@debian.org


signature.asc
Description: Digital signature

Bug#724474: ITP: grub-legacy-doc -- Documentation for GRUB Legacy

2013-09-23 Thread Colin Watson 
Package: wnpp
Severity: wishlist
Owner: Colin Watson 

* Package name: grub-legacy-doc
  Version : 0.97
  Upstream Author : bug-g...@gnu.org
* URL : http://www.gnu.org/software/grub/grub-legacy.html
* License : GFDL
  Description : Documentation for GRUB Legacy

http://bugs.debian.org/708946 reports that the GRUB Legacy info
documentation is non-free due to the use of the GFDL 1.2 with
Front-Cover and Back-Cover Texts (cf.
http://www.debian.org/vote/2006/vote_001).  The GRUB 2 info
documentation does not have this problem; but GRUB Legacy is
aggressively in maintenance mode and I do not expect to get upstream
approval to adjust its licensing.

I think the most practical resolution involving spending the least
effort on GRUB Legacy is to split off its documentation into a source
package in non-free.

-- 
Colin Watson   [cjwat...@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/20130924060306.ga2...@sarantium.pelham.vpn.ucam.org