* Nathanael Nerode:
While on new installs it looks like this:
--
# This is a list of hotpluggable network interfaces.
# They will be activated automatically by the hotplug subsystem.
And, as discussed before, this doesn't work reliably on all
systems. 8-(
--
To UNSUBSCRIBE, email
Florian Weimer schrieb:
* Nathanael Nerode:
While on new installs it looks like this:
--
# This is a list of hotpluggable network interfaces.
# They will be activated automatically by the hotplug subsystem.
And, as discussed before, this doesn't work reliably on all
systems. 8-(
Bastian Venthur wrote:
I've written a bugreport (#403706) which was discussed for a long time
until it finally was downgraded from grave to important and became a
documentation issue the for release-notes.
A questionable move especially since I know from debian-user-german that
many users
Nathanael Nerode wrote:
(I would add this to the Wiki page
http://wiki.debian.org/Sarge2EtchUpgrade but someone made it immutable...)
Seems editable here..
#1.
Just noticed that /etc/network/interfaces is set up differently on new
installs;
it uses udev/hotplug now by default, while it
On Mon, Mar 26, 2007 at 12:30:30AM -0400, Nathanael Nerode wrote:
(I would add this to the Wiki page
http://wiki.debian.org/Sarge2EtchUpgrade but someone made it immutable...)
The information you posted belongs to release-notes's BTS, not to the wiki
(as the wiki tries to track a sarge-etch
On Mon, Mar 26, 2007 at 10:45:46AM +0200, Javier Fernández-Sanguino Peña wrote:
On Mon, Mar 26, 2007 at 12:30:30AM -0400, Nathanael Nerode wrote:
(I would add this to the Wiki page
http://wiki.debian.org/Sarge2EtchUpgrade but someone made it immutable...)
The information you posted
On 3/26/07, Nathanael Nerode [EMAIL PROTECTED] wrote:
(I would add this to the Wiki page
http://wiki.debian.org/Sarge2EtchUpgrade but someone made it immutable...)
It's not immutable when you log in.
--
Andrew Donnellan
ajdlinuxATgmailDOTcom (primary)ajdlinuxATexemailDOTcomDOTau (secure)
Santiago == Santiago Vila [EMAIL PROTECTED] writes:
Santiago Why don't you just keep your RTC to UTC? It worked for
Santiago me.
It breaks if you need to dual boot to a competing operating system and
keep track of times. Hmmm. What was it called again? I think it was
this Windows
On Mar 26, Bastian Venthur [EMAIL PROTECTED] wrote:
I've written a bugreport (#403706) which was discussed for a long time
until it finally was downgraded from grave to important and became a
documentation issue the for release-notes.
Hopefully for lenny we will switch to upstart, which will
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,
Holger Levsen [EMAIL PROTECTED] writes:
Hi,
On Friday 23 March 2007 13:54, Goswin von Brederlow wrote:
We still have no usable linux-source deb. The prepatched source
currently shipped will not build vserver, xen and several archs and
the debian patch is not compatible to make-kpkg and it
Hello,
when installing a Debian etch machine, the installation system
automatically selects the kernel which is most appropriate for the CPU
and installs the corresponding kernel package on the harddisk of the
machine.
Can anybody tell me how the installer decides which kernel to be
installed?
On Monday 26 March 2007 17:24, Christoph Pleger wrote:
Can anybody tell me how the installer decides which kernel to be
installed? Or tell me where I can find the source code of the selection
process?
It is done from the /var/lib/dpkg/base-installer.postinst script, which
calls an
IIRC, the kernel udeb in the installer image runs the installer kernel during
installation and the installer checks for the CPU type.
You can use the 'expert' install option to be given the opportunity to
manually select which kernel is installed during installation.
- Lawrence
On March 26,
On Mon, 26 Mar 2007, Joey Hess wrote:
Nathanael Nerode wrote:
[...]
On old installs it looks like this:
# The first network card - this entry was created during the Debian installation
auto eth0
iface eth0 inet dhcp
-
While on new installs it looks like this:
--
#
Hi,
I have spent the past few days trying to figure out why some of our
machines seem to have ethernet interface numbers that jump around --
eth0 one day, then eth4 or eth5 another.
The culprit comes down to udev. I've filed a bug #416284 against it for
this.
Basically, udev is trying to
On Monday 26 March 2007 10:11, John Goerzen wrote:
I have spent the past few days trying to figure out why some of our
machines seem to have ethernet interface numbers that jump around --
eth0 one day, then eth4 or eth5 another.
As a corollary to this, I have machines where the disks swap
John Goerzen [EMAIL PROTECTED] writes:
I have spent the past few days trying to figure out why some of our
machines seem to have ethernet interface numbers that jump around --
eth0 one day, then eth4 or eth5 another.
The culprit comes down to udev. I've filed a bug #416284 against it for
* Russ Allbery:
There's actually some stuff in udev or some related package to deal with
this, but I can't ever seem to find it when I need it. I think this is
actually a documentation bug more than a functionality bug; we just need a
better guide on how to do it. You can, somehow, assign
Joey Hess schrieb:
Bastian Venthur wrote:
I've written a bugreport (#403706) which was discussed for a long time
until it finally was downgraded from grave to important and became a
documentation issue the for release-notes.
A questionable move especially since I know from debian-user-german
On Mar 26, John Goerzen [EMAIL PROTECTED] wrote:
I think that the right thing to do is to assign the persistent names to
network devices that still exist in the system, but to do nothing with
any other network devices. That will allow systems to still boot and
come up properly in the face of
On Mon, Mar 26, 2007 at 07:35:39PM +0200, Marco d'Itri wrote:
On Mar 26, John Goerzen [EMAIL PROTECTED] wrote:
I think that the right thing to do is to assign the persistent names to
network devices that still exist in the system, but to do nothing with
any other network devices. That
Hello Milan,
Milan P. Stanic [EMAIL PROTECTED] wrote:
On Sun, Mar 04, 2007 at 06:36:34PM +0530, Ganesan Rajagopal wrote:
Milan P Stanic [EMAIL PROTECTED] writes:
I'd like to discuss problem with regards to bug #372665.
Why the racoon should be started in the rcS when even ssh is not?
On Mon, Mar 26, 2007 at 12:42:54 -0500, John Goerzen wrote:
On Mon, Mar 26, 2007 at 07:35:39PM +0200, Marco d'Itri wrote:
On Mar 26, John Goerzen [EMAIL PROTECTED] wrote:
I think that the right thing to do is to assign the persistent names to
network devices that still exist in the
I tried building using make-kpkg with --initrd binary options, and ended up
with a cpio archive. Why? I have no idea.
I looked at the output of the make-kpkg command and was unable to determine
which tool it was using to make the initramfs. I suggest some output be
generated that shows not only
Am Montag 26 März 2007 19:26 schrieb Florian Weimer:
* Russ Allbery:
There's actually some stuff in udev or some related package to deal with
this, but I can't ever seem to find it when I need it. I think this is
actually a documentation bug more than a functionality bug; we just need
a
* Julien Cristau:
I think the problem is that you can't know in advance whether the device
still exists or not, and whether it will be plugged in later (because
everything runs asynchronously).
Sure, but hotpluggable PCI(e) interfaces are the exception, not the
norm. It seems wrong to
On Monday 26 March 2007 12:09, Alan Ezust wrote:
I tried building using make-kpkg with --initrd binary options, and ended
up with a cpio archive. Why? I have no idea.
An initramfs is a cpio archive.
I am assuming that are you referring to the file created after the kernel is
installed. Is
On Mon, Mar 26, 2007 at 08:15:30PM +0200, Florian Weimer wrote:
Sure, but hotpluggable PCI(e) interfaces are the exception, not the
norm. It seems wrong to optimize for this case.
udev sees network devices, not pci devices. and hotpluggable network
devices are common.
Bastian
--
A woman
On Mon, Mar 26, 2007 at 08:28:02PM +0200, Bastian Blank wrote:
On Mon, Mar 26, 2007 at 08:15:30PM +0200, Florian Weimer wrote:
Sure, but hotpluggable PCI(e) interfaces are the exception, not the
norm. It seems wrong to optimize for this case.
udev sees network devices, not pci devices.
On Mon, Mar 26, 2007 at 07:54:45PM +0200, Hendrik Sattler wrote:
The trouble is that nowadays, the kernel does not assign predictable
interface names, and an increasing number of systems has got more than
one Ethernet interface. The downside is that typical Debian
installations aren't
Yes, I'm referring to the initrd.img-2.6.16.XX-bla-di-blah file that is
installed by dpkg when I install the generated kernel-image .deb file that I
created using make-kpkg (--initrd binary)..
On 3/26/07, Warren Turkal [EMAIL PROTECTED] wrote:
On Monday 26 March 2007 12:09, Alan Ezust wrote:
On Mon, Mar 26, 2007 at 01:41:26PM -0500, John Goerzen wrote:
On Mon, Mar 26, 2007 at 07:54:45PM +0200, Hendrik Sattler wrote:
You only need to delete /etc/udev/rules.d/z25_persistent*.rules before udev
runs. That should be doable and could be a configuration option. The
default
* Bastian Blank:
On Mon, Mar 26, 2007 at 08:15:30PM +0200, Florian Weimer wrote:
Sure, but hotpluggable PCI(e) interfaces are the exception, not the
norm. It seems wrong to optimize for this case.
udev sees network devices, not pci devices. and hotpluggable network
devices are common.
It
Il giorno 26/mar/07, alle ore 21:29, Mark Brown ha scritto:
The use cases where users are likely to notice are relatively
limited -
you need to either be trying to do some sort of system imaging or
doing
hardware replacement where you need to do a like for like swap. The
latter case tends
On Mon, 2007-03-26 at 00:04 -0400, Mark Eichin wrote:
I certainly have seen lots of packages build correctly with fakechroot
as-shipped - and these fixes should significantly raise that number.
The more people that use fakechroot the better, but I suppose the thing
that scares me a little is
On Mon, Mar 26, 2007 at 11:11:32PM +0200, Luigi Gangitano wrote:
1. Some ethernet cards like Sun QuadFE share the same MAC address
(even if global OpenFirmware option is set to different MAC-address)
and PCI id and udev blocks while renaming them, leaving with an
unusable systema each
Ah, I see. the initrd is created at install time, not at .deb package
building time.
I inspected the generated .deb file and indeed, there is no initrd.img in
the .deb file - the initrd is created when you actually install the package
on the target system, which means it's the target system that
Hi John!
On Mon, 26 Mar 2007, John Goerzen wrote:
On Mon, Mar 26, 2007 at 08:28:02PM +0200, Bastian Blank wrote:
On Mon, Mar 26, 2007 at 08:15:30PM +0200, Florian Weimer wrote:
Sure, but hotpluggable PCI(e) interfaces are the exception, not the
norm. It seems wrong to optimize for this
Florian Weimer [EMAIL PROTECTED] writes:
* Russ Allbery:
There's actually some stuff in udev or some related package to deal
with this, but I can't ever seem to find it when I need it. I think
this is actually a documentation bug more than a functionality bug; we
just need a better guide on
On Mon, Mar 26, 2007 at 11:11:32PM +0200, Luigi Gangitano wrote:
BTW, there's no easy way to recover from a badly renamed ethernet interface.
Once you have something like 'eth5_rename' how are you supposed to recover?
As you would do for a normal interface rename:
ip link set
Heya,
As a corollary to this, I have machines where the disks swap device files on
each boot. It's pretty annoying when my nfs volumes switch which device name
is used to mount them.
you could mount them by UUID instead of the device name.
Bernd
--
Bernd Zeimetz
[EMAIL PROTECTED]
On Mon, Mar 26, 2007 at 01:40:14PM -0500, John Goerzen wrote:
Still the exception, not the norm.
No, ever since distros started using modular kernels, hotplug _is_ the
norm. You can get rid of it only by building your own kernel image with
all hardware drivers statically built in and module
On Tue, Mar 27, 2007 at 12:00:05AM +0200, Bernd Zeimetz wrote:
you could mount them by UUID instead of the device name.
Btw. do Debian initrds already support specifying the root fs with
LABEL= like Fedora/RedHat?
Gabor
--
-
On Mon, Mar 26, 2007 at 01:41:26PM -0500, John Goerzen wrote:
On Mon, Mar 26, 2007 at 07:54:45PM +0200, Hendrik Sattler wrote:
The trouble is that nowadays, the kernel does not assign predictable
interface names, and an increasing number of systems has got more than
one Ethernet
On Mon, Mar 26, 2007 at 11:11:04AM -0500, John Goerzen wrote:
* dmesg output still mentions hardware using eth0, even if you can't
talk to it at eth0 but must instead use eth5. dmesg doesn't
mention this fact, making it difficult to track down problems.
It's nothing new, this is the
On Mon, Mar 26, 2007 at 05:05:53PM +, Jörg Sommer wrote:
Milan P. Stanic [EMAIL PROTECTED] wrote:
README says that in the /etc/rcS.d/ should go scripts which are
executed once during boot. In debian policy manual rcS.d is
mentioned only once in section 9.3.4, but from short description
Btw. do Debian initrds already support specifying the root fs with
LABEL= like Fedora/RedHat?
Didn't try it, but according to [1] they do.
Cheers,
Bernd
[1] http://wiki.debian.org/InitrdReplacementOptions
--
Bernd Zeimetz
[EMAIL PROTECTED] http://bzed.de/
--
I demand that Luigi Gangitano may or may not have written...
[snip]
1. Some ethernet cards like Sun QuadFE share the same MAC address (even if
global OpenFirmware option is set to different MAC-address) and PCI id and
udev blocks while renaming them, leaving with an unusable systema each time
Hello Milan,
Milan P. Stanic [EMAIL PROTECTED] wrote:
On Mon, Mar 26, 2007 at 05:05:53PM +, Jörg Sommer wrote:
Milan P. Stanic [EMAIL PROTECTED] wrote:
README says that in the /etc/rcS.d/ should go scripts which are
executed once during boot. In debian policy manual rcS.d is
mentioned
I've been reading the discussion and trying to thresh something out of it.
Four points and one proposal.
Point 1.
---
Contrary to some assumptions, answering I got your bug report but I can't deal
with it right now is *very* useful, particularly in encouraging people to help.
I've reported
On Mon, Mar 26, 2007 at 09:12:32PM -0400, Nathanael Nerode wrote:
If a package has a bug with a *patch* attached, where the *patch* has not
been reviewed on by the maintainer(s) within six months, the package will
be orphaned immediately; the maintainer will not be allowed to adopt it
Nathanael Nerode [EMAIL PROTECTED] writes:
Actually, after describing the worst-case scenario, I am going to make a
new tentative proposal:
If a package has a bug with a *patch* attached, where the *patch* has
not been reviewed on by the maintainer(s) within six months, the package
Nathanael Nerode [EMAIL PROTECTED] writes:
I've been reading the discussion and trying to thresh something out
of it.
Thanks very much for taking the time to do this. A summary of a long
thread is useful.
Four points and one proposal.
I agree with all the points.
I won't comment on the
Russ Allbery [EMAIL PROTECTED] writes:
If no one has time to work on a package, orphaning the package
doesn't make it better.
In that case, orphaning the package doesn't make it better.
I think Nathaniel was describing the case where people *do* have the
time, and indeed are proposing fixes
Roberto C. Sánchez [EMAIL PROTECTED] wrote:
Out of curiousity, what is the algorithm for determining whether a patch
has been reviewed? If it is not an algorithm, per se, then what is the
heuristic?
If the maintainer has sent a message to the bug trail mentioning the patch
sometime after the
Ben Finney [EMAIL PROTECTED] writes:
Russ Allbery [EMAIL PROTECTED] writes:
If that person has showed up and is being blocked from helping for some
reason, *then* we can talk.
I think that's what the proposal is suggesting. Do you think the metric
used is bad, or is there some other flaw?
Jörg == Jörg Sommer [EMAIL PROTECTED] writes:
Can't raccon be started like wpa_supplicant by an ifup command? You can
start the wpa_supplicant by bringing up the interface:
,[ /etc/network/interfaces ]---
| iface eth1 inet manual
| wpa_roam /etc/wpa_supplicant.conf
|
After writing a very long message, I realize that there was a much simpler
solution, so if you want to cut to the chase, skip to the end!
Steve Langasek wrote:
Which do you think is the common case -- a system with more than one network
interface where it's necessary to preserve interface
On Tue, Mar 27, 2007 at 12:01:13AM +0200, Gabor Gombas wrote:
No, ever since distros started using modular kernels, hotplug _is_ the
norm.
debian (and other distros) used modular kernels (2.4.18 in woody)
without hotplug or the like.
You can get rid of it only by building your own kernel
On Tue, Mar 27, 2007 at 12:06:09AM -0400, Nathanael Nerode wrote:
After writing a very long message, I realize that there was a much simpler
solution, so if you want to cut to the chase, skip to the end!
Steve Langasek wrote:
Which do you think is the common case -- a system with more than
On Tue, Mar 27, 2007 at 06:39:55AM +0200, NN_il_Confusionario wrote:
On Tue, Mar 27, 2007 at 12:01:13AM +0200, Gabor Gombas wrote:
No, ever since distros started using modular kernels, hotplug _is_ the
norm.
debian (and other distros) used modular kernels (2.4.18 in woody)
without hotplug
On Tue, Mar 27, 2007 at 12:06:09AM -0400, Nathanael Nerode [EMAIL PROTECTED]
wrote:
After writing a very long message, I realize that there was a much simpler
solution, so if you want to cut to the chase, skip to the end!
Steve Langasek wrote:
Which do you think is the common case -- a
On Mon, Mar 26, 2007 at 09:38:24PM -0400, Roberto C. Sánchez [EMAIL
PROTECTED] wrote:
People should be given assistance and encouragement in
doing it. I actually like doing it, but I have unfortunately relatively
little time (sick family members).
I like doing bug triage as well. I
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Sat, 24 Mar 2007 14:07:27 +0100
Source: kdebluetooth
Binary: kdebluetooth-irmcsync qobex kdebluetooth
Architecture: source i386
Version: 0.99+1.0beta2-4
Distribution: unstable
Urgency: low
Maintainer: Michael Meskes [EMAIL PROTECTED]
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Mon, 26 Mar 2007 09:52:10 +0200
Source: clanlib
Binary: libclan2c2a-network libclan2c2a-lua libclan2c2a-gui clanlib-doc
libclan2c2a-vorbis clanlib-examples libclanlib2c2a libclan2c2a-png
libclan2c2a-sound libclan2c2a-jpeg
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Mon, 26 Mar 2007 08:12:17 +0200
Source: linux-2.6
Binary: linux-image-2.6.18-4-powerpc-miboot linux-headers-2.6.18-4-parisc-smp
linux-modules-2.6.18-4-xen-vserver-amd64 linux-headers-2.6.18-4-vserver-amd64
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Mon, 26 Mar 2007 10:16:03 +0200
Source: eazel-engine
Binary: gtk-engines-eazel
Architecture: source amd64
Version: 0.3-6
Distribution: unstable
Urgency: low
Maintainer: Debian QA Group [EMAIL PROTECTED]
Changed-By: Michael
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Mon, 26 Mar 2007 15:06:46 +0200
Source: noffle
Binary: noffle
Architecture: source amd64
Version: 1.2.0~rc1-6
Distribution: unstable
Urgency: low
Maintainer: Debian QA Group [EMAIL PROTECTED]
Changed-By: Michael Ablassmeier [EMAIL
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Mon, 26 Mar 2007 15:12:43 +0200
Source: laptop-netconf
Binary: laptop-netconf
Architecture: source amd64
Version: 0.9.6.7
Distribution: unstable
Urgency: low
Maintainer: Debian QA Group [EMAIL PROTECTED]
Changed-By: Michael
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Mon, 26 Mar 2007 11:59:51 +0900
Source: ptex-jtex
Binary: ptex-jtex
Architecture: source all
Version: 1.7+1-10
Distribution: experimental
Urgency: low
Maintainer: Atsuhito KOHDA [EMAIL PROTECTED]
Changed-By: Atsuhito KOHDA [EMAIL
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Fri, 23 Mar 2007 22:43:48 +0100
Source: ffmpeg
Binary: libavformat-dev libavformat0d ffmpeg libavcodec-dev libpostproc0d
libpostproc-dev libavcodec0d
Architecture: source i386
Version: 0.cvs20060823-8
Distribution: unstable
Urgency:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Mon, 26 Mar 2007 15:34:12 +0200
Source: gnome-pkg-tools
Binary: gnome-pkg-tools
Architecture: source all
Version: 0.11
Distribution: unstable
Urgency: low
Maintainer: Debian GNOME Maintainers [EMAIL PROTECTED]
Changed-By: Loic Minier
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Mon, 26 Mar 2007 15:06:40 +0200
Source: libssh
Binary: libssh-2-dev libssh-2-dbg libssh-2
Architecture: source i386
Version: 0.2+svn20070321-1
Distribution: unstable
Urgency: low
Maintainer: Jean-Philippe Garcia Ballester [EMAIL
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Mon, 26 Mar 2007 16:51:00 +0100
Source: dwm
Binary: dwm
Architecture: source i386
Version: 3.8-4
Distribution: unstable
Urgency: low
Maintainer: Daniel Baumann [EMAIL PROTECTED]
Changed-By: Daniel Baumann [EMAIL PROTECTED]
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Mon, 26 Mar 2007 13:54:25 +0530
Source: xmms-crossfade
Binary: bmp-crossfade audacious-crossfade xmms-crossfade
Architecture: source i386
Version: 0.3.12-1
Distribution: unstable
Urgency: low
Maintainer: Kartik Mistry [EMAIL
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Fri, 23 Mar 2007 13:47:15 +0100
Source: boost
Binary: libboost-signals1.34.0 libboost-wave-dev libboost-iostreams-dev
libboost-test-dev libboost-test1.34.0 libboost-filesystem1.34.0
libboost-serialization-dev libboost-regex1.34.0
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Mon, 26 Mar 2007 17:49:14 +0200
Source: libgnomekbd
Binary: libgnomekbd-common libgnomekbdui-dev libgnomekbdui1 libgnomekbd-dev
gkbd-capplet libgnomekbd1
Architecture: source i386 all
Version: 2.18.0-1
Distribution: experimental
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Mon, 26 Mar 2007 11:07:17 -0500
Source: latex2rtf
Binary: latex2rtf-doc latex2rtf
Architecture: source amd64 all
Version: 1.9.16a-3
Distribution: unstable
Urgency: low
Maintainer: Chris Lawrence [EMAIL PROTECTED]
Changed-By: Chris
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Thu, 8 Mar 2007 22:10:31 +0100
Source: fuse
Binary: libfuse2 libfuse-dev fuse-utils
Architecture: source i386
Version: 2.6.3-2
Distribution: unstable
Urgency: low
Maintainer: Bartosz Fenski [EMAIL PROTECTED]
Changed-By: Adam Cécile
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Mon, 26 Mar 2007 18:02:46 +0200
Source: gnome-user-docs
Binary: gnome-user-guide
Architecture: source all
Version: 2.18.0-1
Distribution: experimental
Urgency: low
Maintainer: Jose Carlos Garcia Sogo [EMAIL PROTECTED]
Changed-By:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Mon, 26 Mar 2007 18:51:27 +0200
Source: postgresql-common
Binary: postgresql-client-common postgresql-common
Architecture: source all
Version: 73
Distribution: unstable
Urgency: low
Maintainer: Martin Pitt [EMAIL PROTECTED]
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Mon, 26 Mar 2007 10:55:15 -0600
Source: postfix
Binary: postfix-pcre postfix postfix-pgsql postfix-doc postfix-ldap postfix-cdb
postfix-dev postfix-mysql
Architecture: all i386 source
Version: 2.4.0~rc9-1
Distribution: experimental
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Mon, 26 Mar 2007 18:53:19 +0100
Source: ekg
Binary: ekg libgadu3 libgadu-dev
Architecture: source i386
Version: 1:1.7~rc2-2
Distribution: unstable
Urgency: high
Maintainer: Marcin Owsiany [EMAIL PROTECTED]
Changed-By: Marcin Owsiany
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Fri, 23 Mar 2007 13:06:57 +0100
Source: newsbeuter
Binary: newsbeuter
Architecture: source i386
Version: 0.3-1
Distribution: unstable
Urgency: low
Maintainer: Nico Golde [EMAIL PROTECTED]
Changed-By: Nico Golde [EMAIL PROTECTED]
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Mon, 26 Mar 2007 08:01:54 -0500
Source: quantlib-swig
Binary: quantlib-ruby quantlib-python
Architecture: source i386
Version: 0.4.1-1
Distribution: unstable
Urgency: low
Maintainer: Dirk Eddelbuettel [EMAIL PROTECTED]
Changed-By:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Mon, 26 Mar 2007 18:57:14 +0100
Source: kdelibs
Binary: kdelibs4c2a kdelibs kdelibs4-doc kdelibs-dbg kdelibs-data kdelibs4-dev
Architecture: source i386 all
Version: 4:3.5.5a.dfsg.1-7
Distribution: unstable
Urgency: high
Maintainer:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Mon, 26 Mar 2007 13:27:51 +0200
Source: ion3-scripts
Binary: ion3-scripts
Architecture: source all
Version: 20061214-2
Distribution: unstable
Urgency: low
Maintainer: Debian QA Group [EMAIL PROTECTED]
Changed-By: Norbert Tretkowski
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Mon, 26 Mar 2007 21:22:07 +0200
Source: newsbeuter
Binary: newsbeuter
Architecture: source i386
Version: 0.3-2
Distribution: unstable
Urgency: low
Maintainer: Nico Golde [EMAIL PROTECTED]
Changed-By: Nico Golde [EMAIL PROTECTED]
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Mon, 26 Mar 2007 21:18:46 +0200
Source: pyblosxom
Binary: pyblosxom
Architecture: source all
Version: 1.3.2-6
Distribution: unstable
Urgency: low
Maintainer: Norbert Tretkowski [EMAIL PROTECTED]
Changed-By: Norbert Tretkowski [EMAIL
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Mon, 26 Mar 2007 11:49:17 -0600
Source: libembperl-perl
Binary: libembperl-perl
Architecture: source i386
Version: 2.2.0-1.2
Distribution: unstable
Urgency: high
Maintainer: Angus Lees [EMAIL PROTECTED]
Changed-By: Gunnar Wolf [EMAIL
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Mon, 26 Mar 2007 21:37:24 +0200
Source: gaim-thinklight
Binary: gaim-thinklight
Architecture: source i386
Version: 0.7-1
Distribution: unstable
Urgency: low
Maintainer: Joachim Breitner [EMAIL PROTECTED]
Changed-By: Joachim Breitner
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Mon, 26 Mar 2007 22:07:35 +0200
Source: ion3-mod-ionflux
Binary: ion3-mod-ionflux
Architecture: source i386
Version: 20061022-4
Distribution: unstable
Urgency: low
Maintainer: Debian QA Group [EMAIL PROTECTED]
Changed-By: Norbert
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Mon, 26 Mar 2007 15:37:26 -0400
Source: maxima
Binary: maxima-test maxima-share maxima-emacs maxima-doc maxima-src xmaxima
maxima
Architecture: source all i386
Version: 5.11.0-1
Distribution: unstable
Urgency: low
Maintainer: Camm
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Mon, 26 Mar 2007 22:27:08 +0200
Source: metacity
Binary: metacity-common metacity libmetacity0 libmetacity-dev
Architecture: source i386 all
Version: 1:2.18.0-1
Distribution: experimental
Urgency: low
Maintainer: Marco Cabizza [EMAIL
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Mon, 26 Mar 2007 22:31:24 +0200
Source: cdrkit
Binary: cdda2wav mkisofs cdrkit-doc genisoimage cdrecord wodim icedax
Architecture: source all amd64
Version: 9:1.1.3-1
Distribution: unstable
Urgency: medium
Maintainer: Joerg Jaspert
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Mon, 26 Mar 2007 17:18:58 +
Source: openmsx
Binary: openmsx openmsx-data
Architecture: source i386 all
Version: 0.6.2~pre2-1
Distribution: experimental
Urgency: low
Maintainer: Joost Yervante Damad [EMAIL PROTECTED]
Changed-By:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Mon, 26 Mar 2007 15:40:10 +0100
Source: gcc-snapshot
Binary: gcc-snapshot
Architecture: source amd64
Version: 20070326-1
Distribution: unstable
Urgency: low
Maintainer: Debian GCC Maintainers debian-gcc@lists.debian.org
Changed
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Sun, 25 Mar 2007 22:40:37 +0200
Source: lwat
Binary: lwat
Architecture: source all
Version: 0.13-2
Distribution: unstable
Urgency: high
Maintainer: Patrick Winnertz [EMAIL PROTECTED]
Changed-By: Patrick Winnertz [EMAIL PROTECTED]
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Mon, 26 Mar 2007 16:00:39 -0400
Source: fish
Binary: fish
Architecture: source i386
Version: 1.22.3-1
Distribution: unstable
Urgency: low
Maintainer: James Vega [EMAIL PROTECTED]
Changed-By: James Vega [EMAIL PROTECTED]
Description:
1 - 100 of 119 matches
Mail list logo
