Bug#307575: cross-site scripting attack via redirect parameter (CAN-2005-1308)
Package: sqwebmail Version: 0.47-4 Severity: important Tags: security sqwebmail is vulnerable to a cross-site scripting attack: Input passed to the "redirect" parameter is not properly sanitised. This can be exploited to inject malicious characters into HTTP headers and may allow execution of arbitrary HTML and script code in a user's browser session in context of an affected site. Details here: http://secunia.com/advisories/15119 This is supposed to be a working proof of concept, but I've not actually tested it: sqwebmail?redirect=%0d%0a%0d%0a[INJECT SCRIPT] -- see shy jo signature.asc Description: Digital signature
Bug#160579: you know
What _I'd_ like someone to explain is why this package cannot just be updated to include the security fix that has been in upstream for *years*. Is it being maintained? -- see shy jo signature.asc Description: Digital signature
Bug#283161: CAN-2005-1119
As I read http://www.securityfocus.com/bid/13171/discussion/ , which has been assigned CVE id CAN-2005-1119, this is a security hole because visodo is not limited to editing /etc/sudoers. With the -f switch, it can be made to edit some other file; if that other file is in a directory to which an attacker has write access, they can overwrite arbitrary files via a symlink attack. Still fairly theoretical, but I wanted to note that this is CAN-2005-1119 .. -- see shy jo signature.asc Description: Digital signature
Bug#307653: Package mdm ist missing
Jan Lühr wrote: > Package: debian-installer > Version: Rc3 > > Greetings, > > I recently had some trouble installing Sarge (with rc3) on software raid > system using the netinst-cd. > For mysterious reasons the package mdadm was missing - and the installation > stopped, complaining about that. > Then I used the business card image and the package was downloaded without > any > trouble. > Please make sure, that mdadm is on the netinst cd. I have, and it is. You must have some other problem, such as a badly burnt CD, or a computer that fails to read the file for some reason. -- see shy jo signature.asc Description: Digital signature
Bug#307697: hard to understand prompt
Package: netbase Version: 4.21 Severity: minor I was prompted with this for some reason or another (while upgrading leafnode): Do you want to ignore this potential problem and continue, or would you rather not do so now ? Continue? (n/y) This prompt crashed my English parser and 3 random English parsers queried on IRC. I had to diagram the sentences manually to work out what a "y" answer or a "n" answer does. I suggest the simpler: Ignore this potential problem? (n/y) -- see shy jo signature.asc Description: Digital signature
Bug#307632: not rc, not a security issues
severity 307632 normal thanks This bug is not RC and is not a security issue. The piece of policy quoted is intended to warn against attacks such as symlink attacks that can be performed on unsafely created temp files. The program in question is run during a fai install, before the system is multiuser, and so its unsafe temp files cannot be created. -- see shy jo signature.asc Description: Digital signature
Bug#307042: fix?
Just a reminder that it's been 5 days since you promised a fix for this RC bug "shortly". -- see shy jo signature.asc Description: Digital signature
Bug#306878: downgrade
severity 306878 normal thanks I'll leave closing the bug up to the maintainer, but based on Allan Lyons's review, this bug is not RC so I'm downgrading it. -- see shy jo signature.asc Description: Digital signature
Bug#307591: referring to examples files in postinst scripts is a policy violation and..
libapache-mod-php4.postinst:cp /usr/share/doc/php4-common/examples/php.ini $phpini libapache2-mod-php4.postinst: cp /usr/share/doc/php4-common/examples/php.ini $phpini php4-cgi.postinst: cp /usr/share/doc/php4-common/examples/php.ini $phpini php4-cli.postinst:cp /usr/share/doc/php4-common/examples/php.ini $phpini Besides apparently breaking the installation of libapache2-mod-php4, all of the above violate policy 12.6. -- see shy jo signature.asc Description: Digital signature
Bug#307834: Installation: Micron Transport floppy=nofifo problem
Eric Shubes wrote: > The error wasn't absolutely consistent. The long rw: value varied. Usually > 24, but sometimes 13 or 20. The rs= value changed too, 2 and 15 > respectively. > The install media was fine. I checked, double checked, cleaned the drive, > and even created media on the same computer which was failing. On occasion > (3 times out of 20 or so) > > I also tried various other parameters: floppy=0,daring; =broken_dcl; > =slow, and none helped. > > I don't know why floppy=nofifo fixed the problem with Woody (Woody had the > same symptoms without it). It appears to me as though floppy=nofifo simply > doesn't work. At least it doesn't do what it did with Woody. > > I've since done a dist-upgrade instead, so I'm not in need of this to > work, but it would be nice to have it fixed for the next person who tries > it. I'll be happy to do whatever testing that may be needed. The issue is that kernel boot time parameters are not seen by modules when they're loaded. The floppy driver is a module in sarge. You should be able to work around the problem by booting with BOOT_DEBUG=3. This will give you several shell prompts after the floppy boots. At the first one, "before hardware detection", you can try to "modprobe floppy floppy=nofifo". If that works for you, then we obviously need a better fix to let these parameters be specified. -- see shy jo signature.asc Description: Digital signature
Bug#303927: patch in ubuntu
FWIW, USN-116-1 is about this bug and bug #305255, and their gzip now includes patches for both. I've not tried to extract the patch for this hole yet. -- see shy jo signature.asc Description: Digital signature
Bug#307632: not rc, not a security issues
Holger Levsen wrote: > This is not true/right, since fai 2.8 "fai" can run on a running system, so > there might be ways to exploit this. Ah sorry I wasn't aware of this. I can verify that it's exploitable if you run it on a running system, FWIW. -- see shy jo signature.asc Description: Digital signature
Bug#307989: backup broken
Package: choose-mirror Version: 1.09 Severity: normal Backing up from the list of mirrors is broken, it just returns to the same list. -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.4.27 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages choose-mirror depends on: pn configured-network Not found. ii libc6 2.3.2.ds1-21 GNU C Library: Shared libraries an ii libdebconfclient0 0.74 Debian Configuration Management Sy ii libdebian-installer40.29 Library of common debian-installer -- see shy jo signature.asc Description: Digital signature
Bug#299939: able to test this?
I notices that Justin Pryzby has proposed a patch to fix the gkdial double-click crash. I wonder if you're able to test it and see if it fixed the bug you filed? You can find the patch at http://bugs.debian.org/299939 ; if you're not comfortable patching it yourself I can do a rebuild. This bug has caused gkdial to be removed from debian sarge and it would be a shame to release without it. If you're not able to test the patch, I might be able to at my Mom's sometime in the next week, assuming I can reproduce the crash there. -- see shy jo signature.asc Description: Digital signature
Bug#156161: simple suggestion
I've re-read this entire bug log after discovering that a deleted rc2.d/S symlink and invoke-rc.d started a daemon that I didn't want running and ate serious quantitues of bandwidth. I'm now very glad I don't pay per megabyte of bandwidth like some people have to. :-/ Anyway, one thing I see agreement on in this bug log is that if there's no S and no K symlink, the setup is undefined or invalid. So why not make invoke-rc.d just detect this and warn about it? I don't care what the behavior is as long as it tells me I've done something wrong so I know to fix it immediatly, not after rouge daemons that I tried to disable have gone haywire etc. -- see shy jo signature.asc Description: Digital signature
Bug#308185: rbscrobbler: Please support ID3 v2.2
reassign 308185 python-eyed3
thanks
Micah Anderson wrote:
> Package: rbscrobbler
> Version: 0.0.9pre3-3
> Severity: wishlist
>
> It seems that ID3 v2.2 support is not included in rbscrobbler, as this
> most recent traceback I received seems to indicate:
>
> Exception in thread Thread-1:Traceback (most recent call last):
> File "/usr/lib/python2.3/threading.py", line 442, in __bootstrap
> self.run()
> File "/usr/lib/python2.3/threading.py", line 422, in run
> self.__target(*self.__args, **self.__kwargs)
> File "/usr/bin/rbscrobbler", line 352, in run
> self.run_iter()
> File "/usr/bin/rbscrobbler", line 397, in run_iter
> mbid = MB.getSignature(uri)
> File "/usr/share/rbscrobbler/Scrobbler_Musicbrainz.py", line 47, in
> getSignature
> mbid = self.__id3mbid(filename)
> File "/usr/share/rbscrobbler/Scrobbler_Musicbrainz.py", line 61, in
> __id3mbid
> tag.link(filename)
> File "/usr/lib/python2.3/site-packages/eyeD3/tag.py", line 455, in link
> padding = self.__loadV2Tag(f);
> File "/usr/lib/python2.3/site-packages/eyeD3/tag.py", line 1188, in
> __loadV2Tag
> if not self.header.parse(fp):
> File "/usr/lib/python2.3/site-packages/eyeD3/tag.py", line 124, in parse
> raise TagException("ID3 v" + str(major) + "." + str(minor) +\
> TagException: ID3 v2.2 is not supported.
This looks to be a limitation of python-eyed3, so reassigning it to
there.
--
see shy jo
signature.asc
Description: Digital signature
Bug#308183: Package: installation-reports
Klaus Ade Johnstad wrote:
> I did notice some translation bugs:
> [1]
> In the first stage of installation the buttons are correctly translated
> to nb_NO (with ja,nei,avbryt), but in the second stage of installation
> they are in English (Yes, No, Cancel),
I think newt is lacking an nb translation.
> [2]
> There is also a parse-error in the second stage concerning the setup of
> the timezone, it just says
> "Ut fra landet er tidssonen sansynligvis .
> Er du i Europe/Oslo-tidssonen?"
> The first sentence doesn't make any sense, there is a 'Europe/Oslo'
> missing there.
>
> I wonder if this might be because of this translation in
> base-config_debian.po:
>
> msgid "Based on your country, your time zone is probably ${zone}."
> msgstr "Ut fra landet er tidssonen sannsynligvis ${timezone}."
Fixed.
--
see shy jo
signature.asc
Description: Digital signature
Bug#257838: resizing to 0 height causes it to consume massize amounts of cpu
Loïc Minier wrote: > Hi, > > This is a followup for Debian bug <http://bugs.debian.org/257838>. > > On lun, oct 18, 2004, Joey Hess wrote: > > > > If I cause rhythmbox's window to be resized to have a zero height, it > > begins consuming 100% of my cpu. This is even when it's not playing a > > song. If it matters, I'm using ion2, and the operation that makes it > > have zero height is a window shade function, similar to one in many > > other window managers. > > I've prepared a package with a patch on wrong Gtk geometry hints which > confused window managers, the new Rhythmbox package sits in > incoming.debian.org right now. Could you confirm this solves your > problem? I haven't seen the problem in ion for a while.. -- see shy jo signature.asc Description: Digital signature
Bug#302454: trackballs update for sarge
reopen 302454
thanks, but the fix doesn't guard against races; see below
Ari Pollak wrote:
> I just uploaded trackballs 1.0.0-10 to unstable, which fixes bug
> #302454, a severity:important and minor security issue, so I'd like to
> get this into sarge. An interdiff between revisions -9 and -10 is attached.
> --- trackballs-1.0.0/config.guess
> +++ trackballs-1.0.0/config.guess
> --- trackballs-1.0.0/config.sub
> +++ trackballs-1.0.0/config.sub
Hurrah for pointless config.* updates in security updates.
> diff -u trackballs-1.0.0/share/icons/Makefile.in
> trackballs-1.0.0/share/icons/Makefile.in
> --- trackballs-1.0.0/share/icons/Makefile.in
> +++ trackballs-1.0.0/share/icons/Makefile.in
> @@ -195,8 +195,8 @@
> maintainer-clean-generic clean mostlyclean distclean maintainer-clean
>
>
> -install-pkgdataDATA:
> - ./installIcons $(bindir) ${DESTDIR}
> +#install-pkgdataDATA:
> +#./installIcons $(bindir) ${DESTDIR}
>
> # Tell versions [3.59,3.63) of GNU make to not export all variables.
> # Otherwise a system limit (for SysV at least) may be exceeded.
> diff -u trackballs-1.0.0/share/icons/trackballs.desktop
> trackballs-1.0.0/share/icons/trackballs.desktop
> --- trackballs-1.0.0/share/icons/trackballs.desktop
> +++ trackballs-1.0.0/share/icons/trackballs.desktop
> @@ -9,14 +8,0 @@
> -Exec=/usr/local/bin/trackballs
> -Exec=/usr/games/trackballs
> -Exec=/usr/games/trackballs
> -Exec=/usr/games/trackballs
> -Exec=/usr/games/trackballs
> -Exec=/usr/games/trackballs
> -Exec=/usr/games/trackballs
> -Exec=/usr/games/trackballs
> -Exec=/usr/games/trackballs
> -Exec=/usr/games/trackballs
> -Exec=/usr/games/trackballs
> -Exec=/usr/games/trackballs
> -Exec=/usr/games/trackballs
> -Exec=/usr/games/trackballs
> + * Don't bother running the script to install a GNOME .desktop file
> +since it doesn't work anyway
Doesn't explain why you modified the .desktop file, although I think I
see why -- the script was appending to it on each build, right?
Anyway, I ended up wasting at least 10 minutes reading the code and
doing my own test build on a system with /usr/share/applications present
to satisfy myself that installIcons never manages to do anything and
that this change is indeed a no-op. If you want quick service for
security fixes, please do not conflate them with unrelated changes like
this one.
> diff -u trackballs-1.0.0/debian/changelog trackballs-1.0.0/debian/changelog
> --- trackballs-1.0.0/debian/changelog
> +++ trackballs-1.0.0/debian/changelog
> @@ -1,3 +1,11 @@
> +trackballs (1.0.0-10) unstable; urgency=low
> +
> + * Backport symlink checking code from upstream CVS (Closes: #302454)
> +
> + -- Ari Pollak <[EMAIL PROTECTED]> Sun, 8 May 2005 18:49:27 -0400
> +
> trackballs (1.0.0-9) unstable; urgency=low
>
>* Somehow I uploaded -8 without the fix. Really do that this time.
> only in patch2:
> unchanged:
> --- trackballs-1.0.0.orig/src/general.cc
> +++ trackballs-1.0.0/src/general.cc
> @@ -25,6 +25,8 @@
> #include "font.h"
> #include "glHelp.h"
> #include "SDL/SDL_image.h"
> +#include
> +#include
>
> using namespace std;
>
> @@ -58,3 +60,10 @@
>if(fp) { fclose(fp); return 1; }
>return 0;
> }
> +
> +int pathIsLink(char *path) {
> + struct stat m;
> + if(lstat(path,&m)) return 0;
> + if(S_ISLNK(m.st_mode)) return 1;
> + return 0;
> +}
This patch immediatly raises a red flag here, since this kind of check
cannot guard against races and is thus useless.
> --- trackballs-1.0.0.orig/src/settings.cc
> +++ trackballs-1.0.0/src/settings.cc
> @@ -140,9 +140,17 @@
>int version=4;
>
>snprintf(str,sizeof(str)-1,"%s/.trackballs",getenv("HOME"));
> + if(pathIsLink(str)) {
> + fprintf(stderr,"Error, %s is a symbolic link. Cannot save
> settings\n",str);
> + return;
> + }
>
>mkdir(str,S_IXUSR|S_IRUSR|S_IWUSR|S_IXGRP|S_IRGRP|S_IWGRP);
>snprintf(str,sizeof(str)-1,"%s/.trackballs/settings",getenv("HOME"));
> + if(pathIsLink(str)) {
> + fprintf(stderr,"Error, %s is a symbolic link. Cannot save
> settings\n",str);
> + return;
> + }
>
>/* TODO. Save all settings here */
>FILE *fp = fopen(str,"wb");
And sure enough, the way this patch uses pathIsLink does not guard
against an attacker racing trackballs and replacing a valid path with a
symlink bewteen the lstat and the fopen. This fails to fix the security
hole.
A correct fix would be to drop permissions before writing to files under
the user's control.
So sorry, I cannot accept this to testing. If you re-do the patch to
really be secure, I'd appreciate it if the new version doesn't include
the gnome desktop file change -- that would help speed its review.
--
see shy jo
signature.asc
Description: Digital signature
Bug#308234: upgrading from 2.1.23 failed because of not setting slapd/dump_database_destdir
Steve Langasek wrote: > reassign 308234 debconf > thanks > > Hi guys, > > On Mon, May 09, 2005 at 08:20:23AM +0200, Torsten Landschoff wrote: > > > On Mon, May 09, 2005 at 12:21:32AM +0200, Ferenc Engard wrote: > > > > While I have upgraded my system, slapd upgrade asked some questions, > > > including directory to dump databases. The text said the default is > > > /var/backups/slapd-VERSION. Reading that, I simply pushed enter. After > > > that, the preinst script have failed, rendering slapd unconfigured. > > > Meanwhile, apt has upgraded my libldap2 package. > > > Which debconf frontend to you use? I hit the same problem with the > > readline frontend which does not seem to use the default value if you > > just push enter but instead the empty value. Maybe the configuration > > script should just replace the empty value by the default value again. > > I really think this is a bug that needs to be dealt with from the debconf > side of things. Torsten, if you want to add a workaround to slapd, that > should be ok, but the real bug appears to be that the readline frontend is > somehow defaulting to an empty string for text values (although, not in my > testing here...). It may be that slapd is one of the more severely affected > packages, but I'm sure it's not the only place this causes problems. The bug is in slapd for including this text in its debconf template: "The default is /var/backups/slapd-VERSION" This comes under the heading of not referring to debconf UI in a template. Just as you don't know how debconf will choose to present a yes/no question and thus "say yes" constructions should be avoided, you don't know how or if a given debconf frontend handles default values[1]. Indeed a static template such as this one doesn't even know for sure what the default value _is_; it could have been overriden. The technical details of why debconf is not able to present a default value with the readline frontend, when the recommended literm-readline-gnu-perl is not installed, or with the teletype frontend, are already explained in bug #183970. I know of no better solution than what debconf already does, aside from perhaps refusing to run the readline frontend without literm-readline-gnu-perl (but this wouldn't fix the teletype frontend anyway). I'll reassign this back to slapd if it's agreeable. -- see shy jo [1] For example, the white mice debconf frontend[2] cannot offer a default value to the mice as they decide which tunnel to run down in the debconf maze. They have to choose right or left, and any debconf template telling them there is a default is obviously wrong. [2] Cheezy, I know, but I'm running out of useful hypothetical debconf frontends. Besides, doom is passe and HHGTTG is back in. signature.asc Description: Digital signature
Bug#307662: maradns stll needs to be fixed in sarge
reopen 307662 tag 307662 sarge thanks Since this security hole was fixed in a new upstream release that has several thousand lines of other changes since the version in testing, and since testing is frozen, I think we need to make a release of version 1.0.23 via t-p-u to get the fix into sarge. I checked the patch at http://www.maradns.org/download/patches/maradns-1.0.26-rekey_rng.patch and it applies to 1.0.23. I have not checked though to see if it really fixes the security hole when applied to that older version (or if it builds). Kai, can you do that and make an upload to testing-proposed-updates? -- see shy jo signature.asc Description: Digital signature
Bug#307968: not yet fixed in sarge
reopen 307968 tag 307968 sarge thanks This bug isn't fixed yet in sarge. I reviewed the changes in the new upstream to see if I could just accept it into sarge, and they're not *too* bad, but I'm concerned that accepting the unrelated active.read changes could introduce new bugs into sarge. Backporting the security fix and uploading via t-p-u seems quite doable. Just moving a couple of free()s, really. Would you/someone like to do that, or is there info about the active.read change that I should know the make a better decision? -- see shy jo signature.asc Description: Digital signature
Bug#307968: Processed: not yet fixed in sarge
Eh, seems I need to go to bed, since I a) reopened the wrong bug and b) shouldn't have sent the mail at all, since vorlon already accepted the new leafnode into sarge. Ignore me. -- see shy jo signature.asc Description: Digital signature
Bug#308234: upgrading from 2.1.23 failed because of not setting slapd/dump_database_destdir
Torsten Landschoff wrote: > > The bug is in slapd for including this text in its debconf template: > > > > "The default is /var/backups/slapd-VERSION" > > How is that a bug? In fact this can be helpful in case you changed the > value and later wonder what is was originally. Apart from that it is an > example how to use the VERSION tag. > > > This comes under the heading of not referring to debconf UI in a > > template. Just as you don't know how debconf will choose to present a > > yes/no question and thus "say yes" constructions should be avoided, you > > don't know how or if a given debconf frontend handles default values[1]. > > So you suggest removing that string and leaving the user completely in > the dark what to enter which is utterly needed especially if the debconf > frontend ignores the default value. There's nothing stopping you from including an example value in the template. Don't present it as the default value. > > Indeed a static template such as this one doesn't even know for sure > > what the default value _is_; it could have been overriden. > > By whom? As I am the maintainer of slapd I expect nobody else to change > that default. Preseeding? Derived distributions? > If you really think we should not mention the default value there that's > okay but on the other side I request that the behaviour of the readline > frontend is changed to at least present the user the current/default > value if the libterm-readline-gnu-perl package is not installed. And > make it very clear that hitting return means submitting an empty value. It does. It prompts as follows: Directory to dump databases: _ Barring some note that tells them there is a default, noone would expect hitting enter to result in some default value here[1]. The convention is that this means there is a default value: Directory to dump databases [/var/backups/slapd-VERSION]: _ Or this: Directory to dump databases: /var/backups/slapd-VERSION_ Debconf uses one or the other of these conventions when possible. Only experienced users use these frontends, and experienced users are expected to be aware of these conventions. > Perhaps it's even better (for compatibility with the readline-installed > case) to ask the user to explicitly input "" for the empty value. And then users need to learn a complicated set of rules for the edge cae where they want to enter a literal pair of double quotes. No thanks. > > I'll reassign this back to slapd if it's agreeable. > > In case you do - what is the right action of slapd here? I'd rather > avoid running each db_go in a loop which checks the input values. Why? Validating user input is the correct thing to do in all cases anyway. -- see shy jo [1] The only general exception to this rule I know of in all of unix/Debian is bootloaders. signature.asc Description: Digital signature
Bug#307989: backup broken
Hmm, very weird thing going on. Here's a debconf protocol dump from when I hit at the mirror/http/mirror question, to when I see the same question asked again. 30 backup GET mirror/http/countries 0 US SET mirror/country US 0 value set GO 30 backup GET mirror/country 0 US SET mirror/http/countries US 0 value set FGET mirror/country seen 0 false FSET mirror/http/ountries seen false 0 false INPUT high mirror/http/countries 0 question will be asked GO Now, despite what the protocol says, it does *not* ask this question, and cdebconf continues on with no pause. I'm leaving out the timestamps from the log, but the next line occurs the same second. 0 ok GET mirror/http/countries 0 US SET mirror/country US 0 value set GO 0 ok GET mirror/country 0 US SUBST mirror/http/mirror mirrors 0 INPUT high mirror/http/mirror 0 question will be asked GO And here it's displaying the mirror/http/mirror. So the reason the go back fails is because cdebconf thinks it asks this other mirror/http/countries question, and behaves as if the user presses ok, but the question is not really displayed. -- see shy jo signature.asc Description: Digital signature
Bug#307989: backup broken
I tried running d-i with the cdebconf text frontend, and I see the same behavior there. I downgraded cdebconf to the version in sarge (built by hand with a munged version number), and still see the same problem. -- see shy jo signature.asc Description: Digital signature
Bug#307989: backup broken
Christian Perrier wrote: > Has this been checked on former version? IIRC, the code itself hasn't > been changed by recent changes. I put in the sarge version and it works. I see the choose-mirror country list and backup from it or from the mirror list works. The problem seems to be some change to choose-mirror's templates has made cdebconf refuse to display the country list. -- see shy jo signature.asc Description: Digital signature
Bug#308550: depends on experimentals's libc6
Package: whiptail Version: 0.51.6-22 Severity: critical [EMAIL PROTECTED]:~>sudo apt-get install whiptail Reading Package Lists... Done Building Dependency Tree... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. Since you only requested a single operation it is extremely likely that the package is simply not installable and a bug report against that package should be filed. The following information may help to resolve the situation: The following packages have unmet dependencies: whiptail: Depends: libc6 (>= 2.3.5-1) but 2.3.2.ds1-21 is to be installed Depends: libnewt0.51 (= 0.51.6-22) but 0.51.6-21 is to be installed E: Broken packages zsh: exit 100 sudo apt-get install whiptail [EMAIL PROTECTED]:~>apt-cache policy libc6 libc6: Installed: 2.3.2.ds1-21 Candidate: 2.3.2.ds1-21 Version Table: 2.3.5-1 0 1 http://http.us.debian.org ../project/experimental/main Packages *** 2.3.2.ds1-21 0 500 http://http.us.debian.org unstable/main Packages 100 /var/lib/dpkg/status -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.4.27 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages whiptail depends on: ii libc6 2.3.2.ds1-21 GNU C Library: Shared libraries an ii libnewt0.51 0.51.6-21Not Erik's Windowing Toolkit - tex ii libpopt01.7-5lib for parsing cmdline parameters ii slang1a-utf81.4.9dbs-8 The S-Lang programming library wit -- no debconf information -- see shy jo signature.asc Description: Digital signature
Bug#308558: needs to conflict with old version of enigma-data
Package: enigma Version: 0.81.1-2 Severity: normal [EMAIL PROTECTED]:~>sudo apt-get install enigma Reading Package Lists... Done Building Dependency Tree... Done The following packages will be upgraded: enigma 1 upgraded, 0 newly installed, 0 to remove and 84 not upgraded. Need to get 0B/1432kB of archives. After unpacking 3150kB of additional disk space will be used. Reading changelogs... Done (Reading database ... 166263 files and directories currently installed.) Preparing to replace enigma 0.81.1-2 (using .../enigma_0.91-2_i386.deb) ... Unpacking replacement enigma ... dpkg: error processing /var/cache/apt/archives/enigma_0.91-2_i386.deb (--unpack): trying to overwrite `/usr/share/doc/enigma/README', which is also in package enigma-data dpkg-deb: subprocess paste killed by signal (Broken pipe) Errors were encountered while processing: /var/cache/apt/archives/enigma_0.91-2_i386.deb E: Sub-process /usr/bin/dpkg returned an error code (1) zsh: exit 100 sudo apt-get install enigma If I install enigma-data at the same time, it's ok. -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.4.27 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages enigma depends on: ii enigma-data 0.81.1-2 Data file for the game enigma ii libc6 2.3.2.ds1-21 GNU C Library: Shared libraries an ii libgcc1 1:3.4.3-13 GCC support library ii liblua40 4.0-13 Main interpreter library for the L ii liblualib40 4.0-13 Extension library for the Lua 4.0 ii libsdl-image1 1.2.4-1image loading library for Simple D ii libsdl-mixer1 1.2.6-1mixer library for Simple DirectMed ii libsdl1.2debi 1.2.7+1.2.8cvs20041007-4.1 Simple DirectMedia Layer ii libstdc++51:3.3.6-3.0.1 The GNU Standard C++ Library v3 ii libtolua0 4.0a-3 Tool to integrate C/C++ code with ii libzipios++0c 0.1.5.9+cvs.2004.02.07-3 a small C++ library for reading zi ii zlib1g1:1.2.2-4 compression library - runtime -- no debconf information -- see shy jo signature.asc Description: Digital signature
Bug#308620: pair of security holes
Package: mozilla-firefox Version: 1.0.3-2 Severity: grave Tags: security I'm sure you already know of these, but for the record, firefox is vulnerale to a pair of new security holes: CAN-2005-1477 The install function in Firefox 1.0.3 allows remote web sites on the browser's whitelist, such as update.mozilla.org or addon.mozilla.org, to execute arbitrary Javascript with chrome privileges, leading to arbitrary code execution on the system when combined with vulnerabilities such as CAN-2005-1476, as demonstrated using a javascript: URL as the package icon and a cross-site scripting (XSS) attack on a vulnerable whitelist site. CAN-2005-1476 Firefox 1.0.3 allows remote attackers to execute arbitrary Javascript in other domains by using an IFRAME and causing the browser to navigate to a previous javascript: URL, which can lead to arbitrary code execution when combined with CAN-2005-1477. -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.4.27 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages mozilla-firefox depends on: ii debianutils 2.13.2 Miscellaneous utilities specific t ii fontconfig 2.3.2-1 generic font configuration library ii libatk1.0-0 1.8.0-4 The ATK accessibility toolkit ii libc62.3.2.ds1-21GNU C Library: Shared libraries an ii libfontconfig1 2.3.2-1 generic font configuration library ii libfreetype6 2.1.7-2.4 FreeType 2 font engine, shared lib ii libgcc1 1:3.4.3-13 GCC support library ii libglib2.0-0 2.6.4-1 The GLib library of C routines ii libgtk2.0-0 2.6.4-1 The GTK+ graphical user interface ii libidl0 0.8.5-1 library for parsing CORBA IDL file ii libjpeg626b-10 The Independent JPEG Group's JPEG ii libkrb53 1.3.6-3 MIT Kerberos runtime libraries ii libpango1.0-01.8.1-1 Layout and rendering of internatio ii libpng12-0 1.2.8rel-1 PNG library - runtime ii libstdc++5 1:3.3.6-3.0.1 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 libxft2 2.1.7-1 FreeType-based font drawing librar ii libxp6 4.3.0.dfsg.1-12.0.1 X Window System printing extension ii libxt6 4.3.0.dfsg.1-12.0.1 X Toolkit Intrinsics ii psmisc 21.6-1 Utilities that use the proc filesy ii xlibs4.3.0.dfsg.1-12 X Keyboard Extension (XKB) configu ii zlib1g 1:1.2.2-4 compression library - runtime -- no debconf information -- see shy jo signature.asc Description: Digital signature
Bug#308620: pair of security holes
Eric Dorland wrote: > Well aware. Of course Mozilla's silly security policies prevent me > from viewing the bug's making a release before MoFo does. But as soon > as 1.0.4 is released I'll have it packaged in short order. BTW, do you know if these only impact firefox, or do they also affect mozilla? -- see shy jo signature.asc Description: Digital signature
Bug#308630: locales settings also screwed up
Eduard Bloch wrote: > I have set the root passwort trough a serial console now and tried to > configure the system manualy. However, as one of the first packages, > locales has failed to install: > > en.ISO-8859-1...cannot open locale definition file `en': No such file or > directory I'm seeing multiple hints in your bug report that you did not get a complete debian base system installed. The above indicates that something is badly broken in the locales package; it seems locale-gen cannot find the locale definition files for english. > debconf: (TERM is not set, so the dialog frontend is not usable.) And the only reasons I can think of why you'd not get a TERM when you sshed in are 1) sshing w/o a teletype or 2) broken terminfo.. -- see shy jo signature.asc Description: Digital signature
Bug#308722: Failed network install at "Install base system" step
Andrew Laughton wrote: > Package: installation-reports > Version:netinst CD image, with Debian base i386 version > [23 Mar 2005] Debian-Installer release candidate 3 > > When attempting to install from the above CD I got as far as > "Validating Libcomerr2" before it came up with an error message saying > "Debootstap error Couldn't download libcomerr2" > > I went back to main menu and tried "Install the base system" again. > got error message > "Cannot install Debian > No Installable CD-rom was found and no valid mirror was configured" > > I tried changing my country from Australia to United States, but I got the > same error message. > > There appeared to be no network traffic during the last "Install base system" > attempts. > I did not check network traffic on the first attempt. You said you used the netinst CD image. If it's the 110 mb iso, then you should not expect much network traffic during the initial install, as this CD contains the whole debian base system and you only need the network to install other stuff, after the base installation. It sounds like it may be having trouble reading some files from your CD. There is a menu item available after it fails that you can use to try to verify the CD contents, or you could try burning a new CD, preferably using different CD media. If on the other hand you're not really using the netinst CD image, but the businesscard image, then it could indeed be a network problem. -- see shy jo signature.asc Description: Digital signature
Bug#308808: FWD: Re: Mail::Mbox::MessageParser test failures
- Forwarded message from David Coppit <[EMAIL PROTECTED]> - From: David Coppit <[EMAIL PROTECTED]> Date: Wed, 6 Apr 2005 23:38:21 -0400 (EDT) To: Joey Hess <[EMAIL PROTECTED]> Subject: Re: Mail::Mbox::MessageParser test failures On Wed, 6 Apr 2005, Joey Hess wrote: >I'm seeing many new test suite failures with version 1.3000 of >Mail::Mbox::MessageParser: Thanks as always. I'm heading out of town, and will try to take a look at this and your other email this weekend. David _ David Coppit [EMAIL PROTECTED] The College of William and Maryhttp://coppit.org/ "Government big enough to supply everything you need is big enough to take everything you have ... The course of history shows that as a government grows, liberty decreases." -- Thomas Jefferson - End forwarded message - -- see shy jo signature.asc Description: Digital signature
Bug#308808: libmail-mbox-messageparser-perl: Please upgrade to newer upstream which fixes infinite loop
Olivier Cappe wrote: > Current version of this package has a severe bug which may cause infite > loops and render the grepmail package unusable: > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=293465 It's pointless to file a bug report to report the existence of a debian bug report. I am aware of bugs on my package and if I were not, I would not be aware of this report either. > Upstream sofware author has released a new version of the package (1.3000: > Mon Mar 14 2005) which he claims fixes the bug: > > > - Fixed a bug where emails with attachments would cause the mailbox parser > > to > >enter an infinite loop. > > http://search.cpan.org/src/DCOPPIT/Mail-Mbox-MessageParser-1.3000/README > > (see also his answer in > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=293465) Yes, except the new version fails many of its own test cases. Upstream has promised me a fix for that problem, I cannot release it as is. -- see shy jo signature.asc Description: Digital signature
Bug#308808: FWD: Mail::Mbox::MessageParser test failures
- Forwarded message from Joey Hess <[EMAIL PROTECTED]> - From: Joey Hess <[EMAIL PROTECTED]> Date: Wed, 6 Apr 2005 17:52:12 -0400 To: David Coppit <[EMAIL PROTECTED]> Subject: Mail::Mbox::MessageParser test failures User-Agent: Mutt/1.5.8i I'm seeing many new test suite failures with version 1.3000 of Mail::Mbox::MessageParser: [EMAIL PROTECTED]:~/Mail-Mbox-MessageParser-1.3000>make test PERL_DL_NONLAZY=1 /usr/bin/perl "-MExtUtils::Command::MM" "-e" "test_harness(0, 'inc', 'blib/lib', 'blib/arch')" t/bzip2.t t/endline.t t/filehandle_compressed.t t/filehandle_noncompressed.t t/filename_compressed.t t/filename_noncompressed.t t/grep.t t/gzip.t t/length.t t/line_number.t t/number.t t/offset.t t/prologue.t t/reset.t t/separators.t t/stdin_compressed.t t/stdin_uncompressed.t t/tzip.t t/bzip2...ok t/endline.ok t/filehandle_compressed...ok 4/16 skipped: tzip not available t/filehandle_noncompressedok t/filename_compressed.ok 1/4 skipped: tzip not available t/filename_noncompressed..ok t/grepok t/gzipok t/length..ok 23/30# Failed test (t/length.t at line 97) t/length..ok 26/30# Failed test (t/length.t at line 97) t/length..ok 29/30# Looks like you failed 2 tests of 30. t/length..dubious Test returned status 2 (wstat 512, 0x200) DIED. FAILED tests 24, 27 Failed 2/30 tests, 93.33% okay t/line_number.NOK 24# Failed test (t/line_number.t at line 97) t/line_number.NOK 27# Failed test (t/line_number.t at line 97) t/line_number.ok 29/30# Looks like you failed 2 tests of 30. t/line_number.dubious Test returned status 2 (wstat 512, 0x200) DIED. FAILED tests 24, 27 Failed 2/30 tests, 93.33% okay t/number..ok 23/30# Failed test (t/number.t at line 97) t/number..NOK 27# Failed test (t/number.t at line 97) t/number..ok 29/30# Looks like you failed 2 tests of 30. t/number..dubious Test returned status 2 (wstat 512, 0x200) DIED. FAILED tests 24, 27 Failed 2/30 tests, 93.33% okay t/offset..NOK 24# Failed test (t/offset.t at line 97) t/offset..ok 26/30# Failed test (t/offset.t at line 97) t/offset..ok 30/30# Looks like you failed 2 tests of 30. t/offset..dubious Test returned status 2 (wstat 512, 0x200) DIED. FAILED tests 24, 27 Failed 2/30 tests, 93.33% okay t/prologueok 23/33# Failed test (t/prologue.t at line 85) t/prologueok 26/33# Failed test (t/prologue.t at line 85) t/prologueok 33/33# Looks like you failed 2 tests of 33. t/prologuedubious Test returned status 2 (wstat 512, 0x200) DIED. FAILED tests 24, 27 Failed 2/33 tests, 93.94% okay t/reset...NOK 45# Failed test (t/reset.t at line 135) t/reset...NOK 48# Failed test (t/reset.t at line 201) t/reset...NOK 51# Failed test (t/reset.t at line 135) t/reset...NOK 54# Failed test (t/reset.t at line 201) t/reset...ok 60/60# Looks like you failed 4 tests of 60. t/reset...dubious Test returned status 4 (wstat 1024, 0x400) DIED. FAILED tests 45, 48, 51, 54 Failed 4/60 tests, 93.33% okay t/separators..ok t/stdin_compressedok 1/4 skipped: tzip not available t/stdin_uncompressed..ok t/tzipok 1/1 skipped: tzip not available Failed Test Stat Wstat Total Fail Failed List of Failed --- t/length.t 2 512302 6.67% 24 27 t/line_number.t2 512302 6.67% 24 27 t/number.t
Bug#308824: tight versioned dependencies between locales and glibc cause problems
Package: glibc Severity: normal Every time a new glibc is uploaded that has a locales with a dependency on exactly that version of glibc, installs of unstable on every architecture are broken until the autobuilder catches up and builds glibc. Installs fail with errors like these: locales: Depends: glibc-2.3.2.ds1-22 which is a virtual package. (Currently failing like this on sparc, alpha, hppa, ...) This is because locales is arch all so it is available in unstable immediatly on all architectures, while the virtual package is provided by an arch any package which has to autobuild. This is really annoying if you're working on the debian installation on any of these architectures, since a new glibc upload can stall any useful testing of unstable installs for days at a time. Can you please try to find a solution to this? Making locales arch any would be one solution. -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.4.27 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) -- see shy jo signature.asc Description: Digital signature
Bug#308630: locales settings also screwed up
Eduard Bloch wrote: > Ehm. AFAICS it is broken because "en" actually IS an invalid entry and > it has been seet by d-i. Try to pass it to locale-gen and it will > complain on a normal Sid system. Ok, you're right. It looks like Frans has explained how this happened. > > > debconf: (TERM is not set, so the dialog frontend is not usable.) > > > > And the only reasons I can think of why you'd not get a TERM when you > > sshed in are 1) sshing w/o a teletype or 2) broken terminfo.. > > 1) What is a teletype in this context? Any documentation? "ssh hostname command" without -t. [EMAIL PROTECTED]:~>ssh localhost echo \$TERM [EMAIL PROTECTED]:~>ssh localhost -t echo \$TERM xterm -- see shy jo signature.asc Description: Digital signature
Bug#308747: netboot.tar.gz doesn't boot a Soekris 4801 via tftp and serial console
Lee Azzarello wrote: > Package: debian-installer > Version: RC3 > > This archive: > http://ftp.debian.org/debian/dists/testing/main/installer-i386/rc3/images/netboot/netboot.tar.gz > fails to boot a Soekris 4801 SBC. Info on the hardware here: > http://www.soekris.com/ > > The symptom is a serial console which has random characters streaming across > the screen, regardless of baud rate selected. It should display the > bootloader screen when set to 9600 baud. > > The problem was defined and patched by [EMAIL PROTECTED] > A replacement pxelinux.0 file was made available on his web page here: > http://centerclick.org/net4801/pxelinux/ > > When replacing the pxelinux.0 file with this one, the bootloader and > installer > screen appears as normal. Is there a reason you didn't try the pxelinux.cfg.serial-9600/default file contained in that same tarball? Aside from the horrible and probably entirely missing documentation of it, that is.. -- see shy jo signature.asc Description: Digital signature
Bug#308722: FWD: Re: Bug#308722: Failed network install at "Install base system" step
- Forwarded message from Andrew Laughton <[EMAIL PROTECTED]> - From: Andrew Laughton <[EMAIL PROTECTED]> Date: Fri, 13 May 2005 10:22:22 +1000 To: Joey Hess <[EMAIL PROTECTED]> Subject: Re: Bug#308722: Failed network install at "Install base system" step User-Agent: KMail/1.7.2 Hi Joey I am using the 110 MB iso, and the CD passed both the verify when burning test and the CD test part of the install options. However the CD later failed so I might be having hardware problems. I need to follow this up when I have more time. Thanks anyway. Andrew. On Thu, 12 May 2005 1:58, you wrote: > Andrew Laughton wrote: > > Package:installation-reports > > Version:netinst CD image, with Debian base i386 version > > [23 Mar 2005] Debian-Installer release candidate 3 > > > > When attempting to install from the above CD I got as far as > > "Validating Libcomerr2" before it came up with an error message saying > > "Debootstap error Couldn't download libcomerr2" > > > > I went back to main menu and tried "Install the base system" again. > > got error message > > "Cannot install Debian > > No Installable CD-rom was found and no valid mirror was configured" > > > > I tried changing my country from Australia to United States, but I got > > the same error message. > > > > There appeared to be no network traffic during the last "Install base > > system" attempts. > > I did not check network traffic on the first attempt. > > You said you used the netinst CD image. If it's the 110 mb iso, then you > should not expect much network traffic during the initial install, as > this CD contains the whole debian base system and you only need the > network to install other stuff, after the base installation. > > It sounds like it may be having trouble reading some files from your CD. > There is a menu item available after it fails that you can use to try to > verify the CD contents, or you could try burning a new CD, preferably > using different CD media. > > If on the other hand you're not really using the netinst CD image, but > the businesscard image, then it could indeed be a network problem. - End forwarded message - -- see shy jo signature.asc Description: Digital signature
Bug#308234: upgrading from 2.1.23 failed because of not setting slapd/dump_database_destdir
Torsten Landschoff wrote: > a) It does neither present the default nor the current value. > b) It is /not/ clear that hitting enter means the empty value. With > alone this information (the above one line) that's what I would have > expected. But I was used to debconf using the default value when hitting > enter even with the readline interface. > > > Barring some note that tells them there is a default, noone would expect > > hitting enter to result in some default value here[1]. The convention is > > I can proof the opposite by counterexample: I would expect it. Not on > the grounds of that output but by using debconf with readline frontend > before and just hitting enter when I did not care about a particular > setting. > > > Or this: > > > > Directory to dump databases: /var/backups/slapd-VERSION_ > > Yep, I was used that from older versions of the debconf readline > interface. As a matter of fact I seldom read the full description of and > option and decide by reading 3-4 lines that the default will be okay and > hit enter. There's nothing older about it; that's the behavior of the readline interface in the gnu readline perl binding is installed -- see shy jo signature.asc Description: Digital signature
Bug#308894: add debconf questions for naming network interfaces
Christian Perrier wrote: > Not sure whether this would be better reassigned to netcfg or > ddetect. Joey? ddetect. We need to use nameif for interfaces anyway because the kernel enforces no guaranteed names on interfaces except module load order, which is too fragile to rely on and the cause of constant bugs as d-i and debian get out of sync. Ubuntu already has a patch for at least renaming all interfaces so the names are static. Not sure about adding a question about interface names; netcfg already uses link information to decide which one of multiple interfaces to use and I'm not convinced renamingthe interfaces warrants another question (in high priority anyway). -- see shy jo signature.asc Description: Digital signature
Bug#308534: review
I took a look at sponsoring this, but since I am interested in getting security fixes into sarge, I did it with my release assistant hat on to see if the changes in this new upstream release (and in unreleased version 1.5.0-2) are acceptable for sarge. I'm afraid they are probably not, there are over 8000 lines of changes in here, large changes to the Debian part of the setup, and the only reason to let it into sarge is for a security hole for which we have no details. I have still sponsored the package for you, but I'm afraid the only way to get the security fix into sarge will be to get details about it and either convince a member of the release team that it's worth the work and risk to approve this massive diff, or better, backport the security fix alone and upload it via t-p-u. -- see shy jo signature.asc Description: Digital signature
Bug#309048: several security issues on 64 largemem systems (CAN-2005-1515, CAN-2005-1514, CAN-2005-1513O
Package: qmail-src Severity: important Tags: security Apparently qmail has some security bugs on 64 bit systems with large amounts (> 4 gb) of memory: http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-1515 http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-1514 http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-1513 -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.4.27 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages qmail-src depends on: ii debconf 1.4.49 Debian configuration management sy ii dpkg-dev 1.10.27 Package building tools for Debian ii fakeroot 1.2.13 Gives a fake root environment ii gcc 4:3.3.5-3 The GNU C compiler ii groff-base 1.18.1.1-7 GNU troff text-formatting system ( ii make 3.80-9 The GNU version of the "make" util ii patch2.5.9-2 Apply a diff file to an original ii sudo 1.6.8p7-1.1 Provide limited super user privile -- see shy jo signature.asc Description: Digital signature
Bug#309049: CAN-2005-1194 (Stack-based buffer overflow in the ieee_putascii function)
Package: nasm Version: 0.98.38-1.1 Severity: important Tags: security red hat found another security hole in nasm. See https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=152962 I've verified that the vsprintf call is in the debian package, but I've not checked to see if the buffer overflow is actually exploitable. -- see shy jo signature.asc Description: Digital signature
Bug#309333:
[EMAIL PROTECTED] wrote: > The system didn't boot. Always hangs after telling that the system is posix > compatible. > Don't know why. When using linux26 the system crashes with > apic/kernel-errors. Have you tried booting with noapic nolapic? -- see shy jo signature.asc Description: Digital signature
Bug#308875: patch does not work
Djoume's patch is no good since it still leaves open a race between checking whether the file exists and writing to it. I also thing the severity of this bug is too low, although I'm not sure if it qualifies as RC. It should at least be severity important. -- see shy jo signature.asc Description: Digital signature
Bug#305215: debconf: strange warnings during upgrade
Frans Pop wrote: > Package: debconf > Version: 1.4.30.13 > > On a new installation from RC3 netinst, debconf is currently upgraded when > tasksel is run (no tasks selected) from v1.4.30.11 to v1.4.30.13. > > During the upgrade I see the following messages flash by: > Setting up debconf (1.4.30.13) > 'import site' failed; use -v for traceback > 'import site' failed; use -v for traceback > > There are no errors; package installation finishes successfully. > I have reproduced this during a second installation. I guess this is some python thing from the generic dh_python boilerplate in the postinst script. -- see shy jo signature.asc Description: Digital signature
Bug#305265: acpi don't give rate information
Nico Golde wrote: > Version: 0.09-1 > Severity: normal > Hi, > If I use the acpi tool sometimes I only get this: > Battery 1: charged, 100%, rate information unavailable. > > Why are these information unavailable? > If I use yacpi at the same time I get this: Rate information reflects how fast a battery is charging. If you're fully charged, that does not apply. > BAT0 Capacity [|||] 100% - AC > status: on > Battery Status: charging > Remaining charge time: 00:00 h > cpu frequency: 600/1500 MHz > cpu governor: userspace > Temperature: 45 degrees C > > Why is acpi unable to fetch this? I don't see anything that resembles "rate information" in the above. -- see shy jo signature.asc Description: Digital signature
Bug#305372: TOCTOU file-permissions vulnerability (CAN-2005-1111)
Package: cpio Version: 2.5-1.2 Severity: normal Tags: security According to the advisory at http://marc.theaimsgroup.com/?l=bugtraq&m=111342664116120&w=2 If a malicious local user has write access to a directory in which a target user is using cpio to extract or compress a file to then a TOCTOU bug can be exploited to change the permission of any file belonging to that user. On decompressing cpio copies the permissions from the compressed cpio file to the uncompressed file. However there is a gap between the uncompressed file being written (and it's file handler being close) and the permissions of the file being changed. During this gap a malicious user can remove the decompressed file and replace it with a hard-link to another file belonging to the user. cpio will then change the permissions on the hard-linked file to be the same as that of the cpio file. The vulnerable line of code can be found on line 581 of the file copyin.c. cpio also use's chmod in a number of other places which may also be vulnerable to exploitation. -- see shy jo signature.asc Description: Digital signature
Bug#305592: alien: Breaks when working with broken packages
Javier Fernández-Sanguino Peña wrote: > I think the current status is pretty dangerous, since some weird commands > might get executed and there seems to be a chance to create a malformed > package that will end up running arbitary code on behalf of the user. > Although I have not investigated that posibility. (that's why I'm not > setting this bug at a higher severity and tagging it security, although I'm > tempted to, see the attached script. Where is the problimatic rpm in question? I'm not 100% sure, but your patch seems to be mostly treating symptoms and not underlying, possily exploitable problems. -- see shy jo signature.asc Description: Digital signature
Bug#280386: long pauses while editing large html files
Stefano Zacchiroli wrote: > I see no attachment in the bug page on the BTS. Did you forget it or was > it lost from some other reason? > > Could you please provide us with the attachment so that we can > investigate the bug report a bit more? I don't know where the attachment went, here's a different one. For this one, follow the instructions on line 622. BTW, I also see the same effect, though with a lesser hang, on smaller html files. -- see shy jo munble.html.gz Description: Binary data signature.asc Description: Digital signature
Bug#305534: rss2email: no README provided
Charles Fry wrote: > It would be very helpful to have some type of documentation (perhaps > README.Debian) that explained how to go about using rss2email. Currently > the only documentation I could find was the r2e manpage, but there is no > way to know that that is the manpage to read without examining the > package contents. You have a long hard uphill battle if you want every command in every package to be mentioned in /usr/share/doc. > As far as I can tell, most of the DESCRIPTION part of the r2e manpage is > actually information that really belongs in /usr/share/doc/rss2email. /usr/share/doc is a dumping ground for documentation that doesn't fit anywhere else, so no, the man page (which I wrote) really doesn't belong there. I'll add a very brief README.Debian with a pointer in the next release, although I consider it a wasted inode. -- see shy jo signature.asc Description: Digital signature
Bug#305599: debian-installer: Unable to resolve domain names when DHCP not used
Brian Frank wrote: > After entering IP, gateway, etc. for NIC upon network install, domain > names (e.g. ftp.debian.org) are unable to be resolved by apt to > download extra packages. If IP adresses for apt repositories are > added to souces.list manually then the installation proceeds. The obvious answer is that you have misconfigured your dns server somehow. Send copies of /etc/resolv.conf and /var/log/debian-installer/syslog to this bug report. -- see shy jo signature.asc Description: Digital signature
Bug#300815: still affects sarge
tag 300815 sarge reopen 300815 thanks Unfortunatly, the security hole still affects sarge, and worse, it doesn't look like the new upstream version will make it in via testing anytime soon. An upload of the old version via t-p-u may be the best way to get this fixed in sarge. -- see shy jo signature.asc Description: Digital signature
Bug#292792: second nmu
I had to make a second NMU because it turned out the patch from the DSA
did not fix all the securtity problems. The attached patch needs the
patch from my first NMU to be applied first.
--
see shy jo
diff -ur old/f2c-20020621/debian/changelog f2c-20020621/debian/changelog
--- old/f2c-20020621/debian/changelog 2005-04-21 12:37:58.0 -0400
+++ f2c-20020621/debian/changelog 2005-04-21 12:37:10.0 -0400
@@ -1,3 +1,13 @@
+f2c (20020621-3.2) unstable; urgency=HIGH
+
+ * NMU again for same security issues.
+ * Corrected the patch to create proper temporary files by not shadowing
+global scope variables with local scope ones. Thanks to Dan McMahill
+from NetBSD [src/sysdep.c, patches/patch.CAN-2005-0017.f2c,
+CAN-2005-0017]
+
+ -- Joey Hess <[EMAIL PROTECTED]> Thu, 21 Apr 2005 12:32:07 -0400
+
f2c (20020621-3.1) unstable; urgency=HIGH
* NMU for security issues. Closes: #292792
diff -ur old/f2c-20020621/src/sysdep.c f2c-20020621/src/sysdep.c
--- old/f2c-20020621/src/sysdep.c 2005-04-21 12:37:58.0 -0400
+++ f2c-20020621/src/sysdep.c 2005-04-21 12:36:03.0 -0400
@@ -97,7 +97,9 @@
if (!debugflag) {
unlink(c_functions);
unlink(initfname);
+ unlink(initbname);
unlink(p1_file);
+ unlink(p1_bakfile);
unlink(sortfname);
unlink(blkdfname);
if (cdelete && coutput)
@@ -121,13 +123,13 @@
p1_bakfile = p1_file + k;
sortfname = p1_bakfile + k;
#else
- char c_functions[] = TMPDIR "/f2c_func_XX";
- char initfname[] = TMPDIR "/f2c_rc_XX";
- char initbname[] = TMPDIR "/f2c_rc.b_XX";
- char blkdfname[] = TMPDIR "/f2c_blkd_XX";
- char p1_file[] = TMPDIR "/f2c_p1f_XX";
- char p1_bakfile[] = TMPDIR "/f2c_p1fb_XX";
- char sortfname[] = TMPDIR "/f2c_sort_XX";
+ sprintf(c_functions, "%s/f2c_func_XX", tmpdir);
+ sprintf(initfname, "%s/f2c_rc_XX", tmpdir);
+ sprintf(initbname, "%s/f2c_rc.b_XX", tmpdir);
+ sprintf(blkdfname, "%s/f2c_blkd_XX", tmpdir);
+ sprintf(p1_file, "%s/f2c_p1f_XX", tmpdir);
+ sprintf(p1_bakfile, "%s/f2c_p1fb_XX", tmpdir);
+ sprintf(sortfname, "%s/f2c_sort_XX", tmpdir);
#endif
{
#ifdef MSDOS
signature.asc
Description: Digital signature
Bug#304525: fixed in new upstream
IlohaMail 0.8.14-RC3 is primarily a security update. A number of XSS vulnerabilities have been patched, a filter to remove potentially malicious code from HTML messages has been added, configuration files have been renamed to prevent content exposure, and documentation has been There's also a 0.9-20050415 with the same fixes. I haven't checked to see if they fully fixed the HTML message display code to strip all the kinds of things mentioned in this bug report. -- see shy jo signature.asc Description: Digital signature
Bug#305971: f2c: segfaults on m68k
Steve Langasek wrote:
> This looks like a pretty serious regression in the latest security NMU of
> f2c. The code now reads:
>
> char *c_functions = "c_functions";
> char *coutput = "c_output";
> char *initfname = "raw_data";
> char *initbname = "raw_data.b";
> char *blkdfname = "block_data";
> char *p1_file = "p1_file";
> char *p1_bakfile= "p1_file.BAK";
> char *sortfname = "init_file";
> char *proto_fname = "proto_file";
>
> [...]
>
> void
> set_tmp_names(Void)
> {
> #ifdef MSDOS
> [...]
> #else
> sprintf(c_functions, "%s/f2c_func_XX", tmpdir);
> sprintf(initfname, "%s/f2c_rc_XX", tmpdir);
> sprintf(initbname, "%s/f2c_rc.b_XX", tmpdir);
> sprintf(blkdfname, "%s/f2c_blkd_XX", tmpdir);
> sprintf(p1_file, "%s/f2c_p1f_XX", tmpdir);
> sprintf(p1_bakfile, "%s/f2c_p1fb_XX", tmpdir);
> sprintf(sortfname, "%s/f2c_sort_XX", tmpdir);
> #endif
> [...]
> }
>
> which is an obvious overflow condition.
>
> AFAICT, the initialization of these strings is completely inappropriate, and
> should be replaced with a sensibly-sized buffer, followed by the use of
> snprintf() instead of sprintf(). Would you (or Dan McMahill, if that's
> where this patch came from) care to fix this up, or would you like me to
> prepare a patch?
I have to confess I took this patch direct from DSA-661-2 and did not
really look at it in detail so this initialisation problem escaped me.
Here's the tricky bit -- in the stable version, the code is almost
exactly the same, except the block of code at the top of set_tmp_names
is not in this ifdef:
#ifdef MSDOS
int k;
if (debugflag == 1)
return;
k = strlen(tmpdir) + 24;
c_functions = (char *)ckalloc(7*k);
initfname = c_functions + k;
initbname = initfname + k;
blkdfname = initbname + k;
p1_file = blkdfname + k;
p1_bakfile = p1_file + k;
sortfname = p1_bakfile + k;
#else
So I think the original patch and the stable version are ok. Steve's
patch also looks ok, but I haven't checked the possible lengths
closely -- Steve's patch does make an assumption about the length of
tmpdir that the above code does not make.
--
see shy jo
signature.asc
Description: Digital signature
Bug#306134: /usr/share/debconf/confmodule usage of echo to communicate with debconf breaks values containing \\
Andreas Metzler wrote:
> --
> foo='\\Nblah' ; echo "$foo
> \Nblah
> --
>
> Please note the missing second backslash.
>
> /usr/share/debconf/confmodule uses "echo" to pass values to debconf,
> mangling \\ by this. I've stumbled upon this in exim4, with this code
> used for debugging:
>
> printf '%s\n' "Original ${dc_other_hostnames}" | logger
> db_set exim4/dc_other_hostnames "${dc_other_hostnames}"
> db_get exim4/dc_other_hostnames
> printf '%s\n' "Debconf-db ${RET}" | logger
>
> This results in this output in syslog:
> Apr 24 14:38:58 argenau logger: Original downhill.aus.cc:\\Nbar\\N
> Apr 24 14:38:58 argenau logger: Debconf-db downhill.aus.cc:\Nbar\N
>
> To test my guesswork I verified that this crude change indeed fixed
> the problem:
Unfortunatly I probably won't be able to fix this for sarge. The printf
fix looks ok, but there's always the potential for some kind of new
breakage and I want to avoid that.
--
see shy jo
signature.asc
Description: Digital signature
Bug#306745: base-config: bad English messages in Debconf templates
Dafydd Harries wrote: > > Why would that be the case? People regularly call it 'apt' in writing, > > rather than 'APT', and I believe the 'Advanced Package Tool' is a > > backronym, too. > > Well, since it is an acronym, I belive all capitals is correct. backronym != acronym. Just because my name is Jets Over Every Year, I don't spell it in all caps. -- see shy jo signature.asc Description: Digital signature
Bug#306880: CAN-2005-0753: buffer overflow and memory access validation
Geoff Crompton wrote: > Package: cvs > Version: 1:1.12.9-11 > Severity: important > > As reported at http://www.securityfocus.com/bid/13217 there are > "Unspecified Buffer Overflow And Memory Access Vulnerabilities". > Not too many details available at the moment. The above web page says: > > > CVS is prone to unspecified buffer overflow, memory access > > vulnerabilities, and a NULL pointer dereference denial of service. > > It is conjectured that the issues may be leveraged by a remote > > authenticated user to disclose regions of the CVS process memory, and > > to corrupt CVS process memory. The two issues combined may lead to a > > remote attacker reliably executing arbitrary code in the context of > > the vulnerable process, although this is not confirmed. > > This BID will be updated as soon as further information is made > > available. > > It also lists versions of cvs from 1.11.5 to 1.11.19 and 1.12.1 to > 1.12.11 as vulnerable. This may mean that woody (1.11.1) is clean. > Fedora, FreeBSD, Gentoo, and others have released advisories. I think > Gentoo have patches with their bug reports, but I'm not sure that > they've got all the patches, or what version they patch against. This is fixed in unstable in cvs 1.12.9-13. -- see shy jo signature.asc Description: Digital signature
Bug#307132: CAN-2005-1345 (Unexpected access control results on configuration errors)
Package: squid Version: 2.5.9 Severity: normal Tags: security squid 2.5.9 is vulnerable to a minor security hole, as described at http://www.squid-cache.org/Versions/v2/2.5/bugs/#squid-2.5.STABLE9-acl_error: synopsisOn configuration errors involving wrongly defined or missing acls the http_access results may be different than expected, possibly allowing more access than intended. This patch makes such configuration errors a fatal error, preventing the service from starting until the access control configuration errors have been corrected. severityCosmetic Security date2005-03-04 22:48 bugzilla#1255 versionsSquid-2.5 and earlier platforms All patch squid-2.5.STABLE9-acl_error.patch workaround Verify your configuration with "squid -k parse" and correct any errors reported before starting Squid. -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.4.27 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages squid depends on: ii adduser 3.63 Add and remove users and groups ii coreutils 5.2.1-2 The GNU core utilities ii debconf 1.4.48 Debian configuration management sy ii libc6 2.3.2.ds1-21 GNU C Library: Shared libraries an ii libldap22.1.30-6 OpenLDAP libraries ii libpam0g0.76-22 Pluggable Authentication Modules l ii logrotate 3.7-2Log rotation utility ii netbase 4.21 Basic TCP/IP networking system pn squid-common Not found. -- see shy jo signature.asc Description: Digital signature
Bug#307134: CAN-2005-1344 htdigest buffer overflow
Package: apache2 Severity: normal Tags: security I've verified that the htdigest from apache2 has the buffer overflow described at http://www.lucaercoli.it/advs/htdigest.txt I dont know of any exploit vectors, as noted it doiesn't work unless something passes user-supplied parameters to htdigest or its made suid. -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.4.27-2-686-smp Locale: LANG=, LC_CTYPE= (charmap=ANSI_X3.4-1968) -- see shy jo
Bug#303812: FWD: Re: Bug#303812: sarge floppy install report
- Forwarded message from Charles Kaufman <[EMAIL PROTECTED]> -
From: Charles Kaufman <[EMAIL PROTECTED]>
Date: Sat, 9 Apr 2005 23:42:48 -0400 (EDT)
To: Joey Hess <[EMAIL PROTECTED]>
Subject: Re: Bug#303812: sarge floppy install report
Reply-To: [EMAIL PROTECTED]
On Sat, 9 Apr 2005, Joey Hess wrote:
> Charles Kaufman wrote:
> > I installed using a 3Com pcmcia wired ethernet card. The first
> > stage install went fine. The reboot went fine except the
> > network connection failed. ('does not seem to be currently
> > connected'). I was then offered ppp as an option, but not dhcp.
> >
> > That is the install floppies found the network but the
> > installed system did not.
>
> What does the /etc/network/interfaces file of the installed system look
> like?
>
This is it:
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).
# The loopback network interface
auto lo
iface lo inet loopback
# The primary network interface
auto eth0
iface eth0 inet dhcp
(end)
When I boot the installed system there is no connection
and ifconfig shows only the loopback. As soon as I run
dhclient, the network becomes available and ifconfig
shows eth0.
Chuck Kaufman
[EMAIL PROTECTED]
- End forwarded message -
--
see shy jo
signature.asc
Description: Digital signature
Bug#311597: RFP: anyterm -- ssh java applet
Package: wnpp, mindterm Severity: wishlist * Package name: anyterm * URL : http://anyterm.org/ * License : GPL Description : ssh java applet This is a mindterm replacement, and assuming it is as good as it looks, the right thing to do would seem to be to make it replace the (unmaintainable) mindterm package in Debian. -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.4.27 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) -- see shy jo signature.asc Description: Digital signature
Bug#311597: RFP: anyterm -- ssh java applet
Joey Hess wrote: > Description : ssh java applet Correction, it does not use ssh (and it's javascript). Makes it less attractive, though it can be secured using https. -- see shy jo signature.asc Description: Digital signature
Bug#312604: automate README file to say final release are final, not devel versions
Package: debian-cd Version: 2.2.22 Severity: normal Debian 3.0 r0 shipped with a CD that claimed it was an unoffical beta release. Years later, Debian 3.1 r0a shipped with a CD that claimed it was an unoffical beta release. Since we don't learn from our mistakes or remember to muck about in READMEs at the very last minute of releases, how about turning that paragraph off if OFFICIAL="Official" in CONF.sh? -- see shy jo signature.asc Description: Digital signature
Bug#312680: RM: bugreporter-udeb -- RoM: obsolete; causes duplicate d-i menu entry
Package: ftp.debian.org Severity: normal bugreporter-udeb has been osolsted by the installation-report udeb. -- see shy jo signature.asc Description: Digital signature
Bug#312661: dh_python bug with -V argument
Josselin Mouette wrote: > You seem to misunderstand the purpose of the -V argument. All > site-packages directories are always scanned. The -V argument is here > when you are shipping private modules in /usr/lib/somepackage, to tell > dh_python that these modules are meant for a specific python version. > > You say you have a test case that fails, could you please explain what > is it doing? Something else must be wrong. Hmm, I had a debhelper upload queued for this but I obviously should have waited for Joss's input. I've canceled the upload pending clarification. -- see shy jo signature.asc Description: Digital signature
Bug#312701: nano needs libncursesw5
Package: debootstrap Version: 0.2.45-0.2 Severity: important Debootstrapping sid now fails because: dpkg: dependency problems prevent configuration of nano: nano depends on libncursesw5 (>= 5.4-1); however: Package libncursesw5 is not installed. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.4.27 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages debootstrap depends on: ii binutils2.15-6 The GNU assembler, linker and bina ii libc6 2.3.2.ds1-22 GNU C Library: Shared libraries an ii wget1.9.1-12 retrieves files from the web -- no debconf information -- see shy jo signature.asc Description: Digital signature
Bug#291723: anton, could you look at this?
Anton, as the maintainer of the cyrillic-desktop task, could you take a look at the bug and decide what to do? Sounds like we should add the kde stuff, and maybe also remove the support for the languages that have their own tasks? -- see shy jo signature.asc Description: Digital signature
Bug#299764: only affects French?
Is there some reason this bug only affects French installs, or is it more general? -- see shy jo signature.asc Description: Digital signature
Bug#312930: install26 should be linux26 or changed
[EMAIL PROTECTED] wrote: > The debian-installer daily cdrom boot image (20050608) for i386 has an > error in the boot loader instruction menu. > > The menu says to install using a 2.6 kernel, type "install26" when in > reality, no such image exists. > > Instead, the user must type "linux26" as in the older revisions of the > installer. One of these items should be corrected. I've been waiting for the CD build process to be switched to using the etch directories for just this reason for nearly a month now. -- see shy jo signature.asc Description: Digital signature
Bug#304712: [Fwd: Bug#304712: avaMail allows directory traversal in attachments (CAN-2005-1105)]
Well, what I read in the thread about this is that at least one other implementation of this API is adding the security check. If apps come to expect the check to be in the implementation, then they probably won't also check things themselves. -- see shy jo signature.asc Description: Digital signature
Bug#313078: RM: languagechooser countrychooser -- RoM: obsolete; cause duplicate d-i menu entried
Package: ftp.debian.org Severity: normal languagechooser and countrychooser have been obsoleted by localechooser -- see shy jo signature.asc Description: Digital signature
Bug#271258: fixed in localechooser
reopen 271258 reassign 271258 localechooser thanks Joey Hess wrote: > I understand that localechooser allows one to choose the C locale (in > expert mode). Hmm, it does, but it does not let you choose C. Reopening. -- see shy jo signature.asc Description: Digital signature
Bug#313301: xaos: I think I've run out of precision
[EMAIL PROTECTED] wrote: > (maxiter 65536) Interesting that's exactly 2^16. Did it stop working as soon as you increased it to that many interations? -- see shy jo signature.asc Description: Digital signature
Bug#313339: debhelper: dh_link doesn't create a relative link when lintian says it should
Andrew Pollock wrote: > I'm fiddling with dhcp3, and I changed the > > ln -s /sbin/dhclient3 $(DESTDIR)/sbin/dhclient > > invocation in debian/rules to > > dh_link sbin/dhclient3 sbin/dhclient > > however Lintian is still barfing about there being an absolute link when > it should be relative, which seems contrary to how the manpage for > dh_link says it should behave. Sorry, but I cannot reproduce this: [EMAIL PROTECTED]:~/src/debhelper>./dh_link -v sbin/dhclient3 sbin/dhclient install -d debian/debhelper/sbin rm -f debian/debhelper/sbin/dhclient ln -sf dhclient3 debian/debhelper/sbin/dhclient [EMAIL PROTECTED]:~/src/debhelper>ls -l debian/debhelper/sbin/dhclient lrwxrwxrwx 1 joey joey 9 Jun 13 11:18 debian/debhelper/sbin/dhclient -> dhclient3 -- see shy jo signature.asc Description: Digital signature
Bug#313342: dh_strip fix for shared library sym-links in *-dbg packages
Raphael Bossek wrote: > Creating -dbg packages using dh_strip --dbg-package= result in packages > where for shared libraries symbolic liks are missing. These sym-links > are missing for the case where the SONAME of the shared library does not > match the filename: > > SONAME libxerces-c.so.1.7 > FILE libxerces-c.so.1.7.0 > > In this case a symlink exists called (/usr/lib): > > SYMLINK libxerces-c.so.1.7 -> libxerces-c.so.1.7.0 > > It is mandatory to copy this sym-link to the -dbg package to. Please > apply this patch to make this step happen. Let me make sure I understand because your bug report is not very clear. These symlinks your referring to need to be in /usr/lib/debug so that gdb will find the debugging symbols to match the shared library? Can you give a real-life example please? -- see shy jo signature.asc Description: Digital signature
Bug#264384: note..
As I note in #299041, I'm of the opinion that all this gconf code does not belong in debhelper and would better be encapsulated in a helper script in gconf. Which would have made this transition easier, or at least possible for sarge too. -- see shy jo signature.asc Description: Digital signature
Bug#299041: packages using dh_gconf should not create files in /root
reassign 299041 gconf2 thanks After consideration, I've decided that debhelper will not reduce itself to messing around with temporary directories (and associated possibly security issues, etc) to isolate the junk that gconftool-2 writes to root's $HOME. This is a bug in gconftool-2; it needs to either -- a. Be fixed to not create all this stuff in root's $HOME when it's run from a postinst script, one way or another. Maybe a new command-line swith. Maybe not creating the junk in the first place. b. Offer some other way that debhelper can register gconf schemas without needing to worry about all this. Given the amount of nasty code debhelper currently inserts into postinst and postrm scripts to work around gconf's behavior, I actually favour 2. I think that a register-gconf-schema wrapper, which can take care of all athe messy details and that postinst scripts can just call, is the best solution. -- see shy jo signature.asc Description: Digital signature
Bug#249815: hmm..
Unfortunatly, I guess that changing this now could possible be a
behavior change that breaks any packages that might inaverdently depend
on the current behavior. So I'm leaning toward only enabling this in v5
compatability mode.
BTW, here's a copy of that patch, in case the link ever goes 404.
--
see shy jo
Make sure to fail if the glob fails, since it's really a bug to
continue as if nothing had happened.
--- dh_install 2004-01-16 04:47:14.0 +0100
+++ /usr/bin/dh_install 2005-02-16 17:23:37.916110572 +0100
@@ -138,6 +138,9 @@
if (! defined $dh{AUTODEST} && @$set > 1) {
$dest=pop @$set;
}
+if (!map { glob "$srcdir/$_" } @$set) {
+ error("missing files (@$set), aborting");
+}
# glob now, relative to srcdir
foreach my $src (map { glob "$srcdir/$_" } @$set) {
next if excludefile($src);
signature.asc
Description: Digital signature
Bug#240421: need more info
It's now over 1 year since I asked for more info on this bug. If I don't get a reply soon, I'll probaly close it. -- see shy jo signature.asc Description: Digital signature
Bug#222652: reassign to dpkg-dev
reassign 222652 dpkg-dev thanks and hope that's ok.. Well, of Branden's options, 1 seems like going behind dpkg-gencontrol's back and the wrong place to put code to remove dups; 2 complicates debhelper unnessarily; 3 seems like a good idea to me, but I dunno how the dpkg developers will feel about it; 4 seems reasonable too. While debhelper might be the highest profile example of this, this is a problem that any tool that generates dependencies during the build process can run into. So fixing it in dpkg (or declaring it a non-problem) seems much better to me than fixing it in debhelper. The clincher for me is that dpkg-shlibdeps *already* works around this same problem to an extent: If multiple shlibs files generate duplicate dependencies on the same versions of a shared library, only one is output into the substvars. dpkg-shlibdeps does not go all the way and check for redundant but non-identical dependencies. Rather than implementing this stuff more than once to varying degrees, it seems better to go up a level and implement it there. Or to ignore it of course. :-) -- see shy jo signature.asc Description: Digital signature
Bug#301424: FWD: Re: Bug#301424: debhelper: dh_installmodules is unusable when running kernel version is not the target kernel version
- Forwarded message from Jerome Vizcaino <[EMAIL PROTECTED]> - From: Jerome Vizcaino <[EMAIL PROTECTED]> Date: Sat, 26 Mar 2005 00:22:53 +0100 To: Joey Hess <[EMAIL PROTECTED]> Subject: Re: Bug#301424: debhelper: dh_installmodules is unusable when running kernel version is not the target kernel version User-Agent: KMail/1.7.2 On Friday 25 March 2005 23:18, you wrote: > Jerome Vizcaino wrote: > > dh_installmodules is used to create postinst and postrm scripts for > > debianized kernel modules. The problem is the following : > > I'm running kernel 2.6.x and I'm building a bundle of two debian > > packages (kernel-image-2.6.y and foobar-module for 2.6.y) > > Install of both packages goes well but when I try to load the foobar > > module after booting my new 2.6.y kernel, foobar is not known. The > > problem comes from the update-modules script : update-modules only > > updates the running kernel's modules.dep. In my case, 2.6.x modules.dep > > got updated when installing the foobar-module package for 2.6.y. Looking > > at the alsa-source, I found that they didn't use dh_installmodules at all > > and wrote their own postinst and postrm template scripts to call depmod > > -a using the associated System.map file (in my case System.map-2.6.y) and > > specifying explicitly the kernel version (2.6.y). > > depmod command looks like this : > >depmod -A -F /boot/System.map-2.6.y 2.6.y > > > > By the way, I've only been testing with 2.6 kernels but I think the > > problem is the same with the 2.4 series. > > > > Could you change how dh_installmodules behaves and generate postinst and > > postrm scripts that takes this problem into account ? > If know about that. Launching /etc/init.d/modtils and /etc/init.d/module-init-tools by hand doesn't solve the problem (even when booting the new kernel). It looks like the depmod --quick doesn't check for new modules. Btw, /lib/modules-2.6.y is not read-only. > Both module-init-tools and modutils have init scripts that run during > boot and run depmod -a. The only way I can see that not working would be > if /lib/modules were not writable. Jerome - End forwarded message - -- see shy jo signature.asc Description: Digital signature
Bug#301424: debhelper: dh_installmodules is unusable when running kernel version is not the target kernel version
Jerome Vizcaino wrote: > If know about that. Launching /etc/init.d/modtils > and /etc/init.d/module-init-tools by hand doesn't solve the problem (even > when booting the new kernel). It looks like the depmod --quick doesn't check > for new modules. Btw, /lib/modules-2.6.y is not read-only. Well according to the documentation --quick makes it compare time stamps, so if the package ships modules that are older than the last boot time of the system, depmod --quick won't see them. Sounds like a bug in the boot scripts to me. -- see shy jo signature.asc Description: Digital signature
Bug#268466: still need info
Just a reminder that I've been waiting for a response on this bug since January. -- see shy jo signature.asc Description: Digital signature
Bug#205142: hmm
clone 205142 -1 retitle -1 could section 8.1 mandate what library directories will be searched by ldconfig, rather than just describing what they currently are reassign -1 debian-policy thanks Policy 8.1 lists a set of directories for shared libraries, but it lists it as a non-normative aside and footnote. It seems to me that ldconfig could change its behavior w/o violating this policy, or something could stick a new line in /etc/ld.so.conf. Indeed, things do put lines in there, and it's not clear if policy requires ldconfig be run for libraries in such directories or not. Also, the list of directories in the footnote does not match those in ls.so.conf on my (sid) system. /usr/X11R6/lib/Xaw3d is long gone. If policy was authoratative about this, I'd not mind putting the list in debhelper, but when it's just descriptive, I risk having to track everything that could change the list myself, which is not a position I want to be in. Reassigning to policy. :-) -- see shy jo signature.asc Description: Digital signature
Bug#225210: please add a way to call logrotate that removes all log files for a given file
reassign 225210 logrotate thanks This bug report asked for dh_installlogrotate to add something to the postrm to clean up old logrotated log files on purge. If we want to do this, it would need some additional support from logrotate. For example, if logrotate had a --cleanup switch that deleted all the log files it had rotated, then the postrm could run something like: logrotate --cleanup /etc/logrotate.d/foo -- see shy jo signature.asc Description: Digital signature
Bug#313342: dh_strip fix for shared library sym-links in *-dbg packages
Raphael Bossek wrote: > > Can you give a real-life example please? > The libxerces1 package where this files exists: > > /usr/lib/libxerces1.so.1.7 -> libxerces1.so.1.7.0 > /usr/lib/libxerces1.so.1.7.0 (SONAME libxerces1.so.1.7) > > GDB try to load /usr/lib/debug/usr/lib/libxerces1.so.1.7 as specified > by SONAME. The symlink is required to get the /usr/lib/debug variant > of file to get loaded. The fallback is to /usr/lib/libxerces1.so.1.7 > which does not contain the symbolic information. Hmm, I'm suprised that gdb has this problem, it seems like it might make more sense if it resulved the symlinks and then looked for the debug file matching the library they pointed to. Your patch to make it just copy the symlinks into the debug directory does look good, but I'd like to hear from Dan first and make sure that this is not a gdb bug and that we really need to do this. -- see shy jo signature.asc Description: Digital signature
Bug#313342: dh_strip fix for shared library sym-links in *-dbg packages
Daniel Jacobowitz wrote: > Well certainly there's more going on than this: please look at > /usr/lib/debug/lib and observe that there's only libc-2.3.2.so there, > not libc.so.6. > > The path to the debug file is based on the original file's location, > but the basename of the debug file is not; it comes from the > .gnu_debuglink section of the object. So, it looks as if that section > is not being created correctly. Which one are you stripping to > generate the debug info? It should be the real file. dh_strip strips the real file, AFAIK. -- see shy jo signature.asc Description: Digital signature
Bug#314157: does not work in d-i anymore
Package: debootstrap Version: 0.3.1 Severity: grave /target/debootstrap # cat debootstrap.log local: 352: apt-utils: bad variable name /target/debootstrap # -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.4.27 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages debootstrap depends on: ii binutils 2.15-6 The GNU assembler, linker and bina ii wget 1.9.1-12 retrieves files from the web -- no debconf information -- see shy jo signature.asc Description: Digital signature
Bug#314160: log file issues cause problems for d-i
Package: debootstrap Version: 0.3.1 Severity: minor debootstrap's change to manage its own log file causes some problems for d-i. d-i contains messages that tell the user to look at vt 3 or /var/log/messages, where we redirect stderr, including debootstrap's. Of course we can changes those messages, but now they need to direct the user to different log locations depending on how well debootstrap succeeded or failed, and users will not just be able to flip to a tty to see debootstrap output for debugging. Also, our installation report framework does things like copy /var/log from the installer to a floppy, or run a web server to export those logs, to aid in debugging failed installs. This will need more special purpose code to also save/export the various new deootstrap log files. I'd be in favour of either making --debian-installer continue to log to stderr, or adding a new switch to get that behavior back. Logging to the log file too would be ok, but redundant, since d-i copies its logs to /target/var/log/installer/ at the end. -- see shy jo signature.asc Description: Digital signature
Bug#222652: reassign to dpkg-dev
Scott James Remnant wrote: > reassign 222652 dpkg-dev > thanks > > ... [EMAIL PROTECTED] ... > -- what was on YOUR mind? :p Argh, that often-made typo finally escaped my box. Thank you mutt. No, not that way. Bleh. > On Mon, 2005-06-13 at 12:03 -0400, Joey Hess wrote: > > > Well, of Branden's options, 1 seems like going behind dpkg-gencontrol's > > back and the wrong place to put code to remove dups; 2 complicates > > debhelper unnessarily; 3 seems like a good idea to me, but I dunno how > > the dpkg developers will feel about it; 4 seems reasonable too. > > > 3 seems like a good idea to me too, for much the same reason. Excellent! -- see shy jo signature.asc Description: Digital signature
Bug#298702: Re-opening this (legitimate) bug
Javier Fernández-Sanguino Peña wrote: > reopen 298702 FWIW, my probability of fixing a given bug on any pass over the BTS is inversely proportional to the size and complexity of the bug report log. New bug numbers are cheap. Please use them. > tags 298702 wontfix > - Frans says this is documented in the manual and, indeed, there is a > mention of it in the manual as a note: Tasksel is not the installation manual. New bug numbers are cheap. Use them. > - Tasksel could pull in Standard packages as a task (instead of having > aptitude do the job itself) I'm already on record as planning to do this for etch. -- see shy jo signature.asc Description: Digital signature
Bug#301282: Package: installation-reports
Brian Beck wrote: > 1. The mail setup is a bit off putting I think there were five options, and > I'm not certain I picked the proper one. Perhaps either more help would be > nice. (Maybe I should just spend more time reading the manual first.) If you have some specific suggestions I'd suggest you file a separate bug on the exim4-config package (or I can clone this one to there), as it's not part of the installer as such. Although we did try to trim this down as much as possible and make the help text as usful as possible given the space. > 2. Would it be possible to offer the user the choice of branches. For > example > I could select Stable, Testing, or Unstable. Not from the netinst CD, as there's only room on the CD for one version of Debian. The businesscard or netboot installer offers these choices, although only in expert mode. -- see shy jo signature.asc Description: Digital signature
Bug#301262: Installation report: Gnome keymap, Audigy2+BTTV problems; Theora suggestion
Timo Jyrinki wrote: > Installation itself went fine. Problems: > 1. GNOME has not Finnish keymap selected, even though Finnish was >selected as the installation language. This should be corrected! >Manually fixed by changing /desktop/gnome/peripherals/keyboard/xkb/ >layouts from us to fi. XF86Config-4 had the correct XkbLayout >already. I think this is a missing feature in localization-config, although others seem to think it's a bug in gnome for not using the X settings as the default. > 2. I've both a tv card and Audigy2 sound card, which both have mixers. >The tv card is not a real audio device, yet it is configured as the >primary "sound card" and I can't get any audio out of my machine. I >had the same problem with Ubuntu Warty, and though I had some success >with esound.conf -d parameter, the only way I found to fix the >problem permanently was to remove the snd-bt87x module entirely, >which is apparently btaudio in 2.4 kernels. This behavior is fixed >in eg. Ubuntu Hoary. If you can tell us _how_ it's fixed in ubuntu, that might be a good start. > Ideas: > 3. libtheora0 should be installed by default when desktop package is >selected. Ogg Theora is The free video codec at the moment, and even >though it's in "alpha" stage its bitstream is fixed and it's fully >usable. It'd be nice to play Theora videos out-of-the-box with Sarge. >Now plays with Totem as soon as libtheora0 is installed. Added to tasksel svn. -- see shy jo signature.asc Description: Digital signature
Bug#300913: d-i Installation report: Device nodes not created
reassign 300913 makedev tag 300913 d-i thanks Tobias Klauser wrote: >Device Boot Start End Blocks Id System >/dev/hda1 1 3 24066 a0 IBM Thinkpad >hibernation >/dev/hda2 4 93 722925 82 Linux swap / > Solaris >/dev/hda3 949733774333005 Extended >/dev/hda5 * 94 102 72261 83 Linux (Other > Distri) >/dev/hda6 103 406 2441848+ 83 Linux (Other > Distri) >/dev/hda7 4071014 4883728+ 83 Linux (Other > Distri) >/dev/hda810151209 1566306 83 Linux (Other > Distri) >/dev/hda912101574 2931831 83 Linux (Other > Distri) >/dev/hda10 15751939 2931831 83 Linux (Other > Distri) >/dev/hda11 19401951 96358+ 83 Linux (Other > Distri) >/dev/hda12 19522680 5855661 83 Linux (Other > Distri) >/dev/hda13 26812826 1172713+ 83 Linux (Other > Distri) >/dev/hda14 28273324 4000153+ 83 Linux (Other > Distri) >/dev/hda15 3325 72261 83 Linux (Other > Distri) >/dev/hda16 33344018 5502231 83 Linux (Other > Distri) >/dev/hda17 40194267 261 83 Linux (Other > Distri) >/dev/hda18 42684279 96358+ 83 Linux (Debian > /boot) >/dev/hda19 42804644 2931831 83 Linux (Debian /) >/dev/hda20 46455373 5855661 83 Linux (Debian /usr) >/dev/hda21 53745616 1951866 83 Linux (Debian /var) >/dev/hda22 7867973314996646 83 Linux (/home) Whee! > After installing the base system from the CD image stated above, the installer > rebooted the system without any problem. But when the newly installed Debian > system started it complained about partions not being mounted. > > I hunted down the problem to the following: During installation only /dev/hda1 > thru /dev/hda20 are created. /dev/hda21 and /dev/hda22 are missing (see my > partitioning scheme above) As a consequence of this my Debian /var and /home > could not be mounted on the reboot after installation. I'm reassigning this to makedev, as it's ultimatly the default set of devices it puts in /dev/ that is used by the installer, and that stops as hda20. I note that bug #146611 has been open for years and tagged wontfix regarding the same problem. Perhaps having another report of this, on another architecture will change Bdale's mind. Bdale: If you're not going to fix this, please reassign it back to d-i so we can put in some nasty hack that checks the target system's fstab and tries to create any missing /dev/ entries.. Perhaps such a hack would be a good idea in general. -- see shy jo signature.asc Description: Digital signature
Bug#300545: acpi task
Per Olofsson wrote: > Attached is a patch which adds an acpi task. This task is installed > automatically if ACPI support is available. It is never shown to the > user. Is this the proper way to make sure that ACPI support is > installed or is this task perhaps too small? I'm hesitant about calling acpi support itself a task. It doesn't full in the blank well in a sentence like "I wanna use a ___.". I'd also prefer to avoid completly hidden tasks, if there's not some visible task (like desktop that triggers them, since I think that could lead to some overly-DWIM behavior. Of course it's a subset of laptop support, which I do think would work as a task; the task could try to detect a laptop, and default the task to install if found; the task would always be visible in the menu. Given that all we need for acpi support is so simple, it might be better to hardcode this elsewhere in the installer. -- see shy jo signature.asc Description: Digital signature
Bug#299059: sarge network-preseed not getting executed
Neil Franklin wrote: > Perhaps it would be good to change the documentation (Sarge > Installation Manual, http://d-i.alioth.debian.org/manual/) to reflect > this limitation of the floppy media? initrd preseeding is a post-sarge feature, which is why it's not documented in the manual yet. -- see shy jo signature.asc Description: Digital signature
