Bug#983389: finit-sysv: can't load init after install of finit-sysv
Package: finit-sysv Version: 3.2~rc3-2 Severity: important Justification: can't load init system after install of finit-sysv -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-3-amd64 (SMP w/1 CPU thread) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled After installing finit-sysv version 3.2~rc3-2 (and dependencies), the result is a significantly broken system - notably can't load init system // example/synopsis - my comments added on lines starting with "//" // Starting from a relatively base/default bullseye 11 amd64 // with systemd-sysv already installed (same seems to also occur if // other init systems are first installed then finit-sysv is installed) # cat /etc/debian_version bullseye/sid # uname -m x86_64 # apt-get -y --no-install-recommends install finit-sysv // ... installation itself gives no errors // Note that we end up with /sbin/init as symlink to pathname /finit // that doesn't exist: # ls -l /sbin/init lrwxrwxrwx 1 root root 6 Jan 4 09:15 /sbin/init -> /finit # ls -l /finit ls: cannot access '/finit': No such file or directory // We do, however, have /sbin/finit: # ls -l /sbin/finit -rwxr-xr-x 1 root root 150248 Jan 4 09:15 /sbin/finit # dpkg -S /sbin/finit finit: /sbin/finit // Haven't rebooted yet, so still running old init system, // so we use appropriate reboot for that: # ls -l /proc/1/exe lrwxrwxrwx 1 root root 0 Feb 23 09:58 /proc/1/exe -> /lib/systemd/systemd # systemctl reboot // After reboot, however, init system fails to load // ... Begin: Running /scripts/init-bottom ... done. run-init: /sbin/init: No such file or directory Target filesystem doesn't have requested /sbin/init. run-init: /sbin/init: No such file or directory run-init: /etc/init: Permission denied run-init: /bin/init: No such file or directory /bin/sh: 0: can't access tty; job control turned off // This leaves us without a loaded init, we examine and attempt // fix or workaround: # ls -l /sbin/init lrwxrwxrwx 1 root root 6 Jan 4 09:15 /sbin/init -> /finit # ls -l /finit ls: cannot access '/finit': No such file or directory # fgrep ro, /proc/mounts /dev/vda1 / ext4 ro,relatime 0 0 # mount -o remount,rw / # cd /sbin # ls -l finit -rwxr-xr-x 1 root root 150248 Jan 4 09:15 finit # ls -ld init lrwxrwxrwx 1 root root 6 Jan 4 09:15 init -> /finit // we attempt workaround: # ln -sf finit init # ls -l init finit -rwxr-xr-x 1 root root 150248 Jan 4 09:15 finit lrwxrwxrwx 1 root root 5 Feb 23 10:07 init -> finit // we then proceed with sync and reboot: # cd / # sync& # mount -o remount,ro / # reboot -f -f // We then end up with: Begin: Running /scripts/local-bottom ... done. Begin: Running /scripts/init-bottom ... done. [3.162731] Not activating Mandatory Access Control as /sbin/tomoyo-init does not exist. [3.177559] finit[1]:main():Failed mounting /sysfs: No such file or directory [3.184566] finit[1]:load_plugins():Failed, cannot open plugin directory /usr/lib/x86_64-linux-gnu/finit/plugins: No such file or directory [3.191312] input: ImExPS/2 Generic Explorer Mouse as /devices/platform/i8042/serio1/input/input2 [3.213120] EXT4-fs (vda1): re-mounted. Opts: errors=remount-ro [3.221124] Adding 1046524k swap on /dev/vda5. Priority:-2 extents:1 across:1046524k FS [4.437246] pcieport :00:02.6: pciehp: Slot(0-6): No device found // That appeared to get us past the /finit path issue, // but now we've failed on /sysfs issue (that pathname doesn't exist). // At this point, we've got netiher login nor shell, so we reset, // and boot with init=/bin/sh to examine and attempt workaround(s): # mount -o remount,rw / # mount -a # ls -l /proc/1/exe lrwxrwxrwx 1 root root 0 Feb 23 10:18 /proc/1/exe -> /bin/dash # ls -ld /sys* dr-xr-xr-x 13 root root 0 Feb 23 10:18 /sys // we try symbolic link, in hopes that may suffice, guessing it may be // looking for sysfs to be mounted upon or accessible via /sysfs # (cd / && ln -s sys sysfs) # ls -ld /sys* dr-xr-xr-x 13 root root 0 Feb 23 10:18 /sys lrwxrwxrwx 1 root root 3 Feb 23 10:18 /sysfs -> sys // we then proceed to reboot: # sync& # mount -o remount,ro / # reboot -f -f // and end up stuck at same place: Begin: Running /scripts/local-bottom ... done. Begin: Running /scripts/init-bottom ... done. [3.163861] Not activating Mandatory Access Control as /sbin/tomoyo-init does not exist. [3.175776] finit[1]:main():Failed mounting /sysfs: No such file or directory [3.181364] finit[1]:load_plugins():Failed, cannot open plugin directory /usr/lib/x86_64-linux-gnu/finit/plugins: No such file or directory [3.197055] input: ImExPS/2 Generic Explorer Mouse as /devices/platform/i8042/serio1/input/input2 [3.220225] EXT4-fs (vda1): re-mounted. Opts: errors=remount-ro [3.231206] Adding
Bug#963197: sudo: listpw=never is broken
bug not present on stretch 9,
bug appears upon stretch 9 --> buster 10 upgrade, (breaking existing
functionality, hence I'd advocate Severity: important, however there does
exist workaround, so Severity debatable)
bug still present with sudo 1.8.27-1+deb10u3 on buster 10.8
bug not present with sudo 1.9.5p2-2 on bullseye
bug still present with sudo 1.8.27-1+deb10u3 on buster 10.8,
demonstration (minimal example relative to defaults):
# dpkg -l sudo 2>&1 | awk '{if($1=="ii")print $2,$3;}'
sudo 1.8.27-1+deb10u3
# cat /etc/debian_version
10.8
# awk '{if(NF>=1 && $1 !~ /^#/ )print;}' /etc/sudoers /etc/sudoers.d/*
Defaultsenv_reset
Defaultsmail_badpass
Defaults
secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
Defaultslistpw=never
rootALL=(ALL:ALL) ALL
%sudo ALL=(ALL:ALL) ALL
# su - michael
$ sudo -l
We trust you have received the usual lecture from the local System
Administrator. It usually boils down to these three things:
#1) Respect the privacy of others.
#2) Think before you type.
#3) With great power comes great responsibility.
[sudo] password for michael:
Expected behavior - it shouldn't prompt for password, per sudoers(5):
SUDOERS(5) BSD File Formats Manual SUDOERS(5)
listpwThis option controls when a password will be required when
never The user need never enter a password to use the
-l option.
bug not present with sudo 1.9.5p2-2 on bullseye:
# dpkg -l sudo 2>&1 | awk '{if($1=="ii")print $2,$3;}'
sudo 1.9.5p2-2
# cat /etc/debian_version
bullseye/sid
# awk '{if(NF>=1 && $1 !~ /^#/ )print;}' /etc/sudoers /etc/sudoers.d/*
Defaultsenv_reset
Defaultsmail_badpass
Defaults
secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
Defaultslistpw=never
rootALL=(ALL:ALL) ALL
%sudo ALL=(ALL:ALL) ALL
@includedir /etc/sudoers.d
# su - michael
$ sudo -l
Sorry, user michael may not run sudo on small.
$
From upstream we have:
https://bugzilla.sudo.ws/show_bug.cgi?id=869
If I add listpw=never in sudoers and run sudo -l it always ask for
user's password.
The workaround I found was to add a new entry with NOPASSWD: to that
user letting it to run /usr/bin/false and change listpw to any.
https://www.sudo.ws/changes.html
2019-01-22 Todd C. Miller
* plugins/sudoers/parse.c:
Fix listpw=never and verifypw=never. Bug #869
[ecb89088a884]
And that and similar workarounds appear to work.
Workaround:
E.g. applying and
testing workaround to
sudo 1.8.27-1+deb10u3 on buster 10.8 as otherwise shown above:
# dpkg -l sudo 2>&1 | awk '{if($1=="ii")print $2,$3;}'
sudo 1.8.27-1+deb10u3
# cat /etc/debian_version
10.8
# SUDO_EDITOR=ed visudo
691
/listpw
Defaultslistpw=never
d
w
669
q
# SUDO_EDITOR=ed visudo -f /etc/sudoers.d/local
0a
ALL ALL=(nobody:nogroup) NOPASSWD: /bin/true ""
.
w
48
q
# awk '{if(NF>=1 && $1 !~ /^#/ )print;}' /etc/sudoers /etc/sudoers.d/*
Defaultsenv_reset
Defaultsmail_badpass
Defaults
secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
rootALL=(ALL:ALL) ALL
%sudo ALL=(ALL:ALL) ALL
ALL ALL=(nobody:nogroup) NOPASSWD: /bin/true ""
# su - michael
$ sudo -l
Matching Defaults entries for michael on small:
env_reset, mail_badpass,
secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin
User michael may run the following commands on small:
(nobody : nogroup) NOPASSWD: /bin/true \"\"
$
"Of course" this requires the otherwise spurious sudo command to be added
to the configuration, but as far as I've been able to tell from what
I've read and tested, as long as the user has access to so much as a
least one NOPASSWD command, if listpw is set to any (or defaults to
such), for that(/those) user(s), it will behave as if listpw=never were
set (at least for that/those users).
Thanks.
From: "Marc Haber"
Subject: Re: Bug#963197: sudo: listpw=never is broken
Date: Mon, 22 Feb 2021 17:06:36 +0100
tags #963197 unreproducible
severity #963197 normal
thanks
Hi Michael,
On Sat, Jun 20, 2020 at 12:06:52PM +, Michael Paoli wrote:
* justification for Severity: (>=) important:
Broken in buster (stable) (at least 1.8.27-1+deb10u2).
I don't agree with that justification, reducing to normal. This issue is
unlikely to be fixed in buster.
Works for me:
|[2/2568]mh@testbuster83:~ $ sudo -l
|Matching Defaults entries for mh on testbuster83:
|env_reset, mail_badpass,
|
secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin
|
|User mh may run the following commands on testbuster83:
|(ALL : ALL) ALL
|[3/2568]mh@testbuster83:~ $
I cannot make sense of that. What exactl
Bug#963197: sudo: listpw=never is broken
Package: sudo Version: 1.8.27-1+deb10u2 Severity: important Tags: upstream Dear Maintainer, * justification for Severity: (>=) important: Broken in buster (stable) (at least 1.8.27-1+deb10u2). Works in stretch (oldstable) (at least 1.8.27-1+deb10u2). Existing listpw=never functionality breaks upon stretch (oldstable) --> buster (stable) upgrade. Hopefully listpw=never fix can be cleanly backported into buster (current stable). :-) * What led up to the situation? stretch (oldstable) --> buster (stable) upgrade. Bug apparently from upstream (apparently fixed in upstream 1.8.28). $ sudo -l fails where it used to work * What exactly did you do (or not do) that was effective (or ineffective)? Not fix, but work-around, change sudoers, e.g. to include: # listpw=never bug work-around: # Defaults listpw = never Defaults listpw = any ALL ALL=(nobody:nogroup) NOPASSWD: /bin/true "" * What was the outcome of this action? fails: sudoers: Defaults listpw=never $ sudo -l Above noted work-around is effective but adds spurious additional sudo command. * What outcome did you expect instead? Should work: sudoers: Defaults listpw=never $ sudo -l * +wishlist: add listpw regression tests to Debian sudo build/test, also feed same to upstream See also / references: Apparently (but I've not verified) fixed in upstream 1.8.28: https://unix.stackexchange.com/questions/466326/listpw-default-option-not-working-with-sudo-1-8-24 https://bugzilla.sudo.ws/show_bug.cgi?id=869 https://www.sudo.ws/repos/sudo/rev/ecb89088a884 -nopass = (pwcheck == all) ? true : false; +nopass = (pwcheck == never) ? true : false; -- System Information: Debian Release: 10.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-9-amd64 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C), LANGUAGE=en_US.UTF-8 (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages sudo depends on: ii libaudit1 1:2.8.4-3 ii libc6 2.28-10 ii libpam-modules 1.3.1-5 ii libpam0g1.3.1-5 ii libselinux1 2.8-1+b1 ii lsb-base10.2019051400 sudo recommends no packages. sudo suggests no packages. -- Configuration Files: (not supplied, see also work-around, etc. above) -- *+Kudos: Debian is fantastic! Much appreciate all the excellent high quality work! Rare that I actually find a bug in stable - been quite a while. https://www.debian.org/intro/help :-)
Bug#933728: cdimage.debian.org: missing files for debian-30r0-i386-binary
Package: cdimage.debian.org
Severity: minor
Although the Debian Archive
http://cdimage.debian.org/mirror/cdimage/archive/
has the Jigdo files:
http://cdimage.debian.org/mirror/cdimage/archive/3.0_r0/i386/jigdo-cd/
woody-i386-1_NONUS.jigdo
woody-i386-1.jigdo
...
woody-i386-7.jigdo
for
debian-30r0-i386-binary-1_NONUS.iso
debian-30r0-i386-binary-1.iso
...
debian-30r0-i386-binary-7.iso
there are many (470 at my last count) files missing from the
Debian Archive needed to create the ISO files from the Jigdo
files (and the Debian Archive doesn't have those ISO files).
The missing files should be added to the archive.
"Patch" available (at least at present) - the missing files
can be obtained (at least at present - maybe/probably not
"forever"), from various location(s)/resources.
General recommended procedure for adding the missing files
to the Debian Archive:
Obtain the missing file(s) and/or
debian-30r0-i386-binary-*.iso file(s) as available (see also
further below on some pointers where those are available).
In the case of *.iso file(s) above, mount them for
(potential) use in creation of other *.iso file(s) via
Jigdo (e.g. debian-30r0-i386-binary-1_NONUS.iso +
woody-i386-1.jigdo is sufficient to create
debian-30r0-i386-binary-1.iso).
Use the available *.jigdo files to assemble/verify all the
*.iso files.
Use the available
http://cdimage.debian.org/mirror/cdimage/archive/3.0_r0/i386/jigdo-cd/MD5SUMS
(which is also signed!) to verify the *.iso files.
Mount the *.iso files.
All the missing files needed to create the *.iso files via
Jigdo are present among the full set of *.iso files (as seen
when the *.iso files are mounted).
Those files can also be further verified individually
against the hashes present in the *.jigdo files.
The missing files should then be uploaded (and probably with
mtimes preserved from them as seen on the *.iso files) to
the Debian Archive, so that the *.iso files can then again
be created via the *.jigdo files plus the then completed set
of files in the Debian Archive.
Where to obtain the missing files and/or ISOs:
Some of the various *.iso files and/or constituent files
thereof may be found various place(s) on The Internet,
search and/or see e.g.:
https://lists.debian.org/debian-cd/2019/07/msg00022.html
For any missing constituent files that still can't be
found/obtained (most especially many needed to complete the
debian-30r0-i386-binary-{4,5,6,7}.iso files via jigdo), I
have the files, and have ("temporarily" ... maybe up to
about 90 days or so?) made them available again.
Anyway, after assembling what one can via Jigdo from the
Debian Archive and/or other available resources, at least at
the present time, any otherwise still missing files can be
obtained by continuing to use Jigdo, just for subsequent
passes to collect the missing, for URL/archive for Jigdo,
give it:
http://old-debian.balug.org/
Note that's NOT A HIGH BANDWIDTH NOR HIGH AVAILABILITY SITE.
references/excerpts:
https://lists.debian.org/debian-cd/2019/07/msg00022.html
https://lists.debian.org/debian-cd/2017/07/msg00043.html
https://lists.debian.org/debian-cd/2017/07/msg00042.html
https://lists.debian.org/debian-cd/2017/07/msg00037.html
https://lists.debian.org/debian-cd/2017/07/msg00036.html
https://lists.debian.org/debian-cd/2016/02/msg8.html
https://lists.debian.org/debian-cd/2016/02/msg7.html
https://lists.debian.org/debian-cd/2016/02/msg6.html
https://lists.debian.org/debian-cd/2014/07/msg00012.html
https://lists.debian.org/debian-cd/2014/07/msg00011.html
Bug#775169: work-around: Bug #775169 pvmove segfaults
I was encountering same, or highly similar issue,
notably pvmove segfaults. Currently on Debian oldstable.
I also found the relatively informative similar/related thread:
https://lists.debian.org/debian-user/2011/06/msg01947.html
https://lists.debian.org/debian-user/2011/06/msg02076.html
My situation "the same", or highly similar:
pvmove segfaults
lvs -a
and
lvdisplay -a
show a [pvmove0] volume
attempts at:
pvmove --abort
lvremove [-f] ...pvmove0
lvchange ... pvmove0
lvmremove [-f] ... pvmove0
all failed
The threat mentioned above had suggestion to remove the dm device,
however, using blkid on all dm devices, I found no DM device with
the UUID shown by lvdisplay -a
nor any devices/links with or containing name pvmove0, and pvmove0
(in lvdisplay -a, lvs -a)
also showed it as size 0, and everything LVM related reported it
as locked and inactive. Not sure what created this situation, but ..
workaround for the above:
I ran vgcfgbackup twice (so I'd have both "current" config saved,
and one slightly older archive saved copy of same).
I then edited the most recent saved copy, removing the pvmove0 section.
I then used vgcfgrestore.
After that, all was fine and good. :-) No more complaints or signs
about pvmove0, and pvmove worked again fine and as expected.
Suggestion - see if something can be added to the lvm code to recognize this
situation and self-correct (or even prevent). It may also be quite feasible
to reproduce the problem, by injecting such data into a file created by
vgcfgbackup, then using vgcfgrestore (I've not attempted that). But,
in case that may be useful, here's the section I'd removed:
# pwd -P; sed -ne '/pvmove0 {/,/}/p' tigger_00754-383252791.vg
/etc/lvm/archive
pvmove0 {
id = "23mVuC-uEaK-gB3Z-9WU0-nYbM-91ls-kQ9KXf"
status = ["READ", "WRITE", "PVMOVE", "LOCKED"]
flags = []
allocation_policy = "contiguous"
segment_count = 0
}
#
Bug#669813: Debian bug: mailman: Re: Archives not-->now working (need Require all granted in )
Most relevant bit found among Debian bugs: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=669813#36 The new apache security model requires adding this to the Directory stanza for mailman: Require all granted But that's not particularly detailed, most notably omits mention of /etc/mailman/apache.conf and the section within. Recommended to (mostly) fix mailman 1:2.1.18-2+deb8u1 amd64: $ diff -U 5 etc/mailman/apache.conf.bug_669813 etc/mailman/apache.conf --- etc/mailman/apache.conf.bug_669813 2016-09-14 23:05:02.0 -0700 +++ etc/mailman/apache.conf 2017-07-11 07:01:29.116879436 -0700 @@ -26,10 +26,11 @@ Options FollowSymlinks AllowOverride None Order allow,deny Allow from all +Require all granted AllowOverride None Order allow,deny Allow from all $ At least that's the case for Jessie (presently oldstable) ( Debian GNU/Linux 8.8 (jessie) x86_64 mailman 1:2.1.18-2+deb8u1 amd64 apache2 2.4.10-10+deb8u9 amd64 ) I haven't (at least yet) checked to see if there's patch applied yet for newer than mailman 1:2.1.18-2+deb8u1 amd64 that may cover that fix. In the meantime, for work-around for at least those versions, in Apache configuration, in addition to (which I added): Include ../mailman/apache.conf (or Include /etc/mailman/apache.conf or equivalent ) also add (and if the above is used via Include, use this *after* the above): Options FollowSymlinks AllowOverride None Order allow,deny Allow from all Require all granted From: "Michael Paoli" <michael.pa...@cal.berkeley.edu> Subject: Archives now working: BALUG-Test list Date: Tue, 11 Jul 2017 00:36:28 -0700 Archives are now working. Relevant bit ... I ought (when I get around to it) check if there's bug filed (it may already be fixed even - but not yet to stable). The missing bit ... I'd (rather than redundantly copied/maintain) used: (relative to /etc/apache2): Include ../mailman/apache.conf in file sites-available/Include/temp.balug.org that was almost all well fine and good (I'd reviewed ./mailman/apache.conf earlier). But it left out one key needed bit, it has: Options FollowSymlinks AllowOverride None Order allow,deny Allow from all but needs: Options FollowSymlinks AllowOverride None Order allow,deny Allow from all Require all granted My relatively simple fix, add to file sites-available/Include/temp.balug.org Options FollowSymlinks AllowOverride None Order allow,deny Allow from all Require all granted after: Include ../mailman/apache.conf ... Apache doesn't seem to care about the same appearing twice, and seems in that case to just use the latter fine, So ... /etc/mailman/apache.conf should have included but failed to include, in it's section: the line: Require all granted So ... I think I'd call that a "bug" - even if it's documentation errata. Might be a Debian specific patch needed, as other distributions and/or Apache may have different defaults on that security. https://temp.balug.org/pipermail/balug-test/2017-July/04.html temp.balug.org will in future be moved to lists.balug.org, so that will become: https://lists.balug.org/pipermail/balug-test/2017-July/04.html
Bug#866626: debian-installer: di 20170615 mis-parses Wi-Fi SSID that contains comma (,)
Package: debian-installer Version: 20170615 Severity: normal Dear Maintainer, di 20170615 misparses Wi-Fi SSID that contains comma (,) while installing: Debian GNU/Linux 9.0 (stretch) x86_64 from: Debian GNU/Linux 9.0.0 "Stretch" - Official Multi-architecture amd64/i386 NETINST #1 20170617-15:50 on/booted from: USB stick having above image using graphics installer (64-bit) installer misparses Wi-Fi SSID containing comma (,), specifically SSID: Paoli,_Michael shows up in selection list as two options: Paoli _Michael selecting either of those two fails (as such SSIDs did not exist) work-around: select option to manually enter SSID and enter: Paoli,_Michael that then works as effective work-around I also seem to note from my perusing of the IEEE specification, that SSID is 0 to 32 octets, so ... may need be appropriately careful in displaying/parsing, etc. (suggestion - maybe unambiguous form for display/entry, e.g. - show bytes that are neither ASCII isgraph nor non-trailing spaces as 3-digit octal escape sequences (\nnn), and show \ as \\, and likewise allow such parsing of entry to be able to use arbitrary SSIDs - note also that SSIDs may not be broadcast/advertised, maybe also add regression tests for arbitrary SSIDs, and some (help) text on display/entry format) bits from logs that seem likely relevant: /var/log/installer/cdebconf/questions.dat Name: netcfg/wireless_essid Template: netcfg/wireless_essid Value: Paoli,_Michael Owners: netcfg Variables: iface = wlp1s0 Name: netcfg/wireless_show_essids Template: netcfg/wireless_show_essids Value: manual Owners: netcfg Variables: essid_list = DeFarrell, xfinitywifi, Paoli,_Michael, Carleton, HOME-68E2, , Lan of the Free, XFINITY, ChezClaude, LBCPRIME, DeFarrrell-Guest, /var/log/installer/syslog Jun 24 16:40:21 cdrom-detect: Detected CD 'Debian GNU/Linux 9.0.0 "Stretch" - Official Multi-architecture amd64/i386 NETINST #1 20170617-15:50' Jun 24 16:44:53 netcfg[5195]: INFO: Activating interface wlp1s0 Jun 24 16:44:55 netcfg[5195]: INFO: Scan of wireless interface wlp1s0 succeeded. Jun 24 16:45:20 netcfg[5195]: INFO: Network chosen: Paoli,_Michael. Proceeding to connect. Jun 24 16:45:25 kernel: [ 358.670377] IPv6: ADDRCONF(NETDEV_CHANGE): wlp1s0: link becomes ready Jun 24 16:45:25 kernel: [ 358.770391] wlp1s0: Limiting TX power to 30 (30 - 0) dBm as advertised by da:c4:6a:9e:0b:9f Jun 24 16:45:26 netcfg[5195]: INFO: buf = bssid=da:c4:6a:9e:0b:9f freq=2437 ssid=Paoli,_Michael id=0 mode=station pairwise_cipher=CCMP group_cipher=CCMP key_mgmt=WPA2-PSK wpa_state=COMPLETED address=48:5d:60:22:08:6d uuid=21d07fc3-2257-56e3-9fe4-11b52065e99a -- System Information: Debian Release: 9.0 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-3-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C), LANGUAGE=en_US.UTF-8 (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) And thanks! - Lovely installer :-) - no other glitches seen thus far.
Bug#649109: bug apparently upstream, partially isolated bug source, ...
comments, summary, then some more details: comments: With 100x performance hit (500x typical), but apparently not present in oldstalbe, but present in stable, I'm guestimating this bug should be important or critical. I've not determined full scope of bug. I may or may not manage to (e.g. time, priorities) find/develop patch, but it would be really nice :-) to have a patch on this for stable to correct this bug. As/when I'm able, I'm looking towards a minimal patch that will correct this bug, but not otherwise alter stable (at least if/as such may be feasible). summary: bug appears to be upstream, bug appears to be problem in function dfaexec bug appears present in GNU grep-2.6.3 bug appears to be gone in GNU grep-2.7 copying: src/dfa.c src/dfa.h src/dfasearch.c from GNU grep-2.7 to GNU grep-2.6.3 causes bug to go away in GNU grep-2.6.3 (but no guarantees that doesn't potentially introduce other issues). That's as far as I've isolated it thus far. details: on getting to the above point (in approximate reverse order): The above and below tests were all done on currently patched Debian stable amd64. Copying the src/dfa* files from unpatched GNU grep-2.6.3 to unpatched GNU grep-2.7 appears to make the bug go away in grep-2.6.3 (no guarantees regarding other impacts). Searched for dfaexec in clean (make distclean) source for above and examined and compared files - seemed limited to, at most the three src/dfa* files; file differences appeared rather non-trivial; as experiment, tried copy as noted to see if it would even compile and function, and possibly squash bug. Compiling for debugging and profiling: CFLAGS='-ggdb -pg' ./configure and executing and examining profile (gprof(1)) indicated major performance problem in dfaexec function. Testing various unpatched released GNU grep versions showed bug apparently present in GNU grep-2.6.3 but apparently not present in GNU grep-2.7 (and subsequent versions). Testing unpatched upstream (orig) from Debian: http://ftp.de.debian.org/debian/pool/main/g/grep/grep_2.6.3.orig.tar.bz2 http://ftp.de.debian.org/debian/pool/main/g/grep/grep_2.9.orig.tar.gz showed bug present in 2.6.3 but not 2.9. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#649109: grep: pathetically slow for some REs; fine in old stable
Package: grep Version: 2.6.3-3 Severity: normal *** FILE //my comments on lines starting with // //MAINTAINER(S) MAY WISH TO INCREASE BUG PRIORITY based on bug scope //and impact (it may cause things to quite unexpectedly fail or //consume excessive resources and time, where such was not the case //before) //bug may - or may not - be related to (or same?) as bug 503658 //under at least certain not-too-unusual circumstances, grep RE //performance is abysmal, e.g.: $ time grep '^\(.\)\(.\).\2\1$' /usr/share/dict/words | wc -l 16 real1m7.503s user1m7.432s sys 0m0.012s $ //top(1) also shows us excessive CPU consumption: PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND 3193 mpaoli20 0 7756 1136 692 R 97.8 0.2 0:24.09 grep //I did also use strace(1) - didn't seem to show anything particularly //unusual - seems the bug consumes excess CPU (is quite CPU bound), //but no obvious excessive system calls or unusual delays on any //system calls noted in strace(1) output //however, when we add the -i option the performance for the above //becomes quite reasonable: $ time grep -i '^\(.\)\(.\).\2\1$' /usr/share/dict/words | wc -l 19 real0m0.582s user0m0.580s sys 0m0.004s $ //likewise performance is fine if we use LC_ALL=C $ time LC_ALL=C grep '^\(.\)\(.\).\2\1$' /usr/share/dict/words | wc -l 16 real0m0.390s user0m0.392s sys 0m0.000s $ //bug is also present if we explicitly use LC_ALL=en_US.UTF-8 $ time LC_ALL=en_US.UTF-8 grep '^\(.\)\(.\).\2\1$' /usr/share/dict/words | wc -l 16 real1m5.347s user1m5.320s sys 0m0.008s $ //bug appears to NOT be present in other common BRE utilities, e.g. //sed(1), ex(1), ed(1): $ time sed -ne '/^\(.\)\(.\).\2\1$/p' /usr/share/dict/words | wc -l 16 real0m0.267s user0m0.256s sys 0m0.012s $ time ex /usr/share/dict/words \__EOF__ | wc -l g/^\(.\)\(.\).\2\1$/p q __EOF__ 16 real0m1.004s user0m0.920s sys 0m0.020s $ time ed /usr/share/dict/words \__EOF__ | wc -l g/^\(.\)\(.\).\2\1$/p q __EOF__ 931708 16 real0m0.300s user0m0.292s sys 0m0.008s $ //for the examples above, most any relatively similar file could be used //instead of /usr/share/dict/words, I specifically used (in case it //matters): $ dpkg -S /usr/share/dict/words diversion by dictionaries-common from: /usr/share/dict/words diversion by dictionaries-common to: /usr/share/dict/words.pre-dictionaries-common wamerican, dictionaries-common: /usr/share/dict/words $ dpkg -l dictionaries-common | tail -n 1 ii dictionaries-common 1.5.17 Common utilities for spelling dictionary tools $ //and locale information (unless/except where explicity shown set //differently above) $ locale LANG=en_US.UTF-8 LC_CTYPE=en_US.UTF-8 LC_NUMERIC=en_US.UTF-8 LC_TIME=en_US.UTF-8 LC_COLLATE=en_US.UTF-8 LC_MONETARY=en_US.UTF-8 LC_MESSAGES=en_US.UTF-8 LC_PAPER=en_US.UTF-8 LC_NAME=en_US.UTF-8 LC_ADDRESS=en_US.UTF-8 LC_TELEPHONE=en_US.UTF-8 LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=en_US.UTF-8 LC_ALL= $ //bug is NOT present in old stable: $ cat /etc/debian_version 5.0.9 $ time grep '^\(.\)\(.\).\2\1$' /usr/share/dict/words | wc -l 16 real0m0.925s user0m0.896s sys 0m0.000s $ //even if we explicitly set LC_ALL=en_US.UTF-8, bug still not present in //old stable: $ time LC_ALL=en_US.UTF-8 grep '^\(.\)\(.\).\2\1$' /usr/share/dict/words | wc -l 16 real0m0.825s user0m0.808s sys 0m0.000s $ //also bug not present in old stable with en_US.utf8 $ locale -a | fgrep -i en_us.utf en_US.utf8 $ time LC_ALL=en_US.utf8 grep '^\(.\)\(.\).\2\1$' /usr/share/dict/words | wc -l 16 real0m0.814s user0m0.812s sys 0m0.000s $ -- System Information: Debian Release: 6.0.3 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages grep depends on: ii dpkg 1.15.8.11 Debian package management system ii install-info 4.13a.dfsg.1-6 Manage installed documentation in ii libc6 2.11.2-10 Embedded GNU C Library: Shared lib grep recommends no packages. Versions of packages grep suggests: ii libpcre3 8.02-1.1 Perl 5 Compatible Regular Expressi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#390397: groff -Tascii broken: should not output ANSI escape sequences
Package: groff-base Version: 1.18.1.1-7 Severity: normal from groff-base 1.18.1.1-7 we have: $ echo '.BR foo bar' | 2/dev/null groff -te -msafer -mtty-char -mm -Tascii | fgrep f | cat -v ^[[1mfoo^[[22mbar $ Apparently with groff-base 1.18.1.1-7, -Tascii is outputting ANSI escape sequences, and this of course breaks all kinds of stuff (e.g. this no longer works on dumb line printers and other devices that perfectly well understand ^H, ^I, ^L and printable ASCII characters, but know nothing of ANSI escape sequences; this similarly breaks stuff passed to less or col -b, etc., generally resulting in quite a mess). This works fine on oldstable (woody) groff-base 1.17.2-15.woody.1 as seen here: $ echo '.BR foo bar' | 2/dev/null groff -te -msafer -mtty-char -mm -Tascii | fgrep f | cat -v f^Hfo^Hoo^Hobar $ If one wants ANSI escape sequences, perhaps there should be a -Tansi, but please, -Tascii should continue to only generate printable ASCII characters and well defined common ASCII control codes (e.g. ^H, ^I, ^L), and should *not* generate ANSI escape sequences, as the actions of these escape sequences are not defined in the ASCII character set. -- System Information: Debian Release: 3.1 Architecture: i386 (i686) Kernel: Linux 2.4.29 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages groff-base depends on: ii libc6 2.3.2.ds1-22sarge4 GNU C Library: Shared libraries an ii libgcc1 1:3.4.3-13sarge1 GCC support library ii libstdc++51:3.3.5-13 The GNU Standard C++ Library v3 -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#389527: pymacs version 0.22-6 won't install; need fix for bug 372294
Package: pymacs Version: 0.22-6 Severity: important installation of pymacs version 0.22-6 fails: # dpkg -i pymacs_0.22-6_all.deb (Reading database ... 191619 files and directories currently installed.) Preparing to replace pymacs 0.22-6 (using pymacs_0.22-6_all.deb) ... remove/pymacs: purging byte-compiled files for emacs20 remove/pymacs: purging byte-compiled files for emacs21 W: Unable to locate package python-all E: No packages found Traceback (most recent call last): File /usr/bin/pycentral, line 1325, in ? main() File /usr/bin/pycentral, line 1319, in main rv = action.run(global_options) File /usr/bin/pycentral, line 919, in run runtimes = get_installed_runtimes() File /usr/bin/pycentral, line 196, in get_installed_runtimes supported = pyversions.supported_versions() File /usr/share/pycentral-data/pyversions.py, line 71, in supported_versions depends = [re.sub(r'\s*(\S+)[ (]?.*', r'\1', s) for s in depends] TypeError: iteration over non-sequence dpkg: warning - old pre-removal script returned error exit status 1 dpkg - trying script from the new package instead ... remove/pymacs: purging byte-compiled files for emacs20 remove/pymacs: purging byte-compiled files for emacs21 W: Unable to locate package python-all E: No packages found Traceback (most recent call last): File /usr/bin/pycentral, line 1325, in ? main() File /usr/bin/pycentral, line 1319, in main rv = action.run(global_options) File /usr/bin/pycentral, line 919, in run runtimes = get_installed_runtimes() File /usr/bin/pycentral, line 196, in get_installed_runtimes supported = pyversions.supported_versions() File /usr/share/pycentral-data/pyversions.py, line 71, in supported_versions depends = [re.sub(r'\s*(\S+)[ (]?.*', r'\1', s) for s in depends] TypeError: iteration over non-sequence dpkg: error processing pymacs_0.22-6_all.deb (--install): subprocess new pre-removal script returned error exit status 1 W: Unable to locate package python-all E: No packages found Traceback (most recent call last): File /usr/bin/pycentral, line 1325, in ? main() File /usr/bin/pycentral, line 1319, in main rv = action.run(global_options) File /usr/bin/pycentral, line 850, in run runtimes = get_installed_runtimes() File /usr/bin/pycentral, line 196, in get_installed_runtimes supported = pyversions.supported_versions() File /usr/share/pycentral-data/pyversions.py, line 71, in supported_versions depends = [re.sub(r'\s*(\S+)[ (]?.*', r'\1', s) for s in depends] TypeError: iteration over non-sequence dpkg: error while cleaning up: subprocess post-installation script returned error exit status 1 Errors were encountered while processing: pymacs_0.22-6_all.deb # All the documented dependencies for pymacs version 0.22-6 are met and python-all is not installed, yet the errors above occur. $ dpkg -l emacsen-common python python-central python-all Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad) ||/ Name VersionDescription +++-==-==- ii emacsen-common 1.4.16 Common facilities for all emacsen ii python 2.3.5-2An interactive high-level object-oriented la ii python-central 0.5.5 register and build utility for Python packag No packages found matching python-all. This also prevents fixing bug 372294, for which the solution is supposed to be upgrading python-mode to =1:1.0-2 however upgrading python-mode to =1:1.0-2 depends upon pymacs and pymacs won't install. Non-working python-mode (e.g. rendered by applying stable updates) and attempting to follow these corrections for bugs results in broken packages and broken dependencies, e.g.: $ dpkg -l junior-programming pymacs python-mode Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad) ||/ Name VersionDescription +++-==-==- iU junior-program 1.9Debian Jr. programming iFR pymacs 0.22-6 interface between Emacs Lisp and Python iU python-mode1.0-3.1Emacs-lisp python-mode and doctest-mode for -- System Information: Debian Release: 3.1 Architecture: i386 (i686) Kernel: Linux 2.4.29 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages pymacs depends on: ii emacsen-common1.4.16 Common facilities for all emacsen ii python2.3.5-2An interactive high-level object-o ii python-central0.5.5 register and build utility for Pyt -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of
Bug#387570: grep -D skip doesn't skip FIFOs but documentation says it should
Package: grep Version: 2.5.1.ds1-4 Severity: normal I also tested this with the binary from Version 2.5.1.ds2-5 (i386) and got the same results. both binaries give the same --version output: $ grep --version grep (GNU grep) 2.5.1 Copyright 1988, 1992-1999, 2000, 2001 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ Per the documentation (--help, info, man pages) -D skip or --devices=skip should cause FIFOs to be skipped. In testing, however, FIFOs are not skipped. The program and the documentation should be consistent (either correct the program to match the documentation, or vice versa). example demonstration of bug: -D, --devices=ACTION how to handle devices, FIFOs and sockets ACTION is 'read' or 'skip' $ mknod p p ls -lond p prw--- 1 1003 0 Sep 14 13:42 p $ out grep -D skip RE p echo REmatchp; wait; cat out [2] 22002 [2]- Donegrep -D skip RE p out REmatch $ I did also test character special device - without options the device is not skipped, and with -D skip the character special device is skipped, so the bug is apparently limited to only certain device type(s) (e.g. FIFOs). In the latest upstream source (e.g.: http://cvs.savannah.gnu.org/viewcvs/grep/src/grep.c?rev=1.121root=grepview=markup ) it would appear the source at least intends to behave consistent with the documentation: #ifndef DJGPP if (devices == SKIP_DEVICES (S_ISCHR(stats-stat.st_mode) || S_ISBLK(stats-stat.st_mode) || S_ISSOCK(stats-stat.st_mode) || S_ISFIFO(stats-stat.st_mode))) #else if (devices == SKIP_DEVICES (S_ISCHR(stats-stat.st_mode) || S_ISBLK(stats-stat.st_mode))) #endif I haven't checked to see precisely where the bug creeps in between the (most current) upstream source's apparent intent, and bug apparently being present in most current Debian (at least in unstable and testing binaries, and stable binary). references: news:[EMAIL PROTECTED] news:[EMAIL PROTECTED] http://savannah.gnu.org/projects/grep/ http://bugs.debian.org/cgi-bin/pkgreport.cgi?which=pkgdata=greparchive=noversion=dist=unstable -- System Information: Debian Release: 3.1 Architecture: i386 (i686) Kernel: Linux 2.4.29 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages grep depends on: ii libc6 2.3.2.ds1-22sarge4 GNU C Library: Shared libraries an -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#387564: bugs.debian.org dropping valid bug submissions
Package: bugs.debian.org
Version: =2006-04-22_through_=2006-09-14
Severity: normal
It appears that bugs.debian.org. is quietly dropping legitimate bug
submissions. It also appears that this has been going on for a fair
while (since at least 2006-04-22) and still happening presently
(2006-09-14), though this problem didn't occur in the past (worked
sometime prior to 2006-04-22, not sure of precise date(s)).
Example of bug:
headers and first part of body of submission:
Content-Type: text/plain; charset=us-ascii
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: Michael Paoli [EMAIL PROTECTED]
To: Debian Bug Tracking System [EMAIL PROTECTED]
Subject: grep -D skip doesn't skip FIFOs but documentation says it should
X-Mailer: reportbug 3.8
Date: Thu, 14 Sep 2006 17:48:45 -0700
X-Debbugs-Cc: bug-grep@gnu.org
Package: grep
Version: 2.5.1.ds1-4
Severity: normal
start and end of tcpdump trace (trailing CRs striped
and tabs converted to spaces in this listing, but present
in the actual data, see also further below for access to
the actual saved tcpdump data):
reading from file tcpdump, link-type EN10MB (Ethernet)
IP 198.144.194.236.44168 140.211.166.43.25: SWE 1549554698:1549554698(0) win
5840 mss 1460,sackOK,timestamp 240592232 0,nop,wscale 0
E..[EMAIL PROTECTED]@..+\\T
.3.
.W%h
IP 198.144.194.236.44168 140.211.166.43.25: . ack 3530140650 win 5840
nop,nop,timestamp 240592236 949033569
[EMAIL PROTECTED]@..+\\T..i..A^.
.W%l8..a
IP 198.144.194.236.44168 140.211.166.43.25: . ack 71 win 5840
nop,nop,timestamp 240592245 949033591
[EMAIL PROTECTED]@[EMAIL PROTECTED]
.W%u8..w
IP 198.144.194.236.44168 140.211.166.43.25: P 0:37(37) ack 71 win 5840
nop,nop,timestamp 240592245 949033591
[EMAIL PROTECTED]@..+\\T..i.0...
.W%u8..wehlo blackie.creasys.berkeley.ca.us
IP 198.144.194.236.44168 140.211.166.43.25: P 37:91(54) ack 193 win 5840
nop,nop,timestamp 240592251 949033603
[EMAIL PROTECTED]@..+\\T0.i..q..
.W%{8...mail FROM:[EMAIL PROTECTED] size=2983
IP 198.144.194.236.44168 140.211.166.43.25: P 91:125(34) ack 201 win 5840
nop,nop,timestamp 240592255 949033616
[EMAIL PROTECTED]@[EMAIL PROTECTED]
.W%.8...rcpt TO:[EMAIL PROTECTED]
IP 198.144.194.236.44168 140.211.166.43.25: P 125:167(42) ack 215 win 5840
nop,nop,timestamp 240592287 949033696
[EMAIL PROTECTED]@..+\\T..i.
.W%.8...rcpt TO:[EMAIL PROTECTED]
IP 198.144.194.236.44168 140.211.166.43.25: P 167:173(6) ack 240 win 5840
nop,nop,timestamp 240592292 949033707
E..:[EMAIL PROTECTED]@..+\\T..i..Y+.
.W%.8...data
IP 198.144.194.236.44168 140.211.166.43.25: . 173:1621(1448) ack 296 win 5840
nop,nop,timestamp 240592296 949033718
[EMAIL PROTECTED]@..6...+\\T..i.
.W%.8...Content-Type: text/plain; charset=us-ascii
MIME-Version: 1.0
...
Versions of packages grep depends on:
ii libc6 2.3.2.ds1-22sarge4 GNU C Library: Shared libraries an
-- no debconf information
.
IP 198.144.194.236.44168 140.211.166.43.25: P 3244:3250(6) ack 324 win 5840
nop,nop,timestamp 240592315 949033765
E..:[EMAIL PROTECTED]@..+\\`..i.-JZ.
.W%.8..%quit
IP 198.144.194.236.44168 140.211.166.43.25: F 3250:3250(0) ack 365 win 5840
nop,nop,timestamp 240592319 949033776
[EMAIL PROTECTED]@..+\\`..i.V2..
.W%.8..0
IP 198.144.194.236.44168 140.211.166.43.25: . ack 366 win 5840
nop,nop,timestamp 240592319 949033776
[EMAIL PROTECTED]@..+\\`..i.W2..
.W%.8..0
tcpdump data available (at least for a while) here:
http://www.rawbw.com/~mp/tmp/tcpdump.gz
The submission, which was apparently transmitted successfully, but
then apparently disappears (doesn't show up in the bug tracking
system, and isn't acknowledged, and no error is returned) was
generated (via script(s)) via:
[EMAIL PROTECTED] reportbug -b -c
--smtphost=bugs.debian.org. --realname='Michael Paoli' --no-check-available -H
'X-Debbugs-CC: bug-grep@gnu.org' --mode=standard --subject=grep -D skip doesn't
skip FIFOs but documentation says it should --body-file=BODYFILE grep
A nearly identical report was submitted 2006-04-22, no errors returned
in submission, and apparently never showed up in the bug tracking
system. On 2006-00-14 I submitted updated version of the bug. After
many hours, and it still not showing in the bug tracking system, I
repeated the attempt, while capturing the data transmission via tcpdump.
I also confirmed (via telnet bugs.debian.org. 25) that there's nothing
funky happening such as ISP filtering/redirects, etc. (the connection
goes through fine and the server is properly identified as expected
debian server).
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#291869: xlibs 4.1.0-16woody5_i386 (libXpm.so.4.11) segfaults fvwm - fixed(?) with upgrades(?)
xlibs 4.1.0-16woody5_i386 (libXpm.so.4.11) segfaults fvwm - fixed(?) with upgrades(?) Package: xlibs Version: 4.1.0-16woody5 Severity: normal *** Please type your report below this line *** At this time, I'm no longer able to conveniently reproduce the problem. Having noted that 4.1.0-16woody6 was released a while ago, I released the hold on 4.1.0-16woody4, and upgraded to 4.1.0-16woody5, to see if the problem would still be reproducible at this point, and I found that I'm no longer able to reproduce the bug that easily. Most likely the bug (which was quite reproducible when originally reported) lies within negative interaction between 4.1.0-16woody5, and earlier versions of packages depending upon that and/or fvwm and/or fvwm2. There have also been some changes in XFree86 configuration (both package versions, and also /etc/X11/XF86Config-4) in the months that have passed, so that may also have been a factor. It's also possible some other interaction may have triggered the bug (I've done roughly 133 individual package upgrades since the problem was originally reported - the particular system is mostly a Woody/Sarge hybrid, and periodically tracks the relevant security and other updates). -- System Information: Debian Release: 3.0 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.4.29 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages xlibs depends on: ii libc62.3.2.ds1-20GNU C Library: Shared libraries an ii libfreetype6 2.0.9-1 FreeType 2 font engine, shared lib ii xfree86-common 4.3.0.dfsg.1-10 X Window System (XFree86) infrastr ii xlibs4.1.0-16woody5 X Window System client libraries Versions of packages fvwm depends on: ii libc6 2.3.2.ds1-20 GNU C Library: Shared libraries an ii libglib1.21.2.10-4 The GLib library of C routines ii libgtk1.2 1.2.10-11 The GIMP Toolkit set of widgets fo ii libncurses5 5.4-4 Shared libraries for terminal hand ii libreadline4 4.3-11 GNU readline and history libraries ii libstroke00.5.1-2support for mouse strokes like tho ii xlibs 4.1.0-16woody5 X Window System client libraries Versions of packages fvwm2 depends on: ii fvwm 2.4.6-2F(?) Virtual Window Manager, versi -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#291875: fvwm info
Package: fvwm Version: 2.4.6-2 Severity: wishlist -- System Information Debian Release: 3.0 Architecture: i386 Kernel: Linux blackie.creasys.berkeley.ca.us 2.4.27 #1 Mon Sep 13 19:20:37 PDT 2004 i686 Locale: LANG=C, LC_CTYPE=C Versions of packages fvwm depends on: ii libc62.3.2.ds1-20GNU C Library: Shared libraries an ii libglib1.2 1.2.10-4The GLib library of C routines ii libgtk1.21.2.10-11 The GIMP Toolkit set of widgets fo ii libncurses5 5.2.20020112a-7 Shared libraries for terminal hand ii libreadline4 4.2a-5 GNU readline and history libraries ii libstroke0 0.5.1-2 support for mouse strokes like tho hi xlibs4.1.0-16woody4 X Window System client libraries -- [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#291880: fvwm2 info
Package: fvwm2 Version: 2.3 Severity: wishlist -- System Information Debian Release: 3.0 Architecture: i386 Kernel: Linux blackie.creasys.berkeley.ca.us 2.4.27 #1 Mon Sep 13 19:20:37 PDT 2004 i686 Locale: LANG=C, LC_CTYPE=C Versions of packages fvwm2 depends on: ii fvwm 2.4.6-2F(?) Virtual Window Manager, versi -- [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#291880: Please cancel: Bug#291875 and Bug#291880
Please cancel: Bug#291875 and Bug#291880 ... seems I stubmled across reportbug Bug#175297 while gathering more information for Bug#291869 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#291869: fvwm/fvwm2 versions/dependency data
Here's fvwm/fvwm2 information I intended[1] to also include on the original report: Package: fvwm Version: 2.4.6-2 Versions of packages fvwm depends on: ii libc62.3.2.ds1-20GNU C Library: Shared libraries an ii libglib1.2 1.2.10-4The GLib library of C routines ii libgtk1.21.2.10-11 The GIMP Toolkit set of widgets fo ii libncurses5 5.2.20020112a-7 Shared libraries for terminal hand ii libreadline4 4.2a-5 GNU readline and history libraries ii libstroke0 0.5.1-2 support for mouse strokes like tho ii xlibs4.1.0-16woody5 X Window System client libraries Package: fvwm2 Version: 2.3 Versions of packages fvwm2 depends on: ii fvwm 2.4.6-2F(?) Virtual Window Manager, versi Footnotes: 1. I stubmled across reportbug Bug#175297, and hence the report was submitted before I got to add the fvwm/fvwm2 version and dependency information to it. -- [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
