Bug#270310: #270310 procps: 'whatis ps' has 132 chars of garbage text appended
The bug seems to be gone from my system in 'procps' v1:3.2.6-2. % whatis ps ps (1) - report a snapshot of the current processes. No more cruft. HTH... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#310333: 'man sane-find-scanner' typos: ... itsself
For some reason 'itsself' is still there. See patch. HTH... --- - 2005-10-01 04:24:41.51296 -0400 +++ /tmp/sanefind-scanner.1.gz.32703 2005-10-01 04:24:41.0 -0400 @@ -91,7 +91,7 @@ .B sane-find-scanner tries to identify the chipset(s) of all USB scanners found in such a file. This option is useful for developers when the output of cat /proc/bus/usb/devices -is available but the scanner itsself isn't. +is available but the scanner itself isn't. .TP 8 .B devname Test device file devname. No other devices are checked if devname is given.
Bug#220005: john: Include patches to crack other password types
Here's another vote to add the Win NT/XP patch described here: Cracking Cached Domain/Active Directory Passwords on Windows XP/2000/2003 By Irongeek Update:8/24/2005 http://www.irongeek.com/i.php?page=security/cachecrack ...Irongeek uses Debian as its model system, that is, he shows how to apply the patch in Debian. Adding this patch would save much duplicated effort by auditors. Also, it's elegant to be able to use a Linux program to do this, (kind of a one up on them thing), as well as responsible, since the more the weaknesses of NT/XP are exposed the more public pressure there would be to fix 'em, which would make the net as a whole better. Which might indirectly reduce DOS attacks by zombie armies because there'd be fewer computers susceptible to enslavement. Everybody benefits... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#323983: cron: bashism in /etc/cron.daily/standard
I get the same bug, since 'dash' is my default scriping shell. Attached
is a patch for '/etc/cron.daily/standard'.
Hope this helps...
--- /etc/cron.daily/standard 2005-08-11 03:06:18.0 -0400
+++ /tmp/standard 2005-08-20 16:52:03.0 -0400
@@ -62,7 +62,7 @@
df -P --type=ext2 --type=ext3 --type=xfs |
awk '/\/dev\// { print }' | sed -e 's/ [[:space:]]*/ /g' |
while read mount block used avail perc mp; do
- [ $mp == / ] mp=
+ [ $mp = / ] mp=
echo $mp/lost+found
done |
while read lfdir; do
Bug#323887: /var/lib/dpkg/info/base-config.postinst: line 59: syntax error near unexpected token `db_fset'
I get the same bug. Attached is a 'diff', (based on Bob Tanner's previous post), that seems to fix it. HTH... --- /tmp/base-config.postinst.old 2005-08-19 01:29:43.0 -0400 +++ /var/lib/dpkg/info/base-config.postinst 2005-08-19 01:29:51.0 -0400 @@ -54,7 +54,7 @@ apt-setup/non-free apt-setup/contrib apt-setup/badsource \ apt-setup/another apt-setup/badedit \ apt-setup/security-updates \ - apt-setup/security-updates-failed \ + apt-setup/security-updates-failed do db_fset $q seen false || true done
Bug#322720: Can not retrieve bugs from the BTS anymore
I also have this bug. Downgrading 'reportbug' doesn't cure it -- I've
tried these versions, all of them are currently prone to the bug:
cd /var/cache/apt/archives/
alfie [VT] /var/cache/apt/archivesls reportbug* -go
-rw-r--r-- 1 125288 May 10 18:47 reportbug_3.12_all.deb
-rw-r--r-- 1 125832 Jun 14 16:02 reportbug_3.13_all.deb
-rw-r--r-- 1 125918 Jun 16 17:47 reportbug_3.14_all.deb
-rw-r--r-- 1 125964 Jun 19 23:47 reportbug_3.15_all.deb
...all of these used to work fine. This bug can't be more than a week
old, though the newest package above is almost two months old.
Running 'reportbug reportbug' in a failed attempt to read this very bug,
looks like:
% reportbug reportbug
{ ... etc... }
126 bug reports found:
Important bugs - outstanding
1) #183573: reportbug: Requires python1.5 for installation
2) #279168: reportbug: Fails to send report, no error message
3) #302103: reportbug: Silent termination with no error when
required http_proxy not specified
4) #304474: reportbug: Verifying package integrity fails with
elinks check
5) #310856: reportbug: the handling of the smtphost is not really
convenient
6) #322720: Can not retrieve bugs from the BTS anymore
7) #322739: querybts fails to retrieve bug reports
(1-7/126) Is the bug you found listed above [y|N|m|r|q|s|f|?]? 6
Retrieving report #322720 from Debian bug tracking system...
No report available: #322720
Conclusion: like Anthony DeRobertis said, something in the BTS
server was changed to be incompatible with our trusty 'reportbug'
clients. Probably not news to the maintainer, but some BTS reader
might be saved a futile downgrade attempt by reading this.
HTH...
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#310367: More 'spliting'
Besides 'hierbox' the same typo is in 'hiertable' and 'treeview'... % zgrep -H -n spliting `dlocate -L blt | grep man` /usr/share/man/man3/hiertable.3blt.gz:1637:Specifies the character sequence to use when spliting the path components. /usr/share/man/man3/treeview.3blt.gz:1640:Specifies the character sequence to use when spliting the path components. /usr/share/man/man3/hierbox.3blt.gz:1637:Specifies the character sequence to use when spliting the path components. Excepting the filemames, the same .diff should work on all three. HTH... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#222621: #222621 /usr/bin/querybts: Could provide option to list all bugs without user interaction
Seconded, that would be useful. In the meantime this here shell
function sort of works:
qbtsnoprompt() { yes n | querybts $1 21 | sed -e 's#^.*?]? *#\n#' -e
's#\n\n#\n#' ; }
Sample run:
qbtsnoprompt bash | head -n 15
Important bugs - outstanding
1) #283702: Race condition when writing ~/.bash_history
2) #288319: bash: doesn't handle suspension of commands in conditional lis
3) #292023: does no longer use .bash_profile
Normal bugs - outstanding: 5 remain
4) #219386: E91: 'shell' option is empty
5) #238226: bash: segfaults on ia64 when expanding large glob
6) #238965: bash oddity with extremely long argument list
7) #240867: vim error
8) #269573: removal problem (postrm script)
9) #283782: shell-mode: command line altered after C-c C-c on an empty lin
10) #286841: bash: Interrupt kills suspended jobs while completing tar xjf
11) #289355: global bash_logout incorrectly documented
12) #291197: command -v prints pathnames of non-executable files
...but I don't understand what Normal bugs - outstanding: 5 remain means.
There's more than 5 bugs remaining. So it's 5 of what?
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#305246: Patch for #305246 mozilla-browser: mozilla doesn't start: syntax error
Attached is a diff/patch for '/usr/bin/mozilla-suite' in mozilla-browser v2:1.7.7-1. HTH... --- /usr/bin/mozilla 2005-04-18 05:46:54.0 -0400 +++ /tmp/mozilla-suite.patch 2005-04-18 19:16:54.669493433 -0400 @@ -69,7 +69,7 @@ P=`fuser /dev/dsp 21 | sed -e 's#^/dev/dsp:##' ` if [ -n $P ]; then if echo $P | xargs ps -p | grep esd /dev/null 21; then MOZILLA_DSP=esddsp; - elif echo $P | xargs ps -p | grep arts /dev/null 21; then MOZILLA_DSP=artsdsp; fi + elif echo $P | xargs ps -p | grep arts /dev/null 21; then MOZILLA_DSP=artsdsp; elif echo $P | xargs ps -p | grep rplayd /dev/null 21; then MOZILLA_DSP=rplaydsp; fi fi elif [ $MOZILLA_DSP = none ];then
Bug#298919: #298919 reportbug: email not sent to reporter
Hi, for the record I also have this bug on my system. 'reportbug' used to CC to sender OK, but the last time it did for me was Feb 13 2005. I send out bugs every other day or so. I also upgrade 'reportbug' whenever there's a new one. According to the changlog: reportbug (3.8) unstable; urgency=medium * Create .reportbugrc with mode 600. (Closes: #295407) * Drop references to bug(1) from man page. (Closes: #293188) * Don't send Bcc field in messages to any external programs. -- Chris Lawrence [EMAIL PROTECTED] Tue, 15 Feb 2005 11:50:53 -0600 reportbug (3.7.1) unstable; urgency=low * Import sys call was forgotten in fix for #292340. -- Chris Lawrence [EMAIL PROTECTED] Thu, 27 Jan 2005 08:01:06 -0600 ...the only new version after Feb 13, is v3.8. The bit about Don't send Bcc field... looks like a possible cause. Some config data, if it matters: % grep -n cc .reportbugrc /etc/reportbug.conf .reportbugrc:15:#no-cc /etc/reportbug.conf:36:cc HTH... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#275721: #275721nvidia-kernel-source: resulting package should in some way conflict with older nvidia-glx packages
I noticed the same problem. It'd be best if the resulting post-compilation package Required: the appropriate 'nvidia-glx' version. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#287310: #287310 nvidia-kernel-source: fails to compile with kernel-headers-2.6.9-1-686
Hi, for the record I'm running the same kernel: % for f in `dglob $( uname -r )`; do echo -ne $f\t ; dlocate -s $f | grep ^Version ; done nvidia-kernel-2.6.9-1-686 Version: 1.0.7167-1 kernel-image-2.6.9-1-686Version: 2.6.9-3 kernel-headers-2.6.9-1-686 Version: 2.6.9-3 ...and 'nvidia-kernel-source' did compile on my system, and the resulting 'nvidia-kernel-2.6.9-1-686' package installed OK, and it works -- on my system anyway. HTH... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#295133: #295133 Weirdness: Page opens from command line, but sometimes hangs FF if opened from 'Go' menu.
I'm thinking this bug is the same as this one: #283408 libflash: crashes on epiphany for many sites including blockbuster.com http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=283408 Since after uninstalling 'libflash-mozplugin', Mozilla could open the troublesome 'scriptpimp' page. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#291794: **FATAL_ERROR** ....open of /var/lib/ntop/prefsCache.db failed
Sorry I'm tardy in replying about this bug; time flies. The description in the README.Debian isn't yet satisfactory. Some time I'd like to figure out how to get 'ntop' working then try to rewrite it. In the meantime, the new text has several typos, for example: 15 Note that you can not run ntop as a user as it need full access to the 16 devices and only root have such access. s/can not/cannot/ s/need/needs/ s/have such/has such/ A patch is attached. More later, HTH... 15,19c15,19 Note that you can not run ntop as a user as it need full access to the devices and only root have such access. After it has got that access it will change user to ntop or whatever you have configured it to. You have to make sure that the user have access files in /var/lib/ntop. This is normally fixed by the installation script but it may fail. --- Note that you cannot run ntop as a user since it needs full access to the devices and only root has such access. After it has root access it will change to user ntop or whatever you have configured it to. You have to make sure the user has access to files in /var/lib/ntop. This is normally done by the installation script, but it may fail.
Bug#229847: #229847 reportbug: Ignores configuration file /etc/reportbug.conf and continues as if it didn't exists
On 18 Feb 2005 at 13:36, Chris Lawrence [EMAIL PROTECTED] wrote: Are you quite certain that there was no contradictory ui line in .reportbugrc beforehand? ui text is written by default to that file, and would override any setting in /etc/reportbug.conf. Thank you and No, you're right, it's me that was buggy. I just checked my '.reportbugrc' and there it was ui text on line #7. Commented it out, changed '/etc/reportbug.conf' to ui newt and got the error! Retraction: my results did NOT confirm this bug. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#229847: #229847 reportbug: Ignores configuration file /etc/reportbug.conf and continues as if it didn't exists
I just noticed this bug after changing '/etc/reportbug.conf' from this: # User interface: text or newt # querybts and reportbug will use this setting ui text ...to this: ui newt I ran 'reportbug' as a user, and the UI was still text. I added the 'newt' line to '~.reportbugrc', ran 'reportbug' and saw results: The newt interface is not supported. Unless you are debugging reportbug, please do not use it. If you are debugging reportbug, please DO NOT file bugs more serious than 'normal' that indicate problems with this interface. Traceback (most recent call last): File /usr/bin/reportbug, line 1666, in ? main() File /usr/bin/reportbug, line 873, in main exec 'import '+iface File string, line 1, in ? File /usr/share/reportbug/reportbug_ui_newt.py, line 23, in ? import commands, string, sys, snack, re, debianbts ImportError: No module named snack ...which confirm this bug. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#293964: sraw: cryptic errors deprecated SCSI ioctl, please convert it to SG_IO
On 10 Feb 2005 at 1:00, Eric [EMAIL PROTECTED] wrote: The problem is that sraw needs a kernel patch to work (patch is in /usr/share/doc/scsitools/kpatch.sraw). But I'm afraid it will not apply cleanly to kernel sources as this patch is really outdated. Btw, I'm thinking of removing it from scsitools package since it is not really useful. Sounds like either the 'kpatch.sraw' should be improved or 'sraw' removed. I hate doing kernel patches**, a module would be more user friendly. (**on a modem it means DL'ing the kernel source, which is like 35 megs, or around three hours, and an uncertain compile, just for a little patch. A module is usually under 100K.) PS: maybe you could use sg_read/sg_read_long from sg3-utils package to benchmark your drives. Thanks for the lead, I didn't know about 'sg3-utils', which works as you say. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#293964: After kernel reconfig, some more details...
More diagnostics: After the last report, I repartitioned the drive, adding 'sda1' (vfat) and 'sda2' (swap), and found that swap wouldn't load on bootup, although '/etc/fstab' had the right line. It turned out my '/boot/initrd.img-2.6.9-1-686' didn't contain the module for the recently added SCSI card, so SCSI was loaded late. To correct that I did a 'dpkg-reconfig kernel-image-2.6.9-1-686', and now swap loads on bootup. Then I tried 'sraw' again: % sraw /dev/sda; echo $? Size 0 sectorsize 0 Floating point exception 136 % sraw /dev/sda1; echo $? Size 0 sectorsize 0 Floating point exception 136 % sraw /dev/sda2; echo $? Size 0 sectorsize 0 Floating point exception 136 It still doesn't work, but the please convert it to SG_IO error is gone. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#285143: Nag: please use the 'libvte4' patch...
Since at least April 2003, this accursed bug keeps getting fixed then COMES BACK FROM THE DEAD like Count Dracula! What's the hold up? Older Debian versions of #285143: PageUp in 'less' has gone a bit haywire http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=190651 strange behavior with certain manpages http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=203049 PageUp behaviour within less broken AGAIN http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=218399 Upstream versions: Bug 115149: PageUp in 'less' has gone a bit haywire http://bugzilla.gnome.org/show_bug.cgi?id=115149 Bug 120401: VTE slow to refresh when scrolling up with less http://bugzilla.gnome.org/show_bug.cgi?id=120401 Bug 164153: Scrolling issues (bugs and flickers) with solid background http://bugzilla.gnome.org/show_bug.cgi?id=164153 Calling Dr. Van Helsing... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#292923: galeon: downloader doesn't check for write access, loses data, wastes time
From where I sit there's no context problem -- you sent a nice reply connecting my bug with some other bugs. Somewhat wrongly as it turned out, but none the less a well meaning diagnosis. I appreciated your reply, but was ticked off that people were so accepting of an annoying and uncomplicated bug. It's a public BTS, and my rant was for the public and wasn't meant as a personal attack -- my apologies if it seemed like one. On unpleasant manners. Unpleasant for who? Management, workers, users? When rewarded conflicts exist, what's pleasant for one side may be unpleasant for the other, and vice versa. Thomas Nast was unpleasant to Boss Tweed. Round and round we go... To exit this loop of subjective interests, a more general term is needed, such as good, as in the general or greater good, the commonweal. Can good be unpleasant, can something pleasant be bad? Hmmm... Unpleasant good things Pleasant bad things --- Dentistry Heroin Whistleblowing Ass-kissing Voting Most Politicians SurgeryFaith Healing Taxes Swiss Bank Accounts The Weekly World News Teen People Etc. Maybe a BTS belongs in the first column. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#292923: galeon: downloader doesn't check for write access, loses data, wastes time
On 31 Jan 2005 at 22:20, Loïc Minier [EMAIL PROTECTED] wrote: That's VOLUNTEER DRIVEN WORK, and yes I agree this bug sucks. That's like saying, it's volunteer so don't EXPECT it to be GOOD. Consider all the great stuff in Debian that's better than the equivalent payware. Stuff that would be impossible if volunteer coding and management were innately disorganized, maladapted or defective. So I talked about it to the other maintainers of mozilla packages: http://lists.alioth.debian.org/pipermail/pkg-mozilla-maintainers/2005-J anuary/10.html Good, but no replies yet. Perhaps if you were less pleasant, or just quoted me? The bug isn't in Galeon, but in Mozilla as I told you. You sure did, but if Mozilla's insensitive to three years of that, they may never fix it; maybe it'd be better to grab the initiative and consider a new and better downloader. Put it on the TODO even. It could be an advantage for Galeon. Look at bugzilla.mozilla.org, and give a hand at fixing these: https://bugzilla.mozilla.org/reports.cgi?product=-All-datasets=NEW%3A; datasets=ASSIGNED%3Adatasets=REOPENED%3Adatasets=UNCONFIRMED% 3A Hmm, a line graph showing 3 new, 16000 unconfirmed, 6000 assigned, 1500 reopened bugs. Hope they're not all Mozilla. Awesome as 3 bugs may seem, it's irrelevant to this one bug here. If you were saying Go to the end of the line. Once the other 2 are fixed then we'll think about this bug that wouldn't follow, as a three year old bug wouldn't be at the end of the line. But ranking bugs by age is dubious. The best method of bug ranking is an interesting topic though. I can understand Galeon seems to lack in some simple domains, ranting won't help sadly, people are working on what they like to do. I strongly believe that ranting does help if we look at the big picture. Definition: by ranting I mean emphatic complaints, usually quite redundant. The most obvious benefit is that it acts like an alarm. But suppose you're right, and redundant alarms do not help fix this or most any other bug, they only annoy maintainers. I'd still say it helps because a public BTS has three audiences: the maintainers, the users, and posterity. Ranting helps other disgruntled users know they're not the only ones with a problem, and helps new users deciding whether to try the software if it's worth the bother. Even rants presently ignored by both maintainers and users may help, since a large body of sound complaints ignored serves as a warning to the future. In sum, a rant may help alarm people into fixing something, and if not it helps debunk the unfixed thing's undeserved good reputation and thus speeds an inferior tool's eventual decline, or failing that, it may help prevent an unwise revival. It's all good. Caveat: this democratic view assumes most complainers have enough common sense to be right more often than not. Aristocrats and elitists who disdain common opinion might logically demand respect and servility at all times, since no mortal knows better than them. The great thing is: you can join and help! Well I am, by COMPLAINING. Also by helping maintainers appreciate that complaints, nags, gripes, bitching, venting, ranting, and so forth are friends indeed. Good friends that tell you what fake friends and flatterers can't. The pleasures of creation aren't always good, and the pains of destruction aren't always bad.
Bug#292923: Progress: Mozilla's Downloader doesn't have this bug
Wait a second... I just tried to download into a forbidden directory using Mozilla (v2:1.7.5-1) and it did the right thing -- it said: | Error saving /var/cache/apt/archives/foo.deb| /!\ Cannot create file. Directory /var/cache/apt/archives is not writable. [ OK ] Now that's the easy algorithm I'd suggested in my first report: 1) prompt user for destination dir. a) is destination verboten? Goto 1). So, Moz gets it right and is not to blame for this bug. It's a 'galeon' bug. But no, you told me: The bug isn't in Galeon, but in Mozilla as I told you. Well I guess if we were infallible there'd be no need for a BTS. Today's moral: Trust, but verify. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#292923: galeon: downloader doesn't check for write access, loses data, wastes time
On 31 Jan 2005 at 9:01, Loïc Minier [EMAIL PROTECTED] wrote: Sadly, this is a known bug in the underlying Mozilla part which is doing the effective download. There are a bunch of bugs concerning this problematic behavior, for example #163905, #197085, #149104, #123129, #145521... Thanks for the patient reportage of that bug info, but looking up those bugs inspires a rant. The oldest bug report is from 2002. Why hasn't such a BASIC easy to fix bug been fixed in THREE YEARS? I see in Galeon's TODO file items like User stylesheets. Very nice but are such things that important? Why are people trying to ADD dubious new features, (and advertise 'em), when they can't SPARE THE TIME to fix a standard feature that's generally useful? Try our wonderful new browser with the GREAT NEW FEATURES. The old features don't work so we're a little ashamed, but we are PROUD of the NEW ONES. Aagh! OK, enough cursing the darkness, yes I'll go quietly officer...
Bug#292457: list-alts: README is an alternative?
On 28 Jan 2005 at 11:38, Graham Williams [EMAIL PROTECTED] wrote: I think w is a genuine alt: $ ls -l /etc/alternatives/w ... /etc/alternatives/w - /usr/bin/w.procps So it is! I did not know that... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#292457: list-alts: README is an alternative?
On 28 Jan 2005 at 21:27, Dirk Eddelbuettel [EMAIL PROTECTED] boldly wrote: Closing this bug report... Prior to v2.0.20, while the README bug still exists. Call me a scaredy cat, but release fixed update THEN close seems less wild than close THEN release fixed update. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#292457: list-alts: README is an alternative?
On 27 Jan 2005 at 23:41, Graham Williams [EMAIL PROTECTED] wrote: Thanks again. I have fixed up the README problem, and I believe this closes this bug. It will be in Version 2.0.20. You're speedy! I'll test it when it comes out, as there was another bit of odd data in the same output: wajig list-alts | cat -n | grep 100 100 w No such 'alt' as w I believe. Perhaps the README fix will remove the w too. The error code issue is a bigger one for wajig. I'm happy to look in to it if you believe it should be fixed (and wanted to add a new Bug report - either a wishlist or bug depending on your point of view). OK: #292581 wajig list-names always returns true error codes http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=292581 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#291794: **FATAL_ERROR** ....open of /var/lib/ntop/prefsCache.db failed
On 27 Jan 2005 at 7:29, Ola Lundqvist [EMAIL PROTECTED] wrote:
It says in '/usr/share/doc/ntop/README.Debian': { quote deleted }
It's not mandatory, there's a qualifying may. If something needs to be
done to get 'ntop' working, the installer script should do it.
You need to set it if it is not there or you have configured in some
special way.
You seem to be saying certain procedures are required for EVERY new install.
In that case the text may need is a bug, and should be revised.
Suggestions...
Before:
At installation you may need to set the administration password.
After:
After installing 'ntop' for the first time, you must set the
administration
password.
As is common when editing technical docs, correcting an ambiguous
expression reveals other faults.
It's unclear what set the administration password means. Root's password as
applied to some part of 'ntop' I'm guessing, but as it's phrased it might mean
a special 'ntop'-only password.
Assuming it's just 'root' though, further revision is needed. What are we
setting? A permission. For what? A daemon, program or file? How does one set
it?
2nd try.
Before:
At installation you may need to set the administration password. You do
that by running ntop with the option -A (or --set-admin-password). It
will prompt you for the password and then exit. Now start the ntop
daemon.
After, with comments in {brackets}:
After installing 'ntop' for the first time, you must set the
administration
password for {what? a daemon, program or file? which ones?}. You do
that by running:
ntop -A { make the code easy to cut and paste! }
You'll be prompted for a root password, then the program will exit.
This
only needs to be done once. {Right?}
Now start the ntop daemon. {How? When? Every time you use 'ntop'?
Every
time you reboot? Just once? Example code should be included. Also
there
should be some note of what to expect -- namely nothing. The daemon
doesn't
produce useful user output, just diagnostic cruft.}
{ Some mention of the 'top'-like user level 'ntop' should be here.
Example:
Now that the {daemon/program/file's?} password has been set, and the
deamon is running, you can run the user level program. If your user
name is bill login as bill, go online, then type 'ntop'. Or
whatever. Perhaps further steps have to be taken so bill can use
it. }
Finally, here's a model example of what we're aiming for from the
'README.Debian' from 'lxdoom-svga':
lxdoom-svga
---
If you want to run lsdoom, the lxdoom SVGAlib binary, as a normal user,
it will need to be setuid root. You can accomplish this by using the
following sequence of commands:
dpkg-statoverride --add root root 4755 /usr/games/lsdoom
chown root:root /usr/games/lsdoom
chmod 4755 /usr/games/lsdoom
This used to be automated via debconf, but is now left up to the user.
-- Joe Drew [EMAIL PROTECTED], Fri, 26 Mar 2004 23:43:36 -0500
That's not perfect, but it's good enough. (He's afraid of 'debconf' too.) The
commands given are easy to cut and paste. No guesswork or looking up switches
in 'man' pages.
As it is a password that is needed to be set and there are
no really good way to do that in postinst with debconf without creating
really bad security issues you need to that manually.
I don't see much problem. The installer script is already running as root,
it has access, (no need to ask for a password), why not do it then, or
at least offer to.
...a repeat of that question: On your system(s), does purging
and reinstalling 'ntop' with the install script options 'ppp0' and 'ntop'
work?
No as I do not have a ppp0 interface.
Much faster for you, but I wish you'd mentioned that earlier.
HEY YOU modem users, if any are reading this: what are your results with
installing 'ntop'?
apt-get remove --purge ntop
apt-get install ntop
(Read README.Debian file)
ntop -A
/etc/init.d/ntop start
That will work for you.
It hasn't so far. (cue audience booing...)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#291794: **FATAL_ERROR** ....open of /var/lib/ntop/prefsCache.db failed
On 24 Jan 2005 at 11:14, Ola Lundqvist [EMAIL PROTECTED] wrote: Ok, what is the permission on the directory /var/lib/ntop? % ls -ld /var/lib/ntop drwxr-x--- 3 jdoe root 1024 Jan 24 01:09 /var/lib/ntop/ $ ls -la /var/lib/ntop total 992 drwxr-x--- 3 jdoe root 1024 Jan 24 01:09 . drwxr-xr-x 64 root root 3072 Jan 24 00:53 .. -rw-rw-r-- 1 jdoe ntop12288 Jan 24 00:59 LsWatch.db -rw-r--r-- 1 jdoe jdoe12288 Jan 24 01:09 addressQueue.db -rw-r--r-- 1 jdoe ntop12288 Jan 24 00:59 dnsCache.db -rw-r--r-- 1 jdoe root 31 Jan 24 01:01 init.cfg -rw-r--r-- 1 jdoe ntop 1077396 Jan 24 00:59 macPrefix.db -rw-rw-rw- 1 jdoe ntop5 Jan 24 01:09 ntop.pid -rw-r--r-- 1 jdoe ntop12288 Jan 24 00:59 ntop_pw.db -rw-r--r-- 1 jdoe ntop12795 Jan 24 00:59 prefsCache.db drwx-- 5 jdoe ntop 1024 Jan 24 00:59 rrd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#291794: **FATAL_ERROR** ....open of /var/lib/ntop/prefsCache.db failed
On 24 Jan 2005 at 22:04, Ola Lundqvist [EMAIL PROTECTED] wrote: Today I tryed to reproduce this problem. I run: ntop -u ntop It's good that it works for you. But why attempt to reproduce the problem by using different command line input? To attempt to see the buggy output, just do what I did: 1) Uninstall 'ntop'. % feta purge ntop 2) Reinstall 'ntop' % feta install ntop 3) Enter the same data at the config script prompts: 'ppp0' and 'ntop'. Also: 'ppp0' and 'jdoe' 4) Run the same command line prompts. a) as root: % ntop b) as user: % ntop -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#291794: **FATAL_ERROR** ....open of /var/lib/ntop/prefsCache.db failed
On 23 Jan 2005 at 20:28, Ola Lundqvist [EMAIL PROTECTED] wrote: Sun Jan 23 02:34:48 2005 **FATAL_ERROR** open of /var/lib/ntop/prefsCache.db failed: File open error What user have permission to that file? I've experimented with several, by reconfiguring the package with: dpkg-reconfigure ntop ...but always seem to get the same error messages. Examples of permission variants that don't work for me... When the config script asks, Which is the name of the user to run the ntop daemon as ? and Which interfaces should ntop listen on? I leave both at the defaults, 'eth0' and 'ntop': ls -l /var/lib/ntop/prefsCache.db;echo $? ls: /var/lib/ntop/prefsCache.db: No such file or directory 1 Reconfigure, with 'ppp0' and 'ntop': -rw-r--r-- 1 ntop ntop 12288 Jan 24 00:59 /var/lib/ntop/prefsCache.db Reconfigure, with 'ppp0' and 'jdoe': -rw-r--r-- 1 jdoe ntop 12795 Jan 24 00:59 /var/lib/ntop/prefsCache.db All of those configurations result in the same errors (see previous message). This seems odd: groups ntop ntop Shouldn't the config script have added 'jdoe'? (So I tried adding 'jdoe', with 'adduser jdoe ntop', but that didn't help.) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#179424: gedit: Sometimes v2.1.91-1 displays TWO cursors.
On 21 Jan 2005 at 11:13, Loïc Minier [EMAIL PROTECTED] wrote: I believe this bug was fixed a while ago in Gtk, and hence I'm closing this bug, please reopen it (or mail me) if you still get the bug. You're are right. Just did a test, and couldn't reproduce the bug with 'gedit' v2.8.2-1. It's fixed.
Bug#181699: #181699 wine: vague error message: dramatically effect in what way?
On 16 Jan 2005 at 18:55, Scott Ritchie [EMAIL PROTECTED] wrote: What really matters is not whether Wine has a Windows drive and filesystem to sit on top of, but whether or not Wine can use native Windows DLLs instead of its builtin ones. Some DLLs in Wine are so perfect that they can be used in Windows - no benefit will be gained from running an app that uses these natively. Some of Wine's DLLs are buggy or incomplete - using stock native Windows ones was a way around this, however a lot of work has been done on the problem areas. So you're saying the vague message is really suggesting that the user start toggling DLLOverides between 'native' and 'builtin', and thus enter into 'wine's own circle of trial-and-error .DLL Hell. Yech! One reason we like Debian better is that '.deb' files do away with most of that. You should already know what wine's .DLL hell entails, but it's new to me, and for other new readers here's an outline of my recent studies... Consider Pegasus Mail. How many .DLLs does it depend on? WINEDEBUG=+loaddll wine ../pmail/winpm-32.exe | grep dll | wc -l 29 # the answer Supposing all 29 .DLLs can be set to native (windows version), or builtin (wine's version) and we don't know in advance which ones work better. 29 combinations of two makes for 2^29=536,870,912 variants to try. Brute force is absurd. We can eliminate certain choices because their 'native' versions will never work with 'wine'. We can eliminate others because 'wine' has no 'builtin' equivalents. Suppose those two rounds of elimination remove 80% of the 29 .DLLs. Leaving 6 .DLLs we're not sure about. 6 .DLLs means 2^6=64 combinations to test. Some of those 64 combinations might work. A 'wine' expert might be able to narrow it down using the debugger. Those particular combinations could change between versions of 'wine' and 'Pegasus', which further complicates matters. Up to 536 million possibilities, which might be lowered to 64 or under, depending on one's expertise. Said wide range of possibilities is CASUALLY ALLUDED to as ONE change you can make that will dramatically effect Wine's behaviour... Third try: Note to sophisticated experimenters: you may be able to dramatically improve Wine's behaviour by editing your '.wine/config' file and toggling its many [DLLOverides] between 'native' and 'builtin'. There can be millions of combinations, so this is only recommended for experts. It's incredible to suggest ordinary users do that. It's a waste of expert time if every expert keeps reconfiguring every program they use. Therefore what's needed is a proper dependency system for 'wine'. I'm thinking it would be a database of popular or useful DLLOverrides that would include 'wine' versions, and unambiguous program and DLL names and versions. Anytime an expert figured out how to get 'Foo v13 for Windows' to work in 'wine' he'd make a little program specific [AppDefaults\\Foov13\\DllOverrides] thingee and add it to the database. Users would look up those Overrides, (or an automated loader would), and 'wine' would use them, and it might work better than MS Windows ever did, because it'd function with conflicting DLLs. How a 'wine' (or a loader program) would use a DLLOverrride database. 1) Check if the correct DLLs existed. If not, advise user. Example: you need foo.DLL version 28 to run Foo v13, it's in Foo's installer archive .EXE. Put it in the 'foo' directory, then try running 'wine foo' again. 2) If the correct DLLs exist, use them. A Bug Tracking System for these Override patches would be needed. A tall order, but what else can be done? Non-experts toggling DLLOverrides is nuts. Windows by it's own chaotic nature needs Overrides. 'wine' experts are already doing the needed work, so what's needed is to organize and harness their redundant labors. ...I highly recommend you don't use a windows drive and instead let Wine create its own fake windows drive automatically, and you then supply some of the missing DLLs using Winetools. A link to Winetools can be found on the Wine downloads page, along with packages for the latest release of Wine. Thanks for the tip, but scavenger hunt advice is such a halfway measure. Please consider providing a URL next time you cite a file. So it's at 'the Wine downloads page'? Here perhaps: http://www.winehq.com/site/download ...which has a 'winetools' URL to: http://www.von-thadden.de/Joachim/WineTools/ ...which has no .deb files, only a .tgz and this .rpm: http://ds80-237-203-29.dedicated.hosteurope.de/wt/winetools-2.1.0-jo.i386.rpm Well it seems that can be converted to a '.deb' file with 'alien', but the result has a dependency on the 'xdialog' package that 'alien' doesn't notice. apt-get install xdialog. 'wt' still won't work until a symlink to 'Xdialog' is made: ln -s `which Xdialog`
Bug#280220: 68th day Nag: #280220 perl-base: 'man perl' doesn't link in 'dwww' or 'pinfo'
Hey, anybody tried the patch yet? The man page looks nicer with it, to say nothing of the improvement under 'pinfo'. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#181585: wc.1: name synopsis should include count keyword
A .diff for '/usr/share/man/man1/wc.1.gz' is attached. Before: wc \- print the number of newlines, words, and bytes in files After: wc \- for text files, count newlines, words and bytes Notes: when seaching with 'apropos', print and number are vague to the point of being useless. On my system: apropos number | wc -l 160 apropos print | wc -l 221 apropos count | wc -l # fewer 22 An unqualified 'files' is worse: apropos files | wc -l 379 apropos file | wc -l 1147 apropos text files | wc -l # fewer 9 apropos text file | wc -l # 12 Trivia: a Bell Labs Unix manual says wc - word count. HTH... 4c4 wc \- print the number of newlines, words, and bytes in files --- wc \- for text files, count newlines, words and bytes
Bug#290127: lg-subscription: v.110 presently not installable
On 13 Jan 2005 at 8:21, Joerg Jaspert [EMAIL PROTECTED] wrote: Its just how the dependency system works. Requiring the packages. Wait until it gets out of incoming and its done. That's not very constructive advice JJ... I already KNEW about Debian Unstable's poorly synchronized dependency system before writing the bug report. Perhaps my first report didn't get my ideas across; a recap and a few ideas as to what a fix might look like follow... The current behavior of 'lg-subscription' makes the package name inaccurate. So either the name should be changed to some other word that doesn't give a false impression of what it does, (lg-recent-issues?), or else it should be fixed so that it lives up to its name. Surely all users would prefer the latter. There must be other ways to do subscriptions so that this doesn't occur. Why should a subscription package depend on any particular issue? Why should the subscription package itself need to be updated whenever a new issue comes out? That's more work for you than if 'lg-subscription' needed no periodic human maintenance. Suppose that there was script that runs every so often, say every four weeks after the last successful subscription fetch, then every few days as needed until the next successful fetch, perhaps after an 'apt-get update'. The script checks what LG issues the user has, and what newer ones are available. Then, IF there's a new one, it constructs an 'lg-subscription-adhoc-latest' package in '/var/cache/apt/archive' on the fly, and updates the package list to include it. Naturally, the hypothetical 'lg-subscription-adhoc-latest' would be required by 'lg-subscription'. Some example code: One way to find out the latest issue available (shell script): dglob lg-issue -a | sed 's/[a-z-]*//' | sort -g | tail -1 107 And how to find out what's the newest issue installed: dglob lg-issue | sed 's/[a-z-]*//' | sort -g | tail -1 107 Compare these numbers, and if the second is lower, make a list of the needed LG issues: wehave=`dglob lg-issue | sed 's/[a-z-]*//' | sort -g | tail -1` theyhave=`dglob lg-issue -a | sed 's/[a-z-]*//' | sort -g | tail -1` if [ $wehave -lt $theyhave ] then getthese=`seq -f lg-issue%g $wehave $theyhave` # magic code goes here to make 'lg-subscription-adhoc-latest', # which depends on '$getthese'. fi Or something like that. Perhaps there's a less kludgy way than making a dummy package -- maybe the magic code could be as simple as: apt-get install $theyhave ...but I don't know how that would work for modem users when they're offline. I'll reopen this bug as a 'wishlist' and rename it with a more general description. Please, if you have no desire to fix it, refrain from closing it and kindly tag it with a 'wontfix'. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#289114: gnome-randr-applet: for crowded button bars applet needs to be on far left
On 10 Jan 2005 at 7:37, Sven Luther [EMAIL PROTECTED] wrote:
...by 'reverting' I think you mean just reverting the screen
resolution, NOT reverting the panel layout which might still become
garbled? If the panel can still be garbled, it would help to warn
users about this somewhere.
Yep, reverting the resolution, people can ungarble the panel by hand
then. I can add a warning in README.Debian if you want, care to propose
a text for it?
It seems kinder to warn them BEFORE the panel gets garbled.
Proposed (prior to resizing) text:
[titlebar: Grandr -- Two 'Gnome Panel' Bug Warnings ]
Caution: when panels are crowded with buttons and applets,
shrinking or expanding the screen size can garble the panel.
Before: |A B C D E { app1, app2, ... }(switcher)(clock)|
After:| A B C D E{a1,a2..} (switcher)(clock)|
Caution: the 'grandr' applet button should be on the far LEFT of
the panel. If it's not, hit 'Cancel' now and move the button left.
(At lower resolutions a button on the right won't fit on the panel,
stranding you the user in a lower resolution.)
For more details on these no good bugs see:
URLs of any relevant bugs
Still want to resize? { OK } { Cancel }
Pixmaps for the 'Before' and 'After' examples would be even better.
For 'gnome-panel' I'm thinking the best solution would be...
Please fill a separate bug for this against the gnome packages (gnome-panel i
think, make sure it is the exact name though).
Here ya go:
#289980: gnome-panel: Panel hides and loses information after resizing
screen
with 'xrandr'
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=289980
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#289117: Re #289117: cause of 'scrunch'. Was: Bug#289114: gnome-randr-applet: for crowded button bars applet needs to
On 10 Jan 2005 at 7:38, Sven Luther [EMAIL PROTECTED] wrote: use gnome-panel, its a safe bet, and then the gnome folk can sort it out between themselve. They team-work anyway, so it is no major problem anyway. Here be it: #289975: gnome-panel: Moving 'Window List' applet scrunches it, messing up panel http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=289975 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#289631: galeon: Browser/Earth graphic in 'HelpAbout' in flagrante delicto?
On 10 Jan 2005 at 10:17, Loïc Minier [EMAIL PROTECTED] wrote: If you're not sure of seeing something shocking, then could we conclude that there's nothing shocking for most people and close this bug? It's not shocking, it's a hoot! What most people make of it I dunno, but I'm not the only one who's noticed it. I really don't think the logo was meant in the intention to shock anyone. Of course not -- which makes it unintentionally hilarious. Consider the greek mythology of the constellation -- some folks can't see the Gemini or Hercules, etc. But stargazers who've learned them can hardly not see them. The Classical Constellations: Northern Hemisphere http://www.cosmopolis.com/star-myths/classical-const-north.html It resembles psychological ambiguities like the Necker Cube: Mark Newbold's Animated Necker Cube (requires Java) http://dogfeathers.com/java/necker.html Necker cube http://en.wikipedia.org/wiki/Necker_cube Multistable perception http://en.wikipedia.org/wiki/Multistable_perception Galeon's logo also recalls a grotesque Time magazine illustration from 1995: http://cgi.pathfinder.com/time/magazine/archive/1995/950703/950703.cover1.jpg Well, this seems like overkill so I'll Say no more!, having become the skit: http://www.jumpstation.ca/recroom/comedy/python/nudge.html
Bug#289631: galeon: Browser/Earth graphic in 'HelpAbout' in flagrante delicto?
On 11 Jan 2005 at 10:00, Loïc Minier [EMAIL PROTECTED] wrote: I can leave this bug as wontfix for example, and if similar reports appear in a quantity suggesting there is really something wrong with the logo for a significant number of people, we'll do something about it. Fair enough. (I wouldn't say it's wrong exactly, just odd, it might be a more interesting graphic for all that, a sort of accidental Joe Camel.)
Bug#289631: URL correction for Time Mag. illo.
AC said yesterday: Galeon's logo also recalls a grotesque Time magazine illustration from 1995: http://cgi.pathfinder.com/time/magazine/archive/1995/950703/950703.cover1.jpg Sorry, wrong URL, that's a dead link. Here's the live one: http://www.nicoladoering.net/Hogrefe/elmer-Dateien/950703.cover1.gif -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
