Re: need help of Octave language expert

[Atsuhito Kohda]

Hi Thomas,

On Wed, 10 Mar 2010 08:34:33 +0100, Thomas Weber wrote:

> I'm cc'ing debian-devel, so people see that there is an answer. If
> whoever wants to continue the discussion, please strongly consider
> dropping debian-devel -- the list is noisy enough.

Sorry for additional noise.

> Directly accessing gnuplot (which is what 'gset' did) is deprecated in
> octave3.0 and even more in the 3.2 series. Spending time on this issue
> is probably wasted, unless TeXmacs' upstream is willing to adapt the
> necessary changes.
> 
> Following 
> http://old.nabble.com/octave-plugin-maintainership-td26618436.html
> it seems Mansour Moufid wanted to take over maintenance of the plugin. I
> suggest getting in contact with him.

Okay, I'll contact him later.  Thanks for your advice.

Best regards,  2010-3-10(Wed)

-- 
 Debian Developer - much more I18N of Debian
 Atsuhito Kohda 
 Department of Math., Univ. of Tokushima


-- 
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/20100310.170954.20519537.ko...@pm.tokushima-u.ac.jp

Vaishnav Kumar would like to add you as a friend on Skoost

[Vaishnav Kumar]

Williams Orellana

We have a mutual friend on Skoost and I'd like to add you as my friend, 
Vaishnav Kumar.

To confirm, follow the link below:
http://www.skoost.com/social/?pid=5940686&eml=debian-de...@lists.debian.org&fid=9038983&blk=0&pge=12

Skoost

Pramod Kumar would like to add you as a friend on Skoost

[Pramod Kumar]

Williams Orellana

We have a mutual friend on Skoost and I'd like to add you as my friend, Pramod 
Kumar.

To confirm, follow the link below:
http://www.skoost.com/social/?pid=5940686&eml=debian-de...@lists.debian.org&fid=11652853&blk=0&pge=12

Skoost

Raj Kumar would like to add you as a friend on Skoost

[Raj Kumar]

Williams Orellana

We have a mutual friend on Skoost and I'd like to add you as my friend, Raj 
Kumar.

To confirm, follow the link below:
http://www.skoost.com/social/?pid=5940686&eml=debian-de...@lists.debian.org&fid=11244287&blk=0&pge=12

Skoost

source package descriptions: subtsvars are not enough

[Stefano Zacchiroli]

On Tue, Mar 02, 2010 at 11:05:14AM +0100, Raphael Hertzog wrote:
> > It would be nice to have support for a Description field in the source
> > stanza of debian/control.

So, beside a few notable exceptions, the thread has a bit drifted to a
set of appreciations on the idea of using substvars to factorize out
common parts of package descriptions.  I agree it is a nice idea, but it
is not something we need specific support for (unless I'm missing some
glitch we can use it right now) and has several shortcomings:

- Most importantly: it does not solve the infrastructure problem,
  i.e. it does not encode properly the source package description so
  that it becomes part of package _metadata_.  This means that all
  infrastructure parts (the PTS, DDPO, UDD, potentially the BTS) are
  still at square 0: they don't know where to find a source package
  description.

  IOW: it is a cool hack for package maintainers, but it is a hack that
  gets resolved at package build time and then vanishes.

- It is not standardized: substvars are set via custom commands in
  debian/rules and there are thousands ways of setting them. When
  opening a random source package, one would not know where exactly to
  look for the common part of source package description. Nor an
  automated tool can extract it.

To fix that, it seems to me that the most reasonable solution advanced
in the thread is to add a proper "Description" field to source package
stanzas. Then, in addition, we can setup an automatic substvar, whose
content is the source description, that can then be used in package
description stanzas to interpolate the source description.

The obvious drawback is that Sources file will increase in size. Given
that the size will be small compared to Packages file, I personally
don't see it as a showstopper.

The appreciation that translators expressed wrt factorizing out text
from binary package description still applies to this proposal.

Cheers.

-- 
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..|  .  |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime


signature.asc
Description: Digital signature

Re: Removing the manpage requirement for GUI programs?

[Wouter Verhelst]

On Fri, Mar 05, 2010 at 03:53:14PM +0800, Paul Wise wrote:
> On Fri, Mar 5, 2010 at 3:41 PM, Daniel Leidert
>  wrote:
> 
> > What's the problem, to write a short manual page, that points to the
> > --help switch? All the maintainer would have to do is to provide the
> > intention of the command, point to the help/usage switch, relevant
> > commands and to locally installed documentation. Such a manual page
> > won't unlikely become outdated and it doesn't need much maintenance.
> > This goes for both: authors and maintainers. But it still provides the
> > necessary information to the user.
> 
> As a user I'd find such a manual page less than useless, it would be
> extremely annoying. In any case the undocumented(7) manual page covers
> these:
> 
> http://manpages.debian.net/man/7/undocumented

Except that undocumented(7) does not say what the command does, and
makes guesses as to where the documentation is. A man page that says
"this program exists to do foo, and its documentation is at this exact
location" is infinitely more useful than man emitting "please go read
undocumented(7) and sod off".

> I find the following two options acceptable:
> 
> Good, useful, up-to-date manual pages.
> 
> No manual page at all.
> 
> An outdated/unmaintained manual page or one that just points at --help
> or existing documentation isn't useful or acceptable.

It is useful if we can expect that each and every command in Debian
either has documentation or a pointer to documentation in its manual
page.

As things stand, one must guess: either the program has a man page, or
it has an info page, or it has a bunch of text or HTML files in
/usr/share/doc, or it is an interactive program that has an on-line help
system, or it has no packaged documentation at all and one must go find
it on some sourceforge.net wiki page. Or it might have a gzipped PDF
file, which is even more annoying, for it requires me to copy,
uncompress, read, remove the documentation.

Having a single way to figure out where the canonical documentation of a
program is, is *extremely* useful. Why not let the man page be that way?
Either it can be the canonical documentation itself, or it can have a
summary overview of the program and a good and exact pointer to where
the full documentation is.

I hate guessing almost as much as I hate hunting for documentation.

-- 
The biometric identification system at the gates of the CIA headquarters
works because there's a guard with a large gun making sure no one is
trying to fool the system.
  http://www.schneier.com/blog/archives/2009/01/biometrics.html


-- 
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/20100310125215.gb10...@celtic.nixsys.be

Re: source package descriptions: subtsvars are not enough

[Raphael Hertzog]

On Wed, 10 Mar 2010, Stefano Zacchiroli wrote:
> - It is not standardized: substvars are set via custom commands in
>   debian/rules and there are thousands ways of setting them. When
>   opening a random source package, one would not know where exactly to
>   look for the common part of source package description. Nor an
>   automated tool can extract it.

You completely misparsed my answer/suggestion. My suggestion is to follow
your advice, add a Description field in the source part of debian/control,
let it flow in the .dsc and Sources _AND_ modify dpkg-gencontrol so that
you can use new default substitution variables to reuse the source
description elsewhere. There would be no need for any custom command
in debian/rules.

> To fix that, it seems to me that the most reasonable solution advanced
> in the thread is to add a proper "Description" field to source package
> stanzas. Then, in addition, we can setup an automatic substvar, whose
> content is the source description, that can then be used in package
> description stanzas to interpolate the source description.

That's precisely what I have been suggesting.

Cheers,
-- 
Raphaël Hertzog

Like what I do? Sponsor me: http://ouaza.com/wp/2010/01/05/5-years-of-freexian/
My Debian goals: http://ouaza.com/wp/2010/01/09/debian-related-goals-for-2010/


-- 
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/20100310125821.gd14...@rivendell

Re: source package descriptions: subtsvars are not enough

[Stefano Zacchiroli]

On Wed, Mar 10, 2010 at 01:58:21PM +0100, Raphael Hertzog wrote:
> You completely misparsed my answer/suggestion. My suggestion is to follow

Sorry for not having been clear: I did not misunderstood your
suggestion, in fact ...

> > To fix that, it seems to me that the most reasonable solution advanced
> > in the thread is to add a proper "Description" field to source package

... the implicit subject here is you, I took your suggestion as the most
reasonable one (and yes, I should have made the subject explicit). If
everybody else on the thread is on the same line ... even better :-)

So, do we have a roadmap of what should be changed so that we can keep
track of this?

Cheers.

-- 
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..|  .  |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime


signature.asc
Description: Digital signature

Re: source package descriptions: subtsvars are not enough

[Hector Oron]

Hello,

2010/3/10 Stefano Zacchiroli :
> The obvious drawback is that Sources file will increase in size. Given
> that the size will be small compared to Packages file, I personally
> don't see it as a showstopper.

Would Packages file size decrease applying your suggestion?
Is there any chance to use this change to shrink Packages file size?

Regards,
-- 
 Héctor Orón


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

Re: Removing the manpage requirement for GUI programs?

[Wouter Verhelst]

On Thu, Mar 04, 2010 at 04:36:56PM +0100, Josselin Mouette wrote:
> I can’t help noticing, though, that it would only duplicate
> functionality that is already present in search engines of desktop help
> systems (which are also able to search in manual pages, FWIW).

I can't help noticing, though, that GUI "desktop environments" seem to
be reinventing the wheel over and over and over and over and over again.
Note that whatis exists far, far longer than "functionality that is
already present in search engines of desktop help systems". Note also
that not everyone *wants* to use "desktop help systems", but sometimes
needs to use individual GUI programs, or know what they do without
starting them.

-- 
The biometric identification system at the gates of the CIA headquarters
works because there's a guard with a large gun making sure no one is
trying to fool the system.
  http://www.schneier.com/blog/archives/2009/01/biometrics.html


-- 
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/20100310133718.gc10...@celtic.nixsys.be

Re: source package descriptions: subtsvars are not enough

[Stefano Zacchiroli]

On Wed, Mar 10, 2010 at 02:31:10PM +0100, Hector Oron wrote:
> Would Packages file size decrease applying your suggestion?
> Is there any chance to use this change to shrink Packages file size?

No, this proposal is completely orthogonal to that (and IMO should
remain so): we're talking about changing source package metadata which
do not belong to Packages and are not necessarily downloaded by users.

Cheers.

-- 
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..|  .  |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime


signature.asc
Description: Digital signature

Re: [Rant] Re: Removing the manpage requirement for GUI programs?

[Wouter Verhelst]

On Sun, Mar 07, 2010 at 09:50:12AM +0100, Josselin Mouette wrote:
> Le vendredi 05 mars 2010 à 17:41 +, brian m. carlson a écrit :
> > This still has the problem that I don't know immediately where to get
> > the documentation.  Do I use the GNOME help system?  KDE's?  man?  info?
> > a DVI?  a PDF?  The benefit of manual pages is that there is one uniform
> > way to get basic documentation on a command and how it is to be run.
> > Other documentation can be referenced from that manual page.
> 
> This discussion is running into circles.
> 
> GNOME, Xfce and KDE maintainers all explained that we have no interest
> in working on manual pages, and our upstreams don’t either.

You don't need to. All you need to do is make sure that "man $prog"
returns something useful. "This program does foo, and the documentation
is over at bar" is something useful, and could be done by a script that
has three points of information: the name of the program, whatever "foo"
is, and whatever "bar" is.

> Those who are nostalgic of the time when a text-only documentation
> system was enough keep repeating ad nauseam “but we need manual pages”.

No, we need a uniform documentation system. Personally, I don't care
whether that uniform documentation system is "man pages" or "HTML
files" or something else, but traditionally, in Debian, that
documentation system has been "man pages", so in the absense of a
compelling argument as to why we should change that, I do not see why we
should -- especially because changing from one documentation system to
another would involve a load of work.

Also note that any alternate uniform documentation system should be
usable for all our users, be they GNOME, KDE or XFCE users, webserver
sysadmins with only a shell through SSH, or those of us who simply
prefer text-only documentation.

Having a uniform documentation system that occasionally says "in this
particular case you need to go look at this other documentation system
rather than me" is not really a problem. Having a "uniform"
documentation system that occasionally says "I don't know what the fuck
you're talking about, sod off", however, is a problem, because it
defeats the point of having a uniform documentation system in the first
place.

[...]
> At this point of the discussion, this should be clear: either you do
> whatever it takes to have your precious manual pages in all Debian
> packages, either you don’t. And if you don’t, I would appreciate that
> you just STFU instead. Maintainers who are already overloaded are not
> here just to take orders from others.

You were suggesting that we just give up on our uniform documentation
system because we're not there yet, and people are understandably upset
about that.

Nobody is suggesting that you take on work that you don't want to take
on; people are instead suggesting that it's okay to have those bugs
open, but that they should still be considered bugs, since they break
the assumption of a uniform documentation system.

> I will personally just sit on policy §12.1, mark manpage-related bugs as
> wontfix, and, to plagiarize Yves-Alexis, it won’t prevent me from
> sleeping at night.

Which is perfectly fine -- they're not RC.

-- 
The biometric identification system at the gates of the CIA headquarters
works because there's a guard with a large gun making sure no one is
trying to fool the system.
  http://www.schneier.com/blog/archives/2009/01/biometrics.html


-- 
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/20100310141329.gd10...@celtic.nixsys.be

Re: Bug#540215: Introduce dh_checksums

[Wouter Verhelst]

On Mon, Mar 08, 2010 at 12:59:00PM -0800, Russ Allbery wrote:
> Frank Lin PIAT  writes:
> 
> > Find a patch attached, for a smooth transition from DEBIAN/md5sums to a
> > recent checksum.
> 
> > The way it is implemented, is that the dh_md5sums is a symlink to the
> > new dh_checksums. The new helper computes both md5sum (for
> > compatibility/transition) and a new checksum (SHA256, which was already
> > chosen by FTP-masters as a remplacement for md5sum for signed files)
> 
> If there's a general consensus that we should go this route, I'm okay with
> it, but I'm personally not sure this is the right approach.
> 
> I think there are two possible directions we can take with this package
> feature:
> 
> 1. Strengthen the integrity check so that it could potentially be useful
>for security purposes as well as for simple integrity checking.
> 
> 2. Declare such checksums only useful for corruption and local (benign)
>modification checksumming.
> 
> If we take option 1, going to a stronger hash is strictly less useful in
> every respect than going to embedded PGP signatures, which apparently only
> require active maintenance and a plan to be acceptable in the archive and
> which would need a different format anyway.

Maybe, but we're not there yet.

At any rate, a PGP signature takes a lot of data; much more so than a
checksum. It's therefore more economical to produce a signed
package.checksums file than it is to produce a package.pgpsigs.

Having package.checksums be GPG-signed will take a significant change in
our infrastructure (buildd hosts, for instance, would need to have a way
to sign checksums files as well), so it's not going to happen tomorrow.
But changing to a more secure checksum algorithm could be done easily
with current infrastructure.

And since checksum files are generated at build time rather than at
install time, it is possible to download a known-good copy of the .deb
that is installed (using snapshot.debian.org, once it gets live, for
instance, or from a not-compromised host's apt cache), and verify the
files against that copy rather than the copy that is on the disk. Until
signed packages or signed checksums are available, this would of course
be a stopgap measure, but one that would actually work -- provided, of
course, that the used checksum algorithm is cryptographically secure,
which MD5 is no longer.

> If we take option 2, SHA256 offers no benefits over MD5 and just takes
> longer to compute.  There is essentially zero chance that random file
> corruption or typical local modification will result in a successful MD5
> preimage attack.

Of course, that much is true.

-- 
The biometric identification system at the gates of the CIA headquarters
works because there's a guard with a large gun making sure no one is
trying to fool the system.
  http://www.schneier.com/blog/archives/2009/01/biometrics.html


-- 
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/20100310143214.ge10...@celtic.nixsys.be

Best practices for OpenPGP keys?

[Drew Scott Daniels]

Hi,
Is there any good documentation about best practices for OpenPGP key
management? I plan to use gnupg (gpg), as it's conventional and seems like
the "best of breed" these days.

Most documentation I've found seems significantly out of date (including
long discussions of incompatibilities with versions from 2001...). I did
find it interesting that the IDEA patents are expiring in May this year
for the EU and US if I remember

The best documentation I have found includes:
http://arfore.com/2007/07/29/gpg-best-practices/
http://www.cam.ac.uk.pgp.net/pgpnet/pgp-faq/

Over the years I've heard some ideas like:
   * Only store your key on less common architecture to make break-ins
involve more esoteric techniques (e.g. common rootkits/scripts fail). A
variant of this would be adding a level of virtual abstraction by using
a virtual machine (though it's just a level of obfuscation).
   * Set an expiry date on your primary key and/or sub-key and sign a new
key before the old key expires. I think this is problematic for some
key reading programs though I can't remember any instances. Expiry
dates aren't default and seemed to be uncommon last time I checked.
   * Revoke primary and/or sub-keys after expiration, or instead of
expiration. While revoking keys can keep people from using the old key
even if they cracked it, many programs might expect that revoked keys
aren't trustworthy at all.
   * Use a really long keylength for your sub-key. The trade off seems to
be that signing and encrypting things takes a lot longer.
   * Use a really long keylength for your primary key and
   * Don't store your key on machines that connect to any networks.
Transferring signed data is time consuming, inconvenient... I'm not
sure if it's fair to say it's vulnerable to social engineering attacks.
   * Use a random string for your passphrase. I was "bit" by this on my
first attempt to use a keypair years ago (around 2003). I forgot the
passphrase.
   * "Harden" machines that contain your private key. While it's usually a
good idea to do this for all machines, I would hope that most things
would be secure without having to spend the extra time doing
configurations...

>From the breakins over the years, and from the difficulties with "extra
secure" choices from some people, I really wonder whether best practices
aren't for a more secure key, but simply for good management of the
location of the key, the passphrase, the revocation data, and patients for
slow signing.

I think key-pair usage could use:
   * Default expiry times. This would make expiry more common.
   * Implied expiry for old keys (though "old" isn't reliable).
   * Use of the existing levels of security, or new levels as it seems the
highest level of trust is all too often required.
   * Spliting trust of identity from trust of actions. SSL management has
personal, server, and program sections. Imagine signing someone's key
because you know who they are, then wanting to not trust code that they
write, or not trust that their signing of other peoples keys.
   * SELinux policy to only allow certain programs access to private keys
made default. E.g. It would be nice if I could prevent scp from
accessing my private key without my explicit authorization by changing
the security context, or via a proxy program's authorization (the proxy
could log the event etc.). AppArmor to exclude access to the private
key is something I think that already happens. A nice guide to
implement the appropriate SELinux security context for a private key
would be nice, maybe I'm missing something from gnupg, fedora and/or
elsewhere.

Please CC me on replies.

Thanks,

 Drew Daniels
Resume: http://www.boxheap.net/ddaniels/resume.html


-- 
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/e81248fe0396a754c3fc202791ccdfb6.squir...@webmail.dreamhost.com

Re: Removing the manpage requirement for GUI programs?

[Vincent Lefevre]

On 2010-03-10 13:52:15 +0100, Wouter Verhelst wrote:
> Or it might have a gzipped PDF file, which is even more annoying,
> for it requires me to copy, uncompress, read, remove the
> documentation.

zxpdf from xpdf-reader can handle it. But I wonder why the need for
two separate commands while the format can easily be detected.
I don't know how other PDF viewers handle compressed PDF files.

For the other points, I completely agree with you.

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


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100310162854.ga23...@prunille.vinc17.org

Re: Bug#540215: Introduce dh_checksums

[Peter Samuelson]

[Wouter Verhelst]
> At any rate, a PGP signature takes a lot of data; much more so than
> a checksum.  It's therefore more economical to produce a signed
> package.checksums file than it is to produce a package.pgpsigs.

Huh?  Since asymmetric cryptography is so computationally expensive,
PGP never signs the payload directly.  Instead, the payload is hashed
and then the hash is signed.  So it is not (noticeably) more economical
to sign foo.md5sums than to sign the whole data.tar.gz.

[Same goes for encrypting: PGP encrypts with a conventional block
cipher like AES and a randomly generated key, then encrypts the _key_
using RSA.  Again, this is for efficiency.]

Or is this not what you meant?  I'm confused.


> And since checksum files are generated at build time rather than at
> install time, it is possible to download a known-good copy of the
> .deb that is installed (using snapshot.debian.org, once it gets live,
> for instance, or from a not-compromised host's apt cache), and verify
> the files against that copy rather than the copy that is on the disk.

If you're going to the trouble to download a .deb, why bother with
signatures at all?  Why not just compare the full text directly?

If you have a .deb on a different host and don't want to transfer the
entire thing over the network, well, no reason you can't do your
SHA16384 on both ends, and transfer only the hashes at that time.
-- 
Peter Samuelson | org-tld!p12n!peter | http://p12n.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/20100310171331.gt18...@p12n.org

Re: source package descriptions: subtsvars are not enough

[Peter Samuelson]

[Stefano Zacchiroli]
> To fix that, it seems to me that the most reasonable solution
> advanced in the thread is to add a proper "Description" field to
> source package stanzas. Then, in addition, we can setup an automatic
> substvar, whose content is the source description, that can then be
> used in package description stanzas to interpolate the source
> description.

Yes, I think pretty much everyone agrees that this would be the most
reasonable approach.

I wonder if, in addition (or perhaps instead of the above), it is
useful to have a substvar for just the _first paragraph_ of the source
Description.  What I'm thinking about is a short blurb you want to copy
into all your binary packages, but perhaps there is _more_ information
you also want to put in the source Description, which it wouldn't be
useful to copy everywhere.

In particular, I do think a single paragraph should always be
sufficient for copying into a binary Description.  We don't want those
things to get too long!  The question then is, might it be useful to
have a longer description in the source package?  I do not know.
Perhaps this additional information always belongs instead in the
diff.tar.gz somewhere, like debian/source.README.
-- 
Peter Samuelson | org-tld!p12n!peter | http://p12n.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/20100310173014.gu18...@p12n.org

Bug#573341: ITP: libmath-gradient-perl -- module for calculating smooth numerical transitions

[Jonathan Yu]

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

* Package name: libmath-gradient-perl
  Version : 0.04
  Upstream Author : Tyler MacDonald 
* URL : http://search.cpan.org/dist/Math-Gradient/
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : module for calculating smooth numerical transitions

Math::Gradient is a Perl module that is useful for calculating numbers needed
to make smooth transitions between two or more numerical values (graphically
represented as gradients). The primary intent of this module is to make it
easy to mix colours, both in terms of basic and multiple-point gradients.

NOTE: this is needed for packaging of Chart::Clicker



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

Bug#573347: ITP: libhash-multivalue-perl -- module for storing multiple values per key in a hash

[Jonathan Yu]

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

* Package name: libhash-multivalue-perl
  Version : 0.08
  Upstream Author : Tatsuhiko Miyagawa 
* URL : http://search.cpan.org/dist/Hash-MultiValue/
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : module for storing multiple values per key in a hash

Hash::MultiValue is a Perl module that provides an object (and a plain hash
reference) that may contain multiple values per key. The hash behaves like a
single-value hash reference, but also provides an API to retrieve multiple
values explicitly on demand.

NOTE: this package is needed for packaging Plack



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

Bug#573345: ITP: radare2 -- free advanced command line hexadecimal editor

[Sebastian Reichel]

Package: wnpp
Severity: wishlist
Owner: Sebastian Reichel 

* Package name: radare2
  Version : 0.4
  Upstream Author : pancake 
* URL : http://www.radare.org/
* License : LGPL, imported GPL and BSD code
  Programming Lang: C; Bindings for: Perl, Python, Ruby, Vala
  Description : free advanced command line hexadecimal editor

The project aims to create a complete, portable, multi-architecture,
unix-like toolchain for reverse engineering.
  
It is composed by an hexadecimal editor (radare) with a wrapped IO
layer supporting multiple backends for local/remote files, debugger
(osx,bsd,linux,w32), stream analyzer, assembler/disassembler (rasm)
for x86,arm,ppc,m68k,java,msil,sparc code analysis modules and
scripting facilities. A bindiffer named radiff, base converter (rax),
shellcode development helper (rasc), a binary information extracter
supporting (pe, mach0, elf, class, ...) named rabin, and a block-based
hash utility called rahash.

Note: radare2 coexists with radare1 and the binary of this package is
called radare2, so I name the source package radare2, too. But I don't
plan to continue maintaining radare1. I will ask for removal once radare2
is in the repository.

-- Sebastian



-- 
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/20100310180618.12109.34456.report...@earth.universe

Bug#573349: ITP: libkcompat -- Linux kernel compatibility library for userspace applications

[Jon Bernard]

Package: wnpp
Severity: wishlist
Owner: Jon Bernard 

* Package name: libkcompat
  Version : 0.1
  Upstream Author : Pierre-Marc Fournier 
* URL : http://lttng.org/
* License : LGPL 2.1
  Programming Lang: C
  Description : Linux kernel compatibility library for userspace 
applications

This package provides userspace ports of APIs available in the Linux
kernel but not available to userspace programs. Included are header
files for atomic integer operations, linked lists, hash tables,
and reference counting.

NOTE: this is needed for the packaging of ltt-ust

-- 
Jon



-- 
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/20100310183316.ga12...@shaniqua

Re: Bug#540215: Introduce dh_checksums

[Russ Allbery]

Peter Samuelson  writes:
> [Wouter Verhelst]

>> At any rate, a PGP signature takes a lot of data; much more so than
>> a checksum.  It's therefore more economical to produce a signed
>> package.checksums file than it is to produce a package.pgpsigs.

> Huh?  Since asymmetric cryptography is so computationally expensive,
> PGP never signs the payload directly.  Instead, the payload is hashed
> and then the hash is signed.  So it is not (noticeably) more economical
> to sign foo.md5sums than to sign the whole data.tar.gz.

However, since the most common verification action is probably going to be
to check whether a specific file installed on the system has been
modified, Wouter's approach is probably the best implementation strategy.
It's more efficient to compute the checksum of a file, check that it
matches the checksum in the signed file, and verify the signature on that
file than it is to verify the data.tar.gz signature and then extract the
relevant file from it and compare it to the file on disk.  Among other
things, you can use the first algorithm with nothing but the signed
checksum files, which are a lot smaller than keeping the whole package
around.

> If you're going to the trouble to download a .deb, why bother with
> signatures at all?  Why not just compare the full text directly?

Indeed.  It's an efficiency gain for much the same reasons as above, but
not really a security gain.

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

Re: Bug#572374: please consider Section: Education

[Ana Guerrero]

On Wed, Mar 10, 2010 at 01:40:07PM +0900, Charles Plessy wrote:
> I agree with Andreas here: we already have other ways to classify software, in
> particular with the Debtags, and to group packages, in particular with the
> Blends tasks, so fragmenting the sections will only introduce doubts and
> controversy about multi-purpose software.

Yes, but as long as we are also using the archive sections, we should improve
them.

> How about renaming the Science section “Science and Education” (or “Education
> and Scicence”, it does not matter to me). The content of the ‘Section’ field 
> in
> the Debian control files could stay ‘science’, since if I understand the
> problem, what matters here is the processed information that our users see on
> our website.

We will always have software fitting in several section, and we never will solve
that problem as long as we use them. What you propose sounds like a bad
workaround, specially because I can understand “Science and Education” as 
application that are both: science and education. Would linguistic apps fit 
there?

Neither we can have sections for everything but in the case of educative 
software I think we have plenty of software falling under this category.

Ana


-- 
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/20100310185815.ga27...@pryan.ekaia.org

Re: dsniff is dead, long life to dsniff

[Luciano Bello]

So, I'm going to upload a new package (python-dsniff) and maintain (or 
co-maintain, with faidon) dsniff (the classical one) in the meantime. 
Personally, I'm going to leave the dsniff maintenance when python-dsniff 
becomes a comparable alternative.

Thanks for all your opinions,

luciano



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

Re: Bug#573345: ITP: radare2 -- free advanced command line hexadecimal editor

[Reinhard Tartler]

On Wed, Mar 10, 2010 at 19:06:18 (CET), Sebastian Reichel wrote:

> Note: radare2 coexists with radare1 and the binary of this package is
> called radare2, so I name the source package radare2, too. But I don't
> plan to continue maintaining radare1. I will ask for removal once radare2
> is in the repository.

what is upstreams opinion on this? is radare1 superseeded upstream? In
that case, I'd rather avoid introducing a new package name and just
upload the new version with the name 'radare', automatically replacing
the old one.

-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4


-- 
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/878wa0ggc8@faui44a.informatik.uni-erlangen.de

Re: Bug#572374: please consider Section: Education

[Andreas Tille]

On Wed, Mar 10, 2010 at 07:58:15PM +0100, Ana Guerrero wrote:
> Yes, but as long as we are also using the archive sections, we should improve
> them.

ACK.
 
> We will always have software fitting in several section, and we never will 
> solve
> that problem as long as we use them.

ACK.

> What you propose sounds like a bad workaround,

I don't think so - it's just another suggestion and in my eyes it s
quite comparable to your original suggestion.

> specially because I can understand ???Science and Education??? as 
> application that are both: science and education.

Would you prefer "Science or education"? ;-)
If I tell you my bag contains "Cacao and sugar" would you think I
brought some chocolate consisting of both ingrediences?

> Would linguistic apps fit there?

Sure.  According to my understanding Charles did not suggest to exclude
pure scientific software from the proposed common section and currently
some linguistic apps are in Science and there is no reason to remove
these just because we add Educationsl applications to the section.

> Neither we can have sections for everything but in the case of educative 
> software I think we have plenty of software falling under this category.

Yes, we do.  I personally have no problem with both suggestions because
they seem to be both able to reduce the effect of the problem (but not
real solutions because there is probable no such thing).  Anas
suggestion leaves the problem that it is hard to decide where to put
packages which are really intended for both Science and Education.
Charles suggestion does hardly enable to move some educational games
into the suggested section.  I think we should leave the final decision
to ftpmaster (do-o-cracy = the doer decides).
 
Kind regards

 Andreas.

-- 
http://fam-tille.de


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100310200358.ga5...@an3as.eu

Bug#573361: ITP: ltt-ust -- LTTng Userspace Tracer

[Jon Bernard]

Package: wnpp
Severity: wishlist
Owner: Jon Bernard 

* Package name: ltt-ust
  Version : 0.3
  Upstream Author : Pierre-Marc Fournier 
* URL : http://lttng.org/
* License : LGPL 2.1
  Programming Lang: C
  Description : LTTng Userspace Tracer

The userspace tracer is designed to provide detailed information about
userspace activity. Like the kernel tracer, performance is the main
goal. Tracing does not require system calls or traps. UST
instrumentation points may be added in any userspace code including
signal handlers and libraries.

-- 
Jon



-- 
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/20100310203307.ga17...@shaniqua

Re: Very newbe help/pointers required about building a distribution from scratch

[Luke Kenneth Casson Leighton]

On Wed, Mar 10, 2010 at 8:18 PM, Lennart Sorensen
 wrote:
> On Wed, Mar 10, 2010 at 07:20:04PM +, Luke Kenneth Casson Leighton wrote:
>>  yeah - i'd like to know how to do this, too.  i installed buildd (and
>> wannabuild) but there appears to be some "manual" steps involved, and
>> i was kind-of expecting it to be automatic and recursive.
>>
>>  what i was expecting was that there was a simple way - e.g. grab all
>> the packages of a task - and just "shove" them at buildd, and i was
>> expecting it to just... go ahead and recursively grab all build
>> dependencies and all source dependencies, right down to coreutils and
>> build them all from the top down.
>>
>>  a bit like openembedded.
>>
>>  ... but there's absolutely nothing that can be found, like that: it
>> seems more that buildd is designed to be a half-way house, which is
>> kinda useless for this sort of task, creating entire specialised
>> rebuilds (a la gentoo) for specific architectures.
>>
>>  yes, basically, i want to rebuild an entire suite of debian packages
>> for the arm cortex A8 processor (the S5PC100).
>
> A number of packages have circular dependancies.  These have to be
> resolved manually by either temporarily using packages built elsewhere
> or by manually building parts of a package to solve the dependancies.

 or by using e.g. debian armel packages a la cross-debootstrap
(rootstock under the dreaded ubuntu), that gets you into a position
where each of those dependencies can be replaced one at a time.

> You better have a good understanding of the debian packaging system and
> how dpkg-buildpackage works.
>
> It only really becomes automatic with wannabuild once you have a working
> base system.

 excellent.

 ... where is all this documented?

 has anyone actually done this - documented and automated e.g. how the
debian-armel port was created, when previously there was only the
debian-arm one?

 because it really does make sense to have a way to do automated total
recompiles for e.g. the cortex a8, and if debian won't "officially"
add that as an architecture, at least having a well-documented and
automated process by which a random person can just... set some
machines compiling for a month, would be good.


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

Re: Very newbe help/pointers required about building a distribution from scratch

[Neil Williams]

On Wed, 10 Mar 2010 21:08:30 +
Luke Kenneth Casson Leighton  wrote:

(When replying, please shorten the CC list, preferably only to the
debian-embedded list.)

> >>  a bit like openembedded.

It's much easier to not do things like OE and to actually build
incrementally, putting dependencies into a local repository to make
them available as build-dependencies of the subsequent packages. That's
how Emdebian did it for Emdebian Crush 1.0.

> >>  ... but there's absolutely nothing that can be found, like that: it
> >> seems more that buildd is designed to be a half-way house, which is
> >> kinda useless for this sort of task, creating entire specialised
> >> rebuilds (a la gentoo) for specific architectures.

Debian is a binary distribution, it's designed to be built
incrementally and to use dependencies as binaries. Where others use a
staging area, Debian uses a repository which can be local.

emdebian-tools has scripts to do this but it's complicated and
cross-building Debian currently is hard.

> >>  yes, basically, i want to rebuild an entire suite of debian packages
> >> for the arm cortex A8 processor (the S5PC100).

armel? Use Emdebian Grip.

http://www.emdebian.org/grip/

Why rebuild? What changes are you making to the packages? (Answers to
questions like this should go to the debian-embed...@lists.debian.org
mailing list, not debian-devel.)

(IMHO - and possibly a lot of other DD's - the benefits of building
packages for a specific machine ala gentoo with no other changes is
often heavily over-rated.)

> > A number of packages have circular dependancies. 

There is some work going on to fix those (nod to Holger and piuparts)
but finding a path through the dependencies is VERY VERY hard. The only
sane way is to start with the toolchain packages, work up gradually,
make mistakes, retrace your steps, go back and try another route then
make some progress until you reach the next impasse.

EVERY time you even think about changing any package during this
process, you have to recalculate the entire path from there on. It is
seriously painful.

> > These have to be
> > resolved manually by either temporarily using packages built elsewhere
> > or by manually building parts of a package to solve the dependancies.

Precisely.
 
>  or by using e.g. debian armel packages a la cross-debootstrap
> (rootstock under the dreaded ubuntu), that gets you into a position
> where each of those dependencies can be replaced one at a time.

Correct.
 
>  ... where is all this documented?

It's not.

Documenting it means keeping it correct and that's just too much work.

>  has anyone actually done this

Yes. Me - I was cross-building the entire chain too. It took me the
best part of a year to get through 200 packages. i.e. SERIOUSLY
reconsider precisely how many packages you want to rebuild and how many
NEED to be rebuilt.

Unless you are making changes to the packages - indeed, unless you're
making FUNCTIONAL changes to packages - do not rebuild.

Use Emdebian Grip which provides smaller versions of existing Debian
packages without binary changes. Please discuss this further on the
debian-embedded mailing list.

> - documented and automated e.g. how the
> debian-armel port was created, when previously there was only the
> debian-arm one?

Native ports start at the toolchain and work up, gradually, putting
aside packages that build-depend on stuff you haven't built yet and
occasionally going back over the list. It takes time, lots of time.
 
>  because it really does make sense to have a way to do automated total
> recompiles for e.g. the cortex a8, and if debian won't "officially"
> add that as an architecture, at least having a well-documented and
> automated process by which a random person can just... set some
> machines compiling for a month, would be good.

*Precisely* what changes do you need for that "architecture" - is it
really a different architecture from armel? (Answers to debian-embedded
please.)

-- 


Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/



pgpICQa5X650Z.pgp
Description: PGP signature

Re: Very newbe help/pointers required about building a distribution from scratch

[Neil Williams]

On Wed, 10 Mar 2010 21:52:57 +
Neil Williams  wrote:

> >  has anyone actually done this
> 
> Yes. Me - I was cross-building the entire chain too. It took me the
> best part of a year to get through 200 packages. i.e. SERIOUSLY
> reconsider precisely how many packages you want to rebuild and how many
> NEED to be rebuilt.

That didn't come across as I intended. Others, lots of others, have
done native builds from scratch - my emphasis was preparing a complete
cross-built distro from scratch. That is not something I recommend
anyone else tries and I'm now trying to create a way for others to do a
partial rebuild, only putting time into packages that really need to be
changed from the standard Debian package. Out of 2,000 packages, I'm
expecting to need to rebuild less than 100.

(Some idea of the packages involved can be gleaned from the Emdebian
CodeAudit wiki page [0]. Most of those do NOT need to be rebuilt,
the only ones are probably those with tags highlighted in bold.)

[0] http://wiki.debian.org/EmdebianCodeAudit

-- 


Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/



pgpXsNhxBWCCH.pgp
Description: PGP signature

Re: Bug#540215: Introduce dh_checksums

[Frank Lin PIAT]

Hello,

On Mon, 2010-03-08 at 17:36 +0100, Frank Lin PIAT wrote:
> On Thu, 2010-03-04 at 20:08 +0100, Tollef Fog Heen wrote:
> >  Frank Lin PIAT wrote:
> > > What about a transitional dh_md5sums that would produce md5sum AND
> > > invoke dh_sha ?
> > 
> > Or call it dh_checksums or something so we don't have to change the tool
> > name each time we decide to change the algorithm.
> 
> Find a patch attached, for a smooth transition from DEBIAN/md5sums to a
> recent checksum.


Since SHA algorithms is a family, tools and API usually implement
multiple variants. Wouter's initial email suggested to use the name
shasums. I must admit I find this quite sensible for future
improvements. People should be encourage to detect and support SHA-224
and better hash, even though we should only accept sha256 in the archive
for now.

I have still named the helper "dh_checksums", because it we ever want to
ship a different algorithm, we would probably still use the same
(updated) helper to generate that file.

Find an updated patch attached.

Regards,
diff --git a/debian/copyright b/debian/copyright
index a9f950d..162bfc0 100644
--- a/debian/copyright
+++ b/debian/copyright
@@ -48,7 +48,7 @@ Copyright: Steve Robbins 
 License: GPL-2+
 
 Files: dh_md5sums
-Copyright: Charles Briscoe-Smith 
+Copyright: Charles Briscoe-Smith , Frank Lin PIAT 

 License: GPL-2+
 
 Files: dh_bugfiles
diff --git a/debian/links b/debian/links
new file mode 100644
index 000..3e7d603
--- /dev/null
+++ b/debian/links
@@ -0,0 +1,3 @@
+usr/share/man/man1/dh_md5sums.1.gz usr/share/man/man1/dh_checksums.1.gz
+usr/bin/dh_md5sums usr/bin/dh_checksums
+
diff --git a/dh b/dh
index bcac8da..0aa9bc3 100755
--- a/dh
+++ b/dh
@@ -322,7 +322,7 @@ $sequences{install} = [...@{$sequences{build}}, qw{
 my @b=qw{
dh_installdeb
dh_gencontrol
-   dh_md5sums
+   dh_checksums
dh_builddeb
 };
 $sequences{'binary-indep'} = [...@{$sequences{install}}, @b];
diff --git a/dh_md5sums b/dh_md5sums
index da00090..33bf561 100755
--- a/dh_md5sums
+++ b/dh_md5sums
@@ -2,7 +2,7 @@
 
 =head1 NAME
 
-dh_md5sums - generate DEBIAN/md5sums file
+dh_checksums - generate DEBIAN/*sums files (md5, sha256)
 
 =cut
 
@@ -12,18 +12,24 @@ use Debian::Debhelper::Dh_Lib;
 
 =head1 SYNOPSIS
 
+B [S>] [B<-x>] [B<-X>I] 
[B<--include-conffiles>]
+
 B [S>] [B<-x>] [B<-X>I] 
[B<--include-conffiles>]
 
 =head1 DESCRIPTION
 
-dh_md5sums is a debhelper program that is responsible for generating
-a DEBIAN/md5sums file, which lists the md5sums of each file in the package.
-These files are used by the debsums package.
+dh_checksums is a debhelper program that is responsible for generating
+a DEBIAN/md5sums and DEBIAN/sha256sums files, which respectively lists the
+md5sums and sha256sums of each file in the package. These files are used
+by the debsums package.
 
-All files in DEBIAN/ are omitted from the md5sums file, as are all
+All files in DEBIAN/ are omitted from the checksums files, as are all
 conffiles (unless you use the --include-conffiles switch).
 
-The md5sums file is installed with proper permissions and ownerships.
+The checksums files are installed with proper permissions and ownerships.
+
+dh_md5sums is deprecated, you should use dh_checksums instead, which generates 
the
+type of checksums files recommended by the Debian policy.
 
 =head1 OPTIONS
 
@@ -37,7 +43,7 @@ redundant since it is included elsewhere in debian packages.
 =item B<-X>I, B<--exclude=>I
 
 Exclude files that contain "item" anywhere in their filename from
-being listed in the md5sums file.
+being listed in the checkums file.
 
 =back
 
@@ -48,15 +54,26 @@ init(options => {
"include-conffiles" => \$dh{INCLUDE_CONFFILES},
 });
 
+my ($basename) = $0=~m:.*/(.+):;
+
 foreach my $package (@{$dh{DOPACKAGES}}) {
next if is_udeb($package);
-   
+
+   if (basename($0) == 'dh_md5sums') {
+   warning("This program should no longer be used. Please read the 
dh_checksums(1) man page.");
+   }
+
my $tmp=tmpdir($package);
 
if (! -d "$tmp/DEBIAN") {
doit("install","-d","$tmp/DEBIAN");
}
 
+   # Detect if this is run multiple times (calling both dh_md5sums and 
dh_checksums?)
+   if (-f "$tmp/DEBIAN/md5sums" or -f "$tmp/DEBIAN/sha256sums") {
+   warning("Re-computing checksum file (even though md5sums and/or 
sha256sums exists)");
+   }
+
# Check if we should exclude conffiles.
my $exclude="";
if (! $dh{INCLUDE_CONFFILES} && -r "$tmp/DEBIAN/conffiles") {
@@ -76,6 +93,7 @@ foreach my $package (@{$dh{DOPACKAGES}}) {
}

complex_doit("(cd $tmp >/dev/null ; find . -type f $exclude ! -regex 
'.*/DEBIAN/.*' -printf '%P\\0' | xargs -r0 md5sum > DEBIAN/md5sums) 
>/dev/null");
+   complex_doit("(cd $tmp >/dev/null ; find . -type f $exclude ! -regex 
'.*/DEBIAN/.*' -printf '%P\\0' | xargs -r0 sha256sum > DEBIAN/sha256sums) 
>/dev/null");
# If the file's emp

Re: Bug#540215: Introduce dh_checksums, clear-signed checksum

[Frank Lin PIAT]

On Wed, 2010-03-10 at 10:52 -0800, Russ Allbery wrote:
> Peter Samuelson  writes:
> > [Wouter Verhelst]
> 
> >> At any rate, a PGP signature takes a lot of data; much more so than
> >> a checksum.  It's therefore more economical to produce a signed
> >> package.checksums file than it is to produce a package.pgpsigs.
> 
> > Huh?  Since asymmetric cryptography is so computationally expensive,
> > PGP never signs the payload directly.  Instead, the payload is hashed
> > and then the hash is signed.  So it is not (noticeably) more economical
> > to sign foo.md5sums than to sign the whole data.tar.gz.
> 
> However, since the most common verification action is probably going to be
> to check whether a specific file installed on the system has been
> modified, Wouter's approach is probably the best implementation strategy.
> It's more efficient to compute the checksum of a file, check that it
> matches the checksum in the signed file, and verify the signature on that
> file than it is to verify the data.tar.gz signature and then extract the
> relevant file from it and compare it to the file on disk.  Among other
> things, you can use the first algorithm with nothing but the signed
> checksum files, which are a lot smaller than keeping the whole package
> around.

GPG clear-signed messages
¨
I made some tests, and it seems that we could allow,but not require, GPG
signed checksum-file. sha256sum will ignore invalid lines by default
(unless you specify --warn option).

Similarly, the policy could state that GPG clear-signed shasum files are
allowed. Tools using shasum should still strip the signature, especially
when using the checksum for security purpose.


Let me know you find this feature useful (or over engineered). 

Regards,

Franklin


-- 
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/1268259720.3291.3261.ca...@solid.paris.klabs.be

Re: md5sums files

[Frank Lin PIAT]

On Wed, 2010-03-03 at 03:06 +0100, Wouter Verhelst wrote:
> 
> I must say I was somewhat surprised by these numbers. Out of 2483
> packages installed on my laptop, 2340 install md5sums. While that
> might've been useful at some point, I don't think it still is.

Hi all,

Can you think of any sensible reason for not including md5sums of
control files, especially the {pre,post}{inst,rm} scripts ?

In the shasum file, those files could be either:
 1. inserted, with the patch rewritten to match their expected 
location on the target system.
or
 2. inserted as a *comment* in the shasum file, like:
#68b329da9893e34099c7d8ad5cb9c940 CONTROL.TAR:postinst


Thanks,

Franklin


-- 
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/1268264672.3291.3654.ca...@solid.paris.klabs.be

Re: Bug#540215: Introduce dh_checksums, clear-signed checksum

[The Fungi]

On Wed, Mar 10, 2010 at 11:22:00PM +0100, Frank Lin PIAT wrote:
> I made some tests, and it seems that we could allow,but not require, GPG
> signed checksum-file. sha256sum will ignore invalid lines by default
> (unless you specify --warn option).
> 
> Similarly, the policy could state that GPG clear-signed shasum files are
> allowed. Tools using shasum should still strip the signature, especially
> when using the checksum for security purpose.

Is there any good reason not to use a detached signature in a
separate file instead? I know that doubles the number of files, but
it also reduces the raw size by around 47 bytes and simplifies
parsing of the checksum files themselves.
-- 
{ IRL(Jeremy_Stanley); PGP(9E8DFF2E4F5995F8FEADDC5829ABF7441FB84657);
SMTP(fu...@yuggoth.org); IRC(fu...@irc.yuggoth.org#ccl); ICQ(114362511);
AIM(dreadazathoth); YAHOO(crawlingchaoslabs); FINGER(fu...@yuggoth.org);
MUD(fu...@katarsis.mudpy.org:6669); WWW(http://fungi.yuggoth.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/20100311003709.gi1...@yuggoth.org

Bug#573393: ITP: maven-release -- Maven Release Plugin

[Gabriele Giacone]

Package: wnpp
Severity: wishlist
Owner: Gabriele Giacone <1o5g4...@gmail.com>

* Package name: maven-release
  Version : 2.0
  Upstream Author : Release plugin team at 
http://maven.apache.org/plugins/maven-release-plugin/team-list.html
* URL : http://maven.apache.org/plugins/maven-release-plugin
* License : ASL 2.0
  Programming Lang: java
  Description : Maven Release Plugin

 This plugin is used to release a project with Maven, saving a lot of
 repetitive, manual work. Releasing a project is made in two steps:
 prepare and perform. It provides the following goals:
  * release:clean - Clean up after a release preparation.
  * release:prepare - Prepare for a release in SCM.
  * release:prepare-with-pom - Prepare for a release in SCM, and generate
release POMs that record the fully resolved projects used.
  * release:rollback - Rollback a previous release.
  * release:perform - Perform a release from SCM.
  * release:stage - Perform a release from SCM into a staging folder/repository.
  * release:branch - Create a branch of the current project with all versions
updated.
  * release:update-versions - Update the versions in the POM(s).



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20100311005804.22252.90753.report...@phenomenon.

Re: Bug#540215: Introduce dh_checksums

[Ryan Niebur]

[despite having not yet replied to this thread, I am watching it...I
just don't have the desire to add to yet another giant, silly thread on
-devel. anyways...]

On Mon, Mar 08, 2010 at 12:21:42PM -0500, Joey Hess wrote:
> 
> >   Your comments on the patch are obviously welcome (feel free to hack
> >   it your self if you want)
> > 
> > Any chance to merge it before squeeze Freeze?
> 
> Is debsums ready to handle other checksums types?
> 

no. I will happily add support for it if there is consensus that a
switch to sha256sums (or any other checksum algorithm, for that
matter) should happen, and once packages begin to migrate to it.

Cheers,
Ryan

-- 
_
Ryan Niebur
ryanrya...@gmail.com


signature.asc
Description: Digital signature

Re: Team uploads.

[Paul Wise]

On Sun, Mar 7, 2010 at 1:47 PM, Charles Plessy  wrote:

> It was proposed in 2009 to formalise "Team uploads" in analogy to the "QA
> uploads", as a special case of NMU, where most conventions are relaxed.

As the initiator of the previous thread, I'd like to thank you for pushing this.

As far as implementation details go, would it be a good idea to also
add dch --team, which would produce the right string for the purposes
of quieting lintian?

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

Re: Team uploads.

[Luke Cycon]

On Thu, 2010-03-11 at 10:08 +0800, Paul Wise wrote:
> As far as implementation details go, would it be a good idea to also
> add dch --team, which would produce the right string for the purposes
> of quieting lintian? 

I think that would be useful.  I think if we don't do this, many will
simply "wing it" when writing the changelog rather than looking up the
'correct' way to quiet lintian.

A thought:  Maybe make it accept dch --team  for the
cases where the QA team for some reason may be uploading in place of the
normal team, or in the cases where there normally is no team.

(Sorry if that is somewhat confusing, I have been up for 26 hrs I am
seeing yellow elephants...)
-- 
Luke Cycon 


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

Sumit Kumar added you as a friend on Skoost

[Sumit Kumar]

Williams Orellana

Sumit Kumar added you as a friend on Skoost.

To see what your friends are up to and confirm Sumit Kumar as a friend, follow 
the link below:
http://www.skoost.com/social/?pid=5940686&eml=debian-de...@lists.debian.org&fid=19405212&blk=0&pge=12

If you want to unfriend (block) this person, follow the link below:
http://www.skoost.com/social/?pid=5940686&eml=debian-de...@lists.debian.org&fid=19405212&blk=1&pge=12

Skoost