Stefano Zacchiroli wrote:
On Wed, May 06, 2009 at 12:10:54AM +0200, Joerg Jaspert wrote:
So, does anybody still see reasons to continue supporting a standalone
/usr?
There had been lots of responses to that.
Yes, the most repeated argument has been mount /usr via NFS.
Unfortunately, nobody
Giacomo Catenazzi c...@debian.org writes:
- On large parallel systems, people use something more than a base debian
console installation.
Usually on net you have a complete copy for root, var etc
(in case of compromised computers. Very handy instead of reinstalling the
system)
So
Package: wnpp
Severity: wishlist
Owner: Julián Hernández Gómez julianhernan...@gmail.com
* Package name: python-ftputil
Version : 2.4
Upstream Author : Stefan Schwarzer sschwar...@sschwarzer.net
* URL : http://ftputil.sschwarzer.net/
* License : BSD
Well, some people argued for that. Like you, I'm wondering how one
actually does this in practice! However there are some rather more
reasonable uses which have been mentioned:
- read-only /usr (for security)
- backups
- recovery (ability to mount root only; important if there's fs
[no answers for this yet on ‘debian-mentors’, so trying here]
Howdy all,
I have an upstream for a package who has started using a VCS hosting
site for publishing the code. It's possible they will continue to make
tarball releases, but in case they don't at some point in the future,
I'd like to
On Tue, 2009-05-05 at 16:25 -0700, Russ Allbery wrote:
Stefano Zacchiroli z...@debian.org writes:
Yes, the most repeated argument has been mount /usr via NFS.
Unfortunately, nobody yet explained how do they update the resulting
cluster of machines.
It's not particularly difficult. You
Frank Lin PIAT fp...@klabs.be writes:
On Tue, 2009-05-05 at 16:25 -0700, Russ Allbery wrote:
It's not particularly difficult. You update the system master and
push that update into NFS, synchronizing any non-/usr data as you
need to across all the systems mounting that NFS partition.
I
Package: wnpp
Severity: wishlist
Owner: Ritesh Raj Sarraf r...@researchut.com
* Package name: inotifyx
Version : 0.1.0
Upstream Author : Forest Bond for...@alittletooquiet.net
* URL : http://www.alittletooquiet.net/software/inotifyx/
* License : MIT/X
On Wed, May 06, 2009 at 12:30:14AM +0200, Stefano Zacchiroli wrote:
Of course the problem is that if you update on the NFS server, then
related /etc and /var files [1] will not get updated on the NFS client
machines and you need to propagate changes there.
One thing to remember is when you
Le mardi 05 mai 2009 à 16:25 -0700, Russ Allbery a écrit :
It's not particularly difficult. You update the system master and push
that update into NFS, synchronizing any non-/usr data as you need to
across all the systems mounting that NFS partition.
Sure, but what is the point of doing that
Le mardi 05 mai 2009 à 23:15 -0700, Russ Allbery a écrit :
I think it's pretty unlikely that *most* Debian machines are done that
way. There are a lot better tools for keeping large numbers of systems
in sync these days than simple cloning from golden images, and a lot of
drawbacks to the
+ Ritesh Raj Sarraf (Wed, 06 May 2009 12:23:06 +0530):
Hello!, and thanks for your interest in packaging new software for
Debian.
* Package name: inotifyx
Version : 0.1.0
Upstream Author : Forest Bond for...@alittletooquiet.net
* URL :
Thank you for the additional information you have supplied regarding
this Bug report.
This is an automatically generated reply to let you know your message
has been received.
Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will
On 2009-05-06, Russ Allbery r...@debian.org wrote:
Giacomo Catenazzi c...@debian.org writes:
- On large parallel systems, people use something more than a base debian
console installation.
Usually on net you have a complete copy for root, var etc
(in case of compromised computers. Very
On Wednesday 06 May 2009 13:45:19 Adeodato Simó wrote:
Description : Simple Python binding to the Linux inotify file
system event monitoring API
inotifyx is a Python extension providing access to the Linux inotify
file system event notification API. It is primarily written in C but
Twas brillig at 17:09:45 06.05.2009 UTC+05 when r...@researchut.com did gyre
and gimble:
RRS Given the pytagsfs upstream maintainer's announcement email [1], I
RRS believe python-inotify is not going to be maintained further.
RRS But this whole discussion started with python-inotify in
RRS
Em Qua, 2009-05-06 às 00:30 +0200, Stefano Zacchiroli escreveu:
On Wed, May 06, 2009 at 12:10:54AM +0200, Joerg Jaspert wrote:
So, does anybody still see reasons to continue supporting a standalone
/usr?
There had been lots of responses to that.
Yes, the most repeated argument has been
On May 05, Steve Langasek vor...@debian.org wrote:
This is false for Ubuntu. Not only is it supported, but significant effort
was put into *fixing* a /usr-as-separate-mount bug in Ubuntu 9.04 as
pertains to wpasupplicant.
You may want to discuss this with Keybuk then, because he still
On Wed, May 06, 2009 at 09:38:39AM -0300, Daniel Ruoso wrote:
Simple.
sarcasm
Sure, that's precisely what I'd call being properly supported in
Debian.
/sarcasm
In particular, from the replies to my question the picture I get is
that everybody is using ad hoc solutions to implement what some
Stefano Zacchiroli wrote:
On Wed, May 06, 2009 at 09:38:39AM -0300, Daniel Ruoso wrote:
Simple.
sarcasm
Sure, that's precisely what I'd call being properly supported in
Debian.
/sarcasm
In particular, from the replies to my question the picture I get is
that everybody is using ad hoc
On Wed, 06 May 2009, Stefano Zacchiroli wrote:
Of the two one:
- We decide that mounting /usr remotely is a Debian goal.
If we do so, the mechanisms to make it work should not be as ad hoc
as this thread as hinted. We should provide a package explicitly
made to make this workflow
Stefano Zacchiroli wrote:
A few side notes:
* everybody overlooked the subtle theoretical problem that our
maintainer scripts can potentially do *everything* on the file
system and *everywhere*, and that they are written in a Turing
complete language (shell script). This means that you
[Stefano Zacchiroli]
The trick of fiddling the dpkg database on the client machine and
then run dpkg --configure -a there is indeed nice. But again,
requesting our users to do that, potentially messing up with the
dpkg database, is IMO not something we can call being properly
On Wed, May 06, 2009 at 03:06:34PM +0200, Giacomo A. Catenazzi wrote:
But system administration is per definition ad hoc solution.
This is our power. Why we give sources? Also to allow us
to tweak debian.
This is a utterly poor argument.
I can easily twist it against you by saying why we give
Stefano Zacchiroli wrote:
On Wed, May 06, 2009 at 03:06:34PM +0200, Giacomo A. Catenazzi wrote:
But system administration is per definition ad hoc solution.
This is our power. Why we give sources? Also to allow us
to tweak debian.
This is a utterly poor argument.
I can easily twist it against
Hi,
are there any plans to adopt
https://code.launchpad.net/vmbuilder
for Debian?
Being able to create ec2, vmware or similar images easily would be nice to have
for Debian, too.
Cheers,
Bernd
--
Bernd Zeimetz Debian GNU/Linux Developer
GPG Fingerprint: 06C8 C9A2
Bernd Zeimetz a écrit :
Hi,
are there any plans to adopt
https://code.launchpad.net/vmbuilder
for Debian?
Being able to create ec2, vmware or similar images easily would be nice to
have
for Debian, too.
Hi Bernd,
There is this:
On-demand Cloud Computing with Amazon EC2 and Eucalyptus
Package: wnpp
Severity: wishlist
Owner: Mathieu Parent math.par...@gmail.com
* Package name: ansel1
Version : 1.0
Upstream Authors: Chuck Hagenbuch ch...@horde.org
Michael J. Rubinsky mrubi...@horde.org
* URL : http://horde.org/ansel/
* License
On Wed, May 06, 2009 at 03:31:23PM +0200, Stefano Zacchiroli wrote:
Anyhow, *you* don't understand the problem and you are probably the
only one thinking I'm selling vapor. From other people's replies I
conclude that the problem is quite clear and my vapor was so concrete
that others hinted
Okay, again; waldi told me there are missing information,
and that debian-de...@lists.d.o has to be Cc’d.
Package name: php-perl (Binary: php5-perl)
Version:1.0.0
Upstream Author:Dmitry Stogov
Licence:PHP 3.0 (upstream), GPL (packaging)
Language:
Le mercredi 06 mai 2009 à 08:57 -0500, Peter Samuelson a écrit :
Also, this procedure would be much more reliable if we said, in Policy,
that maintainer scripts are not allowed to fail if /usr is not writable.
(mount -o ro, SELinux, chattr +i, NFS root_squash, whatever.)
Would you support
On Tue, 05 May 2009, Marco d'Itri wrote:
I know that Debian supports this, but I also know that maintaning
forever large changes to packages for no real gain sucks.
I wonder what these are, and I hope you will start a separate thread with
that information.
So, does anybody still see reasons
| Debian is switching to EGLIBC
|
| I have just uploaded Embedded GLIBC (EGLIBC) into the archive (it is
| currently waiting in the NEW queue), which will soon replace the GNU
| C Library (GLIBC).
| [...]
-- http://blog.aurel32.net/?p=47
Where did this decission (and the discussion around it)
Le mercredi 06 mai 2009 à 18:18 +0200, Michael Prokop a écrit :
Where did this decission (and the discussion around it) took place?
I can't find anything neither on debian-devel nor on debian-devel-glibc.
Do all maintainers need your approval before switching to another branch
for packages they
Michael Prokop a écrit :
| Debian is switching to EGLIBC
|
| I have just uploaded Embedded GLIBC (EGLIBC) into the archive (it is
| currently waiting in the NEW queue), which will soon replace the GNU
| C Library (GLIBC).
| [...]
-- http://blog.aurel32.net/?p=47
Where did this
* Josselin Mouette j...@debian.org wrote:
Le mercredi 06 mai 2009 =C3=A0 18:18 +0200, Michael Prokop a =C3=A9crit :
Where did this decission (and the discussion around it) took place?
I can't find anything neither on debian-devel nor on debian-devel-glibc.
Do all maintainers need your
Should source packages need to build-depend on debug packages?
(See python-gtk2 for one example. python-all-dbg is small but
python-numpy-dbg is 15Mb!)
Just curious - is it only python packages that do this?
--
Neil Williams
=
http://www.data-freedom.org/
Le mercredi 06 mai 2009 à 17:35 +0100, Neil Williams a écrit :
Should source packages need to build-depend on debug packages?
When it is needed.
(See python-gtk2 for one example. python-all-dbg is small but
python-numpy-dbg is 15Mb!)
python-all-dbg brings python2.[45]-dbg, which makes 48 MB.
Michael Prokop a écrit :
* Josselin Mouette j...@debian.org wrote:
Le mercredi 06 mai 2009 =C3=A0 18:18 +0200, Michael Prokop a =C3=A9crit :
Where did this decission (and the discussion around it) took place?
I can't find anything neither on debian-devel nor on debian-devel-glibc.
Do all
On Thu, May 7, 2009 at 12:33 AM, Michael Prokop m...@grml.org wrote:
No. Though I think that for essential packages like libc it could be
worth a public discussion.
In this case there wouldn't be any point of discussing it, I predict
the discussion would simply be yes, AOL, +1, do it already,
* Aurelien Jarno aurel...@aurel32.net wrote:
Michael Prokop a écrit :
* Josselin Mouette j...@debian.org wrote:
Le mercredi 06 mai 2009 =C3=A0 18:18 +0200, Michael Prokop a =C3=A9crit :
Where did this decission (and the discussion around it) took place?
I can't find anything neither on
On Wed, 06 May 2009 18:39:32 +0200
Josselin Mouette j...@debian.org wrote:
Le mercredi 06 mai 2009 à 17:35 +0100, Neil Williams a écrit :
Should source packages need to build-depend on debug packages?
When it is needed.
(See python-gtk2 for one example. python-all-dbg is small but
Package: wnpp
Severity: wishlist
Owner: Michael Biebl bi...@debian.org
* Package name: libatasmart
Version : 0.13
Upstream Author : Lennart Poettering lenn...@poettering.net
* URL : http://0pointer.de/blog/projects/being-smart.html
* License : LGPLv2+
Le 6 mai 09 à 00:30, Stefano Zacchiroli a écrit :
On Wed, May 06, 2009 at 12:10:54AM +0200, Joerg Jaspert wrote:
So, does anybody still see reasons to continue supporting a
standalone
/usr?
There had been lots of responses to that.
Yes, the most repeated argument has been mount /usr via
On Wed, Mar 11, 2009 at 10:10:13PM -0700, Steve Langasek wrote:
But moving the 32-bit libs to /usr/lib32 does not make us
standards-conformant on amd64, because the FHS (yuckily) standardized on
storing the *32-bit* libs in /usr/lib on this architecture, with 64-bit libs
in /usr/lib64.
That
On Wed, Mar 11, 2009 at 06:11:18PM +, Clint Adams wrote:
Thoughts?
I am going to assume from the lack of responses to this that no one
but the bug submitters care.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact
On Wed, May 06, 2009 at 02:56:20PM +0200, Stefano Zacchiroli wrote:
In particular, from the replies to my question the picture I get is
that everybody is using ad hoc solutions to implement what some people
are pretending to be properly supported by Debian. I found it not
defendable, maybe
Aurelien Jarno wrote:
Michael Prokop a écrit :
| Debian is switching to EGLIBC
|
| I have just uploaded Embedded GLIBC (EGLIBC) into the archive (it is
| currently waiting in the NEW queue), which will soon replace the GNU
| C Library (GLIBC).
| [...]
-- http://blog.aurel32.net/?p=47
John Goerzen jgoer...@complete.org wrote:
Hi,
I, for one, have heard just about enough of Hey developers, we're doing
$FOO, and it's already been decided, so put up or shut up from people.
I'd like a little bit more along the lines of Hey developers, we
really think $FOO is a good idea.
On Wed, May 06, 2009, Neil Williams wrote:
(See python-gtk2 for one example. python-all-dbg is small but
python-numpy-dbg is 15Mb!)
pythonx.y-dbg is ABI incompatible with pythonx.y and we need to bdep on
pythonx.y-dbg to build a -dbg for a python extension -- these are *not*
detached
Philipp Kern tr...@philkern.de writes:
On 2009-05-06, Russ Allbery r...@debian.org wrote:
I think it's pretty unlikely that *most* Debian machines are done
that way. There are a lot better tools for keeping large numbers of
systems in sync these days than simple cloning from golden images,
Hi all,
It is new to me that we should announce changes in packages on
debian-devel. I haven't seen that before for other (key) packages, while
it is very usual to see such announcements on planet.debian.org.
I have decided to add a blog entry after many people asking me on IRC
What is this
Dear developers,
There is an increased usage of triggers in squeeze and I would like to issue a
word of warning concerning lenny to squeeze upgrade:
Before removing the maintainer script code that that is replaced by the
activation of a trigger, you have to make sure that a suitable version
of
On Wed, 06 May 2009 21:57:19 +0200 Julien BLACHE jbla...@debian.org
wrote:
How does hey developers, we're sick and tired of having to put up
with Uli, how about you find some new people to maintain glibc in
Debian sound like?
It sounds unnecessarily confrontational---it's daring people to
Package: wnpp
Severity: wishlist
Owner: Janos Guljas ja...@janos.in.rs
* Package name: python-django-south
Version : svn
Upstream Author : Andrew Godwin and...@aeracode.org
* URL : http://south.aeracode.org
* License : Apache
Programming Lang: Python
On Tue, May 05, 2009 at 05:06:26PM +0200, martin f krafft wrote:
also sprach Carsten Hey cars...@debian.org [2009.05.05.1645 +0200]:
Depending on default-mta | mta in a upload to s-p-u does not fix
anything since there is no default-mta in stable. This would possibly
even break pinning in
Steve Langasek wrote:
On Tue, May 05, 2009 at 05:06:26PM +0200, martin f krafft wrote:
also sprach Carsten Hey cars...@debian.org [2009.05.05.1645 +0200]:
FWIW, Ubuntu did what I consider the right thing:
http://launchpadlibrarian.net/21235281/mdadm_2.6.7.1-1ubuntu4_2.6.7.1-1ubuntu5.diff.gz
On Wed, May 06, 2009 at 10:53:33PM +0200, Janos Guljas wrote:
Package: wnpp
Severity: wishlist
Owner: Janos Guljas ja...@janos.in.rs
* Package name: python-django-south
An ITP for this was already filed[0] by David Watson (CCed) a few days
ago. Maybe the two of you could work together
On May 06, Luk Claes l...@debian.org wrote:
Maybe we should also consider changing the default MTA to postfix?
Agreed, it's about time.
--
ciao,
Marco
signature.asc
Description: Digital signature
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, 06 May 2009 14:21:05 -0500
John Goerzen jgoer...@complete.org wrote:
I for one would have appreciated it if, before the upload, you had
laid out why you're planning to do it here on debian-devel. I don't
think you would have met any
I will get in touch with David Watson.
Thank you.
On Wed, May 6, 2009 at 11:29 PM, James Vega james...@debian.org wrote:
On Wed, May 06, 2009 at 10:53:33PM +0200, Janos Guljas wrote:
Package: wnpp
Severity: wishlist
Owner: Janos Guljas ja...@janos.in.rs
* Package name :
Le mercredi 06 mai 2009 à 18:14 +0100, Neil Williams a écrit :
It did strike me as unusual when working from a basis of autotools and
C/C++ packages. If the -dbg package is more than just debugging
symbols, should those other parts be in the -dev and leave the
debugging symbols alone? Is that
Julien BLACHE wrote:
John Goerzen jgoer...@complete.org wrote:
Hi,
I, for one, have heard just about enough of Hey developers, we're doing
$FOO, and it's already been decided, so put up or shut up from people.
I'd like a little bit more along the lines of Hey developers, we
really think
Le mercredi 06 mai 2009 à 23:29 +0200, Luk Claes a écrit :
Maybe we should also consider changing the default MTA to postfix?
Given that the default configuration is extremely simplistic and doesn’t
use a percent of either exim or postfix features, I still wonder why it
is not something like
Yves-Alexis Perez wrote:
On Wed, 06 May 2009 14:21:05 -0500
John Goerzen jgoer...@complete.org wrote:
I for one would have appreciated it if, before the upload, you had
laid out why you're planning to do it here on debian-devel. I don't
think you would have met any opposition.
I
Le mardi 05 mai 2009 à 23:38 +0200, Frank Lin PIAT a écrit :
Interesting. I thought 386 wasn't supported anymore (?)
AFAIK the kernel is able to emulate a 486 when running on a 386.
--
.''`. Josselin Mouette
: :' :
`. `' “I recommend you to learn English in hope that you in
`-
Josselin Mouette wrote:
Le mercredi 06 mai 2009 à 23:29 +0200, Luk Claes a écrit :
Maybe we should also consider changing the default MTA to postfix?
Given that the default configuration is extremely simplistic and doesn’t
use a percent of either exim or postfix features, I still wonder why
+ Thorsten Alteholz (Wed, 06 May 2009 13:22:53 +0200):
Hi Adeodato,
Hello, Thorsten (hope it's okay I'm quoting you in public).
could you please tell me the reason for blocking libtool's transition
from unstable to testing? I have a few packages that depend on libtool
but don't want to
also sprach Joerg Jaspert jo...@debian.org [2009.05.07.0002 +0200]:
As much as i like postfix and hate exim: no. If we change, please
go to something like nullmailer|ssmtp|whateversimple.
Correct me if I am wrong, but I think those do not do queueing,
which will break the default assumption
also sprach Marco d'Itri m...@linux.it [2009.05.06.2338 +0200]:
Maybe we should also consider changing the default MTA to postfix?
Agreed, it's about time.
http://doodle.com/exre35q7ckruyxpx
--
.''`. martin f. krafft madd...@d.o Related projects:
: :' : proud Debian developer
Le jeudi 07 mai 2009 à 00:01 +0200, Luk Claes a écrit :
The default MTA if the one that should work easily for most situations IMHO.
Where do we draw the line for “most situations”? If you want to do
serious email work, you’ll have to spend some time configuring your
exim/postfix and install
On 11742 March 1977, Luk Claes wrote:
Maybe we should also consider changing the default MTA to postfix?
As much as i like postfix and hate exim: no. If we change, please go to
something like nullmailer|ssmtp|whateversimple.
--
bye, Joerg
Overfiend joshk: okay. I've manned a Debian booth
On Wed, May 06, 2009 at 09:36:56PM +0200, Iustin Pop wrote:
- We decide that if you want to mount /usr remotely you are on your
own.
If we do so, we should stop using mount /usr remotely as an
argument for keeping /usr as a single filesystem.
What about the (many) arguments made
On Thu May 07 00:38, Stefano Zacchiroli wrote:
What about the (many) arguments made here about the *other* reasons to
have /usr a separate filesystem?
I've nothing against them, I was countering only this precise
argument. FWIW, I haven't seen that many, though the one about
read-only
On Thu, 07 May 2009, martin f krafft wrote:
Correct me if I am wrong, but I think those do not do queueing,
which will break the default assumption that I've seen almost
everywhere, which is that when sendmail returns, your email is
getting delivered, or you'll get a DSN.
Nullmailer does.
Package: wnpp
Severity: wishlist
Owner: Janos Guljas ja...@janos.in.rs
* Package name: python-django-squeeze
Version : 0+git20090142
Upstream Author : Artiom Diomin kro...@gmail.com
* URL : http://github.com/kron4eg/django-squeeze/tree
* License : BSD
On Mon, 04 May 2009 19:07:18 +0200, Raphael Hertzog hert...@debian.org
wrote:
On Fri, 01 May 2009, Jiří Paleček wrote:
should
almost never happen (except diversion) and the result when it happens
is
Should I read it as the only legal situation where it returns multiple
packages are
On Thu, May 07, 2009 at 12:14:42AM +0200, martin f krafft wrote:
also sprach Joerg Jaspert jo...@debian.org [2009.05.07.0002 +0200]:
As much as i like postfix and hate exim: no. If we change, please
go to something like nullmailer|ssmtp|whateversimple.
Correct me if I am wrong, but I think
Janos Guljas wrote:
Please package this very handy application.
Do you intend to package it, or do you want somebody else to package it? If the
latter, this should be an RFP and not an ITP:
http://www.debian.org/devel/wnpp/
Cheers,
Emilio
signature.asc
Description: OpenPGP digital signature
Peter Samuelson pe...@p12n.org writes:
Also, this procedure would be much more reliable if we said, in
Policy, that maintainer scripts are not allowed to fail if /usr is not
writable. (mount -o ro, SELinux, chattr +i, NFS root_squash,
whatever.)
Would you support that policy? I suspect
On May 06, Josselin Mouette j...@debian.org wrote:
Given that the default configuration is extremely simplistic and doesn???t
use a percent of either exim or postfix features, I still wonder why it
is not something like nullmailer or ssmtp.
Because it's expected from a UNIX system to be able
On Thu, May 07, 2009 at 03:24:13AM +0200, Marco d'Itri wrote:
On May 06, Josselin Mouette j...@debian.org wrote:
Given that the default configuration is extremely simplistic and doesn???t
use a percent of either exim or postfix features, I still wonder why it
is not something like
Quoting Josselin Mouette (j...@debian.org):
Where do we draw the line for “most situations”? If you want to do
serious email work, you’ll have to spend some time configuring your
exim/postfix and install extra components to run with it. If you don’t,
a trivial configuration will do the trick,
Quoting John Goerzen (jgoer...@complete.org):
So I think the problem here is not that you made a technically bad
decision. It sounds like you made a good decision. It's how it was
communicated.
I guess that, in some way, the glibc maintainers wanted to save us
from a probably very long and
John Goerzen wrote:
Julien BLACHE wrote:
John Goerzen jgoer...@complete.org wrote:
Hi,
I, for one, have heard just about enough of Hey developers, we're doing
$FOO, and it's already been decided, so put up or shut up from people.
I'd like a little bit more along the lines of Hey
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.8
Date: Wed, 06 May 2009 15:43:35 +1000
Source: debian-maintainers
Binary: debian-maintainers
Architecture: source all
Version: 1.58
Distribution: unstable
Urgency: medium
Maintainer: Debian Maintainer Keyring Team
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.8
Date: Sun, 03 May 2009 12:05:51 +0200
Source: freebsd-manpages
Binary: freebsd-manpages
Architecture: source all
Version: 7.2-1
Distribution: unstable
Urgency: low
Maintainer: Gürkan Sengün gur...@phys.ethz.ch
Changed-By: Gürkan Sengün
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.8
Date: Wed, 06 May 2009 09:03:20 +0200
Source: freebsd-buildutils
Binary: freebsd-buildutils
Architecture: source amd64
Version: 7.2-1
Distribution: unstable
Urgency: low
Maintainer: Aurelien Jarno aure...@debian.org
Changed-By: Aurelien
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.8
Date: Mon, 04 May 2009 21:43:57 +0200
Source: tulip
Binary: tulip tlprender tulip-doc libtulip-3.1 libtulip-dev libtulip-ogl-3.1
libtulip-ogl-dev libtulip-qt4-3.1 libtulip-qt4-dev libtulip-pluginsmanager-3.1
libtulip-pluginsmanager-dev
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.8
Date: Wed, 06 May 2009 15:18:46 +0900
Source: ecasound2.2
Binary: ecasound libecasound2.2-dev libkvutils2.2-dev python-ecasound2.2
libecasound-ruby1.8 libecasoundc2.2-dev ecasound-el
Architecture: source all amd64
Version: 2.6.0-1
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.8
Date: Wed, 06 May 2009 15:19:54 +0900
Source: whizzytex
Binary: whizzytex
Architecture: source all
Version: 1.3.1-4
Distribution: unstable
Urgency: low
Maintainer: Junichi Uekawa dan...@debian.org
Changed-By: Junichi Uekawa
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.8
Date: Wed, 06 May 2009 11:22:45 +0200
Source: lp-solve
Binary: lp-solve lp-solve-doc liblpsolve55-dev
Architecture: source amd64 all
Version: 5.5.0.13-5
Distribution: unstable
Urgency: low
Maintainer: Juan Esteban Monsalve Tobon
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.8
Date: Wed, 06 May 2009 19:15:17 +0900
Source: ttf-hanazono
Binary: ttf-hanazono
Architecture: source all
Version: 20090506-1
Distribution: unstable
Urgency: low
Maintainer: Nobuhiro Iwamatsu iwama...@nigauri.org
Changed-By: Nobuhiro
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.8
Date: Wed, 06 May 2009 12:02:59 +0200
Source: sane-backends
Binary: sane-utils libsane libsane-dev libsane-dbg
Architecture: source amd64
Version: 1.0.20-2
Distribution: unstable
Urgency: low
Maintainer: Julien BLACHE jbla...@debian.org
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.8
Date: Wed, 06 May 2009 13:46:20 +0200
Source: busybox
Binary: busybox busybox-static busybox-udeb
Architecture: source i386
Version: 1:1.13.3-1
Distribution: unstable
Urgency: low
Maintainer: Debian Install System Team
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.8
Date: Wed, 06 May 2009 13:56:04 +0200
Source: mklibs
Binary: mklibs mklibs-copy
Architecture: source all i386
Version: 0.1.27
Distribution: unstable
Urgency: low
Maintainer: Debian Install System Team debian-b...@lists.debian.org
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.8
Date: Wed, 06 May 2009 09:19:49 +0200
Source: libwmf
Binary: libwmf0.2-7 libwmf-bin libwmf-dev libwmf-doc
Architecture: source amd64 all
Version: 0.2.8.4-6.1
Distribution: unstable
Urgency: high
Maintainer: Loic Minier l...@dooz.org
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.8
Date: Wed, 06 May 2009 14:21:17 +0200
Source: sane-backends-extras
Binary: libsane-extras libsane-extras-dev libsane-extras-dbg
Architecture: source amd64
Version: 1.0.20.1
Distribution: unstable
Urgency: low
Maintainer: Julien BLACHE
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.8
Date: Wed, 06 May 2009 14:19:18 +0200
Source: debian-xcontrol
Binary: debian-xcontrol
Architecture: source amd64
Version: 0.0.4-1
Distribution: unstable
Urgency: low
Maintainer: Simon Richter s...@debian.org
Changed-By: Simon Richter
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.8
Date: Mon, 04 May 2009 15:09:36 +0200
Source: libio-socket-inet6-perl
Binary: libio-socket-inet6-perl
Architecture: source all
Version: 2.54-1.1
Distribution: unstable
Urgency: low
Maintainer: Masahito Omote om...@debian.org
Changed-By:
1 - 100 of 148 matches
Mail list logo
