Bug#999598: dpkg-dev: Can we have binary package descriptions back for source uploads?
[Holger Levsen] > IMO this would only be a clumsy workaround (esp for packages with many > binary package) and we should rather fix the cause: Not sure a source package description will provide the information I wish for, which is simply to get a similar list to what we used to get before source only upload became popular. An example from 2010 is https://lists.debian.org/debian-devel-changes/2010/01/msg0.html>: Description: logcheck - mails anomalies in the system logfiles to the administrator logcheck-database - database of system log rules for the use of log checkers logtail- Print log file lines that have not been read (deprecated) -- Happy hacking Petter Reinholdtsen
Bug#999598: dpkg-dev: Can we have binary package descriptions back for source uploads?
Package: dpkg-dev Version: 1.20.9 Dear dpkg-dev developers, One feature that is deeply missed, and which disappered when we moved to source only uploads, is the listing of binary package descriptions in the email to debian-devel-chan...@lists.debian.org. The emails used to have a section like this, listing the short description of each binary package: Description: gdm- GNOME Display Manager I used this to see if a package I never heard about could be interesting to check out or not. After we moved to source only uploads to unstable, there is no Description section any more in the emails, and it is a lot harder to guess what the odd packages are useful for. The email content is simply the uploaded .changes file. Would it be possible to adjust the .changes generator to include the description of all binary packages listed in d/control, even if none of them are included in the upload? -- Happy hacking Petter Reinholdtsen
Bug#613428: dpkg --force-unsafe-io still calls fsync()
[Guillem Jover] I've suspected this would be the case all along, but as I don't use one of the new filesystems (due to issues like this), I never bothered to test it. Note, I only tested on ext4. I have not tested on any of the new file systems. :) -- Happy hacking Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#613428: dpkg --force-unsafe-io still calls fsync()
I've now tested using the dpkg patch disabling fsync(), and ran each test three times, first comparing the normal dpkg with the Dir::Bin::dpkg wrapper, and next comparing the patched dpkg with the patched dpkg and the Dir::Bin::dpkg wrapper: Sun Sep 21 09:21:28 CEST 2014 used: 750 default Sun Sep 21 09:30:53 CEST 2014 used: 562 dpkg_conf Sun Sep 21 09:43:32 CEST 2014 used: 756 default Sun Sep 21 09:53:02 CEST 2014 used: 567 dpkg_conf Sun Sep 21 10:06:25 CEST 2014 used: 800 default Sun Sep 21 10:15:47 CEST 2014 used: 559 dpkg_conf The 'default' average is 769+-32 seconds, the 'dpkg_conf' average is 563+-5 seconds. Sun Sep 21 10:33:15 CEST 2014 used: 772 dpkg_nofsync Sun Sep 21 10:42:38 CEST 2014 used: 560 dpkg_conf Sun Sep 21 10:55:19 CEST 2014 used: 758 dpkg_nofsync Sun Sep 21 11:04:43 CEST 2014 used: 561 dpkg_conf Sun Sep 21 11:17:23 CEST 2014 used: 757 dpkg_nofsync Sun Sep 21 11:26:45 CEST 2014 used: 559 dpkg_conf The 'dpkg_nofsync' average is 762+-10 seconds, the 'dpkg_conf' average is 560+-1 seconds. So the advantage of disabling fsync() in dpkg itself seem neglectable, while the advantage of using eatmydata is significant, also with a patched dpkg. -- Happy hacking Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#613428: dpkg --force-unsafe-io still calls fsync()
[Guillem Jover]
Hi!
Hi. :)
You asked in the past why the current implementation is the way it
is. A quick summary would be that, [...]
Thank you for the explanation. :)
You should either clear the kernel cache or reboot on each iteration
to try to get a similar initial state. The former can be done with
something like:
sudo sh -c 'sync echo 3 /proc/sys/vm/drop_caches'
Good point. I did some more testing with such flushing in place, and
tried a bit with different ordering too, and got this result
installing the kde-full package and dependences (around 1700
packages):
Fri Sep 19 10:39:48 CEST 2014 used: 576 dpkg_conf
Fri Sep 19 10:49:09 CEST 2014 used: 558 divert
Fri Sep 19 11:01:33 CEST 2014 used: 741 default
Fri Sep 19 11:14:08 CEST 2014 used: 556 dpkg_conf
Fri Sep 19 11:23:28 CEST 2014 used: 557 divert
Fri Sep 19 11:37:57 CEST 2014 used: 866 default
Fri Sep 19 12:11:27 CEST 2014 used: 930 default
Fri Sep 19 12:20:54 CEST 2014 used: 564 divert
Fri Sep 19 12:30:21 CEST 2014 used: 564 dpkg_conf
Fri Sep 19 15:24:50 CEST 2014 used: 805 default
Fri Sep 19 15:34:15 CEST 2014 used: 562 divert
Fri Sep 19 15:43:40 CEST 2014 used: 562 dpkg_conf
The machine had 100Mbit/s to the mirror, so most of the time is spent
unpacking. The speedup seem to be significant, in the range two to
three minutes for this set of packages.
Also, this indicate that using eatmydata for dpkg is enough to get
most of the advantage, and that using it for apt-get do not gain much
extra speedup. Adding a wrapper and configuring Dir::Bin::dpkg to
call it might be seen as less intrusive than the dpkg-divert method.
You might also want to try with the attached dpkg patch which should
disable all fsync() calls in the main dpkg program, to see how the
rest of the system affects your performance, besides dpkg itself.
Will try to find time to do this later.:)
This is the script I use for testing now.
#!/bin/sh
set -e
suite=testing
chroot=chroot-testing
#mirror=http://http.debian.net/debian
mirror=http://ftp.uio.no/debian
unset TMP TMPDIR TEMP TEMPDIR
# Never wait for input
DEBIAN_FRONTEND=noninteractive
export DEBIAN_FRONTEND
info() { echo info: $@ ; }
error() { echo error: $@ ; }
make_chroot() {
debootstrap $suite $chroot $mirror
printf #!/bin/sh\nexit 101\n $chroot/usr/sbin/policy-rc.d
chmod a+rx $chroot/usr/sbin/policy-rc.d
chroot $chroot apt-get install -y eatmydata
}
install_chroot_pkgs() {
chroot $chroot apt-get install -o APT::Acquire::Retries=3 -y kde-full
}
test_default() {
make_chroot
install_chroot_pkgs
}
test_divert() {
make_chroot
for bin in dpkg apt-get aptitude tasksel ; do
file=/usr/bin/$bin
# Test that the file exist and have not been diverted already.
if [ -f $chroot/usr/bin/$bin ] ; then
info diverting /usr/bin/$bin using eatmydata
printf #!/bin/sh\neatmydata $bin.distrib \\$@\\n \
$chroot/usr/bin/$bin.edu
chmod 755 $chroot/usr/bin/$bin.edu
chroot $chroot dpkg-divert --package debian-edu-config \
--rename --quiet --add /usr/bin/$bin
ln -sf ./$bin.edu $chroot/usr/bin/$bin
else
error unable to divert /usr/bin/$bin, as it is missing.
fi
done
install_chroot_pkgs
}
# https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=613428
test_dpkg_conf() {
make_chroot
cat $chroot/usr/bin/dpkg-eatmydata 'EOF'
#!/bin/sh
/usr/bin/eatmydata /usr/bin/dpkg $@
EOF
chmod a+rx $chroot/usr/bin/dpkg-eatmydata
cat $chroot/etc/apt/apt.conf.d/dpkg-eatmydata EOF
Dir::Bin::dpkg /usr/bin/dpkg-eatmydata;
EOF
install_chroot_pkgs
}
info Logging to run-$suite.log
exec /dev/null run-$suite.log 21
for f in \
default \
divert \
dpkg_conf
do
rm -rf $chroot
echo
echo Testing $f
echo
sync echo 3 /proc/sys/vm/drop_caches
start=$(date +%s)
test_$f
end=$(date +%s)
(LC_ALL=C date; echo used: $(($end - $start)) $f ) test.log
done
echo
tail test.log
--
Happy hacking
Petter Reinholdtsen
--
To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#613428: dpkg --force-unsafe-io still calls fsync()
Hi.
I did some testing installing using eatmydata to see how much it could
reduce the installation time. I used the enclosed test script to
compare the installation time for three test setup. One is the normal
one, the other is using dpkg-divert to divert apt-get, aptitude and
dpkg, while the third uses the Dir::Bin::dpkg setting to use a dpkg
wrapper with eatmydata enabled.
The installation was done with 100Mbit/s connection to the Debian
mirror, so most of the time is spend unpacking. I tried using two
package sets, kde-standard and kde-full, picked to get a fairly large
number of packages installed.
This was the result. The number is in seconds.
Installing kde-standard
Wed Sep 17 09:54:50 CEST 2014 used: 357 divert
Wed Sep 17 10:00:51 CEST 2014 used: 359 dpkg_conf
Wed Sep 17 10:09:38 CEST 2014 used: 525 default
Installing kde-full with policy-rc.d in place.
Wed Sep 17 10:29:33 CEST 2014 used: 424 divert
Wed Sep 17 10:36:29 CEST 2014 used: 413 dpkg_conf
Wed Sep 17 10:45:35 CEST 2014 used: 543 default
As you can see, the reduction in installation time is in the range
21-32 percent of the current default. It is not obvious to me why the
Dir::Bin::dpkg approach can be quicker than the divert approach. This
might be caused by other issues, as the last run was done just after
boot. Perhaps the order these tests are executed matter?
Anyway, just wanted to share with you this data point comparing the
different ways to speed up package installation in Debian.
test-install-speed
#!/bin/sh
suite=testing
chroot=chroot-testing
mirror=http://http.debian.net/debian
mirror=http://ftp.uio.no/debian
unset TMP TMPDIR
# Never wait for input
DEBIAN_FRONTEND=noninteractive
export DEBIAN_FRONTEND
make_chroot() {
debootstrap $suite $chroot $mirror
printf #!/bin/sh\nexit 101\n $chroot/usr/sbin/policy-rc.d
chmod a+rx $chroot/usr/sbin/policy-rc.d
chroot $chroot apt-get install -y eatmydata
}
install_chroot_pkgs() {
chroot $chroot apt-get install -y kde-full
}
test_default() {
make_chroot
install_chroot_pkgs
}
test_divert() {
make_chroot
for bin in dpkg apt-get aptitude tasksel ; do
file=/usr/bin/$bin
# Test that the file exist and have not been diverted already.
if [ -f $chroot/usr/bin/$bin ] ; then
info diverting /usr/bin/$bin using eatmydata
printf #!/bin/sh\neatmydata $bin.distrib \\$@\\n \
$chroot/usr/bin/$bin.edu
chmod 755 $chroot/usr/bin/$bin.edu
chroot $chroot dpkg-divert --package debian-edu-config \
--rename --quiet --add /usr/bin/$bin
ln -sf ./$bin.edu $chroot/usr/bin/$bin
else
error unable to divert /usr/bin/$bin, as it is missing.
fi
done
install_chroot_pkgs
}
# https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=613428
test_dpkg_conf() {
make_chroot
cat $chroot/usr/bin/dpkg-eatmydata 'EOF'
#!/bin/sh
/usr/bin/eatmydata /usr/bin/dpkg $@
EOF
chmod a+rx $chroot/usr/bin/dpkg-eatmydata
cat $chroot/etc/apt/apt.conf.d/dpkg-eatmydata EOF
Dir::Bin::dpkg /usr/bin/dpkg-eatmydata;
EOF
install_chroot_pkgs
}
for f in divert dpkg_conf default ; do
rm -rf $chroot
start=$(date +%s)
test_$f
end=$(date +%s)
(LC_ALL=C date; echo used: $(($end - $start)) $f ) test.log
done
echo
tail test.log
--
Happy hacking
Petter Reinholdtsen
--
To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#483997: dpkg: please allow for a mechanism to specify postinst ordering beyond Depends:
[Guillem Jover] Hope that explains. Thank you, it does. And after giving it some thoughts, I believe the background for my surprise is that I expect recommends to behave like depends when APT::Install-Recommends is enabled. Handling it like something else break the priciple of least surprise to me. When I added 'Recommends: apache2' to sitesummary, I expected it to behave as if it was a dependency in the default case (APT::Install-Recommends enabled) when installing sitesummary, while allowing sitesummary to be installed without apache2 (or apache2 to be removed after installation) without also having to remove sitesummary. I realise now that is not how apt and dpkg really work. Perhaps they should work like that? Am I the only one surprised by this? Policy is not mentioning anything about expected postinst ordering for recommends, but perhaps it should? -- Happy hacking Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#483997: dpkg: please allow for a mechanism to specify postinst ordering beyond Depends:
Control: block 760084 by -1 Control: block 745834 by -1 Hi. Following up on a old bug, which now affect packages related to apache2. The new apache2 postinst code need such mechanism too. I ran into this when migrating sitesummary to the new apache2 setup. The sitesummary package recommends apache2, and when apache2 is configured before sitesummary, the sitesummary server is set up automatically. But as it is only a recommends, the ordering is not guaranteed and if apache2 is unpacked before sitesummary but configured after it, the sitesummary postinst fail. This is bug URL: https://bugs.debian.org/760084 . A similar bug is URL: https://bugs.debian.org/745834 regarding the svn webdav setup. What about making sure dpkg take recommends into account when ordering postinst scripts? If package A recommends B, and both A and B is installed in the same dpkg run, the postinst scripts should run in order B.postinst, A.postinst. It would solve the problem I see, and allow for a mechanism to specify postinst ordering also for non-depend relationships. Is there a better way to fix the problems we experience in bugs #760084 and #745834? -- Happy hacking Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#483997: dpkg: please allow for a mechanism to specify postinst ordering beyond Depends:
Thank you for the quick reply. [Guillem Jover] I've not checked those bug reports, but I'm assuming that the package might also fail in case apache2 is not installed at all? Or how do you handle that case? And the subsequent missing configuration when apache2 gets installed later on? For sitesummary, the package do not fail if apache2 is not installed at all. The postinst fragment look like this: case $1 in configure) # Enable it on fresh installations as before Apache 2.4. if [ -z $2 ] \ [ -e /usr/share/apache2/apache2-maintscript-helper ] ; then . /usr/share/apache2/apache2-maintscript-helper apache2_invoke enmod cgi.load apache2_invoke enconf sitesummary.conf fi If the apache2 package isn't installed unpacked yet, the sitesummary collector CGI script will simply not be activated by default. I do not know how the svn stuff handle the case. I think using triggers would solve all your problems. It would also cover the case where a user installs sitesummary, but not apache2, and later on installs apache2. You might need to coordinate with the apache2 team to create possibly an explicit trigger name for this. Or would that not solve your problem? The reason apache2 is only a recommends is to ensure other web servers can be used with sitesummary, and that the sitesummary server scripts can be used without a web server active. I am not sure it is a good idea to activate sitesummary automatically outside the initial installaiton, and thus unsure if the trigger approach is the right one. But I will investigate. -- Happy hacking Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#483997: dpkg: please allow for a mechanism to specify postinst ordering beyond Depends:
[Guillem Jover] The problem is that it would make the dependency resolution harder, as that's in fact changing the Recommends to Depends. So dpkg would have less leeway when there are dependency cycles and similar. But see below. I've tried to understand this comment, but failed so far. My proposal would be regarding the ordering of the postinst for the set of packages already selected for installation, and thus not really affect the dependency resolution as such. Also, my proposal is for cycle free dependency trees, as package sets with cycles are already broken at a random location and thus any hope of predictable ordering of postinst execution is gone already. -- Happy hacking Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#694886: dpkg: Complain about missing descriptions for packages in /var/lib/dpkg/available
Package: dpkg Version: 1.16.9 Severity: normal Dear Maintainer, I discovered this in the installation log of a freshly installed wheezy test system. The log contained messages like this: dpkg: warning: parsing file '/var/lib/dpkg/available' near line 219 package 'libtext-wrapi18n-perl': missing description I was able to reproduce it after installation using apt-get install. See for example this run: root@skolelinuxtest:~# LANG=C apt-get install kde-i18n-nn Reading package lists... Done Building dependency tree Reading state information... Done The following extra packages will be installed: kde-l10n-nn The following NEW packages will be installed: kde-i18n-nn kde-l10n-nn 0 upgraded, 2 newly installed, 0 to remove and 0 not upgraded. Need to get 1410 kB of archives. After this operation, 5903 kB of additional disk space will be used. Do you want to continue [Y/n]? Get:1 http://ftp.no.debian.org/debian/ wheezy/main kde-l10n-nn all 4:4.8.4-2 [1403 kB] Get:2 http://ftp.debian.org/debian/ squeeze/main kde-i18n-nn all 4:4.4.5-1 [7014 B] Fetched 1410 kB in 1s (1248 kB/s) dpkg: warning: parsing file '/var/lib/dpkg/available' near line 219 package 'libtext-wrapi18n-perl': missing description dpkg: warning: parsing file '/var/lib/dpkg/available' near line 296 package 'libustr-1.0-1:i386': missing description dpkg: warning: parsing file '/var/lib/dpkg/available' near line 471 package 'debconf': missing description dpkg: warning: parsing file '/var/lib/dpkg/available' near line 720 package 'dash': missing description dpkg: warning: parsing file '/var/lib/dpkg/available' near line 1384 package 'coreutils': missing description dpkg: warning: parsing file '/var/lib/dpkg/available' near line 1571 package 'debianutils': missing description dpkg: warning: parsing file '/var/lib/dpkg/available' near line 2058 package 'login': missing description dpkg: warning: parsing file '/var/lib/dpkg/available' near line 3292 package 'libuuid1:i386': missing description dpkg: warning: parsing file '/var/lib/dpkg/available' near line 3604 package 'lsb-base': missing description dpkg: warning: parsing file '/var/lib/dpkg/available' near line 4765 package 'ncurses-base': missing description dpkg: warning: parsing file '/var/lib/dpkg/available' near line 4869 package 'libpam0g:i386': missing description dpkg: warning: parsing file '/var/lib/dpkg/available' near line 5374 package 'bsdutils': missing description dpkg: warning: parsing file '/var/lib/dpkg/available' near line 5495 package 'sensible-utils': missing description dpkg: warning: parsing file '/var/lib/dpkg/available' near line 6915 package 'ncurses-bin': missing description dpkg: warning: parsing file '/var/lib/dpkg/available' near line 6948 package 'perl-base': missing description dpkg: warning: parsing file '/var/lib/dpkg/available' near line 7012 package 'sysv-rc': missing description dpkg: warning: parsing file '/var/lib/dpkg/available' near line 8614 package 'libsepol1:i386': missing description dpkg: warning: parsing file '/var/lib/dpkg/available' near line 8706 package 'libpam-modules:i386': missing description dpkg: warning: parsing file '/var/lib/dpkg/available' near line 8786 package 'tzdata': missing description dpkg: warning: parsing file '/var/lib/dpkg/available' near line 9138 package 'libsemanage1:i386': missing description dpkg: warning: parsing file '/var/lib/dpkg/available' near line 10439 package 'diffutils': missing description dpkg: warning: parsing file '/var/lib/dpkg/available' near line 11212 package 'tar': missing description dpkg: warning: parsing file '/var/lib/dpkg/available' near line 11688 package 'libmount1': missing description dpkg: warning: parsing file '/var/lib/dpkg/available' near line 12084 package 'zlib1g:i386': missing description dpkg: warning: parsing file '/var/lib/dpkg/available' near line 13188 package 'libgcc1:i386': missing description dpkg: warning: parsing file '/var/lib/dpkg/available' near line 14136 package 'base-files': missing description dpkg: warning: parsing file '/var/lib/dpkg/available' near line 14260 package 'mount': missing description dpkg: warning: parsing file '/var/lib/dpkg/available' near line 14514 package 'libtext-iconv-perl': missing description dpkg: warning: parsing file '/var/lib/dpkg/available' near line 15042 package 'libncurses5:i386': missing description dpkg: warning: parsing file '/var/lib/dpkg/available' near line 17250 package 'libattr1:i386': missing description dpkg: warning: parsing file '/var/lib/dpkg/available' near line 17664 package 'sed': missing description dpkg: warning: parsing file '/var/lib/dpkg/available' near line 18677 package 'e2fslibs:i386': missing description dpkg: warning: parsing file '/var/lib/dpkg/available' near line 19291 package 'base-passwd': missing description dpkg: warning: parsing file '/var/lib/dpkg/available' near line 19618 package
Bug#694886: dpkg: Complain about missing descriptions for packages in /var/lib/dpkg/available
[Guillem Jover] Was it obvious from the log when did it start to warn? Yes. It happened while deboostrap was running. Just after e2fsprogs was configured and before adduser was unpacked: Dec 1 17:16:00 debootstrap: Setting up sysvinit (2.88dsf-34) ... Dec 1 17:16:00 debootstrap: sysvinit: creating /run/initctl Dec 1 17:16:00 debootstrap: Not restarting sysvinit: init not running Dec 1 17:16:00 debootstrap: Setting up e2fsprogs (1.42.5-1) ... Dec 1 17:16:00 debootstrap: dpkg: warning: parsing file '/var/lib/dpkg/available' near line 35 package 'libc-bin': Dec 1 17:16:00 debootstrap: missing description [...] Dec 1 17:16:01 debootstrap: missing description Dec 1 17:16:01 debootstrap: dpkg: warning: parsing file '/var/lib/dpkg/available' near line 3870 package 'whiptail': Dec 1 17:16:01 debootstrap: missing description Dec 1 17:16:01 debootstrap: (Reading database ... Dec 1 17:16:01 debootstrap: 6256 files and directories currently installed.) Dec 1 17:16:01 debootstrap: Unpacking adduser (from .../adduser_3.113+nmu3_all.deb) ... Dec 1 17:16:01 debootstrap: Unpacking libstdc++6:i386 (from .../libstdc++6_4.7.2-4_i386.deb) ... Dec 1 17:16:01 debootstrap: Unpacking libapt-pkg4.12:i386 (from .../libapt-pkg4.12_0.9.7.6_i386.deb) ... Dec 1 17:16:02 debootstrap: Unpacking gpgv (from .../gpgv_1.4.12-6_i386.deb) ... Maybe the file was not right from the start; I'm not sure if d-i populates it. No idea. :) -- Happy hacking Petter Reinholdtsn -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#613428: dpkg --force-unsafe-io still calls fsync()
[ Mike Hommey ] While this is stricly true, there are still two fsync()s occuring on each package unpack, making the whole thing still slow when installing many packages at a time. These happen for /var/lib/dpkg/updates and /var/lib/dpkg/tmp.ci. [ Raphael Hertzog ] This is on purpose. Can you explain in which situation where --force-unsafe-io is used that you believe these fsync()s to be an advantage? I've tried to come up with such scenarios without any luck so far. The users of --force-unsafe-io seem to be those that know that if something go wrong during installation, they scratch everything and start again, and finishing quickly is more important than handling power outages. One example is building live CDs. Another is installing the system for the first time. A third is creating chroots for testing. In all these cases any power outage or other system failure will make one erase everything and start over, and there is no need for dpkg to keep an consistent state. I would love my distro upgrade test to become faster and thus hope also these fsyncs can go away. I install stable in a chroot, dist-upgrade to testing, and check the rsult. If the something go wrong I remove the chroot and start over, so there is no need for any sync to disk. :) -- Happy hacking Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#613428: dpkg --force-unsafe-io still calls fsync()
Thank you for the quick reply. I wish you a happy new year. :) [Raphael Hertzog] This is an option that we wish it did not exist. OK. Still do not explain to me in what situation or use case it is useful drop fsync() for the package files while still using fsync() on /var/lib/dpkg/updates and /var/lib/dpkg/tmp.ci. I assume there is such usecase, given that the option is working the way it is. The proper approach is to enhance your testing tools to use eatmydata to really disable all fsync() and not only those of dpkg. It is not really possible to do this without rewriting all of Debian to allow it. While adding a file to gain a similar effect is possible. I tried to get eatmydata to work, but there are just too many packages that would need to change for it to have the desired effect. --force-unsafe-io has not been meant for those use case at all, it was meant for some users to gain back some performance lost on supplementary fsync() that have been added to dpkg. It was not meant to disable all fsync() and in particular not those on the database. I would expect these users to also want the extra performance gained by dropping the left behind fsyncs()? Why should this use case want the remaining fsync()s in place? -- Happy hacking Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#613428: dpkg --force-unsafe-io still calls fsync()
[Raphael Hertzog] Because they care about the integrity of their system? We de not want to make it easy to corrupt your dpkg database. Your comment do not make sense to me. I fail to understand how those caring about the integrity of their system during the dpkg run would use --force-unsafe-io. At least I only use it if I care about speed, and would be happy to start again if something went wrong half-way through the installation. When I use it, I do not care about the integrity, and neither do those building live CDs. :) Anyway, hopefully someone some time in the future will come up with a usecase that could make me understand when it is useful to not fsync the package files and only fsync the dpkg database. -- Happy hacking Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Dependency based boot sequencing and triggers (Was: dpkg semi-hijack - an announcement (also, triggers))
[Mike Bird] I hope I'm not mis-stating Frans's position when I say that Frans believes dpkg triggers are the best way to install dependency-based initscripts[0]. I believe your understanding of Frans' position is fairly correct, but it differ from mine, and I am the one behind the dependency boot sequencing proposal. I am not convinced yet that triggers are needed, nor wanted, for dependency boot sequencing. This is partly because I believe the failure modes Frans mention in his post are unlikely to happen (or impossible, but it is harder to prove). So those of you wanting to test dependency based boot sequencing do not have to wait for triggers for it to work properly. 80% of the packages got the dependency headers already, and those already using it report that it work quite well. :) More information on the feature is available from URL:http://wiki.debian.org/LSBInitScripts/DependencyBasedBoot. Otherwise the installer unnecessarily and repetitively globally recalculates initscript dependencies for each package installed. Actually, it happens every time a init.d script is added to the boot and shutdown sequence, and I believe it have to do that, to make sure each script insertion fail individually when a script with incorrect dependency information is encountered. I will have to learn more about triggers before I make up my mind, though. Happy hacking, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#458523: dpkg-query: Missing newline make output hard/impossible to parse
Package: dpkg
Version: 1.14.14
Severity: important
When trying to list all obsolete init.d scripts that are conffiles, I
ran into a problem with the output from dpkg-query. The reason is
that there is no newline between the list of files between different
packages.
Here is an example to demonstrate the problem:
minerva:/# dpkg-query -W -f='${Conffiles}' | grep /etc/init.d/init.d |grep
obsolete|head -2
/etc/init.d/loadcpufreq 5cf8c5572d789beaf18d79fc52f95665 obsolete
/etc/fonts/conf.d/unhinted.conf 4070b0651a9e3e0d26a77d6cc6f7e575 obsolete
/etc/init.d/fuse 0a6a4540ffd72926dbb9f12d9f1ad31d
minerva:/#
Notice how there is no newline between 'obsolete' and
'/etc/init.d/fuse'.
Please change the output from dpkg-query to add a newline between
entries for different packages.
Happy hacking,
--
Petter Reinholdtsen
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#148221: dpkg: Small off by one error in parseversion()
Package: dpkg
Version: 1.9.21
Severity: normal
Tags: patch
The following patch fixes a off by one error in dpkg. It reads one
past the allocated buffer.
I discovered it using valgrind,
URL:http://developer.kde.org/~sewardj/.
--- lib/parsehelp.c.origSun May 26 19:24:23 2002
+++ lib/parsehelp.c Sun May 26 19:22:34 2002
@@ -214,7 +214,7 @@
} else {
rversion-epoch= 0;
}
- rversion-version= nfstrnsave(string,end-string+1);
+ rversion-version= nfstrnsave(string,end-string);
hyphen= strrchr(rversion-version,'-');
if (hyphen) *hyphen++= 0;
rversion-revision= hyphen ? hyphen : ;
-- System Information
Debian Release: 3.0
Architecture: i386
Kernel: Linux diskless 2.4.18-686 #2 Wed Mar 20 20:21:31 EST 2002 i686
Locale: LANG=C, LC_CTYPE=no_NO
Versions of packages dpkg depends on:
ii libc62.2.5-6 GNU C Library: Shared libraries an
ii libncurses5 5.2.20020112a-7 Shared libraries for terminal hand
ii libstdc++2.10-glibc2.2 1:2.95.4-7 The GNU stdc++ library
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
