Re: quilt 3.0 source format and dpkg-source/dpkg-buildpackage

2010-01-22 Thread Raphael Hertzog 
On Fri, 22 Jan 2010, tangke wrote:
> why not apply the patches when build automatically,

This is the case when you build the source package (i.e. dpkg-source does
it if it was not yet done).

> and make clean to unapply the patches?

The clean process is controlled by the maintainer. You could in theory
unapply the patch there.

But the truth is that dpkg-buildpackage was not designed with VCS
in mind and we should start designing a complementary vcs-buildpackage
that implements a friendlier approach like:
 - use the VCS to build the source package
 - unpack the source package in a temporary tree
 - build the binary package there

Currently I don't have the time to start designing this but it's on my
long term TODO to collaborate with {svn,git,bzr,*}-buildpackage
maintainers and to offer a common solution for all VCS that would be
integrated in dpkg-dev.

Cheers,
-- 
Raphaël Hertzog


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

graphicsmagick or imagemagick

2010-01-22 Thread Jérémy Lal 
Hi,
my naïve questions for today :

1) is graphicsmagick really better than imagemagick ?
it advertises it's twice as fast, scales better, and 'contains'
imagemagick.

2) if so, why graphicsmagick is not widely used ?
The migration "looks" easy. I feel i'm missing something.


Jérémy.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: graphicsmagick or imagemagick

2010-01-22 Thread Paul Wise 
On Sat, Jan 23, 2010 at 12:41 AM, Jérémy Lal  wrote:

> 2) if so, why graphicsmagick is not widely used ?
> The migration "looks" easy. I feel i'm missing something.

Probably a simple matter of mindshare and inertia. imagemagick has
been around for longer. graphicsmagick probably hasn't done enough
marketting to overcome the imagemagick inertia. For me, imagemagick is
good enough and the benefits of graphicsmagick aren't that obvious.

-- 
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

Re: quilt 3.0 source format and dpkg-source/dpkg-buildpackage

2010-01-22 Thread Joachim Wiedorn 
Hello,

Raphael Hertzog  wrote:
> On Fri, 22 Jan 2010, tangke wrote:
> > why not apply the patches when build automatically,
> 
> This is the case when you build the source package (i.e. dpkg-source does
> it if it was not yet done).
> 
> > and make clean to unapply the patches?
> 
> The clean process is controlled by the maintainer. You could in theory
> unapply the patch there.

Now I must use quilt for apply and unapply the patches. I think this way
is transparent.

But there is one problem: 
If I had unapplied all patches of debian/patches and later I start with
debuild, then dpkg-source works with the unpatched sources - it doesn't
apply the patches as in format 1.0. Is there a chance that dpkg-source
see the patches and can recognize that they must be applied before run
further?


Fondest regards,
 Joachim Wiedorn



signature.asc
Description: PGP signature

Re: quilt 3.0 source format and dpkg-source/dpkg-buildpackage

2010-01-22 Thread Raphael Hertzog 
On Fri, 22 Jan 2010, Joachim Wiedorn wrote:
> If I had unapplied all patches of debian/patches and later I start with
> debuild, then dpkg-source works with the unpatched sources - it doesn't
> apply the patches as in format 1.0. Is there a chance that dpkg-source
> see the patches and can recognize that they must be applied before run
> further?

It does this already as I said, quoting the dpkg-source manual page:
| [...] dpkg-source will apply the patches by itself
| if  it  believes  that they have not yet been applied. To detect this 
situation, it
| uses the following heuristic: it finds the list  of  supposedly  unapplied  
patches
| (they  are  listed  in  the series file but not in .pc/applied-patches), and 
if the
| first patch in that set can be applied without errors, it will apply them 
all.  The
| option --no-preparation can be used to disable this behaviour.

But dpkg-source is only called when you build the source package so
it works for "debuild/debuild -S" but not for "debuild -b/debuild -B".

Cheers,
-- 
Raphaël Hertzog


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Odd patch behaviour [Was: quilt 3.0 source format and dpkg-source/dpkg-buildpackage]

2010-01-22 Thread Goswin von Brederlow 
tangke  writes:

> On 2010年01月20日 23:39, Goswin von Brederlow wrote:
>> Norbert Preining  writes:
>>
>>
>>> On Mo, 28 Dez 2009, Raphael Hertzog wrote:
>>>  
> Mind that git-buildpackage with normal 1.0 source format does NOT pollute
> the git repository, so my expectation is that the 3.0 format does the
> same, but alas, it doesn't.
>  
 Well, if you have the usual quilt rules, you working copy is also modified
 until the next debian/rules clean. Here the clean doesn't unapply the

>>> I disagree:
>>>
>>> $ ls ~/.gbp.conf
>>> ls: cannot access /home/norbert/.gbp.conf: No such file or directory
>>> $ git status
>>> # On branch master
>>> nothing to commit (working directory clean)
>>> $ git-buildpackage -us -uc -rfakeroot -S
>>> ...
>>> dpkg-buildpackage: source only, diff-only upload (original source NOT 
>>> included)
>>> Now running lintian...
>>> Finished running lintian.
>>> $ git status
>>> # On branch master
>>> nothing to commit (working directory clean)
>>> $
>>>
>>> So please tell me *what* has changed?
>>>
>>> Doing the same with source format 3.0 git status reports hundreds
>>> of differences.
>>>
>>> So please do not spread things that are not correct!
>>>  
>> He did say that with 3.0 (quilt) format the "clean" state is with
>> patches applied, like you get after dpkg-source -x. That part is
>> different to 1.0 format where "clean" would have patches unapplied.
>>
>> So when you go from 1.0 to 3.0 you will get a ton of files changed
>> after the first build + clean because now patches are applied.
>>
>> MfG
>>  Goswin
>>
> why not apply the patches when build automatically, and make clean to 
> unapply the patches?
> when I build the package, I must check quilt applied and quilt 
> unapplied, It's very trouble.
>
> thanks
>
> best regards.
>
> ta...@lemote.com

I was under the impression that build would always apply all missing
patches now that dpkg-source always creates a .pc dir. It certainly
does apply patches when none are applied.

% apt-get source mdadm
Reading package lists... Done
Building dependency tree   
Reading state information... Done
Need to get 469kB of source archives.
Get:1 http://chocos sid/main mdadm 3.0.3-2 (dsc) [1261B]
Get:2 http://chocos sid/main mdadm 3.0.3-2 (tar) [337kB]
Get:3 http://chocos sid/main mdadm 3.0.3-2 (tar) [131kB]
Fetched 469kB in 0s (1831kB/s)
dpkg-source: info: extracting mdadm in mdadm-3.0.3
dpkg-source: info: unpacking mdadm_3.0.3.orig.tar.gz
dpkg-source: info: unpacking mdadm_3.0.3-2.debian.tar.gz
dpkg-source: info: applying all patches with quilt push -q 
debian/conffile-location.diff
Applying patch fixes/udev-blkid.diff
Applying patch contrib/docs/raid5-vs-raid10.diff
Applying patch contrib/docs/superblock_formats.diff
Applying patch contrib/docs/md.txt.diff
Applying patch contrib/docs/jd-rebuilding-raid.diff
Applying patch debian/conffile-location.diff
Now at patch debian/conffile-location.diff

% cd mdadm-3.0.3 
% quilt pop 
Now at patch contrib/docs/jd-rebuilding-raid.diff
% debuild -us -uc
 dpkg-buildpackage -rfakeroot -D -us -uc -ICVS
dpkg-buildpackage: set CFLAGS to default value: -g -O2
dpkg-buildpackage: set CPPFLAGS to default value: 
dpkg-buildpackage: set LDFLAGS to default value: 
dpkg-buildpackage: set FFLAGS to default value: -g -O2
dpkg-buildpackage: set CXXFLAGS to default value: -g -O2
dpkg-buildpackage: source package mdadm
dpkg-buildpackage: source version 3.0.3-2
dpkg-buildpackage: source changed by martin f. krafft 
dpkg-buildpackage: host architecture amd64
 fakeroot debian/rules clean
dh_testdir
dh_testroot
rm -f debian/bugscript debian/mkconf
rm -f build-stamp
[ ! -f Makefile ] || /usr/bin/make clean
make[1]: Entering directory `/tmp/mdadm/mdadm-3.0.3'
rm -f mdadm mdmon mdadm.o config.o mdstat.o  ReadMe.o util.o Manage.o 
Assemble.o Build.o Create.o Detail.o Examine.o Grow.o Monitor.o dlink.o Kill.o 
Query.o Incremental.o mdopen.o super0.o super1.o super-ddf.o super-intel.o 
bitmap.o restripe.o sysfs.o sha1.o mapfile.o crc32.o sg_io.o msg.o 
platform-intel.o probe_roms.o mdmon.o monitor.o managemon.o util.o mdstat.o 
sysfs.o config.o Kill.o sg_io.o dlink.o ReadMe.o super0.o super1.o 
super-intel.o super-ddf.o sha1.o crc32.o msg.o bitmap.o platform-intel.o 
probe_roms.o pwgr.o core *.man \
mdadm.tcc mdadm.uclibc mdadm.static *.orig *.porig *.rej *.alt \
mdadm.Os mdadm.O2 \
mdassemble mdassemble.static mdassemble.auto mdassemble.uclibc \
mdassemble.klibc swap_super \
init.cpio.gz mdadm.uclibc.static test_stripe mdmon
make[1]: Leaving directory `/tmp/mdadm/mdadm-3.0.3'
rm -f mdadm.udeb mdadm
dh_clean
debconf-updatepo
 dpkg-source -ICVS -b mdadm-3.0.3
dpkg-source: info: using source format `3.0 (quilt)'
dpkg-source: warning: patches have not been applied, applying them now (use 
--no-preparation to override)
dpkg-source: info: applying all patches with quilt push -q 
debian/conffile-location.diff
Applying patc

Bug#566280: ITP: libcache-historical-perl -- cache simple data with time history

2010-01-22 Thread Mats Erik Andersson 
Package: wnpp
Severity: wishlist
Owner: Mats Erik Andersson 

* Package name: libcache-historical-perl
  Version : 0.03
  Upstream Author : Mike Schilli 
* URL : http://search.cpan.org/dist/Cache-Historical/
* License : GPL or Artistic
  Programming Lang: Perl
  Description : cache simple data with time history

 This perl module provides simple methods to store and search text values
 that are tied to a time and a key, like a user or a category. Each caching
 operation sets a time stamp, thus making it possible to search according
 to events in time. Like the name suggests, it was originally conceived
 for recording of historic events such as stock trading.
 .
 This module uses SQLite3 as database backend, thus leaving ample space
 for costumized additional tools to the same cached historic data.

-- System Information:
Debian Release: 5.0.3
  APT prefers stable
  APT policy: (500, 'stable'), (90, 'testing'), (80, 'unstable')
Architecture: i386 (i686)



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: graphicsmagick or imagemagick

2010-01-22 Thread Alexander E. Patrakov 

22.01.2010 16:41, Jérémy Lal wrote:

Hi,
my naïve questions for today :

1) is graphicsmagick really better than imagemagick ?
it advertises it's twice as fast, scales better, and 'contains'
imagemagick.


This fork was created primarily for legal/licensing reasons.


2) if so, why graphicsmagick is not widely used ?


I don't know. But it is still the fact.


The migration "looks" easy. I feel i'm missing something.


Yes. Vulnerabilities. For licensing reasons, they can't borrow patches 
from ImageMagick. And some not-so-competent bug reporters like myself 
report bugs only to ImageMagick lists, and thus bugfixes don't reach 
GraphicsMagick.


Look here for my posts:

http://studio.imagemagick.org/pipermail/magick-developers/2009-January

and also:

http://studio.imagemagick.org/pipermail/magick-developers/2009-March/003119.html

and see if any of the linked images still cause GraphicsMagick to 
misbehave (crash, access uninitialized variables, leak memory, or unpack 
pixels even if explicitly told to extract only image metadata).


--
Alexander E. Patrakov


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Bug#565675: ITP: pthsem -- pth replacement with semaphore support

2010-01-22 Thread Ralf S. Engelschall 

On 20.01.10 23:04, Martin Koegler wrote:

On Wed, Jan 20, 2010 at 10:06:21PM +0100, Julien Cristau wrote:

On Wed, Jan 20, 2010 at 21:04:30 +0100, Marc Leeman wrote:


I need pthsem, so I only want a working version with all features I
need.


All I care about is that there is an agreement between the Debian
community and the upstream developer. Martin is very active in
supporting his environment and in that respect I am to inclined to
support his decision.

Can we conclude that pthsem is a valid branch, worth a seperate package?

An alternative for Martin is probably to include/hide pthsem in bcusdk;
but that would not be as clean IMHO (ffmpeg anyone?)


If pthsem is pth + improvements, and pth is unmaintained both upstream
and in Debian, what's the advantage of changing the library/package
name?  I'm not sure we care if its homepage is at GNU or elsewhere.


I have no problem with renaming pthsem into pth, if this is wanted by
the "community". I don't want to do a hostile takeover of pth.

But this needs coordination with the other distributions shipping pth.
If one of the big distributions says no and still ships GNU pth, it
will only cause confusion.

I will not call the result "GNU pth", only pth. Calling it GNU will
probably only add restrictions/requirements, without any benefit.


This seems like a Debian related discussion. But as the author of
GNU Pth I can at least say that I've never heard of "pthsem"
myself (if I received any email, then, sorry, it seems it was
filtered by the anti-spam stuff) and also don't know why GNU Pth is 
considered unmaintained.


Sure, I've not released any newer versions since 2006, but as long
as nobody drops me a note that something is broken there is no
requirement for any new releases. I'm using it at least under
the latest versions of FreeBSD, Linux and Solaris since years.
The functionality of GNU Pth is fully complete (at least to the
extend I originally planned at about 2004) since 2006 and
version 2.0.x.

Over the last 10 years we have seen half a dozen forks of
GNU Pth (for various addon functionalities or whatever), but they
were at least never named "GNU Pth" or just "Pth". If the current
name of this fork is "pthsem", please keep it this way. But please avoid 
naming it (or its Debian package) just "pth". Thanks.


If "pthsem" is really fully backward compatible to GNU Pth,
then we can even check whether we can include its functionality into
GNU Pth, too. Where do I find its latest sources? Is is the one
under http://www.auto.tuwien.ac.at/~mkoegler/index.php/pth?

   Ralf S. Engelschall
   r...@engelschall.com
   www.engelschall.com


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Zapytanie

2010-01-22 Thread kartkowo.net 
Witam!
Chcia³bym spytaæ czy istnieje mo¿liwoœæ, aby wysy³aæ do Ciebie informacje o 
zmianach w serwisie kartkowo.net - serwis umo¿liwia otrzymywanie kartek 
pocztowych za darmo od innych u¿ytkowników serwisu. Oczywiœcie nie musisz siê 
zgadzaæ na otrzymywanie mailingu - wtedy po prostu nie odpowiadaj na t¹ 
wiadomoϾ.
Pozdrawiam,
Autor serwisu

Bug#566313: ITP: ipheth -- Linux kernel driver that adds support for iPhone tethering

2010-01-22 Thread Paul McEnery 
Package: wnpp
Severity: wishlist
Owner: Paul McEnery 


* Package name: ipheth
  Version : 0.1
  Upstream Author : Diego Giagio 
  Upstream Author : Daniel Borca 
* URL : http://giagio.com/wiki/moin.cgi/iPhoneEthernetDriver
* License : (GPL, BSD)
  Programming Lang: C
  Description : Linux kernel driver that adds support for iPhone tethering

Provides a Linux kernel driver that adds support for iPhone tethering through
USB cables. Unlike other solutions out there, you don't need to jailbreak your
phone or install third-party proxy applications.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Next week in Dubai, Finance for Non-Finance Professionals Course

2010-01-22 Thread Finance For Non Finance 

This email newsletter was sent to you in graphical HTML format.
If you're seeing this version, your email program prefers plain text emails.
You can read the original version online:
http://ymlp129.com/zrcVPo



Dear colleagues,

It is our pleasure to remind you about

Finance for Non-Finance Professionals Course

In Dubai from 1 - 5 Febuary 2010

Our courses are certified from: Cambridge Regional College

View materials sample
http://cvlearn.com/Finance1.aspx

For further assistance, please contact us at:

market...@cvlearn.com

Fax: +966(3) 8476146

Mobile: +966 505 844 134

www.cvlearn.com

_
Links to our online courses:

Absolute Vs Comparative advantage in international trade:
http://mba.articulate-online.com/6316888759

Linear Programming:
http://mba.articulate-online.com/6316862162

Metformin:
http://mba.articulate-online.com/6316897033

Digoxin Pharmacokinetics:
http://mba.articulate-online.com/6316856624

_
Change email address / Leave mailing list: 
http://ymlp129.com/u.php?YMLPID=guquhemgsgjbqhujg
Powered by  YourMailingListProvider

Re: Is tabular data in binary format acceptable for Debian ?

2010-01-22 Thread Charles Plessy 
Le Thu, Jan 21, 2010 at 06:14:15PM -0800, Steve Langasek a écrit :

> reading your message made me worry that the ftp team were moving the
> line for archive acceptance without discussion, when reading the bug log
> shows that they're simply trying to determine on which side of the existing
> line these files fall.
> 
> I would suggest that you add documentation to the source package in
> debian/copyright

The archive administrators are trying to determine if the files are DFSG-free,
have asked three times more information (here is the third time
(http://lists.alioth.debian.org/pipermail/debian-med-packaging/2009-December/005336.html)
and despite all our answers are not giving their conclusion. It is my opinion
that if their conclusion is that the file is non-free, they move the line for
archive acceptance.

The whole thread can be stopped by one member of the FTP team writing ‘Go
ahead, these files are free.’ As I demonstrated earlier, there are too many
human errors to take the acceptance of the package as a silent confirmation
that the files are free. Also, the next upload may contain some ASCII dumps of
the tables, just in case. So we may not be able to conclude.

I do not see why we would need to add extra information in debian/copyright (by
the way, aren't we suppose to work on a format that helps the maintainers to
waste less time with that file?). If such a documentation were necessary for
r-cran-epir, why would it be dispensable for the other packages in the archive,
like r-cran-rocr ? Also, shall we add one for the PDF documentation as well ?
The archive administrators did not find their source at the first review…

We do need clear answers and guidelines to acheive consistency, that puts some
sense in our efforts. If it is an archive-wide request to add a disclaimer for
the .Rdata files that contain tables, explaining that despite being part of
Debian they are not non-free, I will obey despite disagreeing. But just making
and ad-hoc rule that applies to only one package does not make much sense in my
opinion.

Lastly, it is relevant that these files are not intended to be modified: as
reminded by Don, it is contrary to the idea of free software if the upstream
authors would keep for themselves a file that facilitates the edition of one
component of the software. For components that are not expected to be modified,
who cares if it at the first modification (and only the first) it takes half an
hour instead of ten minutes? My experience of long-term relations with
upstream is that they start on much better grounds if we contact them with good
news about the distribution of their works or with useful patches, rather than
with futile requests.

Have a nice day,

-- 
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

Bug#566346: ITP: krb5-appl - Kerberos applications and clients

2010-01-22 Thread Sam Hartman 
package: wnpp
severity: wishlist
owner: hartm...@debian.org

name: krb5-appl
URL: http://web.mit.edu/kerberos/dist/krb5-appl
License: MIT Kerberos license 
(roughly MIT license plus a requirement that if you modify the
software you must mark it as modified)
description: Contains fairly ancient versions of telnetd, ftpd, rsh and
rlogin that support Kerberos authentication

Up until the upcoming Kerberos 1.8 release, these applications were part
of the main krb5 tree.  They are kind of old and crufty, but attempts to
kill them off have met with users (and Debian users) who say they are
still valuable in certain environments.  Reasons cited include that the
code base is simpler than things like ssh, it works and is in use, etc.
My belief that the security of the rsh and rlogin programs is quite
good, although the telnet and telnetd are well below current security
standards.

However upstream krb5 doesn't want to maintain the applicatinos as part
of the main source tree.  So, they are being split out.  Since Debian
users still want them, I'm going to package them.  They've been in
Debian for years already, so I think this should not be a problem.

To look at the WIP packages see
git://git.debian.org/git/pkg-k5-afs/debian-krb5-appl.git


pgpzgsy54Ey9T.pgp
Description: PGP signature

Re: What criteria does ftpmaster use for the ‘copyright’ file of a package?

2010-01-22 Thread Charles Plessy 
Le Fri, Jan 22, 2010 at 02:48:39PM +1100, Ben Finney a écrit :
> 
> Especially in combination with your later points (that the copyright
> notices can't be “corrected”, which I take to imply that aggregation and
> re-phrasing of the notices is also verboten), there seems to be little
> point reproducing the verbatim copyright *notices*, especially since
> they're all in the source regardless.

Dear all,

Given that the patch that is being rushed in the Policy (#566220) does not
clarify what is meant by “verbatim”, I urge the Policy maintainers or the
archive administrators to confirm if and when aggregation of the copyright
notices is permitted.

Alternatively, we could start a GR to at last find an exit to this endless
debate (In that case, I would propose that the only requirement is to respect
the license and the copyright laws, and that any extra is welcome but
optional).

Have a nice day,

-- 
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

Re: What criteria does ftpmaster use for the ‘cop yright’ file of a package?

2010-01-22 Thread Russ Allbery 
Charles Plessy  writes:
> Le Fri, Jan 22, 2010 at 02:48:39PM +1100, Ben Finney a écrit :

>> Especially in combination with your later points (that the copyright
>> notices can't be “corrected”, which I take to imply that aggregation
>> and re-phrasing of the notices is also verboten), there seems to be
>> little point reproducing the verbatim copyright *notices*, especially
>> since they're all in the source regardless.

> Dear all,

> Given that the patch that is being rushed in the Policy (#566220) does not
> clarify what is meant by “verbatim”,

That's because there isn't a precise definition in existing practice, and
the purpose of that change is to document existing practice unless and
until we reach some consensus for changing it.  Not to set some new
standard other than what we've historically followed.  The current
practice is that verbatim is not a clearly defined term and people are
using a common-sense, and imprecise, definition.

Incidentally, don't you think it's a little inaccurate and melodramatic to
describe as "rushed" something that hasn't even been committed to a Git
repository yet, let alone put into any sort of release, and whose only
action so far has been some discussion and three seconds?

-- 
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

Re: Bug#566220: What criteria do es ftpmaster use for the ‘copyright ’ file of a package?

2010-01-22 Thread Charles Plessy 
Le Fri, Jan 22, 2010 at 07:11:23PM -0800, Russ Allbery a écrit :

> The current practice is that verbatim is not a clearly defined term and
> people are using a common-sense, and imprecise, definition.

Then let's face the complex reality and document what you described in the 
Policy. What is sure is that the practice does not enforce “verbatim”
stricto-sensu. We could write ‘copyright notices must be reproduced in
debian/copyright; they can be agregated to a degree that is left to the
appreciation of the archive administrators’.

Anyway, I think that I have taken my decision and will propose a GR later. We
wasted already too much time on this issue. Not everybody has the same common
sense, so we need clear guidelines.

Have a nice day,

-- 
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

Re: Bug#566220: What criteria do es ftpmaster use for the ‘copyright ’ file of a package?

2010-01-22 Thread Steve Langasek 
On Sat, Jan 23, 2010 at 01:10:23PM +0900, Charles Plessy wrote:
> Le Fri, Jan 22, 2010 at 07:11:23PM -0800, Russ Allbery a écrit :

> > The current practice is that verbatim is not a clearly defined term and
> > people are using a common-sense, and imprecise, definition.

> Then let's face the complex reality and document what you described in the 
> Policy. What is sure is that the practice does not enforce “verbatim”
> stricto-sensu. We could write ‘copyright notices must be reproduced in
> debian/copyright; they can be agregated to a degree that is left to the
> appreciation of the archive administrators’.

The patch that has been submitted to Policy is to eliminate a single
ambiguity in the wording that permits a particular twisted interpretation of
the phrase "verbatim copy of its copyright and distribution license" which
is historically incorrect.  I believe this is orthogonal to any question of
what the policy *should* be, or whether the enforcement of this rule has
been strict and consistent.

Do you disagree with my assertion that this is what the current Policy text
*means* (has always meant)?

> Anyway, I think that I have taken my decision and will propose a GR later. We
> wasted already too much time on this issue. Not everybody has the same common
> sense, so we need clear guidelines.

Why do you think this should be clarified by a GR, rather than through the
Policy process?  Except where it intersects with the legal requirements of
licenses, the contents of debian/copyright are, AFAICS, a technical policy
that don't require ratification by the project.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Re: Is tabular data in binary format acceptable for Debian ?

2010-01-22 Thread Steve Langasek 
On Sat, Jan 23, 2010 at 11:38:42AM +0900, Charles Plessy wrote:
> Le Thu, Jan 21, 2010 at 06:14:15PM -0800, Steve Langasek a écrit :

> > reading your message made me worry that the ftp team were moving the
> > line for archive acceptance without discussion, when reading the bug log
> > shows that they're simply trying to determine on which side of the existing
> > line these files fall.

> > I would suggest that you add documentation to the source package in
> > debian/copyright

> The archive administrators are trying to determine if the files are DFSG-free,

Are you sure that's what they're trying to determine?

License review in NEW consists of two questions:

  - Can we distribute it?
  - Does its license meet the DFSG?

If these files are made available under the terms of the GPL, then
determining whether these files are the source is related to the *first*
question, not the second.

> (http://lists.alioth.debian.org/pipermail/debian-med-packaging/2009-December/005336.html)
> and despite all our answers are not giving their conclusion. It is my opinion
> that if their conclusion is that the file is non-free, they move the line for
> archive acceptance.

Indeed, the DFSG does not require inclusion of source code for anything that
isn't a program.  If the ftp masters are imposing such a requirement,
that's a bug which should be addressed by a GR; but there's insufficient
evidence to conclude that this is what's happening here.  The simpler
explanation, given what I've read, is that they're guarding against license
violations.

> The whole thread can be stopped by one member of the FTP team writing ‘Go
> ahead, these files are free.’

Then you should be cc:ing the ftpmasters, not just posting on debian-devel.

Or, you can use the standard method of getting the ftp team's attention, and
upload the package to the NEW queue making sure to provide the information
that the ftp team found lacking in the previous upload.

> I do not see why we would need to add extra information in
> debian/copyright

Because inline documentation is a good thing, and the ftp team's questions
demonstrate that it's not self-evident that the package is distributable.
Because the package might have to go through NEW again in the future, and
it'll be far more pleasant for everyone if the explanation is immediately to
hand when the package is being reviewed by some other member of the ftp team
years from now.  Because it sets a good example for other packages.

I'm not saying that including this information in debian/copyright should be
(or is) a condition of the package being accepted into Debian; I'm saying
that I think it's a sensible thing to do in its own right, and, barring the
ftp team overstepping their authority, has the added benefit of getting the
package past NEW without further waffling on the mailing lists.

> (by the way, aren't we suppose to work on a format that helps the
> maintainers to waste less time with that file?).

Well, I don't believe DEP5 is going to save maintainers time.  If anything,
I think it'll probably be a wash.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

please add my Id for Links Exchange

2010-01-22 Thread Anika seo partner 
HI Dear,

please add my ID for Link Ex.

i have new Back links.

-- 


*Best Regards*
Anika
(¨`•.•´¨) Always
`•.¸(¨`•.•´¨) Keep
(¨`•.•´¨)¸.•´ Smiling!
`•.¸.•´

Thank you Very much.:)

Bug#566358: RFA: d-shlibs -- Debian shared library package building helper scripts

2010-01-22 Thread Junichi Uekawa 
Package: wnpp
Severity: normal


Description: Debian shared library package building helper scripts
 Shared library packages in Debian need some special catering to do
 with regards to which files go where. This package contains
 programs which try to help automate the process and catch simple
 errors
 .
 "d-shlibmove" moves the shared library binary around from temporary
 installation directory to the  destination package directory
 .
 "d-devlibdeps" tries to list the development library dependencies
 required for using the -dev package.





-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#566364: RFH: doc-central

2010-01-22 Thread Charles Plessy 
Package: wnpp
Severity: normal

Dear Robert and everybody,

The native package doc-central looks abandonned by its listed maintainer,
Guilherme de S. Pastore (gpastore), whose last upload was four years ago.  It
currently has 298 popcon users, and has been updated two times in NMU by Robert
Luberda, who kept the package alive for the Lenny release.

doc-central has one release-critical bug, making it unfit for the release. Are
there volunteers to adopt it? Robert? The QA team? Otherwise, despite it is
useful, it is maybe time to give up and remove it from our archive...

Only two packages recommend doc-central, libsuitesparse-doc and gnumed-client.
I have filed bugs on them to loosen the dependancy to suggest or drop it, since
these package do not particuarly need doc-central and it is already suggested
by the doc-base package.

Have a nice day,

--
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