Re: Clarifying the mandatory contents of the Debian copyright file.

[Chow Loong Jin]

On 18/01/2012 10:09, Peter Miller wrote:
> Are there any plans to write a tool to scan a project tree and generate
> the DEP-5 debian/copyright file?

I personally use:
$ licensecheck --copyright -r . | /usr/lib/cdbs/licensecheck2dep5 > 
debian/copyright

And then manually modify debian/copyright to compress entries to satisfaction.

There's also a bug regarding merging the two scripts together:


-- 
Kind regards,
Loong Jin



signature.asc
Description: OpenPGP digital signature

Re: dpkg-source again broken wrt to 3.0 (quilt)???

[Bernhard R. Link]

* Norbert Preining  [120118 03:08]:
> On Mi, 18 Jan 2012, Jakub Wilk wrote:
> > Wait, are you patching files inside debian/? That won't fly.
>
> Umpf, and, is that so evil?

One of the problems "3.0 (quilt)" solves is upstream tarballs already
having a debian/ directory. By having the complete debian/ contents
in the .debian.tar.gz and the unpacking replacing any upstream debian
directory with those contents, the maintainer of the Debian package does
not have to care what upstream placed there[1] and any automated tool
looking for debian information (like copyright or changelog) can extract
this information in an easy way from a well specified location [2].

Once you start with the new contents of debian/, what is a patch of
those files supposed to do? Either it is already applied or the package
was not in proper state while building...

> Esp for a NMU this is *very* good
> as it allows to see what the changes of the NMU are ...
> 
> Not that I am patching debian/control or debina/rules ...

So you suggest that someone interested at what this NMU does needs to
compare the two debian/ directories (of the old and the new package)
for changes in control, rules and changelog but then read some other
changes of the same directory in the form of a patch places in the
same directory?

I'd say that is the exactly opposite of "allows to see what the changed
of the NMU are".

So to answer you question: Yes, it is that evil.


Bernhard R. Link

[1] especially debhelper likes to behave differently if some file is
there or not, so left over files can have ugly consequences.
[2] the .orig.tar is hard to cope with, as it must allow pristine
upstream files which can have quite a variety and absurdity in them.
And having information split in the form of some content in the one file
and a diff in the other file is hard, too. (You either need to do a full
unpack or restrict to the case the information is either fully in the
one or in the other like e.g. reprepro and changestool do to get Section
and Priority information from a .dsc).


-- 
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/20120118082728.ga1...@server.brlink.eu

Re: dpkg-source again broken wrt to 3.0 (quilt)???

[Mehdi Dogguy]

On 18/01/12 03:08, Norbert Preining wrote:

On Mi, 18 Jan 2012, Jakub Wilk wrote:

Wait, are you patching files inside debian/? That won't fly.


Umpf, and, is that so evil? Esp for a NMU this is *very* good as it
allows to see what the changes of the NMU are ...



You're supposed to send a debdiff when NMUing. That's even better to see
what the changes of the NMU are (See devref §5.11.1). Personally, I find
patching files under debian/ directory makes things more difficult to
track (probably because I don't expect to find those changes there).

Regards,

--
Mehdi Dogguy


--
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/4f168bbb.3040...@dogguy.org

Re: Patch Tagging Guidelines: DEP-3 moved to ACCEPTED status

[Dominique Dumont]

Le Monday 16 January 2012 19:15:07, Jakub Wilk a écrit :
> Does a DEP-3 parser exist? And why not?

config-edit -appli dpkg (soon to become 'cme edit dpkg') is able to parse, 
modify and save DEP-3 patches ( note that this command also deal with 
debian/copyright, debian/control and some other debian files).

This command is part of libconfig-model-perl package

HTH

Dominique
--
http://config-model.wiki.sourceforge.net/ -o- http://search.cpan.org/~ddumont/
http://www.ohloh.net/accounts/ddumont -o- http://ddumont.wordpress.com/


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

Re: Clarifying the mandatory contents of the Debian copyright file.

[Dominique Dumont]

Le Wednesday 18 January 2012 09:03:14, Chow Loong Jin a écrit :
> I personally use:
> $ licensecheck --copyright -r . | /usr/lib/cdbs/licensecheck2dep5 >
> debian/copyright
> 
> And then manually modify debian/copyright to compress entries to
> satisfaction.

Oooh, that's a good one. I'll probably reuse all that stuff to propose a 
default debian/copyright file with config-edit/soon-to-be-cme 

Thanks 

Dominique
--
http://config-model.wiki.sourceforge.net/ -o- http://search.cpan.org/~ddumont/
http://www.ohloh.net/accounts/ddumont -o- http://ddumont.wordpress.com/


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

Re: Clarifying the mandatory contents of the Debian copyright file.

[Peter Miller]

On Wed, 2012-01-18 at 16:03 +0800, Chow Loong Jin wrote:
> $ licensecheck --copyright -r . | /usr/lib/cdbs/licensecheck2dep5 > 
> debian/copyright

That is just what I was looking for, although I doubt I'll be editing
the output, just adding it to my build system, next to where I build the
Debian package for Continuous Integration (even though it's "upstream"
at that point).

I think this information should be highlighted in
http://dep.debian.net/deps/dep5/


-- 
Peter Miller 


--
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/1326883309.2413.80.camel@hawk

Re: Clarifying the mandatory contents of the Debian copyright file.

[Peter Miller]

On Tue, 2012-01-17 at 20:01 -0800, Russ Allbery wrote:
> Peter Miller  writes:
> 
> > My understanding is that all project files are covered, although
> > wildcards are permitted.
> 
> > Each different copyright x license combination needs its own separate
> > entry.
> 
> I don't think this is the case.  [...]

> I am absolutely certain that this is not the intention of DEP-5, and I
> would be in favor of modifying it to make that clear if you could identify
> the places where you got that mistaken impression.

http://dep.debian.net/deps/dep5/

"Files paragraph (Repeatable)

"The declaration of copyright and license for files is done in
one or more paragraphs. In the simplest case, a single paragraph
can be used which applies to all files and lists all applicable
copyrights and licenses."

It says "all applicable copyrights and licenses".  Note the "and".   To
me, in a standards context, this means conjunction (logical and) not
disjunction (logical or).

If there was some other intent, the words don't say it.  Note there are
*three* potentially ambiguous lists in that definition, they *all* need
to be disambiguated in the language of DEP-5.

Look at it from the other perspective:
(a) given filename X, what license(s) apply?  Does DEP-5, by conflating
copyrights and licenses, risk returning too many licenses? inapplicable
licenses?
(b) given filename X, what copyright(s) apply?  Does DEP-5, by
conflating copyrights and licenses, risk returning too many copyrights?
inapplicable copyrights?

One solution may be to separate it into two paragraphs, one for
applicable copyrights, and one for applicable licenses.  That is, you
can have "Files:" && "Copyright:" || "Files:" && "License:", but you
can't have "Files:" && "Copyright:" && "License:"

While I'm banging on about semantics, when you are looking up a file by
name, is it the first file name pattern match that applies, or the last,
or do all of them?  It doesn't say.

English is sloppy be default.  Standards language should try very had
not to be, even optional standards.

-- 
Peter Miller 


--
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/1326882967.2413.75.camel@hawk

Re: Clarifying the mandatory contents of the Debian copyright file.

[Simon Josefsson]

Russ Allbery  writes:

>> Note that "Copyright (C) 2008 Peter Miller" is different than "Copyright
>> (C) 2011 Peter Miller" is different than "Copyright (C) 1991, 2012 Peter
>> Miller", so the cross product is going to be substantial for long lived
>> projects, even when the number of contributors is small.
>
> I am absolutely certain that this is not the intention of DEP-5, and I
> would be in favor of modifying it to make that clear if you could identify
> the places where you got that mistaken impression.

I would support making this clearer by adding the example above to DEP5.
When I have written DEP5 copyright files, I have been uncertain about
this aspect too, but I can't point to anything directly in the document
that gave me this impression (nor to anything that would have given me
the reversed impression).  An example would probably have helped.

Thinking even further, maybe there should be a tutorial at the end of
DEP5 on how to convert an existing compliant debian/copyright file into
a DEP5-compliant debian/copyright file.  As far as I understand from
this discussion, it would be sufficient to merely make it syntactically
conform to the DEP5 file format, typically by folding the old data under
a 'Files: *' header.  If this is the case, and there is an example on
how to do it, this could trigger more DEP5 adoption.

/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/87hazt8g5w@latte.josefsson.org

Re: Clarifying the mandatory contents of the Debian copyright file.

[Josue Abarca]

On Wed, Jan 18, 2012 at 09:36:07PM +1100, Peter Miller wrote:
> On Tue, 2012-01-17 at 20:01 -0800, Russ Allbery wrote:
> > Peter Miller  writes:
...
> While I'm banging on about semantics, when you are looking up a file by
> name, is it the first file name pattern match that applies, or the last,
> or do all of them?  It doesn't say.
...

About this:

http://dep.debian.net/deps/dep5/#files-field

"Files
...
Multiple Files paragraphs are allowed. The last paragraph that
matches a particular file applies to it."


-- 
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/20120118110653.GA6538@numenor.numenor

Re: Clarifying the mandatory contents of the Debian copyright file.

[Charles Plessy]

Le Wed, Jan 18, 2012 at 04:03:14PM +0800, Chow Loong Jin a écrit :
> On 18/01/2012 10:09, Peter Miller wrote:
> > Are there any plans to write a tool to scan a project tree and generate
> > the DEP-5 debian/copyright file?
> 
> I personally use:
> $ licensecheck --copyright -r . | /usr/lib/cdbs/licensecheck2dep5 > 
> debian/copyright
> 
> And then manually modify debian/copyright to compress entries to satisfaction.

Dear Peter and Chow,

In my experience, licensecheck has false positives and false negatives.  Please
be sure to validate its results with an independant method.

In my packaging workflow, I am usually taking the reverse approach as you do: I
generate the Debian copyright file by hand (guided by grep), and then confront
the result to the output of licensecheck.

This said, both ways are a matter of preference, as long as there is
proofreading.

The licensecheck to DEP 5 converter may also be even more useful if it could be
implemented as a lintian check, that would for instance verify that no new
license is missed when upgrading a package.  Sometimes, non-free files try to
sneak in…

In the future, there will be a safe (but possibly time-consumming) way to
autogenerate a machine-readable Debian copyright file: exhaustively document
all the files following the SPDX standard, and then convert from this format.
See for instance Ubuntu's project on the matter.

  
https://blueprints.launchpad.net/ubuntu/+spec/foundations-p-machine-readable-copyrights

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
Archive: http://lists.debian.org/20120118113113.gd26...@merveille.plessy.net

Re: Clarifying the mandatory contents of the Debian copyright file.

[Jonas Smedegaard]

On 12-01-18 at 08:31pm, Charles Plessy wrote:
> Le Wed, Jan 18, 2012 at 04:03:14PM +0800, Chow Loong Jin a écrit :
> > On 18/01/2012 10:09, Peter Miller wrote:
> > > Are there any plans to write a tool to scan a project tree and generate
> > > the DEP-5 debian/copyright file?
> > 
> > I personally use:
> > $ licensecheck --copyright -r . | /usr/lib/cdbs/licensecheck2dep5 > 
> > debian/copyright
> > 
> > And then manually modify debian/copyright to compress entries to 
> > satisfaction.
> 
> Dear Peter and Chow,
> 
> In my experience, licensecheck has false positives and false 
> negatives.  Please be sure to validate its results with an independant 
> method.

Good point.

That's also the reason licensecheck2dep5 adds a FIXME to each and every 
section of its output: Not to be trusted as-is - requires proofreading!


> The licensecheck to DEP 5 converter may also be even more useful if it 
> could be implemented as a lintian check, that would for instance 
> verify that no new license is missed when upgrading a package.  
> Sometimes, non-free files try to sneak in…

Would be nice indeed.

Currently, licensecheck2dep5 when used with cdbs does something similar: 
warns during build (not independently as lintian does) if an included 
auto-generated file lacks entries from a freshly autogenerated one.

Yes, I really should do as promised in bug#472199 and integrate 
licensecheck2dep5 with licensecheck itself to have more parts of its 
functionality available independent from CDBS.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: Digital signature

Re: dpkg-source again broken wrt to 3.0 (quilt)???

[Norbert Preining]

On Mi, 18 Jan 2012, Raphael Hertzog wrote:
> It would be nice if you could avoid the "flaming tone" in all your mails.
> In particular since most of the time it ends up being a mistake of yours.

And it would be nice if dpkg-buildpackage gives a decent error message.
What is shipped here is plain incomprehensible. 

How should I *guess* that patching files in debian is not allowed in
quilt (3.0), since it was in older versions (I am quite sure you remeber
that) of source standards.

Am I supposed to dig into the source of dpkg-buildpackage/dpkg-source?

> But if the debian directory already contains changes which are part of the
> patches, then it will fail trying to re-apply those changes.

So well, but if out of some crazy reasin I *want* to do that, then 
dpkg-* should tell me: Sorry, this is not possible with quilt (3.0),
please go back to 1.0 source format (which was anyway a better IMHO).

Since we are at quilt 3.0 bashing: Maybe you can give me a rational
why I *ALWAYS* have to type in
export QUILT_PATCHES=debian/patches
before working with debian source packages?  And when I forget it
I get hurt by quilt?

Is this the *easy*handling* as promised?

And NO, I wil lnot set this by default in my env, since I am working
with quilt in several other projects out of debian, and I cannot afford
getting even worse bitten.

> There's a lintian error for this if for some reason you still manage to
> build it:

No I didn't managed, as I wrote.

Best wishes

Norbert

Norbert Preiningpreining@{jaist.ac.jp, logic.at, debian.org}
JAIST, Japan TeX Live & Debian Developer
DSA: 0x09C5B094   fp: 14DF 2E6C 0307 BE6D AD76  A9C0 D2BF 4AA3 09C5 B094

SHOEBURYNESS (abs.n.) The vague uncomfortable feeling you get when
sitting on a seat which is still warm from somebody else's bottom.
--- Douglas Adams, The Meaning of Liff


-- 
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/20120118131827.gb11...@gamma.logic.tuwien.ac.at

Re: dpkg-source again broken wrt to 3.0 (quilt)???

[Stefano Rivera]

Hi Norbert (2012.01.18_15:18:27_+0200)
> Since we are at quilt 3.0 bashing: Maybe you can give me a rational
> why I *ALWAYS* have to type in
>   export QUILT_PATCHES=debian/patches
> before working with debian source packages?

Because you haven't set up a .quiltrc? The maint-guide has a really nice
example you can steal.

SR

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  H: +27 21 465 6908 C: +27 72 419 8559  UCT: x3127


-- 
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/20120118132425.gb14...@bach.rivera.co.za

Re: dpkg-source again broken wrt to 3.0 (quilt)???

[Norbert Preining]

On Mi, 18 Jan 2012, Stefano Rivera wrote:
> Because you haven't set up a .quiltrc? The maint-guide has a really nice
> example you can steal.

Ugg, and call dquilt or quilt --quiltrc=... yeah
I will try to remember that, and will forget it as well as I forget
setting QUILT_PATCHES

Thanks, that was not helpful

Best wishes

Norbert

Norbert Preiningpreining@{jaist.ac.jp, logic.at, debian.org}
JAIST, Japan TeX Live & Debian Developer
DSA: 0x09C5B094   fp: 14DF 2E6C 0307 BE6D AD76  A9C0 D2BF 4AA3 09C5 B094

NOTTAGE (n.)
Nottage is the collective name for things which you find a use for
immediately after you've thrown them away. For instance, your
greenhouse has been cluttered up for years with a huge piece of
cardboard and great fronds of gardening string. You at last decide to
clear all this stuff out, and you burn it. Within twenty-four hours
you will urgently need to wrap a large parcel, and suddenly remember
that luckily in your greenhouse there is some cardb...
--- Douglas Adams, The Meaning of Liff


-- 
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/20120118133125.gc11...@gamma.logic.tuwien.ac.at

Re: dpkg-source again broken wrt to 3.0 (quilt)???

[Cyril Brulebois]

Norbert Preining  (18/01/2012):
> On Mi, 18 Jan 2012, Raphael Hertzog wrote:
> > It would be nice if you could avoid the "flaming tone" in all your mails.
> > In particular since most of the time it ends up being a mistake of yours.
> 
> And it would be nice if dpkg-buildpackage gives a decent error message.
> What is shipped here is plain incomprehensible. 

I'd like to echo Raphael's wishes here. Please stop yelling on this
mailing list, and start filing bugs, possibly with patches, to implement
the missing bits.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: dpkg-source again broken wrt to 3.0 (quilt)???

[Jakub Wilk]

* Norbert Preining , 2012-01-18, 22:18:
Since we are at quilt 3.0 bashing: Maybe you can give me a rational why 
I *ALWAYS* have to type in

export QUILT_PATCHES=debian/patches
before working with debian source packages?  And when I forget it I get 
hurt by quilt?


dpkg (>= 1.15.8.6) creates the .pc/.quilt_series file. So no, not always.

--
Jakub Wilk


--
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/20120118133523.ga6...@jwilk.net

Re: from / to /usr/: a summary

[Goswin von Brederlow]

Thomas Goirand  writes:

> On 12/22/2011 07:07 PM, Russell Coker wrote:
>> It seems to me that wanting to have / outside LVM but /usr inside LVM is a 
>> fairly obscure corner case.
> I have about 100 servers setup this way, and my laptops as well. I really
> don't see why this would be a corner case. Please understand that many
> different people have many different configuration, and that in today's
> Debian, *absolutely everything is allowed*, and never, ever, Debian said
> that one type of setup would one day be forbidden.
>
> Taking decisions that some setup are "not supported" would be a bad move
> whatever the partitioning we are talking about. Please don't do that,
> there's no reason why Debian would take such move.
>
> Thomas

The reason for such a setup is, historically, so that you could boot
without initramfs. A small / (including /boot) to boot from and start up
lvm before mounting /usr, /var and /home.

Prior to grub2, which can now boot from LVM directly, this was a verry
sensible setup.

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/87sjjd9knn.fsf@frosties.localnet

Re: Switching /etc/mtab to /proc/mounts and removing /lib/init/rw

[Goswin von Brederlow]

jida...@jidanni.org writes:

> Forty years of pleasant df(1) and mount(1) reading shattered in one day,
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=653073

Any update on why the root filesystem is listed by UUID? Is that a
problem of busybox mount reporting the long device name to the kernel
why real mount uses the short one?

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/87obu19kc9.fsf@frosties.localnet

Re: dpkg-source again broken wrt to 3.0 (quilt)???

[Raphael Hertzog]

On Wed, 18 Jan 2012, Norbert Preining wrote:
> On Mi, 18 Jan 2012, Raphael Hertzog wrote:
> > It would be nice if you could avoid the "flaming tone" in all your mails.
> > In particular since most of the time it ends up being a mistake of yours.
> 
> And it would be nice if dpkg-buildpackage gives a decent error message.

[... snip useless flames ...]

> > But if the debian directory already contains changes which are part of the
> > patches, then it will fail trying to re-apply those changes.
> 
> So well, but if out of some crazy reasin I *want* to do that, then 
> dpkg-* should tell me: Sorry, this is not possible with quilt (3.0),

Please submit a wishlist bug for this.

> Since we are at quilt 3.0 bashing

You decide whether you're doing useless bashing or constructive
discussion... and we would be all better off if you picked the second
choice.

> : Maybe you can give me a rational
> why I *ALWAYS* have to type in
>   export QUILT_PATCHES=debian/patches
> before working with debian source packages?  And when I forget it
> I get hurt by quilt?

First, this is not true. As pointed out by Jakub, dpkg-source -x sets up
the .pc directory so that quilt knows where to find the series file and
the patches.

Then, for the cases where you end up without this directory, you could
follow the advice of /usr/share/doc/quilt/README.source which provides
a .quiltrc snippet that only sets QUILT_PATCHES if you're within a Debian
source package...

RTFM, man.

> Is this the *easy*handling* as promised?

If you have an unpacked source package with all patches already applied,
the easy handling is to just do your changes and then run "dpkg-source
--commit". It will create and register the patch for you.

> And NO, I wil lnot set this by default in my env, since I am working
> with quilt in several other projects out of debian, and I cannot afford
> getting even worse bitten.

The recommended snippet does avoid this problem...

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Pre-order a copy of the Debian Administrator's Handbook and help
liberate it: http://debian-handbook.info/liberation/


-- 
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/20120118141110.ga27...@rivendell.home.ouaza.com

Re: Switching /etc/mtab to /proc/mounts and removing /lib/init/rw

[Roger Leigh]

clone 653073 -1
retitle -1 df: [patch] Please ignore rootfs in df output
reassign -1 coreutils
thanks

On Wed, Jan 18, 2012 at 03:05:58PM +0100, Goswin von Brederlow wrote:
> jida...@jidanni.org writes:
> 
> > Forty years of pleasant df(1) and mount(1) reading shattered in one day,
> > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=653073
> 
> Any update on why the root filesystem is listed by UUID? Is that a
> problem of busybox mount reporting the long device name to the kernel
> why real mount uses the short one?

This needs to be investigated by Dan, as I requested in the report.
It's just a matter of looking at what is really happening in the
initramfs with e.g. break=init-bottom.

I'll clone this into a separate bug against df/coreutils for Joey's
rootfs patch.  The bug is not a bug in initscripts; it should be
reassigned to klibc, busybox or initramfs-tools as appropriate.


Thanks,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?   http://gutenprint.sourceforge.net/
   `-GPG Public Key: 0x25BFB848   Please GPG sign your mail.


-- 
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/20120118141836.gy9...@codelibre.net

Re: dpkg-source again broken wrt to 3.0 (quilt)???

[Paul Wise]

On Wed, Jan 18, 2012 at 9:13 AM, Jakub Wilk wrote:

> Wait, are you patching files inside debian/? That won't fly.

I've personally missed this feature for a package I need to patch
outside of Debian. When it was dpkg-source v1 I could just drop in the
patches/series and everything would work. Now with dpkg-source v3 the
patches do not apply and months later I'm still wondering what to do
in this situation.

-- 
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/caktje6eqffbdchshzmg4bfhffzwgcnquxjpbgfeat9ycg-4...@mail.gmail.com

Re: bug#10363: /etc/mtab -> /proc/mounts symlink affects df(1) output for

[Goswin von Brederlow]

"Alan Curry"  writes:

> jida...@jidanni.org writes:
>> 
>>   Filesystem 1K-blocksUsed 
>> Available Use% Mounted on
>>   rootfs   1071468  287940   
>>  729100  29% /
>>   /dev/disk/by-uuid/551e44e1-2cad-42cf-a716-f2e6caf9dc78   1071468  287940   
>>  729100  29% /
>
> (I'm replying only on the issue of the duplicate mount point. Someone else
> can tackle the long ugly name.)
>
> The one with "rootfs" as its device is the initramfs which you automatically
> get with all recent kernels. Even if you aren't using an initramfs, there's
> an empty one built into the kernel which gets mounted as the first root
> filesystem. The real root gets mounted on top of that.
>
> So this is a special case of a general problem with no easy solution: What
> should df do when 2 filesystems are mounted at the same location? It can't
> easily give correct information for both of them, since the later mount
> obscures the earlier mount from view.

The problem also exists in a larger extend with chroots. There will be
lots of entries from outside the chroot that are inaccessible to a df
running inside the chroot.

What df should do is automatically skip the entries that are obscured or
generally inaccessible. Unfortunately the kernel does not (re)sort the
entries correctly following a mount --move call:

rootfs / rootfs rw 0 0
none /sys sysfs rw,nosuid,nodev,noexec,relatime 0 0
none /proc proc rw,nosuid,nodev,noexec,relatime 0 0
none /dev devtmpfs rw,relatime,size=491516k,nr_inodes=122879,mode=755 0 0
none /dev/pts devpts rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0
/dev/mapper/s-root / ext3 ro,relatime,errors=remount-ro,data=ordered 0 0
tmpfs /lib/init/rw tmpfs rw,nosuid,relatime,mode=755 0 0
...

Going by that list the /dev/mapper/s-root filesystems obscures the
rootfs, /sys, /proc, /dev and /dev/pts. In reality though only the
rootfs is obscured because the rest was moved prior to the initramfs
switching / around. What the kernel should do is move the relevant
entries so they appear below the filesystem they are moved to (and
before any that do obscure them, moving them to the bottom isn't always
the right solution).

So at the moment is a bit of a guess which entries are real and which
are obscured. The best you can do is check that each entry is actually a
mountpoint and guess that the last of identical mountpoints is the right
one.

> If there's a way for df to get the correct information for the lower mount, I
> don't know what it would be. If you have a process with a leftover cwd or
> open fd in the obscured filesystem, you can use that. But generally you
> won't.

There afaik isn't and there should not be a way to do so.

> But maybe we could do better than reporting incorrectly that the lower mount
> has size and usage identical to the upper mount! At least df could print a
> warning at the end if it has seen any duplicate entries. Perhaps there is
> some way it could figure out which one is on top, and print a bunch of
> question marks as the lower mount's statistics.

Maybe compare the major/minor of the device node with statfs() output.

> If df is running as root, it might be able to unshare(2) the mount namespace,
> unmount the upper level, and then statfs the mount point again to get the
> correct results for the lower level. That won't work in all cases (even in a
> private namespace you can't unmount the filesystem containing your own cwd)
> and it does nothing for you if you're not root, but still... it would be a
> cool bonus in the cases where it does work.
>
> As a special case, "rootfs" should probably be excluded from the default
> listing, since the initramfs is not very interesting most of the time. It
> could still be shown with the -a option, although it would always have the
> wrong statistics. Or if you really want to be impressive, default to showing
> the initramfs if and only if it is the only thing mounted on "/" - so you can
> run df within the initramfs before the real root is mounted and get the right
> result.

What if you only have a rootfs?

Imho the /proc/mounts file should only contain entries visible in the
processes mount namespace. So for normal systems the rootfs shouldn't
appear and in chroots the list should be even shorter.

> Or... (brace yourself for the most bold idea yet)... can you imagine a kernel
> interface that would *cleanly* give access to obscured mount points?

I fear that would let too much information escape from/into the mount
namesapces.

But there could be a /proc/global-mounts or something that is only
readable from the root namespace.

> Comments on any of the above? Do the BSDs have any bright ideas we can steal,
> or is their df as embarrassingly bad at handling obscured mount points as
> ours?

MfG
Goswin


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

Re: Bug#652275: Guided partitioning should not offer separate /usr, /var, and /tmp partitions; leave that to manual partitioning

[Goswin von Brederlow]

Ted Ts'o  writes:

> On Fri, Dec 16, 2011 at 02:38:11PM +, Lars Wirzenius wrote:
>> On Fri, Dec 16, 2011 at 02:13:29PM +0100, Stig Sandbeck Mathisen wrote:
>> > Simon McVittie  writes:
>> > 
>> > > life's too short to spend time booting in single-user mode and
>> > > resizing LVs.
>> > 
>> > That's probably why we now have online resizing of LVs and filesystems
>> 
>> resize2fs, at least, only supports online resizing to make the filesystem
>> larger, not smaller. It's not particularly useful for, say, the root
>> filesystem.
>
> FYI, the resize2fs proram does support shrinking off-line shrinking of
> ext3 file systems.  It doesn't currently support off-line resizing of
> ext4 file systems (just on-line growth), but that's something I
> consider a bug that I just haven't had the time to get around to fix.
>
> Regards,
>
>   - Ted

It could also be nice to be able to shrink the root filesystem by
alowing it to be mounted read-only and locking all pages of resize2fs
into memory. Just a thought.

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/87fwfd9jai.fsf@frosties.localnet

Re: Source package without a binary

[Goswin von Brederlow]

Joachim Breitner  writes:

> Dear devel,
>
> I have an interesting case for a hypothetical „source package without
> binary packages“: The haskell compiler comes with an extensive test
> suite. This test suite
>  1. is distributed separately from the sources,
>  2. takes a long time to run and
>  3. partly depends on libraries that do not come with the compiler
> packages, and which in turn Build-Depend on the compiler.
>
> Now point 1 could be solved with dpkg’s multi-tarball-feature, and point
> 2 is also somewhat minor (but not irrelevant, compiling GHC already
> takes more than a day on weak architectures, delaying this further is
> undesireable), but point 3 clearly prevents running the test suite
> during the build of the GHC package itself.
>
> From my point of view, it seems desirable to package the testsuite as a
> source-package of its own, build-depending on GHC and the additional
> libraries required, and upload that. Our autobuilding infrastructure
> would thus run the testsuite on the various architectures, which is very
> desirable, given that we are talking about a compiler that is not
> well-tested by upstream on the more exotic architectures.
>
> Theoretically, there is no interesting binary package produced from this
> source package and it seems that the policy does not explicitly require
> that a source package produces binary packages... but I am certain that
> this is an assumption buried deep within so many parts of our
> infrastructure that it is not a good idea to actually try this.
>
> So the logical conclusion is to build a binary package from the source
> that contains nothing (or maybe a log of the test results) and clearly
> states in its description that there is no point in installing this
> binary package.
>
> Is this something that we want to allow? If not, how else should I
> proceed? And are there developers who think that having a source package
> without binary package is a good way to stress-test our infrastructure
> for corner-case-bugs? :-)
>
> Greetings,
> Joachim

I think you could make the binary package be interesting:

1) run the tests during build and include the results
2) include the test suite to be run on the users system
3) provide a little script to run the test suite and to compare the
   results with the results generated by the buildd.

Use cases for this package would be to stress test your system and for
testing patches to the compiler or libraries to check for regressions.

For it to be truely usefull it would be important to know about the
expected behaviour. Some tests could be expected to fail on arm for
example while they work on amd64 and so on and to be able to only give
an error if the local results differ from the buildd.

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/87boq19ipl.fsf@frosties.localnet

Re: How mature is Pkg-format 3.0 (git), yet?

[Goswin von Brederlow]

"Thijs Kinkhorst"  writes:

> On Mon, January 16, 2012 23:26, Paul Wise wrote:
>>> I just wanted to ask how mature Package-format 3.0 (git) became until
>>> now.
>>
>> It is not currently accepted by the Debian archive:
>>
>> http://bugs.debian.org/642801
>
> My experience until now is that it's mature in dpkg. It does the job just
> like other source formats, for me.
>
> It's indeed not accepted in the Debian archive and also tools like Lintian
> don't support it. So it depends on your goals whether you can call it
> mature. It works very well for a local package I maintain.
>
>
> Thijs

There is a lot of different opinions about wether the format is sane at
all. A problem with the basic idea/design of 3.0 (git) as opposed to the
maturity of the implementation.

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/87y5t583v4.fsf@frosties.localnet

Re: dpkg-source again broken wrt to 3.0 (quilt)???

[Neil Williams]

On Wed, 18 Jan 2012 22:24:22 +0800
Paul Wise  wrote:

> On Wed, Jan 18, 2012 at 9:13 AM, Jakub Wilk wrote:
> 
> > Wait, are you patching files inside debian/? That won't fly.
> 
> I've personally missed this feature for a package I need to patch
> outside of Debian. 

This is something I'll need to look at again when Emdebian starts
preparing modified cross-built packages to modify the dependency chain
(Emdebian Crush). Currently that's stalled waiting for MultiArch but
the only reliable way I found to do it is to maintain a separate
debian/ directory in a VCS and apply it to the orig.tar.gz. Maintenance
will be a problem but then getting debian/rules to support minor
variants is also plagued with problems of maintenance because most
maintainers will not (have time to / be able to) build the variants,
let alone test them on device.

One example here is qtembedded. I'm currently keeping a debian/
directory based on the version in Squeeze and it could possibly work as
an alternative build inside the Qt debian packages but it's not a short
build and testing it isn't a small task either. (I failed to get a sane
cross-build out of it, so now have to wait 16hrs for a native build.)
We're maintaining this build out-of-tree for now.

It is useful to have the (unchanged) debian/patches/ to include into the
build for the embedded derivative but in other ways, it is just hard to
do well.

> When it was dpkg-source v1 I could just drop in the
> patches/series and everything would work. Now with dpkg-source v3 the
> patches do not apply and months later I'm still wondering what to do
> in this situation.

However, I disagree with you here, Paul. Patches, especially quilt
patches, to debian/ files are NOT maintainable because you still need
to update the patches when a minor debian revision takes place. i.e.
you need the files to which to make the patches so you might as well
make those files use conditionals within the build to enable that
variant and then you at least have the chance to build the full Debian
version with a simple DEB_BUILD_OPTION for sanity reasons.

ifneq (,$(findstring qtembedded,$(DEB_BUILD_OPTIONS)))

I did a LOT of patching to debian/ for the initial development of
Emdebian Crush based on Lenny and the only way to do it is to base on a
suite which is already frozen, otherwise the patches just fail
almost everytime the maintainer does anything to the package. It just
doesn't scale, so it's better to pick a frozen/stable suite and don't
try to keep up with more than a handful of packages.

In future, there will be no patches applied automatically to existing
Debian packages for Emdebian - we'll work out-of-tree and work on some
kind of conditional / derivative buildd support, possibly related to
the idea of partial architectures and existing work on bootstrap builds.

http://www.linux.codehelp.co.uk/serendipity/index.php?/archives/223-Qt-embedded-armel-for-Emdebian.html

http://lists.debian.org/debian-embedded/2011/10/msg00023.html

http://www.emdebian.org/trac/browser/current/emdebian/trunk/qt4-embedded/trunk/debian

Maintaining a separate tree in VCS is also easy in that various tools
already support it. I used svn-inject with the -o option. Then a
judicious use of meld against apt-get source is enough to add a few
updates for the next build.

Admittedly in the current build, the option is explicitly set for ease
but that's just debug. There are niggles which I'll get around to
filing as bugs once I start doing this seriously again.

What I'd like to see is better support for conditionals in debian/rules
to allow packages like busybox, cairo, curl, openssh and others to be
routinely built with certain optional components turned off or
particular configurations turned on (in the case of busybox) -
possibly only on certain architectures. Yes, those builds may well be
dangerous to install on a regular Debian box (busybox in particular) but
there are still situations where ldap and the like make installation of
standard Debian packages (or packages from Emdebian Grip) completely
infeasible.

http://www.emdebian.org/trac/browser/current/target

-- 


Neil Williams
=
http://www.linux.codehelp.co.uk/



pgpgFKzC9PRJt.pgp
Description: PGP signature

Re: dpkg-source again broken wrt to 3.0 (quilt)???

[Goswin von Brederlow]

Norbert Preining  writes:

> Hi everyone,
>
> maybe its just me, but I cannot get the hang of that 3.0 (quilt)
> and pre/post applying patches.
>
> Recently I prepared a NMU for less to finally fix the missing xz(tar.xz)
> support, added a new patch, but it is *impossible* for me to build
> a package. Irrelevant wether the patches were applied beforehand
> or not, dpkg-buildpackage always ends up in trying to apply them TWO
> times, which of course does not work.

As others have pointed out the error is this:

> patching file debian/lesspipe.1
> Reversed (or previously applied) patch detected!  Skipping patch.
> 1 out of 1 hunk ignored -- saving rejects to file debian/lesspipe.1.rej

No patching of files in debian/.


But that has been said. The reason why I write this mail is to suggest a
change in how you prepare a patch for a 3.0 (quilt) package that will
prevent you from running into this situation alltogether:

Just edit the files directly and build the (source) package.

Dpkg-buildpackage will automatically build (and update on repeated
builds) a debian/patches/debian-changes(-version) patch for you. Then
when you are satisfied that everything is as it should be you rename the
patch (quilt rename this-is-a-patch-for-foo) and edit the patch header to
properly annotate your work.

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/87ty3t83gh.fsf@frosties.localnet

Re: Bug#654896: ITP: xul-ext-debianbuttons -- Buttons for querying Debian-related pages with Iceweasel/Firefox

[Damyan Ivanov]

-=| Adam Borowski, 07.01.2012 13:02:28 +0100 |=-
> On Fri, Jan 06, 2012 at 05:32:20PM +0100, Tanguy Ortolo wrote:
> > * Package name: xul-ext-debianbuttons
> > * URL : https://addons.mozilla.org/firefox/addon/debian-buttons/
> >   Description : Buttons for querying Debian-related pages with 
> > Iceweasel/Firefox
> > 
> > Debian buttons is an extension that provides three new buttons for quick
> > access to information about Debian package or bug report on the web
> > using text from the X11 clipboard.
> 
> What's exactly the point of this extension?

Saving time.

> It appears to do exactly nothing a simple keyword can't do.

True, but it does it easier.

> Even in bare Firefox, you make a bookmark with URL 
> http://bugs.debian.org/%s
> and keyword "bts", then typing "bts 654896" or "bts bash" gets you there.
> And keywords don't take up screen space a series of buttons does.

Also true. Keywords take keystrokes though. With this extension you 
only need to (1) select the bug number/package etc, and (2) click on 
the button (middle-click for new tab).

With a keyword you have to add to that typing "bts ", possibly 
removing # or : or , around the bug number, and pressing enter (or 
shift-enter for new tab).

The price is some screen estate (32×32 pixels), yes.

The package is already in the archive, so cheers!


dam,
upstream author


signature.asc
Description: Digital signature

Re: dpkg-source again broken wrt to 3.0 (quilt)???

[Agustin Martin]

On Wed, Jan 18, 2012 at 02:35:23PM +0100, Jakub Wilk wrote:
> * Norbert Preining , 2012-01-18, 22:18:
> >Since we are at quilt 3.0 bashing: Maybe you can give me a
> >rational why I *ALWAYS* have to type in
> > export QUILT_PATCHES=debian/patches
> >before working with debian source packages?  And when I forget it
> >I get hurt by quilt?
> 
> dpkg (>= 1.15.8.6) creates the .pc/.quilt_series file. So no, not always.

It is sometimes removed. It is still unclear to me when/why that happens,
guess that dh_quilt_unpatch may be the responsible for that.

Of course, there is the alternative of README.source snippet.

Regards,

-- 
Agustin


-- 
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/20120118160429.ga4...@agmartin.aq.upm.es

Re: DEP-5: Clarifying copyright/license requirements (was: Clarifying the mandatory contents of the Debian copyright file.)

[Russ Allbery]

Pushing this towards debian-project, which is where the DEP-5 discussion
is supposed to happen.

Peter Miller  writes:

> http://dep.debian.net/deps/dep5/

> "Files paragraph (Repeatable)
> 
> "The declaration of copyright and license for files is done in
> one or more paragraphs. In the simplest case, a single paragraph
> can be used which applies to all files and lists all applicable
> copyrights and licenses."

> It says "all applicable copyrights and licenses".  Note the "and".  To
> me, in a standards context, this means conjunction (logical and) not
> disjunction (logical or).

So it sounds like we need to explicitly say that if there are files
Copyright 2010 and others Copyright 2009, you just write:

Copyright: 2009, 2010 whoever

and be done with it.  This is one of those things that to me is "obvious,"
but apparently it's not that obvious so we should spell it out.
Furthermore, we should probably also say that if upstream has a general
copyright notice, it's not required to sort through every file and find
every other mention of a copyright holder (but we should be sure that
ftpmaster is okay with that, since on that front I've heard conflicting
things).

Similarly, if the licenses used by upstream on the files allow releasing
under some other license that's covering the work as a whole, we should
probably say that it's okay to just list the license under which
everything is being distributed (although it's probably ideal to document
the separate licenses).

> If there was some other intent, the words don't say it.  Note there are
> *three* potentially ambiguous lists in that definition, they *all* need
> to be disambiguated in the language of DEP-5.

If you have those handy, could you mention where they are?

> Look at it from the other perspective:
> (a) given filename X, what license(s) apply?  Does DEP-5, by conflating
> copyrights and licenses, risk returning too many licenses? inapplicable
> licenses?

The work as a whole is often distributed under some particular license,
with individual files under some other, compatible license.  In that
situation, the most important thing to document is the license of the work
as a whole, since we know that we can deal with everything within that
work under that license and (most importantly) that's the license of the
resulting binaries.

Documenting the separate compatible licenses of individual files is useful
to people who want to separate the work, but is not nearly as important.

> (b) given filename X, what copyright(s) apply?  Does DEP-5, by
> conflating copyrights and licenses, risk returning too many copyrights?
> inapplicable copyrights?

I don't think this is a good way to look at it, honestly.  That's not why
we document copyrights; it's almost never important in copyright law to
get the exact list of copyright statements that apply to a specific file.
Collecting them and collapsing the years is de rigueur.

The main reason why we document the copyright notices is because many
licenses require them.  The secondary reason is that if there are any
legal questions, those are the people who have to be asked.  Neither of
those reasons require treating "Copyright 2009 foo" and "Copyright 2002,
2010 foo" as distinct strings.

> One solution may be to separate it into two paragraphs, one for
> applicable copyrights, and one for applicable licenses.  That is, you
> can have "Files:" && "Copyright:" || "Files:" && "License:", but you
> can't have "Files:" && "Copyright:" && "License:"

I think this is way too much overhead.  I'd rather just clarify the
wording to make it clear that you can do the, to me, obvious thing.

Incidentally, this conversation would be easier to have if you didn't come
across as quite this angry.  No one involved in DEP-5 is trying to
strangle your kittens or torture your dog, I swear!

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

Re: dpkg-source again broken wrt to 3.0 (quilt)???

[Russ Allbery]

Norbert Preining  writes:
> On Mi, 18 Jan 2012, Stefano Rivera wrote:

>> Because you haven't set up a .quiltrc? The maint-guide has a really
>> nice example you can steal.

> Ugg, and call dquilt or quilt --quiltrc=... yeah
> I will try to remember that, and will forget it as well as I forget
> setting QUILT_PATCHES

The point of .quiltrc is that you put it in your home directory and forget
about it.  /usr/share/doc/quilt/README.source has:

for where in ./ ../ ../../ ../../../ ../../../../ ../../../../../; do
if [ -e ${where}debian/rules -a -d ${where}debian/patches ]; then
export QUILT_PATCHES=debian/patches
break
fi
done

Put that in ~/.quiltrc and be happy.

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

Re: Patch Tagging Guidelines: DEP-3 moved to ACCEPTED status

[Jakub Wilk]

* Dominique Dumont , 2012-01-18, 10:41:

Does a DEP-3 parser exist? And why not?
config-edit -appli dpkg (soon to become 'cme edit dpkg') is able to 
parse, modify and save DEP-3 patches ( note that this command also deal 
with debian/copyright, debian/control and some other debian files).


Huh? What has dpkg to do with DEP-3?

And how do I use this parser? I want something as simple as: for a given 
patch, check if the header complies to DEP-3 and if it does, dump it in 
some machine-readable format.


--
Jakub Wilk


--
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/20120118174144.ga9...@jwilk.net

Re: Patch Tagging Guidelines: DEP-3 moved to ACCEPTED status

[Stefano Zacchiroli]

On Tue, Jan 17, 2012 at 10:05:06AM +0100, Josselin Mouette wrote:
> Le lundi 16 janvier 2012 à 18:07 +, Ian Jackson a écrit :
> > I think the DPL should appoint a dictator who will rule on when
> > consensus has been achieved on a DEP.

(I originally interpreted this as being enclosed within  tags)

> Seconded. The DEP process is missing a clear way to make a DEP change
> state. With a single-person (or small team) responsibility, everything
> should be clearer.

I'm not sure I see the point. DEP was never meant to be a device that
gives more power to anyone. It was just a device to keep track of a
discussion that was already happening, document it in some durable form,
and monitor its status. It's not like that the person with the power of
marking a DEP as "ACCEPTED" has the power of creating the corresponding
consensus.

Consensus should exist by itself, ditto for an implementation, and then
the corresponding DEP could be marked ACCEPTED. If that happens too
soon, no big deal, it's in a VCS, we can revert the commit.  Some people
might be fooled in the interim in believing something is "more standard"
than how much it actual is, but the same could have happened to anyone
looking at the archive of some discussion (i.e. without DEP).

If a DEP is in strict need of a formal rubber stamp of standardization,
then its "implementation" should probably correspond to formal
integration into policy (as, IIRC, it is the case for DEP-5).


The above notwithstanding, we can probably learn from this thread that,
for the future, it would help to first announce "I'm about to mark
DEP-$x as ACCEPTED" and then doing that.  I personally don't think it is
a big deal, but given that others disagree, ... why not.


Cheers.
-- 
Stefano Zacchiroli zack@{upsilon.cc,pps.jussieu.fr,debian.org} . o .
Maître de conférences   ..   http://upsilon.cc/zack   ..   . . o
Debian Project Leader...   @zack on identi.ca   ...o o o
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: Digital signature

LEGAL QUEST

[Kaya Mustafa]

 I pray my mail gets to you this time. I'd write you on two occasions 
concerning your assistance to help certify a piece of document due to some 
similarities in location with the supposed care-taker to enable a safe transfer 
of securities proceeds money out of Turkey. Please let me know if you were in 
receipt of my previous communication emailed to you.
 
Further information will be forwarded to you on receipt of your confirmation.
 
Thank you,
Mr. Kaya Mustafa



-- 
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/20120118173223.4db58f50...@jeff.kundenserver42.de

Re: dpkg-source again broken wrt to 3.0 (quilt)???

[Raphael Hertzog]

Hi,

On Wed, 18 Jan 2012, Agustin Martin wrote:
> On Wed, Jan 18, 2012 at 02:35:23PM +0100, Jakub Wilk wrote:
> > * Norbert Preining , 2012-01-18, 22:18:
> > >Since we are at quilt 3.0 bashing: Maybe you can give me a
> > >rational why I *ALWAYS* have to type in
> > >   export QUILT_PATCHES=debian/patches
> > >before working with debian source packages?  And when I forget it
> > >I get hurt by quilt?
> > 
> > dpkg (>= 1.15.8.6) creates the .pc/.quilt_series file. So no, not always.
> 
> It is sometimes removed. It is still unclear to me when/why that happens,
> guess that dh_quilt_unpatch may be the responsible for that.

You should not use dh_quilt_patch / dh_quilt_unpatch with a "3.0 (quilt)"
source package. dpkg-source takes care of everything, you should not
apply/unapply patches in debian/rules.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Pre-order a copy of the Debian Administrator's Handbook and help
liberate it: http://debian-handbook.info/liberation/


-- 
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/20120118182918.gb28...@rivendell.home.ouaza.com

Re: bug#10363: /etc/mtab -> /proc/mounts symlink affects df(1) output for

[Paul Eggert]

On 01/18/12 06:25, Goswin von Brederlow wrote:
> What df should do is automatically skip the entries that are obscured or
> generally inaccessible.

Isn't this missing some of the larger context?  df is just doing what
lots of other programs do: finding out what file systems one has,
and reporting statistics on them.  It sounds suboptimal to require
the maintainers of all these programs (coreutils, nautilus, etc.)
to rewrite their apps to deal with obscured entries.  Surely it would
be better to have the kernel ordinarily return just the ordinary entries,
and to return obscured entries only when they are specially requested.
That way, this issue would be isolated to the few bits of code that really
want to see obscured entries.


-- 
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/4f170b94.3010...@cs.ucla.edu

Re: Patch Tagging Guidelines: DEP-3 moved to ACCEPTED status

[Dominique Dumont]

Le Wednesday 18 January 2012 18:41:44, Jakub Wilk a écrit :
> >config-edit -appli dpkg (soon to become 'cme edit dpkg') is able to 
> >parse, modify and save DEP-3 patches ( note that this command also deal 
> >with debian/copyright, debian/control and some other debian files).
> 
> Huh? What has dpkg to do with DEP-3?

This command is designed to help debian packager do their job, i.e editing 
debian package files, including debian/patches in DEP-3 format.

> And how do I use this parser? I want something as simple as: for a given 
> patch, check if the header complies to DEP-3 and if it does, dump it in 
> some machine-readable format.

Currently, it cannot be used outside of the more general debian package 
files editor. 

I guess that config-edit could be slightly modified to be applied to 
individual package files. In check only mode, it should be able to 
validate the DEP-3 patches and issues error or warning in case of trouble. 

Even if Config::Model does not really qualify as simple, would that 
interest you ? ( then we could work out the  "dump it in some 
machine-readable format" part )

If not, feel free to reuse the parser code [1]

All the best

Dominique
[1] 
https://metacpan.org/source/DDUMONT/Config-Model-1.265/lib/Config/Model/Backend/Debian/Dpkg/Patch.pm

--
http://config-model.wiki.sourceforge.net/ -o- http://search.cpan.org/~ddumont/
http://www.ohloh.net/accounts/ddumont -o- http://ddumont.wordpress.com/


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

Bug#656360: ITP: ruby-ntlm-http -- 1

[Gunnar Wolf]

Package: wnpp
Severity: wishlist
Owner: Gunnar Wolf 

* Package name: ruby-ntlm-http
  Version : 0.1.1
  Upstream Author : Kohei Kajimoto, Kingsley Hendrickse 

* URL : http://rubyforge.org/projects/rubyntlm
* License : Ruby
  Programming Lang: Ruby
  Description : Library implementing NTLM authentication over HTTP

Ruby/NTLM provides message creator and parser for the NTLM
authentication.

This package is required as a build-dependency for the new version of
ruby-mechanize.



-- 
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/20120118183926.21794.65731.report...@mosca.iiec.unam.mx

Bug#656362: ITP: ruby-webrobots -- Library for creating robots.txt-aware web robots

[Gunnar Wolf]

Package: wnpp
Severity: wishlist
Owner: Gunnar Wolf 

* Package name: ruby-webrobots
  Version : 0.0.12
  Upstream Author : Akinori MUSHA 
* URL : https://github.com/knu/webrobots
* License : BSD
  Programming Lang: Ruby
  Description : Library for creating robots.txt-aware web robots

This library helps write robots.txt-compliant web robots in Ruby,
based on Nokogiri's functionality.

This package is required as a build-dependency for the new version of
ruby-mechanize.



-- 
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/20120118184707.27110.10736.report...@mosca.iiec.unam.mx

Re: Patch Tagging Guidelines: DEP-3 moved to ACCEPTED status

[Jakub Wilk]

* Dominique Dumont , 2012-01-18, 19:37:

https://metacpan.org/source/DDUMONT/Config-Model-1.265/lib/Config/Model/Backend/Debian/Dpkg/Patch.pm


Judging by a quick look, it doesn't support dpatch patches[0] or 
pseudo-headers[0][1].



[0] Don't ask what are these "features" good for. But they are in the 
specification.


[1] Also don't ask me how to unambiguously tell where the pseudo-header 
starts.


--
Jakub Wilk


--
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/20120118191501.ga4...@jwilk.net

Bug#656370: ITP: ruby-ntlm -- Pure Ruby implementation of Microsoft's NTLM protocol

[Gunnar Wolf]

Package: wnpp
Severity: wishlist
Owner: Gunnar Wolf 

* Package name: ruby-ntlm
  Version : 0.1.1
  Upstream Author : Kohei Kajimoto
* URL : http://rubyforge.org/projects/rubyntlm
* License : Ruby
  Programming Lang: Ruby
  Description : Pure Ruby implementation of Microsoft's NTLM protocol

Ruby/NTLM provides message creator and parser for the NTLM authentication.

Some features:
* Independent from non-standard Ruby libraries.
* Supports NTLM and NTLMv2 reponses.



-- 
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/20120118195412.30514.61632.report...@mosca.iiec.unam.mx

Re: Switching /etc/mtab to /proc/mounts and removing /lib/init/rw

[brian m. carlson]

On Wed, Jan 18, 2012 at 03:05:58PM +0100, Goswin von Brederlow wrote:
> jida...@jidanni.org writes:
> 
> > Forty years of pleasant df(1) and mount(1) reading shattered in one day,
> > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=653073
> 
> Any update on why the root filesystem is listed by UUID? Is that a
> problem of busybox mount reporting the long device name to the kernel
> why real mount uses the short one?

It's due to the libata transition.  Since drives that might formerly
have been hd? are now sd?, there was a debconf question to ask to
convert them all into UUIDs.  Then it doesn't matter which driver (ide
or libata or something else entirely) is being used.

-- 
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: Digital signature

Re: Switching /etc/mtab to /proc/mounts and removing /lib/init/rw

[Ben Hutchings]

On Wed, Jan 18, 2012 at 08:02:03PM +, brian m. carlson wrote:
> On Wed, Jan 18, 2012 at 03:05:58PM +0100, Goswin von Brederlow wrote:
> > jida...@jidanni.org writes:
> > 
> > > Forty years of pleasant df(1) and mount(1) reading shattered in one day,
> > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=653073
> > 
> > Any update on why the root filesystem is listed by UUID? Is that a
> > problem of busybox mount reporting the long device name to the kernel
> > why real mount uses the short one?
> 
> It's due to the libata transition.  Since drives that might formerly
> have been hd? are now sd?, there was a debconf question to ask to
> convert them all into UUIDs.  Then it doesn't matter which driver (ide
> or libata or something else entirely) is being used.

...or whether you have a USB storage device plugged in at boot.

Ben.

-- 
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
  - Albert Camus


-- 
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/20120118201029.gc12...@decadent.org.uk

Re: Patch Tagging Guidelines: DEP-3 moved to ACCEPTED status

[Fernando Lemos]

On Wed, Jan 18, 2012 at 4:37 PM, Dominique Dumont  wrote:
> Le Wednesday 18 January 2012 18:41:44, Jakub Wilk a écrit :
>> And how do I use this parser? I want something as simple as: for a given
>> patch, check if the header complies to DEP-3 and if it does, dump it in
>> some machine-readable format.
>
> Currently, it cannot be used outside of the more general debian package
> files editor.

You can use "dpkg-copyright" instead of "dpkg", though:

http://search.cpan.org/~ddumont/Config-Model-1.265/lib/Config/Model/models/Debian/Dpkg/Copyright.pod

Regards,


--
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/CANVYNa-ivQQYdbEcno5di=+yv8f_iu6chnef4ddqwxvb0fw...@mail.gmail.com

Bug#656389: ITP: trustmanager -- Java TrustManager interface with grid features

[Dennis van Dok (Software Engineer)]

Package: wnpp
Severity: wishlist
Owner: "Dennis van Dok (Software Engineer)" 


* Package name: trustmanager
  Version : 3.0.5
  Upstream Author : Joni Hahkala 
* URL : https://twiki.cern.ch/twiki/bin/view/EGEE/TrustManager
* License : Apache 2
  Programming Lang: Java
  Description : Java TrustManager interface with grid features

 TrustManager is an implementation of the java TrustManager interface
 with implementation of cert path checking, grid namespace
 restrictions and dynamic loading of CA certs, credentials, CRLs and
 namespace restrictions. Also provided is integration into tomcat,
 axis and axis2. There are many utility classes and methods for
 certificate and proxy creation and handling in trustmanager. It can
 be used both in the server side for the server ssl handler and on the
 client side for the opening of ssl connections.



-- 
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/20120118233121.26528.17053.reportbug@localhost6.localdomain6

Re: Releasing DEP 5 in two weeks in the absence of blocking bugs.

[Charles Plessy]

Le Wed, Jan 18, 2012 at 07:13:34PM +0100, Stefano Zacchiroli a écrit :
> 
> The above notwithstanding, we can probably learn from this thread that,
> for the future, it would help to first announce "I'm about to mark
> DEP-$x as ACCEPTED" and then doing that.  I personally don't think it is
> a big deal, but given that others disagree, ... why not.

Dear Stefano and everybody,

this is probably the occasion for me to remind that I posted such a message for
DEP 5 last December, and that I have not read disagreements.

  http://lists.debian.org/debian-project/2011/12/msg00011.html

While I wrote “in two weeks” at that time, it would have fell on the 24th,
which in retrospect I felt was not appropriate.  Now that I have almost resumed
my routine activities, I am ready to keep my promise, probably next week.

I do not intend to push a document on which persons disagree, so please, if you
think that there are serious problems with the current wording DEP 5, or if you
found an important bug in its syntax, report it to the BTS.

More than one year ago, Lars announced on debian-devel-announce “DEP5:
CANDIDATE and ready for use in squeeze+1”.  Let's make sure it happens.

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
Archive: http://lists.debian.org/20120119005013.gb11...@merveille.plessy.net

Re: Releasing DEP 5 in two weeks in the absence of blocking bugs.

[Russ Allbery]

Charles Plessy  writes:

> I do not intend to push a document on which persons disagree, so please,
> if you think that there are serious problems with the current wording
> DEP 5, or if you found an important bug in its syntax, report it to the
> BTS.

I reported what I think are problems with the current wording just now to
debian-policy, and yes, I believe that should block marking it as
ACCEPTED.

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

Bug#656413: ITP: jbigkit -- JBIG-KIT is a library implementing JBIG1 in T.85 & non-T.85 mode

[Michael van der Kolff]

Package: wnpp
Severity: wishlist
Owner: Michael van der Kolff 

* Package name: jbigkit
  Version : 2.0.0
  Upstream Author : Markus Kuhn 
* URL : http://www.cl.cam.ac.uk/~mgk25/jbigkit/
* License : GPL
  Programming Lang: C
  Description : JBIG-KIT is a library implementing JBIG1 in T.85 & non-T.85 
mode

JBIG-KIT is a library implementing JBIG1 in T.85 & non-T.85 mode.  JBIG1 is 
used by
faxes and some printers, notable the SPL range from Samsung & some zjs printers.



-- 
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/20120119040213.5830.72064.report...@mvdk-pers-lap.lan