Bug#525315: connect/disconnect loops with ifupdown and wpa_supplicant in roaming mode
Package: ifupdown
Version: 0.8.35+b1
Followup-For: Bug #525315
Hey,
I'm pretty sure this should be filed as a bug to wpasupplicant.
In my case (same phenomena on display as OP reported), increasing the
hysteresis timeout to 10 seconds was enough to stop the cycling reliably.
For the record that would be 10 seconds (instead of 4) in
wpa_hysteresis_check() in /etc/wpa_supplicant/functions.sh (a
pro-forma patch is attached).
The actual question here is: how do I debug this cycle properly?
--- a/wpa_supplicant/functions.sh
+++ b/wpa_supplicant/functions.sh
@@ -847,9 +847,10 @@ wpa_hysteresis_check () {
local TIME
local TIMESTAMP
local TIMEWAIT
+ local TIMEDELTA=10
TIME=$(date +%s)
- # current time minus 4 second event buffer
- TIMEWAIT=$(($TIME-4))
+ # current time minus TIMEDELTA second event buffer
+ TIMEWAIT=$((TIME-TIMEDELTA))
# get time of last event
TIMESTAMP=$(cat $WPA_CLI_TIMESTAMP)
# compare values, allowing new action to be processed
Bug#851464: prosody: Please suggest/recommend python-bcrypt (provides bcrypt auth backend)
Package: prosody Version: 0.9.11-1 Severity: wishlist Dear Maintainer, bcrypt is one of the hash algorithms looked upon more favourably. Prosody supports it, yet the package makes no mention of it. Could we recommend/suggest it? Also: kudos for your on-the-button packaging! Yours, Hagen
Bug#851183: fenics: Misses important 'mshr' module
Dear Johannes, > No, not really - none of the demo programs in DOLFIN uses mshr. Got me there. The project I'm contributing to (micromagnetics software) switched to it and the only two examples I've found of any interest were using it. I /might/ have extrapolated a bit. ;) > mshr is already packaged for Debian[...] Again: thanks for your work! > mshr needs a patched version of CGAL. Ouf. Anything I can do or is it simply a matter of just waiting for the maintainers? -Hagen
Bug#851183: fenics: Misses important 'mshr' module
Package: fenics Version: 2016.2.0.1 Severity: important Hello, Fenics/Dolfin contains the core module 'mshr' which deals in meshes. All current examples seem to be employing 'mshr', eg. https://fenicsproject.org/qa/9414/fenics-mesh-generation-mark-inner-region The Fenics project page mentions that simply installing Fenics should bring 'mshr' along, so maybe/hopefully this is a simple matter to resolve. (Knowing Fenics, it most probably isn't.) Many thanks for packaging the newest Fenics versions in any case! If I can help in any capacity, shoot. Regards, Hagen
Bug#793740: kwrite: spell checking does not work at all
Hey, Alright, running kwrite with:: LANGUAGE=en LANG=en kwrite works (with spotty highlighting for auto-check, but yeah). My locale says:: LANG=en_GB.utf8 LANGUAGE=en_GB:en however. I installed everything (on a clean slate Debian testing machine) by saying:: aptitude install kwrite sonnet-plugins aspell-en hunspell-en-gb \ kde-cli-tools libqt5xcbqpa5 Note, I'm not running a KDE environment, hence the 'libqt5xcbqpa5' package. I'm simply using kwrite in XFCE (not even that's entirely true, as I'm reporting this bug for somebody else :). The kde-cli-tools report failure, too:: $ kcmshell5 spellchecking Could not find module 'spellchecking'. See kcmshell5 --list for the full list of modules. Nevertheless, I did a complete purge and reinstall cycle, even went so far as to install 'plasma-framework' (I have no stomach to try task-kde-desktop). However, none of the above changed. Hypothesis: hunspell is never asked. Supporting: Removing aspell-en yields the same behaviour as before, this time with No language dictionaries for the language: "en" in the terminal. Also: > [copious strace output] > > As you can see, it finds (and then loads) all the plugins. Yes. Yes, it does. My point was, however, that a '/usr//usr/' path anywhere can't be healthy. But it can possibly safely be ignored, I wouldn't know. Thanks!
Bug#793740: kwrite: spell checking does not work at all
Hi,
> Do you have sonnet-plugins installed?
Yes. I also tried to provide different backends (aspell, hunspell,
myspell) exclusively and all together. No dice.
Note again, that after starting kwrite with eg.
strace -s 512 kwrite |& grep 'sonnet'
I'm still seeing the line
stat("/usr//usr/lib/x86_64-linux-gnu/qt5/plugins/kf5/sonnet", 0x7fff8cff2920)
= -1 ENOENT (No such file or directory)
immediately after selecting 'Tools > Spelling > Spelling ...'.
Thanks for looking into it!
-Hagen
Bug#793740: kwrite: spell checking does not work at all
Package: kwrite
Followup-For: Bug #793740
Hi,
Discovering that the bug is happily alive, I tinkered a bit with with
strace. One of the lines that appears after activating the
spell-checker reads::
stat("/usr//usr/lib/x86_64-linux-gnu/qt5/plugins/kf5/sonnet", 0x7ffe5537a0b0)
= -1 ENOENT (No such file or directory)
Note the '/usr//usr/' part. I haven't looked at the source. /2¢
-Hagen
Bug#767864: units should recommend python-unidecode
Hi, Both these fixes will be in the first upload after Jessie releases. Grand, thanks! -Hagen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#767864: units should recommend python-unidecode
Package: units Version: 2.11-1 Followup-For: Bug #767864 Hello, Thanks for maintaining units! Love it. I have two suggestions, 1) Simply a refinement of Mike's proposal: Depend on or suggest python-unidecode instead of python:all, it's compatible with Python 2 and 3, so this does the trick just as well. 2) Change units_cur a bit to avoid warnings from unidecode when trying to decode simple ASCII strings. With that, I can run units_cur every week or so as a cronjob without reading unidecode's RuntimeWarning over and over again. Here's the patch (unified diff): --- /usr/bin/units_cur 2014-04-09 07:35:56.0 +0200 +++ units_cur 2015-03-24 11:56:15.584269473 +0100 @@ -50,8 +50,8 @@ for i in xrange(len(names)): if names[i] == 'anguilla(ecd)': names[i] = 'eastcaribbeandollar' - ascii = unidecode(names[i]) - if names[i] != ascii: + if type(names[i]) != str: +ascii = unidecode(names[i]) if not foundunicode: foundunicode = True outstr += '# Unicode Currency Names\n\n!utf8\n' -Hagen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#377548: usbmount: Fails mounting some parts in a n-in-1 device
Hello, https://github.com/hfuchs/usbmount/tree/hfuchs.377548 This version has a bug, though: [...] The problem is that $mountpoint is now set within a subshell[.] Fixed. Using command groups now instead of that blasted subshell. Updated on Github. (Shell scripting is never fun.) Do not deride my evening's entertainment! ;) Thanks, Hagen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#676554: usbmount: no write permission on hotplugged usb devices: PLEASE CLOSE
Package: usbmount Followup-For: Bug #676554 Hi, Please close the bug report. There's nothing to do here. The problem seems specific to the original poster's configuration (and might, of course, be caused by what Edward described!). Don't keep idle bug reports around, please close. Thanks! -Hagen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#759530: libc-bin: ldconfig breaks a system
Package: libc-bin
Version: 2.19-11
Followup-For: Bug #759530
Hello!
Something similar happened to me (after upgrade to 2.19-11). If this
report wasn't on top of libc-bin and absolutely recent, I would not have
said a word: read on!
Foundation-laying: the scenario. All packages that call ldconfig in their
install scripts started sputtering like this one:
Setting up golang (2:1.3.2-1) ...
Processing triggers for libc-bin (2.19-11) ...
Segmentation fault
/sbin/ldconfig.real: Path `/lib/x86_64-linux-gnu' given more than once
/sbin/ldconfig.real: Path `/usr/lib/x86_64-linux-gnu' given more than once
/usr/lib/x86_64-linux-gnu/libfakeroot:
libfakeroot-0.so - libfakeroot-tcp.so
/usr/local/lib:
/lib/x86_64-linux-gnu:
libthread_db.so.1 - libthread_db-1.0.so
[...]
libglib-2.0.so.0 - libglib-2.0.so.0.4200.0
/usr/lib/x86_64-linux-gnu:
Segmentation fault
dpkg: error processing package libc-bin (--configure):
subprocess installed post-installation script returned error exit status 139
Errors were encountered while processing:
libc-bin
Hu? ldconfig dies like this (strace):
[natural-looking output]
stat(/usr/lib/x86_64-linux-gnu/libQtScript.so.4, {st_mode=S_IFREG|0644,
st_size=2692504, ...}) = 0
stat(/usr/lib/x86_64-linux-gnu/libjasper.so.1, unfinished ...
+++ killed by SIGSEGV +++
Segmentation fault
Oh?
# file /usr/lib/x86_64-linux-gnu/libjasper.so.1
Segmentation fault
Drastic measures (wtf?):
# ls !$
ls /usr/lib/x86_64-linux-gnu/libjasper.so.1
Segmentation fault
# rm /usr/lib/x86_64-linux-gnu/libjasper.so.1
Segmentation fault
# unlink !$
unlink /usr/lib/x86_64-linux-gnu/libjasper.so.1
# ls /usr/lib/x86_64-linux-gnu/libjasper.so.1
ls: cannot access /usr/lib/x86_64-linux-gnu/libjasper.so.1: No such file or
directory
Done (reinstall libjasper1).
Now, ordinarily, I'd say: severe FS corruption, something or other.
But, with this report on top, perhaps there's something deeper going on.
No idea.
Note: I now have no way of returning to the broken state.
I doubt anyone can profit from this, but I had to throw it in (as I
already mentioned).
Such is my tale of woe.
Regards,
Hagen
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#377548: usbmount: Fails mounting some parts in a n-in-1 device
Package: usbmount Followup-For: Bug #377548 Hi! Frédéric's reply to this bugreport warmed my heart and I was inspired to do what I promised Rogério a couple of years ago: solve all of usbmount's problems. ;) While Frédéric's approach is outstandingly creative, I think we can address #377548 and #403209 simply by switching to another locking approach. I replaced all calls to utilities from 'lockfile-progs' by one to flock(1), thereby gaining: 1) Even less dependencies (and LOC); flock comes from the essential package 'util-linux'. 2) A snappy locking implementation that doesn't wait in increments of 5, 10, 15, ... seconds like lockfile-* does. (WTF!) I tested with a pen drive that has 20 partitions, different file systems and I consistently mount all of 'em under 4 seconds. I have a bugfix-branch of upstream, https://github.com/hfuchs/usbmount/tree/hfuchs.377548 which contains only the necessary changes (almost: I also handle the /var/run - /run transition because it's the same code region). (Don't forget: There's another one for #658028!) -Hagen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#377548: usbmount: Fails mounting some parts in a n-in-1 device
Hi there! [flock(1)] I feel silly for not having been aware of that simple command. :) Well, its handling is a bit weird (take a look at the 'third form' description in the man page), but it does the job amiably. Also: I spent a ludicrous amount of time trying to make usbmount lockless. -Hagen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#676554: usbmount: no write permission on hotplugged usb devices (CLOSE)
Package: usbmount Followup-For: Bug #676554 Hi, As nobody yelled during the last month, I strongly suggest we close this bug report. If in future anything similar occurs, there's nothing stopping anybody from filing a new bug or requesting to reopen this one. Regards, Hagen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#666059: clusterssh: cssh does not deal well with compound commands
Package: clusterssh Followup-For: Bug #666059 Hello, Please close this report - clusterssh does not exhibit the bug any more. I wrote the following over two years ago, but for some reason it never reached the server (probably missing pseudo-header): Upstream fixed the problem in question (employing the exact same method I proposed :). See https://github.com/duncs/clusterssh/commit/cb3aa92febd16c8af901066dffd9f428c8ef255a Regards, Hagen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#658028: usbmount: Udev should not wait for mounting
Package: usbmount Followup-For: Bug #658028 This is indeed a very valid concern (not that I have been affected personally). Quite a few scripts in /lib/udev/rules.d seem to be doing things that might take a while or even hang. I'm surprised, honestly. In any case, I imagine usbmount's udev compliance could be trivially ensured: make 'usbmount' a wrapper that calls, say, usbmount.real proper with all the banalities, insecurities, hopes and despair that comes with it. I created a branch of the alioth upstream sources that implements precisely this change, https://github.com/hfuchs/usbmount/tree/hfuchs.658028 and also renames usbmount.rules - 90-usbmount.rules because it seemed proper (all of the other rule scripts start with some ordering number, only usbmount stood out :). How about it? -Hagen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#676554: usbmount: no write permission on hotplugged usb devices
Package: usbmount Followup-For: Bug #676554 Hello, All my hotplugged usb devices are owned by root and only writable by the superuser. This can't possibly be the way this is supposed to work. It's not. Rather, I'd suggest that somewhere along the line something got misconfigured. Do reply if you're still affected by/interested in this, josh! Otherwise I suggest we close this report in, say 30 days. I'll be back, eh? Regards, Hagen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#743378: workstation.d/kernel: trivial fix for reworded Caching mode page messages
Package: logcheck-database
Version: 1.3.16
Severity: normal
Tags: patch
Hello,
Attached you'll find a trivial patch that enables
'ignore.d.workstation/kernel' to capture the recently reworded message
No Caching mode page present (nowadays its present - found).
Thanks,
Hagen
diff --git a/logcheck/ignore.d.workstation/kernel b/logcheck/ignore.d.workstation/kernel
index 53cd1dc..2bc9f80 100644
--- a/logcheck/ignore.d.workstation/kernel
+++ b/logcheck/ignore.d.workstation/kernel
@@ -61,7 +61,7 @@
^\w{3} [ :[:digit:]]{11} [._[:alnum:]-]+ kernel:( \[ *[[:digit:]]+\.[[:digit:]]+\])? sd [:[:digit:]]+: \[sd[a-z]\] [[:digit:]]+-byte physical blocks$
^\w{3} [ :[:digit:]]{11} [._[:alnum:]-]+ kernel:( \[ *[[:digit:]]+\.[[:digit:]]+\])? sd [:[:digit:]]+: \[sd[a-z]\] Write Protect is (off|on)$
^\w{3} [ :[:digit:]]{11} [._[:alnum:]-]+ kernel:( \[ *[[:digit:]]+\.[[:digit:]]+\])? sd [:[:digit:]]+: \[sd[a-z]\] Mode Sense: [[:xdigit:]]+ [[:xdigit:]]+ [[:xdigit:]]+ [[:xdigit:]]+$
-^\w{3} [ :[:digit:]]{11} [._[:alnum:]-]+ kernel:( \[ *[[:digit:]]+\.[[:digit:]]+\])? sd [:[:digit:]]+: \[sd[a-z]\] No Caching mode page present$
+^\w{3} [ :[:digit:]]{11} [._[:alnum:]-]+ kernel:( \[ *[[:digit:]]+\.[[:digit:]]+\])? sd [:[:digit:]]+: \[sd[a-z]\] No Caching mode page (present|found)$
^\w{3} [ :[:digit:]]{11} [._[:alnum:]-]+ kernel:( \[ *[[:digit:]]+\.[[:digit:]]+\])? sd [:[:digit:]]+: \[sd[a-z]\] Assuming drive cache: write through$
^\w{3} [ :[:digit:]]{11} [._[:alnum:]-]+ kernel:( \[ *[[:digit:]]+\.[[:digit:]]+\])? sd [:[:digit:]]+: \[sd[a-z]\] Spinning up disk\.\.\.\.ready$
^\w{3} [ :[:digit:]]{11} [._[:alnum:]-]+ kernel:( \[ *[[:digit:]]+\.[[:digit:]]+\])? [[:space:]]*sd[a-z]:( sd[a-z][[:digit:]]+)*$
Bug#717245: cups-daemon: Bonjour record changed format from printer@host.domain to printer@host in 1.6
Hello, For posteriority and vanity's sake: I did indeed write a script for the transition period from long to short Bonjour names as advertised by CUPS[0]. It turned out surprisingly effective and stable, so I decided to keep the script around instead of just throwing it away. Perhaps somebody finds it a useful starting point for the same or a similar problem. The thing's called Bonjour Aliases and was in productive use for the last three months at the aforementioned research institute. I put the code up on Github: https://github.com/hfuchs/bonjour_aliases The thing is written in Python and needs one additional module called pybonjour[1] which is not (yet) in the Debian repository. This excellently documented library is essentially doing the heavy lifting. I provide a fleshed-out README and a run-script for use with 'daemontools' or 'runit'. So, for me, the problem is solved and this bugreport may be closed. Thanks! -Hagen [0] Now don't you go round changing it back again! :) [1] https://code.google.com/p/pybonjour/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#722332: libcommon-sense-perl: common::sense runs into trouble with Perl 5.18, eg. no say().
First of all: Nice response time! I'm always in awe of Debian maintainers'
work ethic.
In response to your last comment,
I've committed the changes for the first point; reviews welcome!
I'm not sure how I can review those changes? I `dpkg -i`'d the unstable
version of libcommon-sense-perl, but it's the same thing as before.
What am I missing?
Meanwhile, here's the results of a little investigation of my own:
Executive summary.
This is probably a case for upstream: they'll have to adapt their use of
the '$^H' variable.
Longer version.
The common::sense module's really short, so I tried poking in the source
a bit. Turns out, there's quite a bit of eye-candy; among those the use
of the magic variable '$^H'. `perldoc perlvar` says:
$^H WARNING: This variable is strictly for internal use only.
Its availability, behavior, and contents are subject to change
without notice.
So ... the gods went ahead and changed it, hu? My best guess for
where to look is feature.pm and the difference between 5.14 and 5.18:
https://metacpan.org/source/DAPM/perl-5.14.4/lib/feature.pm
https://metacpan.org/source/RJBS/perl-5.18.1/lib/feature.pm
Rabbit hole! Turns out, in 5.18, $^H is now initialized(?) with
$hint_mask= 0x1c00;
[...]
sub __common {
[...]
$^H |= $hint_mask;
And, of course, a few more manglings happen. Now, simply saying
sed -i 's|0x820f00|0x1c00|' /usr/lib/perl5/common/sense.pm
does the trick:
$ perl -Mcommon::sense -e 'say $common::sense::VERSION; say $^V; say Hi!;'
3.72
v5.18.1
Hi!
(Mind, this naïve substitution is all kinds of wrong -- this is a bitmask with
definitive meaning and will quite probably still not work for all other
use cases of common::sense (utf8, switch, ...) or even introduce more
subtle errors!)
In conclusion, I hope to have established a case for upstream to become
involved.
Regards,
Hagen
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#722332: libcommon-sense-perl: common::sense runs into trouble with Perl 5.18, eg. no say().
[package tracking system and git repository] I see, thanks! Wondering if we should clone it with lowered severity for a more elegant fix. Comments? Executive Sum.: Upstream is cleared of any wrongdoing, common::sense needs to be built for every Perl version anew. Longer: I've been delving into common::sense's source and realized that the magic number (0x820f00 in the old version's case) is actually set correctly according to Perl version in the build script, sense.pm.PL . So, if common::sense is being built with Perl 5.18 it will work with 5.18 but not with 5.14 and perhaps not even with 5.20 (due to the fast-changing Perl 'feature' facility evinced by the ephemeral nature of $^H). So the line sed -i 's|0x820f00|0x1c00|' /usr/lib/perl5/common/sense.pm simply worked, because it reset the 5.14 $^H to a version that's at least length-wise compatible with 5.18's. Does that make any ... No, no cheap pun today. That's a bit of a bummer for the package's progression through unstable-testing-stable, though, isn't it? Or is that only a problem in my mind? Regards, Hagen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#722332: libcommon-sense-perl: common::sense runs into trouble with Perl 5.18, eg. no say().
Hi! Sorry for not mentioning this in my first reply. More embarrassing hand-holding? :) Alright, as you guys have this thing covered on all angles, I'll just say this: Awesome work! (I need new vocabulary.) I'm actually looking forward to my next bug report. Sadly enough, I really do. Yours, Hagen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#722332: libcommon-sense-perl: common::sense runs into trouble with Perl 5.18, eg. no say().
Package: libcommon-sense-perl Version: 3.72-1 Severity: grave Justification: renders package unusable Dear maintainer, I just noticed that, upon upgrading to Perl 5.18.1-3 (Debian testing), common::sense stopped having some: $ perl -Mcommon::sense -e 'say hi;' syntax error at -e line 1, near say hi Execution of -e aborted due to compilation errors. On another machine with Perl 5.14 still installed and the same version of libcommon-sense-perl (3.72-1) it's still the same friendly response: $ perl -Mcommon::sense -e 'say hi;' hi So, *something* happened upon upgrading, although I'm currently at a loss (of time, mainly) to specify what exactly. Surely I messed something up and everything's working fine for everybody else? Thank you! Regards, Hagen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#693604: [Pkg-utopia-maintainers] Bug#693604: avahi-daemon takes 100% CPU right after boot and at every restart of CUPS
Hello again, That's me back-tracking. Otmar was absolutely right: The load excursions started again (after three months, quite suddenly); reliably, usually at least twice a day with a production print server on Debian Wheezy. Again, Till Kamppeter's patch referenced earlier fixed it (as it did for Otmar). I have *no* idea what causes this. Other print servers -- configured in precisely the same way, seeing about the same usage -- are fine. Please consider the patch for adoption. Thanks, Hagen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#717245: cups-daemon: Bonjour record changed format from printer@host.domain to printer@host in 1.6
Hello again, Thanks for the effort, appreciate it! I have now pretty much exhausted my options by playing with Avahi's settings (and CUPSens, for all I know). For example, I set browse-domain=domain.local in Avahi's config and got at least my Ubuntu test client to go along with that. Not Macs, of course, they aren't quite as forgiving. My options reduce to: 1. Make a clone of every CUPS 1.5 machine and keep it running alongside the updated machines for as long as the domain-nodomain transition lasts; or 2. Write a small script that takes every nodomain record and creates a replica with only the 'Service Name' field changed to the old form. #2 seems promising and something I'd look forward to do (wield that old 800 pound chainsaw again). I will call the project 'Avahi Aliases' -- it will be an instant classic. :) Input/concerns welcome (for example, I have as yet no idea on how to get/inject Bonjour packets out of/into Avahi)! -Hagen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#717245: cups-daemon: Bonjour record changed format from printer@host.domain to printer@host in 1.6
Hi Brian, Thanks for the quick reply! The only way I can get the second type of record permanently is by putting it in /etc/hostname, which I believe is read by avahi-daemon. Ah, well now we're going into interesting territory. My /etc/hostname actually says 'cups4dhcp'[0]. I have set CUPS' ServerName to 'cups.pks.mpg.de' and assume this was the name used for the Bonjour record. Is there a way to debug the communication between avahi-daemon and cupsd that doesn't involve an actual debugger? I found avahi-daemon's '--debug' switch to be not that verbose. Is your Debian testing a new install or an upgrade from Wheezy? My servers are all on 'testing' as in 'eternal testing'. :) That probably means the answer is upgrade from Wheezy. I'll keep digging around... -Hagen [0] It's not quite easy to explain, but I'll try: I have *4* CUPS servers that serve different physical subnets (eg. LAN and WLAN). I chose the odd CUPS ServerName-setting in order to ensure that MacOS clients always see the same Bonjour name, instead of 'printer @ cups4dhcp.pks.mpg.de' when connected via cable and 'printer @ cups4wlan.pks.mpg.de' when in the WLAN. MacOS assumes they're different printers, so unhappiness quickly ensues. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#717245: cups-daemon: Bonjour record changed format from printer@host.domain to printer@host in 1.6
Package: cups-daemon Version: 1.6.2-10 Severity: important Hello! I am using CUPS in Debian testing to provide access to a pool of 30+ printers to all sorts of OSes (research institute). Switching from CUPS 1.5.3 to 1.6.2, I noticed that it registers its Bonjour records differently with Avahi: `avahi-browse -a` now shows + eth0 IPv4 ps22 @ cups Internet Printer local instead of + eth0 IPv4 ps22 @ cups.pks.mpg.deInternet Printer local This change, unfortunately, breaks printing to these printers from all MacOS systems. A work-around would be to remove all Bonjour-printers from the clients' systems and re-add them again. Considering our user base and the nerves of our IT support team, I'd much prefer to keep the old record format. So, is this change intentional? If so, is there a way to revert to the old format with CUPS 1.6? (I have been playing with 'ServerName', 'ServerAlias' settings in cupsd.conf -- to no avail. I also tried changing the 'host-name' parameter in Avahi -- dito.) Thanks! Regards, Hagen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#693604: [Pkg-utopia-maintainers] Bug#693604: avahi-daemon takes 100% CPU right after boot and at every restart of CUPS
Hello, About two weeks ago I replaced all my locally modified packages with those in testing (which are currently the same version as in stable: 0.6.31-2). In that period approx. 4000 print jobs have gone over our four print servers and none of them showed any signs of the aforementioned load excursion. Previously, not a day went by without going on a hunt for rogue Avahi daemons. So, I guess either Avahi's been patched silently or some other condition remedies (masks?) the problem. In any case, from my point of view, it would make sense to reduce the severity or even close the bug report now. Thanks! -Hagen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#693604: avahi-daemon takes 100% CPU right after boot and at every restart of CUPS
Package: avahi-daemon Followup-For: Bug #693604 Hello, I can confirm that applying the patch mentioned above[0] directly on the Debian avahi-sources stopped these occurrences. To be clear: Avahi /never/ recovers from these load excursions and stays at ~100% until killed. In our environment of 39 print queues (about 30 physical printers) this had become rather a serious headache with multiple daily occurrences. I wrote a rather desperate script that would minutely check for Avahi's well-being. After applying the patch about two weeks ago, it (the script) recorded not one instance of permanent overload. More tidbits: I have/had two servers exhibiting this behaviour (from a total of four). They multicast into different subnets. One is a x86_64 KVM machine, the other a i686 OpenVZ container. Also, the behaviour occurs in heavily MacOS-infes...frequented subnets. Thanks! -Hagen [0] Direct link: https://bugs.launchpad.net/ubuntu/+source/avahi/+bug/1059286/+attachment/3387784/+files/avahi_0.6.31-1ubuntu1_0.6.31-1ubuntu2.debdiff -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#669388: wicd-daemon: Fix for CVE-2012-2095 invalidates all templates that use 'ca_cert', 'password' and other fields.
Package: wicd-daemon
Version: 1.7.2.1-1
Severity: grave
Tags: upstream
Justification: renders package unusable
Hi there,
[tl;dr. wicd 1.7.2 (upstream development revision 751) introduces
a fatal bug that invalidates many connection templates.]
I just upgraded my wicd installation (to Wheezy's 1.7.2) and witnessed
my wireless connection fail. wicd's log file contains entries that read
2012/04/19 13:10:22 :: Trying to set invalid property (or property not
permitted): ca_cert.
2012/04/19 13:10:22 :: Trying to set invalid property (or property not
permitted): password.
2012/04/19 13:10:22 :: Trying to set invalid property (or property not
permitted): identity.
Those settings will accordingly not be reflected in
/etc/wicd/wireless-settings.conf or /var/lib/wicd/configurations/*.
I (quickly :) realized that the changes introduced in reaction to
CVE-2012-2095 where to blame. So, without further ado, I'll point you
the appropriate patch:
http://bazaar.launchpad.net/~wicd-devel/wicd/experimental/revision/751/wicd/wicd-daemon.py
The properties that `self._validProperties` introduces are *nowhere
near* a complete representation of supported wpa_supplicant fields
(which it quite probably should!). Just to be sure, I consulted
wpa_supplicant.conf(5) and found all of the invalid properties above
used in examples.
Finally, I applied the patch below to
/usr/share/wicd/daemon/wicd-daemon.py and could 'appily browse again
(thus the bug report :).
I suggest you get this to upstream's attentation as quickly as possible
as quite a few of wicd's own templates are now invalid. Hence the
elevated priority (I *do* hope, I'm not wrong on this ... ).
Thanks!
Regards,
Hagen Fuchs
Trivial proof-of-concept patch (diff -wu wicd-daemon.py*):
--- wicd-daemon.py 2012-04-19 15:35:52.023010442 +0200
+++ wicd-daemon.py.hfuchs 2012-04-19 15:55:04.830971520 +0200
@@ -1087,9 +1087,10 @@
Sets property to value in network specified.
# We don't write script settings here.
if prop.strip() not in self._validProperties:
-print Trying to set invalid property (or property not \
- permitted): + prop.strip() + .
-return False
+print I'll allow that - for now! :)
+#print Trying to set invalid property (or property not \
+# permitted): + prop.strip() + .
+#return False
self.LastScan[netid][prop] = misc.to_unicode(misc.Noneify(value))
@dbus.service.method('org.wicd.daemon.wireless')
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#669388: wicd-daemon: Fix for CVE-2012-2095 invalidates all templates that use 'ca_cert', 'password' and other fields.
Hello David, Unfortunately, I'm the only upstream developer, so I can't really test every possible scenario. Well, you're doing one hell of a job. wicd is my prime architectural role models for UI server-client architecture. One of those keep in mind for the big thing projects. I'm really sorry for having introduced such a nasty bug. It's your software, do as you like. ;) I hope I'll be able to release 1.7.2.2 later tonight, when I'll be back home from work. Marvellous! I'll stop heaping kudos now and wait till rev 759 hits the repo (or should it already have done so?). Yours, Hagen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#669388: wicd-daemon: Fix for CVE-2012-2095 invalidates all templates that use 'ca_cert', 'password' and other fields.
Hi, I already uploaded it a while ago, so if it doesn't tonight, it surely will be tomorrow :) I was actually looking forward to digging around in the code a bit tonight, but you were simply too fast - I didn't realize that you not only fixed the thing but also packaged it by now. Impressive response time. Got to be nimble on my feet next time. Thanks again, Hagen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#666059: clusterssh: cssh does not deal well with compound commands
Package: clusterssh
Version: 4.00_11
Severity: normal
Tags: upstream
Hello,
I am in the unenviable position to report a bug on behalf of a
colleague, whom I explained the behaviour described below to. He
subsequently lost interest and my almost-finished, rather lucidly
written script that reproduced the critical cssh-features lingered sadly
on my drive ever since. No more! Here we go:
ClusterSSH does not deal well with compound commands as handed to the
'-a' flag, eg.
cssh [remote_server] -a cd /; ls; sleep 10
The directory listed will be the local working directory, /not/ the
remote root directory.
I elaborated on this in a separate Perl script, available on Github[0]
and attached. The comment section does a good job (I'm a bit
self-aggrandising today, am I not?) explaining, but heavily references
the (very small) code section of the script. For this reason, I am not
including the description here and instead would like to refer you to
the script.
In addition the script offers a naïve solution!
Sorry for the wild circumstancial mess.
Yours,
Hagen
[0] https://github.com/hfuchs/misc/blob/master/cssh_action_test.pl
#!/usr/bin/perl
# 2011-11-04, Created by Hagen Fuchs hagen.fu...@physik.tu-dresden.de
#
# Purpose: ClusterSSH does not deal well with compound commands as
# handed to the '-a' flag, eg.
#
# cssh [remote_server] -a cd /; ls; sleep 10
#
# The directory listed will be the local working directory, /not/ the
# remote root directory. This file is a working example that exhibits
# the precise same behaviour. Almost all of the code here has been
# pasted and shortened to its essence from App/ClusterSSH.pm (in
# /usr/share/perl5 on my system). That makes it slightly longer than
# strictly necessary but code here can now easily be matched with code
# in the ClusterSSH module.
#
# Looking at the eval()ed and exec()ed strings below, one can easily see
# how appropriate quoting will break the expression in $helper_script.
# Eg. trying to protect the inner expression with single quotes,
#
# cssh [remote_server] -a 'cd /; ls; sleep 10'
#
# or
#
# perl cluster_test.pl [remote_server] -a 'cd /; ls; sleep 20'
#
# will spectacularly fail. On the other hand, an expression like
#
# perl cluster_test.pl [remote_server] -a \\\cd /; ls; sleep 20\\\
#
# works as it transports both backslashes and quotes safely through
# two layers of string interpolation (first Perl's, then the shell's).
# This translates straightforward into
#
# cssh [cluster] -a \\\cd /; ls; sleep 10\\\
#
#
# Proposed Solution:
# --
# Naïvely, I'd say substitute $config{command} in $helper_script with
# the unwieldy construct
#
# \\\$config{command}\\\
#
# and be done with it. But deep down I'd know: this whole part needs
# more thought and less brittle quoting magic.
use common::sense; # Where else, if not here? ;)
use Pod::Usage;
use Getopt::Long qw(:config no_ignore_case bundling no_auto_abbrev);
my @options_spec = ( 'action|a=s' );
my %options;
my %config;
pod2usage( -verbose = 1 )
if ( !GetOptions( \%options, @options_spec ) );
$config{command} = $options{action} if ( $options{action} );
my @servers = @ARGV;
my $helper_script = HERE;
my \$command = ssh $servers[0];
\$command .= \\\$config{command}\\\ || sleep 5;
exec(\$command);
HERE
#eval $helper_script || die ($@);
my $exec = xterm -e \$^X\ \-e\ '$helper_script';
# hfuchs| Diagnostics (not in ClusterSSH).
say Helper Script:;
say $helper_script;
say Exec Line:;
say $exec;
exec($exec) == 0 or die $!;
Bug#377548: Fails mounting some parts in a n-in-1 device
Hello again, I was pondering a lock-less solution and your patches seem to provide a good upgrade path towards that. Unfortunately: $ git clone git://git.katzien.de/usbmount.git Cloning into usbmount... git.katzien.de[0: 82.165.99.49]: errno=Connection timed out fatal: unable to connect a socket (Connection timed out) Thanks for the quick response! Yours, Hagen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#377548: Fails mounting some parts in a n-in-1 device
Package: usbmount Severity: normal Hello, I tested Jan's patch with a flash drive that has 12 partitions on it. The original position of the locking code just at the beginning of the add handler will usually only be able to mount 3 to 4 partitions on my machine before lockfile-create will give up. Jan has proposed a more logical position right before usbmount actually deals with the outside world - putting the locking code there (as a whole or as a function call) will consistently yield the expected usbmount behaviour: mounting of all 12 partitions. This solution doesn't scale very well either, though, because we're using `lockfile-create --retry 3` which waits in fixed time intervals between retries (+5sec on every retry, ie 15sec after the third try), thus increasing the likelihood of deadlocks. In my 12-partition-scenario, the last partitions get sometimes mounted in the third (and last) retry cycle of lockfile-create (after ~30 sec). In any case, we should adopt Jan's patch, thereby closing this bug for n-in-1 devices where n 10. Regards, Hagen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#403209: locking - necessary to avoid long wait for multi-device card reader
Package: usbmount Severity: normal Hello, I just now perused the changelog and saw the message for version 0.0.17.1: revert patch from #403209 (seems to introduce race conditions) Seems, I should familiarize myself with the code /and/ its history, before going off and analysing code from my chair when its already been proven not to work. Sorry for that. Regards, Hagen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#403209: locking - necessary to avoid long wait for multi-device card reader
Package: usbmount Severity: normal Hello Richard, Rogério, Won't per-device locking eventually produce race conditions? Specifically, I'm looking at the code that allocates a mount point: # Search an available mountpoint. for v in $MOUNTPOINTS; do if [ -d $v ] ! grep -q ^[^ ][^ ]* *$v /proc/mounts; then mountpoint=$v log debug mountpoint $mountpoint is available for $DEVNAME break fi So if you don't do global locks and plug in a few different, /active/ devices, you'll probably overmount. ;) So I think we'll have to find another way to speed usbmount up a little. Best Regards, Hagen Fuchs -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#377548: Fails mounting some parts in a n-in-1 device
Package: usbmount Severity: normal Hello Jan, I have just looked at #403209 and the patch proposed there seems to me to lead straight into race conditions upon finding a free mount point (see there for further reference). The problem you described sounds almost as if you had the #403209-patch applied, but I assume there's a different problem at work. I will try to find and reactivate an old USB-IDE and partition it heavily in order to try and reproduce your report. Your patch, by the way, looks good to me! usbmount only needs to lock right before search a free mount point and putting logically related code in a separate function is almost always a good idea. So, yeah, I think we should use that. Best Regards, Hagen Fuchs -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#630541: wrong permission in mount
Package: usbmount Severity: normal Hello barabba, I'm trying to squish a few bugs in usbmount and this one is currently the only one listed with a severity level of important. Unfortunately, I cannot quite grasp the problem(s) you're describing. The following list tries to summarize what I think you might experience and suggestions/questions that I have. 1. usbmount r/w access only possible as root, permissions are wrong Have you tried specifying a custom fstype string for vfat in the configuration file? 2. The mount point is not correct usbmount currently uses generic mount points, eg. /media/usb0 up to /media/usb7. There is another bug for usbmount, a wishlist item, that addresses this[0]. 3. usbmount has udisk problems I don't understand. What were you trying to do? Please elaborate on those points, if at all possible. If you're not sure whether those problems persist or you don't care anymore, please tell us regardless. Many thanks! Best Regards, Hagen Fuchs [0] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=321694 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#632112: openthesaurus-de-text: does not trivially work with ding
Package: openthesaurus-de-text Version: 20110119-3 Severity: important Hello, The description of the openthesaurus package specifically mentions its usability with the dictionary program ding. As I was unable to actually achieve this (without major hackage such as reformatting the entire openthesaurus.txt file), I would like to request a short description of the process in the README.Debian file. Best Regards, Hagen Fuchs -- System Information: Debian Release: 6.0.2 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i586) Kernel: Linux 2.6.32-5-486 Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8) (ignored: LC_ALL set to en_GB.utf8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#632116: ding: not possible to add generic search
Package: ding Version: 1.7-1 Severity: normal Hi there, I ran into considerable difficulties trying to make good on the promise of the package openthesaurus-de-text that it would work with ding. The format of their file is bla;foo;bar so that I cannot simply use ding's dictionary mode (using the semicolon as separator). Therefore, I tried to add a generic search (via Search Preferences) which invariably always requites my efforts with an error message reading can't read smeth(grepcmd): no such element in array An example setup would be Name: test Search command: dict Language: English The same message appears when specifying my executable scripts with full (and valid) path names as Search command. The documentation - both on- and in-line - seems rather silent on this topic. An obvious fix for this /special/ case would be to convert the thesaurus file into the two-term format that the dictionary module of ding expects. But the problem described here is more general. In case I really didn't lengthily show off my incompetence just now, I would be happy to assist in hunting this down. Best Regards, Hagen -- System Information: Debian Release: 6.0.2 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i586) Kernel: Linux 2.6.32-5-486 Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8) (ignored: LC_ALL set to en_GB.utf8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#622626: lxc: Re: LXC Debian template architecture bug
Package: lxc Version: 0.7.2-1 Severity: normal Hi there, Same behaviour here. Though my hardware's different (Transmeta Crusoe), I found that lxc-debian works happily with the patch appended. This patch is just a readily applicable (and slightly more [Ba]shistic) version of Benjamin's suggestion (I'd written this report before spotting his - I'd probably have shut up otherwise :). Best Regards, Hagen Fuchs --- lxc-debian 2011-05-16 10:19:09.0 +0200 +++ lxc-debian.fixed2011-05-16 10:19:03.0 +0200 @@ -151,7 +151,7 @@ arch=amd64 fi - if [ $arch == i686 ]; then + if [ $arch == i686 -o $arch == i586 ]; then arch=i386 fi
Bug#625845: apt: Cron job doesn't correctly handle removal by archive size.
Package: apt Version: 0.8.14.1 Severity: normal I recently discovered the /etc/cron.daily/apt script and wanted to use it to download upgradeable packages and then immediately afterwards delete them. Point is: There's a caching daemon (apt-cacher-ng) in between that will keep requested packages around but cannot by itsself determine and download upgradeable packages. So, as suggested in the cron job, I created the file /etc/apt/apt.conf.d/02periodic with the following contents: APT::Periodic::MinAge 0; APT::Periodic::Verbose 2; APT::Periodic::MaxSize 1; APT::Periodic::Update-Package-Lists 1; APT::Periodic::Download-Upgradeable-Packages 1; The MinAge=0 setting should allow the clean-by-size-routine to indiscriminately kill newly downloaded packages, or so I thought. Well, it doesn't, as this whole clean-by-size subtree will be deactivated if MinAge==0. This is easily fixed by moving this check a bit deeper as can be seen in the small and trivial patch I attached (apt.remove_by_size.diff). I don't think it'll break any of the more customary use cases (such as actually keeping downloaded packages around for later installation :). There are also a few comments marked TODO in this diff - those contain suggestions for later improvements (or silly remarks, I'm often not sure). Thanks, Hagen diff --git a/cron.daily/apt b/cron.daily/apt index 75986f5..efce46f 100755 --- a/cron.daily/apt +++ b/cron.daily/apt @@ -170,6 +170,7 @@ check_size_constraints() # check size if [ ! $MaxSize -eq 0 ]; then # maxSize is in MB + # TODO Well, no... 1024 - binary prefixes (MiB, KiB,... :). MaxSize=$(($MaxSize*1024)) #get current time @@ -187,7 +188,7 @@ check_size_constraints() fi # check for MinAge of the file - if [ $MinAge -ne 0 ]; then + # hfuchs| Moved age check deeper below - doesn't make sense here. # check both ctime and mtime mtime=$(stat -c %Y $file) ctime=$(stat -c %Z $file) @@ -196,14 +197,19 @@ check_size_constraints() else delta=$(($now-$ctime)) fi - if [ $delta -le $MinAge ]; then + # hfuchs| Moved MinAge != 0 check here. + if [ $delta -le $MinAge -a $MinAge -ne 0 ]; then debug_echo skip remove by archive size: $file, delta=$delta $MinAgeSec + # TODO Why break here? Just because of one file that's too fresh? break else # delete oldest file + # TODO btw: I read somewhere at the top of this file that + # the biggest files are deleted first? I can't see it + # happening. Don't relly care, either. ;) + # TODO Indentation is a bit of a mess down here. debug_echo remove by archive size: $file, delta=$delta = $MinAgeSec (sec), size=$size = $MaxSize rm -f $file - fi fi done fi
Bug#147839: Short README file describing how to create a password DB for pam_userdb.so
Package: libpam-modules Severity: normal Hello, I would just like to add that the last part in this README concerning the implicit addition of the '.db' extension in the pam_userdb module hit me quite hard this week. Could pam_userdb(8) perhaps add an appropriate line? The 'db' entry under OPTIONS looks to me like the prime candidate: db=/path/database Use the /path/database database for performing lookup. There is no default; the module will return PAM_IGNORE if no database is provided. Please note that the extension '.db' will be appended implicitly. Thanks! Best Regards, Hagen Fuchs -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#608843: iwatch: Trouble with utf8 characters in filenames (+ 2 possible fixes)
Hi, I realise that both versions posted earlier (1: downgrade system()-string; 2: use Encode, use open) break character representation in e-mail notifications. So the royal way would probably be to properly decode()/encode() everywhere. Or am I going completely astray here? Regards, HF -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#608843: iwatch: Trouble with utf8 characters in filenames (+ 2 possible fixes)
Package: iwatch
Version: 0.2.2
Severity: normal
Hi,
iwatch had - for as long as I dare to remember - a somewhat strained
relationship with UTF-8 characters. Exempli gratia:
First shell:
iwatch -v -c 'ls %f' -e create .
Second shell:
touch mö
Output (first shell):
Watch .
[ 3/Jan/2011 23:24:35] IN_CREATE ./mö
[ 3/Jan/2011 23:24:35] * Command: ls ./mö
ls: cannot access ./mö: No such file or directory
I decided not to work around this behaviour any longer and try to get
iwatch to correctly pass on UTF-8 chars. And down Perl's
UTF-8/utf8/PerlIO hole I went... I have two very small patches
(+2 lines each, appended) that seem to produce what I like to think
could be correct behaviour. I tested variant 1 (see
iwatch.variant1.diff) and have it in (very limited) production use.
I would be happy to discuss the patches if anybody's interested - I
still haven't quite grasped what I actually did.
Best Regards,
Hagen Fuchs
-- System Information:
Debian Release: 5.0.7
Architecture: i386 (i686)
Kernel: Linux 2.6.26-2-686 (SMP w/2 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8) (ignored: LC_ALL
set to en_GB.utf8)
Shell: /bin/sh linked to /bin/bash
--- iwatch 2011-01-03 22:29:06.0 +0100
+++ iwatch.variant1 2011-01-03 22:33:32.0 +0100
@@ -416,6 +416,8 @@
$command =~ /^(.+)$/;
return if(!defined($1));
my $securecommand = $1;
+# Force byte-string semantics [why does that work?].
+utf8::downgrade($securecommand) if (utf8::is_utf8($securecommand));
system($securecommand);
}
if(defined($Message) $Path-{'alert'}) {
--- iwatch 2011-01-03 22:29:06.0 +0100
+++ iwatch.variant2 2011-01-03 22:32:23.0 +0100
@@ -19,6 +19,9 @@
use XML::SimpleObject::LibXML;
use POSIX;
use Sys::Syslog;
+# Force UTF-8 interpretation of strings and IO.
+use encoding 'utf-8';
+use open qw|:utf8 :std|;
my $PROGRAM = iWatch;
my $VERSION = 0.2.2;
Bug#593520: cil: Dependency missing: libfile-homedir-perl.
Package: cil Version: 0.07.00-1 Severity: important The upstream version of cil has the dependency on libfile-homedir-perl in 'debian-lenny/control'. But, even tough the debian source-archive (acquired with `apt-get source cil`) contains the dependency specification, the actual package does not list it: http://packages.debian.org/sid/cil Am I missing something trivial here? I suspect so. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#570542: gitosis: Does not initialise as advertised - needs Python module peak
Package: gitosis Version: 0.2+20090917-2 Severity: important Following the setup procedures in /usr/share/doc/gitosis/README.Debian, I issued (as root): sudo -H -u gitosis gitosis-init gitosis_rsa.pub The resulting Python traceback essentially says: ImportError: No module named peak The same thing after aptitude install python-peak.util works fine. So, I suggest making the package 'python-peak.util' a mandatory requirement. Thanks, Hagen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#369662: fortunes: typo in Brandeis quote: fortune -m 'mean of zeal'
There seems to be a duplication as well: cd /usr/share/games/fortunes $ grep encroachment * cookie:The greatest dangers to liberty lurk in insidious encroachment by mean of zeal, cookie.u8:The greatest dangers to liberty lurk in insidious encroachment by mean of zeal, politics:The greatest dangers to liberty lurk in insidious encroachment by men politics.u8:The greatest dangers to liberty lurk in insidious encroachment by men So, `politics` contains the right, `cookie` the wrong quote. Who would've guessed? fortunes 1:1.99.1-3.1 Regards, Hagen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#516653: nagios3-common: Preremoval script: syntax error
Package: nagios3-common Version: 3.0.6-3 Severity: normal Trying to purge nagios3 from my system, I encountered this message: Removing nagios3-common ... /var/lib/dpkg/info/nagios3-common.prerm: line 23: syntax error near unexpected token `fi' dpkg: error processing nagios3-common (--remove): subprocess pre-removal script returned error exit status 2 Simple enough, the line in question (in 'nagios3-common.prerm') is syntactically wrong. I attached a unified diff fixing the problem. -- System Information: Debian Release: 5.0 Architecture: i386 (i686) Kernel: Linux 2.6.26-1-686 (SMP w/2 CPU cores) Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8) (ignored: LC_ALL set to en_GB.utf8) Shell: /bin/sh linked to /bin/bash --- nagios3-common.prerm.old2009-02-22 23:22:24.0 +0100 +++ nagios3-common.prerm2009-02-22 21:32:57.0 +0100 @@ -4,7 +4,7 @@ apacheconf=/etc/nagios3/apache2.conf -if [ -f $apacheconf ] +if [ -f $apacheconf ]; then case $1 in remove) # find the configured servers
Bug#497928: rsnapshot uses the lchown perl module
You just made my day. I'm halfway into the new one already? Nevermind, you made that, too. Thanks, Hagen signature.asc Description: Digital signature
Bug#501738: iwatch: Wrong email address in XML file
Package: iwatch Version: 0.2.1-2 Severity: minor In /etc/iwatch/iwatch.xml the guard email entry is [EMAIL PROTECTED] This should probably be [EMAIL PROTECTED] For reference, the whole entry (I'm too tired to diff properly, it's trivial anyway): config guard email=[EMAIL PROTECTED] name=IWatch/ watchlist -- System Information: Debian Release: 4.0 Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-6-k7 Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8) (ignored: LC_ALL set to en_GB.utf8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#501520: flashcards: fails with Package geometry Error; even on the example page
Package: texlive-latex-extra Version: 2007.dfsg.4-1 Severity: normal The 'flashcards' package, residing in /usr/share/texmf-texlive/tex/latex/flashcards/, does not properly built the example flash card document 'samplecards.tex' http://www.tug.org/texlive/Contents/live/texmf-dist/doc/latex/flashcards/samplecards.tex and fails with ! Package geometry Error: You must set \paperwidth properly. This seems to be a known problem and has already been described: http://www.feferraz.net/en/flashcards.html (see section 'Problems'). A diff is also provided. I already tried the unstable version; same result. Thanks, Hagen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#499465: rsnapshot: Does not get executed by anacron as its cron-file resides in cron.d
Package: rsnapshot Version: 1.2.9-1 Severity: important As the cron-file for rsnapshot is in cron.d/, systems which rely on anacron for execution of cron-jobs may not be doing backups as expected! Anacron does *not* execute jobs in cron.d/. I suggest splitting the rsnapshot cron-files into cron.daily/, cron.weekly/ and cron.monthly/ files. And yes, I think it is a PITA to repeat oneself like that, but for the sake of Desktop users that rely on anacron (and rsnapshot!), it seems to be the right thing to do. Thanks, Hagen -- System Information: Debian Release: 4.0 Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-6-k7 Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8) (ignored: LC_ALL set to en_GB.utf8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#497928: rsnapshot: The lchown Perl-module is not available in Debian-ized form
Package: rsnapshot Version: 1.2.9-1 Severity: normal rsnapshot produces warnings like this WARNING: Could not lchown() symlink when the Perl Lchwon.pm-module is not installed. It is, however, not possible to install this package in a clean, Debian-ized way, as this module (file) is nowhere to be found in Debian's official repos. The rsnapshot downloads-page http://www.rsnapshot.org/downloads.html gives another page http://permalink.gmane.org/gmane.comp.sysutils.backup.rsnapshot.general/1565 which allegedly provides a way to get sarge-packages. However, one of the hosts that have to be added to the 'sources.list' is not available. The only option left, which I would like to circumvent, is to run Perl to fetch it from CPAN. Thanks, Hagen -- System Information: Debian Release: 4.0 Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-6-k7 Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8) (ignored: LC_ALL set to en_GB.utf8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#496450: ncmpc: Jumping to song dir from search (F5) not possible
After a substantial amount of hacking, I think I have actually succeded in implementing this function. I would not consider my changes to be hacks, although I had my quarrels with the design (which I find quite pleasing now). Anyway, my patch makes it possible to press 'g' (goto) on an search results entry in order to browse the corresponding mpd-directory (in which the song is listed). I dont't know if this is a desireable feature, so either * close the ticket, as I'm satisfied or * notify upstream (or should I do that? - I'm not sure what the protocol suggests ;) So long, Hagen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#496450: ncmpc: Jumping to song dir from search (F5) not possible
I'm not sure I did understand you correctly. What do you mean by entering some album? Do you mean something like add the corresponding album to the playlist? That would be a consequence of the feature I'm interested in: Enter the browse-screen (3) from one of the entries of the search-screen (5) by hitting a particular key (eg. 'g' for 'goto'). I've played around with the code, but due to the very C-ish structure, I was unable to find a way to tell the browse-screen to open up in a certain directory, without major intrusion. Regards, HF -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#496450: ncmpc: Jumping to song dir from search (F5) not possible
Package: ncmpc Version: 0.11.1+svn-r3965-2 Severity: wishlist It would be very logical to implement a way to enter the album that corresponds to one of the resulting entries in a search list; á la: I'd really like to hear that album where 'foo' sang 'bar'! Thanks, HF -- System Information: Debian Release: 4.0 Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-6-k7 Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8) (ignored: LC_ALL set to en_GB.utf8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#495219: freetalk: Hangs on start-up, works fine after pressing CTRL-C once.
can you please tell me, which aspell dictionary you are using? may be if it is too big, freetalk is not handling it.. Sorry, I tried different word-lists (wngerman was the one with 300.000+ entries) - english, british and even cleared the wordlist once: Loading dictionary [/usr/share/dict/words]... [0] words Also, I tried de-installing aspell and installing the most recent version - the problem persists: An indefinitely long hang on start-up. Thanks, Hagen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#495219: freetalk: Hangs on start-up, works fine after pressing CTRL-C once.
Package: freetalk Version: 0.5-2 Severity: normal After invoking freetalk 0.5, I need to press CTRL-C after waiting one moment: $ freetalk [ 1 sec ] CTRL-C Loading dictionary [/usr/share/dict/words]... [320577] words and normal operation begins. This even happens, when I remove my '.freetalk'-folder: $ mv .freetalk/ freesomething $ freetalk Welcome to freetalk! Running for the first time? Performing some one-time initializations ... [ waiting ... ] CTRL-C Loading dictionary [/usr/share/dict/words]... [320577] words and everything goes smoothly from here. -- System Information: Debian Release: 4.0 Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-6-k7 Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8) (ignored: LC_ALL set to en_GB.utf8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#495219: freetalk: Hangs on start-up, works fine after pressing CTRL-C once.
Hi, Try latest version from Lenny or even more latest version from Sid. I have never seen such issues before with freetalk. Already tried that - sorry to say: same outcome. I can wait infinitely long (so it seems) after invoking freetalk. Then I Ctrl-C and all is well. Is there some way to get debug-output from freetalk - without wading into Guile-waters, preferably? Or perhaps one of the libraries (readline?) blocks? What is it supposed to be doing at the stage before this one: Loading dictionary [/usr/share/dict/words]... - Library versions (aptitude output): --\ guile-1.6 i A 1.6.8-6 --\ guile-1.6-libs i A 1.6.8-6 --\ libc6 (= 2.3.5-1) i A 2.7-13 --\ libglib2.0-0 (= 2.8.5) i A 2.16.4-2 --\ libloudmouth1-0 (= 1.0.1) i A 1.4.0-1 --\ libncurses5 (= 5.4-5) i A 5.6+20080713-1 --\ libreadline5 (= 5.1) p A 5.2-3 - So long, Hagen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
