[SCM] dpkg's main repository branch, master, updated. 1.14.20-100-g4174eea
The following commit has been merged in the master branch: commit 4174eea758751055dc36caf3941368fe12148bd9 Author: Kenshi Muto [EMAIL PROTECTED] Date: Sun Jul 6 18:41:12 2008 +0900 update Japanese translation diff --git a/po/ja.po b/po/ja.po index 989d367..42bc26c 100644 --- a/po/ja.po +++ b/po/ja.po @@ -14,13 +14,13 @@ # dpkg 用の日本語メッセージ (Linux/GNU Debian). # Copyright (C) 1998 Masato Taruishi [EMAIL PROTECTED] # Copyright (C) 1999-2004 Keita Maehara [EMAIL PROTECTED] -# Copyright (C) 2004-2007 Kenshi Muto [EMAIL PROTECTED] +# Copyright (C) 2004-2008 Kenshi Muto [EMAIL PROTECTED] msgid msgstr -Project-Id-Version: dpkg 1.13 r503\n +Project-Id-Version: dpkg git\n Report-Msgid-Bugs-To: [EMAIL PROTECTED] POT-Creation-Date: 2008-05-13 05:54+0300\n -PO-Revision-Date: 2007-12-20 14:53+0900\n +PO-Revision-Date: 2008-07-06 18:35+0900\n Last-Translator: Kenshi Muto [EMAIL PROTECTED]\n Language-Team: Debian Japanease List [EMAIL PROTECTED]\n MIME-Version: 1.0\n @@ -490,35 +490,34 @@ msgid alternatives (`|') not allowed in %s field msgstr 選択記号 (`|') は %s フィールド内では許可されていません #: lib/fields.c:508 -#, fuzzy msgid value for `triggers-pending' field not allowed in this context msgstr -`config-version' フィールドの値はこのコンテキストでは許可されていません +`triggers-pending' フィールドの値はこのコンテキストでは許可されていません #: lib/fields.c:514 -#, fuzzy, c-format +#, c-format msgid illegal pending trigger name `%.255s': %s -msgstr `%s' フィールド、無効なパッケージ名 `%.255s': %s +msgstr 無効な保留トリガ名 `%.255s': %s #: lib/fields.c:518 #, c-format msgid duplicate pending trigger `%.255s' -msgstr +msgstr 重複する保留トリガ `%.255s' #: lib/fields.c:533 -#, fuzzy msgid value for `triggers-awaited' field not allowed in this context -msgstr `status' フィールドの値はこのコンテキストでは許可されていません +msgstr +`triggers-awaited' フィールドの値はこのコンテキストでは許可されていません #: lib/fields.c:539 -#, fuzzy, c-format +#, c-format msgid illegal package name in awaited trigger `%.255s': %s -msgstr %d 行目のパッケージ名は不正です: %.250s +msgstr 待ち受けトリガ `%.255s' に不正なパッケージ名があります : %s #: lib/fields.c:545 -#, fuzzy, c-format +#, c-format msgid duplicate awaited trigger package `%.255s' -msgstr パッケージ `%.250s' のファイル一覧 +msgstr 重複する待ち受けトリガパッケージ `%.255s' #: lib/lock.c:47 msgid unable to unlock dpkg status database @@ -556,9 +555,8 @@ msgid realloc failed (%ld bytes) msgstr realloc 失敗 (%ld バイト) #: lib/mlib.c:78 -#, fuzzy msgid failed to allocate memory -msgstr ディレクトリの作成に失敗しました +msgstr メモリの割り当てに失敗しました #: lib/mlib.c:85 #, c-format @@ -817,20 +815,20 @@ msgstr 不適切なステータスを持つパッケージの Configured-Versio #: lib/parse.c:271 #, c-format msgid package has status %s but triggers are awaited -msgstr +msgstr パッケージは状態 %s ですが、トリガを待ち受けています #: lib/parse.c:275 msgid package has status triggers-awaited but no triggers awaited -msgstr +msgstr パッケージはトリガ待ち受けの状態ですが、待ち受けトリガはありません #: lib/parse.c:281 #, c-format msgid package has status %s but triggers are pending -msgstr +msgstr パッケージは状態 %s ですが、トリガは保留されています #: lib/parse.c:285 msgid package has status triggers-pending but no triggers pending -msgstr +msgstr パッケージはトリガ保留の状態ですが、保留トリガはありません #: lib/parse.c:295 msgid Package which in state not-installed has conffiles, forgetting them @@ -929,69 +927,73 @@ msgstr フォーマットに閉じ括弧 (}) が抜けています\n #, c-format msgid invalid package name `%.250s' in triggers deferred file `%.250s' msgstr +延期されたファイル `%2$.250s' のトリガに無効なパッケージ名 `%1$.250s' があり +ます #: lib/trigdeferred.l:71 -#, fuzzy, c-format +#, c-format msgid truncated triggers deferred file `%.250s' -msgstr statoverride ファイル `%.250s' +msgstr 延期されたファイル `%.250s'のトリガが切り詰められました #: lib/trigdeferred.l:75 #, c-format msgid syntax error in triggers deferred file `%.250s' at character `%s'%s msgstr +延期されたファイル `%.250s' のトリガの文字 `%s'%s の位置に文法エラーがありま +す #: lib/trigdeferred.l:112 -#, fuzzy, c-format +#, c-format msgid unable to open/create triggers lockfile `%.250s' -msgstr ソースファイル `%.250s' をオープンできません +msgstr ロックファイル `%.250s' のトリガをオープンおよび作成できません #: lib/trigdeferred.l:119 -#, fuzzy msgid unable to lock triggers area -msgstr %s のロックを解除できません: %s +msgstr トリガエリアをロックできません #: lib/trigdeferred.l:130 -#, fuzzy, c-format +#, c-format msgid unable to stat triggers deferred file `%.250s' -msgstr その他の新しいファイル `%.250s' の状態を取得できません +msgstr 延期されたファイル `%.250s' のトリガの状態を取得できません #: lib/trigdeferred.l:144 -#, fuzzy, c-format +#, c-format msgid unable to open triggers deferred file `%.250s' -msgstr ソースファイル `%.250s' をオープンできません +msgstr 延期されたファイル `%.250s' のトリガをオープンできません #: lib/trigdeferred.l:158 -#, fuzzy, c-format +#, c-format msgid unable to open/create new triggers deferred file `%.250s' -msgstr 新しい格納ファイル `%.250s' をオープンできません +msgstr +延期されたファイル `%.250s' の新しいトリガをオープンおよび作成できません #: lib/trigdeferred.l:178 -#, fuzzy, c-format +#, c-format msgid error reading triggers deferred file `%.250s' -msgstr ファイル %2$.255s からの %1$s の読み取り中にエラーが発生しました +msgstr 延期されたファイル `%.250s' のトリガの読み取り中にエラーが発生しました #: lib/trigdeferred.l:186 -#, fuzzy, c-format +#, c-format msgid unable to write new triggers deferred file
[SCM] dpkg's main repository branch, master, updated. 1.14.20-101-gcf6b114
The following commit has been merged in the master branch:
commit cf6b114b9b21840a55d5618910be6f4db1a9295c
Author: Michel Lespinasse [EMAIL PROTECTED]
Date: Sun Jul 6 20:45:48 2008 +0200
Reduce dselect memory usage
* dselect/baselist.cc (baselist::startdisplay): Create the
pad with the list of the size of the display and not of the
size of the list content itself.
* dselect/basetop.cc (baselist::refreshlist): The part to
display is always at the top of the pad.
(baselist::redrawitemsrange): Simplified to redraw the real
range only.
* dselect/pkglist.cc (packagelist::sortmakeheads): No need to reallocate
the pad when the list changes.
* dselect/pkgtop.cc (packagelist::redraw1itemsel): The line
of the item in the infopad doesn't correspond to its index in
the list any more. Adjust accordingly.
diff --git a/ChangeLog b/ChangeLog
index d002876..a7a2094 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,18 @@
+2008-07-06 Michel Lespinasse [EMAIL PROTECTED]
+
+ * dselect/baselist.cc (baselist::startdisplay): Create the
+ pad with the list of the size of the display and not of the
+ size of the list content itself.
+ * dselect/basetop.cc (baselist::refreshlist): The part to
+ display is always at the top of the pad.
+ (baselist::redrawitemsrange): Simplified to redraw the real
+ range only.
+ * dselect/pkglist.cc (packagelist::sortmakeheads): No need to reallocate
+ the pad when the list changes.
+ * dselect/pkgtop.cc (packagelist::redraw1itemsel): The line
+ of the item in the infopad doesn't correspond to its index in
+ the list any more. Adjust accordingly.
+
2008-07-05 Guillem Jover [EMAIL PROTECTED]
* src/archives.c (filesavespackage): Do not mark debug message for
diff --git a/THANKS b/THANKS
index 9fe8302..81fd913 100644
--- a/THANKS
+++ b/THANKS
@@ -121,6 +121,7 @@ Michael Alan Dorman [EMAIL PROTECTED]
Michael Shields [EMAIL PROTECTED]
Michael Sobolev [EMAIL PROTECTED]
Michael Vogt [EMAIL PROTECTED]
+Michel Lespinasse [EMAIL PROTECTED]
Miguel Figueiredo [EMAIL PROTECTED]
Miquel van Smoorenburg [EMAIL PROTECTED]
Miroslav Kure [EMAIL PROTECTED]
diff --git a/debian/changelog b/debian/changelog
index 40bbb89..eecb539 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -64,6 +64,9 @@ dpkg (1.15.0) UNRELEASED; urgency=low
Thanks to Thomas Hood [EMAIL PROTECTED]. Closes: #107098
* Use description of installed package as fallback in dselect.
Based on a patch from Bruce Sass [EMAIL PROTECTED]. Closes: #21659
+ * Reduce memory usage of dselect by avoiding usage of a big infopad.
+Thanks to Michel Lespinasse [EMAIL PROTECTED] for the patch.
+Closes: #395140
[ Pierre Habouzit ]
* Add a --query option to update-alternatives. Closes: #336091, #441904
diff --git a/dselect/baselist.cc b/dselect/baselist.cc
index e7768a3..82ce4fa 100644
--- a/dselect/baselist.cc
+++ b/dselect/baselist.cc
@@ -171,7 +171,7 @@ void baselist::startdisplay() {
if (!whatinfowin) ohshite(_(failed to create whatinfo window));
wattrset(whatinfowin,whatinfo_attr);
- listpad= newpad(nitems+1, total_width);
+ listpad = newpad(ymax, total_width);
if (!listpad) ohshite(_(failed to create baselist pad));
colheadspad= newpad(1, total_width);
diff --git a/dselect/basetop.cc b/dselect/basetop.cc
index 6297ba8..85b63ed 100644
--- a/dselect/basetop.cc
+++ b/dselect/basetop.cc
@@ -39,7 +39,7 @@ void baselist::refreshlist() {
list_row + nitems - topofscreen - 1);
x= lesserint(total_width - leftofscreen - 1,
xmax - 1);
- pnoutrefresh(listpad, topofscreen,leftofscreen, list_row,0, y,x);
+ pnoutrefresh(listpad, 0, leftofscreen, list_row, 0, y, x);
getmaxyx(listpad,maxy,maxx);
y++;
while (y list_row + list_height - 1) {
@@ -49,9 +49,10 @@ void baselist::refreshlist() {
}
void baselist::redrawitemsrange(int start, int end) {
- if (ldrawnstart==-1) { ldrawnstart= ldrawnend= end; }
- while (ldrawnstart start) { ldrawnstart--; redraw1item(ldrawnstart); }
- while (ldrawnend end) { redraw1item(ldrawnend); ldrawnend++; }
+ int i;
+ for (i = start; i end; i++) {
+redraw1item(i);
+ }
}
void baselist::refreshcolheads() {
diff --git a/dselect/pkglist.cc b/dselect/pkglist.cc
index 53bf43a..0621819 100644
--- a/dselect/pkglist.cc
+++ b/dselect/pkglist.cc
@@ -344,15 +344,7 @@ void packagelist::sortmakeheads() {
}
if (listpad) {
-int maxx, maxy;
-getmaxyx(listpad,maxx,maxy);
-if (nitems maxy) {
- delwin(listpad);
- listpad= newpad(nitems+1, total_width);
- if (!listpad) ohshite(failed to create larger baselist pad);
-} else if (nitems maxy) {
- werase(listpad);
-}
+werase(listpad);
}
sortinplace();
diff --git a/dselect/pkgtop.cc b/dselect/pkgtop.cc
index 3022c50..8876e7d 100644
--- a/dselect/pkgtop.cc
+++ b/dselect/pkgtop.cc
@@ -139,6 +139,7
Re: [SCM] dpkg's main repository branch, master, updated. 1.14.20-100-g4174eea
Hi, On Sun, 06 Jul 2008, Kenshi Muto wrote: The following commit has been merged in the master branch: commit 4174eea758751055dc36caf3941368fe12148bd9 Author: Kenshi Muto [EMAIL PROTECTED] Date: Sun Jul 6 18:41:12 2008 +0900 update Japanese translation Please don't start translating the master branch until Lenny is released. It will complicate merging from one branch to the other. Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [SCM] dpkg's main repository branch, master, updated. 1.14.20-100-g4174eea
Quoting Raphael Hertzog ([EMAIL PROTECTED]): Please don't start translating the master branch until Lenny is released. It will complicate merging from one branch to the other. I'm not convinced this would be a great idea to merge po/ directories with the VCS merge facilities. I think that the following would be much more efficient: (assuming that a copy of the lenny branch is in lenny/ and a copy of master is in master/) cd master/po (do all magic to update dpkg.pot with current source) mkdir NEW for i in *.po ; do if [ -f ../../lenny/po/$i ] ; then msgcat --use-first ../../lenny/po/$i $i NEW/$i msgmerge -U NEW/$i dpkg.pot fi done mv NEW/* . rmdir NEW The git add *.po and git commit -m'Resync with lenny branch' That would guarantee a better and more efficient merge and fuzzy matching as that will use the gettext functions for that. I would recommend repeating this for all po/ directories. signature.asc Description: Digital signature
Re: [SCM] dpkg's main repository branch, master, updated. 1.14.20-100-g4174eea
Hi Raphael, At Sun, 6 Jul 2008 12:23:33 +0200, Raphael Hertzog wrote: Please don't start translating the master branch until Lenny is released. It will complicate merging from one branch to the other. Sorry. I did it because I got an error when was commiting once for lenny branch. Anyway I memorize your advice for next time. Thanks, -- Kenshi Muto [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFC: Idea for improved diversions and alternatives handling
Goswin von Brederlow wrote: working on dpkg reminded me that I wanted to propose a better diversion and alternatives handling for debian packages. Currently they have to be manually added and removed in the maintainer scripts. This method is prone to errors and can easily leave diversions or alternatives behind. Instead I suggest creating two new control files detailing the diversions and alternatives a package should have. Can symlinks be supported in the declarative control file stanzas? One problem within Emdebian is replacing coreutils etc. with busybox - currently we are having to use a rigid replacement where the options enabled in busybox must be removed from the package set (or added as Conflicts: in busybox) and then the symlinks for each applet are listed in the dpkg file list. This requires a particular level of coordination and makes it harder to customise Emdebian for a different scenario. If both /bin/foo and /bin/bar are called during the boot/init process, the issue is allowing for this scenario: Install package foo, includes symlink /bin/bar - /bin/foo Also includes a variety of others (about 30 in total). At a later date, the installation needs to be customised to allow the full version of /bin/bar from package bar to be installed for extra functionality. If Replaces: is used, bar cannot be removed because the box would not be bootable anymore - the previous symlink has gone forever. How to divert a symlink such that it can be restored later? Alternatives isn't a good solution because it means reimplementing the alternatives support code to avoid the use of Perl - and alternatives (IIRC) does not support symlinks as alternatives. What I need to avoid is having to make dozens of changes to postinst scripts to enable diversions in a long list of packages. Busybox 1.10.3 (not yet in Debian) does support discrete binaries linked to a shared library version of busybox but the library is bigger than the current busybox binary and each discrete binary is just over 4Kb so that is an appreciable increase in total size. (Seeing as this is busybox, size increases must be avoided.) It would allow the use of alternatives (subject to replacement non-perl code) but that method also needs changes in other packages (currently). So that costs an extra 2Mb or so and involves rewriting the code supporting alternatives - not my favourite option when the entire OS has to fit into 32Mb (or 64Mb for a full GUI using glibc). -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ signature.asc Description: This is a digitally signed message part
Re: [SCM] dpkg's main repository branch, master, updated. 1.14.20-100-g4174eea
On Sun, 06 Jul 2008, Christian Perrier wrote: I'm not convinced this would be a great idea to merge po/ directories with the VCS merge facilities. If we have conflicts, the merge is a pain and we should use msgmerge to merge properly both files. But if we have no conflicts (because the po files have not been modified since the creation of the branch that we're merging), then the VCS merge functionnality is fine... I think that the following would be much more efficient: It would be great to have such a script to merge all translations from another branch in the current branch. (assuming that a copy of the lenny branch is in lenny/ and a copy of master is in master/) One should not make such an assumption... we have a single repository in the git model. But we have tools to use to extract files from another branch. git-unpack-file / git-cat-file to extract blog objects but I don't know yet how to identify the blog id of a given file in another branch. Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [SCM] dpkg's main repository branch, master, updated. 1.14.20-100-g4174eea
Raphael Hertzog [EMAIL PROTECTED] writes: On Sun, 06 Jul 2008, Christian Perrier wrote: I'm not convinced this would be a great idea to merge po/ directories with the VCS merge facilities. If we have conflicts, the merge is a pain and we should use msgmerge to merge properly both files. But if we have no conflicts (because the po files have not been modified since the creation of the branch that we're merging), then the VCS merge functionnality is fine... Not that I have time to write this, but Git does support custom merge drivers and Christian's merge strategy could, I think, be implemented in one. Then Git would use msgmerge automatically for conflicts between *.po files. gitattributes(5) has the details under Defining a custom merge driver. It looks like the only hard part would be finding the *.pot file with which to msgmerge. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [SCM] dpkg's main repository branch, master, updated. 1.14.20-100-g4174eea
On Sun, 06 Jul 2008, Raphael Hertzog wrote: It would be great to have such a script to merge all translations from another branch in the current branch. (assuming that a copy of the lenny branch is in lenny/ and a copy of master is in master/) One should not make such an assumption... we have a single repository in the git model. But we have tools to use to extract files from another branch. git-unpack-file / git-cat-file to extract blog objects but I don't know yet how to identify the blog id of a given file in another branch. git show branch:filename -- is the proper answer apparently. Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [SCM] dpkg's main repository branch, master, updated. 1.14.20-100-g4174eea
Hello, On Sun, Jul 06, 2008 at 11:01:12AM -0700, Russ Allbery wrote: It looks like the only hard part would be finding the *.pot file with which to msgmerge. msgmerge is not necessary. msgcat will take care of merging the two PO files. The final merge will be done by make update-po. Best Regards, -- Nekral -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#483418: Not limit dpkg-divert to install but valid also for upgrade in app.
Thanks for the review! Raphael Hertzog [EMAIL PROTECTED] writes: On Sat, 05 Jul 2008, Russ Allbery wrote: The postrm has to do the reverse: example - if [ remove = $1 ]; then + if [ remove = $1 -o abort-install = $1 -o disappear = $1 ]; then To be really complete we should also handle the abort-upgrade if the old version had no diversion... but that would make it too complicated for its purpose. Oh, hm, yes, the new postrm abort-upgrade is called in a useful place for it to fix this. But the abort-upgrade case would need to test the version number from which we're upgrading to determine whether to roll back the diversion. Since this is Policy (even an appendix), and since the failure case is what people most frequently get wrong, I think I'd like to try to capture the whole situation. Do you think that something like this is more confusing than it's worth? I think it is the fully correct handling. diff --git a/policy.sgml b/policy.sgml index 7d54e29..5975d37 100644 --- a/policy.sgml +++ b/policy.sgml @@ -10550,26 +10550,48 @@ install-info --quiet --remove /usr/share/info/foobar.info supposing that a prgnsmailwrapper/prgn package wishes to install a wrapper around file/usr/sbin/smail/file: example - if [ install = $1 ]; then - dpkg-divert --package smailwrapper --add --rename \ ---divert /usr/sbin/smail.real /usr/sbin/smail - fi - /example Testing tt$1/tt is necessary so that the script - doesn't try to add the diversion again when - prgnsmailwrapper/prgn is upgraded. The tt--package - smailwrapper/tt ensures that prgnsmailwrapper/prgn's - copy of file/usr/sbin/smail/file can bypass the diversion and - get installed as the true version. + dpkg-divert --package smailwrapper --add --rename \ + --divert /usr/sbin/smail.real /usr/sbin/smail + /example The tt--package smailwrapper/tt ensures that + prgnsmailwrapper/prgn's copy of file/usr/sbin/smail/file + can bypass the diversion and get installed as the true version. + It's safe to add the diversion unconditionally on upgrades since + it will be left unchanged if it already exists, but + prgndpkg-divert/prgn will display a message. To suppress that + message, make the command conditional on the version from which + the package is being upgraded: + example + if [ upgrade != $1 ] || dpkg --compare-versions $2 lt 1.0-2; then + dpkg-divert --package smailwrapper --add --rename \ + --divert /usr/sbin/smail.real /usr/sbin/smail + fi + /example where tt1.0-2/tt is the version at which the + diversion was first added to the package. Running the command + during abort-upgrade is pointless but harmless. /p p The postrm has to do the reverse: example - if [ remove = $1 ]; then + if [ remove = $1 -o abort-install = $1 -o disappear = $1 ]; then + dpkg-divert --package smailwrapper --remove --rename \ +--divert /usr/sbin/smail.real /usr/sbin/smail + fi + /example If the diversion was added at a particular version, the + postrm should also handle the failure case of upgrading from an + older version (unless the older version is so old that direct + upgrades are no longer supported): + example + if [ abort-upgrade = $1 ] dpkg --compare-versions $2 lt 1.0-2; then dpkg-divert --package smailwrapper --remove --rename \ --divert /usr/sbin/smail.real /usr/sbin/smail fi - /example + /example where tt1.02-2/tt is the version at which the + diversion was first added to the package. The postrm should not + remove the diversion on upgrades both because there's no reason to + remove the diversion only to immediately re-add it and since the + postrm of the old package is run after unpacking so the removal of + the diversion will fail. /p p -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#483418: Not limit dpkg-divert to install but valid also for upgrade in app.
On Sun, 06 Jul 2008, Russ Allbery wrote: Since this is Policy (even an appendix), and since the failure case is what people most frequently get wrong, I think I'd like to try to capture the whole situation. Do you think that something like this is more confusing than it's worth? I think it is the fully correct handling. It looks fine, yes. Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#395140: dselect memory usage is high
Hello, On Tue, 24 Oct 2006, Michel Lespinasse wrote: dselect select seems to take about 48 MB while displaying the packages, this causes a small-memory system (32MB) to go heavily into swap. A quick run with valgrind --tool=massif reveals that about 15MB are allocated by 'newpad'. Apparently dselect creates a 2-line ncursed pad to hold the package list. Since the same information is also present as part of the in-memory package database, it might be possible to save the memory by generating a smaller pad for just the part of the list that's being shown at any given time. This change is reasonable IMO. I updated the patch and pushed it here: http://git.debian.org/?p=users/hertzog/dpkg.git;a=shortlog;h=refs/heads/pu/bug395140-dselect-memory-usage I tested it and it works fine apparently. I'll merge it if nobody expresses any concern. On Fri, 27 Oct 2006, Michel Lespinasse wrote: The attached patch helps with low-memory performance by implementing segregated memory storage. A separate obstack is used for allocating information related to the Installed-Size, Origin, Maintainer, Bugs, Architecture, Source, Filename, Size, MD5sum, MSDOS-Filename and Description fields, as well as any arbitrary field contents (which these days seems to include SHA1, SHA256, Tag and Task fields). I don't think that we want such a change. It will apply both to dselect and to dpkg, and it's probably not desirable in general. It would be fine-tuning generic code for a specific use case and that doesn't make sense. On Sat, 28 Oct 2006, Michel Lespinasse wrote: This change reworks parse.c to avoid mmapping the entire file, which reduces memory usage by up to 20MB when parsing the available file. This patch will also not be merged IMO. We have some other patches/branches that will change the parsing code to be a flex-based parser and this should resolve this concern too. Thanks for the work and analysis anyway! Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#316521: dpkg: don't forget to delete directories
tags 316521 - patch retitle 316521 dpkg forgets shared directories containing manually generated files which are removed by postrm purge thanks The situation on this bug is a bit complicated so I'll make a summary... I took some time to read everything. First of all, Frank fixed the bulk of the initial problem by deferring removal of directories containing conffiles to after the purge. This is commit e0bea5706dd1a0accb39a28f7002d30c10b4caa6 that got fixed in dpkg 1.13.20. However we still have one scenario where dpkg forgets (rightfully) that a directory is part of a package because the package doesn't have any packaged file inside that directory: it's when the directory is shared with other packages. Obviously dpkg can't remove the dir since it's still in active use by other packages. The problem appears however when the just removed (and not yet purged) package is responsible of a manually generated file inside that directory. When all the other packages that share the directory are removed, nobody owns the directory and even purging the package that created the last file left, the directory won't be removed as it's no more associated to it. Bart proposed a patch that basically forbids dpkg to forget the directories as long as they are shared by multiple packages (see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=318825#27). This is definitely not the proper solution as all removed packages would be listed as owner of directories that they shouldn't own anymore. Until we provide a way for packages to teach what files are generated by each package, I only see two solutions: - either we define that the postrm purge should try to remove parent directories too - or we ask dpkg to remember directories that it can't remove if they contain at least one file not owned by any package and if they have a postrm script (this is the smallest subset of packages that we can identify and that could be responsible of the removal of the given directory) Cheers, PS: FTR, the bulk of the discussion is in 318825 and 348133. -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#102609: dpkg: --force-confask - replace conffiles with no new version
Hi Henning, On Fri, 26 Dec 2003, Henning Makholm wrote: This patch adds a force option to dpkg which will cause it to offer to replace a locally changed conffile with the file provided in the .deb even if the .deb's file has not changed since the current installation. I find this option useful too. Would you be interested in updating your patch for the current codebase of dpkg ? If yes, see http://wiki.debian.org/Teams/Dpkg/GitUsage for instructions to grab the git repository. Provide me a patch against the master branch and I'll merge it if it's fine. Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#397121: unnecessary dpkg accesses to the available file
Hi, On Sun, 2006-11-05 at 02:55:58 -0800, Michel Lespinasse wrote: Package: dpkg Version: 1.13.24 Severity: normal As reported under bug 395140, dpkg/dselect takes a lot of memory and can easily push low-memory systems to swap. Most of this memory usage is related to parsing the available file into an in-memory database. I mentionned this issue to Matt Zimmerman and he made the following observation: The fact that dpkg pays attention to the available file at all is a bug; it should only care about the state of the system and not about external repositories. Only higher level package managers like apt and dselect should do that. I think he's correct, in that dpkg only needs to consider dependencies or conflicts with the installed packages on the system, and can safely ignore anything that has not been installed. Any other behaviour is at best undocumented, and most likely, a bug. The only problem I see with this is that then dpkg will ignore completely any override from the archive, which most of the time is not really important as they affect stuff not used by dpkg for the dependency resolution as you said. The only important information might be the Section and Priority fields, which are usually overriden and used to create roostraps or select what's the base system, etc. But on the other hand I think all programs doing that are using the archive Packages files for that purpose, so I guess it's fine to apply this patch. In detail, here is what I suggest: dpkg --install / --unpack / --configure / --remove / --purge currently read and write the available file, they need not touch it at all. dpkg --get-selections / --set-selections / --clear-selections / --audit / --yet-to-unpack should not need to touch the available file either, I think. dpkg-query should never read or write the available file except for the --print-avail command. The commands that write to the available file should be limited to: dpkg --record-avail dpkg --update-avail / --merge-avail / --clear-avail (any writes to the available file will be lost at the next dselect update anyway, but dpkg --update-avail needs to work for dselect update to work). The commands that read the available file should be limited to: dselect select (reads and rewrites today) dpkg-query --print-avail (already done readonly today) dpkg --forget-old-unavail (reads and rewrites today) dpkg --predep-package (already done readonly today) Yeah seems reasonable, will review and merge. thanks, guillem -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: dpkg: don't forget to delete directories
Processing commands for [EMAIL PROTECTED]: tags 316521 - patch Bug#316521: dpkg: forgets to delete directories when purging Tags were: patch Bug#348133: dpkg: incomplete cleanup of emtpy directories Tags removed: patch retitle 316521 dpkg forgets shared directories containing manually generated files which are removed by postrm purge Bug#316521: dpkg: forgets to delete directories when purging Changed Bug title to `dpkg forgets shared directories containing manually generated files which are removed by postrm purge' from `dpkg: forgets to delete directories when purging'. thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: Re: Bug#77828: dpkg: [PATCH]: users should be able to use update-alternatives (not only root)
Processing commands for [EMAIL PROTECTED]: tags 77828 - patch Bug#77828: [U-A] users should be able to use u-a (not only root) Tags were: patch Bug#79292: [U-A] update-alternatives: user alternatives Bug#79941: [U-A] gnome-session: gnome-wm calls x-window-manager with full path Tags removed: patch tags 77828 + wontfix Bug#77828: [U-A] users should be able to use u-a (not only root) There were no tags set. Bug#79292: [U-A] update-alternatives: user alternatives Bug#79941: [U-A] gnome-session: gnome-wm calls x-window-manager with full path Tags added: wontfix thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#77828: dpkg: [PATCH]: users should be able to use update-alternatives (not only root)
tags 77828 - patch tags 77828 + wontfix thanks On Sat, 25 Nov 2000, Martin Quinson wrote: Here is an (unified) patch against update-alternatives.pl as found today in the CVS. Its purpose is to allow the users to manage an alternative system on their account. I'm not really inclined to support such a feature. I have yet to see a valid use case. When the user wants to override a system-wide setting, there are already dozens of solutions going from using some environment variable to changing the PATH so that ~/bin/ is looked first. And ~/bin/ can contain symlinks corresponding to the various name of alternatives and have them point to their program of choice. Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#395140: dselect memory usage is high
Hi, On Sun, 2008-07-06 at 15:26:02 +0200, Raphael Hertzog wrote: On Tue, 24 Oct 2006, Michel Lespinasse wrote: dselect select seems to take about 48 MB while displaying the packages, this causes a small-memory system (32MB) to go heavily into swap. A quick run with valgrind --tool=massif reveals that about 15MB are allocated by 'newpad'. Apparently dselect creates a 2-line ncursed pad to hold the package list. Since the same information is also present as part of the in-memory package database, it might be possible to save the memory by generating a smaller pad for just the part of the list that's being shown at any given time. This change is reasonable IMO. I updated the patch and pushed it here: http://git.debian.org/?p=users/hertzog/dpkg.git;a=shortlog;h=refs/heads/pu/bug395140-dselect-memory-usage I tested it and it works fine apparently. I'll merge it if nobody expresses any concern. Seems fine to me as well, except for the few missing spaces and more than one statement on the same line. On Fri, 27 Oct 2006, Michel Lespinasse wrote: The attached patch helps with low-memory performance by implementing segregated memory storage. A separate obstack is used for allocating information related to the Installed-Size, Origin, Maintainer, Bugs, Architecture, Source, Filename, Size, MD5sum, MSDOS-Filename and Description fields, as well as any arbitrary field contents (which these days seems to include SHA1, SHA256, Tag and Task fields). I don't think that we want such a change. It will apply both to dselect and to dpkg, and it's probably not desirable in general. It would be fine-tuning generic code for a specific use case and that doesn't make sense. I think the idea behind this change is good, some of those fields you listed are not used internally by dpkg on the most intensive operations, which mostly use the dependency information. But I didn't like the implementation, I think generalizing a bit the non-freeing allocating code would be better anyway, there's for example direct usage of obstacks in src/archive.c, that should be abstracted away. I wrote some initial code the other day for that generalization, should cleanup and commit, afterwards we could consider this patch. regards, guillem -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#395140: dselect memory usage is high
On Sun, 06 Jul 2008, Guillem Jover wrote: Seems fine to me as well, except for the few missing spaces and more than one statement on the same line. Ok, will fix before merge. On Fri, 27 Oct 2006, Michel Lespinasse wrote: The attached patch helps with low-memory performance by implementing segregated memory storage. A separate obstack is used for allocating information related to the Installed-Size, Origin, Maintainer, Bugs, Architecture, Source, Filename, Size, MD5sum, MSDOS-Filename and Description fields, as well as any arbitrary field contents (which these days seems to include SHA1, SHA256, Tag and Task fields). I don't think that we want such a change. It will apply both to dselect and to dpkg, and it's probably not desirable in general. It would be fine-tuning generic code for a specific use case and that doesn't make sense. I think the idea behind this change is good, some of those fields you listed are not used internally by dpkg on the most intensive operations, which mostly use the dependency information. But I didn't like the implementation, I think generalizing a bit the non-freeing allocating code would be better anyway, there's for example direct usage of obstacks in src/archive.c, that should be abstracted away. I'm not convinced that it will help dpkg a lot since it always has to write the status file back and it will access all the fields at this point of time anyway. Of course this also applies to dselect but since it's an interactive program, it's logical to have different considerations for interactive responsiveness. I wrote some initial code the other day for that generalization, should cleanup and commit, afterwards we could consider this patch. You write too many things in parallel. :-) Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: setting package to dselect dpkg-dev dpkg, tagging 395140
Processing commands for [EMAIL PROTECTED]: # Automatically generated email from bts, devscripts version 2.10.33 # via tagpending # # dpkg (1.15.0) UNRELEASED; urgency=low # # * Reduce memory usage of dselect by avoiding usage of a big infopad. #Thanks to Michel Lespinasse [EMAIL PROTECTED] for the patch. #Closes: #395140 # package dselect dpkg-dev dpkg Ignoring bugs not assigned to: dpkg-dev dselect dpkg tags 395140 + pending Bug#395140: dselect memory usage is high Tags were: patch Tags added: pending End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#395140: setting package to dselect dpkg-dev dpkg, tagging 395140
# Automatically generated email from bts, devscripts version 2.10.33 # via tagpending # # dpkg (1.15.0) UNRELEASED; urgency=low # # * Reduce memory usage of dselect by avoiding usage of a big infopad. #Thanks to Michel Lespinasse [EMAIL PROTECTED] for the patch. #Closes: #395140 # package dselect dpkg-dev dpkg tags 395140 + pending -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#237675: [UTF-8] patch for dselect UTF-8 support
On Fri, 27 Jun 2008, Raphael Hertzog wrote: On Thu, 03 Mar 2005, Changwoo Ryu wrote: If the patch is too long to be accepted for now, how about starting with replacing libncurses5 with libncursesw5? Just replacing, without touching other things, is also useful. The only problem is that libncursesw5 is not in base... but after sarge all programs can be replaced. This has been done some time ago when it really broke badly. For the rest of your patch, I just forward-ported it to the current git tree, the fix for #342495 was in conflict with your patch and had to be redone given that you use libtextwrap. Apart from that and from some build-system adjustement, the patch applied mostly fine. Some other conflicting changes have been merged in the mean time. I reupdated the patch and I'm keeping a branch here: http://git.debian.org/?p=users/hertzog/dpkg.git;a=shortlog;h=refs/heads/pu/bug237675-dselect-wide-char-support Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
