from:"A Mennucc"

sorry, I was remembering incorrectly the dates
(and by no means meaning that I want the release to be 3 months later
than what Steve announced)

a.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: congratulations to our ftp-master team

Javier Fernández-Sanguino Peña wrote:
> On Wed, Dec 14, 2005 at 11:08:52AM +0100, Moritz Muehlenhoff wrote:
>  I *guess* mplayer could do likewise.
> 

MPlayer was once very picky regarding the versions of ffmpeg that it
does compile with. Moreover MPlayer want to link all core libraries
together (for performance reasons). So I think not.

> Notice, in any case, that the xvidcap packages in NEW *don't* use ffmpeg, the
> source code is there:
> 
> $ ldd /usr/bin/xvidcap  .

'ldd' does not mean anything: most versions of xvidcap ship a  copy of
ffmpeg in their own sources:

$ wget
http://heanet.dl.sourceforge.net/sourceforge/xvidcap/xvidcap-1.1.3-p7.tar.gz

$  tar xzf xvidcap-1.1.3-p7.tar.gz
$ du -s xvidcap-1.1.3-p7/ffmpeg/
6420xvidcap-1.1.3-p7/ffmpeg/

$  wget
http://heanet.dl.sourceforge.net/sourceforge/xvidcap/xvidcap-1.1.3.tar.gz
$ tar xzf xvidcap-1.1.3.tar.gz
$ du -s xvidcap-1.1.3/ffmpeg/
6340xvidcap-1.1.3/ffmpeg/


a.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

I did ask, Re: congratulations to our ftp-master team

Dear Jeroen and everybody,

here attached is an email I sent in September.

Yes, I did ask to ftp-masters clarifications about your proposal in
http://lists.debian.org/debian-devel/2005/04/msg00997.html
and never received a reply.

Jeroen van Wolffelaar wrote:
> While you indeed haven't got a later mail, you also didn't ask for one
> to the best of my knowledge (my memory isn't infallible, so I might be
> wrong, if so, I'm sorry, please correct me)...

yes, your memory failed  :-)
(you are in the CC of the attached email)

> I'm wondering what bit of my last few lines in the quoted email were
> unclear. While I specifically noted that removing mpeg encoding stuff
> might or might not be required, I explicitely said that stripping it
> anyway will make the whole pondering on whether it can be in the
> (source) package at all moot for the question whether mpeg encoding
> would be legal to ship on ftp.debian.org. 

(sorry my english fails me here)

>To the best of my knowledge,
> mpeg encoding stuff is nowhere near the core funcionality of mplayer
> anyway, isn't it?

yes AFAIK mencoder cannot encode MPEG2 in this version (that is in NEW
queue)

> Of course, if this way is choosen and is turning out
> to work out, later inclusion of the mpeg encoding stuff in mplayer must
> be discussed with ftp-master prior to it happening -- we (as in, Debian
> users in general) just get to have a chance of a slightly crippled
> mplayer in the archive in the meanwhile.
> 

I agree

> As in all cases, final verdict on whether a package will pass NEW
> is made at the time it's sitting in NEW and being processed by an
> ftp-master team member

Of course.

This is what I have been waiting for. For 880 days, roughly.

a.
>From debdev Mon Sep 26 11:33:39 2005
Date: Mon, 26 Sep 2005 11:33:39 +0200
To: [EMAIL PROTECTED]
Cc: Diego Biurrun <[EMAIL PROTECTED]>, MJ Ray <[EMAIL PROTECTED]>,
Dariush Pietrzak <[EMAIL PROTECTED]>,
Joerg Jaspert <[EMAIL PROTECTED]>,
Jeroen van Wolffelaar <[EMAIL PROTECTED]>
Subject: questions on mplayer 
Message-ID: <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature"; boundary="nFreZHaLTZJo0R7j"
Content-Disposition: inline
User-Agent: Mutt/1.5.9i
Status: RO
Content-Length: 2300
Lines: 64

--nFreZHaLTZJo0R7j
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Dear ftp-masters,=20
(and in particular Jeroen van Wolffelaar and Joerg Jaspert,
who have discussed the problem before),

in April 2005, during a thread discussing inclusion of mplayer in Debian,
at http://lists.debian.org/debian-devel/2005/04/msg00997.html
J. van Wolffelaar  expressed the opinion that nowadays the only
issue still blocking acceptance of mplayer in Debian may be=20
the (*) presence of MPEG encoding software.=20

[(*) as a matter of fact, up to some time ago AFAIK mplayer was unable to
 encode MPEG stream; but I heard that they are working on it]

J. van Wolffelaar also said though that "We're not (yet?)  saying it's
*required* to strip MPEG encoding stuff, but in my personal opinion,
it seems likely that this is what it'll turn out to be."

I would be very grateful if the ftp-masters team may finally decide
what are the requirements so that mplayer be accepted into Debian;
in doing so, they may want to read
  http://people.debian.org/~mjr/legal/mplayer.html
where M J Ray summarizes and links many info.

To fix ideas, I would need official (at least privately to us) answers
to these questions:

1) can mplayer be included into Debian, possibly with some fixes,
 including removal of source from the mplayer...orig.tar.gz ?
2) (if yes) do we need to remove MPEG decoding stuff?
3) what other problems should we fix ?
 (please read  http://people.debian.org/~mjr/legal/mplayer.html
  to know what has been already fixed )

The above questions are somewhat urgent, since the current version of
mplayer in NEW has a security bug, so I would love to prepare a new
version, and I would love to prepare it to comply to any request by
the ftp-masters, so that I may upload it into NEW for their review.

a.

--=20
Andrea Mennucc
 "Ukn ow,Ifina llyfixe dmysp acebar.ohwh atthef"

--nFreZHaLTZJo0R7j
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDN8Bz9B/tjjP8QKQRAmxfAJ9IJ686tgGjSRBIbqBqQaACm7OROwCdH94G
ulHqI6eqYyiOis8K8mrKz/8=
=6Wc/
-END PGP SIGNATURE-

--nFreZHaLTZJo0R7j--

signature.asc
Description: OpenPGP digital signature

Re: congratulations to our ftp-master team

actually, there was a response in Aug 2004, as in attachment


A Mennucc wrote:
> The oldest upload of  'mplayer' that I still find in my harddisk was 
> 'Wed Jul 23 10:44:54 2003'  (see attachment)
> 
> So 'mplayer' has been waiting in NEW queue for some response from
> ftp-masters for 876 days (at least)

>From [EMAIL PROTECTED]  Mon Aug 16 00:54:00 2004
Return-Path: <[EMAIL PROTECTED]>
Delivered-To: [EMAIL PROTECTED]
Received: from sns.it (mail.sns.it [192.167.206.31])
by tonelli (Postfix) with ESMTP id 68F2517601
for ; Mon, 16 Aug 2004 00:54:00 +0200 (CEST)
Received: from newraff.debian.org ([208.185.25.31] verified)
  by sns.it (CommuniGate Pro SMTP 4.1.8)
  with ESMTP id 20014347 for [EMAIL PROTECTED]; Mon, 16 Aug 2004 01:01:46 +0200
Received: from troup by newraff.debian.org with local (Exim 3.35 1 (Debian))
id 1BwTic-00016O-00; Sun, 15 Aug 2004 18:43:14 -0400
From: James Troup <[EMAIL PROTECTED]>
To: A Mennucc1 <[EMAIL PROTECTED]>,
Dariush Pietrzak <[EMAIL PROTECTED]>
X-Katie: lisa $Revision: 1.30 $
Cc: Debian Installer <[EMAIL PROTECTED]>
Precedence: bulk
Subject: mplayer_1.0.cvs20030324-1_i386.changes REJECTED
Message-Id: <[EMAIL PROTECTED]>
Sender: James Troup <[EMAIL PROTECTED]>
Date: Sun, 15 Aug 2004 18:43:14 -0400
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on tonelli.sns.it
X-Spam-Level: 
X-Spam-Status: No, hits=-4.9 required=4.5 tests=AWL,BAYES_00 autolearn=ham 
version=2.63
Status: RO
X-Status: A
Content-Length: 299
Lines: 16

Hi,

Sorry for the delay in processing this package.

Please upload a version with a sane copyright file - the one currently
in the package still just says "GPL".

-- 
James



===

If you don't understand why your files were rejected, or if the
override file requires editing, reply to this email.

policy on stati/dynamically linked binaries

2006-01-02 Thread A Mennucc

hi 

does the Debian Policy mandate that binaries should be dynamically
linked and not statically linked to their needed libraries ?

I thought so but I could not find it; in particular, I looked in
section "10.1 Binaries", where it goes at length in talking of the
debugging and stripping options, but it never explicitly says that
binaries should be dynamically linked.

I noted this curious fact while posting bug 345506.

a.

-- 
Andrea Mennucc
 "E' un mondo difficile. Che vita intensa!" (Tonino Carotone)


signature.asc
Description: Digital signature

new mplayer 1.0pre7try2 package

2006-01-16 Thread A Mennucc


hi everybody 

a new version of mplayer  1.0pre7try2  is available ; add  either

for the etch version, the line
 "deb http://tonelli.sns.it/pub/mplayer/etch ./"

or

for the sarge version, the line
 "deb http://tonelli.sns.it/pub/mplayer/sarge ./"

to /etc/apt/source.list .

a.


signature.asc
Description: Digital signature

CERT* VB-98.04: Vulnerabilities in xterm and Xaw

1998-04-28 Thread A Mennucc



Hi

Are we aware of (concerned by) 
 ftp://ftp.cert.org/pub/cert_bulletins/VB-98.04.xterm.Xaw
?
it says that 


> Vulnerabilities exist in the terminal emulator xterm(1), and the Xaw
> library distributed in various MIT X Consortium; X Consortium, Inc.;
> and The Open Group X Project Team releases. These vulnerabilities may
> be exploited by an intruder to gain root access. 

the only solutions seems to

  chmod 0755 `which xterm`



thanks and bye

a.m.

ps: I have a proposal: why not do this:
 1) create a  debian mailing list 
 (lets call it   "debian-warning" just to make the point),
 for very sensitive informations,
 like the presence of a security bug in a package,
 or of a flaw that may damage data or similair.
 2) advertise it on debian-*
 3) tweack the smail and sendmail packages so that
 on the installation they will ask to the root
 (and strongly suggest) that he/she joins 
 "debian-warning" , (and then do it automatically)

 This would create a channel that we now lack:
 "debian-warning" should be a list of very low traffic,
 so that people would really read it
 
 An example: some time ago someone by mistake
 uploaded a version of  grep that was broken;
 I installed it, and lost functionality of some 
 things I needed, and the lost a lot of time
 trying to understand what had gone wrong;
 had I received a message from debian-warning
 I would have not installed it. 
 Another example is of course the above message.
 


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: mplayer 1.0pre6a-4 for i386 and PowerPC and sparc

2005-04-07 Thread A Mennucc

Laszlo Boszormenyi wrote:
On Tue, 2005-03-15 at 00:56 +0100, Sven Luther wrote:
 

Well, there are two issues here, one is why mplayer is not in debian.
Supposedly it was because the legal situation was not clear and that made it
dangerous and maybe illegal for us to distribute it. I wonder why ubuntu does
not have this problem (even it if is in universe/multiverse), and if maybe
this means the problems got solved and it could be included in debian now, or
maybe because ubuntu just didn't care about the legal dubious situation.
   

Just a note, that their homepage[1] is something like closed:
"Free Software Multimedia Threatened by Software Patents
Closed for patent infringement
This site has been shut down because of numerous patent violations in
MPlayer. The other free software multimedia players are next." [...]
This is a preliminary warning, but everyone should look into all
possibilities.
if mplayer will become illegal because of the new european patent laws, 
so will be xine and all other programs that are already in Debian

a.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

arm seems OK: release status?

2005-04-11 Thread A Mennucc

hi
reading the latest message on the status of the release
http://lists.debian.org/debian-devel-announce/2005/04/msg3.html
I understood that the release was near, and that, given good progress 
with d-i and
testing-security, the main showstopper was the arm buildds trouble. (*)

Yesterday I have uploaded two packages, with low priority, and the arm 
buildds
compiled them after only 4 hours.

So I am curious : what is stopping the freeze now? testing-security?
a.
ps: (*)  OTOH, that message was issued on april 1st :->
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: arm seems OK: release status?

2005-04-11 Thread A Mennucc

Steve Langasek wrote:
So I am curious : what is stopping the freeze now? testing-security?
   

What's stopping the freeze is all the people uploading their low-priority
packages and keeping the arm autobuilders from ever catching up on the ones
that are actually medium and high priority.  ARM is *not* OK; we still have
only two buildds on-line instead of the usual four, and the build queue is
getting longer, not shorter.
 

hi Steve
your answer is puzzling. How is the queue in arm buildd managed?
If I would design a queue for a buildd, I would put medium and high 
priority packages
before low priority packages. You seem to suggest that this is not the case.
So I do not fully understand your "ever catching up...medium and high 
priority" comment.

Or... wait... maybe I understand... the problem is
http://buildd.debian.org/stats/graph-week.png
That, and still waiting for the glibc upload to roll in, and for
testing-security to be 100% on-line.
 

ok
a.
ps: I promise not to upload anything else :-)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: arm seems OK: release status?

2005-04-11 Thread A Mennucc

when a buildd builds a package, it first install all build-dependencies, 
then compiles, then remove all build-dependencies. For my package, that 
was a total of 113 MB of data to be moved in and out of disks;
since ARM is running late, maybe it would be wise to not remove 
build-dependencies at the end of a run, (and check for any build 
conflict before starting, and just remove that)

for example, to compile my package , sbuild had to install things as
gettext, libtool autotools-dev debhelper xlibs-dev libxaw7-dev xutils texinfo
I propose to keep them installed for some time..
moreover my package depends on   libgtk2.0-dev: I guess there are many packages
that has the same dependency
a.
Steve Langasek wrote:
On Mon, Apr 11, 2005 at 09:25:56AM +0200, A Mennucc wrote:
 

reading the latest message on the status of the release
http://lists.debian.org/debian-devel-announce/2005/04/msg3.html
I understood that the release was near, and that, given good progress 
with d-i and
testing-security, the main showstopper was the arm buildds trouble. (*)
   

 

Yesterday I have uploaded two packages, with low priority, and the arm 
buildds
compiled them after only 4 hours.
   

 

So I am curious : what is stopping the freeze now? testing-security?
   

What's stopping the freeze is all the people uploading their low-priority
packages and keeping the arm autobuilders from ever catching up on the ones
that are actually medium and high priority.  ARM is *not* OK; we still have
only two buildds on-line instead of the usual four, and the build queue is
getting longer, not shorter.
That, and still waiting for the glibc upload to roll in, and for
testing-security to be 100% on-line.
 


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

mplayer 1.0pre7

2005-04-25 Thread A Mennucc

hi

mplayer 1.0pre7 is ready and packaged at
http://tonelli.sns.it/pub/mplayer/sarge

a.

ps: still no news from ftpmasters... hope they at least will try to read
  http://people.debian.org/~mjr/mplayer.html

-- 
Andrea Mennucc
 "E' un mondo difficile. Che vita intensa!" (Tonino Carotone)


signature.asc
Description: Digital signature

Re: mplayer 1.0pre7

2005-04-26 Thread A Mennucc

I had forgotten  mplayer_1.0pre7.orig.tar.gz
now it is there
A Mennucc wrote:
hi
mplayer 1.0pre7 is ready and packaged at
http://tonelli.sns.it/pub/mplayer/sarge
a.
ps: still no news from ftpmasters... hope they at least will try to read
 http://people.debian.org/~mjr/mplayer.html
 


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Is Luca - De Whiskey's - De Vitis MIA?

2005-06-07 Thread A Mennucc


Roberto C. Sanchez wrote:


I am wondering what the deal is with Luca and his packages,
specifically httperf.

httperf was uploaded once, 3.5 years ago.  It has two important and one
normal bug [0].  He has never responded to any bug on httperf.

#215277: httperf: please update libssl dependency (1 year and 239 days)
#308097: httperf errors out when requesting SSL sessions (30 days)
#170060: Please move httperf to main archive (2 years and 198 days)

Of his other packages [1], his latest upload was late 2003.  He has a
number of bugs open [2] as far back as 6 years ago.  Many are
unacknowledged, including two important bugs, one regarding a policy
violation in a package description and another about a filename
collision between a package he maintains and another package.

Just wondering what, if anything, should be done.  Personally, I would
be willing to adopt httperf because I would like to see the bugs fixed.

-Roberto

[0] http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=httperf
[1] http://qa.debian.org/[EMAIL PROTECTED]
[2] http://bugs.debian.org/cgi-bin/pkgreport.cgi?maint=luca%40debian.org
 

some people started to work on zope , on pkg-zope on alioth, and indeed 
we have not heard from him in a long time (that is, since June 2004)


a.



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

new mplayer

2006-09-21 Thread A Mennucc

hi everybody

I prepared a new mplayer (with help from  Diego Biurrun of the mplayer team)

it has version 1.0~rc1~svn19921 
(note that I have decided to use the new ~ element, so this version
appears to be older than 1.0rc1 or 1.0pre8 ; you may need
to manually use dpkg to install it)

it was uploaded into Debian incoming, and it is available from
 http://tonelli.sns.it/pub/mplayer/etch/

a.

-- 
Andrea Mennucc
 "E' un mondo difficile. Che vita intensa!" (Tonino Carotone)


signature.asc
Description: Digital signature

FAQ, Re: new mplayer

2006-09-26 Thread A Mennucc


hi everybody

I just now notice the debate on mplayer going on;
so here are a few answers

[many people]
> MPlayer dev team and Debian do not work together

this is not the case.

I have been working with Diego Biurrun (of the mplayer team)
and Joerg Jaspert (of ftp-master team)

many changes that Joerg asked have been applied directly
by Diego into SVN

this is why this package is a SVN snapshot

> Please tell me what's wrong with current package and what can we
> do to make it better and stop saying me it's license issue.

in July, Joerg reviewed the mplayer package in NEW and listed
many issues; most of them regards the licenses

 Since MPlayer incorporates code from many sources, it needs to
properly document this fact ; this was done,
by adding all necessary licenses and copyrights statements
both in upstream code (thanks to Diego) and in
debian/copyright file . Moreover now Mplayer
documents the differences between its shipped version
of libraries such as FFMPEG, and the upstream version ;
this is again done to comply with GPL .

 [Andrew Donnellan ]
> Since when was MPlayer acceptable in the Debian archive?

mplayer is in the NEW queue (sorry for the misunderstanding)

 [Yavor Doganov]
> I was wondering, what's so important about mplayer?

it works quite well for me ;  e.g. , I have a digital camera
that can record movies (MPEG4 in MOV) , last time I tried
(~1 month ago) totem and xine reproduced my movies with skippy audio ;
moreover , when I tried ~1 year ago, mplayer was capable
of playing DVDs on my Pentium 450, while some other players
were skipping frames .

Of course, other people may prefer other players... that is fine for
me; one nice point of Debian is that it offers all choices,
Gnome vs KDE, Emacs vs Vi vs ... , OpenOffice vs AbiWord ;
so it is just a big shame that mplayer is still missing


 [fEnIo]
> Mplayer comes with his friend mencoder.

Not in Debian, and it probably never will.
At the request of Joerg from ftp-master team, I even deleted mencoder.c
from the tarball, to make it clear that we do not want to incur in any
patent problem.

> Yes, I know there won't be w32codecs package in Debian, but even
> mplayer would be great addition.

there is a script for downloading those


a.

ps: feel free to ask more questions; if you want a quick answer, CC me, 
I do not read d-devel usually



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#397615: ITP: fuzzyocr -- spamassassin plugin to check image attachments

2006-11-08 Thread A Mennucc

Package: wnpp
Severity: wishlist
Owner: A Mennucc <[EMAIL PROTECTED]>


* Package name: fuzzyocr
  Version : 2.3b
  Upstream Author : Christian Holler, decoder_at_own-hero_dot_net
* URL : http://wiki.apache.org/spamassassin/FuzzyOcrPlugin
* License : (GPL, LGPL, BSD, MIT/X, etc.)
  Programming Lang: (C, C++, C#, Perl, Python, etc.)
  Description : spamassassin plugin to check image attachments

This Spamassassin plugin checks for specific keywords in image/gif,
image/jpeg or image/png attachments, using gocr (an optical character
recognition program).

This plugin can be used to detect spam that puts all the real spam
content in an attached image, while the mail itself is only random
text and random html, without any URL's or identifiable information.

Additionally to the normal OcrPlugin, it can do approximate matches on
words, so errors in recognition or attempts to obfuscate the text
inside the image will not cause the detection to fail. Another
improvement was to move the wordlist into the configuration file so it
can be easily extended.




a.

-- 
Andrea Mennucc

"The EULA sounds like it was written by a team of lawyers who want to tell 
me what I can't do, and the GPL sounds like it was written by a human 
being who wants me to know what I can do."
Anonymous,http://www.securityfocus.com/columnists/420


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

double GPG signature in Release files

hi

I use amd64 here ; recently all tools (aptitude, debmirror)
started complaining that archives are not properly signed ;
here is a snippet of code to show the situation:

$ cd /var/lib/apt/lists
$ for i in *Release ; do echo === $i ; \
 gpg --verify $i.gpg $i && echo  OK ; done

=== ftp.debian.org_debian_dists_unstable_Release
gpg: Signature made Wed Nov 22 00:19:30 2006 CET using DSA key ID 2D230C5F
gpg: Good signature from "Debian Archive Automatic Signing Key (2006)
<[EMAIL PROTECTED]>"
gpg: WARNING: This key is not certified with a trusted signature!
gpg:  There is no indication that the signature belongs to the
owner.
Primary key fingerprint: 0847 50FC 01A6 D388 A643  D869 0109 0831 2D23 0C5F
gpg: Signature made Wed Nov 22 00:19:30 2006 CET using DSA key ID 6070D3A1
gpg: Can't check signature: public key not found
=== ftp.it.debian.org_debian_dists_etch_Release
gpg: Signature made Wed Nov 22 00:18:42 2006 CET using DSA key ID 2D230C5F
gpg: Good signature from "Debian Archive Automatic Signing Key (2006)
<[EMAIL PROTECTED]>"
gpg: WARNING: This key is not certified with a trusted signature!
gpg:  There is no indication that the signature belongs to the
owner.
Primary key fingerprint: 0847 50FC 01A6 D388 A643  D869 0109 0831 2D23 0C5F
gpg: Signature made Wed Nov 22 00:18:42 2006 CET using DSA key ID 6070D3A1
gpg: Can't check signature: public key not found
=== ftp.it.debian.org_debian_dists_unstable_Release
gpg: Signature made Wed Nov 22 00:19:30 2006 CET using DSA key ID 2D230C5F
gpg: Good signature from "Debian Archive Automatic Signing Key (2006)
<[EMAIL PROTECTED]>"
gpg: WARNING: This key is not certified with a trusted signature!
gpg:  There is no indication that the signature belongs to the
owner.
Primary key fingerprint: 0847 50FC 01A6 D388 A643  D869 0109 0831 2D23 0C5F
gpg: Signature made Wed Nov 22 00:19:30 2006 CET using DSA key ID 6070D3A1
gpg: Can't check signature: public key not found
=== security.debian.org_dists_etch_updates_Release
gpg: Signature made Tue Nov 21 19:14:24 2006 CET using DSA key ID 2D230C5F
gpg: Good signature from "Debian Archive Automatic Signing Key (2006)
<[EMAIL PROTECTED]>"
gpg: WARNING: This key is not certified with a trusted signature!
gpg:  There is no indication that the signature belongs to the
owner.
Primary key fingerprint: 0847 50FC 01A6 D388 A643  D869 0109 0831 2D23 0C5F
 OK


as you see many archives seem to be signed with two keys:
1st is key 2D230C5F
 "Debian Archive Automatic Signing Key (2006) <[EMAIL PROTECTED]>"
2nd is a key 6070D3A1

why this ?

where do I find the latter key ?

a.



signature.asc
Description: OpenPGP digital signature

Re: Debian Archive Automatic Signing Key (4.0/etch)?

Martin Zobel-Helas ha scritto:
>
> gpg --recv-keys A70DAF536070D3A1 && (gpg --export -a A70DAF536070D3A1 | 
> apt-key add -)
> 

$ gpg --recv-keys A70DAF536070D3A1
gpg: requesting key 6070D3A1 from hkp server keyring.debian.org
gpgkeys: key A70DAF536070D3A1 not found on keyserver
gpg: no valid OpenPGP data found.
gpg: Total number processed: 0



signature.asc
Description: OpenPGP digital signature

Re: double GPG signature in Release files

uh I see that there is a thread on that

a.



signature.asc
Description: OpenPGP digital signature

Re: Debian Archive Automatic Signing Key (4.0/etch)?

Luca Capello ha scritto:
> Hello!
> 
> On Wed, 22 Nov 2006 12:09:58 +0100, Hendrik Sattler wrote:
>> Noone answered, yet, why this key is not in debian-archive-keyring
>> package.
> 
> It's there since the last update:
> =
> debian-archive-keyring (2006.11.22) unstable; urgency=low
> 
>   * Non-maintainer upload.
>   * Add Etch release key
>   * Bump priority to important (Closes: Bug#397698)
>   * Update FSF address in copyright.
> 
>  -- Anthony Towns   Wed, 22 Nov 2006 01:30:50 +1000
> =
> 
>> I thought that the whole idea was to make it available before it
>> gets used. 
>> That would be the easiest (install it at installation time) and
>> "apt-key update" could be used.
> 

that package is only 2 days old and did not transition to etch yet

so it is too early to start signing etch archives with it 

and it empties the whole idea : to restore my trust path , I
will have to manually download that package and install it

a.



signature.asc
Description: OpenPGP digital signature

just wait more next time, Re: Debian Archive Automatic Signing Key (4.0/etch)?

actually, there is no need for tons of documentation:
 the usage of the package debian-archive-keyring should
 really automate the whole thing, as long as it is done correctly:

1) release team generates new key and new package debian-archive-keyring
2) users install it : in postinst, /usr/bin/apt-key update is run
3) after some time (>10 days), release team starts using new key

If done that way, it really works, and we have a trust path,
since the new package debian-archive-keyring is certified by
the old key.

The problem is that , in this particular case,
the new package debian-archive-keyring was released 22 Nov,
and the new key was used almost immediately : so people
using testing did not have time to import it.

next time, they should just wait (at least 10 days -
but maybe 30days would be better)

a.

Andreas Tille ha scritto:
> On Tue, 21 Nov 2006, Kurt Roeckx wrote:
> 
>> On Tue, Nov 21, 2006 at 04:50:29PM -0600, Peter Samuelson wrote:
>>>
>>> [Martin Zobel-Helas]
 gpg --recv-keys A70DAF536070D3A1 && (gpg --export -a
 A70DAF536070D3A1 | apt-key add -)
>>>
>>> Uh, don't forget the part about verifying that the key is actually
>>> signed by the ftpmasters.  Skipping that step pretty much defeats the
>>> entire point.
>>>
>>>   gpg --list-sigs A70DAF536070D3A1
>>
>> Try gpg --check-sigs A70DAF536070D3A1 instead.
> 
> But Hendrik Sattler is perfectly right and this knowledge has to be stored
> at prominant places like:
> 
>a) installation manual
>b) apt-key.8
>c) perhaps somewhere else
> 
> Could maintainers of a) and b) (and perhaps c) ;-)) acknowledge, that this
> will be done or should we rather file bug reports (IMHO with severity
> "important") to these packages?
> 
> Kind regards
> 
>  Andreas.
> 
> PS: debian-boot@lists.debian.org in CC because of the installation manual
> issue.  Forgive me if this should be off-topic there.
> 




signature.asc
Description: OpenPGP digital signature

Re: Debian Archive Automatic Signing Key (4.0/etch)?

Julien Cristau ha scritto:
> On Wed, Nov 22, 2006 at 14:53:38 +0100, A Mennucc wrote:
> 
>> that package is only 2 days old and did not transition to etch yet
>>
>> so it is too early to start signing etch archives with it 
>>
>> and it empties the whole idea : to restore my trust path , I
>> will have to manually download that package and install it
>>
> no, because the Release file is still signed with the 2006 key, which is
> in apt's keyring already.

you are right on that : I can check that at least one key is verifying OK
but gpgv returns an error for that;
so debmirror does not run : look

$ cd /var/lib/apt/lists
$ for i in *unstable*Release ; do echo === $i ; \
 gpg --verify $i.gpg $i && echo  OK ; done

=== ftp.debian.org_debian_dists_unstable_Release
gpg: Signature made Wed Nov 22 00:19:30 2006 CET using DSA key ID 2D230C5F
gpg: Good signature from "Debian Archive Automatic Signing Key (2006)
<[EMAIL PROTECTED]>"
gpg: WARNING: This key is not certified with a trusted signature!
gpg:  There is no indication that the signature belongs to the
owner.
Primary key fingerprint: 0847 50FC 01A6 D388 A643  D869 0109 0831 2D23 0C5F
gpg: Signature made Wed Nov 22 00:19:30 2006 CET using DSA key ID 6070D3A1
gpg: Can't check signature: public key not found

as you see, no OK is printed.

a.

-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Dropping GStreamer 0.8 for etch

2006-12-12 Thread A Mennucc

Josselin Mouette ha scritto:
> As the situation is very similar in mplayer, mplayer is considered
> RC-buggy by the security team.

Josselin Mouette is talking about is bug 395252

Moritz Muehlenhoff (that is in security) asserted that he thinks that
that bug 395252 should be RC

But then I asked to Moritz, and he answered me so
> On Wed, Nov 01, 2006 at 12:24:24AM +0100, A Mennucc wrote:
>> BTW: I have been assuming that Moritz is reporting the consensus of the
>> whole security team , and not only his personal opinion... is it so?
> 
> I'm speaking for myself. However, we already have unfixed issues in
> libavcodec in Sarge, which are very time-consuming to fix and apparently
> no one has started to work on in either, so I don't suppose anyone would
> be keen on it. CCing the rest of Security Team for comments.
>  
> Cheers,
> Moritz
(the above comes from
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=395252;msg=139   )

Moritz did not update me, or bug 395252, on the consensus of the
security team on this matter. (That is why I am CCing him).

Today, I have asked d-ctte to deliberate on 395252: see bug 402772.

Moreover, Josselin has filed 402793 re: gst-ffmpeg.

So now the security team should express their opinion on  those two bugs.

a.



signature.asc
Description: OpenPGP digital signature

Re: please let mplayer into testing

2006-12-12 Thread A Mennucc

Moritz Muehlenhoff ha scritto:
> A Mennucc wrote:
>> Brief summary of bug:  MPlayer contains an embedded copy of FFmpeg
>> (indeed, they are developed by ~the same people); Aur=E9lien G=C9R=D4ME a=
>> nd
>> Moritz Muehlenhoff ask that the mplayer package be dynamically linked to
>>  the libraries in the Debian package ffmpeg; they consider this a RC bug.=
>>
>> Unfortunately, this cannot be currently done (mplayer does not compile
>> with current ffmpeg package;  and we are too late to update ffmpeg into
>> Etch ; more details are in the above bug report).
>>
>> So we agreed to ignore that problem for the sake of the etch release
>
> Where did I agree until now?

sorry,  I got confused in the English, that last "we"
was meant to mean "me and Aurelien" (and not including you)

anyway, shortly after I wrote that email, the situation reverted again
(for worse); so currently there is no agreement between me and Aurelien,
and I put that matter to d-ctte, in bug 402772

>> Please hint MPlayer into Etch.
> 
> I've tried it myself and it is indeed not possible to link against
> libavcodec dynamically currently. Given that mplayer was only accepted
> into the archive 2.5 months after the current ffmpeg snapshot was made
> and that mplayer is an important application I do now think we can
> ignore this RC bug for Etch as a one-time exception. In any case further
> mplayer maintenance needs to be synchronised with Debian's libav[codec|
> format], even if it means to not being able to upload the most recent
> upstream version every week.

happy to know this. May you please forward this statement into bug
402772? (I would really appreciate).

> Also, the static linking against libdv introduced in 1.0~rc1-4 should
> be reverted.

I did not mean to introduce any static linking; I will investigate


a.



signature.asc
Description: OpenPGP digital signature

Re: please let mplayer into testing

2006-12-18 Thread A Mennucc

[actually, my original mail had to go to d-release, but I
miss-auto-completed the To:]

Bill Allombert ha scritto:
> On Tue, Dec 12, 2006 at 11:09:09PM +0100, A Mennucc wrote:
>> anyway, shortly after I wrote that email, the situation reverted again
>> (for worse); so currently there is no agreement between me and Aurelien,
>> and I put that matter to d-ctte, in bug 402772

the d-ctte, and all other people, settled for this final agreement
- the bug 395252 should stay RC , but
- the bug is though 'etch-ignore'

> If you need an example of massive code duplication between
> security-sensitive packages, I offer iceweasel and icedove:
> 
> LANG=C diff -sr icedove-1.5.0.8.dfsg1/build-dir/mozilla/ iceweasel-2.0+dfsg/ 
> | grep "are identical"|wc -l
>   21131
>
> So there are at least 21131 fully duplicated files between this two
> packages.

thanks for the tip

I agree with you... moreover, iceweasel/firefox , icedove/thunderbird ,
etc etc , have been a frequent source of security problems

indeed this kind of argument was already presented in the discussion  of
the bug 395252 , but it did not work


it seems that MPlayer is kind of a lighting rod for criticism and strong
feelings

a.



signature.asc
Description: OpenPGP digital signature

Re: db.debian.org (and related infrastructure) updates

2006-12-30 Thread A Mennucc

hi [& thanks Ryan for the work]

Ryan Murray ha scritto:
> The mail gateway, web scripts, and userdir-ldap command line interface have 
> all been updated to deal with the new fields.

I connected to the web interface at
https://db.debian.org/update.cgi?id=mennucc1

I found fields for birthdate and Greylisting and Callout, but no fields
for RBL and RHSBL and whitelisting

a.





signature.asc
Description: OpenPGP digital signature

kudos, Re: db.debian.org (and related infrastructure) updates

2007-01-06 Thread A Mennucc

hi

I keep statistics of my email

before I activated "greylisting" and "sender verification callouts", my
average was ~200 spam/day  (with peaks of ~400) ; after that, it is ~40
spam/day (and most do not pass thru debian.org, but are delivered
directly at my account)

so I want to kudo all people who made this possible

a.




signature.asc
Description: OpenPGP digital signature

FuzzyOcr 3.5.1 for Debian

2007-01-07 Thread A Mennucc

Hello all,

I have packaged fuzzyocr 3.5.1 for Debian ;
the name of the package is "fuzzyocr3" ;
I uploaded it into debian/experimental ;
it is also available at
http://tonelli.sns.it/pub/mennucc1/fuzzyocr

a.

ps: I previously uploaded  fuzzyocr 2.3b-1
as "fuzzyocr"



signature.asc
Description: OpenPGP digital signature

xdelta, "grave" bug 147187, time left

2007-01-13 Thread A Mennucc

hi

xdelta is affected by bug 147187

this is Steve Langasek analysis:
"the problem was that the xdelta file format includes information
telling xdelta how much memory it needs to allocate in order to read in
the patch structure -- and when allocating space for objects that
include pointers, this is obviously going to differ between 32-bit and
64-bit architectures. "

this bug's severity was debated a lot; in the end , it was decide to
downgrade it

fast forward to today: since I would need to use xdelta across 32bit and
64bit archs (see
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=147187;msg=53)
I found a patch that should solve the problem; this patch is used in
RedHat version of the package.

So the question to d-release team (and to the mantainer) is:
should/could I NMU a new version with this patch applied?

Also, how much time is left before Etch is released? I may actually
spend some time testing this patch (I now have access to a amd64).

a.



signature.asc
Description: OpenPGP digital signature

etch before vista

2006-03-24 Thread A Mennucc

hi everybody

According to the latest [1] Microsoft announcement, Vista will be released
in Jan 2007; according to our schedule [2],  Etch may be released in Dec 2006.

If we accomplish it, it will be a great feat: Debian will (possibly)
show it is able to relase two versions of its distribution since Jul
2002 (= woody release); whereas Microsoft seems unable to release its
own O.S. (even though XP has been out since Dec 2001, if I recall
correctly).

Yes guys, it means
 we (Debian + Open/Free SW community) manage to release
   ~ 9GB of binary precompiled integrated software , times
   ~ 10 binary architectures ,
 (maybe) twice , and  for free ...

 while in roughly the same  time frame 

 Microsoft is unable to release Vista, and Office [3] as well; that is
AFAIK less than 1GB of binary code.

Amazing.

Is somebody out there doubting that Free/Open Software will eventually 
lead?

I hope we do manage to release in Dec 2005 (and I thank people who
 work hard to this end).

a.

[1] http://arstechnica.com/news.ars/post/20060321-6433.html
[2] http://lists.debian.org/debian-devel-announce/2005/12/msg00013.html
http://lists.debian.org/debian-devel-announce/2005/10/msg4.html
[3] http://www.eweek.com/category2/0,1874,1840947,00.asp


signature.asc
Description: Digital signature

Re: etch before vista

2006-03-24 Thread A Mennucc

On Fri, Mar 24, 2006 at 08:07:48PM +0100, Joerg Jaspert wrote:
> On 10603 March 1977, A. Mennucc wrote:
> > I hope we do manage to release in Dec 2005 (and I thank people who
> >  work hard to this end).
> 
> We wont, im sure.

:->   gotme

but in the beginning of the email I got it right  :-)

 "yesterday" I went thru 4 airports, ~5000miles , 7 hours
 jetlag, 20 hours of travelling overall ; so a misstype is somewhat to
 be expected.
 ("yesterday" is quoted, since, for me , intercontinental flying feels
 more like two days than one) 

btw : I am in University of Minneapolis now, mail me for keysigning /
 beer / Debian related events

a.

-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

fonts prbl in sid

2006-04-24 Thread A Mennucc

hi

I use sid and Gnome ; I upgraded my box (after 3 weeks in which I did 
not have time to) ; now I have serious problems with fonts.

Symptoms: some programs fail to find and use the fonts ,and are then
almost unusable ; including 'emacs-snapshot-gtk' 'display' 'xmms'
('xmms' is missing fonts for the menus but not for the main display);
'gpr' 'gnomecal' .

Note that, in my desktop, I set:
$ env |  grep  LANG
LANG=it_IT.UTF-8
GDM_LANG=it_IT.UTF-8

note also that other programs are fine, for example, all GTK2 applications.

I encounter some peculiar behaviour, here is a listing

$ gnomecal 
(never starts) 

$ LANG='' gnomecal
(prints this forever)
The font 
"-adobe-helvetica-bold-r-normal--12-*-*-*-p-*-*-*,-cronyx-helvetica-medium-r-normal-*-14-*-*-*-p-*-koi8-r,-*-*-bold-r-normal--12-*-*-*-*-*-ksc5601.1987-0,*"
 does not support all the required character sets for the current locale 
"LC_CTYPE=en_US;LC_NUMERIC=C;LC_TIME=C;LC_COLLATE=C;LC_MONETARY=C;LC_MESSAGES=C;LC_PAPER=C;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=C;LC_IDENTIFICATION=C"
  (Missing character set "ISO8859-1")
  (Missing character set "ISO8859-1")

$ gpr
(starts, no text anywhere)

$ LANG='' gpr
(starts , text is blocky but fine)

$ display
 display: unable to load font 
`-*-helvetica-medium-r-normal--12-*-*-*-*-*-iso8859-1'.
 display: unable to load font 
`-*-helvetica-medium-r-normal--12-*-*-*-*-*-iso8859-1'.
(fails to start)

$ xlsfonts -fn -*-helvetica-medium-r-normal--12-*-*-*-*-*-iso8859-1
-adobe-helvetica-medium-r-normal--12-120-75-75-p-67-iso8859-1
-adobe-helvetica-medium-r-normal--12-120-75-75-p-67-iso8859-1
-adobe-helvetica-medium-r-normal--12-120-75-75-p-67-iso8859-1
-adobe-helvetica-medium-r-normal--12-87-100-100-p-0-iso8859-1
-adobe-helvetica-medium-r-normal--12-87-100-100-p-0-iso8859-1
-adobe-helvetica-medium-r-normal--12-87-100-100-p-0-iso8859-1

$ LANG='' display -font 
-adobe-helvetica-medium-r-normal--12-87-100-100-p-0-iso8859-1
display: unable to load font 
`-adobe-helvetica-medium-r-normal--12-87-100-100-p-0-iso8859-1'.
display: unable to load font 
`-adobe-helvetica-medium-r-normal--12-87-100-100-p-0-iso8859-1'.
(fails to start as well!)

$ xcalc -font   -adobe-helvetica-medium-r-normal--12-120-75-75-p-67-iso8859-1
Warning: Cannot convert string 
"-adobe-helvetica-medium-r-normal--12-120-75-75-p-67-iso8859-1" to type 
FontStruct
Warning: Missing charsets in String to FontSet conversion
Warning: Unable to load any usable fontset
(starts, fonts look funny)


Does anyone have an helping clue ? 

a.

-- 
Andrea Mennucc
 "E' un mondo difficile. Che vita intensa!" (Tonino Carotone)


signature.asc
Description: Digital signature

Re: fonts prbl in sid

2006-05-02 Thread A Mennucc

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Michael Meskes wrote:
> On Mon, Apr 24, 2006 at 11:38:43AM +0300, Daniel Stone wrote:
> 
>>>almost unusable ; including 'emacs-snapshot-gtk' 'display' 'xmms'
>>>('xmms' is missing fonts for the menus but not for the main display);
> 
> 
> Not sure if this is related but for display see 
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=363371
> 
> Michael

yes it was the same bug

 it was solved by forcing  dpkg-reconfigure to properly recreate
/etc/X11/xorg.conf ; then , after reboot , it all worked fine (for some
reason, server restart was not enough...)

a.


-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFEVzcx9B/tjjP8QKQRAul7AKCN64Qd7dCkMq0A/LapNK+zndaMXgCdGjaS
5SDTcri3TQ3Jz74ZgstUNqo=
=uaiD
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: fonts prbl in sid

2006-05-02 Thread A Mennucc

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

James Vega wrote:
> On Mon, Apr 24, 2006 at 11:22:42AM +0200, A Mennucc wrote:
> 
>>hi
>>
>>I use sid and Gnome ; I upgraded my box (after 3 weeks in which I did 
>>not have time to) ; now I have serious problems with fonts.
> 
> 
> Have you reconfigured xserver-xorg?  As part of the modular Xorg update,
> the directories the fonts reside in have moved.  Your xorg.conf may
> still be pointing to the old directories.  Refer to
> <http://wiki.debian.org/Xorg69To7> for other side-effects you may
> experience from the upgrade.


thank you,

it was not very easy to tell to have dpkg-reconfigure to properly
recreate /etc/X11/xorg.conf ; then I managed to put the correct MD4 in
the correct directory; then, after reboot , it all worked fine
(for some reason, server restart was not enough...)

a.



-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFEVzdl9B/tjjP8QKQRAmdVAJ9gyCVSM4LsV5pHRl8uoWIn3oGi7QCghWBc
xa5qEN8+/cVvy2Qy9HEHb+s=
=kt69
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: effectiveness of rsync and apt

2006-05-02 Thread A Mennucc

hi

I did a similar thing some time ago; I used 'xdelta' on two versions of
kernel and of tetex; the results were impressive; I could prepare a
'debdiff' that was < 10% (AFAICR) of the size, and that would recreate
an exact copy of the new version of the package, given the previous
version of the package. Currently my notebook is broken (power
transformer fried with a white flash); when it is alive again, I will
post more details.

a.

Brian Eaton wrote:
> Hello all -
> 
> Regarding the ideas discussed here:
> 
> http://rsync.samba.org/rsync-and-debian/rsync-and-debian.html
> 
> Has anyone ever done some log file analysis to figure out how much
> bandwidth would be saved by transferring package deltas instead of
> entire new packages?
> 
> Assuming someone hasn't done the work already, I'd be interested in
> looking at some logs to figure it out.
> 
> Regards,
> Brian
> 
> 

-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

exp. lightspeed disappeared

2006-05-10 Thread A Mennucc

hi

I uploaded an experimental version of 'lightspeed', as you see in
http://packages.qa.debian.org/l/lightspeed/news/20060507T214839Z.html
on Sun 7th of May ; but strangely enough it does not appear, neither in
http://packages.qa.debian.org/l/lightspeed.html
nor in
http://packages.debian.org/cgi-bin/search_packages.pl?searchon=names&version=all&exact=1&keywords=lightspeed

Actually, in this latter there is the version for kfreebsd-i386 , but not
the version for i386, that I uploaded.

Why?  

(also, who should I write to? if there is a more apt list to post this
message, please tell me)

a.

ps: note that the above is a NMU... I am helping fixing a bug; I 
 uploaded the new version in experimental to make it available
 to the bug reporter and so that I would see if autobuilders do compile it

-- 
Andrea Mennucc
 "Ukn ow,Ifina llyfixe dmysp acebar.ohwh atthef"


signature.asc
Description: Digital signature

Re: effectiveness of rsync and apt

2006-05-10 Thread A Mennucc

hi

I had the same idea some time ago

if you ever decide to work on that, I may help

Goswin von Brederlow wrote:

> I actualy have a little hack how one could implement patch debs now to
> test this out:
> 
> 1. Create an archive mirror with rsync batch files (or xdelta or
> whatever) between the last and current version of each package. It
> might be simplest to replace the data.tar.gz in each deb with the
> rsync batch file and leave the rest of the deb as is.
> 
> 2. Create Packages.gz and friends for those patch debs
> 
> 3. Create an apt method "http-patch" to apt that will first check for
> the old version of the package or dpkg-repack it, then forks the http
> method to download the patch deb, applies the patch and returns the
> build deb.
> 
> 4. Add
> 
> deb http-patch://server/path suite dist
> 
> to sources.list _before_ the normal http url.
> 
> 
> One drawback of this hack would be that you get an error from the
> http-patch method when you don't have the previous version available
> before apt-get falls back to the http url.
> 
> MfG
> Goswin
> 
> 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: exp. lightspeed disappeared

2006-05-12 Thread A Mennucc

Steinar H. Gunderson wrote:
> Perhaps it fixed itself? :-)

yes it did.

The reason I posted is that, when I posted, the page
http://packages.debian.org/lightspeed
was showing the kfreebsd binary but not the i386 binary
that I had uploaded...I was very puzzled!

thanks for checking

a.

ps: it seems anyway that there are some weird issue with
 archives: see
http://permalink.gmane.org/gmane.linux.debian.devel.general/100417



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

debdelta

2006-05-31 Thread A Mennucc

Dear Debian people,

I have completed a reasonably working version of 'debdelta', a package
suite to compute differences between Debian packages.

For sake of clarity, let's call '.debdelta' a file that encodes
the differences between Debian packages, and '.deb' a Debian package.

The command 'debdelta' creates a .debdelta ; the command 'debpatch'
applies it to the old .deb to recreate the new .deb ; or,
it can use the *installed* files of the old .deb.

The command 'debdelta-upgrade' is meant to be run between 'apt-get
 update' and 'apt-get upgrade'; it downloads .debdelta files and
 recreate the new .deb files from them; always using the *installed* old
 version of the .deb, and not the old .deb file itself.

Downloading .debdeltas instead of .deb packages can be a huge
benefit for people with slow Internet access, and/or to keep traffic
on servers low (as when the X security upgrade did saturate the server
security.debian.org , see http://www.debian.org/News/2005/20050920 )

More info and details are in 
  http://tonelli.sns.it/pub/mennucc1/debdelta/README

The 'debdelta' package is in
 http://tonelli.sns.it/pub/mennucc1/debdelta/etch
or
 http://tonelli.sns.it/pub/mennucc1/debdelta/sarge

Unfortunately my repository of .debdelta is currently stored in a
slow-bandwidth server; I would need some space (~800Mb) in some Debian
server to host it (in a server where there is a copy of the archive). Any
suggestions? The best would be if ftp-masters may help me set it up
in ftp.debian.org .

a.

-- 
Andrea Mennucc



signature.asc
Description: Digital signature

Re: proposal for a more efficient download process

2006-06-01 Thread A Mennucc


hi

by quite a coincidence, while you people were discussing this idea, I was 
already implementing it, in a package called 'debdelta' : see
 http://lists.debian.org/debian-devel/2006/05/msg03120.html

Moreover, by some telepathy :-) , I already included features you were
proposing, and addressed problems you where discussing
(and other problems you were not discussing since you did not
try implementing it  :-) 

Here are the replies:

To curt manucredo : while the implementation is not exactly what you
were suggesting in your original email, it still achieves all desired
goals; moreover, it is alive an kicking.

'debdelta' differs from your implementation in this respect:
- it does not use dpkg-repack (for many good reasons, see below)
- it recreates the new .deb , and guarantees that it is equal to the 
  one in archives, so archive signatures can be verified;
  currently it does not patch into the filesystem 
  (altough  this would be an easy adaptation, if anybody wishes for it)

'debdelta' conforms to your requests, in that 
- it can recreate the new .deb, either using the installed version of
 the old .deb, or old .deb file.

On the bright side, everything is already working, there is already
a repository of patches available, and a method of downloading them.

To Tyler MacDonald :
 - 'debdelta' uses 'bsdiff' , or 'xdelta' as a fallback, see below
 - regarding this:
> Some work will have to go into the math to determine when it's
> actually more efficient to download the latest archive, etc just a
> fleeting mental note, the threshold should not be 100% of the full archives
> size, it should be 90 or 80% due to the CPU/RAM overhead of patching and the
> bandwidth/latency overhead of requesting multiple patch files vs. one
> stream of data.
This math must go in the client side, and it is in my TODO list
(see at the end of the README); it is a nice exercise in Dynamical Programming.

Anyway , currently the archive discards deltas that exceed ~50% of the
new .deb , just as an heuristic, and to keep disk usage low.

To Goswin von Brederlow :
>| bsdiff is quite memory-hungry. It requires max(17*n,9*n+m)+O(1)

Ah so this is the correct formula! The man page just says '17*n'.

But  in my stats, that that is not the case; my stats
are estimating that the memory is '12*n' so that is what I use

>| bytes of memory, where n is the size of the old file and m is the
>| size of the new file. bspatch requires n+m+O(1) bytes.
> That is quite unacceptable. We have debs in debian up to 160Mb

'debdelta' has an option '-M ' to choose between 'xdelta' and 'bsdiff' ;
by default, it uses 'xdelta' when memory usage would exceed 50Mb ;
but in the server, I set '-M 200' since I have 1GB RAM there.
 
> Seems to be quite useless for patching full debs. One would have to
> limit it to a file-by-file approach.

This is in my TODO list. Actually, I have in mind a scheme to
break TARs at suitable points, I have to check if it is 
worthwhile ; I can discuss details.

To: Tyler MacDonald again:
>   True.. It'd probably only be efficient if the deltas were based on
> the contents of the .deb's before they're packed.

.. and this is the reason why I do not use dpkg-repack... why unpacking
data when I need them unpacked ?   :-)

Absolutely true. Look at this

$ ls -s tetex-doc_3.0-17_all.deb tetex-doc_3.0-18_all.deb
 42388 tetex-doc_3.0-18_all.deb 42340 tetex-doc_3.0-17_all.deb

$ bsdiff tetex-doc_3.0-17_all.deb tetex-doc_3.0-18_all.deb brutal.bsdiff
$ ls -s brutal.bsdiff
 10092 brutal.bsdiff

Hat tip to 'bsdiff', but we can do better...

$ ar p tetex-doc_3.0-17_all.deb data.tar.gz | zcat >  /tmp/17.tar
$ ar p tetex-doc_3.0-18_all.deb data.tar.gz | zcat >  /tmp/18.tar
$ ls -s /tmp/17.tar /tmp/18.tar

53532 /tmp/17.tar  53580 /tmp/18.tar

$ time bsdiff /tmp/17.tar /tmp/18.tar /tmp/tar.bsdiff

times: 
 real2m4.994s user2m3.947s
memory:
  PID USER  PR  NI  VIRT  RES  SHR S %CPU %MEMTIME+  COMMAND
 9784 debdev25   0  471m 470m 1384 T  0.0 46.5   1:18.82 bsdiff
size:
  92 /tmp/tar.bsdiff 

so as you see, the reduction in size is impressive, 
but it uses too much memory  and takes too much time.

$ time xdelta delta -m 50M -9  /tmp/17.tar /tmp/18.tar /tmp/tar.xdelta
times:
 real0m1.728s user0m1.660s
memory...  it is too fast
size:
  236 /tmp/tar.xdelta

still good enough for our goal



Comparing to the above

$ ls -s pool/main/t/tetex-base/tetex-doc_3.0-17_3.0-18_all.debdelta

288 pool/main/t/tetex-base/tetex-doc_3.0-17_3.0-18_all.debdelta

(the extra 35kB are the script that 'debpatch' uses  :-( 
 actually, I told 'debdelta' to use 'bzip' instead of gzip
 in this cases, but it did not... just found another bug :-)  )

To:  Marc 'HE' Brockschmidt <[EMAIL PROTECTED]>:
> Now the interesting questions: How many diffs do you keep?

very few, currently, due to space constraints; moreover , suppose that

 you have a_1.deb installed, a_1_2.debdelta and  a_2_3.debdelta are in
 pool of deltas, wan

Re: debdelta

2006-06-09 Thread A Mennucc


Nikita V. Youshchenko wrote:

The command 'debdelta-upgrade' is meant to be run between 'apt-get
 update' and 'apt-get upgrade'; it downloads .debdelta files and
 recreate the new .deb files from them; always using the *installed* old
 version of the .deb, and not the old .deb file itself.


Is it safe - e.g. in case of localy-modified config files?



yes

a.


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

snmpkit stuck in unstable ?

2005-09-08 Thread A Mennucc

hi people 

(maybe I do not properly understand how the transition unstable -> testing 
goes , but...)

my packages from source  libprinterconf, see
http://bjorn.haxx.se/debian/testing.pl?package=libprinterconf
are waiting for snmpkit to go into testing;

at the same time, 
my packages from source snmpkit  seem ready, are  quite old, see
http://bjorn.haxx.se/debian/testing.pl?package=snmpkit
but still they are not going into testing.

what is happening?

a.

ps: please CC me

-- 
Andrea Mennucc
 "Ukn ow,Ifina llyfixe dmysp acebar.ohwh atthef"


signature.asc
Description: Digital signature

email error message from d.o may be better

2005-09-08 Thread A Mennucc

hi

I sent an email to [EMAIL PROTECTED] instead of 
debian-68k@lists.debian.org ; the error message that I got
was strange (in particular, the two lines 
  procmail: Error while writing to "DeadLog"
  procmail: Error while writing to "/var/mail/debian"
look as if there is a misconfiguration somewhere );
moreover, it would be better if the error was akin to
"no such user".

Hope someone may find some time to look into it
(altoh I ack that it is a minor minor problem)

(btw, I do not know if this list is the best place to report
this - any suggestions on where I should report this?)

a.

- Forwarded message from Mail Delivery System <[EMAIL PROTECTED]> -

From: Mail Delivery System <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: Mail delivery failed: returning message to sender

This message was created automatically by mail delivery software (Exim).

A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:

  pipe to |/usr/bin/procmail -p .procmail/rc.split
generated by [EMAIL PROTECTED]
Child process of address_pipe transport returned 73 (could mean can't 
create output file) from command:
/usr/bin/procmail

The following text was generated during the delivery attempt:

-- pipe to |/usr/bin/procmail -p .procmail/rc.split
   generated by [EMAIL PROTECTED] --

procmail: Error while writing to "DeadLog"
procmail: Error while writing to "/var/mail/debian"

-- This is a copy of the message, including all the headers. --

Received: from cibs10.sns.it (reed.sns.it) [192.167.206.30] 
by master.debian.org with esmtp (Exim 3.35 1 (Debian))
id 1E6pjV-00024M-00; Sun, 21 Aug 2005 08:19:29 -0500
Received: from [192.167.206.31] (helo=sns.it)
by reed.sns.it with esmtp (Exim 3.35 #1 (Debian))
id 1E6pkn-0006wk-00
for <[EMAIL PROTECTED]>; Sun, 21 Aug 2005 15:20:49 +0200
X-Virus-Scanned: by cgpav
Received: from [192.84.155.215] (HELO tonelli)
  by sns.it (CommuniGate Pro SMTP 4.1.8)
  with ESMTP id 36570565 for [EMAIL PROTECTED]; Sun, 21 Aug 2005 15:21:04 +0200
Received: by tonelli (Postfix, from userid 1013)
id 1EA0D176C1; Sun, 21 Aug 2005 15:19:28 +0200 (CEST)
Date: Sun, 21 Aug 2005 15:19:28 +0200
To: [EMAIL PROTECTED]
Subject:  zope2.7 failed to build
Message-ID: <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.9i
[omitted]

- End forwarded message -

-- 
Andrea Mennucc
 "Ukn ow,Ifina llyfixe dmysp acebar.ohwh atthef"


signature.asc
Description: Digital signature

Re: snmpkit stuck in unstable ?

2005-09-08 Thread A Mennucc


Andreas Barth wrote:


* A Mennucc ([EMAIL PROTECTED]) [050908 13:39]:
 

(maybe I do not properly understand how the transition unstable -> testing 
goes , but...)


my packages from source  libprinterconf, see
http://bjorn.haxx.se/debian/testing.pl?package=libprinterconf
are waiting for snmpkit to go into testing;

at the same time, 
my packages from source snmpkit  seem ready, are  quite old, see

http://bjorn.haxx.se/debian/testing.pl?package=snmpkit
but still they are not going into testing.

what is happening?
   



I'd say your package is part of the c++-abi-transition.

 

sorry... since the dependency on c++ libraries is not listed in the 
above excuses, I forgot about it


a.


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: snmpkit stuck in unstable ?

2005-09-09 Thread A Mennucc

On Thu, Sep 08, 2005 at 09:12:15AM -0400, Nathanael Nerode wrote:
> Looks like its entire chain is ready, so now you need a "hint".  Ask 
> debian-release to do this:

the page on excuses was speaking of an "hint"...
what is it ?
choice 1) a plain english email to [EMAIL PROTECTED]
choice 2) a procedure involving gpg signing and email to an obscure address
 using a set of keywords nobody ever documented properly

1 was my hope, 2 was my Debian-experience-induced-fear

a.

-- 
Andrea Mennucc
 "Ukn ow,Ifina llyfixe dmysp acebar.ohwh atthef"

signature.asc
Description: Digital signature

zope2.7 security fix (for bug 334055)

2005-10-21 Thread A Mennucc

hi everybody

I have (hopefully) fixed the bug 334055 of zope2.7, that is a security alert.

Note that my patch is much smaller than the original hotfix,
which included also some new features such as nl and ca languages -
- but usually we do not add new features in Debian when releasing security
upgrades.

- testing

This is the updated binary for testing/etch
http://tonelli.sns.it/pub/mennucc1/zope/debian/etch-security/zope2.7_2.7.5-3sec1.deb

I will not upload it to secure-testing-master since it violates point 1 at
http://secure-testing-master.debian.net/
"Only upload changes that have already been made in unstable."
People in the pkg-zope-team are introducing in unstable a completely
different zope framework.

- sarge

This is the proposed update for stable/sarge :
http://tonelli.sns.it/pub/mennucc1/zope/debian/sarge-security/zope2.7_2.7.5-2sec1_source.changes
unfortunately I do not have available a clean sarge environment, so
you have to compile it.

This is the diff w.r.t the older version
http://tonelli.sns.it/pub/mennucc1/zope/debian/sarge-security/zope-hotfix_2005-10-09-sarge.diff

Warning: do not apply that patch to the installed files of zope2.7,
it will not work. Compile the above source, or help me use a sarge buildd.

ps: I wrote to the security team asking info on the sarge upload, never
got an answer. Question: can I upload a source-only to sarge-security?

ps2: I would also appreciate if someone who understands what 334055 is about
would compile and test my fix to see if it really works.

--
Andrea Mennucc
"E' un mondo difficile. Che vita intensa!" (Tonino Carotone)

signature.asc
Description: Digital signature

Re: Segmentation fault on xmms startup (NVIDIA graphic driver involved)

2005-10-27 Thread A Mennucc

hi

try this:
deinstall all xmms plugins that use GL graphics;

indeed the crash is in the "add_plugin ()" call


Paolo Pantaleo wrote:

>Well i discovered that it is not an xmms issue, but some problems with
>NVIDIA non free graphic drivers, probalby it is a configuration
>problem (specific of my own installation).
>  
>

btw: NVIDIA drivers works very well on my system:
I can play all GL games that are in Debian, and DVDs, on a 450MHz
Pentium system
(and never experience crashes)

a.

>
>
>  
>


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

xkcd

2008-05-17 Thread A Mennucc

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

we had to have this

http://xkcd.com/424/

a.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFILybU9B/tjjP8QKQRAr5xAJ4gI/2k/LQqlsVKWXtCW0Nsli0RPgCfTSMH
fCHEC7M6erNUsmN0d+zUADQ=
=pIM0
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#538728: ITP: dvbstreamer -- DVBStreamer is an console based application to stream DVB/ATSC service(s)

2009-07-26 Thread A Mennucc

Package: wnpp
Severity: wishlist
Owner: A Mennucc 


* Package name: dvbstreamer
  Version : 2~svn
  Upstream Author : Adam Charrett  et al
* URL : https://sourceforge.net/projects/dvbstreamer/
* License : GPL 2
  Programming Lang: C, Python
  Description : DVBStreamer is an console based application to stream 
DVB/ATSC service(s)

DVBStreamer is an console based application to stream DVB/ATSC 
service(s) over UDP or to a file. It is more that just an app to stream 
AV though and feature a simple plugin architecture to allow more 
features to be added.

-- System Information:
Debian Release: 5.0.2
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)



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

Re: xdelta, "grave" bug 147187, time left

2007-01-19 Thread A Mennucc

On Thu, Jan 18, 2007 at 09:03:16PM -0700, LaMont Jones wrote:
> I hadn't seen the mail that added the patch to the bug report - I'll
> work on xdelta this weekend.

that patch should fix interoperability between 64 and 32 bit

I dont know if it addresses security implications...

> thanks

thank you

if interoperability would be achived , that would really help
my debdelta project

a.

-- 
Andrea Mennucc

"The EULA sounds like it was written by a team of lawyers who want to tell 
me what I can't do, and the GPL sounds like it was written by a human 
being who wants me to know what I can do."
Anonymous,http://www.securityfocus.com/columnists/420


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

daylight saving time and RTC clock

2007-03-25 Thread A Mennucc

hi everybody

today is the first day of daylight saving time in Italy, (and many other
 European countries); but something did not work as expected in my Etch box


--- brief summary of what I saw happening:

this morning, when I booted my PC, I looked at the date
# date
dom mar 25 08:34:22 CEST 2007
that is, it was 1 hour behind ; so I issued
# ntpdate-debian
25 Mar 09:34:32 ntpdate[3996]: step time server 193.204.114.105 offset
3599.702392 sec
and this moved my clock 1 hour ahead, and then the date was correct:
# date
dom mar 25 09:34:35 CEST 2007

-

 my RTC clock is not set to UTC , and maybe this is the cause for what I
saw happening above.

Is there any way so that people not keeping their RTC to UTC may still
have a correct time on daylight-saving switching days?

What package may I send a bug report (wishlist) to?

a.



signature.asc
Description: OpenPGP digital signature

Re: daylight saving time and RTC clock

2007-03-26 Thread A Mennucc

hi & thanks anyone

yes, in the past I had to accomodate for dual booting into that peculiar
other operating system (hereby called Windows, as by Santiago
suggestion) : I developed gtkmorph in the past, and it had to run on
both O.S.es ; but nowadays I dont, so I think I will switch my RTC to
UTC, and be done with it.

The reason why I did send the first post is that I thought there may be
 a way to do daylight switching even when RTC!=UTC ... but thinking
about it more, I decided it is almost impossible: when dual booting, the
RTC is affected by both O.S.es, so it all would depend on which one of
the O.S.es is booted first on daylight-switching-day : the only way is,
possibly , that Debian should  peek into the innards of the Windows
registry, to see if daylight-switching was already done, or not, on the
RTC... this seems too complex to be feasible (I for once could not do it)

a.



signature.asc
Description: OpenPGP digital signature

checklib

2007-05-24 Thread A Mennucc

hi

what about http://rerun.lefant.net/checklib/ ?

madcoder mentioned in
http://lists.debian.org/debian-devel/2007/01/msg00822.html
of the intention of getting the checklib service up again: any progress?

also, where do I get the source code from (since the link
http://greek0.net/div/checklib.tar.gz seems broken)?

maybe the source code may be uploaded in  the alioth project

thanks

a.



signature.asc
Description: OpenPGP digital signature

Re: compiling packages

Oliver Block ha scritto:
> Hello list,
> 
> I am not very familiar with the debian developer tools. How to recompile a 
> package with debuggin option (gcc -g)?

usually packages are compiled with -g, but are stripped afterwards; to
avoid that, see example:

as root
# apt-get build-dep  mplayer
# apt-get install devscripts

as user
$ apt-get source mplayer
$ cd mplayer-1.0~rc1
$ DEB_BUILD_OPTIONS=nostrip debuild binary

when a package uses debhelper, the dh_strip command will respect your
request; but not all packages so; so in some cases you may need to edit
debian/rules to change the build rules

a.



signature.asc
Description: OpenPGP digital signature

removing 'printtool' from archives

hi

I am the mantainer of 'printtool'

brief history:
 printtool was the GUI tool that Red Hat had developed for easy printer
configurations ; it was then ~2000 adopted by the GNULpr project at
http://lpr.sourceforge.net/ ; but, after the doc-com crisis, the project
was eventually abandoned.

Currently I mantain some code that came out of  lpr.sf.net , and keep it
alive: in particular, I use and appreciate 'gpr' , and I have developed
the code (lately I added support for CUPS).

But I think that 'printtool' has outlived its usefullness: its database
of printers (that is actually contained in the package
'printfilters-ppd', for some strange reason) is outdated; and Debian
ships many tools to configure printing (foomatic-gui ,
gnome-cups-manager , just to name two) , that work well and have
up-to-date printer databases.

If nobody is interested in 'printtool', I will ask for its removal from
archive.

a.



signature.asc
Description: OpenPGP digital signature

removing 'printtool' from archives

hi

I am the mantainer of 'printtool'

brief history:
 printtool was the GUI tool that Red Hat had developed for easy printer
configurations ; it was then ~2000 adopted by the GNULpr project at
http://lpr.sourceforge.net/ ; but, after the doc-com crisis, the project
was eventually abandoned.

Currently I mantain some code that came out of  lpr.sf.net , and keep it
alive: in particular, I use and appreciate 'gpr' , and I have developed
the code (lately I added support for CUPS).

But I think that 'printtool' has outlived its usefullness: its database
of printers (that is actually contained in the package
'printfilters-ppd', for some strange reason) is outdated; and Debian
ships many tools to configure printing (foomatic-gui ,
gnome-cups-manager , just to name two) , that work well and have
up-to-date printer databases.

If nobody is interested in 'printtool', I will ask for its removal from
archive.

a.



signature.asc
Description: OpenPGP digital signature

Re: checklib

Lucas Nussbaum ha scritto:
> On 24/05/07 at 21:22 +0200, Pierre Habouzit wrote:
>> On Thu, May 24, 2007 at 08:26:00PM +0200, A Mennucc wrote:

>>> maybe the source code may be uploaded in  the alioth project
>>   that would be good yes.
> 
> Feel free to use the collab-qa alioth project for that, if you want.

there is a 'checklib' project in alioth

a.



signature.asc
Description: OpenPGP digital signature

debdelta service back on track

2007-07-17 Thread A Mennucc

hi all,

about two weeks ago  'debdelta-upgrade' started failing. Unfortunately I
was away with (almost) no Internet access. Today I could finally fix the
problem.

The problem was due to a subtle change in zlib1g: in newer versions, the
compressed output has 0x02 instead of 0x00 at the 10th byte (that is in
the header). This change occurred somewhere between version 1.2.3-13 and
1.2.3.3.dfsg-5 .
(I am sending a CC to the upstream authors and to the Debian Mantainer,
in case they are not aware of this change).
 Since dpkg-deb uses zlib1g, this changed the .deb files. So a file
reconstructed by "debpatch" would be different with the original in 2
bytes.

I have added a workaround for that problem in 'debdelta' version 0.21 ,
and I have installed it in the server that prepares deltas for
'debdelta-upgrade' . Now it should work again as expected. (If it does
not, mail me, or send a bug in the BTS).

Note that endusers that only use 'debpatch' and 'debdelta-upgrade' do
not need to upgrade: the workaround is in the delta-ing code.

a.

 --- Info

debdelta is a program suite designed to compute changes between Debian
packages.
It contains various utilities, including 'debdelta-upgrade' that can be
used by people with slow access to Internet to speed up their "apt-get
upgrade". The debian package is
http://packages.debian.org/unstable/devel/debdelta
More info are available at
http://tonelli.sns.it/pub/mennucc1/debdelta/README



signature.asc
Description: OpenPGP digital signature

Bug#433774: ITP: xdelta3 -- Xdelta3 is a set of tools and APIs for reading and writing binary deltas

2007-07-19 Thread A Mennucc

Package: wnpp
Severity: wishlist
Owner: A Mennucc <[EMAIL PROTECTED]>


* Package name: xdelta3
  Version : 30q
  Upstream Author : Josh MacDonald
* URL : http://xdelta.org/
* License : GPL v2
  Programming Lang: C, Python
  Description : programs and libraries to "diff" binary files

 Xdelta3 is a set of tools designed to compute changes between
 binary files.  These changes (delta files) are similar to the output of the
 "diff" program, in that they may be used to store and transmit only the
 changes between files.  The "delta files" that Xdelta3 manages are
 stored in RFC3284 (VCDIFF) format.

a.

-- 
Andrea Mennucc

"The EULA sounds like it was written by a team of lawyers who want to tell 
me what I can't do, and the GPL sounds like it was written by a human 
being who wants me to know what I can do."
Anonymous,http://www.securityfocus.com/columnists/420


signature.asc
Description: Digital signature

Re: debdelta service back on track

2007-07-20 Thread A Mennucc

hi

Mark Brown ha scritto:
> On Tue, Jul 17, 2007 at 11:23:53AM +0200, A Mennucc wrote:
> 
>> The problem was due to a subtle change in zlib1g: in newer versions, the
>> compressed output has 0x02 instead of 0x00 at the 10th byte (that is in
>> the header). This change occurred somewhere between version 1.2.3-13 and
>> 1.2.3.3.dfsg-5 .
> 
> Byte 10 is the XFL field which contains compression method specific
> flags.  For deflate a value of two indicates that the compressor was
> aiming for maximum compression and a value of zero indicates nothing in
> particular.  The code was previously not bothering to provide any
> information about how hard it was trying to compress things.

thanks for the explanation (I was too lazy to go look into it myself :-)

>>  Since dpkg-deb uses zlib1g, this changed the .deb files. So a file
>> reconstructed by "debpatch" would be different with the original in 2
>> bytes.
> 
> Two bytes?

a .deb file is an "ar" archive containing both a control.tar.gz and a
data.tar.gz

BTW: let me remind that one goal of debdelta is to obtain "perfect
reconstruction". The change in zlib1g did break "perfect
reconstruction"; but the reconstructed .deb files were OK in all other
respects.

>> I have added a workaround for that problem in 'debdelta' version 0.21 ,
>> and I have installed it in the server that prepares deltas for
>> 'debdelta-upgrade' . Now it should work again as expected. (If it does
>> not, mail me, or send a bug in the BTS).
> 
> I'm not sure exactly what debdelta is doing here but it sounds like
> it ought to have specific code for handing the reconstruction of this
> header in order to be robust against reasonable upstream changes.

that is what I did. Currently  a delta file also saves the header file
and then puts it back forcibly.

> There
> are several fields in there which are informational and could be varied
> by the compressor pretty much at will.

debdelta relies on the fact that dpkg-deb uses zlib1g to compress
control.tar.gz and a data.tar.gz ; so debdelta calls "minigzip", that
obtains the same exact result - unless zlib1g changes, of course.

"debdelta" currently is not robust w.r.t. strong changes in zlib1g ...
the only way to achieve robustness would be that I should ship a copy of
the source code of zlib1g inside the debdelta package (but that is
inconvenient in other respects).

a.

signature.asc
Description: OpenPGP digital signature

debdelta, Re: proposed release goal: DEBIAN/md5sums for all packages

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

hi

just for the record :  "debdelta" uses md5sums (when available) as a way
to speed up delta creation, to rapidly detect if there are any identical
files in the archives. So , yes, I (*) would be happy if md5sums where
always available.


BTW, I also encountered a strange "bug" : sometimes the md5sums file
contains MD5 of files that are not shipped. This is printed as a warning
in my server. If MD5 will become a release goal, this should be
corrected as well : in case, I will send bug reports.

a.

* that is, my server that generates the patches for 'debdelta-upgrade'
would be faster, and that would make me happier
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFG0plu9B/tjjP8QKQRAm+iAKCLbo9dUeQtA3fR9FV9rIcLp8mCkgCfcWoj
g1Rw/3sW8rPgaI3/laq/yn0=
=jcX9
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: proposed release goal: DEBIAN/md5sums for all packages

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Marc 'HE' Brockschmidt ha scritto:
> Yes, that sounds like a good idea. It might also be interesting to not
> put those into the control.tar.gz, but directly into the deb, so that it
> can easily be extracted.

I do not agree, for two reasons:

1) it is quite easy, by piping 'ar' and 'tar' , to extract files such
md5sums from control.tar.gz

2) if md5sums is inside control.tar.gz, then it is compressed better,
since the list of files is also inside control.tar.gz, and gzip is quite
good at compressing repeated stuff

a.


-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFG0p4a9B/tjjP8QKQRAjv3AJ4jSAZei167CemUvLu1LZ8KDjAE/QCggHm4
nsnr8dj2Abjo9mvFFgdyElE=
=K2wf
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: proposed release goal: DEBIAN/md5sums for all packages

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Lars Wirzenius ha scritto:
> It strikes me that if we want to make it policy, having dpkg generate
> the checksums upon creating the .deb would be the simplest and best way
> to do it. This way we wouldn't have to change packages to do it, and if
> we ever want to change the format (sha1 as well as md5?) there's only
> one place to change it.

this would guarantee that the list will really reflect what is inside
the data.tar.gz

as I said in another post, my debdelta-generating-server often complains
 that packages ship a md5sum that does not correspond to what is in
data.tar.gz

a.


-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFG0p6a9B/tjjP8QKQRAhP4AJ9MfotrnlskSd+TsArbYQP0kyvffgCfe2nR
GMHUwKKTHNONe8V1j3o9g9s=
=RRx8
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: proposed release goal: DEBIAN/md5sums for all packages

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Stefano Zacchiroli ha scritto:
> In an attempt to prevent drift to a well-known counter argument:
> DEBIAN/md5sums (used by debsums) are *not* intended as a mean to counter
> security attacks, since they can be easily altered.  

If md5sums become part of the policy, then this brings me to an old idea
of mine.

Idea: we set up a database containing those md5sums , for all
packages/versions that pass thru the archive, and add a web interface to
that. This database then may be really used in forensic.

Example usage. Suppose that I find out that my PC has been hacked. I
then shut it down immediatly, and grab a live CD. I boot my PC using the
live CD, and have it connect to Internet. I then start a simple utility
(think of 'debsums --web --root'), that, for any package that is
installed in the OS in the PC, downloads the md5sum for that version
from the web interface, and goes checking; eventually leaving a list of
all files that did not check OK or that were found in /etc /usr /bin ...
and have no md5sum.

Of course this would give many false positives, (such as the aspell
hashes, as is discussed in a subthread ; and a lot of stuff in /etc);
but it would be useful to prune the majority of OK files out, and leave
a small subset for human forensic  analysis.


a.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFG0qHD9B/tjjP8QKQRAmJnAJ9oUWwME6Q8g6JrRt6bF4nk6HYIawCdG1hP
GRyBERL04/5Nz2/YmM16uts=
=M3m4
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: proposed release goal: DEBIAN/md5sums for all packages

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Peter Samuelson ha scritto:
> [Lars Wirzenius]
>> It strikes me that if we want to make it policy, having dpkg generate
>> the checksums upon creating the .deb would be the simplest and best
>> way to do it.
> 
> I'd opt for dpkg generating the checksums upon _extracting_ the .deb
> file. 

we already have debsums to do that

also, in that case, it would damage my debdelta server  :-(

a.


-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFG0qJt9B/tjjP8QKQRAmiBAJ9vC9AVUOZMJvyK1yHnG+X6IhcN6gCgn24X
rbGdgmcvfWdshScmb7UtIg4=
=44br
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: proposed release goal: DEBIAN/md5sums for all packages