Hi,
as a QA effort the whole archive was rebuilt yesterday to catch
build-failures, whether a package can be build twice in a row (unpack,
build, clean, build). We found about 400 packages not having a sane
clean target.
To cite
Raphael Hertzog wrote / napísal(a):
On Tue, 15 May 2007, Mgr. Peter Tuharsky wrote:
Yes, bugs are unavoidable. However, testing is often in situation whole
system broken or nearly useless. I see difference here; occassional
bug in desktop app is acceptable. Whole system unreliable is not
Steve Greenland wrote / napísal(a):
On 14-May-07, 07:55 (CDT), Mgr. Peter Tuharsky [EMAIL PROTECTED] wrote:
Ask somebody, what distro would he install at desktop for novice or M$
refugee? Why many are choosing Ubuntu instead of Debian, and even worse,
abandon Debian in favor of Ubuntu?
Why
In several mails you claimed testing as broken. This is completely
orthognal to my experience. I'm using testing since its existence
on most of my boxes.
I use it on some boxes too, however, mostly the snapshots from the
half-year before-stable period of time. Attempts to use much sooner
On Wed, 16 May 2007, Mgr. Peter Tuharsky wrote:
Don't remember, not too much. However, if hundred of packages had broken
deps,
This statement is definitely wrong.
where would You report the bug? I'm not too experienced with apt and I
hate hacking around it.
There is no need to hack around
[Christine Spang]
I'll maintain powertop if you're looking to get rid of it. I have a
new package for 1.2 sitting on my machine right now, just waiting to
get an okay before I upload.
Great to hear. I already got offers from Patrick Winnertz and Jose
Luis Rivas Contreras, who plan to
On Wed, May 16, 2007 at 08:10:44AM +0200, Martin Zobel-Helas wrote:
as a QA effort the whole archive was rebuilt yesterday to catch
build-failures, whether a package can be build twice in a row (unpack,
build, clean, build). We found about 400 packages not having a sane
clean target.
Wow,
On Wednesday 16 May 2007 09:11, Mgr. Peter Tuharsky wrote:
I'd say, half of problems with testing were connected to bugs in
installer.
This statement really wants some qualifications...
The official releases (beta and RC) of the installer for testing have had
no really serious bugs, though
Hi,
On Wed May 16, 2007 at 10:11:55 +0200, Stefano Zacchiroli wrote:
On Wed, May 16, 2007 at 08:10:44AM +0200, Martin Zobel-Helas wrote:
as a QA effort the whole archive was rebuilt yesterday to catch
build-failures, whether a package can be build twice in a row (unpack,
build, clean,
On Wed, 16 May 2007, Stefano Zacchiroli wrote:
I mean, packages that fail to build the second time have for
sure garbage left around after the former invocation of clean.
Not always. In some cases (for example, two of my packages) the error
was to modify a .po file in place to update it. The
On Wed, 16 May 2007, Stefano Zacchiroli wrote:
Wouldn't it be better to unpack a package twice in two different
directories, build and clean in one dir and then compare the obtained
tree with the tree available in the other dir?
I personally store the diff.gz from first build and compare with
* Santiago Vila [Wed, 16 May 2007 10:52:02 +0200]:
Not always. In some cases (for example, two of my packages) the error
was to modify a .po file in place to update it. The second time
you build the package, dpkg-source complains about the .mo files,
as they are binary files and they have
On Wed, May 16, 2007 at 10:11:55AM +0200, Stefano Zacchiroli wrote:
Wouldn't it be better to unpack a package twice in two different
directories, build and clean in one dir and then compare the obtained
tree with the tree available in the other dir?
IMHO, a good test would be to build the
On Wed, May 16, 2007 at 11:12:56AM +0200, Richard Atterer wrote:
Wouldn't it be better to unpack a package twice in two different
directories, build and clean in one dir and then compare the obtained
tree with the tree available in the other dir?
IMHO, a good test would be to build the
On Wed, 16 May 2007 10:52:02 +0200 (CEST)
Santiago Vila [EMAIL PROTECTED] wrote:
On Wed, 16 May 2007, Stefano Zacchiroli wrote:
I mean, packages that fail to build the second time have for
sure garbage left around after the former invocation of clean.
Not always. In some cases (for
On Tue, May 15, 2007 at 10:05:56PM -0400, Felipe Sateler wrote:
Roberto C. Sánchez wrote:
Well, the ~ character is stated to be evaluated to be less than the
empty string. If a package is the target of a security upload in
stable, you can be certain that the testing/unstable version will
On Wed, May 16, 2007 at 11:21:51AM +0200, Guus Sliepen wrote:
On Wed, May 16, 2007 at 11:12:56AM +0200, Richard Atterer wrote:
Wouldn't it be better to unpack a package twice in two different
directories, build and clean in one dir and then compare the obtained
tree with the tree
Hi, Greg
You took it quite actively.
As many see, all of them are different in server and in desktop world,
and many times Debian chooses to dictate the users we know the best
what You need instead of listening to them.
Why then are there 28000+ packages in Debian? If Debian only dictates,
I'm glad it works for You.
Peter
Greg Folkert wrote / napísal(a):
On Tue, 2007-05-15 at 21:43 +0200, Andreas Tille wrote:
On Tue, 15 May 2007, Mgr. Peter Tuharsky wrote:
We're going OT, however my experience based on last two Debian
releases:
testing becomes quite stable in means of
I don't have enough knowledge to do that.
Peter
David Nusinow wrote / napísal(a):
On Tue, May 15, 2007 at 09:41:17AM +0200, Mgr. Peter Tuharsky wrote:
The kernel, the X.org
So are you volunteering to join the kernel and XSF teams to make this
happen?
- David Nusinow
--
To
How long should bugs be tagged pending in advance of an upload?
Is it acceptable to tag a bug pending when fixed upstream and the
maintainer is confident of an upstream release in under a week? (This
is easy for me, I'm also upstream in many cases. :-))
Does it depend on the severity of the bug?
Haven't heard how libtruetype security upgrade caused OpenOffice.org,
Sorry, should be libfreetype
Peter
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
On Wednesday 16 May 2007, Mgr. Peter Tuharsky wrote:
Do you realize Debian's stable is classified as this:
Stable means stable package list. No changes in API and ABI
names or versions. This means no newer versions will ever make
it into stable. It is in
Hi all!
On Mit, 16 Mai 2007, Santiago Vila wrote:
Not always. In some cases (for example, two of my packages) the error
was to modify a .po file in place to update it. The second time
I agree. In texinfo I have the following problem
- upstream ships po/*.gmo
- debian patches patch the .po
On Wed, May 16, 2007 at 01:12:30PM +0200, cobaco (aka Bart Cornelis) wrote:
On Wednesday 16 May 2007, Mgr. Peter Tuharsky wrote:
Do you realize Debian's stable is classified as this:
Stable means stable package list. No changes in API and ABI
names or versions. This
On Wednesday 16 May 2007 12:50, Neil Williams wrote:
How long should bugs be tagged pending in advance of an upload?
For me pending is a signal to users saying issue has been confirmed,
solution is available and will be included with the next upload.
It would IMO not be correct to mark a bug
On Wednesday 16 May 2007, Neil Williams wrote:
How long should bugs be tagged pending in advance of an upload?
To me pending means, a fix is applied and will be in the next upload/release
(hence no further triaging needed on this bug).
It says nothing about when the upload with the fix will
Hi, Andreas
Another hand, many problems were well-known by the time I met them,
there wasn't need to report them again.
So if there are really well-known many problems can you do me a favour
and list one or two here?
It's been in context, meant as many of those problems -a relative part
of
On Wed, 16 May 2007, Norbert Preining wrote:
Sounds like a hack. What do other say?
There are different opinions about orig.tar.gz should be equal
to upstream. I tend to the opinion that no precompiled stuff
that can be builded by the source has to be in orig.tar.gz and
in such cases I would
On Wed, 16 May 2007, Neil Williams wrote:
How long should bugs be tagged pending in advance of an upload?
Time isn't the important metric, in my opinion. The question is
whether the maintainer has fixed the bug (or believes they have fixed
the bug) in their development environment and the fix
* Andreas Tille [Wed, 16 May 2007 13:27:54 +0200]:
On Wed, 16 May 2007, Norbert Preining wrote:
Sounds like a hack. What do other say?
There are different opinions about orig.tar.gz should be equal
to upstream.
In case there is confusion, my original suggestion was to remove the
files
Hi, Daniel
When you talk about desktop users, I think you really mean novice
consumers. Is that a fair assessment? In my experience, Debian can
work just fine on the desktop in some situations, just not for novice
home users. (think, e.g., about desktops for office workers)
We have had
On Wed, 16 May 2007, Adeodato [utf-8] Simó wrote:
There are different opinions about orig.tar.gz should be equal
to upstream.
In case there is confusion, my original suggestion was to remove the
files from debian/rules ('clean' target), not to remove them from the
orig tarball. I don't think
Neil Williams [EMAIL PROTECTED] wrote:
How long should bugs be tagged pending in advance of an upload?
Is it acceptable to tag a bug pending when fixed upstream and the
maintainer is confident of an upstream release in under a week? (This
is easy for me, I'm also upstream in many cases. :-))
Le mercredi 16 mai 2007 à 13:15 +0200, Norbert Preining a écrit :
On Mit, 16 Mai 2007, Adeodato Simó wrote:
Deleting the binary files in the clean target. dpkg-source will complain
that they're missing, but will build the package just fine.
Sounds like a hack. What do other say?
That's
I try to keep all changes to upstream as a number of patches in
debian/patches. I've heard that restricting the .diff.gz to ./debian is a
Good Thing. The drawback is that the .diff.gz becomes more difficult to read,
with the diff of diffs and all, but once the source package is unpacked it's
Frank Küster escreveu:
Neil Williams [EMAIL PROTECTED] wrote:
How long should bugs be tagged pending in advance of an upload?
Is it acceptable to tag a bug pending when fixed upstream and the
maintainer is confident of an upstream release in under a week? (This
is easy for me, I'm also
On Wed, 16 May 2007 13:24:07 +0200
Frans Pop [EMAIL PROTECTED] wrote:
On Wednesday 16 May 2007 12:50, Neil Williams wrote:
How long should bugs be tagged pending in advance of an upload?
For me pending is a signal to users saying issue has been confirmed,
solution is available and will be
On Wed, 16 May 2007, Don Armstrong wrote:
On Wed, 16 May 2007, Neil Williams wrote:
How long should bugs be tagged pending in advance of an upload?
Time isn't the important metric, in my opinion. The question is
whether the maintainer has fixed the bug (or believes they have fixed
the
On Wednesday 16 May 2007, Mgr. Peter Tuharsky wrote:
Thus, I assume that not only novice consumers have the need for
improving desktop software and bugs seen fixed.
However, Debian dosen't officially support and embrace any way to do
this. Watching for new version, You're on Your own.
Yes,
Andreas Tille [EMAIL PROTECTED] wrote:
On Wed, 16 May 2007, Adeodato [utf-8] Simó wrote:
There are different opinions about orig.tar.gz should be equal
to upstream.
In case there is confusion, my original suggestion was to remove the
files from debian/rules ('clean' target), not to remove
Norbert Preining wrote:
Now at a second build time we have changes in the binary .gmo files
which cannot be represented.
What is the preferred solution for such a case?
I usually save upstream's generated files somewhere in debian/rules during
build, and copy them back in the clean target.
Hi
On Wed, 16 May 2007 13:52:28 +0200
Magnus Holmgren [EMAIL PROTECTED] wrote:
Now, how do you combine these? Several people have thought: The VCS
can handle the changesets. Putting patches under VCS is silly! Maybe it is.
What's for certain is, that to someone who just does 'apt-get
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, May 16, 2007 at 01:24:07PM +0200, Frans Pop wrote:
On Wednesday 16 May 2007 12:50, Neil Williams wrote:
How long should bugs be tagged pending in advance of an upload?
For me pending is a signal to users saying issue has been confirmed,
Magnus Holmgren [EMAIL PROTECTED] wrote:
Now, how do you combine these? Several people have thought: The VCS
can handle the changesets. Putting patches under VCS is silly! Maybe it is.
I don't agree. With patches in debian/patches, you can give names to
those files. Names that explain what
Magnus Holmgren wrote:
Now, how do you combine these? Several people have thought: The VCS
can handle the changesets. Putting patches under VCS is silly!
I fully agree. Unfortunately Subversion doesn't make it easy for you. You
can keep your patches in different feature branches, but it gets
I am attaching the local.te file below for comment; some of
this should probably go into the refpolicy package, and, eventually,
upstream.
Would be nice to actually append the file.
I have attached a patch that I'm using in my work on getting a strict unstable
system to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, May 16, 2007 at 06:01:54AM -0700, Don Armstrong wrote:
On Wed, 16 May 2007, Kevin Mark wrote:
would it be useful for some process to periodically poll the bts for
'pending' tags that are unusually old [ say 1 or 2 months ] and ping
the
On Wednesday 16 May 2007 14:52, Marcus Better wrote:
However, he can read debian/copyright and
debian/README.Debian to find out where the maintainer keeps his
repository,
Or check the PTS, if you use XS-Vcs-* control fields.
Yeah, I suppose I didn't know that when I started writing my
On Wed, 16 May 2007, Kevin Mark wrote:
The other idea was for a simple .../pending page on the bts so that
folks could quickly see what is about to be fixed.
Just append ;pend-inc=pending-fixed; to your pkgreport.cgi url, like so:
Le Wed, May 16, 2007 at 01:26:30AM +0200, Frans Pop a écrit :
On Wednesday 16 May 2007 01:11, Charles Plessy wrote:
Maybe at each point release, the release notes could be
updated on the basis of these messages. Things like emacs21 does not
have full unicode support, but you can display
Marcus Better [EMAIL PROTECTED] wrote:
Frank Küster wrote:
The VCS can handle the changesets. Putting patches under VCS is silly!
I don't agree. With patches in debian/patches, you can give names to
those files.
With a VCS you can also name branches, or changesets (stgit).
Personally,
Am 2007-05-15 09:29:46, schrieb Mgr. Peter Tuharsky:
I think, any new stable version of the desktop software should be
automaticaly added to security updates and distributed to end user.
There's no need to test the tested and stabilise the stable software.
Should the new stable version be
Am 2007-05-15 11:25:56, schrieb Mgr. Peter Tuharsky:
Do You think, that
-compiling new upstream version of software against stable platform,
building a package and distributing it
Containing NEW bugs and the loop goes on... -- No Thanks!
-needs more effort than
-studying security fixes
Am 2007-05-15 09:41:17, schrieb Mgr. Peter Tuharsky:
The kernel, the X.org
I realise, that the kernel and X.org are somewhat delicate things,
because they affect both desktop and server. Changing them in the middle
of release life, might not sound too well.
Sorry, thats not right!
I
(Please don't CC me on list mail.)
On 16-May-07, 01:58 (CDT), Mgr. Peter Tuharsky [EMAIL PROTECTED] wrote:
Steve Greenland wrote / nap?sal(a):
As I illustreted, rock solid is not automatically guaranteed by
oldness of software or by length of pre-release testing.
And as others have
On Wed, May 16, 2007 at 08:10:44AM +0200, Martin Zobel-Helas wrote:
as a QA effort the whole archive was rebuilt yesterday to catch
build-failures, whether a package can be build twice in a row (unpack,
build, clean, build). We found about 400 packages not having a sane
clean target.
To
Martin Zobel-Helas [EMAIL PROTECTED] writes:
On Wed May 16, 2007 at 10:11:55 +0200, Stefano Zacchiroli wrote:
Wouldn't it be better to unpack a package twice in two different
directories, build and clean in one dir and then compare the obtained
tree with the tree available in the other dir?
Martin Zobel-Helas [EMAIL PROTECTED] writes:
Wouldn't it be better to unpack a package twice in two different
directories, build and clean in one dir and then compare the obtained
tree with the tree available in the other dir?
That would surely be the better solution to catch this policy
On Wed, 16 May 07 11:36, Lennart Sorensen wrote:
What about packages that automatically pull in updated autoconf files as
part of the build, or regenerate .po files which were already there, but
due to a new version of the tools generates a different .po file from
what was already there? The
Si no ves este newsletter, pincha aquiacute; o pega esta ruta en tu navegador
http://mails.lasagra.com/envios/2007-05-16.html
On 16/05/07 at 10:11 +0200, Stefano Zacchiroli wrote:
Isn't twice building too coarse grained to spot actual violation of
this rule? I mean, packages that fail to build the second time have for
sure garbage left around after the former invocation of clean. But it
is not granted that packages
On Tue, 15 May 2007 23:54:02 +0200
maximilian attems [EMAIL PROTECTED] wrote:
i'd appreciate if you post such questions to the corresponding
development mailing list which is debian-kernel for initramfs
questions.
thanks
Current pratice is to only call `update-initramfs -u', that is, to
Magnus Holmgren wrote:
I have now. IIUC, it lets you group and name diffs vs. a particular state
of the source code, but the end result is a normal .diff.gz, meaning that
everyone else has to use stgit too to get all the benefits, right?
Yes. People working on the same project team should use
Frank Küster wrote:
Personally, I don't like branches very much. Nobody ever explained to
me a good receipe to handle them in the case where development proceeds
in both, and important fixes are copied from one to the other.
I believe git handles that, it should work nicely in most cases.
On Fri, 2007-05-11 at 01:44 +0100, Stephen Gran wrote:
This one time, at band camp, Ludovic Rousseau said:
Le 10.05.2007, à 00:25:32, Stephen Gran a écrit:
I have always just asked them on IRC on #debian-kernel.
Have you done this time again?
If not, could you? (I do not use IRC.)
On (16/05/07 13:52), Magnus Holmgren wrote:
svn-buildpackage has a feature called mergeWithUpstream mode, which means
that only the files that are actually touched are put under version control
(I thought most $TLA-buildpackage would have something similar, but it seems
to be unique to
On Wed, May 16, 2007 at 07:57:33PM +0200, Armin Berres wrote:
I may be wrong, but IIRC removing those generated files in the clean
target is the solution if you want a clean .diff.gz.
But dpkg-buildpackage will then spit out lots of warnings about being
unable to store the deletion of a binary
I am currently trying to find a valid UTF8 encoded text file to check my
terminal settings and such to make sure I have it working right. So to
do this I figured I would just find some changelog file that claims to
be in UTF8 format and see if it views correctly. Well so far no luck.
Every
Lennart Sorensen [EMAIL PROTECTED] writes:
So should changelog files for debian packages be UTF8
Yes.
and if so are there any that actually are
lintian's is, at least. Many others are these days as well. All of my
packages have UTF-8 changelog files, although not all actually have
On Wed, May 16, 2007 at 02:53:09PM -0700, Russ Allbery wrote:
Lennart Sorensen [EMAIL PROTECTED] writes:
Yes.
Hmm, well I haven't found one yet and I think I checked 10 so far, all
of which have non ascii characters but none of which appeared valid to
me.
lintian's is, at least. Many others
* Lennart Sorensen [Wed, 16 May 2007 18:01:40 -0400]:
I wonder how many packages are triggering that right now.
http://lintian.debian.org/reports/Tdebian-changelog-file-uses-obsolete-national-encoding.html
So is this valid utf-8? I don't believe so. If it is I have to go
reread the UTF-8
On Wed, May 16, 2007 at 06:01:40PM -0400, Lennart Sorensen wrote:
On Wed, May 16, 2007 at 02:53:09PM -0700, Russ Allbery wrote:
Lennart Sorensen [EMAIL PROTECTED] writes:
Yes.
Hmm, well I haven't found one yet and I think I checked 10 so far, all
of which have non ascii characters but none
Lennart Sorensen [EMAIL PROTECTED] writes:
On Wed, May 16, 2007 at 02:53:09PM -0700, Russ Allbery wrote:
debian-changelog-file-uses-obsolete-national-encoding is the tag.
I wonder how many packages are triggering that right now.
96.
[EMAIL PROTECTED] (Lennart Sorensen) writes:
So is this valid utf-8? I don't believe so. If it is I have to go
reread the UTF-8 spec again. :)
4b c4 99 73 74 75 74 69 73 (K..stutis)
(I found this one in base-config from sarge since I happened to have
that one open in a hex editor for
On ke, 2007-05-16 at 23:17 +0100, Dagfinn Ilmari Mannsåker wrote:
That's trivial to check. Just feed it to recode and specify UTF-8
Hexadecimal input:
You might also be interested in isutf8 from moreutils.
--
Never underestimate the power of a small tactical Lisp interpreter.
--
To
On Wed, May 16, 2007 at 10:00:57AM +, [EMAIL PROTECTED] wrote:
On Wed, May 16, 2007 at 11:21:51AM +0200, Guus Sliepen wrote:
On Wed, May 16, 2007 at 11:12:56AM +0200, Richard Atterer wrote:
Wouldn't it be better to unpack a package twice in two different
directories, build and
Steve Langasek [EMAIL PROTECTED] wrote:
granted there are things like this, but reproducible builds would be
fantastic and well worth the effort.
If you're talking about byte-for-byte identical builds, then no, that
would be a tremendous amount of effort for no practical gain. There's no
On ke, 2007-05-16 at 16:26 -0700, Tyler MacDonald wrote:
We should expect that given the same source, headers, and libraries, we
would get the same bytes out of a build every time. Any deviation from this
would indicate something different, or erratic. If it doesn't cause
problems, fine, but
Lars Wirzenius [EMAIL PROTECTED] wrote:
printf(This program was compiled on __DATE__ \n);
An example like the above has already been given. Build dates and other
variable information gets put into a lot of output files from
compilations.
Sorry, I was speaking from an overly selfish point
Tyler MacDonald [EMAIL PROTECTED] writes:
We should expect that given the same source, headers, and libraries, we
would get the same bytes out of a build every time.
This just isn't how compilers work. Timestamps are encoded in binaries,
temporary build directories are encoded in debugging
Package: wnpp
Severity: wishlist
Owner: Bernd Zeimetz [EMAIL PROTECTED]
* Package name: wmi
Version : 20070516
Upstream Author : Zenoss / Andrzej Hajda / The Samba Team
* URL : http://dev.zenoss.org/svn/trunk/wmi/
* License : GPL/LGPL and others
Programming
Frank Küster wrote:
Personally, I don't like branches very much. Nobody ever explained to
me a good receipe to handle them in the case where development proceeds
in both, and important fixes are copied from one to the other.
http://youtube.com/watch?v=4XpnKHJAok8
is good to view if you're
Package: wnpp
Severity: wishlist
Owner: Sebastien Delafond [EMAIL PROTECTED]
* Package name: jruby
Version : 1.0.0rc2
Upstream Author : The JRuby Team
* URL : http://jruby.codehaus.org/
* License : tri license CPL/GPL/LGPL
Programming Lang: Ruby, Java
Roberto C. Sánchez wrote:
On Tue, May 15, 2007 at 10:05:56PM -0400, Felipe Sateler wrote:
Roberto C. Sánchez wrote:
Well, the ~ character is stated to be evaluated to be less than the
empty string. If a package is the target of a security upload in
stable, you can be certain that the
On Wed, May 16, 2007 at 10:54:09PM -0400, Felipe Sateler wrote:
Roberto C. Sánchez wrote:
On Tue, May 15, 2007 at 10:05:56PM -0400, Felipe Sateler wrote:
Roberto C. Sánchez wrote:
Well, the ~ character is stated to be evaluated to be less than the
empty string. If a package is the
Mgr. Peter Tuharsky [EMAIL PROTECTED] writes:
I wrote worse because for Debian, this is worse. Not that it is
damaging it somehow. Of course there naturally will be other
distros, cooperating hopefully.
It's worse because it implies, that Debian is not as good desktop
as it ought to be.
[Lennart Sorensen]
But dpkg-buildpackage will then spit out lots of warnings about being
unable to store the deletion of a binary file in the diff. So it
will look ugly, but work I guess.
dpkg-buildpackage doesn't store _any_ deletions in the diff.gz - the
warning about deletions has nothing
Peter Samuelson wrote:
I'd file a bug asking for this, but clearly the warning is intentional,
so a bug is not likely to get much more attention than #12564, which is
also related.
12564 should be fixable with wig and pen. If it does get fixed then
deleting files in clean will no longer be the
I install regulary NEW kernels where Debian had only 2.4.27 I used
2.4.32/33 and thats NOT the same as pushing a NEW Xorg into stable.
The Kernels can be installed without any problems parallel, and if
one is not working, you boot the last working one.
Yes, I have written it there too.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Wed, 16 May 2007 07:21:32 +0200
Source: xml-im-exporter
Binary: libxml-im-exporter-java
Architecture: source all
Version: 1.1-3
Distribution: unstable
Urgency: low
Maintainer: Debian Java maintainers [EMAIL PROTECTED]
Changed-By:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Wed, 16 May 2007 07:42:33 +0200
Source: ganymed-ssh2
Binary: libganymed-ssh2-java
Architecture: source all
Version: 210-2
Distribution: unstable
Urgency: low
Maintainer: Debian Java Maintainers [EMAIL PROTECTED]
Changed-By: Michael
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Wed, 16 May 2007 15:56:42 +1000
Source: 915resolution
Binary: 915resolution
Architecture: source i386
Version: 0.5.2-11
Distribution: unstable
Urgency: low
Maintainer: Steffen Joeris [EMAIL PROTECTED]
Changed-By: Steffen Joeris
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Tue, 15 May 2007 23:19:17 -0700
Source: autogen
Binary: autogen libopts25-dev libopts25
Architecture: source i386
Version: 1:5.9.1-2
Distribution: unstable
Urgency: low
Maintainer: Matt Kraai [EMAIL PROTECTED]
Changed-By: Matt Kraai
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Tue, 15 May 2007 19:48:06 +0200
Source: gcc-snapshot
Binary: gcc-snapshot
Architecture: source amd64
Version: 20070515-1
Distribution: unstable
Urgency: low
Maintainer: Debian GCC Maintainers [EMAIL PROTECTED]
Changed-By: Martin
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Wed, 16 May 2007 13:58:24 +0900
Source: heartbeat
Binary: libstonith0 heartbeat libpils0 heartbeat-2 heartbeat-dev libstonith-dev
ldirectord libpils-dev ldirectord-2 heartbeat-2-dev heartbeat-gui
heartbeat-2-gui
Architecture:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Wed, 16 May 2007 15:44:32 +1000
Source: foo2zjs
Binary: foo2zjs
Architecture: source i386
Version: 20061224-3
Distribution: unstable
Urgency: low
Maintainer: Steffen Joeris [EMAIL PROTECTED]
Changed-By: Steffen Joeris [EMAIL
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Tue, 15 May 2007 18:35:14 -0700
Source: guilt
Binary: guilt
Architecture: source all
Version: 0.25-1
Distribution: unstable
Urgency: low
Maintainer: Brandon Philips [EMAIL PROTECTED]
Changed-By: Brandon Philips [EMAIL PROTECTED]
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Wed, 16 May 2007 09:06:44 +0200
Source: cupsys
Binary: libcupsys2-dev cupsys libcupsys2 libcupsimage2 cupsys-common
cupsys-client cupsys-dbg cupsys-bsd libcupsimage2-dev
Architecture: source i386 all
Version: 1.2.11-2
Distribution:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Wed, 16 May 2007 09:25:21 +0200
Source: wammu
Binary: wammu
Architecture: source all
Version: 0.20-1
Distribution: unstable
Urgency: low
Maintainer: Michal ÄihaÅ [EMAIL PROTECTED]
Changed-By: Michal ÄihaÅ [EMAIL PROTECTED]
1 - 100 of 196 matches
Mail list logo
