Re: Bug#603938: debian-installer: The 1st CD doesn't contain desktop nor laptop tasks
(About xz compression) > On the whole pool/ on CD1, the gains are smaller than that -- roughly one > third, which still makes a massive difference. I just realised today that unfortunately xz compression is not supported by python, and therefore neither by dak (http://bugs.debian.org/556407). Cheers, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101126113434.ga32...@merveille.plessy.net
Bug#604728: general: Cannot play anything in totem or gnome-mplayer while a flash movie is running in iceweasel
[Holger Levsen] >> Looks like editing the file /etc/asound.conf fixed the problem. >> Thanks, but shouldn't this be done automatically while installing >> pulseaudio package? > > I'll leave this decission to the pulseaudio maintainers... ;-) Just to let you know, we will change the default in Debian Edu to use pulseaudio by default by editing our /etc/asound.conf file to do this. We earlier only enabled this for thin clients, but if it make sure Adobe Flash audio do not block other programs, it seem a good default to have for non-thin clients too. Happy hacking, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2flvd3kuuia@login1.uio.no
Re: Bug#605009: serious performance regression with ext4
Hi, adding debian-devel, debian-boot, debian-kernel and Theodore Y. Ts'o in CC because I'm fed up with this problem. Sorry for the massive crosspost, you might want to follow up only on -devel and on the bug report. Some clones/reassign should probably result from this discussion anyway. On Fri, 26 Nov 2010, Michael Biebl wrote: > I'm using ext4 with the default mount option and the fs was created with > the default settings from /etc/mke2fs.conf. > Since the latest upgrade, performance suffered badly. > > E.g. installing vim-runtime took ~8 secs with 1.15.8.5, now it takes > ~44secs. > > It was suggested that I use the nodelalloc mount option for ext4. > But that not only takes away some of the benefits of ext4, it also > requires explicit configuration. > > dpkg should work properly(with good performance) out-of-the-box on ext4. There's currently no way we're going to fix this. It all started with report of corrupted (zero-length) files on ext4/ubifs (see http://bugs.debian.org/430958). We did the right thing to fix this which is to call fsync() on the fly on each file that dpkg unpacks. That was introduced in dpkg 1.15.6. (Ubuntu had more than 80 bug reports related to this and Debian very few because we don't use ext4 by default) That was disastrous in terms of performance, so we then grouped the fsync()+rename() calls at the end of the unpack phase before updating the dpkg database. That can be witnessed in dpkg 1.15.7. That was ok everywhere except on ext4. For some unknown reasons, with the nodelalloc option the performance are again reasonable (but we discovered that only recently). Ubuntu is using ext4 by default and this performance was not acceptable and we tried to work-around the problem by replacing all the fsync() by a single sync() on Linux only (because Linux's sync() is synchronous while it's not necessarily the case on other systems). This was enabled in dpkg 1.15.7.2 in response to http://bugs.debian.org/578635. Now using sync() appears to be a bad choice since it resulted in RC bugs like http://bugs.debian.org/595927 and http://bugs.debian.org/600075 and was an annoyance for people using dpkg on tmpfs to get super-high speed (http://bugs.debian.org/588339). So we reverted that hackish work-around of using sync() and we're back to the situation where dpkg is very slow on ext4. But we have added a new option --force-unsafe-io that can be used when data safety is not important (in a temporary chroot, during initial installation, etc.) as requested in http://bugs.debian.org/584254. Where does that leaves us? Here are various options to consider (they are not necessarily mutually exclusive): 1/ This problem and the known work-arounds should be documented in the release notes. 2/ d-i should be modified to use --force-unsafe-io if it detects a dpkg version >= 1.15.8.6. 3/ d-i might want to setup the nodelalloc option by default when a partition is formatted with ext4 and mounted as / or /usr. 4/ Theodore might want to find out why ext4 is behaving so badly under this usage pattern while ext3 doesn't... i.e. fix https://bugzilla.kernel.org/show_bug.cgi?id=15910 Or at least suggest another usage pattern which result in the same guaranty for dpkg but without the poor performance (and sync() is not the right answer as experience showed us). Note that doing N x fsync() followed by N x rename() is not giving us any better result that doing N x (fsync()+rename()). Note that calling posix_fallocate() before writing the files that are fsynced() did not help either (Mike Hommey thought it could be a way to emulate nodelalloc at the dpkg level only but apparently not). What has not been tried: reordering the fsync() based on FIEMAP information. Or using fdatasync() instead of fsync() and calling fsync() on directories. 5/ maybe the debian-kernel team wants to discuss the issue on LKML. Both for the bad ext4 performances (see above) and the (incorrect?) behaviour of sync() which is never finishing under important I/O loads (cf https://bugzilla.kernel.org/show_bug.cgi?id=18632). But right now from the point of view of dpkg maintainers, this bug is a "wontfix" at our level. Just to sum up what dpkg --unpack does in 1.15.8.6: 1/ set the package status as half-installed/reinst-required 2/ extract all the new files as *.dpkg-new 3/ for all the unpacked files: fsync(foo.dpkg-new) followed by rename(foo.dpkg-new, foo) 4/ set the package status as unpacked Note that the directories are not fsynced() because we mainly don't care if the rename is recorded or not, as long as the installed file always has the content of either the old or the new file. This could be fixed but is unlikely to help in getting better performances I guess. The only thing we want to achieve is that: - when the package is set to unpacked status, all changes have been committed - when the process is abruptly interrupted, we don't leave corrupted files around (like unwanted empty files) Cheers, -- Ra
Bug#605009: Info received (Bug#605009: serious performance regression with ext4)
Thank you for the additional information you have supplied regarding this Bug report. This is an automatically generated reply to let you know your message has been received. Your message is being forwarded to the package maintainers and other interested parties for their attention; they will reply in due course. Your message has been sent to the package maintainer(s): Dpkg Developers If you wish to submit further information on this problem, please send it to 605...@bugs.debian.org. Please do not send mail to ow...@bugs.debian.org unless you wish to report a problem with the Bug-tracking system. -- 605009: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=605009 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.605009.b605009.129078321425560.acki...@bugs.debian.org
Re: Bug#605009: serious performance regression with ext4
On Fri, Nov 26, 2010 at 03:53:27PM +0100, Raphael Hertzog wrote: > But right now from the point of view of dpkg maintainers, this bug is a > "wontfix" at our level. > > Just to sum up what dpkg --unpack does in 1.15.8.6: > 1/ set the package status as half-installed/reinst-required > 2/ extract all the new files as *.dpkg-new > 3/ for all the unpacked files: fsync(foo.dpkg-new) followed by >rename(foo.dpkg-new, foo) > 4/ set the package status as unpacked > > Note that the directories are not fsynced() because we mainly don't care > if the rename is recorded or not, as long as the installed file always has > the content of either the old or the new file. This could be fixed but is > unlikely to help in getting better performances I guess. > > The only thing we want to achieve is that: > - when the package is set to unpacked status, all changes have been > committed > - when the process is abruptly interrupted, we don't leave corrupted files > around (like unwanted empty files) How about dpkg doesn't care, like it used to, *except* for really important packages (say, essential ones, or priority important, or whatever). Since apparently the whole avoid empty files thing is much more important for libc than it is for iceweasel, when for one your system is hosed and for the other, you have everything required to repair. We could even provide an autorepair tool that could e.g. use debsums to check installed files and reinstall hosed packages. Mike -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101126150910.ga22...@glandium.org
Re: Bug#605009: serious performance regression with ext4
On Fri, Nov 26, 2010 at 3:53 PM, Raphael Hertzog wrote: > It all started with report of corrupted (zero-length) files on ext4/ubifs > (see http://bugs.debian.org/430958). We did the right thing to fix this > which is to call fsync() on the fly on each file that dpkg unpacks. That Is durable required or is atomic enough? The fact that fsync wasn't present suggests durable isn't required. IMO the ext4 issue should be solved by supporting atomic file updates without all kludges like renaming. Olaf -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktimfqmroxuknsdgkndlsqwg6a5_oshu4uhrkl...@mail.gmail.com
Bug#605030: general: bluetooth adapter ar3011 on acer aspire 5553g don't start after shutdown
Package: general Severity: normal I am using Debian testing with latest updates installed. I have a atheros ar3011 bluetooth adapter on my laptop. The problem is next, when i shutdown my laptop and on first boot choose to run debian my adapter don't start. To get my adapter working i have to boot into my windows 7 second system and then reboot to debian. This steps allow me to use bluetooth untill next shutdown. When my adapter is unavailable i get empty output from 'hcitool dev' command. Nevertheless the output by 'lsusb' is this: Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 004 Device 002: ID 0cf3:3002 Atheros Communications, Inc. Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 001 Device 002: ID 0402:9665 ALi Corp. Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub. Here is my adapter on Bus 004. But system can't start it. -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (900, 'testing'), (800, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/3 CPU cores) Locale: LANG=ru_RU.utf8, LC_CTYPE=ru_RU.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101126150018.13604.60622.report...@amunnb
Re: Bug#605009: serious performance regression with ext4
* Betr.: " Re: Bug#605009: serious performance regression with ext4" (Fri, 26 Nov 2010 15:53:27 +0100): > That was ok everywhere except on ext4. JFTR: I am experiencing those problems as well on XFS. Cheers, -- Mathias Behrle MBSolutions Gilgenmatten 10 A D-79114 Freiburg Tel: +49(761)471023 Fax: +49(761)4770816 http://m9s.biz UStIdNr: DE 142009020 PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6 signature.asc Description: PGP signature
Bug#605032: general: Acer Aspire 5553g fails to resume after hibernate
Package: general Severity: normal When i use hibernate mode on my laptop Acer Aspire 5553g with closing my notebook i cant resume the session when open it later. It simply freezes. All i can do is force shut down using 5 sec press power button. There no other key is responsing. -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (900, 'testing'), (800, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/3 CPU cores) Locale: LANG=ru_RU.utf8, LC_CTYPE=ru_RU.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101126150443.13712.41671.report...@amunnb
Re: Bug#605009: serious performance regression with ext4
Low performance with Btrfs as well, :( (Even Btrfs is not supported in squeeze, I think this could help on digging whether it is a more generic problem than EXT4 only.) -- Regards, Aron Xu -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktinrkbpzkfa3ch84q_kra14bcbq-nmpfyjscm...@mail.gmail.com
Processed: Re: Bug#605032: general: Acer Aspire 5553g fails to resume after hibernate
Processing commands for cont...@bugs.debian.org: > reassign 605032 linux-2.6 Bug #605032 [general] general: Acer Aspire 5553g fails to resume after hibernate Bug reassigned from package 'general' to 'linux-2.6'. > thanks Stopping processing here. Please contact me if you need assistance. -- 605032: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=605032 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.c.12907865318843.transcr...@bugs.debian.org
Processed: Re: Bug#605030: general: bluetooth adapter ar3011 on acer aspire 5553g don't start after shutdown
Processing commands for cont...@bugs.debian.org: > reassign 605030 linux-2.6 Bug #605030 [general] general: bluetooth adapter ar3011 on acer aspire 5553g don't start after shutdown Bug reassigned from package 'general' to 'linux-2.6'. > thanks Stopping processing here. Please contact me if you need assistance. -- 605030: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=605030 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.c.12907865578922.transcr...@bugs.debian.org
Bug#605040: ITP: qt-gstreamer -- GStreamer bindings for C++/Qt4
Package: wnpp Severity: wishlist Owner: George Kiagiadakis * Package name: qt-gstreamer Upstream Author : George Kiagiadakis , Mauricio Piacentini * URL : http://cgit.freedesktop.org/gstreamer/qt-gstreamer/ * License : LGPL Programming Lang: C++ Description : GStreamer bindings for C++/Qt4 QtGStreamer provides C++ bindings for GStreamer with a Qt-style API, plus some helper classes for integrating GStreamer better in Qt applications. The library is currently under heavy development and the first release is expected in a few weeks' time. I don't intend to upload pre-release snapshots to the debian archive, but only prepare the package to be ready for upload after the first release. It is probably best to put this under the maintenance of pkg-gstreamer, if the pkg-gstreamer team agrees of course, as it is an official gstreamer project. Of course, I will actively maintain this package. Regards, George -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101126170336.20074.68037.report...@localhost
Fw: Bug#605009: serious performance regression with ext4
* Betr.: " Re: Bug#605009: serious performance regression with ext4" (Fri, 26 Nov 2010 16:33:06 +0100): > On Fri, 26 Nov 2010, Mathias Behrle wrote: > > * Betr.: " Re: Bug#605009: serious performance regression with ext4" (Fri, > > 26 Nov 2010 15:53:27 +0100): > > > > > That was ok everywhere except on ext4. > > > > JFTR: I am experiencing those problems as well on XFS. > > Can you give us figures to quantify the slowdown that you experience? > Please compare dpkg 1.15.8.5 and 1.15.8.6. > > (I suppose that's the problem you're referring to) I have to correct my previous mail. I am experiencing since some time a substantial slowdown on my XFS file systems (could also be related to upgrading to kernel 2.6.32). This slowdown is also quite perceivable on system upgrades with apt-get/aptitude. Now for the first time Bug#605009 came to my knowledge and I guessed it could also be a cause for the meanwhile rather painful upgrades on my desktop machine. I just upgraded my testing machine to dpkg 1.15.8.6. and tested with 'aptitude -o DPkg::options::="--force-unsafe-io"' and see that my guess was at least partly wrong. Unpacking of the debs still causes very heavy load on the harddisk while final install seems to be faster. So the problems I am facing with XFS are probably at least not closely related to #605009. Sorry for the noise, -- Mathias Behrle MBSolutions Gilgenmatten 10 A D-79114 Freiburg Tel: +49(761)471023 Fax: +49(761)4770816 http://m9s.biz UStIdNr: DE 142009020 PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6 signature.asc Description: PGP signature
Bug#605062: ITP: libtest-database-perl -- facilitates testing against several databases
Package: wnpp Severity: wishlist Owner: Nicholas Bamber * Package name: libtest-database-perl Version : 1.11 Upstream Author : Phillpe Bruhat * URL : http://seach.cpan.org/dist/Test-Database * License : perl Programming Lang: perl Description : facilitates testing against several databases This module is needed to upgrade libdatetime-format-dbi-perl. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101126211543.3356.63511.report...@leonhartsberger.periapt
Bug#605064: ITP: libtest-identity-perl -- assert the referential identity of a reference
Package: wnpp Severity: wishlist Owner: Nicholas Bamber * Package name: libtest-identity-perl Version : 0.01 Upstream Author : Paul Evans * URL : http://search.cpan.org/dist/Test-Identity/ * License : Perl Programming Lang: Perl Description : assert the referential identity of a reference needed to upgrade IO::Async -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101126212226.3393.31457.report...@leonhartsberger.periapt
Re: Bug#605009: serious performance regression with ext4
On Fri, Nov 26, 2010 at 03:53:27PM +0100, Raphael Hertzog wrote: > Just to sum up what dpkg --unpack does in 1.15.8.6: > 1/ set the package status as half-installed/reinst-required > 2/ extract all the new files as *.dpkg-new > 3/ for all the unpacked files: fsync(foo.dpkg-new) followed by >rename(foo.dpkg-new, foo) What are you doing? 1) Suppose package contains files "a", "b", and "c". Which are you doing? a) extract a.dpkg-new ; fsync(a.dpkg-new); rename(a.dpkg-new, a); extract b.dpkg-new ; fsync(b.dpkg-new); rename(b.dpkg-new, b); extract c.dpkg-new ; fsync(c.dpkg-new); rename(c.dpkg-new, c); or b) extract a.dpkg-new ; fsync(a.dpkg-new); extract b.dpkg-new ; fsync(b.dpkg-new); extract c.dpkg-new ; fsync(c.dpkg-new); rename(a.dpkg-new, a); rename(b.dpkg-new, b); rename(c.dpkg-new, c); or c) extract(a.dpkg-new); extract(b.dpkg-new); extract(c.dpkg-new); fsync(a.dpkg-new); fsync(b.dpkg-new); fsync(c.dpkg-new); rename(a.dpkg-new, a); rename(b.dpkg-new, b); rename(c.dpkg-new, c); (c) will perform the best for most file systems, including ext4. As a further optimization, if "b" and "c" does not exist, of course it would be better to extract into "b" and "c" directly, and skip the rename, i.e.: d) extract(a.dpkg-new); extract(b); # assuming the file "b" does not yet exist extract(c); # assuming the file "c" does not yet exist fsync(a.dpkg-new); fsync(b); fsync(c); rename(a.dpkg-new, a); ... and then set the package status as unpacked. I am guessing you are doing (a) today --- am I right? (c) or (d) would be best. - Ted -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101126215254.gj2...@thunk.org
Adding some Pre-Depends php-pear (>= 5.3) to fix upgrade from Lenny
As per request from the RT, I'm forwarding this to -devel: we're about to add some Pre-Depends: on few PHP PEAR packages, in order to fix upgrading from Lenny to Squeeze. If anyone wants to object, please have a look to the discussion about it in -release, then reply to #602865, with a copy to pkg-php-ma...@lists.alioth.debian.org. Cheers, Thomas Original Message Subject: Re: [php-maint] [Pkg-php-pear] RFS: php-net-smtp (updated package) Date: Fri, 26 Nov 2010 16:10:54 + From: Adam D. Barratt To: Thomas Goirand CC: pkg-php-maint but new Pre-Depends are also supposed to be raised on debian-de...@lists.d.o ; I'd imagine this case wouldn't be particularly controversial, but it would be good to check. :) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4cf0a74d.3070...@debian.org
Re: Bug#605009: serious performance regression with ext4
Hi Ted, Ted Ts'o wrote: > 1) Suppose package contains files "a", "b", and "c". Which are you > doing? > > a) extract a.dpkg-new ; fsync(a.dpkg-new); rename(a.dpkg-new, a); > extract b.dpkg-new ; fsync(b.dpkg-new); rename(b.dpkg-new, b); > extract c.dpkg-new ; fsync(c.dpkg-new); rename(c.dpkg-new, c); > > or > > b) extract a.dpkg-new ; fsync(a.dpkg-new); > extract b.dpkg-new ; fsync(b.dpkg-new); > extract c.dpkg-new ; fsync(c.dpkg-new); > rename(a.dpkg-new, a); > rename(b.dpkg-new, b); > rename(c.dpkg-new, c); > > or > > c) extract(a.dpkg-new); > extract(b.dpkg-new); > extract(c.dpkg-new); > fsync(a.dpkg-new); > fsync(b.dpkg-new); > fsync(c.dpkg-new); > rename(a.dpkg-new, a); > rename(b.dpkg-new, b); > rename(c.dpkg-new, c); > > > (c) will perform the best for most file systems, including ext4. [...] > I am guessing you are doing (a) today --- am I right? (c) or (d) > would be best. We are doing (c) today. Regards, Jonathan -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101127075831.gc24...@burratino
