Bug#291046: foomatic-filters-ppds
On Tue, 18 Jan 2005, Chris Lawrence wrote: > I think the PPD files in the latest version of foomatic-filters-ppds > are compatible with hpijs 2.x (at least for the printers where it > makes a difference), so it looks like we should actually make it > depend on the new hpijs rather than the old one. Well, I didn't check if it *dependend* on hpijs, so I suggested *conflicting* with the old hpijs... -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#291177: [PROPOSAL] Policy for user/groups creation/removal in package maintainer scripts
On Wed, 19 Jan 2005, Javier Fernández-Sanguino Peña wrote: > There is currently no policy on how should per-package users be created and > removed. Eeven though the 'UID and GID classes' sections determines that > packages _should_ use adduser --system in some occasions it doesn't Make it *must* use adduser --system, *if* they add an user at all. > - maintainers scripts should create a system user for their daemon in > postinst. User creation should not fail if the user already exists > (example code should be provided here, since this is sometimes not done > properly in maintainer scripts). Maintainer scripts can ask to the admin if > the user already exists. Maintainer scripts can ask about an already existing user *if and only if* it is not a system user... no more useless, aggravating postinst prompts, please. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh
Bug#291177: [PROPOSAL] Policy for user/groups creation/removal in package maintainer scripts
On Wed, 19 Jan 2005, Javier Fernández-Sanguino Peña wrote: > On Wed, Jan 19, 2005 at 09:54:50AM -0200, Henrique de Moraes Holschuh wrote: > > On Wed, 19 Jan 2005, Javier Fernández-Sanguino Peña wrote: > > > There is currently no policy on how should per-package users be created > > > and > > > removed. Eeven though the 'UID and GID classes' sections determines that > > > packages _should_ use adduser --system in some occasions it doesn't > > > > Make it *must* use adduser --system, *if* they add an user at all. > > Some packages might need to use a hardcoded UID (and there's a UID range > for those) those don't use 'adduser --system' Then they *must* request that UID to be statically allocated to them, and add a proper versioned dep to the base-passwd package providing it. This is an old, old rule, if it is not a "must" yet, it is about time it becomes one... > > Maintainer scripts can ask about an already existing user *if and only if* > > it is not a system user... no more useless, aggravating postinst prompts, > > please. > > True. I would love to see a sample for that so that postinst scripts would > reuse that. Actually, it could even be integrated into a dh_adduser script, > couldn't it? Yes, it could. For a sample, please see the amavisd-new or cyrus21-imapd packages. Both do it. I do not claim they do it in the best possible way, but it works. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh
Bug#291321: hplip: turns printer on on start/restart
Package: hplip Version: 0.8.4-4 Severity: minor Tags: upstream forwarded confirmed Certain USB printers will be turned on every time hpiod or cups is started/restarted. This is caused by the HPLIP probes on ink level and so on. Upstream knows of the issue, and it will have to be fixed there. Upstream technical support contact recomends that the printer be left on, instead of being subject to continuous power-up/power-down cycles. -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (990, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.10-debian4+libata9dev1 Locale: LANG=pt_BR, LC_CTYPE=pt_BR (charmap=ISO-8859-1) Versions of packages hplip depends on: ii cupsys 1.1.23-2 Common UNIX Printing System(tm) - ii hplip-data 0.8.4-4 HP Linux Printing and Imaging - da ii libc6 2.3.2.ds1-20 GNU C Library: Shared libraries an ii libcupsys2-gnutls10 1.1.23-2 Common UNIX Printing System(tm) - ii libgcc1 1:3.4.3-7GCC support library ii libsnmp55.1.2-6 NET SNMP (Simple Network Managemen ii libssl0.9.7 0.9.7e-3 SSL shared libraries ii libstdc++5 1:3.3.5-6The GNU Standard C++ Library v3 ii python 2.3.4-6 An interactive high-level object-o -- no debconf information -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#291429: hplip_toolbox leave processes and zombies
On Thu, 20 Jan 2005, Erwan David wrote: > After using and leaving hplip_toolbox, I noticed there was a zombie of > xsane. Looking further, the father of the zombie was a python script > named hpguid, that the toolbox had left behind and which makes zombies. hpguid is indeed left behind as a daemon, to present GUI messages to the user. But it should not leave zoombies behind. Unfortunately, I have *zero* capability of testing any of the scan/photo-card access functions, so we will need your help to try to fix this. Upstream tells me a 0.8.7 release is just around the corner. After it is released, and uploaded to debian, I'd like you to re-test the issue to see if it was fixed upstream, and report back to this bug. If the issue is still there, we shall see what we can do to try to fix it. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#291431: Font too big and no way to change it in hplip_toolbox
On Thu, 20 Jan 2005, Erwan David wrote: > The hplip_toolbox is displayed with a font far too big for my > system. However, tehre is no way to change this font. It uses the Qt toolkit, maybe one of the KDE configuration helpers can configure Qt fonts? -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#291445: coreutils: dd: should have option to enable O_DIRECT
Package: coreutils Version: 5.2.1-2 Severity: wishlist dd should either always use O_DIRECT for reading and writing, or it should allow one to set it as an option. /dev/raw is deprecated, and many dd uses really are a prime candidate for O_DIRECT. Examples of stuff that waste a tremendous ammount of VM due to dd's lack of O_DIRECT behaviour: dd if=/dev/zero of=(disk block device) dd if=file of=(disk, tape or cd/dvdrom block device in packet writing mode) dd if=(one block device) of=(other block device) with disks. -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (990, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.10-debian4+libata9dev1 Locale: LANG=pt_BR, LC_CTYPE=pt_BR (charmap=ISO-8859-1) Versions of packages coreutils depends on: ii libacl1 2.2.26-1 Access control list shared library ii libc6 2.3.2.ds1-20 GNU C Library: Shared libraries an -- no debconf information -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#291445: coreutils: dd: should have option to enable O_DIRECT
On Thu, 20 Jan 2005, Jim Meyering wrote: > FYI, this feature is available in the latest upstream test release: > ftp://alpha.gnu.org/gnu/coreutils/coreutils-5.3.0.tar.gz > ftp://alpha.gnu.org/gnu/coreutils/coreutils-5.3.0.tar.bz2 Neat! I hope it is uploaded to unstable soon, then! -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#221894: Bug#226720: Is there a timeframe for building 2.2?
On Fri, 21 Jan 2005, RISKO Gergely wrote: > > > Would you be opposed to putting the package under collaborative > > > maintenance on alioth? That would allow people to start using and > > > improving whatever you have at the moment. > > > > Not really. Lets see if I manage to do this early next week. > > We have seen. I think, now you should accept Fabian's help. http://alioth.debian.org, search for pkg-cyrus-imap. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#115655: [ARCH][DPKG-ARCHITECTURE] outputs non-canonical GNU system type
On Sat, 22 Jan 2005, Scott James Remnant wrote: > 4) Add a dependency on autotools-dev; promoting it all the way from >optional to Essential. It is simple enough that this would be doable, BUT I don't think it is the right way either. > I don't think (3) fixes the problem and I don't think (4) is tenable. I > think the correct solutions to this bug are (1) and (2), which we > already do. > > I therefore declare this bug closed unless a (5) can be found. (5) dpkg-architecture are static values, known to all arches that are supported. One can: 5a) Use config.sub at build time (autotools-dev build dep, if one wants), to get the full GNU arch string OR 5b) Just hardcode it like the rest. I don't mean runtime-add a -gnu, I mean actually using config.sub at the time an arch is added to check what the correct string is, and add that to dpkg. IF we ever need to change that string, it is trivial to get it included as an alias at least on Debian's config.sub. Still, since the whole madness IS currently fixed by autotools-dev, I don't really care. So, as far as I am concerned, we could just *document* that what we return through dpkg-architecture is basically incomplete and needs to be piped through config.sub to get the full string. How to use it in a correct way is alredy documented by autotools-dev. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#291746: hplip: uninstalls uncleanly
On Sat, 22 Jan 2005, Chung-chieh Shan wrote: > Purging hplip leaves compiled Python files (*.pyc) in /usr/lib/hplip . > Perhaps these files should be removed when hplip is uninstalled? They should. Which version of hplip? -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#115655: [ARCH][DPKG-ARCHITECTURE] outputs non-canonical GNU system type
On Sun, 23 Jan 2005, Scott James Remnant wrote: > It's useful to pass to anything that accepts a GNU type, because they That's a very weak excuse to keep this unfixed. Please document it as a BUGS entry in the dpkg-architecture manpage, at the very least. > either understand non-canonical types or canonicalise types before using > them. They *always* canonicalse types. But that can only be done safely if whatever you gave to config.sub is unique enough. For *now*, stuff lacking -gnu are good enough, so nothing breaks. BTW, what you have in the dpkg-architecture manpage about how to use the output of dpkg-architecture with autoconf would best be replaced to a pointer to the README.Debian for autotools-dev. Really. If you'd rather have it on a manpage, I can write one and add it to autotools-dev. Does autotools-dev(7) sound good? > It's suitable for "configure", and good enough for gcc; seems reasonable > to me. Since when are we about "good enough" anything? If that's the explanation, please reopen the bug and tag it wontfix. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#288876: [Flac-dev] liboggflac1 soname
On Mon, 24 Jan 2005, Josh Coalson wrote: > OK, I am going to do a 1.1.2 earlier than I wanted in order to > fix this. anyway there are some bug fixes and speedups that will > be of benefit. > > because of the mess and since there have been API changes and > additions in both libFLAC and libOggFLAC since 1.1.1 I plan on > bumping all the libtool numbers as follows: current++, revision=0 > age=0. if this will cause problems please let me know. That'll be perfect. Thank you! -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#291939: (fwd) Re: Bug#268377: Bug#291939: Support for arch aliases (Was: Split System/Cpu for architecture handling)
Drat, reply to list was not what I had to do. Sorry about this. - Forwarded message from Henrique de Moraes Holschuh <[EMAIL PROTECTED]> - On Mon, 24 Jan 2005, Guillem Jover wrote: > The idea is to introduce architecture aliases, they will only take [...] > I've a added as well a new option (-n normalize) to dpkg-architecture > so Maintainers can use it to get the alias expansions. Try it to see > the results. The (only) problem I can see with this is that, should we add or remove a new arch to an alias, you have to recompile everything to be completely in sync. This can be fixed by keeping the alias somewhere, instead of just expanding it everywhere. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#292299: ITP: policyrcd -- policy-compliant interface from invoke-rc.d to local config files
On Wed, 26 Jan 2005, David Pashley wrote: > > Since there are at least two packages containing their own version of > > invoke-rc.d, having a search path policy for policy-rc.d can be > > messy and is prone to be unstructured and uncoordinated. No, it is not. invoke-rc.d *HAS* to be coordinated, and implemented by every initscript system. The maintainers of these packages are well aware of that fact. The better fix IS to add an extra line to both incarnations of invoke-rc.d (sysv-rc's and file-rc's) to look under /usr/local/sbin first. > It seems a bit excessive having a package for just one script. Is there > not another package this could go in instead? No. Either it has to go on a package of its own, or it has to have the functionality folded into file-rc and sysv-rc. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#292299: ITP: policyrcd -- policy-compliant interface from invoke-rc.d to local config files
On Wed, 26 Jan 2005, David Pashley wrote: > > The better fix IS to add an extra line to both incarnations of invoke-rc.d > > (sysv-rc's and file-rc's) to look under /usr/local/sbin first. Make that "later". I just noticed one has to run the system's /usr/sbin/policy-rc.d in preference to all else. If it does not exist, then /usr/local/sbin/policy-rc.d can be checked for. > Then I suggest a patch is submitted to both file-rc and sysv-rc. So do i. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#292299: ITP: policyrcd -- policy-compliant interface from invoke-rc.d to local config files
On Thu, 27 Jan 2005, Marc Haber wrote: > On Wed, 26 Jan 2005 08:12:36 -0200, Henrique de Moraes Holschuh > <[EMAIL PROTECTED]> wrote: > >On Wed, 26 Jan 2005, David Pashley wrote: > >> > The better fix IS to add an extra line to both incarnations of > >> > invoke-rc.d > >> > (sysv-rc's and file-rc's) to look under /usr/local/sbin first. > > > >Make that "later". I just noticed one has to run the system's > >/usr/sbin/policy-rc.d in preference to all else. > > Why? Because if any package that is NOT a policy-rc.d package is providing a policy-rc.d in /usr/sbin, it has a damn good reason to do so, and it should take precendence. Examples of damn good reasons are alternative initscript managers such as runit. If a package that is a policy-rc.d package is installed, then the local admin is supposed to take care of things (he should uninstall that package, if he wants to use his own policy-rc.d under /usr/local. Or register his policy-rc.d as an alternative and select that one, etc). -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#292299: ITP: policyrcd -- policy-compliant interface from invoke-rc.d to local config files
On Thu, 27 Jan 2005, Marc Haber wrote: > On Thu, Jan 27, 2005 at 10:37:05AM -0200, Henrique de Moraes Holschuh wrote: > > On Thu, 27 Jan 2005, Marc Haber wrote: > > > On Wed, 26 Jan 2005 08:12:36 -0200, Henrique de Moraes Holschuh > > > <[EMAIL PROTECTED]> wrote: > > > >On Wed, 26 Jan 2005, David Pashley wrote: > > > >> > The better fix IS to add an extra line to both incarnations of > > > >> > invoke-rc.d > > > >> > (sysv-rc's and file-rc's) to look under /usr/local/sbin first. > > > > > > > >Make that "later". I just noticed one has to run the system's > > > >/usr/sbin/policy-rc.d in preference to all else. > > > > > > Why? > > > > Because if any package that is NOT a policy-rc.d package is providing a > > policy-rc.d in /usr/sbin, it has a damn good reason to do so, and it should > > take precendence. Examples of damn good reasons are alternative initscript > > managers such as runit. > > Packages providing /usr/sbin/policy-rc.d are required to use the > alternatives system anyway. Yes, but they can use diversions when the entire policy-rc.d system has to be disabled, if need be. However, if invoke-rc.d searches /usr/local/sbin/policy-rc.d first, this whole safety net is disabled. So invoke-rc.d could be changed to look under /usr/local/sbin/policy-rc.d as well, but only if it failed to find a runnable policy-rc.d at /usr/sbin/policy-rc.d. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#292299: ITP: policyrcd -- policy-compliant interface from invoke-rc.d to local config files
On Thu, 27 Jan 2005, Henrique de Moraes Holschuh wrote: > Yes, but they can use diversions when the entire policy-rc.d system has to > be disabled, if need be. Make it a very high priority alternative. It is probably a bad idea to try our luck with diverting an alternative. Still, the rationale for /usr/local last holds. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#292299: ITP: policyrcd -- policy-compliant interface from invoke-rc.d to local config files
On Thu, 27 Jan 2005, Marc Haber wrote: > On Thu, Jan 27, 2005 at 11:24:01AM -0200, Henrique de Moraes Holschuh wrote: > > However, if invoke-rc.d searches /usr/local/sbin/policy-rc.d first, this > > whole safety net is disabled. > > One could argue that the local admin explicitly requested to have that > net disabled. > > > So invoke-rc.d could be changed to look under /usr/local/sbin/policy-rc.d as > > well, but only if it failed to find a runnable policy-rc.d at > > /usr/sbin/policy-rc.d. > > So how do I override a non-fitting /usr/sbin/policy-rc.d? Being forced Remove the package providing it. The only two types of pacakge that are to provide policy-rc.d are packages that implement a policy-rc.d system (and if you don't want that, remove the package), AND packages that know they must disable invoke-rc.d for some weird reason (which I am kind of suspicious might be a mistake on the whole reasoning of whomever needs that, but I am playing safe). -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#341000: hplip-base: fails to install due to libsnmp5 (>= 5.1) not being installable
reassign 341000 ftp.bugs.debian.org severity 341000 important merge 341000 340467 thanks There is nothing I can do. Thanks for assigning 341000 to me :-) But unfortunately this is a major testing fuckup and not something wrong with the HPLIP packages. On Sun, 27 Nov 2005, Aldo Maggi wrote: > Package: hplip-base > Version: 0.9.3-3 > Severity: grave > Justification: renders package unusable > > fails to install due to libsnmp5 (>= 5.1) not being installable, this package > is not listed > among dependancies in http://packages.debian.org/testing/utils/hplip-base Yes it is. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#341060: initscript: completely broken
Package: sysfsutils Version: 1.3.0-3 Severity: grave Justification: renders package unusable if [ "$f1" ] ;... is NOT valid shell syntax. Nor is [ ... -a "$f2" ]. You're missing a "-n" in front of all bare string tests inside [ ]. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (990, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.13.4-debian1+libata+bluesmoke+imq+lm85 Locale: LANG=pt_BR.ISO-8859-1, LC_CTYPE=pt_BR.ISO-8859-1 (charmap=ISO-8859-1) Versions of packages sysfsutils depends on: ii libc6 2.3.5-8.1 GNU C Library: Shared libraries an ii libsysfs1 1.3.0-3interface library to sysfs sysfsutils recommends no packages. -- no debconf information -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#341060: initscript: completely broken
severity 341060 grave thanks (I am setting it back to grave so that apt-listbugs warns people off until an upload fixing the bug hits the archive. See the rest of the email). On Mon, 28 Nov 2005, Martin Pitt wrote: > The script runs fine with bash and dash, and [ "$foo" ] is common Well, here it broke with bash from sid depending on the values of $foo, which is probably why you could not reproduce it. > practice and described in test(1: > >-n STRING > the length of STRING is nonzero > >STRING equivalent to -n STRING Braindamaged common practice, that one is. If with "-" the string is, stupid things test will do. Never use naked strings with test, it is courting an error mode. I *think* it is smart enough not to croak if you [ "$string" ], but it will on [ "$string" -a something -a "$string2" ]... In this case it barfs when some of the strings are "-1", see attached error dump. Try this: a=1 ; b=-1 ; [ -n "$a" -a "$b" ] && echo ok Interestingly enough, a=1 ; b=-1 ; [ "$a" -a "$b" ] && echo ok won't croak. This is bash trying to be smart, as a=1 ; b=-1 ; /usr/bin/[ "$a" -a "$b" ] && echo ok WILL croak. > Please give me the output of sh -nx /etc/init.d/sysfsutils if it > really breaks for you. "if it really breaks"? I'd have worded that request very differently, the way you did is not nice at all. I hope you did so because of the @d.o address, and would not write something like that to a regular user. Output attached, and sysfs.conf attached too. BTW, "-nx" gives no output, I ran it with -x only. also, just for completeness: khazad-dum:/etc# ls -lad /bin/sh lrwxrwxrwx 1 root root 4 Oct 14 19:47 /bin/sh -> bash and khazad-dum:/etc# head -n 1 /etc/init.d/sysfsutils #! /bin/sh -e -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh # # /etc/sysfs.conf - Configuration file for setting sysfs attributes. # # The sysfs mount directory is automatically prepended to the attribute paths. # # Examples: # # Always use the powersave CPU frequency governor # devices/system/cpu/cpu0/cpufreq/scaling_governor=powersave # # Use userspace CPU frequency governor and set initial speed # devices/system/cpu/cpu0/cpufreq/scaling_governor = userspace # devices/system/cpu/cpu0/cpufreq/scaling_setspeed = 60 ## ## ADM-1027 temperature monitor / fan controller ## # Device setup (maybe overriden later by /etc/sensors.conf) # Generated using sensors.conf, look there. class/i2c-adapter/i2c-0/device/0-002e/vrm = 91 class/i2c-adapter/i2c-0/device/0-002e/in0_max = 1576 class/i2c-adapter/i2c-0/device/0-002e/in0_min = 1419 class/i2c-adapter/i2c-0/device/0-002e/in1_max = 1523 class/i2c-adapter/i2c-0/device/0-002e/in1_min = 1301 class/i2c-adapter/i2c-0/device/0-002e/in2_max = 3472 class/i2c-adapter/i2c-0/device/0-002e/in2_min = 3128 class/i2c-adapter/i2c-0/device/0-002e/in3_max = 5260 class/i2c-adapter/i2c-0/device/0-002e/in3_min = 4740 class/i2c-adapter/i2c-0/device/0-002e/in4_max = 12625 class/i2c-adapter/i2c-0/device/0-002e/in4_min = 11375 ## Temperature control ## # temp1: CPU Temperature class/i2c-adapter/i2c-0/device/0-002e/temp1_min = 05000 class/i2c-adapter/i2c-0/device/0-002e/temp1_max = 8 class/i2c-adapter/i2c-0/device/0-002e/temp1_auto_temp_off = 26000 class/i2c-adapter/i2c-0/device/0-002e/temp1_auto_temp_min = 45000 class/i2c-adapter/i2c-0/device/0-002e/temp1_auto_temp_max = 55000 class/i2c-adapter/i2c-0/device/0-002e/temp1_auto_temp_crit = 65000 # temp2: ADM1027 Temperature class/i2c-adapter/i2c-0/device/0-002e/temp2_min = 0 class/i2c-adapter/i2c-0/device/0-002e/temp2_max = 6 class/i2c-adapter/i2c-0/device/0-002e/temp2_auto_temp_off = 35000 class/i2c-adapter/i2c-0/device/0-002e/temp2_auto_temp_min = 35500 class/i2c-adapter/i2c-0/device/0-002e/temp2_auto_temp_max = 5 class/i2c-adapter/i2c-0/device/0-002e/temp2_auto_temp_crit = 5 # temp3: Motherboard (environment) Temperature class/i2c-adapter/i2c-0/device/0-002e/temp3_min = 0 class/i2c-adapter/i2c-0/device/0-002e/temp3_max = 55000 class/i2c-adapter/i2c-0/device/0-002e/temp3_auto_temp_off = 35000 class/i2c-adapter/i2c-0/device/0-002e/temp3_auto_temp_min = 35500 class/i2c-adapter/i2c-0/device/0-002e/temp3_auto_temp_max = 5 class/i2c-adapter/i2c-0/device/0-002e/temp3_auto_temp_crit = 6 ## Fan and PWM control ## class/i2c-adapter/i2c-0/device/0-002e/auto_acoustics_enhancement = 2 # fan1: CPU fan class/i2c-adapter/i2c-0/device/0-002e/fan1_min = 2000 class/i2c-adapter/i2c-0/device/0-002e/pwm1_auto_channels = -1 # fan2: VR fan #class/i2c-adapter/i2c-0/device/0-002e/fan2_min = 1800 #class/i2c-adapter/i2c-0/device/0-002e/pwm2_auto_channels = -1 class/i2c-adapter/i2c-0/device/0-002e/fan2_min = 0 class/i2c-adapter/i2c-0/device/0-002e/pwm2_auto_channels = 0 # fan3: Front fan and fan4: Rear fan class/i2c-
Bug#193364: [Amavisd-new-debian-devel] Re: Bug reports
forwarding message from amavisd-new upstream to relevant bug reports.
From: Mark Martinec <[EMAIL PROTECTED]>
Subject: [Amavisd-new-debian-devel] Re: Bug reports
Date: Wed, 3 Aug 2005 17:25:11 +0200
Brian,
Sorry for delay, your mail just arrived when I left for vacation,
and now it took me a while to catch up with my mail.
> I am going through old bug reports for amavisd-new in Debian,
> I suspect many are obsolete and can be closed.
>
> Anyone know if any of these can be closed?
> Any help closing bug reports would be appreciated.
http://bugs.debian.org/193364>
Can be closed, the default current log entry (2.3.2) looks like:
Blocked SPAM, [10.11.12.13] [10.1.2.3] <...> -> <...>,
Message-ID: <...>, mail_id: DLIEolNRsDou, Hits: 22.545+1.8, 11958 ms
The corresponding macro is %c:
%c spam level/hits (mnemonic: sCore) as provided by SpamAssassin,
including a per-recipient boost when used in $log_recip_templ
and a min of per-recipient boosts in other templates
http://bugs.debian.org/211740>
Solved in amavisd-new-2.3.0 when feeding MTA->amavisd over LMTP.
The problem does not have a better solution when using SMTP protocol.
From the release notes:
- at last: when mail is received through LMTP protocol, gracefully handle
a temporary failure 4xx reply from MTA to a RCPT TO command and pass it
back to a LMTP client for tempfailed recipients only, instead of returning
450 for _all_ recipients (needed the sending routine to be aware of the
receiving side capabilities, which was previously not available);
http://bugs.debian.org/228766>
In 2.3.2 (and earlier) there are the following commented-out lines
in file amavisd. Uncommenting them achieves what was requested.
# $hdr_edits->append_header('X-Spam-Checker-Version',
# sprintf("SpamAssassin %s (%s) on %s", Mail::SpamAssassin::Version(),
# $Mail::SpamAssassin::SUB_VERSION, $myhostname));
http://bugs.debian.org/236482>
In case of exceeded decoding quota or file number limit the
current version (2.3.2) or amavisd-new no longer 'preserves evidence',
it just tempfails the message.
http://bugs.debian.org/281752>
The request is still valid, but has a low significance, because
REJECT is only useful in pre-queue mail filtering setup, and
amavisd-new is targeted at post-queue filtering, in which case
the additional information would only be seen in one's own MTA log,
which is not of much use. The REJECT destiny setting is pretty much
useless in post-queue setup, the preferred settings are BOUNCE or DISCARD
Regards
Mark
- End forwarded message -
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#228766: marking this bug as wontfix
tag 228766 + wontfix thanks This bug cannot be fixed without help from spamassassin upstream. Upstream amavisd-new removed the commented-out code, and Debian won't add futher breakage points to amavisd-new for a wishlist. Please feel free to remove the wontfix tag AND notify us *if* spamassassin upstream ever publishes an official, public API to get the version strings from perl. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#342068: azureus: Missing options in "options" dialog in the new version
Package: azureus Version: 2.3.0.6-1 Severity: normal Some options are missing in the new version's option dialog, *even in advanced mode*. Namely, the "Priorize most completed files" option is missing. However, that option STILL exists, and it STILL works... but now I cannot disable it anymore! (it was enabled while using an older version of Azureus). Since the file storing Azureu's config is NOT editable without specialized tools or knowledge, I cannot even fix that "by hand" easily. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (990, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.14.3-debian4+bluesmoke+atapassthru+lm85 Locale: LANG=pt_BR.ISO-8859-1, LC_CTYPE=pt_BR.ISO-8859-1 (charmap=ISO-8859-1) Versions of packages azureus depends on: ii libcommons-cli-java 1.0-7 API for working with the command l ii liblog4j1.2-java 1.2.12-1 Logging library for java ii libseda-java 3.0-3 the Staged Event-Driven Architectu ii libswt-gtk-3.1-java 3.1-3 Standard Widget Toolkit for GTK Ja pn sun-j2re1.5 | java-virtual-ma (no description available) pn sun-j2re1.5 | java2-runtime(no description available) Versions of packages azureus recommends: ii java-package 0.27 utility for building Java(TM) 2 re -- no debconf information -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#342314: cyrus22-imapd: long line bug in Cyrus
On Tue, 06 Dec 2005, Mark Nipper wrote: > Please include the patch below as seen on the DSPAM users > list recently (and supposedly already reported to the Cyrus folks, but > no new releases have been made upstream since then). We should try to find this patch (and all other important ones) in Cyrus upstream CVS, and use their version instead (just in case the fix upstream was slightly different). -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#342451: pbuilder-buildpackage-funcs: missing "install" on apt-get line
Package: pbuilder
Version: 0.140
Severity: important
See attached patch, it is an obviously correct one-line fix. Without it,
pbuilder won't work when EXTRAPACKAGES is not empty.
-- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT policy: (990, 'unstable')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.14.3-debian4+bluesmoke+atapassthru+lm85
Locale: LANG=pt_BR.ISO-8859-1, LC_CTYPE=pt_BR.ISO-8859-1 (charmap=ISO-8859-1)
Versions of packages pbuilder depends on:
ii cdebootstrap 0.3.9 Bootstrap a Debian system
ii coreutils 5.93-5 The GNU core utilities
ii debianutils 2.15.1 Miscellaneous utilities specific t
ii debootstrap 0.3.3 Bootstrap a basic Debian system
ii gcc 4:4.0.2-1 The GNU C compiler
ii wget 1.10.2-1 retrieves files from the web
Versions of packages pbuilder recommends:
ii devscripts2.9.10 Scripts to make the life of a Debi
ii fakeroot 1.5.5 Gives a fake root environment
ii sudo 1.6.8p9-3 Provide limited super user privile
-- no debconf information
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
--- pbuilder-buildpackage-funcs.orig2005-12-07 12:30:30.301625633 -0200
+++ pbuilder-buildpackage-funcs 2005-12-07 12:30:40.891320907 -0200
@@ -50,7 +50,7 @@
fi
# install extra packages to the chroot
if [ -n "$EXTRAPACKAGES" ]; then
- $CHROOTEXEC usr/bin/apt-get -y --force-yes ${EXTRAPACKAGES}
+ $CHROOTEXEC usr/bin/apt-get -y --force-yes install ${EXTRAPACKAGES}
fi
}
Bug#342660: cyrus22-imapd: suggest making skiplist the default database backend for new installs
On Fri, 09 Dec 2005, Mark Nipper wrote: > anything BDB. There are seemingly known issues even using db4.3 and db4.3 != db4.2... and there is *NO* *CHANCE* of we linking to BDB 4.3 anytime soon, if I can help it. Skiplist is sensitive to corruption. As in: if it happens, you can start crying. It *can* and *does* deal well with aborted transactions, that's not what I am talking about. bdb 4.2 is fairly resilient to corruption, most of the time a db4.2_recover will do just that, with no data loss. It is also faster than skiplist for random lookups (mailboxes DB/TLS DB/duplicate delivery suppression DB), *especially* when you have a huge ammount of processes doing it (which happens to the mailbox db). So, I really think we should keep using BDB 4.2 as a default for those functions where upstream recommends doing so for performance reasons. > although I upgraded all of my existing db3 files to db4.2 using > db4.2_upgrade, I still ended up having cyrmaster crash on me due to > critical database errors. Cyrus needs to be stopped for that to work without causing corruption, AFAIK. I didn't attempt a db migration yet using Cyrus, but it is always posible to do so using dumps. > At the very least, I would mention this as either part of a > debconf message or in one of the Debian README files so that folks are > aware of the potential dangers in using the BDB backend and a really > simple way to avoid trouble by using only skiplist instead. No debconf obnoxious messages. This is non-negotiable. But discussing about the good and bad of each database backend in the documentation is a good idea. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#342314: [Pkg-Cyrus-imapd-Debian-devel] Bug#342314: cyrus22-imapd: long line bug in Cyrus
On Sat, 10 Dec 2005, Benjamin Seidenberg wrote: > Found this patch, it's the same[0]. Do you want to patch using dpatch or > actually patch the source tree? If you let me know, I can commit tonight. We should always use dpatch, but I'd place this one first in the dpatch chain, with 00__upstream_, or something to the same effect. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#343158: Fcron runs with group "camera".
On Tue, 13 Dec 2005, Olleg Samoylov wrote: > Package: fcron > Version: 3.0.0-2 > Severity: normal > > File created by fcron scripts have group "camera". Only if somehow your system has fucked up its passwd/shadow files. Did you change the system users in *any* way? Activated NIS? Changed /etc/passwd? Changed the passwd map in /etc/nsswitch.conf? Removed the fcron user in some way behind the package's back? -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#343158: Fcron runs with group "camera".
On Tue, 13 Dec 2005, Olleg Samoylov wrote: > How fcron know what group to choose? There are no group settings neither > in config file nor in command options. Did gid setted in compile time? By name (getpwent() lookup). The name is set to 'fcron'. I don't recall if it uses this only to locate the user and then uses the primary group for that user, or if it also chegid to fcron. > But in postinst don't set explicitly what group id assign to fcron group. Yes, it does: adduser --system --group --home /var/spool/fcron \ --no-create-home --disabled-password fcron This creates a fcron _system_ user AND a fcron _system_ group. I have no idea how fcron could get things wrong without external tampering. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#343420: Split directories can only be turned off for the imap spool
tag 343420 upstream wontfix thanks 2.1 is in Deep Maintenance mode. Only Debian-packaging related bugs, or sofware defects will be fixed, wishilist requests for new functionality in the software itself will all be denied. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#343854: amavisd-new: Insecure dependency in `` while running with -T switch at /usr/share/perl5/Net/Server/Daemonize.pm line 67
severity 343854 important thanks On Sun, 18 Dec 2005, Giovanni Biscuolo wrote: > Package: amavisd-new > Version: 20030616p10-5 > Severity: critical > Justification: breaks the whole system As in it destroyed your harddrive, stopped the entire boot process or somesuch? I seriously doubt so. Don't file critical bugs claiming that they break the whole system unless they do exactly that. Downgrading to important. > Starting amavisd: Insecure dependency in `` while running with -T switch at > /usr/share/perl5/Net/Server/Daemonize.pm line 67. I will check that in chroot later. Meanwhile, you can try the version in experimental if you want a non-ancient amavisd-new. *BUT* if you do, please don't file bugs against experimental versions at any priority over "normal". -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#343854: amavisd-new: Insecure dependency in `` while running with -T switch at /usr/share/perl5/Net/Server/Daemonize.pm line 67
On Sun, 18 Dec 2005, Henrique de Moraes Holschuh wrote: > > Starting amavisd: Insecure dependency in `` while running with -T switch > > at /usr/share/perl5/Net/Server/Daemonize.pm line 67. > > I will check that in chroot later. Meanwhile, you can try the version in I cannot duplicate the bug. Plese send me a copy of *all* amavisd-new configuration files, that might help me track down the bug. Also, please make sure you are using up-to-date Etch. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#343854: amavisd-new: Insecure dependency in `` while running with -T switch at /usr/share/perl5/Net/Server/Daemonize.pm line 67
On Mon, 19 Dec 2005, Steve Langasek wrote: > Yes, "critical" is the wrong severity, but why is "important" the wrong one? I will assume you meant "why is 'important' the right one?" > He seems to be describing a bug that makes amavisd unusable, which would > still be "grave", yes? If it was affecting everybody, sure. Unfortunately it isn't, so it is giving me trouble to track it down. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#343854: amavisd-new: Insecure dependency in `` while running with -T switch at /usr/share/perl5/Net/Server/Daemonize.pm line 67
On Mon, 19 Dec 2005, Giovanni Biscuolo wrote: > * Henrique de Moraes Holschuh <[EMAIL PROTECTED]> [2005-12-18 11:56:26 -0200]: > > > I cannot duplicate the bug. Plese send me a copy of *all* amavisd-new > > configuration files, that might help me track down the bug. > > All? I use /etc/amavis/amavisd.conf, you can find it attached. Also /etc/init.d/amavis* and /etc/default/amavis*. And you forgot to attach the amavisd.conf file :-) I *think* you have a problem with perl. I cannot reproduce it here (i386), and really: > Insecure dependency in `` while running with -T switch at > /usr/share/perl5/Net/Server/Daemonize.pm line 67. > Dec 19 10:57:54 amavisd-new[5823]: Net::Server: 2005/12/19-10:57:54 > Insecure dependency in `` while running with -T switch at > /usr/share/perl5/Net/Server/Daemonize.pm line 67.\n\n at line 251 in file > /usr/share/perl5/Net/Server.pm > Dec 19 10:57:54 amavisd-new[5823]: Net::Server: 2005/12/19-10:57:54 > Server closing! That would have caught my eye immediately were it an amavisd-new bug, and it would have been reported quite a while ago too, the amavisd-new you are using is in *sarge*, and it has been there for a damn big while now. So either a perl change broke it, or it rooted out a latent bug. > > Also, please make sure you are using up-to-date Etch. > > Before my bug report I made an "aptitude dist-upgrade", is there > anything else I can check? As long as your mirror is current, and you did an "aptitude update" beforehand, an "aptitude upgrade" (or dist-upgrade) would be all you need to do, to have an up-to-date system. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#344045: cyrus21-common: non \n terminated lines at end of mail will be lost invoking "mail -s xyz [EMAIL PROTECTED]"
> I did not track the problem down but in the /var/spool/cyrus/ mailbox > the missing lines are not present. To reproduce the problem call: > > echo"This works" | mail -s "Test with newline"[EMAIL PROTECTED] > echo -n "This is lost" | mail -s "Test without newline" [EMAIL PROTECTED] The bug is something more insiduous. I don't think LMTP can even allow such a thing to happen, but I will need to re-read the LMTP RFC. Please send me a full protocol dump of the LMTP transaction between cyrus and your MTA while trying to deliver the "This is lost" email. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#344401: firefox: Printing support (CUPS) completely hosed
Package: firefox Version: 1.5.dfsg-2 Severity: important Firefox is one step ahead on the road of getting printing completely wrong. Now, it pops up a dialog which supposedly should get the printer's profile from CUPS, but screws that up. Royally. And I cannot even fix this dumbass software by telling it to call xpp instead of lpr (xpp does things right). The result of the "new printer support" is that NONE of the printer's capabilities are available since firefox screws that up, BUT now firefox refuses to print at all just because my printer has a4 paper and I cannot get even the fucking postscript/generic driver (which should support ALL paper sizes, damn it!) to work. [EMAIL PROTECTED] PoS software thinks that even postscript/generic must support only letter-sized paper! And the Debian paperconfig default in this machine is a4 just to add insult to the injury. I am not sure if you guys are aware, but letter size is NOT a good way to try to print on a4 paper (it causes information loss), which is used in most of the world. If firefox is going to pretend it knows about printing, it must get at least THAT much right. Please remove all "intelligent printing" crap from firefox until it is ready for use. Let us use xpp or kprint or something else that actually works for now. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (990, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.14.3-debian4+bluesmoke+atapassthru+lm85 Locale: LANG=pt_BR.ISO-8859-1, LC_CTYPE=pt_BR.ISO-8859-1 (charmap=ISO-8859-1) Versions of packages firefox depends on: ii debianutils 2.15.2 Miscellaneous utilities specific t ii fontconfig 2.3.2-1.1 generic font configuration library ii libatk1.0-0 1.10.3-1The ATK accessibility toolkit ii libc62.3.5-9 GNU C Library: Shared libraries an ii libcairo21.0.2-3 The Cairo 2D vector graphics libra ii libfontconfig1 2.3.2-1.1 generic font configuration library ii libfreetype6 2.1.10-1FreeType 2 font engine, shared lib ii libgcc1 1:4.0.2-5 GCC support library ii libglib2.0-0 2.8.4-2 The GLib library of C routines ii libgtk2.0-0 2.8.9-2 The GTK+ graphical user interface ii libidl0 0.8.5-1 library for parsing CORBA IDL file ii libjpeg626b-11 The Independent JPEG Group's JPEG ii libpango1.0-01.10.1-2Layout and rendering of internatio ii libpng12-0 1.2.8rel-5 PNG library - runtime ii libstdc++6 4.0.2-5 The GNU Standard C++ Library v3 ii libx11-6 6.8.2.dfsg.1-11 X Window System protocol client li ii libxcursor1 1.1.3-1 X cursor management library ii libxext6 6.8.2.dfsg.1-11 X Window System miscellaneous exte ii libxft2 2.1.7-1 FreeType-based font drawing librar ii libxi6 6.8.2.dfsg.1-11 X Window System Input extension li ii libxinerama1 6.8.2.dfsg.1-11 X Window System multi-head display ii libxp6 6.8.2.dfsg.1-11 X Window System printing extension ii libxrandr2 6.8.2.dfsg.1-11 X Window System Resize, Rotate and ii libxrender1 1:0.9.0-2 X Rendering Extension client libra ii libxt6 6.8.2.dfsg.1-11 X Toolkit Intrinsics ii psmisc 21.8-1 Utilities that use the proc filesy ii zlib1g 1:1.2.3-9 compression library - runtime firefox recommends no packages. -- no debconf information -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#344406: firefox: Firefox should never suggest an user to "restart his system" under Unix!
Package: firefox Version: 1.5.dfsg-2 Severity: minor After a crash, trying to re-run firefox causes an extremely aggravating dialog to show up which suggests that one has to *restart* his system to get rid of the broken-but-still-running firefox. This is *nix, not Windows. Get rid of that dialog and tell people to kill the firefox process instead. Heck, even in non-ancient microsoft windows that would work too. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (990, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.14.3-debian4+bluesmoke+atapassthru+lm85 Locale: LANG=pt_BR.ISO-8859-1, LC_CTYPE=pt_BR.ISO-8859-1 (charmap=ISO-8859-1) Versions of packages firefox depends on: ii debianutils 2.15.2 Miscellaneous utilities specific t ii fontconfig 2.3.2-1.1 generic font configuration library ii libatk1.0-0 1.10.3-1The ATK accessibility toolkit ii libc62.3.5-9 GNU C Library: Shared libraries an ii libcairo21.0.2-3 The Cairo 2D vector graphics libra ii libfontconfig1 2.3.2-1.1 generic font configuration library ii libfreetype6 2.1.10-1FreeType 2 font engine, shared lib ii libgcc1 1:4.0.2-5 GCC support library ii libglib2.0-0 2.8.4-2 The GLib library of C routines ii libgtk2.0-0 2.8.9-2 The GTK+ graphical user interface ii libidl0 0.8.5-1 library for parsing CORBA IDL file ii libjpeg626b-11 The Independent JPEG Group's JPEG ii libpango1.0-01.10.1-2Layout and rendering of internatio ii libpng12-0 1.2.8rel-5 PNG library - runtime ii libstdc++6 4.0.2-5 The GNU Standard C++ Library v3 ii libx11-6 6.8.2.dfsg.1-11 X Window System protocol client li ii libxcursor1 1.1.3-1 X cursor management library ii libxext6 6.8.2.dfsg.1-11 X Window System miscellaneous exte ii libxft2 2.1.7-1 FreeType-based font drawing librar ii libxi6 6.8.2.dfsg.1-11 X Window System Input extension li ii libxinerama1 6.8.2.dfsg.1-11 X Window System multi-head display ii libxp6 6.8.2.dfsg.1-11 X Window System printing extension ii libxrandr2 6.8.2.dfsg.1-11 X Window System Resize, Rotate and ii libxrender1 1:0.9.0-2 X Rendering Extension client libra ii libxt6 6.8.2.dfsg.1-11 X Toolkit Intrinsics ii psmisc 21.8-1 Utilities that use the proc filesy ii zlib1g 1:1.2.3-9 compression library - runtime firefox recommends no packages. -- no debconf information -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#338028: jadetex: breaks tetex upgrade
On Thu, 22 Dec 2005, Frank Küster wrote: > These are all now ancient versions. Is the bug still reproducible, or > at do you have still the temporary file that the postinst script asked > you to include in the bugreport? It's called /tmp/jadetex.postinst.* Postinst didn't ask anything, and I have been through at least five reboots since then (and /tmp is tmpfs here, you figure it out :-) ). How should I go about reproducing this, now? I don't think there is a way for me to give you more information on this bug. You can tag it unreproducible and close it if you want, if it is still happening, someone will reopen it. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh
Bug#344401: firefox: Printing support (CUPS) completely hosed
severity 344401 grave retitle 344401 firefox: all printing support broken thanks It gets better and better. I tried various combinations, and here's what I found: 1. xprint usually lets one change paper size and still works, but if you try to print to file, you're likely to get something like this: *** glibc detected *** double free or corruption (fasttop): 0x411f9838 *** and firefox obviously crashes on that. 2. the CUPS queues either don't work (because of the paper size braindamage, sometimes even when paper size is left at the default), or they print to file just fine. They didn't crash firefox, unlike xprint. And the CUPS queues sometimes ignore the print command, and sometimes respect it. Often the command is reset to the default (!) after it works *once*. This is higly worrysome, there are obviously dangling pointers or worse in this mess, I cannot reproduce *anything* reliably, it is like hunting ghosts. I am bumping this bug to grave, this crap cannot reach testing. Feel free to downgrade if, for some reason or another it works for most users. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#338028: jadetex: breaks tetex upgrade
Package: jadetex Version: 3.13-6 Severity: important Jadetex breaks completely any upgrades from pre 3.0 tetex to 3.0 tetex. Purging it and reinstalling it later after tetex was upgraded works. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (990, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.13.4-debian1+libata+bluesmoke+imq+lm85 Locale: LANG=pt_BR.ISO-8859-1, LC_CTYPE=pt_BR.ISO-8859-1 (charmap=ISO-8859-1) Versions of packages jadetex depends on: ii debianutils 2.15.1 Miscellaneous utilities specific t ii tetex-bin 3.0-10.1 The teTeX binary files ii tetex-extra 3.0-10 Additional library files of teTeX Versions of packages jadetex recommends: ii jade 1.2.1-45 James Clark's DSSSL Engine Versions of packages tetex-base depends on: ii dpkg 1.13.11.0.1 package maintenance system for Deb ii tex-common 0.9 Common infrastructure for using an ii ucf 2.003 Update Configuration File: preserv Versions of packages tetex-bin depends on: ii debconf [debconf-2.0]1.4.58 Debian configuration management sy ii debianutils 2.15.1 Miscellaneous utilities specific t ii dpkg 1.13.11.0.1 package maintenance system for Deb ii ed 0.2-20 The classic unix line editor ii libc62.3.5-7 GNU C Library: Shared libraries an ii libgcc1 1:4.0.2-3 GCC support library ii libice6 6.8.2.dfsg.1-10 Inter-Client Exchange library ii libkpathsea4 3.0-10.1path search library for teTeX (run ii libpaper11.1.14-3Library for handling paper charact ii libpng12-0 1.2.8rel-5 PNG library - runtime ii libsm6 6.8.2.dfsg.1-10 X Window System Session Management ii libstdc++6 4.0.2-3 The GNU Standard C++ Library v3 ii libt1-5 5.1.0-2 Type 1 font rasterizer library - r ii libx11-6 6.8.2.dfsg.1-10 X Window System protocol client li ii libxaw8 6.8.2.dfsg.1-10 X Athena widget set library ii libxext6 6.8.2.dfsg.1-10 X Window System miscellaneous exte ii libxmu6 6.8.2.dfsg.1-10 X Window System miscellaneous util ii libxp6 6.8.2.dfsg.1-10 X Window System printing extension ii libxpm4 6.8.2.dfsg.1-10 X pixmap library ii libxt6 6.8.2.dfsg.1-10 X Toolkit Intrinsics ii mime-support 3.35-1 MIME files 'mime.types' & 'mailcap ii perl 5.8.7-7 Larry Wall's Practical Extraction ii sed 4.1.4-4 The GNU sed stream editor ii tetex-base 3.0-10 Basic library files of teTeX ii ucf 2.003 Update Configuration File: preserv ii xlibs6.8.2.dfsg.1-10 X Window System client libraries m ii zlib1g 1:1.2.3-6 compression library - runtime Versions of packages tetex-extra depends on: ii dpkg 1.13.11.0.1 package maintenance system for Deb ii tetex-base 3.0-10 Basic library files of teTeX ii tetex-bin3.0-10.1The teTeX binary files ii ucf 2.003 Update Configuration File: preserv -- debconf information excluded -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#343645: Processed: Re: [Pkg-sysvinit-devel] Processed: Re: Bug#343645: e2fsprogs: Superblock last mount time is in the future, fix it ? (Y)
tag 343645 wontfix thanks Please, no screwing with this glibc and util-linux issue. It should be fixed by util-linux (patch 50% done by yours thruly), and glibc. It is wontfix for initscripts. It is almost-pending for util-linux. I have no idea if, after util-linux is fixed, glibc will do the right thing and make sure /etc/localtime is always valid (bugs will need to be reassigned to glibc, I don't think they have been notified yet. /etc/localtime IS glibc's domain, as timezones and locales are their domain. It should be kept up-to-date by tzconfig. It should be a copy of the zonefile instead of a symlink. d-i probably has to be fixed to severely discourage UTC=no and to also do copies, but that's something else. I am against futher breakage on this issue by trying to work around it in initscripts. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#316468: [Pkg-sysvinit-devel] Bug#316468: Implement, but assist backporters?
On Thu, 05 Jan 2006, Thomas Hood wrote: > Petter Reinholdtsen replied: > > I would prefer it if the current sysvinit package did not have any > > dependenices missing in debian/stable, to make it easier to backport > > the package to sarge. Please wait with this change until etch is > > released. That won't happen, sorry. Etch will need some stuff that simply doesn't exists in sarge. > Is "-delete" is no slower than the current "-print0 | xargs rm" code? > I'll assume so. It might be a bit slower (extra fork, pipe setup), but it won't make much of a difference, either way. I doubt it is in the easily measurable land. > How about we make this change but encapsulate the find call in a function > in order to assist the sarge backporters? The sysvinit packages already > require modification for use in sarge. IMHO It makes no sense to do such a change and place it in a function call, the function call is probably slower than the original code to begin with :) -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#343645: Processed: Re: [Pkg-sysvinit-devel] Processed: Re: Bug#343645: e2fsprogs: Superblock last mount time is in the future, fix it ? (Y)
Hi LaMont! On Thu, 05 Jan 2006, LaMont Jones wrote: > On Thu, Jan 05, 2006 at 08:55:26AM -0200, Henrique de Moraes Holschuh wrote: > > It should be fixed by util-linux (patch 50% done by yours thruly), and > > glibc. It is wontfix for initscripts. It is almost-pending for util-linux. > > I have no idea if, after util-linux is fixed, glibc will do the right thing > > and make sure /etc/localtime is always valid (bugs will need to be > > reassigned to glibc, I don't think they have been notified yet. > > What's the status of the patch, and can I get a copy of it? I was trying to write one that did all in util-linux, but during that time it become apparent that the fix needs to involve glibc and initscripts too to be effective during DST. I will send you a simple patch ASAP that just fixes things but requires the user to manually edit the hwclockfirst.sh file and add TZ= something there, and fix that manually for DST. The full solution will (if approved by initscripts and glibc) have a working /etc/localtime by the time hwclockfirst is run, so that TZ= will be unneeded, and it will all work even during DST. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#342887: [PATCH] move hwclock to S05 and S46. Fix initscript problems
tag 342887 + patch
thanks
See attached patch. It was not completely tested yet, but it seems sane,
and it survived some light testing.
Note that hwclock.sh runs much later than I'd like it to, but we need to
make sure /usr is mounted, and that means it must run after NFS has had its
change of mounting /usr.
USER'S GUIDE:
1. Install util-linux with the patch applied
2. Edit hwclockfirst.sh and set TZ to your timezone
3. Change that TZ according to daylight savings time, manually.
The TZ hack will be uncessary eventually, and util-linux will be fixed
accordingly to not mention TZ anymore in the initscript (dpkg will warn you
that the initscript conffile has changed). When that happens, please update
the initscript.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
diff -ruN util-linux-2.12r/debian/hwclock.sh
util-linux-2.12r-fix2/debian/hwclock.sh
--- util-linux-2.12r/debian/hwclock.sh 2006-01-05 09:17:51.677942513 -0200
+++ util-linux-2.12r-fix2/debian/hwclock.sh 2006-01-05 20:41:58.799569064
-0200
@@ -11,6 +11,12 @@
# during startup/shutdown.
# - Added comments to alert users of hwclock issues
# and discourage tampering without proper doc reading.
+# 2006-01-05 Henrique M. Holschuh <[EMAIL PROTECTED]>
+# - Improve message handling
+# - Fix FIRST=yes/no invocations of hwclock --hctosys,
+# and other minor things
+# - Make very sure /etc/adjtime is not used on FIRST=yes
+# - Follow symlinks in /etc/adjtime (no reason not to)
# WARNING: Please read /usr/share/doc/util-linux/README.Debian.hwclock
# before changing this file. You risk serious clock
@@ -22,8 +28,15 @@
# as machine hardware clock type for Alphas.
HWCLOCKPARS=
+# Set this to your timezone if your clock is not in UTC, this hack will go
+# away soon. Make sure to use the simplest form for TZ, see tzset(3) for
+# details
+# e.g. TZ=ABC+03:00 for GMT-3:00, TZ=AAA-05:30 for UTC+05:30
+#
+#TZ=
+
[ ! -x /sbin/hwclock ] && exit 0
-. /etc/default/rcS
+[ -r /etc/default/rcS ] && . /etc/default/rcS
. /lib/lsb/init-functions
verbose_log_action_msg() { [ "$VERBOSE" = no ] || log_action_msg "$@"; }
@@ -34,7 +47,9 @@
UTC=""
if [ "X$FIRST" = "Xyes" ] && [ ! -r /etc/localtime ]; then
if [ -z "$TZ" ]; then
- log_action_msg "System clock was not updated at this
time"
+ log_warning_msg "Hardware clock misconfiguration
detected!"
+ log_warning_msg "Hardware clock not in UTC, TZ unset
and /etc/localtime unreadable"
+ log_failure_msg "System clock was not updated at this
time"
exit 1
fi
fi
@@ -42,55 +57,65 @@
yes)GMT="--utc"
UTC="--utc"
;;
- *) log_action_msg "Unknown UTC setting: \"$UTC\""; exit 1 ;;
+ *) log_warning_msg "Hardware clock misconfiguration detected!"
+ log_failure_msg "Unknown UTC setting: \"$UTC\""; exit 1 ;;
esac
case "$BADYEAR" in
no|"") BADYEAR="" ;;
yes)BADYEAR="--badyear" ;;
- *) log_action_msg "unknown BADYEAR setting: \"$BADYEAR\""; exit 1
;;
+ *) log_warning_msg "Hardware clock misconfiguration detected!"
+ log_failure_msg "unknown BADYEAR setting: \"$BADYEAR\""; exit 1
;;
esac
case "$1" in
start)
- if [ ! -f /etc/adjtime ] && [ ! -e /etc/adjtime ]; then
+ if [ "$FIRST" != yes ] && [ ! -e /etc/adjtime ]; then
+ # (will follow symlinks)
echo "0.0 0 0.0" > /etc/adjtime
fi
- if [ "$FIRST" != yes ]; then
- # Uncomment the hwclock --adjust line below if you want
- # hwclock to try to correct systematic drift errors in the
- # Hardware Clock.
- #
- # WARNING: If you uncomment this option, you must either
make
- # sure *nothing* changes the Hardware Clock other than
- # hwclock --systohc, or you must delete /etc/adjtime
- # every time someone else modifies the Hardware Clock.
- #
- # Common "vilains" are: ntp, MS Windows, the BIOS Setup
- # program.
- #
- # WARNING: You must remember to invalidate (delete)
- # /etc/adjtime if you ever need to set the system clock
- # to a very different value and hwclock --adjust is being
- # used.
- #
- # Please
Bug#346148: [Pkg-sysvinit-devel] Bug#346148: checkroot.sh: does not properly handle fsck exit states
On Fri, 06 Jan 2006, Wouter Verhelst wrote: > I just noticed that my laptop, at bootup, started an fsck for the root > filesystem, claiming that it was a filesystem with errors. When it was > about 20% done, it exited, and told me to rerun it manually. I expected > a prompt for my root password and to be put in single-user mode, but > this did not happen; instead, my system did a normal boot. This means fsck returned error codes 2 or 3. If fsck needs to be re-run manually, it should have something else (bit 1 should not be set, bit 2 should be set, and I am not sure about bit 3. Other bits should be unset). What is your root filesystem? -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#343645: Processed: Re: [Pkg-sysvinit-devel] Processed: Re: Bug#343645: e2fsprogs: Superblock last mount time is in the future, fix it ? (Y)
On Fri, 06 Jan 2006, Thomas Dickey wrote: > On Thu, Jan 05, 2006 at 04:50:24PM +0100, Henrique de Moraes Holschuh wrote: > > I was trying to write one that did all in util-linux, but during that time > > it become apparent that the fix needs to involve glibc and initscripts too > > to be effective during DST. > > The patch was too simplistic to be of use anyway. Granted that it was > "tested lightly"... Simplistic as in? What did it fail to do? The whole fix involves a lot of crap that won't be done by util-linux, but rather initscripts. The patch just fixes util-linux back to what it should be doing. > I don't see any discussion on this thread that points out that modifying > the hardware clock from another system can make the Debian system unbootable > (until one waits for the future to arrive ;-). And you won't :-P We don't protect people from hanging themselves on purpose. If you want to discuss that the test is completely stupid, or that fsck is not repairing it correctly or in the desired way, you have to talk to the e2fsck maintainer. OTOH, a misshandled clock (as in we say we support it in local time but really don't) is a bug no matter how we look at it, so even if e2fsck stops caring about the system clock, we would still need to do something about this issue at early boot anyway. Or drop the non-UTC support for the RTC. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#346218: pget: must close connections that already transmitted their share
Package: lftp Version: 3.4.0-1 Severity: important At least in ftp mode, pget is not closing the connections that have already transmitted their share. This leads to absurd waste of bandwitdh when dealing with really huge files (like CD or DVD iso images) if every partition does not transfer at the same rate. It really needs to partition the file correctly, and when a partition is done transfering, close it. If a connection dealing with a partition times out, restart THAT connection (I think it already does this), etc. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (990, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.14.5-debian6+bluesmoke+atapassthru+lm85 Locale: LANG=pt_BR.ISO-8859-1, LC_CTYPE=pt_BR.ISO-8859-1 (charmap=ISO-8859-1) Versions of packages lftp depends on: ii libc6 2.3.5-11 GNU C Library: Shared libraries an ii libexpat1 1.95.8-3 XML parsing C library - runtime li ii libgcc1 1:4.0.2-5 GCC support library ii libgcrypt11 1.2.2-1LGPL Crypto library - runtime libr ii libgnutls11 1.0.16-14 GNU TLS library - runtime library ii libgpg-error0 1.1-4 library for common error values an ii libncurses5 5.5-1 Shared libraries for terminal hand ii libreadline5 5.1-5 GNU readline and history libraries ii libtasn1-20.2.17-1 Manage ASN.1 structures (runtime) ii netbase 4.24 Basic TCP/IP networking system ii zlib1g1:1.2.3-9 compression library - runtime lftp recommends no packages. -- no debconf information -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#346321: aptitude: offers upgrade to exp version (pri -10) instead of unst version (990)
Package: aptitude Version: 0.4.1-1 Severity: important I am tagging this as important because any bug that makes people install experimental packages unawares is quite problematic :) $ apt-cache policy libarts1c2a libarts1c2a: Installed: 1.4.3-3 Candidate: 1.5.0-3 Version table: 1.5.0-3 0 990 http://mirrors.kernel.org unstable/main Packages 990 http://ftp.fi.debian.org unstable/main Packages 1.5.0-2 0 -10 http://mirrors.kernel.org experimental/main Packages -10 http://ftp.fi.debian.org experimental/main Packages *** 1.4.3-3 0 100 /var/lib/dpkg/status However, aptitude does this: libarts1c2a recommends libarts1-akode --\ The following actions will resolve this dependency: -> Upgrade libarts1c2a [1.4.3-3 (now) -> 1.5.0-2 (experimental, experimental)] -> Keep libarts1c2a at version 1.4.3-3 (now) -> Remove libarts1c2a [1.4.3-3 (now)] -> Install libarts1-akode [4:3.5.0-2 (experimental, experimental)] -> Leave the dependency "libarts1c2a recommends libarts1-akode" unresolved. i.e it prefers to install the experimental version, even if it is priority -10. The correct solution is to install libarts1c2a 1.5.0-3, and leave the dependency unresolved. OR to hold everything. But installing anything that has a negative priority is a no-no. For reference, my /etc/apt/preferences is: Package: * Pin: release a=experimental Pin-Priority: -10 -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (990, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.14.5-debian6+bluesmoke+atapassthru+lm85 Locale: LANG=pt_BR.ISO-8859-1, LC_CTYPE=pt_BR.ISO-8859-1 (charmap=ISO-8859-1) Versions of packages aptitude depends on: ii apt [libapt-pkg-libc6.3-6-3.1 0.6.43 Advanced front-end for dpkg ii libc6 2.3.5-11 GNU C Library: Shared libraries an ii libgcc1 1:4.0.2-5 GCC support library ii libncursesw5 5.5-1 Shared libraries for terminal hand ii libsigc++-2.0-0c2a2.0.16-2 type-safe Signal Framework for C++ ii libstdc++64.0.2-5The GNU Standard C++ Library v3 Versions of packages aptitude recommends: ii aptitude-doc-en [aptitude-doc 0.4.1-1English manual for aptitude, a ter -- no debconf information -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#346329: [Pkg-sysvinit-devel] Bug#346329: swap on LVM
On Fri, 06 Jan 2006, Joel Johnson wrote: > However, I have my swap located on an LVM volume, and the dm_mod isn't So do I. > loaded until later (libdevmapper1.02) so attempting to activate the swap > is futile. The script should check if the fstab entry is /dev/mapper/* and The swap could be, e.g, in /dev//. Then we have the miriad of ways device mapper could be activated: lvm, evms, etc... and also dmbased RAID. Argh. I really don't know how useful trying to make those checks even more comprehensive will be. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh
Bug#346598: init script stop example should use --oknodo
On Sun, 08 Jan 2006, Matt Kraai wrote: > According to the LSB Core Specification 3.1, init scripts should > consider running stop on a service already stopped or not running > successful, but the example in policy does not behave this way because > it does not pass --oknodo to start-stop-daemon in the stop case. The > attached patch makes it do so. It must also use retry or some other way to make sure the daemon indeed stopped, and we should add a comment that you cannot use --exec if: 1. the daemon isn't an ELF executable (i.e. no #! stuff can use --exec) 2. the daemon could be running when its executable was replaced by a package upgrade. Or remove that error-inducing example completely and tell people to read /etc/init.d/skeleton (which is easier to fix than policy :-) ). -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#347264: Incorrect *Manufacturer string
On Mon, 09 Jan 2006, Pascal De Vuyst wrote: > hplip-ppds package incorrectly uses *Manufacturer: "HP (HPLIP)" inside PPDs. Yes, this is done on purpose because of the myriad of other sources of possibly non-compatible PPDs for HP printers managed by hpijs (i.e. HPLIP). Are we going to remove all HP PPDs from all other PPD-installing packages in Debian, including the crap that comes with cupsys by default, and the ones in foomatic* ? -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#347264: Incorrect *Manufacturer string
On Tue, 10 Jan 2006, Roger Leigh wrote: > An alternate approach, used by Foomatic and Gutenprint, is to put the > driver name after the model: > > zgrep '^\*NickName:' > /usr/share/cups/model/gutenprint/5.0/en/stp-escp2-c60.5.0.ppd.gz > *NickName: "EPSON Stylus C60 - CUPS+Gutenprint v5.0.0-rc2" I will do so, then. However, the other parts of the PPD spec for Debian will not be followed by hplip until all other issues are fixed, i.e. I will still ship the PPDs in a hplip/ subdir off the toplevel PPD directory for now, and that contains hpijs PPDs mixed with "pure" postscript PPDs. Is it desireable to forecefully case-normalize the PPD filenames? HP uses basically the "toss a coin" way of selecting which case they use on these things, and linuxprinting.org did not fix it upon acceptance of the PPDs. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#347527: [Pkg-Cyrus-imapd-Debian-devel] Bug#347527: please expand 45-kolab2-annotations patch
On Wed, 11 Jan 2006, Steffen Joeris wrote: > I want to send you all patches from Kolab which are provided, some of them are > really necessary for a cyrus to run with kolab (hope you agree). Please include a description with each patch of the functionality provided by that patch *and* all possible incompatibilities with upstream it could generate. Patch dependency information is also quite useful :P Depending on what comes of that, we can take the patches as is, or we'll ask you to make them runtime-controlled for each compartimentalized functionality (which would be a good way to get them accepted upstream too, I suppose). -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#347264: Incorrect *Manufacturer string
On Wed, 11 Jan 2006, Pascal De Vuyst wrote: > For the above reasons hplip-ppd should provide HPLIP PPDs and > foomatic-filters-ppds should not. HPLIP provides *HP* PPDs. This includes all hpijs ones, and all postscript ones. I am not about to deal with the mess of shipping a different set of PPDs than upstream (I can deal with shipping all, or shipping none). The reason for this is user confusion, which I am wary of increasing. > We should not remove all HP PPDs from packages providing PPDs since there > are other binary gs drivers (e.g. pcl3) for use with HP printers where PPDs > are provided by foomatic-filter-ppds. You'll have to verify if HPLIP is not providing those... If they are supported by HP, it probably does. > Roger Leigh has a good point here. > HPLIP PPDs already use the above Foomatic approach so that's no problem. Only in CVS, I didn't upload the packages not screwing up with the Manufacturer's field yet. > So if PPDs are named e.g. "HP-DeskJet_520-hpijs.ppd.gz" and are located in As I said, there are ppds for other drivers than hpijs, including pure postscript. > I think Debian should lead the way here by providing unified naming for PPDs > which opens possibilities for GUI tools that are currently not possible. > Perhaps a bug should be filed against foomatic-db to get this changed > upstream. It *will* have to be changed upstream if you want to change names. But only the case is weird in HP's case, and that I can deal with. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#347657: please add imapd.patch from kolab upstream
On Wed, 11 Jan 2006, Steffen Joeris wrote:
> -#if defined(HAVE_STDARG_H) || defined(_WINDOWS)
> +#if defined(HAVE_STDARG_H) || defined(__STDC__) || defined(_WINDOWS)
> +#ifdef __FreeBSD__
> +/* #define fdatasync(fd) fsync(fd) */
> +#define O_DSYNC 0
> +#endif
> +
Assorted fixes we can ignore in Debian.
> +#include
That one we want anyway.
> #-#ifdef HAVE_CONFIG_H
> #-#include
> #-#endif
> #+#include "../../../config.h"
We must fix this properly. Just "config.h" should have been enough, and
is *always* wrong :)
> +#ifdef ATVDOM /* allow '@' being a regular character in mboxname even when
> using virtual domains */
> + else if ((cp = strrchr(name, '@'))) {
> +#else
> if ((cp = strrchr(name, '@'))) {
> +#endif /* ATVDOM */
Not acceptable for regular cyrus.
> -static void db_err(const char *db_prfx, char *buffer)
> +static void db_err(const DB_ENV *dbenv, const char *db_prfx, const char
> *buffer)
> {
> syslog(LOG_WARNING, "DBERROR %s: %s", db_prfx, buffer);
> }
We should verify this one.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#347658: please include patch from kolab for Shell.pm
On Wed, 11 Jan 2006, Steffen Joeris wrote: > Enclosed there is a small patch for the Shell.pm file. > We also found it in the kolab-upstream. > There I can only see some additional thinks. > I think these are interesting for the mailboxes. > The mailboxes with kolab have an other look. It is acutally a proper fix for shell.pm, we should apply it anyway. It documents valid cyrus 2.2 (without kolab changes). -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#347659: please discuss patch for ldap authentification (Kolab)
On Wed, 11 Jan 2006, Steffen Joeris wrote:
> This is the ldap authentification patch for cyrus.
> As far as I know it enables the ldap authentification.
> Kolab uses ldap for all user information.
[...]
> -{ "virtdomains", "off", ENUM("off", "userid", "on") }
> +{ "virtdomains", "off", ENUM("off", "userid", "ldap", "on") }
THAT I didn't like at all. If it is an authz module, it should have been
plugged to the ptloader. Looks more like a hack to the vir. domain system.
If kolab touched that, the chances of we taking the patches have decreased
to close to zero. I do NOT want people doing such things that 2.3 will
NEVER support.
We might need a cyrus-kolab package that has the patches applied, and to
keep the rest of cyrus "pure"...
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#347660: please look at the wildcard-deactivating patches (Kolab)
On Wed, 11 Jan 2006, Steffen Joeris wrote:
> This is necessary because Kolab uses the whole email adress for the
> mailbox and there are for example '%' 's :)
I will not take this patch. It would be asking for misterious breakages.
Also, I am not sure it is legal IMAP either, and if it is not legal IMAP per
the RFCs, I'd push for its removal even if it were accepted...
> We know that it will be very difficult or maybe impossible to integrate it
> into the official cyrus package, but i think we will discuss it
Indeed. Why not fix Kolab so that it stops doing such weird things? It
should be doable.
> + #ifdef notdef
> /* verify that the mailbox doesn't have a wildcard in it */
> for (p = oldmailboxname; !r && *p; p++) {
> if (*p == '*' || *p == '%') r = IMAP_MAILBOX_BADNAME;
> }
> + #endif
We *really* don't want to mess with this.
> + * original definition
> #define GOODCHARS " +,-.0123456789:[EMAIL PROTECTED]"
> + */
> +
> +#define GOODCHARS " #$%'()*+,-.0123456789:;<=>[EMAIL PROTECTED]|}~"
> +
Some of those might be needed for other stuff... as a rule, cyrus avoids
chars that could cause hell on scripts or the imap protocol, and reserves
some itself. So no ^ (unixhiersep), no wildcards, no {, no }, etc.
Exactly what kind of crazy thing does kolab do with mailboxes that it needs
the above changes?
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#347659: [Pkg-Cyrus-imapd-Debian-devel] Bug#347659: please discuss patch for ldap authentification (Kolab)
On Thu, 12 Jan 2006, Philip Thiem wrote: > Cyrus 2.2 Supporta Virtual domains and SASL has or at least can be properly > patched for LDAP authentication. It always seemed to me like SASL was the There are three mechanisms that much act together to properly have accounts in LDAP: 1. LDAP auth (SASL with auxprop+LDAP patch -- not in Debian, we need to update to latest sasl + the patches; saslauthd works, but it is on its way out) 2. Cyrus ptloader autorization module for LDAP (IMAP ACL support) This is how upstream wants it done, and there is a damn good ptloader module for LDAP, we would do well to support that one in Debian, but it is useless if we don't fix the SASL packages. 3. Cyrus mailboxes database, which is *NOT* in LDAP -- usually people work around this one using the autocreate patches, and scripts to remove outdated mailboxes. I am completely against messing with (3) in any way that will not work in 2.3 in the replicated Murder with Virtual Domains scenario, and I am also completely against anything that does not do (2) correctly. So, I am completely against the ldap mess kolab did on the virtual domain code: we don't want to support non-kolab users using that. Now AFAIK (so far), kolab needs to filddle with a lot of stuff because they did something that *everyone* who ever tried to do it that way before had been told to Not Do It by Cyrus upstream: they got information that is out of band (the domain) and placed it in-band ([EMAIL PROTECTED] mailboxes). So please excuse me if I am dead set against adding such stuff to regular Cyrus, it is asking for trouble. OTOH, I don't mind adding a cyrus-kolab package with the patches that break cyrus so that kolab can work applied (I will talk about this on the ML thread about the kolab+cyrus team collaboration). > * Patching SASL if the upstream stream isn't ready (i'm using a patched > package > myself). We should have a proper LDAP-worthy SASL in Debian, but nobody stepped up to take care of the monster of a package that is SASL, and I simply do NOT have the time right now. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#342887: util-linux: please copy /etc/localtime
On Thu, 12 Jan 2006, Martin Stolle wrote: > The only valid solution is to copy the appropriate timezone info to > /etc/localtime. Rerunning tzconfig or recopying this file when That's what will be done, when we prove it to the glibc people that it is save (i.e. please do so on your system, and report back that NOTHING breaks...). I have that running on two systems already, no problems so far. I believe we have to test the KDE and GNOME timezone setting stuff too, but those should be changed in Debian to use tzconfig and /etc/timezone anyway, so if they break, we just fix them and go ahead. > /usr/share/zoneinfo is updated is a perfectly fine solution and by far > the least hackiest solution. Yes. TZ=something is just a workaround. BTW, RedHat does what we are trying to do, so I am pretty sure we won't have much problems, just some Debian scripts (in the glibc package) to fix. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#347659: [Pkg-Cyrus-imapd-Debian-devel] Bug#347659: please discuss patch for ldap authentification (Kolab)
On Thu, 12 Jan 2006, Sven Mueller wrote:
> >>-{ "virtdomains", "off", ENUM("off", "userid", "on") }
> >>+{ "virtdomains", "off", ENUM("off", "userid", "ldap", "on") }
> >
> > THAT I didn't like at all. If it is an authz module, it should have been
> > plugged to the ptloader. Looks more like a hack to the vir. domain system.
>
> >From what I saw in the patch, it uses the LDAP userid (uid field) to
> look up the primary email address of the user. It then returns that
> email address canonified for authentication (i.e. the user logs in with
> his uid, but mail is stored and passwords looked up in sasl according to
> his primary email address.
That ain't how it works with Cyrus. The user logs in with his *mailbox*,
which is [EMAIL PROTECTED] To change that, you add a canonization plugin that
gets whatever was sent to Cyrus as the mailbox, and changes it to the real
user and domain. But AFAIK, canonization is *global*.
Which means you DELIVER through LMTP to the pre-canonized account, do IMAP
logins and POP3 logins to the pre-canonized account... Depending on how
early SASL is called, SASL may have do deal with the pre-canonized account
as well, I didn't check.
> Besides thinking that the patch is somewhat incomplete (it doesn't
> handle alternate addresses at all AFAICT), I don't see how it could harm
> normal cyrus operation.
I am afraid it might cause subtle bugs, but that's not the worst problem
IMHO. It is that we have no reason to believe it will be easily
forward-portable to 2.3, and 2.3 requires one to be very careful as the
entire murder code has been unified with the normal daemons, and there is
the whole replication system to take into account.
> Well, I don't really see how to map LDAP uids (which are normally also
> login names for servers/workstations) to email addresses (on which cyrus
> operates. The only alternative would be to not use vdomains in cyrus and
> use the MTA to deliver mails to any of the mail addresses of a user to
> .
IF you are logging in (imap, pop) using [EMAIL PROTECTED], or using different
listening interfaces to automatically detect vdomain, in which case you
_can_ just use userid instead:
Email, you deliver to [EMAIL PROTECTED] using LMTP. This is done by teaching
the MTA to ask LDAP about the accounts, and where to deliver mail for an
account; that's how everyone doing email delivery of any sort using LDAP
have been doing things for years.
Cyrus logins are [EMAIL PROTECTED], mapped to SASL as userid=userid,
REALM=vdomain, and used internally by Cyrus as user userid, in domain
vdomain. *SASL* has to map that back to LDAP dn to check the credentials,
usually doing some string substitution to get a dn. If you need to do it
using LDAP *searches*, you have to improve the SASL LDAP auxprop module --
actually, I think the latest one can do it already, it has been a LONG time
since I mucked with cyrus+ldap.
After the authentication (SASL), Cyrus needs to ask stuff on LDAP only to
expand group ACLs (during authorization). That is supposed to be done
through a ptloader LDAP plugin, and definately not a new vdomain scheme.
Heck, tweaking cyrus so that it can canonize each type of service login
differently, and to use dynamically selected canonization schemes would
have been a nice and clean way to do what kolab seems to need done (if I
understood things correctly).
I hope this makes a bit more clear my misgivings about including the patch.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#347813: amavisd-new: amavis not checking for spam or viruses after upgrade
On Thu, 12 Jan 2006, Christopher Wagner wrote:
> After upgrading to the latest Etch version of amavisd-new yesterday, I
> reconfigured amavis from scratch (doing away with my old amavis.conf). I made
Please send me a tarball with the entire contents of /etc/amavis. Please
overwite any sensitive information with XXX.
> Jan 12 12:12:52 toober /usr/sbin/amavisd-new[21815]: ANTI-VIRUS codeNOT
> loaded
> Jan 12 12:12:52 toober /usr/sbin/amavisd-new[21815]: ANTI-SPAM codeNOT
> loaded
This tipically happens if for some reason or another, the config is subtly
wrong, especially since the config files in /usr will DISABLE the anti-virus
and anti-spam code, so something weird happening in later config files will
probably cause the checks to remain disabled.
The config files are processed one-by-one, so it is very likely that the
problem is in 15-content-filter-mode (if you did not change the variables
controlling av and sa in another file). Just in case, I am attaching a
known-valid 15-content-filter-mode file with *enables* AV and SPAM checks.
You could try overwriting the one you're using with that one (or using diff)
to see if some sort of small typo escaped your checks.
Make sure all the config files return "1".
Make sure there are no open-ended ", ', {, (, and so on.
You can run amavis in "debug" mode through the perl debugger, to see if it
is processing the config files as expected.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
use strict;
# You can modify this file to re-enable SPAM checking through spamassassin
# and to re-enable antivirus checking.
#
# Default antivirus checking mode
# Uncomment the two lines below to enable it back
#
@bypass_virus_checks_maps = (
\%bypass_virus_checks, [EMAIL PROTECTED], \$bypass_virus_checks_re);
#
# Default SPAM checking mode
# Uncomment the two lines below to enable it back
#
@bypass_spam_checks_maps = (
\%bypass_spam_checks, [EMAIL PROTECTED], \$bypass_spam_checks_re);
1; # insure a defined return
Bug#283027: status update on this bug.
I can't recall why I tagged this bug pending but never closed it. Chances are it has been fixed already, probably by 1:2.3.3-1 or maybe even earlier. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#344045: [Pkg-Cyrus-imapd-Debian-devel] Bug#344045: cyrus21-common: non \n terminated lines at end of mail will be lost invoking "mail -s xyz [EMAIL PROTECTED]"
On Fri, 23 Dec 2005, Leif Jakob wrote: > Could you reproduce the problem? LMTP session protocol dump, please. The only thing I can think of is that sendmail is closing the door on Cyrus' face, and some bug is causing it to drop the last EOL. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#335657: amavisd-new: Amavis reports email format error on correctly formed subject field
tag 335657 moreinfo
thanks
On Tue, 25 Oct 2005, Thue Janus Kristensen wrote:
> Version: 20030616p10-5
>
> Subject: =?ISO-8859-1?B?MTIzNDU2Nzg5IDEyMzQ1Njc4OSAxMjM0NQ==?=
> =?ISO-8859-1?B?Njc4OSAxMjM0NTY3ODkgMTIzNDU2Nzg5IA==?=
> =?ISO-8859-1?B?MTIzNDU2Nzg5IDEyMzQ1Njc4OSA=?=
>
> ("123456789 123456789 123456789 123456789 123456789 123456789 123456789 "
> encoded in base64). However, amavis appends the error message
>
> X-Amavis-Alert: BAD HEADER Improper use of control character (char 0D hex) in
> message header 'Subject'
> Subject: ...5IDEyMzQ1Njc4OSAxMjM0NQ==?=\r\n =?ISO-8859-1?... ^
I cannot reproduce this here with 2.3.3, even if the code *looks* like it
should be buggy. Can you confirm you still have this problem with
amavisd-new 2.3.3 ?
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#342887: hwclock must run after /usr
Let's go over the way things work, and see how we can fix them back so that they work correctly. Please bear with me while I go over the entire problem, and feel free to correct any mistakes I make. Reading manpage tzset(3) before you read any further is advised. AFAIK There are ONLY TWO valid modes of early boot operation: 1. UTC (hardware clock in UTC, UTC=yes) 2. Non-UTC with TZ set or /etc/localtime in the root filesystem (hardware clock in local time, UTC=no, system knows timezone) Anything else is an invalid system configuration, and must be fixed. By invalid configuration, I mean one where the system UTC clock (which has nothing to do with the hardware clock) is NOT set to the correct UTC time. I would bet it is common to find people with invalid configurations, since a separate /usr is common, TZ is not mentioned at the top of /etc/init.d/hwclockfirst.sh, and there isn't a way for d-i to set that up either. Also, do refer to tzset(3), we would need to use the simplest TZ form, since it must work without data that is in /usr/share. It is good to remember that timezones can be changed at will, by any user (just set TZ) at any time, and also that TZ overrides /etc/localtime so we don't want to define it system-wide. What that means? Below are the two valid configurations and what actions hwclock initscripts should do (doing anything else is probably a big bad bug ;-) ), and the most common invalid configuration. (*) are the points where hwclock scripts must take some action. UTC mode: 0. Kernel might boot with correct time (if it reads the RTC by itself) * 1. hwclockfirst sets kernel time to the correct UTC time 2. system runs with a local timezone (if /etc/localtime is readable) or with UTC as a timezone 3. something mounts /usr 4. System runs with the proper timezone Early boot runs fine, system thinks timezone is UTC if /usr is not mounted, or reads timezone from /etc/localtime if it is mounted. No big deal, as apps use UTC for persitent timekeeping. e2fsck should not be going bonkers in this case. hwclock should try to set the system clock only on early boot. Non-UTC valid config mode, with /usr as a separate partition 0. kernel boots with wrong time (even if it reads the RTC by itself) * 1. TZ is set so hwclockfirst sets the kernel time to the correct UTC time 2. system runs with a local timezone (if /etc/localtime is readable) or with UTC as a timezone 3. Something mounts /usr 4. System runs with the proper timezone Again, hwclock should try to set the system clock only on early boot. Notice that TZ must be set only for the hwclockfirst initscript, we don't want it in the global environment. I'd suggest removing UTC from /etc/default/rcS, and adding TZ and UCT to a new file, /etc/default/timezone. Non-UTC *valid config* mode, /usr inside the root partition 0. kernel boots with wrong time (even if it reads the RTC by itself) 1. /etc/localtime is readable, so everything else runs just like it does in UTC mode. With a valid configuration, hwclockfirst does all the job that doesn't need a timezone and must run VERY early. hwclock does the jobs that require a timezone (which is actually just displaying the time in the local timezone so that the users have a better clue of what's happening, and we don't increase d-user traffic with RTC problems again). This means hwclock.sh *must* run after /usr is mounted. That's the only time we *know* the timezone will be correct, no matter which configuration is used (including invalid ones -- hwclock after /usr is a *debugging aid*). What would happen in the typical broken configuration? Non-UTC, /usr separate, no TZ defined anywhere: 0. kernel boots with wrong time (even if it reads the RTC by itself) * 1. hwclock sets the kernel UTC time to the local time in the RTC, and thus the system clock could be wrong by several hours in either direction. 2. System runs with wrong time. e2fsck can croak, etc. 3. something mounts /usr * 4. hwclock runs, and tells the user a completely ludricous time (timezone applied twice :P) <=== We could fix the mess here, so if the user doesn't hit a bug (e.g. e2fsck) before, he would not suffer much from his broken config. hwclock MUST be run after /usr is mounted to be able to help fix the mess (well work around it, realy). Now, there's a bug in that hwclockfirst should bitch to all winds if it detects an invalid config, currently it just outputs a meek "System clock was not updated at this time" and bangs out with exit status 1. There is also a bug in that hwclockfirst must be one of the VERY first things to be run, AND that hwclock must be run AFTER /etc/localtime is working well in a typical Debian system. I.e. *after* /usr is mounted. And there is a third bug which is the lack of easy TZ handling and lack of documentation. The funny thing is that I could swear I added TZ and some documen
Bug#342887: hwclock must run after /usr
Please remember this is bug is being dealt with with util-linux perspective when reading my answers... On Sun, 01 Jan 2006, Nate Eldredge wrote: > Right. Which is kind of painful in the daylight savings case. I can't Correct. It is *flat out impossible* to fix this issue completely (as in do everything transparently) in util-linux. Either one must have one's clock on UTC as any non-braindamaged system does, OR one's /etc/localtime better be in the root partition. Otherwise, one has to keep daylight savings in mind and fix TZ by himself... or risk breakage. > Yes. Note that setting TZ is rather inconvenient. First because you have Using a hardware clock not in UTC is extremely inconvenient, as well. In fact, supporting that has been extremely inconvenient for long YEARS, now. I'd have dropped that support a lng time ago. At least this time, I know there is nothing better we can do. The user has two choices, either he must have the hw clock in UTC, or he must have his system fully timezone-capable since instant zero, which means /etc/localtime MUST be in the root partition. Setting TZ is kind of a middleground fix, a best effort fix if you will. And it does work, but it means people have to go and manually fix TZ when entering and leaving daylight savings time... > forget which package has the config script where you select your timezone, libc6 has tzconfig. > but I guess it could in principle apply it in both places. But that's Yes, it could be changed. > kind of ugly, and anyway the Debian philospohy is not to force people into > using config scripts. Well, if we were to do it in the strict Debian way (always do what is more correct technically speaking), we would drop non-UTC support. It complicates the boot procedure, it is prone to *very* subtle bugs, and it is technically insane to have a hardware clock in local time, and Microsoft itself only does so because they were dumb enough not to fix that in Windows 95, and because of MSDOS before that. But we try our best to support it, since people seem to find it useful. If that means they will have to jump through loops, that means they will have to jump through loops. But we certainly need to document this better, and d-i should warn the user right away that using the hardware clock in local time mode IS NOT a good idea, and that the system might not be able to deal automatically with daylight savings in that case. > >What would happen in the typical broken configuration? > > > >Non-UTC, /usr separate, no TZ defined anywhere: > > 0. kernel boots with wrong time (even if it reads the RTC by itself) > >* 1. hwclock sets the kernel UTC time to the local time in the RTC, > >and thus the system clock could be wrong by several hours in either > >direction. > > 2. System runs with wrong time. e2fsck can croak, etc. > > 3. something mounts /usr > >* 4. hwclock runs, and tells the user a completely ludricous time > >(timezone applied twice :P) <=== We could fix the mess here, so > >if the user doesn't hit a bug (e.g. e2fsck) before, he would not > >suffer much from his broken config. > >hwclock MUST be run after /usr is mounted to be able to help fix > >the mess (well work around it, realy). > > I don't have my unstable box handy to check right now, but it gets fixed > eventually. I think when hwclock runs after /usr is mounted, it sets the > time correctly. So it's only wrong before that point. I used to have Yes, but this bug showed up exactly because it is not running after /usr anymore (which is in fact broken behaviour and should be fixed, as I explained). > You know, another solution would be to relocate the whole > /usr/share/zoneinfo hierarchy to the root filesystem. I don't really like That's 5MiB more in the root filesystem. One can always ask the glibc maintainers to do it, or one can ask them to add something that keeps track of /etc/localtime and updates it every time glibc is updated or tzconfig is run, so only the required data would end up in the root partition (and /etc/localtime would not be a symlink anymore). I won't though. If the submitter feels like doing it, be my guest. Remember to point the glibc people to this bug so that they get the whole story. > to local time, which isn't really the Unix way. (I only did it because I > was dual-booting Windows, which insisted on having the hw clock in local > time.) Does it even do that anymore? Anyway, just lie about your timezone to Windows so that you get the correct time, and keep the clock in UTC. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#336263: hplip-data: Please don't depend on hplip
tag 336263 wontfix severity 336263 wishlist thaks On Sat, 29 Oct 2005, Samuel Mimram wrote: > I want to use hplip but I don't need all the qt stuff (in hplip). From the You are out of luck. Upstream mixed things so much that I am dropping hplip-base. I will reconsider this again when hplip goes 1.0.0 with fax support, but for now it will be a single arch any package, plus hpijs (arch any), and the two arch-all packages hplip-ppds and hplip-data. > hplip-base description, hplip-base is all I need. However, hplip-base hplip-base is gone with the 0.9.6-1 upload. The new packages conflict with it, it should be impossible to upgrade to 0.9.6 and still remain with hplip-base in the system. > depends on hplip-data which now depends on hplip. Is hplip really Parts of hplip-data are needed by the basic daemons, and I am not going to split hplip-data right now. A new package split will happen only when upstream finishes fax support and releases 1.0.0, as I hope that things will settle down, then. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#336287: hplip: hp-toolbox does not start
On Sat, 29 Oct 2005, Tibor Hajling wrote: > Traceback (most recent call last): > File "/usr/bin/hp-toolbox", line 274, in ? > sys.exit(main(sys.argv[1:])) > File "/usr/bin/hp-toolbox", line 237, in main > client = tbx_client() > File "/usr/bin/hp-toolbox", line 74, in __init__ > self.connect((prop.hpssd_host, prop.hpssd_port)) > File "/usr/lib/hplip/base/async_qt.py", line 201, in connect > raise socket.error, err > socket.error: 111 Make sure hpiod and hpssd are running. If they are not, please locate the error messages, and and send them here. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#336287: hplip: hp-toolbox does not start
On Sat, 29 Oct 2005, Hajling Tibor wrote: > Saturday 29 October 2005 12.41 dátummal Henrique de Moraes Holschuh ezt írta: > > > Make sure hpiod and hpssd are running. If they are not, please locate the > > error messages, and and send them here. > > They are not running. There is an error message: "You are missing a > dpkg-statoverride on /var/run/hplip. Fix it, otherwise you risk silent > breakage on upgrades." > > There is no such a file. What should I do? Run dpkg --pending --configure as root. What happens? -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh
Bug#336643: kernel-package: missing recommends on xmlto (kernel_doc target)
Package: kernel-package Version: 9.008.4 Severity: important xmlto is required for the make-kpng kernel_doc target to work so it should be recommended by kernel-package. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (990, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.13.4-debian1+libata+bluesmoke+imq+lm85 Locale: LANG=pt_BR.ISO-8859-1, LC_CTYPE=pt_BR.ISO-8859-1 (charmap=ISO-8859-1) Versions of packages kernel-package depends on: ii dpkg 1.13.11.0.1 package maintenance system for Deb ii dpkg-dev 1.13.11 package building tools for Debian ii gcc [c-compiler] 4:4.0.2-1 The GNU C compiler ii gcc-2.95 [c-compiler] 1:2.95.4-22.1 The GNU C compiler ii gcc-3.3 [c-compiler] 1:3.3.6-10The GNU C compiler ii gcc-3.4 [c-compiler] 3.4.4-9 The GNU C compiler ii gcc-4.0 [c-compiler] 4.0.2-3 The GNU C compiler ii gcc272 [c-compiler]2.7.2.3-19The GNU C compiler. ii make 3.80-11 The GNU version of the "make" util ii perl 5.8.7-7 Larry Wall's Practical Extraction Versions of packages kernel-package recommends: ii bzip2 1.0.2-10 high-quality block-sorting file co ii libc6-dev [libc-dev] 2.3.5-7GNU C Library: Development Librari -- no debconf information -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#340467: hplip-base depends on libsnmp5 which isn't in testing
severity 340467 important retitle 340467 [britney] removes dependencies from testing making packages uninstalable reassign 340467 ftp.debian.org thanks Summary for ftp.debian.org: hplip-base is still in testing. However, one of its dependencies (Depends:) was removed from testing, making hplip-base uninstalable. hplip-base should have been removed as well, OR the package it Depends: should not have been removed in the first place. Packages involved: hplib-base, libsnmp5 On Wed, 23 Nov 2005, Ido Abramovich wrote: > The package hplip-base (0.9.3-3) depends on libsnmp5, > but libsnmp5 isn't in the testing repository. WTF why hplip 0.9.3 not removed from testing, then, if one of its dependencies was? This is a very serious problem in the testing archive. > the lib package is only available on > security.debian.org sarge/updates. That might be a data point. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#340679: pyqt-tools: pyuic should NOT attempt to connect to session/x servers
Package: pyqt-tools Version: 3.15-4 Severity: normal While building hplip in a pbuider chroot (and later verified in all autobuilders using their logs): pyuic -x -o ui/loadpaperform_base.py ui/loadpaperform_base.ui Session management error: Could not open network socket It should not have tried to connect to anything in the first place. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (990, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.13.4-debian1+libata+bluesmoke+imq+lm85 Locale: LANG=pt_BR.ISO-8859-1, LC_CTYPE=pt_BR.ISO-8859-1 (charmap=ISO-8859-1) Versions of packages pyqt-tools depends on: ii libc62.3.5-8 GNU C Library: Shared libraries an ii libgcc1 1:4.0.2-4 GCC support library ii libqt3-mt3:3.3.5-1 Qt GUI Library (Threaded runtime v ii libstdc++6 4.0.2-4 The GNU Standard C++ Library v3 ii libx11-6 6.8.2.dfsg.1-10 X Window System protocol client li ii libxext6 6.8.2.dfsg.1-10 X Window System miscellaneous exte ii xlibs6.8.2.dfsg.1-10 X Window System client libraries m pyqt-tools recommends no packages. -- no debconf information -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#314603: azureus: Extremely annoying, useless "possible network disconnect/reconnect" message
Package: azureus Version: 2.3.0.2-1 Severity: minor Azureus has, for some braindamaged reason or another, the very dubious feature of poping up a window notifying you every time one of its tcp connections get an unexpected close. The damned thing pops up on *all* desktops, at the topmost layer. It can't get more disruptive than this. There is no rate limiting for those windows. You have to close them one by one, and after 24h of activity or so, there can be quite a lot of them open. They are completely useless, since azureus restarts the connection in the first place, and busy links are quite likely to cause some TCP connections to be closed by one of the sides apparently. Please kill that error message, make it a debug message to the debug log where it belongs. While at it, please remove the "open on all desktops" features of all error message windows as well. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (990, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.11.11-debian0.4+libata6dev1+bluesmoke Locale: LANG=pt_BR.ISO-8859-1, LC_CTYPE=pt_BR.ISO-8859-1 (charmap=ISO-8859-1) Versions of packages azureus depends on: ii gij-3.4 [java-virtual-machin 3.4.4-0 The GNU Java bytecode interpreter ii gij-4.0 [java-virtual-machin 4.0.0-9 The GNU Java bytecode interpreter ii j2re1.4 [java2-runtime] 1.4.2.02-1 Blackdown Java(TM) 2 Runtime Envir ii libcommons-cli-java 1.0-6 API for working with the command l ii liblog4j1.2-java 1.2.9-1 Logging library for java ii libseda-java 3.0-2 the Staged Event-Driven Architectu ii libswt-gtk-3.1-java 3.0+3.1M4-3 Standard Widget Toolkit for GTK Ja azureus recommends no packages. Versions of packages azureus is related to: ii reportbug 3.13 reports bugs in the Debian distrib pn totem-gstreamer(no description available) -- no debconf information -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#310325: gitweb: git is not a version control system
Package: gitweb Severity: minor Git may be a lot of things, but a version control system it is NOT. Linus himself said that a number of times in the git threads. Git is a tree management system. Cogito, OTOH, is supposed to evolve into a full featured version control system, AFAIK. Please fix the gitweb package description. -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (990, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.11.10-debian0.4+libata6dev1+bluesmoke Locale: LANG=pt_BR.ISO-8859-1, LC_CTYPE=pt_BR.ISO-8859-1 (charmap=ISO-8859-1) -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#303576: Bazaar 1.3.2 available upstream
retitle 303576 Please package new stable bazaar release thanks Bazaar 1.3.2 is available upstream, from http://bazaar.canonical.com/download.html *PLEASE* package it. Do you want help? NMUs? -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#305110: cupsys: does not install in sid
Package: cupsys Version: 1.1.23-8 Severity: grave Tags: sid Justification: renders package unusable Setting up cupsys (1.1.23-8) ... error in control file: `Section' value not specified at /usr/sbin/install-docs line 606, line 7. dpkg: error processing cupsys (--configure): subprocess post-installation script returned error exit status 9 Errors were encountered while processing: cupsys -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (990, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.11.7-debian2+libata6dev1+bluesmoke Locale: LANG=pt_BR.ISO-8859-1, LC_CTYPE=pt_BR.ISO-8859-1 (charmap=ISO-8859-1) Versions of packages cupsys depends on: ii adduser 3.63 Add and remove users and groups ii debconf 1.4.48 Debian configuration management sy ii libc6 2.3.2.ds1-21 GNU C Library: Shared libraries an ii libcupsimage2 1.1.23-8 Common UNIX Printing System(tm) - ii libcupsys2-gnutls10 1.1.23-8 Common UNIX Printing System(tm) - ii libgnutls11 1.0.16-13GNU TLS library - runtime library ii libpam0g0.76-22 Pluggable Authentication Modules l ii libpaper1 1.1.14-3 Library for handling paper charact ii libslp1 1.0.11a-2OpenSLP libraries ii patch 2.5.9-2 Apply a diff file to an original ii perl-modules5.8.4-8 Core Perl modules ii xpdf-utils 3.00-13 Portable Document Format (PDF) sui ii zlib1g 1:1.2.2-4compression library - runtime -- debconf information excluded -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#304976: Fixed in NMU 1.5.5-2.1
tag 304976 + fixed thanks Oops, forgot to close the bug in changelog. This bug has been fixed by the 1.5.5-2.1 NMU, just uploaded. libsasl7-dev is being removed from sid and sarge. This package is NOT going to spoil it with a broken dependency any longer... NMU diff attached. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh diff -ruN xfmail-1.5.5/debian/changelog xfmail-1.5.5-2.1/debian/changelog --- xfmail-1.5.5/debian/changelog 2005-04-17 21:24:06.371202998 -0300 +++ xfmail-1.5.5-2.1/debian/changelog 2005-04-17 21:13:42.608361964 -0300 @@ -1,3 +1,11 @@ +xfmail (1.5.5-2.1) unstable; urgency=low + + * NMU + * Get rid of bogus libsasl7-dev build-dependency + * Clean up config.log and config.status in clean rule + + -- Henrique de Moraes Holschuh <[EMAIL PROTECTED]> Sun, 17 Apr 2005 21:13:40 -0300 + xfmail (1.5.5-2) unstable; urgency=low * Use $LD instead of "$LD" inside configure so the shell will find diff -ruN xfmail-1.5.5/debian/control xfmail-1.5.5-2.1/debian/control --- xfmail-1.5.5/debian/control 2005-04-17 21:24:06.371202998 -0300 +++ xfmail-1.5.5-2.1/debian/control 2005-04-17 20:45:50.801547143 -0300 @@ -3,7 +3,7 @@ Priority: optional Maintainer: Florian Hinzmann <[EMAIL PROTECTED]> Standards-Version: 3.6.1 -Build-Depends: dpatch, debhelper (>= 4), libforms-dev, xlibs-dev, libdb3-dev, libgdbm-dev, libglib1.2-dev, libcompfaceg1-dev, libesd0-dev, libldap2-dev, libsasl-dev, libmcrypt-dev +Build-Depends: dpatch, debhelper (>= 4), libforms-dev, xlibs-dev, libdb3-dev, libgdbm-dev, libglib1.2-dev, libcompfaceg1-dev, libesd0-dev, libldap2-dev, libmcrypt-dev Package: xfmail Architecture: any diff -ruN xfmail-1.5.5/debian/rules xfmail-1.5.5-2.1/debian/rules --- xfmail-1.5.5/debian/rules 2005-04-17 21:24:06.373202753 -0300 +++ xfmail-1.5.5-2.1/debian/rules 2005-04-17 21:13:31.181754135 -0300 @@ -77,6 +77,8 @@ # Add here commands to clean up after the build process. -$(MAKE) distclean + rm -f config.log config.status + dh_clean
Bug#305119: RM: cyrus-sasl/sid -- Outdated, deprecated, and finally not needed anymore
Package: ftp.debian.org Severity: grave Justification: the package is useless Please remove cyrus-sasl and all its binary packages from sid. After NMUing it a lot of times, and giving both the public (via email to d-devel and d-user) and the almost-MIA maintainer more than 3 months to speak up against its removal, I am living up to the title of maintainer-in-charge-because-nobody-else-is-doing-anything-about-it, and requesting that the final blow be dealt to it. -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (990, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.11.7-debian2+libata6dev1+bluesmoke Locale: LANG=pt_BR.ISO-8859-1, LC_CTYPE=pt_BR.ISO-8859-1 (charmap=ISO-8859-1) -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#305119: RM: cyrus-sasl/sid -- Outdated, deprecated, and finally not needed anymore
On Mon, 18 Apr 2005, Jeroen van Wolffelaar wrote: > As the person doing MIA, I note that the maintainer isn't even in the > MIA database. So apparantly nobody inquired about this before on QA or Because dima isn't MIA per se, he is mostly MIA. From experience, Dima doesn't have time to deal with SASL unless something very weird happens, but he DOES show up from time to time. > Dima, please comment on this removal request; do you agree to have this > package removed? Dima, please reply soon. I did ask you a lot of time ago, and got no reply. Nobody from d-d or [EMAIL PROTECTED] spoke up against removing old sasl, either. I am willing to help with new sasl, but we really, really have no good reasons I can see for keeping old SASL in Debian, and I am *not* willing to help to keep it secure. Heck, not even qmail uses old sasl anymore, so we don't even have that aggravating reason to keep it around anymore... Upstream has deprecated this old version of SASL more than 3 years ago. It is about time we let it rest in peace. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#304976: build-dep is not bogus, but binary depends is missing
On Mon, 18 Apr 2005, Steve Langasek wrote:
> > 2) Any idea why ${shlibs:Depends} does not include libsaslX?
>
> Because the above check is wrong: the xfmail binary is *not* linked against
> libsasl.
Oh.
> $ objdump -p /tmp/xfmail/usr/bin/xfmail | grep NEEDED
> NEEDED libmail.so.0
> NEEDED libeditor.so.0
> NEEDED libface.so.0
> NEEDED libgdbm_compat.so.3
> NEEDED libgdbm.so.3
> NEEDED libnsl.so.1
> NEEDED libmcrypt.so.4
> NEEDED libltdl.so.3
> NEEDED libdl.so.2
> NEEDED libforms.so.1
> NEEDED libXpm.so.4
> NEEDED libSM.so.6
> NEEDED libICE.so.6
> NEEDED libX11.so.6
> NEEDED libesd.so.0
> NEEDED libaudiofile.so.0
> NEEDED libldap.so.2
> NEEDED liblber.so.2
> NEEDED libresolv.so.2
> NEEDED libglib-1.2.so.0
> NEEDED libstdc++.so.5
> NEEDED libm.so.6
> NEEDED libgcc_s.so.1
> NEEDED libc.so.6
> $
>
> One or more of *these* libraries links against libsasl (apparently libldap),
Yeah, libldap does link against libsasl2.
> and this is the only reason sasl shows up in the output of ldd. So there is
> no missing dependency.
That's a relief, it means xfmail in the NMU should be working fine...
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#304976: build-dep is not bogus, but binary depends is missing
On Mon, 18 Apr 2005, Florian Hinzmann wrote:
> The build dependency is fine. It's the binary depends that is
> missing.
Ouch! I didn't think of that one. I *did* remove all traces of libsasl7 and
friends from my system, so I knew the build would not be able to complete if
xfmail really needed old SASL...
> The NMU still links against libsasl:
> [EMAIL PROTECTED]:~/xfmail-sasl-stuff$ dpkg-deb -x xfmail_1.5.5-2.1_i386.deb
> nmu-binary
> [EMAIL PROTECTED]:~/xfmail-sasl-stuff$ ldd nmu-binary/usr/
> bin/ lib/ share/
> [EMAIL PROTECTED]:~/xfmail-sasl-stuff$ ldd nmu-binary/usr/bin/xfmail |grep
> sasl
> libsasl2.so.2 => /usr/lib/libsasl2.so.2 (0xb7911000)
Oops, that's the new SASL. That means I have to at least do a new NMU
adding a build-dependency on libsasl2-dev... SASL usually changes APIs when
the ABI changes, so it doesn't make much sense to build-depend on
libsasl-dev usually.
> Two questions:
> 1) Is libsasl2-dev and libsasl2 going to be removed, too?
If they are, which is not probable in the near future, that will be because
libsasl3 hit the archive...
And by that time, I am sure xfmail will have a depends on libsasl2 that
will not let anyone forget to notify you about it before trying to remove
the package ;-)
> 2) Any idea why ${shlibs:Depends} does not include libsaslX?
No, probably some LD_LIBRARY_PATH or other issue that broke the shlibdeps
scanning. I will look the package over and tell you what I find.
Do you prefer I mail you patches, or that I clean up the mess with another
NMU?
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#305119: RM: cyrus-sasl/sid -- Outdated, deprecated, and finally not needed anymore
On Mon, 18 Apr 2005, Dima Barsky wrote: > You are right, I don't have time now to maintain the SASL package > properly. I'm going to offer it for adoption soon (unless you want to > take over). As for this bug, I agree, cyrus-sasl should be removed. Ok. I suggest that the SASL packages should be maintained by a team in Alioth (I don't mind being part of the team), but I don't think I have all the time maintaining SASL properly requires, otherwise I would have asked to officially adopt it already... -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#305299: hplip: hp-probe doesn't find networked laserjet 4 plus
On Mon, 18 Apr 2005, [EMAIL PROTECTED] wrote: > 'hp-probe --bus=net' does not find the printer. hp-probe --bus=net is not implemented yet, according to hp-probe's online help. I could not get it to find anything on the network, either (I have a networked HP PhotoSmart 2610). You'll need to use hp-makeurl to "find" a network printer using its IP address... -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#305428: amavisd-new: bug processing "MAIL FROM: AUTH=<>" - breaks postfix!
tags 305428 + fixed-in-experimental thanks On Tue, 19 Apr 2005, Paul Traina wrote: > I've checked the source in amavisd-new, and it's definitely not processing > AUTH properly. The good news, however, is that it's fixed in the current > version of amavisd-new. Ok. Tagged accordingly. > I see in another bug that you have a sid package just about ready to go, > but that message is dated in 2004. Help please? This is screwing things > kinda badly for me (I have to change my filtering to not reject spam...). It has been uploaded to experimental, and there is an alioth project that you can join if you want to help with the packaging. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#305517: foomatic-db-hpijs: Please update to new upstream
Package: foomatic-db-hpijs Version: 1.5-20050403-1 Severity: wishlist HPIJS 2.1.2 introduced a new GrayScale FastDraft printing mode, and a lot of PPDs were updated accordingly with the HPLIP 0.9.2 release. Please upload an updated package. Thanks. -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (990, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.11.7-debian2+libata6dev1+bluesmoke Locale: LANG=pt_BR.ISO-8859-1, LC_CTYPE=pt_BR.ISO-8859-1 (charmap=ISO-8859-1) Versions of packages foomatic-db-hpijs depends on: ii foomatic-db 20050403-1 linuxprinting.org printer support ii foomatic-filters3.0.2-20050403-1 linuxprinting.org printer support ii hpijs 2.1.2+0.9.2-1HP Linux Printing and Imaging - gs -- no debconf information -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#305596: gbib: Do not upload to Sid packages compiled with gcc 4.0
Package: gbib Version: 0.1.2-3 Severity: grave Tags: sid * gbib depends on libgcc1 (>= 1:4.0) [UNAVAILABLE] Please use a clean sid chroot to build packages if you must use experimental packages in your development machine... -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (990, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.11.7-debian2+libata6dev1+bluesmoke Locale: LANG=pt_BR.ISO-8859-1, LC_CTYPE=pt_BR.ISO-8859-1 (charmap=ISO-8859-1) Versions of packages gbib depends on: ii gdk-imlib1 1.9.14-16.2 imaging library for use with gtk ( ii libart2 1.4.2-19The GNOME canvas widget - runtime ii libaudiofile00.2.6-6 Open-source version of SGI's audio ii libc62.3.2.ds1-21GNU C Library: Shared libraries an ii libdb3 3.2.9-22Berkeley v3 Database Libraries [ru ii libesd-alsa0 [libesd 0.2.35-2Enlightened Sound Daemon (ALSA) - ii libgcc1 1:3.4.3-12 GCC support library ii libglib1.2 1.2.10-9The GLib library of C routines ii libgnome32 1.4.2-19The GNOME libraries ii libgnomesupport0 1.4.2-19The GNOME libraries (Support libra ii libgnomeui32 1.4.2-19The GNOME libraries (User Interfac ii libgtk1.21.2.10-17 The GIMP Toolkit set of widgets fo ii libice6 4.3.0.dfsg.1-12.0.1 Inter-Client Exchange library ii libsm6 4.3.0.dfsg.1-12.0.1 X Window System Session Management ii libstdc++5 1:3.3.5-12 The GNU Standard C++ Library v3 ii libx11-6 4.3.0.dfsg.1-12.0.1 X Window System protocol client li ii libxext6 4.3.0.dfsg.1-12.0.1 X Window System miscellaneous exte ii libxi6 4.3.0.dfsg.1-12.0.1 X Window System Input extension li ii xlibs4.3.0.dfsg.1-12 X Keyboard Extension (XKB) configu -- no debconf information -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#305598: cbios: new upstream available
Package: cbios Version: 0.19-3 Severity: wishlist 0.20 is available upstream, please package it... -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (990, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.11.7-debian2+libata6dev1+bluesmoke Locale: LANG=pt_BR.ISO-8859-1, LC_CTYPE=pt_BR.ISO-8859-1 (charmap=ISO-8859-1) -- no debconf information -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#305598: cbios: new upstream available
On Thu, 21 Apr 2005, Joost Yervante Damad wrote: > On Thursday 21 April 2005 02:20, Henrique de Moraes Holschuh wrote: > > Package: cbios > > Version: 0.19-3 > > Severity: wishlist > > > > 0.20 is available upstream, please package it... > > Package is already made quite some time ago; it is still pending a sponsored > upload. Do you want me to upload it? -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#305853: Debian Bug#305853: openmsx: IPS patch support is incomplete
On Sat, 23 Apr 2005, Wouter Vermaelen wrote: > But when i try it with KnightMare III and the Portuguese translation > patch it doesn't work (MSX crashes after the Konami logo). However when Yeah, I noticed. I was about to send more email to the bug report, apparently the IPS file is bad. > So maybe my original rom and/or patch is corrupt or maybe the patched > game only works in certain MSX models? These are the SHA1SUMS of my > files, can you verify these against your files? > > 25f5adeca8a2ddb754d25eb18cff0d84e5b003bc Shalom_(1987)_(Konami)_(J).rom > 5426b18a8d670087795d2e9e4886fff9f287fe15 SHALOMP.IPS > 0441a3dc6ec268ba1f62fb32cdb89dffbc303bc5 Shalom-patched.rom > > If they are different, can you send me your files? Thanks. I have a working (mostly) ROM, produced by the IPS patch author. but that breaks the SHALOM disk support (which works well in the original ROM). The SHA1 sums match yours, including the (damaged) ROM I get when I use the IPS patch. Apparently, I will have to track down the IPS patch author and get a good one (or at least an explanation wether the shalom disk support is broken on purpose. If so, we could produce a new IPS patch from the already-patched ROM he provides). If you are interested in the already-patched ROM, I can send that to you. Since you have added full IPS support to openMSX, this bug report can be closed when the new openMSX package with full IPS support is uploaded. Thanks! -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#305991: openmsx: please write SRAM files in synchronous mode (no buffering)
Package: openmsx Version: 0.5.1-2 Severity: wishlist Tags: upstream It would be nice if the SRAM files (especially stuff like the Konami Gamemaster-II SRAM files) were always kept current on disk. As it is, the files do not always reflect the contents of the SRAM while openMSX is running (and I just lost a few hours worth of KnightMare III progress because of it :-P ). If writing to the SRAM on-disk backup in syncronous mode is not feasible, flushing it out every second (only when the contents were modified) would do just fine. -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (990, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.11.7-debian2+libata6dev1+bluesmoke Locale: LANG=pt_BR.ISO-8859-1, LC_CTYPE=pt_BR.ISO-8859-1 (charmap=ISO-8859-1) Versions of packages openmsx depends on: ii cbios 0.20-1 open source MSX BIOS roms ii libc6 2.3.2.ds1-21 GNU C Library: Shared libraries an ii libgcc1 1:3.4.3-12 GCC support library ii libpng12-01.2.8rel-1 PNG library - runtime ii libsdl-image1 1.2.4-1image loading library for Simple D ii libsdl1.2debi 1.2.7+1.2.8cvs20041007-4.1 Simple DirectMedia Layer ii libstdc++51:3.3.5-12 The GNU Standard C++ Library v3 ii libxml2 2.6.16-7 GNOME XML library ii tcl8.48.4.9-1Tcl (the Tool Command Language) v8 ii xlibmesa-gl [ 4.3.0.dfsg.1-12.0.1Mesa 3D graphics library [XFree86] ii zlib1g1:1.2.2-4 compression library - runtime -- no debconf information -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#305853: openmsx: IPS patch support is incomplete
Package: openmsx Version: 0.5.1-2 Severity: wishlist Tags: upstream IPS files with overlapping regions are not supported. This is required, for example, for the KnightMare III translation patch for Portuguese. That patch takes the 256kb ROM and creates a new one that is bigger (512kb) with some changes to the old ROM and a lot of new stuff. WinIPS 2.0 patches the file just fine, but I dislike wine heavily, and I'd rather see openMSX support this fully... -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (990, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.11.7-debian2+libata6dev1+bluesmoke Locale: LANG=pt_BR.ISO-8859-1, LC_CTYPE=pt_BR.ISO-8859-1 (charmap=ISO-8859-1) Versions of packages openmsx depends on: ii cbios 0.20-1 open source MSX BIOS roms ii libc6 2.3.2.ds1-21 GNU C Library: Shared libraries an ii libgcc1 1:3.4.3-12 GCC support library ii libpng12-01.2.8rel-1 PNG library - runtime ii libsdl-image1 1.2.4-1image loading library for Simple D ii libsdl1.2debi 1.2.7+1.2.8cvs20041007-4.1 Simple DirectMedia Layer ii libstdc++51:3.3.5-12 The GNU Standard C++ Library v3 ii libxml2 2.6.16-7 GNOME XML library ii tcl8.48.4.9-1Tcl (the Tool Command Language) v8 ii xlibmesa-gl [ 4.3.0.dfsg.1-12.0.1Mesa 3D graphics library [XFree86] ii zlib1g1:1.2.2-4 compression library - runtime -- no debconf information -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#309114: postfix: bsmtp entry in master.cf causes data corruption
Package: postfix Version: 2.2.3-2 Severity: important The current line in the bsmtp mailer in master.cf tells pipe to do dot-stuffing and then calls bsmtp with the -d switch, which also does dot-stuffing. Please remove that -d option from the bsmtp command invocation -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (990, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.11.9-debian0.2+libata6dev1+bluesmoke Locale: LANG=pt_BR.ISO-8859-1, LC_CTYPE=pt_BR.ISO-8859-1 (charmap=ISO-8859-1) Versions of packages postfix depends on: ii adduser 3.63 Add and remove users and groups ii debconf [debconf-2.0] 1.4.49 Debian configuration management sy ii dpkg1.10.27 Package maintenance system for Deb ii libc6 2.3.2.ds1-22 GNU C Library: Shared libraries an ii libdb4.24.2.52-18Berkeley v4.2 Database Libraries [ ii libsasl22.1.19-1.5 Authentication abstraction library ii libssl0.9.7 0.9.7g-1 SSL shared libraries ii netbase 4.21 Basic TCP/IP networking system -- debconf information excluded -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#292672: hplip_toolbox opens everytime something is printed
retitle 292672 hpguid reopens toolbox always tags 292672 + upstream confirmed thanks Apparently, hpguid is doing dumb things. First of all, printing and ending a print job are the type of stuff one does NOT want the gui to flag as status changes... Second, it is not honouring the option to *not* open the device manager (toolbox) on status changes. On Fri, 28 Jan 2005, Adolfo Gonzalez Blazquez wrote: > Once hplip_toolbox is opened, everytime you send something to the > printer, the toolbox opens again. If toolbox is never opened, this never > happens. Kill any running instances of "python /usr/lib/hplip/hpguid.py" as a workaround. > This behaviour is very annoying, 'cause toolbox window is very big (in Agreed. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#292722: bzflag: [gameplay] stealth/cloacked tank can be seen by the tracks
Package: bzflag Version: 2.0.0.20050118 Severity: normal Tags: upstream When the visual effect of tank tracks is enabled, one can see the tracks of the invisible tanks... This wouldn't be a bad thing at all, if not for the fact that the tracks effect is *optional*. -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (990, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.10-debian4+libata9dev1 Locale: LANG=pt_BR, LC_CTYPE=pt_BR (charmap=ISO-8859-1) Versions of packages bzflag depends on: ii libadns1 1.0-8.2Asynchronous-capable DNS client li ii libc6 2.3.2.ds1-20 GNU C Library: Shared libraries an ii libcurl3 7.12.3-2 Multi-protocol file transfer libra ii libgcc1 1:3.4.3-7 GCC support library ii libice6 4.3.0.dfsg.1-10Inter-Client Exchange library ii libidn11 0.5.2-3GNU libidn library, implementation ii libsdl1.2debi 1.2.7+1.2.8cvs20041007-4.1 Simple DirectMedia Layer ii libsm64.3.0.dfsg.1-10X Window System Session Management ii libssl0.9.7 0.9.7e-3 SSL shared libraries ii libstdc++51:3.3.5-7 The GNU Standard C++ Library v3 ii libx11-6 4.3.0.dfsg.1-10X Window System protocol client li ii libxext6 4.3.0.dfsg.1-10X Window System miscellaneous exte ii libxi64.3.0.dfsg.1-10X Window System Input extension li ii xlibmesa-gl [ 4.3.0.dfsg.1-10Mesa 3D graphics library [XFree86] ii xlibmesa-glu 4.3.0.dfsg.1-10Mesa OpenGL utility library [XFree ii xlibs 4.3.0.dfsg.1-10X Keyboard Extension (XKB) configu ii zlib1g1:1.2.2-4 compression library - runtime -- no debconf information -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#292723: bzflag: CR/LF on message console stops working
Package: bzflag Version: 2.0.0.20050118 Severity: normal Sometimes, after switching console modes (shift-f1, shift-f2...), bzflag gets completely confused, and draws *all* messages on the console show in the last line, one on top of the other. So far, the only way I found to get the console back to an useful state is to exit bzflag and restart. -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (990, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.10-debian4+libata9dev1 Locale: LANG=pt_BR, LC_CTYPE=pt_BR (charmap=ISO-8859-1) Versions of packages bzflag depends on: ii libadns1 1.0-8.2Asynchronous-capable DNS client li ii libc6 2.3.2.ds1-20 GNU C Library: Shared libraries an ii libcurl3 7.12.3-2 Multi-protocol file transfer libra ii libgcc1 1:3.4.3-7 GCC support library ii libice6 4.3.0.dfsg.1-10Inter-Client Exchange library ii libidn11 0.5.2-3GNU libidn library, implementation ii libsdl1.2debi 1.2.7+1.2.8cvs20041007-4.1 Simple DirectMedia Layer ii libsm64.3.0.dfsg.1-10X Window System Session Management ii libssl0.9.7 0.9.7e-3 SSL shared libraries ii libstdc++51:3.3.5-7 The GNU Standard C++ Library v3 ii libx11-6 4.3.0.dfsg.1-10X Window System protocol client li ii libxext6 4.3.0.dfsg.1-10X Window System miscellaneous exte ii libxi64.3.0.dfsg.1-10X Window System Input extension li ii xlibmesa-gl [ 4.3.0.dfsg.1-10Mesa 3D graphics library [XFree86] ii xlibmesa-glu 4.3.0.dfsg.1-10Mesa OpenGL utility library [XFree ii xlibs 4.3.0.dfsg.1-10X Keyboard Extension (XKB) configu ii zlib1g1:1.2.2-4 compression library - runtime -- no debconf information -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#293062: otrs: scripts for PerlRequire should be in /etc, and need to be fixed for Debian
Package: otrs Version: 1.3.2p01-3 Severity: normal The scripts used to pre-load perl modules should be in /etc/otrs (and linked from /usr/share/otrs/scripts I suppose), since it is likely the user will need to muck with them a bit. Also, they currenly do not work (at least for apache2, which will spin around in a busy loop and won't start), and still have "/opt/otrs" nonsense in them. -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (990, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.10-debian4+libata9dev1 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages otrs depends on: ii apache2 2.0.52-3 Next generation, scalable, extenda ii apache2-mpm-prefork [apache2] 2.0.52-3 Traditional model for Apache2 ii libauthen-sasl-perl 2.08-1 Authen::SASL - SASL Authentication ii libdate-pcalc-perl1.2-2 Perl module for Gregorian calendar ii libdbi-perl 1.46-6 Perl5 database interface by Tim Bu ii libemail-valid-perl 0.15-1 Check validity of Internet email a ii libio-stringy-perl2.109-3Perl5 modules for IO from scalars ii libmailtools-perl 1.62-1 Manipulate email in perl programs ii libmime-perl 5.415-2Perl5 modules for MIME-compliant m ii perl 5.8.4-5Larry Wall's Practical Extraction -- no debconf information -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
