Package: syslog-ng
Dec 1 01:57:22 somehost syslog-ng[314]: STATS: dropped 1
Huh?
STATS this is merely a statistic, not a serious error condition???
dropped 1? One what? One packet (obvious thing computers dropped)?
One message? One bar of soap?
What the heck is causing multiple messages like
Package: installation-reports
uname -a: Linux battlefield 2.4.28p1-battlefield-3 #1 SMP Tue Apr 5 17:33:41
PDT 2005 i686 unknown
Debian-installer-version: sarge-rc3-cdimage-netinst (30 Mar 2005)
Date: Sat Apr 1 15:00:00 PDT 2005
Method: CDROM /dev/sr0 (aic7880u)
Machine: Intel PR440FX
Another problem, though minor, that I ran into. The graphics card on this
system was known to not be high-reliability. This isn't a major issue as
the system only needed a text console. I did notice that during
installation d-i tries to use international characters during language
selection. This
Is this truely a /grave/ bug with /lilo/?
Certainly you were able to use the force option, and LILO did its job;
this is annoying but not unusable. Certainly it didn't cause data loss.
The verbose flag told you what was going on, it had incorrectly detected
the presence of an NT FS. Is there
Package: mdadm
Version: 1.9.0-4
Severity: important
This was with the 20050322 Binary-1 minimal install CD, so the version
might now be right. This might also be considered a Debian-Installer
problem, or the RAID udeb...
When using alternative partitioning schemes (Sun disklabel here), the
Package: debian-installer
Version: 20050322
With the i386 Binary-1 20050322 install CD being used as rescue...
The installer *really* wants to claim swap partitions. In particular it
decided it needed to initialize a swap device and refused to do anything
else prior to initializing it. This was
Package: ifupdown
Version: 0.6.7
The postinst's behavior on creating /etc/network/run is, well, dreadful.
Falling back to saving runtime state in /etc is very bad as the root
filesystem may be read-only. /var/run seems a *far* superior fallback, as
it will be guarenteed to exist and be writable.
Package: dump
Version: 0.4b37-1
# ls -li
total 80
64566 -rw-r--r-- 5 root root 2196875759616 Dec 26 17:24 -f
64566 -rw-r--r-- 5 root root 2196875759616 Dec 26 17:24 -fr
64566 -rw-r--r-- 5 root root 2196875759616 Dec 26 17:24 -r
64566 -rw-r--r-- 5 root root 2196875759616 Dec 26 17:24 -rf
64566
Package: ucspi-tcp-src
Version: 0.88-9
Add a me too for this bug report. This is needed for any package which
depends on ucspi-tcp to support IPv6. Given the increasing prevailance of
packages supporting IPv6, I'd tend to call this a normal bug, not a
wishlist one. Documenting the absence of IPv6
Package: ucspi-tcp-src
Version: 0.88-9
Doh! Originally sent to the wrong bug (151550 vs 326415).
Add a me too for this bug report. This is needed for any package which
depends on ucspi-tcp to support IPv6. Given the increasing prevailance of
packages supporting IPv6, I'd tend to call this a
From: Eugene V. Lyubimkin [EMAIL PROTECTED]
Though, I think, severity of this bug can be downgraded (imho, to important)
if it show itself rarely. And it's very hard to fix, yes.
No.
Have you looked at how many reports there are of the MMap problem and how
old they are?
A quick browse found
In truth the problematic patch for LILO may have been introduced
substantially earlier. Mainly I just ran into something that looks
suspiciously like this bug in 1:22.6.1-9.3
More interesting story in my case, I've got a disk that is acting up
(unsure whether it is merely acting up versus
Package: tetex-base
Version: 3.0.dfsg.3-5etch1
Got the following when trying to install the latest:
Setting up tetex-base (3.0.dfsg.3-5etch1) ...
mktemp: cannot make temp dir /tmp/user/0/tmp.lVDrA16897: No such file or
directory
dpkg: error processing tetex-base (--configure):
subprocess
Package: libmailutils0
Version: 1:0.6.1-4sarge2
Severity: wishlist
Could we get a build of libmailutils that *doesn't* include the SQL
backends? In smaller environments, being able to remove SQL libraries is
a fairly sizable security improvement.
--
(\___(\___(\__ --= 8-) EHM =--
Severity: important
Sami Liedes isn't the only one running into this. Due to etch shipping
with a 2.6.18 kernel, I think this qualifies as important since lacking
the 2.6.18 version (which etch shipped with) of the patch effectively
renders this package useless.
For others running into this
Package: nvidia-glx
Version: 1.0.8776-4
Subject says it all. The init script for nvidia-glx attempts to write to
/usr, without checking for the possiblity of it being read-only. In such
a case it would seem a good idea for the script to check whether the
links are okay. If they are don't bother,
Package: samba-common
Version: 3.0.24-6etch1
Subject tells the story. Attempting to install samba-common with /tmp
mounted noexec fails. I suspect this is likely endemic throughout the
Samba packages, but have not confirmed this.
--
(\___(\___(\__ --= 8-) EHM =--
From: Steve Langasek [EMAIL PROTECTED]
On Sun, May 20, 2007 at 04:41:19PM -0700, Elliott Mitchell wrote:
Package: samba-common
Version: 3.0.24-6etch1
Subject tells the story.
Please post the error message you're getting.
Samba does not exec anything directly out of /tmp to my
Add a me to for the issue of wanting the qmail package broken apart.
For folks who aren't using POP, it is useful for stripping another
unneeded binary off the system. Thereby shrinking the system further.
--
(\___(\___(\__ --= 8-) EHM =-- __/)___/)___/)
\BS (|
Package: qmail-src
Version: 1.03-38
Sendmail definitely supports IPv6, and I strongly suspect Postfix does as
well. This makes Qmail the unusual one in /not/ supportting IPv6. Given
the increasing prevalence of support, I'd suggest either documenting the
lack of support or including the Qmail
Package: qmail-src
Version: 1.03-38
Qmail does not *require* procmail to operate correctly. First, it can be
used on a system that merely filters and forwards mail. In such a case a
mail-reader and mail-delivery program is unneeded. Second, maildir style
mailboxes can be used, which Qmail handles
From: Jon Marler [EMAIL PROTECTED]
Quoting Elliott Mitchell [EMAIL PROTECTED]:
Sendmail definitely supports IPv6, and I strongly suspect Postfix does as
well. This makes Qmail the unusual one in /not/ supportting IPv6. Given
the increasing prevalence of support, I'd suggest either
Package: syslog-ng
Version: 1.6.5-2.2
Severity: important
If /dev is read-only, syslog-ng will give the error message
syslog-ngio.c: bind_unix_socket(): bind failed /dev/log (Address already
in use). The relevant section from `ltrace -LSf`:
From: SZALAY Attila [EMAIL PROTECTED]
On Wed, 2005-09-07 at 00:02 -0700, Elliott Mitchell wrote:
If /dev is read-only, syslog-ng will give the error message
syslog-ngio.c: bind_unix_socket(): bind failed /dev/log (Address already
in use). The relevant section from `ltrace -LSf
Version: 0.2.15.9-2
Add a me too to bug #243451. Still definitely present in the
released/stable version of Aptitude. A possibly related symptom, when
getting the Y/N/D/Z prompt, 'Z' spawns a new shell rather than suspending
(close enough to do the job, but isn't quite the standard action).
This
Package: ssh
Version: 1:3.8.1p1-8.sarge.4
Turns out that if X11UseLocalhost is disabled, sshd will only bind to the
X11 port on one of the local IPv6 addresses (might bind to several, but I
haven't tested that), rather than ::/IN6ADDR_ANY_INIT. As a result
IPv4-only X clients *cannot* connect as
Package: aptitude
Version: 0.2.15.9-2
I'm doing a update from what is now oldstable to stable, using Aptitude's
interactive mode. There are a number of cases where Aptitude's dependancy
resolution likes to select packages that are unneeded. Sometimes these
selections even cause packages that were
From: Daniel Burrows [EMAIL PROTECTED]
On Wednesday 22 June 2005 02:08 am, Elliott Mitchell wrote:
I'm doing a update from what is now oldstable to stable, using Aptitude's
interactive mode. There are a number of cases where Aptitude's dependancy
resolution likes to select packages
From: Daniel Burrows [EMAIL PROTECTED]
On Wednesday 22 June 2005 07:30 pm, Elliott Mitchell wrote:
I don't know the code layout, so I can't comment on that.
The four cases are *very* real. I mentioned I was doing this over a
couple sessions. Pretty much I quit for the night
Package: e2fsprogs
Version: 1.37-2sarge1
`tune2fs` happily allows the creation of shared journals, and the kernel
I've got happily allows mounting of filesystems utilizing a shared
journal. OTOH `e2fsck` explodes when being run on such filesystems,
whether or not they're clean.
Documenting
From: Theodore Ts'o [EMAIL PROTECTED]
On Mon, Jun 27, 2005 at 10:42:10PM -0700, Elliott Mitchell wrote:
`tune2fs` happily allows the creation of shared journals, and the kernel
I've got happily allows mounting of filesystems utilizing a shared
journal. OTOH `e2fsck` explodes when being run
From: Manoj Srivastava [EMAIL PROTECTED] (va, manoj)
On Fri, 8 Jul 2005 19:08:38 -0700 (PDT), Elliott Mitchell [EMAIL PROTECTED]
said:
Besides the obvious me too, it might also be nice for DEB_DEST be
overridden either by the command line or environment variable
Package: initscripts
Version: 2.86.ds1-1
Severity: minor
The use of /forcefsck to force fsck to run on a clean filesystems is
problematic if / is read-only. Notably you must first remount /
read-write and create the file (yuck), the init scripts will be unable to
remove it, and you end up having
Package: kernel-package
Version: 8.135
Severity: wishlist
Tags: patch
I'll count this as wishlist due to the other tiny change here. The
default setting of KPKG_DEST_DIR is incorrect; it should be
$(SRCTOP)/$(DEB_DEST), not $(SRCTOP)/..
It would also be nice to change DEB_DEST, as such, the
Package: util-linux
Version: 2.12p-4sarge1
Looks like it is time for another Mad System Administrator bug(s):
The display of varying disk slice types is inconsistant. From what I can
tell, it appears that the unit display of MSDOS partitions reports end
sector-1, rather than end sector. In
Package: login
Version: 1:4.0.3-31sarge5
Enabling CLOSE_SESSIONS in /etc/login.defs prevents suspending of su'd
shells. Typing `suspend` into the shell simply hangs. Sending SIGCONT to
the shell gets it to resume, but access to the parent shell is never
obtained.
--
(\___(\___(\__
Package: chkrootkit
Version: 0.44-2
There are two serious failures in getCMD() inside `chkrootkit`.
First, the RUNNING=... will only give a string if the program is running
at the time. A test might be run for a daemon that isn't installed. Even
if the daemon is present, it might not be
Package: libnss-db
Version: 2.2-6
Severity: important
Other than the extremely sparse notes in /etc/default/libnss-db (which
you only find by looking at the package files), there is absolutely no
documentation for libnss-db. No man page, no files in /usr/share/doc.
--
(\___(\___(\__
Package: e2fsprogs
Version: 1.37-2sarge1
Severity: important
Subject tells the story, because devics can change, e2fsck needs to be
able to find external journal devices by UUID and correct the superblock
field specifying the device. Isn't this why the journal UUID is present
in the superblock?
From: Theodore Ts'o [EMAIL PROTECTED]
Um, e2fsck does search for the external journal device by UUID. It
only falls back to the superblock field specifying the device if the
journal can't be found.
I was in a hurry so I might of misread the symptoms I was seeing, but it
sure looked like
From: Theodore Ts'o [EMAIL PROTECTED]
On Mon, Mar 06, 2006 at 09:44:47PM -0800, Elliott Mitchell wrote:
I was in a hurry so I might of misread the symptoms I was seeing, but it
sure looked like e2fsck 1.37-2sarge1 wasn't finding the journal. I didn't
dare try reseting the field with tune2fs
From: Theodore Ts'o [EMAIL PROTECTED]
The attitude is indeed to leave this for userspace for doing such
searches; that's why what is specified is the device number. The
correct tool for doing the searches is the blkid library, which is
what e2fsck and tune2fs uses, and arguably mount should
Package: ssmtp
Version: 2.61-5
Many of the MTAs support IPv6, it would be nice if stub mailers did too.
The man page's mention of a -6 option also implies the presence of IPv6
support, yet it is absent.
--
(\___(\___(\__ --= 8-) EHM =-- __/)___/)___/)
\BS (|
From martin f krafft [EMAIL PROTECTED]:
also sprach Neil Brown [EMAIL PROTECTED] [2006.06.01.0427 +0200]:
This is fixed with version-1 superblocks.
Thus this was fixed by upstream when I uploaded 2.4.1-1.
The version-1 metadata records the offset in the device of the
superblock. So if
From: martin f krafft [EMAIL PROTECTED]
Would result in detection of md0 on sd?1, md1 on sd?2, md3 on sd?4,
md4 on sd?5, and md5 on sd?6.
Is there a second disk? If not, could you please give me more
information on how your RAID is set up?
I will try to reproduce this problem, but I
From: Theodore Ts'o [EMAIL PROTECTED]
On Tue, Mar 07, 2006 at 06:12:25PM -0800, Elliott Mitchell wrote:
That isn't what I have a problem with in this case. Problem is `mount`
would have to understand the target filesystem in order to find out the
journal UUID is. `mount` doesn't have
From: Theodore Ts'o [EMAIL PROTECTED]
On Fri, Mar 10, 2006 at 11:36:17PM -0800, Elliott Mitchell wrote:
How much are block devices expected to change on every boot? For
automatically mounted filesystems, this could be done as part of
`fsck -a`. I'm unsure of the hint format, one solution
Package: apt
Version: 0.6.46.4-0.1
Severity: grave
Justification: renders package unusable, conventional workaround doesn't work
Well, it's everyone's favorite bug with apt-get:
Reading package lists... Error!
E: Dynamic MMap ran out of room
E: Error occurred while processing
This appears to be due to testing. Removing the binary line for it (or
rather the mirror) from /etc/apt/sources.list made this go away. Removing
any of the other repositories failed to make the problem disappear. I was
even able to produce core files (seems to suggest a bigger problem).
I must
From: A Mennucc [EMAIL PROTECTED]
In this same bug there were reported two different issues, a Dynamic
MMap error and a segmentation fault; moreover some people were using
APT in Etch, and some other in Lenny.
I believe this is a good estimation of how it breaks down.
The only way to
From: Eugene V. Lyubimkin [EMAIL PROTECTED]
Elliott Mitchell wrote:
Have you looked at how many reports there are of the MMap problem and how
old they are?
A quick browse found #178623, #295051 and #380509. Plus #400768 which is
a distinct problem, but still tickles the MMap problem
From: Eugene V. Lyubimkin [EMAIL PROTECTED]
A Mennucc wrote:
IMHO one way to decide if to accept a patch during the freeze is to
see how large and important it is. Does anybody have an example
patch, or a description of what code changes would be necessary?
I had a look on this bug and,
From: Eugene V. Lyubimkin [EMAIL PROTECTED]
Elliott Mitchell wrote:
I have made no such claims. I am merely stating that this is a serious
bug. Severe enough to seriously consider delaying the release. This is
what the release team gets to decide, which is worse (neither option is
good
I don't believe this is attributable to NIS, but a more generalized
problem (and I would expect the general problem to effect current
versions of the passwd package too).
I'm running into a similar sort of difficulty here, except the package
I've got interacting in a bad way is libnss-db. Mainly,
Package: kernel-package
Version: 11.015
Another SSIA. With the current release version of kernel-package, I used
my standard set of options, --append_to_version -host-0 --revision 0
--stem host. Despite using --revision, the resultant package version was
still 2.6.26-host-0-10.00.Custom.
--
Package: nfs-common
Version: 1:1.1.2-6lenny1
The users option got broken with the latest release, despite working
correctly in 1:1.0.10-6+etch.1 (old stable). Non-root users can mount
filesystems listed in /etc/fstab that have users specified, but they
will be unable to unmount the filesystem
Given libsnmp's suboptimal security history, might I suggest statically
linking with it is a /bad/ idea? Wouldn't it be better to create a
separate /sbin/apc-killpower command that takes care of shutting the
UPS down?
How does this bug manage to rate important severity, not grave
severity?
--
Package: apcupsd
Version: 3.14.4-1lenny1
The subject line tells the story. The scripts with apcupsd all assume
they can write to /etc/apcupsd/powerfail, which only works if / is
mounted read-write.
Two solutions jump to mind:
First solution, `init` has powerfail/powerok states; if that state is
From: Matija Nalis mnalis-deb...@voyager.hr
So, original question was what broke? You still didn't answer that.
Package being upgraded is not breaking. If you lost some functionality, that
might have been breakage (from your POV), and that is what I (and Gerrit, I
believe) are interested in
Package: initramfs-tools
Version: 0.92o
If the running kernel has had module support removed, you'll get a bunch
of errors of:
grep: /proc/modules: No such file or directory
The one place I found was in /usr/share/initramfs-tools/hook-functions,
the function manual_add_modules(). Looks like you
reopen 326415
stop
From: ow...@bugs.debian.org (Debian Bug Tracking System)
There are no TCP listeners in the qmail package. The TCP layer is handled by
another package. I would be more than happy to add IPV6, but since it
doesn't have any TCP listeners, it is not possible.
Please point
From: Jon Marler jmar...@debian.org
Have you tested that this patch works? I don't have an IPV6 network to play
with.
Seems to, there isn't too much SMTP traffic over IPv6 right now. At the
very least, it doesn't break SMTP over IPv4. Note though that there is
the one small conflict with
Package: e2fsprogs
Version: 1.41.3-1
Subject tells the story. Why are mere /precautionary/ filesystem checks
allowed to slow a system booting so much? ie the ones triggered by either
the mount count or check time exceeding their limits.
I would suggest limiting it to doing a precautionary check
From: ty...@mit.edu
If you are mounting the file system read-only, feel free to change the
fsck pass number in /etc/fstab to be 0. That will cause e2fsck to be
skipped completely.
Wrong behavior. The desire here is not to disable checks due to being on
read-only media, but the filesystem is
From: ty...@mit.edu
On Thu, Mar 25, 2010 at 12:55:50AM -0700, Elliott Mitchell wrote:
Which is why I wasn't writing about the mount count. I was writing about
the check interval/check time. With systems that reboot less than once a
month, the mount count will never be reached. Instead
I'll confess I'm only trying with the 2.6.26-21lenny3 kernel source, but
I'm seeing the same thing Xel Media reportted. Given how large the
differences are though, I've got a very strong suspicion it won't apply
to the kernel source originally shipped with lenny either.
I suppose this is an
From: Gerrit Pape p...@smarden.org
Hi, you don't say in which way it breaks the older unofficial package
for you.
Seeing how ucspi-tcp is/was most often generated from ucspi-tcp-src for
more than the past 10 years, I'd hardly call it unofficial.
This should have been displayed to you when
From: Matija Nalis mnalis-deb...@voyager.hr
On Tue, Apr 27, 2010 at 01:57:20PM -0700, Elliott Mitchell wrote:
From: Gerrit Pape p...@smarden.org
Hi, you don't say in which way it breaks the older unofficial package
for you.
Seeing how ucspi-tcp is/was most often generated from ucspi
Package: ucspi-tcp
Version: 1:0.88-2
Severity: important
The ucspi-tcp created by Gerrit Pape breaks all packages produced from
ucspi-tcp-src created by Jon Marler. It does this in two ways, first it
uses the ucspi-tcp package name that ucspi-tcp-src has been using for
it's output packages for 10
Package: aptitude
Version: 0.4.11.11-1~lenny1
Updating the display of packages behind the search box while typing
characters is nice, it is also rather sluggish. Worse, it appears that
aptitude updates its display after each character pressed, not accounting
for someone having typed faster and
Package: sun-java5-doc
Version: 1.5.0-17-0.1
The subject line pretty well covers it. The message specifies downloading
the Java documentation zip file to /tmp, when it really wants it
downloaded to ${TMP_DIR}.
--
(\___(\___(\__ --= 8-) EHM =-- __/)___/)___/)
\BS (
Package: jailtool
Version: 1.1-4
We have the symbolic link: /usr/share/man/man1/update-jail.1.gz
which points to: jailtool.1.gz
Alas, the mysterious man page jailtool.1.gz does not appear to exist
anywhere in Debian.
--
(\___(\___(\__ --= 8-) EHM =-- __/)___/)___/)
Package: quilt
Version: 0.46-6
Appears that quilt needs to depend on mail-transport-agent, otherwise
/usr/share/quilt/compat/sendmail won't be too useful.
The link /usr/share/quilt/compat/awk has a similar issue. Does quilt
need to depend on gawk? Could it perhaps use /usr/bin/awk, or
Package: libpango1.0-doc
Version: 1.20.5-5+lenny1
libpango1.0-doc needs to depend on libglib2.0-doc, otherwise the symbolic
links: /usr/share/doc/libpango1.0-doc/glib and
/usr/share/doc/libpango1.0-doc/gobject will point to invalid locations.
(or those two links could be removed)
--
Package: libmilter1.0.1
Version: 8.14.3-5+lenny1
/usr/share/bug/libmilter1.0.1 points to sendmail, which only exists
if sendmail-base is installed (other tools can use milter and drag in
libmilter).
--
(\___(\___(\__ --= 8-) EHM =-- __/)___/)___/)
\BS (|
Package: kaffe-pthreads
Version: 2:1.1.8-5.2
/usr/lib/kaffe/pthreads/include points to ../include, which is absent
unless kaffe-dev is installed.
--
(\___(\___(\__ --= 8-) EHM =-- __/)___/)___/)
\BS (| e...@gremlin.m5p.com PGP F6B23DE0 |) /
Package: initscripts
Version: 2.86.ds1-61
I'm guessing some step is being done by the initial ramdisk scripts,
with Etch that step was also done by the regular init script; whereas
in Lenny it got removed from the initscripts.
$ head -2 /proc/mounts
rootfs / rootfs rw 0 0
/dev/root / ext3
From: Petter Reinholdtsen p...@hungry.com
[Elliott Mitchell] wrote:
I'm guessing some step is being done by the initial ramdisk scripts,
with Etch that step was also done by the regular init script;
whereas in Lenny it got removed from the initscripts.
I am not aware of any changes
From: Petter Reinholdtsen p...@hungry.com
[Elliott Mitchell]
Hrmm, one more setting that may be required to reproduce, this
system mounts / read-only.
What does your /etc/fstab file look like? What about the
/proc/cmdline content? I have no clue what is going on, so I thought
it best
From: Petter Reinholdtsen p...@hungry.com
[Elliott Mitchell]
fstab: Several FSes listed. / is defaults,ro. /proc and /tmp are
explicitly listed, the other tmpfs mounts are not listed (/dev/shm,
etc).
Can you attach a copy of your /etc/fstab too?
The line of interest is:
/dev/sda1
Package: initramfs-tools
Version: 0.92o
Subject tells the story. Appears the images generated by initramfs-tools
completely ignore the `rdev` setting that the kernel was given to the
kernel. While 99% of users may be explicitly passing the root device via
passing root=/dev/foo through the
reopen 589118
quit
From: Ben Hutchings b...@decadent.org.uk
On Wed, 2010-07-14 at 18:11 -0700, Elliott Mitchell wrote:
Package: initramfs-tools
Version: 0.92o
Subject tells the story. Appears the images generated by initramfs-tools
completely ignore the `rdev` setting that the kernel
Just realized I may have made an error when listing the conditions
necessary to reproduce. I am uncertain whether or not a non-initrd kernel
is required to reproduce.
What may instead be the required ingredient is the using the `rdev`
setting to specify the root filesystem. I'll check tommorrow,
Bit more testing and I've merely gotten rid of more causes. Tried booting
with an older 2.6.18 kernel from etch that I had handy. Problem still
occurred. Tried booting the current kernel while passing the the root
device via the kernel command-line (root=/dev/sda1), problem still
occurred.
reopen 589118
quit
From: Ben Hutchings b...@decadent.org.uk
On Thu, 2010-07-15 at 13:48 -0700, Elliott Mitchell wrote:
Bzzzt! While the initrd= kernel command-line option and `rdev` kernel
settings are not completely orthogonal, they are mostly unrelated.
You obviously haven't read
Any update?
Should /I/ create a second bug report and attach it to util-linux? (or
are you going to do the honors?) Thought I saw the current BTS can have a
report shared amoung multiple packages...
The algorithm that comes to mind for this problem:
Pass 0: (/etc/init.d/checkroot.sh)
From: ty...@mit.edu
On Mon, May 24, 2010 at 03:11:23PM -0700, Elliott Mitchell wrote:
If you hate precautionary checks so much, then turn them off. The
tools for doing this are within your hands. Or do them using a LVM
snapshot.
I don't hate precautionary checks. The problem is my
Package: ucf
Version: 3.0016
Severity: important
The subject line pretty well says it all. The ucf package needs to
include a dependancy on awk|mawk|gawk as appropriate, otherwise there is
no guarentee it will be present on the system (even if other tools depend
on it, as one could be in the
reopen 551029
quit
From: Manoj Srivastava sriva...@acm.org
This is not abug. awk is a virtually essential package, so no
package needs to depend on it. (hint: dpkg will not work unless there
is a awk on the disk).
While it may be rather uncommon to run across systems that do not
Package: lilo
Version: 1:22.8-10
First noticed this with the 1:22.8-7 (lenny) version. The lilo package
installs hooks to get rerun when the initramfs-tools are invoked, or a
kernel package is installed. These hooks though completely ignore
/etc/kernel-img.conf (configuration file created by
Package: elilo
Version: 3.12-4
The elilo package installs hooks to get rerun when the initramfs-tools
are invoked, or a kernel package is installed. These hooks though
completely ignore /etc/kernel-img.conf (configuration file created by
kernel-package); in particular the do_bootloader option,
Package: dump
Version: 0.4b43-1
I'm trying to believe this is all the fault of #588675 and dump is
blameless, but I'm uncertain. The problem is pretty straightforward, when
the root filesystem is listed in /etc/mtab|/proc/mounts as /dev/root,
the output for the -w option for the root filesystem
Might I suggest pondering returning bug #359717 to wishlist severity and
taging it wontfix?
The problem is binding mounts *will* break things if used improperly (or
properly depending on POV and how sadistic you are). The steps used by
`mountpoint` are absolutely correct from Unix traditions,
I spotted bugs #326647 and #526398 while doing a bit of research for
another problem. #326647 is worth mentioning because it requires almost
exactly the same key ingredient as #575343. Mainly some method to inhibit
precautionary checks while allowing regular unclean-FS checks to go
through
Just found what looks suspiciously like a proverbial smoking gun on the
GTK/GDK side of things. Rather contrary to my previous suspicions,
disabling handling FocusOut, FocusIn, LeaveNotify and EnterNotify events
failed to improve the situation. So, finally went in and tried adding
Package: atftpd
Version: 0.7.dfsg-9.1
Subject hopefully describes the situation. If atftpd is invoked with
*both* the --port and --bind-address options, it will lose track of the
port.
I believe something along the lines of:
-8---8-
Package: atftpd
Version: 0.7.dfsg-9.1
Looks like when concentrating on the development to work with multicast
TFTP, you forgot about the far more common case of singlecast. I'm unsure
of the limitations of the device I'm working with, but it appears to want
a response from the same IP/port that
Did a bit more looking and it looks like I attributed this wrong. The
device isn't getting confused by moving to a new port, instead it looks
like atftpd may be losing track. Got some better packet traces now:
:69- remote RREQ file, timeout 5
local - remote OACK timeout 5
local -
From: Luk Claes l...@debian.org
The users option got broken with the latest release, despite working
correctly in 1:1.0.10-6+etch.1 (old stable). Non-root users can mount
filesystems listed in /etc/fstab that have users specified, but they
will be unable to unmount the filesystem
I should also add that I'm now dealing with nfs-common 1:1.2.2-4, and
mount 2.17.2-9 (current stable).
--
(\___(\___(\__ --= 8-) EHM =-- __/)___/)___/)
\BS (| e...@gremlin.m5p.com PGP F6B23DE0 |) /
\_CS\ | _ -O #include
1 - 100 of 392 matches
Mail list logo
