16/05/2008 11:10:57 [GMT+0200]
Malware has been found in a message that included your e-mail address as the
sender of the message!
Check if your computer is infected.
Hacking tool found: Exploit/iFrame
File name: message_attachment3
Sender: debian-devel-italian@lists.debian.org
Recipients:
On Thu, May 15, 2008 at 11:30:40PM +0200, Peter Palfrader wrote:
On Thu, 15 May 2008, Norbert Preining wrote:
On Do, 15 Mai 2008, Mike Hommey wrote:
I beg to differ. This particular mail is important enough to be sent to
d-d-a instead of d-i-a.
I agree, dia is not what I would be
The following is a listing of packages for which help has been requested
through the WNPP (Work-Needing and Prospective Packages) system in the
last week.
Total number of orphaned packages: 433 (new: 6)
Total number of packages offered up for adoption: 104 (new: 6)
Total number of packages
On Thu, 15 May 2008, Steve Langasek wrote:
2) Introduce a default-mta package (currently) depending on exim4. All
packages requiring a MTA should depend on default-mta |
mail-transport-agent.
This will have the extra advantage that we (and others like CDDs and
derived
distros)
On Do, 15 Mai 2008, Peter Palfrader wrote:
I beg to differ. This particular mail is important enough to be sent to
d-d-a instead of d-i-a.
I agree, dia is not what I would be subscribed to under normal
circumstances, and with all the caos that type of announce is for dda.
Which is
On Thu, May 15, 2008 at 03:19:55PM +1200, Martin Langhoff wrote:
I am looking at hosts that are runing other linuxen that may have weak
keys now, or see those weak keys uploaded inadvertently in the future.
Is there a straightforward way to get hosts that are !(Debian|Ubuntu)
to use that
Eugeniy Meshcheryakov, 2008-05-16 02:10:39 +0200 :
This can happen if user has 'default-mta' package installed, and it
changes (if it is done like with 'gcc' package now).
Unless default-mta Depends: exim4 | mail-transport-agent. But that's
a bit ugly.
Roland.
--
Roland Mas
Fate always
On Thu, May 15, 2008 at 04:45:19PM -0700, Steve Langasek wrote:
2) Introduce a default-mta package (currently) depending on exim4. All
packages requiring a MTA should depend on default-mta |
mail-transport-agent.
This will have the extra advantage that we (and others like CDDs and
Steve Langasek [EMAIL PROTECTED] writes:
On Thu, May 15, 2008 at 11:33:04PM +0200, Sune Vuorela wrote:
Noticing among others this bug report
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=322751 and observing the
many packages depending on $MTA | mail-transport-agent with $MTA having
Peter Palfrader skrev:
On Thu, 15 May 2008, Norbert Preining wrote:
On Do, 15 Mai 2008, Mike Hommey wrote:
I beg to differ. This particular mail is important enough to be sent to
d-d-a instead of d-i-a.
I agree, dia is not what I would be subscribed to under normal
circumstances, and with
On Thu, May 15, 2008 at 07:53:21AM -0700, Russ Allbery wrote:
Guido Günther [EMAIL PROTECTED] writes:
On Thu, May 15, 2008 at 03:33:41PM +1000, Brian May wrote:
Apparently, Heimdal in Debian also is affected. I am not aware of any
solution other then to manually regenerate all keys.
Package: wnpp
Severity: wishlist
Owner: Vincent Danjean [EMAIL PROTECTED]
* Package name: libbiblio-endnotestyle-perl
Version : 0.05
Upstream Author : Mike Taylor [EMAIL PROTECTED]
* URL : http://search.cpan.org/dist/Biblio-EndnoteStyle/
* License : perl
On Fri, May 16, 2008 at 08:41:25AM +0200, Norbert Preining wrote:
On Do, 15 Mai 2008, Peter Palfrader wrote:
I beg to differ. This particular mail is important enough to be sent to
d-d-a instead of d-i-a.
I agree, dia is not what I would be subscribed to under normal
Package: wnpp
Severity: wishlist
Owner: Debian Octave Group [EMAIL PROTECTED]
* Package name: octave-tsa
Version : 3.10.6
Upstream Author : Alois Schlögl
* URL : http://octave.sourceforge.net/tsa/index.html
* License : GPL2+
Programming Lang: Octave
Kevin B. McCarty [EMAIL PROTECTED] wrote:
If you see packages for which a Debian-specific patch seems unnecessary,
please by all means file a bug (severity wishlist) requesting that the
patch be either reverted or submitted upstream.
Most time the patch is already submitted upstream, but
Hello Raphael,
Unfortunately I had some personal problems that I was not best to keep
this package.
I agree with you, if I can not keep then not caught. I am putting the
package up for adoption.
In respect of other packages I will be updating them.
Regards,
Jose Carlos
2008/5/15 Raphael Hertzog
Hi,
Le 16 mai 08 à 13:48, Martin Uecker a écrit :
Kevin B. McCarty [EMAIL PROTECTED] wrote:
If you see packages for which a Debian-specific patch seems
unnecessary,
please by all means file a bug (severity wishlist) requesting that
the
patch be either reverted or submitted upstream.
On Fri, May 16, 2008 at 08:55:34AM -0300, Jose Carlos Medeiros wrote:
I agree with you, if I can not keep then not caught. I am putting the
package up for adoption.
I'd be interested in this package as I have some issues with acpi
anyway. I won't be able to look into this before next week
Le vendredi 16 mai 2008 à 14:48 +0200, Thibaut Paumard a écrit :
Let's hope this discussion will, in the end, bring good ideas and
trigger actual work to improve Debian, and perhaps the free software
community at large.
Best regards, Thibaut.
That'd be great.
But please, may I
On Thu, May 15, 2008 at 06:28:36PM -0400, Filipus Klutiero wrote:
I don't see your point.
I can have libfoo1 and libfoo2 installed and used at the same time so
both applications compiled for libfoo1 and libfoo2 can be used at the
same time. I can recompile my applications for libfoo2 as I get
Package: wnpp
Severity: wishlist
Owner: Bernd Schubert [EMAIL PROTECTED]
* Package name: unionfs-fuse
Version : 0.9.19~hg
Upstream Author : Radek Podgorny [EMAIL PROTECTED], Bernd Schubert [EMAIL
PROTECTED]
* URL : http://podgorny.cz/moin/UnionFsFuse
* License
I've started http://wiki.debian.org/NewInLenny and would like to
invite y'all to populate the page with stuff that's changed between
etch and lenny. For now, I suppose just dumping anything to the end
of the list is good, we'll categorise later — but that's not to stop
anyone who wants to
2008/5/16 Thibaut Paumard [EMAIL PROTECTED]:
the topic has already been changed to ssl security desaster, and in my
opinion this is precisely what my post is about: what can we learn from this
disaster. (More precisely, I'm giving my 2c on what level of patching is
acceptable in a Debian
Miriam Ruiz [EMAIL PROTECTED] writes:
Maybe there should also be a clasification of packages according to
how bad would a bug be in them for the whole system, so that patches
in those could be more carefully reviewed.
Perhaps uploads could come with the diff against the last version (or
a link
Le 16 mai 08 à 15:41, Miriam Ruiz a écrit :
2008/5/16 Thibaut Paumard [EMAIL PROTECTED]:
[...] Maybe there should also be a
clasification of packages according to how bad would a bug be in them
for the whole system, so that patches in those could be more carefully
reviewed.
Actually, I seem
On 16/05/08 at 15:41 +0200, Miriam Ruiz wrote:
2008/5/16 Thibaut Paumard [EMAIL PROTECTED]:
the topic has already been changed to ssl security desaster, and in my
opinion this is precisely what my post is about: what can we learn from this
disaster. (More precisely, I'm giving my 2c on
[Breaking the thread on purpose to start a new one]
On Fri, 16 May 2008, Lucas Nussbaum wrote:
On 16/05/08 at 15:41 +0200, Miriam Ruiz wrote:
just reviewed by just one person, but then again, I seriously think
that it would have been quite difficult to discover that there was a
problem
On Thu, 15 May 2008, Steinar H. Gunderson wrote:
On Wed, May 14, 2008 at 06:22:37PM -0500, Steve Greenland wrote:
Therefore, anyone who had a DSA key has had it compromised...
Shouldn't that be anyone who had a DSA key *created by the flawed
version of openssl* has had it compromised...?
[EMAIL PROTECTED] wrote:
I disagree. The cause of the disaster was not that Debian does its own
patching, but the fact that that patch was buggy.
Buggy patches happen all the time. The question is, how could
something as bad as this slip through? And one important
reason is IMHO, that
On Fri, May 16, 2008 at 11:26 AM, nicolas vigier [EMAIL PROTECTED] wrote:
On Thu, 15 May 2008, Steinar H. Gunderson wrote:
No. Any key who had a single DSA signature created by the flawed version of
OpenSSL should be considered compromised. DSA requires a secret, random
number as part of the
Please Cc [EMAIL PROTECTED] on this thread!
Including the full response for the list.
also sprach Raphael Hertzog [EMAIL PROTECTED] [2008.05.16.1654 +0100]:
[Breaking the thread on purpose to start a new one]
On Fri, 16 May 2008, Lucas Nussbaum wrote:
On 16/05/08 at 15:41 +0200, Miriam
On Fri, May 16, 2008 at 05:26:09PM +0200, nicolas vigier wrote:
If I understand correctly, it means that if you use a good key with a
flawed openssl to connect to an other host using that key, then that
key can be considered compromised.
If I have a DSA key, and the client (my machine) has a
Martin Uecker wrote:
[EMAIL PROTECTED] wrote:
I disagree. The cause of the disaster was not that Debian does its own
patching, but the fact that that patch was buggy.
Buggy patches happen all the time. The question is, how could
something as bad as this slip through? And one
Hi Martin,
Martin Uecker wrote:
Kevin B. McCarty [EMAIL PROTECTED] wrote:
If you see packages for which a Debian-specific patch seems unnecessary,
please by all means file a bug (severity wishlist) requesting that the
patch be either reverted or submitted upstream.
Most time the patch
2008/5/16 martin f krafft [EMAIL PROTECTED]:
Please Cc [EMAIL PROTECTED] on this thread!
Done.
also sprach Raphael Hertzog [EMAIL PROTECTED] [2008.05.16.1654 +0100]:
Add to this that each patch should have some standardized header on top
stating:
- a description of the patch and its
martin f krafft [EMAIL PROTECTED] wrote:
[2] And IMO we should go further than patches.d.o, we need to create a
cross-distro infrastructure where we can share patches. We really have to
show the way here... (we complained enough that ubuntu patches were
unusable, surely we can show how to do
Barry deFreese wrote:
[...]
Buggy patches happen all the time. The question is, how could
something as bad as this slip through? And one important
reason is IMHO, that splitting up the development/bug fixing/review
by creating different software branches is bad.
Different software
Hi
On Fri, 16 May 2008 19:28:52 +0200
Martin Uecker [EMAIL PROTECTED] wrote:
Upstream answered that it is okay too remove the seeding of the PRNG
with uninitialized memory, but the concrete patch which additionally and
erranously removed all seeding was never posted on openssl-dev.
Are you
On Fri, May 16, 2008 at 06:54:18PM +0200, Martin Uecker wrote:
I am not convinced that more technological infrastructure is really
the solution. Isn't simply the upstream source the right place for
collaboration?
NACK, or better: ACK in theory, but not in practice. Sometime you have
wonderful
martin f krafft [EMAIL PROTECTED] writes:
Please Cc [EMAIL PROTECTED] on this thread!
Including the full response for the list.
also sprach Raphael Hertzog [EMAIL PROTECTED] [2008.05.16.1654 +0100]:
Add to this that each patch should have some standardized header on top
stating:
- a
On 19:51 Fri 16 May , Stefano Zacchiroli wrote:
On the contrary, as the Debian counterpart I cannot point them to a
single unified place where my patches are available. Or better, I can
but just because all OCaml packages are stored in a single svn
repository, with a clear defined policy
Hi Kevin!
Kevin B. McCarty [EMAIL PROTECTED] wrote:
Martin Uecker wrote:
[...]
Well, *assuming* the patch is good, a subset of users of the software
(i.e. Debian users and users of downstream distributions) benefit from
it between the time it's applied in Debian and the time it's applied
also sprach Donnie Berkholz [EMAIL PROTECTED] [2008.05.16.1853 +0100]:
http://patches.ubuntu.com/by-release/extracted/ contains patches
for both Debian and Ubuntu. It's quite useful.
Lucas Nussbaum threw the idea of having a webpage with posisbly
annotated patches for each Debian package on
Hi Michal!
Martin Uecker [EMAIL PROTECTED] wrote:
Upstream answered that it is okay too remove the seeding of the PRNG
with uninitialized memory, but the concrete patch which additionally and
erranously removed all seeding was never posted on openssl-dev.
Are you sure?
Martin Uecker [EMAIL PROTECTED] writes:
I don't now. I see no reason why all this good work which now ends up in
Debian patches can't be seperated from the actual packaging work.
It's probably worth mentioning somewhere in this discussion that one of
the most common, perhaps the most common
On Fri, May 16, 2008 at 05:54:32PM +0200, Raphael Hertzog wrote:
Add to this that each patch should have some standardized header on top
stating:
- a description of the patch and its purpose
, including pointers to relevant discussions, if any.
The idea is that anyone reviewing the patch get
Hi Martin,
I'm afraid this will be my last remark in this thread (do I hear cheers
from the crowd?) since I really should go do something more productive
now :-) Thanks for keeping the tone of discourse civil -- clearly this
is a subject you feel strongly about, and the problem that started the
Raphael Hertzog wrote:
I totally agree that we need to make our changes more visible. In the
openssl case, the patch in question is inside the .diff.gz and you don't
notice it in the unpacked source package. I tend to give a look to what's
in debian/patches/ when I rebuild a package but not to
Le vendredi 16 mai 2008 à 16:04 -0400, Joey Hess a écrit :
You're insinuatiog that a VCS does not allow easily browsing and
examining patches, and I just don't buy it.
I can do more than insinuating: a VCS does not allow easily browsing and
examining patches. It doesn’t prevent it, but solely,
Russ Allbery wrote:
Martin Uecker [EMAIL PROTECTED] writes:
In this case, the security advisory should clearly be updated. And all
advise about searching for weak keys should be removed as well, because
it leads to false sense of security. In fact, *all* keys used on Debian
machines should
Josselin Mouette wrote:
Le vendredi 16 mai 2008 à 16:04 -0400, Joey Hess a écrit :
You're insinuatiog that a VCS does not allow easily browsing and
examining patches, and I just don't buy it.
I can do more than insinuating: a VCS does not allow easily browsing and
examining patches. It
On Friday 16 May 2008, Joey Hess wrote:
Raphael Hertzog wrote:
I totally agree that we need to make our changes more visible. In the
openssl case, the patch in question is inside the .diff.gz and you don't
notice it in the unpacked source package. I tend to give a look to what's
in
On Friday 16 May 2008, Joey Hess wrote:
Josselin Mouette wrote:
Le vendredi 16 mai 2008 à 16:04 -0400, Joey Hess a écrit :
You're insinuatiog that a VCS does not allow easily browsing and
examining patches, and I just don't buy it.
I can do more than insinuating: a VCS does not allow
Josselin Mouette wrote:
Le vendredi 16 mai 2008 à 16:04 -0400, Joey Hess a écrit :
You're insinuatiog that a VCS does not allow easily browsing and
examining patches, and I just don't buy it.
I can do more than insinuating: a VCS does not allow easily browsing and
examining patches. It
Adam Majer [EMAIL PROTECTED] writes:
Clear patches are not because of VCS, but because of clear and concisely
described changesets. If you have patches with bad descriptions or a
giant blob in VCS, then that is useless not because of the failure of
VCS, but the failure of the developer.
And
Daniel Burrows wrote:
I notice that pwsafe is linked against openssl. Is it affected by the
recent debacle and if so, how? Do I need to regenerate all my
randomized passwords, or somehow re-encrypt the pwsafe database?
I've looked briefly into it: The Blowfish encryption key is constructed
On Fri, 16 May 2008, Joey Hess wrote:
Raphael Hertzog wrote:
To me this one proof more than even when VCS are used to maintain
packages, our source packages must clearly identify the Debian patches
that are applied.
You're insinuatiog that a VCS does not allow easily browsing and
Raphael Hertzog [EMAIL PROTECTED] writes:
But don't get me wrong, I'm not opposed to using VCS for package
maintainance (I do it!), I just think that we haven't found the perfect
workflow yet.
In fact, despite being one of the big quilt advocates in the last round of
this discussion, I am at
* Martin Uecker
| Another problem I have argued about before, not directly related to this
| incident, but IMHO another desaster waiting to happen: There is no
| way to independetly validate that a debian binary package was
| created from the corresponding source.
How would you go about doing
On Fri, 16 May 2008, Joey Hess wrote:
Coming up with a complex set of requirements that everyone has to follow
up front in their workflow[1] is not going to yeld the best results, and
I think that's my core reason for disliking Raphael's proposal. Now, if
you can come up with
Tollef Fog Heen [EMAIL PROTECTED] writes:
* Martin Uecker
| What bothers me too is the fact that the installer scripts of all
| packages have root permissions during installation. While this might
| be hard to do, in principle I see no good reason why installer
| scripts could not be
On Fri, 16 May 2008 22:10:36 +0200, Josselin Mouette [EMAIL PROTECTED] said:
Le vendredi 16 mai 2008 à 16:04 -0400, Joey Hess a écrit :
You're insinuatiog that a VCS does not allow easily browsing and
examining patches, and I just don't buy it.
I can do more than insinuating: a VCS does not
On Fri, 16 May 2008 14:39:56 -0700, Russ Allbery [EMAIL PROTECTED] said:
Adam Majer [EMAIL PROTECTED] writes:
Clear patches are not because of VCS, but because of clear and
concisely described changesets. If you have patches with bad
descriptions or a giant blob in VCS, then that is useless
2008/5/16 martin f krafft [EMAIL PROTECTED]:
Lucas Nussbaum threw the idea of having a webpage with posisbly
annotated patches for each Debian package on *.debian.org at me the
other day, in response to the OpenSSL debacle. I really liked it!
I think it would be a great Idea, but the point
Manoj Srivastava [EMAIL PROTECTED] writes:
Create a submission branch. There are two audiences for your
work; one is downstream (which includes the integration branch for
Debian), the other is upstream, one audience does not like rebases, the
other thrives on it. See
On Sat, 17 May 2008 00:19:59 +0300, George Danchev [EMAIL PROTECTED] said:
I personally don't think there is any need for new infrastrutures. We
only need to follow some simple rules, i.e. orig.tar.gz should be
really the original upstream source; diff.gz (debian/patches/
included) is what
On 11387 March 1977, Martin Uecker wrote:
Nevertheless, the right thing in my opinion would have been to
propose a patch, wait until it is accepted, and then to package
the new upstream version.
If you want that - build an own distribution. Or well - an LFS.
Because thats *not* what a
On Fri, 16 May 2008 23:27:03 +0300, George Danchev [EMAIL PROTECTED] said:
On Friday 16 May 2008, Joey Hess wrote:
Raphael Hertzog wrote:
I totally agree that we need to make our changes more visible. In
the openssl case, the patch in question is inside the .diff.gz and
you don't notice
Hi
Dne Fri, 16 May 2008 20:59:44 +0200
Martin Uecker [EMAIL PROTECTED] napsal(a):
I don't see a patch there. This might sound like nitpicking, but
a real patch would have provided some context to the two lines.
Yes there is no context, but it is patch and it is clear that it wants
to remove
On Fri, May 16, 2008 at 05:08:31PM -0500, Manoj Srivastava wrote:
I am not sure I can agree. I find examining a single patch deep
down in a quilt series very hard, unless I learn and use quilt, since
the patches are all linearized, and each patch is dependent on th
previous patch.
On Saturday 17 May 2008, Manoj Srivastava wrote:
On Fri, 16 May 2008 23:27:03 +0300, George Danchev [EMAIL PROTECTED] said:
On Friday 16 May 2008, Joey Hess wrote:
Raphael Hertzog wrote:
I totally agree that we need to make our changes more visible. In
the openssl case, the patch in
On Saturday 17 May 2008, Manoj Srivastava wrote:
On Sat, 17 May 2008 00:19:59 +0300, George Danchev [EMAIL PROTECTED] said:
I personally don't think there is any need for new infrastrutures. We
only need to follow some simple rules, i.e. orig.tar.gz should be
really the original upstream
Le May 16, 2008 09:10:35 am Lennart Sorensen, vous avez écrit :
On Thu, May 15, 2008 at 06:28:36PM -0400, Filipus Klutiero wrote:
I don't see your point.
I can have libfoo1 and libfoo2 installed and used at the same time so
both applications compiled for libfoo1 and libfoo2 can be used at
On Fri, 16 May 2008, Martin Uecker wrote:
Requiring distro specific changes feels wrong anyway. Software
should be coupled by standardized interfaces. But I might be naive
here. What are the distro specific changes we are talking about?
It'd be great[0] if we never had to do distribution
I went again through the mips build problems and collected the appended
list which records the current state, with a few annotations added.
Thiemo
Debian mips port, status 2007-05-16. See also:
http://buildd.debian.org/~jeroen/status/architecture.php?suite=unstablea=mipspriority=
George Danchev [EMAIL PROTECTED] writes:
A large number of packages do not follow that simple rule, but patching
the orig.tar.gz instead.
I have never seen a package that does this apart from DFSG-freeness issues
and a few beginner mistakes. The Debian changes are separated out in our
source
On Fri, May 16, 2008 at 02:55:58PM +0200, Michael Meskes wrote:
I'd be interested in this package as I have some issues with acpi
anyway. I won't be able to look into this before next week though. If
anyone else's interested I'd happily be part of a team.
Good.
I'm already working on acpid
On Sat, 17 May 2008, George Danchev wrote:
On Saturday 17 May 2008, Manoj Srivastava wrote:
This is exactly what happened in the openssl case (modulo
./debian/patches).
Not true. openssl packaging didn't and still does not use clearly
identified diff files in debian/patches/.
Uh...
On Fri, 16 May 2008 15:49:25 -0700, Russ Allbery [EMAIL PROTECTED] said:
Manoj Srivastava [EMAIL PROTECTED] writes:
Create a submission branch. There are two audiences for your work;
one is downstream (which includes the integration branch for Debian),
the other is upstream, one audience
Roland Mas [EMAIL PROTECTED] writes:
- Keys submitted through the web interface are now filtered, and only
RSA keys end up in your authorized_keys file. Don't even try
putting DSA keys in your authorized_keys2 file, the use of that file
has been disabled (and it'll be deleted anyway).
On Fri, 16 May 2008 15:25:11 -0700, Russ Allbery [EMAIL PROTECTED] said:
Raphael Hertzog [EMAIL PROTECTED] writes:
But don't get me wrong, I'm not opposed to using VCS for package
maintainance (I do it!), I just think that we haven't found the
perfect workflow yet.
In fact, despite being
On Fri, May 16, 2008 at 11:26:01AM -0700, Don Armstrong wrote:
On Fri, 16 May 2008, Martin Uecker wrote:
Requiring distro specific changes feels wrong anyway. Software
should be coupled by standardized interfaces. But I might be naive
here. What are the distro specific changes we are
Le Fri, May 16, 2008 at 09:18:56PM +0200, Agustin Martin a écrit :
On Fri, May 16, 2008 at 05:54:32PM +0200, Raphael Hertzog wrote:
Add to this that each patch should have some standardized header on top
stating:
- a description of the patch and its purpose
, including pointers to relevant
On Fri, 2008-05-16 at 15:49:25 -0700, Russ Allbery wrote:
That would work, although it does... well, not double, but at least
increase the work for any branch that also has a submission branch, since
any upstream merge conflicts have to be resolved on both branches. Or is
there some way to
Quoting Raphael Hertzog ([EMAIL PROTECTED]):
On Fri, 16 May 2008, Joey Hess wrote:
Coming up with a complex set of requirements that everyone has to follow
up front in their workflow[1] is not going to yeld the best results, and
I think that's my core reason for disliking Raphael's
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.8
Date: Thu, 15 May 2008 21:35:24 +0200
Source: bouml
Binary: bouml bouml-plugouts-src
Architecture: source all amd64
Version: 4.3.3-1
Distribution: unstable
Urgency: low
Maintainer: Thomas Girard [EMAIL PROTECTED]
Changed-By: Thomas Girard
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.8
Date: Thu, 15 May 2008 10:17:34 +0800
Source: ttf-arphic-uming
Binary: ttf-arphic-uming
Architecture: source all
Version: 0.2.20080216.1-1
Distribution: unstable
Urgency: low
Maintainer: Arne Goetje [EMAIL PROTECTED]
Changed-By: Arne
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.8
Date: Thu, 16 May 2008 08:23:03 +0200
Source: latencytop
Binary: latencytop
Architecture: source i386
Version: 0.4
Distribution: unstable
Urgency: low
Maintainer: Giacomo Catenazzi [EMAIL PROTECTED]
Changed-By: Giacomo Catenazzi [EMAIL
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.8
Date: Thu, 15 May 2008 10:25:35 +0800
Source: ttf-arphic-ukai
Binary: ttf-arphic-ukai
Architecture: source all
Version: 0.2.20080216.1-1
Distribution: unstable
Urgency: low
Maintainer: Arne Goetje [EMAIL PROTECTED]
Changed-By: Arne Goetje
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.8
Date: Fri, 16 May 2008 08:22:00 +0200
Source: ecryptfs-utils
Binary: ecryptfs-utils libecryptfs0 libecryptfs-dev
Architecture: source i386
Version: 45-1
Distribution: unstable
Urgency: low
Maintainer: Daniel Baumann [EMAIL PROTECTED]
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.8
Date: Fri, 16 May 2008 09:45:51 +0200
Source: octave-image
Binary: octave-image
Architecture: source i386
Version: 1.0.6-2
Distribution: unstable
Urgency: low
Maintainer: Debian Octave Group [EMAIL PROTECTED]
Changed-By: Thomas Weber
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.8
Date: Thu, 15 May 2008 14:56:58 +0200
Source: pygobject
Binary: python-gobject python-gobject-dev python-gobject-dbg
Architecture: source all i386
Version: 2.14.1-5
Distribution: unstable
Urgency: low
Maintainer: Josselin Mouette [EMAIL
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.8
Date: Fri, 16 May 2008 12:41:16 +0200
Source: telepathy-gabble
Binary: telepathy-gabble telepathy-gabble-dbg
Architecture: source amd64
Version: 0.7.6-1
Distribution: unstable
Urgency: low
Maintainer: Debian Telepathy maintainers [EMAIL
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.8
Date: Fri, 16 May 2008 11:50:12 +0100
Source: idjc
Binary: idjc
Architecture: source amd64
Version: 0.7.5-4
Distribution: unstable
Urgency: low
Maintainer: Debian Multimedia Team [EMAIL PROTECTED]
Changed-By: Free Ekanayaka [EMAIL
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.8
Date: Fri, 16 May 2008 19:58:37 +0900
Source: emboss
Binary: emboss emboss-data emboss-doc emboss-lib libajax5 libajax5-dev
libnucleus5 libnucleus5-dev
Architecture: source powerpc all
Version: 5.0.0-7
Distribution: unstable
Urgency: low
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.8
Date: Thu, 15 May 2008 14:20:57 +0200
Source: wordnet
Binary: wordnet wordnet-dev wordnet-base wordnet-sense-index wordnet-grind
dict-wn
Architecture: source all i386
Version: 1:3.0-10
Distribution: unstable
Urgency: high
Maintainer:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.8
Date: Fri, 16 May 2008 14:14:06 +0200
Source: pygobject
Binary: python-gobject python-gobject-dev python-gobject-dbg
Architecture: source all i386
Version: 2.14.1-6
Distribution: unstable
Urgency: low
Maintainer: Josselin Mouette [EMAIL
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.8
Date: Fri, 16 May 2008 15:15:13 +0200
Source: libxau
Binary: libxau6 libxau6-dbg libxau-dev
Architecture: source i386
Version: 1:1.0.3-3
Distribution: unstable
Urgency: low
Maintainer: Debian X Strike Force [EMAIL PROTECTED]
Changed-By:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.8
Date: Sat, 17 May 2008 11:39:33 +1000
Source: regina-normal
Binary: regina-normal regina-normal-dev regina-normal-mpi regina-normal-doc
Architecture: source all amd64
Version: 4.5-1
Distribution: unstable
Urgency: low
Maintainer: Ben
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.8
Date: Fri, 16 May 2008 15:08:17 +0200
Source: mpdscribble
Binary: mpdscribble
Architecture: source i386
Version: 0.2.12-10
Distribution: unstable
Urgency: low
Maintainer: Michal Čihař [EMAIL PROTECTED]
Changed-By: Michal Čihař [EMAIL
1 - 100 of 133 matches
Mail list logo
