- Pacman-dev - lists.archlinux.org

Re: [pacman-dev] [translation] String freeze for pacman 3.1.2 release
by João Felipe Santos 15 Feb '08

15 Feb '08

> Here is the po file for pacman in pt_BR, just in time, I hope. > > jfsantos Again, but now gzipped :P jfsantos

2 1

[pacman-dev] [translation] String freeze for pacman 3.1.2 release
by Dan McGee 14 Feb '08

14 Feb '08

Some comments from the 3.1.1 string freeze still apply so I have included these below. Note that libalpm has had zero string changes this time around, meaning you do not need to submit this po file unless you are making grammar or spelling corrections, etc. If you have any questions, please contact the pacman-dev mailing list. Thanks! > I've CC-ed this to the Arch General list to see if we can get a > helping hand with some of our currently neglected translations. As > this list may not be quite as familiar with how everything works, > PLEASE reply to the list or privately to me if you have questions or > want to help out but are not sure how. > > Our pacman translation policy is outlined here. The important sections > for translators are the introduction and up to (and including) > pre-release updates. > http://www.archlinux.org/pacman/translation-help.html > > As stated in the above document, PO files have been made available to translate: > http://code.toofishes.net/pacman/po_files/ > > I would like to get the release out within the next 7 days, so the > sooner the better for the translations. Current list of known translators: http://projects.archlinux.org/git/?p=pacman.git;a=blob;f=TRANSLATORS > If you wish to help translate, but your language is already listed as > handled by someone, please contact them at the above addresses. If the > language is listed as "no current translator", then please reply to > ALL on this message stating you are doing the translation so we do not > have duplicated effort (although you are more than welcome to work in > teams). > > Once you have updated or completed a translation, simply tar and gzip > the files up and send them back to pacman-dev(a)archlinux.org with a > [translation] prefix in the message. > > For those that are used to the old method of updating translations > (GIT patches), those are still acceptable as well. Please prefix the > patch with "translation:" so it can be picked out easily. HOWEVER, if > at all possible, please do not needlessly update the line numbers in > the code! It makes it much easier to see which translations have been > changed and updated if line number changes are not 90% of the patch. > The "translations" branch is located in my GIT repo; one of the > following things will probably be of help. > > http://code.toofishes.net/gitweb.cgi?p=pacman.git;a=shortlog;h=translations > > git remote add dan http://code.toofishes.net/gitprojects/pacman.git > git checkout -b translations dan/translations

4 5

[pacman-dev] [translation] Hungarian (pacman) translation for 3.1.2
by Nagy Gabor 12 Feb '08

12 Feb '08

Hi! The gzipped po/hu.po file is attached. Bye ---------------------------------------------------- SZTE Egyetemi Könyvtár - http://www.bibl.u-szeged.hu This mail sent through IMP: http://horde.org/imp/

2 2

[pacman-dev] [GIT] The official pacman repository branch, maint, updated. v3.1.1-27-gf4ac63a
by Dan McGee 12 Feb '08

12 Feb '08

This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "The official pacman repository". The branch, maint has been updated via f4ac63ab43a277cdc6a409c0bd6f0d04c1791882 (commit) via 8068a14c5217989a25a03fa1677086c086ad90d6 (commit) via 9bf487b2ff0a3f56bd8e2159a7688264950f3a02 (commit) via fbf3beb8d281e85c69f1683df2d9c7b2fb5c1ab7 (commit) via 7586072beb8fde6631fe43a2eee5ca76255055d0 (commit) via 17180890a58365d717a8f79d2e60f5af4f829eef (commit) from 14ee1be1ef21e09a84f01dc9623e8513218709d4 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log ----------------------------------------------------------------- commit f4ac63ab43a277cdc6a409c0bd6f0d04c1791882 Author: Dan McGee <dan(a)archlinux.org> Date: Thu Feb 7 20:33:11 2008 -0600 Update NEWS in prep for 3.1.2 release Signed-off-by: Dan McGee <dan(a)archlinux.org> commit 8068a14c5217989a25a03fa1677086c086ad90d6 Author: Dan McGee <dan(a)archlinux.org> Date: Mon Feb 11 20:15:44 2008 -0600 setlibpaths(): remove a stray set_option line For some reason, we set our dbpath to the logfile path, which was completely broken, and we didn't even check the return value coming back (which of course was -1 meaning the set failed). Add some comments so people can understand what is going on here now too. Signed-off-by: Dan McGee <dan(a)archlinux.org> commit 9bf487b2ff0a3f56bd8e2159a7688264950f3a02 Author: Dan McGee <dan(a)archlinux.org> Date: Mon Feb 11 19:36:12 2008 -0600 Move some translations to their generic language code For our Czech, Polish, and Russian translations, they do not need to be at the more specific 'lang_COUNTRY' code, but can live at just plain 'lang'. This follows the pattern of most other translated programs out there as Roman pointed out on IRC. ru_RU: 2 (pacman and libalpm) ru: 128 for him, 131 for me (everything else) Signed-off-by: Dan McGee <dan(a)archlinux.org> commit fbf3beb8d281e85c69f1683df2d9c7b2fb5c1ab7 Author: Dan McGee <dan(a)archlinux.org> Date: Mon Feb 11 09:51:34 2008 -0600 ensure chk_fileconflicts reads entire file list If the end of the pB list was reached before the end of pA, we failed to read any remaining files from the pA list. Add an additional loop to ensure all entries of pA are added to the return list regardless of whether we have reached the end of pB. This new loop also eliminates the now-unnecessary check for a null pB, as we need to ensure we are excluding directories in the resulting output anyway. Signed-off-by: Dan McGee <dan(a)archlinux.org> commit 7586072beb8fde6631fe43a2eee5ca76255055d0 Author: Nagy Gabor <ngaba(a)bibl.u-szeged.hu> Date: Sat Feb 9 17:51:05 2008 +0100 Fixes file relocation pactests This patch fixes upgrade040.py and upgrade041.py (041 now fails!): * the old pactests didn't check the existence of the relocated file * upgrade041.py was broken due to a typo (missing comma) New upgrade046.py pactest was added (derived from the fixed upgrade041.py). This fails because the file relocation check is _hacked_ to conflict.c, and _alpm_db_find_fileconflicts is not called in case of --force. Signed-off-by: Nagy Gabor <ngaba(a)bibl.u-szeged.hu> Signed-off-by: Chantry Xavier <shiningxc(a)gmail.com> commit 17180890a58365d717a8f79d2e60f5af4f829eef Author: Chantry Xavier <shiningxc(a)gmail.com> Date: Fri Feb 8 22:34:51 2008 +0100 makepkg : set sane umask before source extraction. This fixes FS#9242 and FS#9362. Set umask before the sources are extracted, and after the /etc/profile.d/* files are sourced in handledeps. This sourcing of profile.d files is why umask was moved to the build function in the first place, as can be seen in commit ac965ed401. Signed-off-by: Chantry Xavier <shiningxc(a)gmail.com> ----------------------------------------------------------------------- Summary of changes: NEWS | 13 +++++++++++++ TRANSLATORS | 6 +++--- lib/libalpm/conflict.c | 14 ++++++++++---- lib/libalpm/po/LINGUAS | 6 +++--- lib/libalpm/po/{cs_CZ.po => cs.po} | 0 lib/libalpm/po/{pl_PL.po => pl.po} | 0 lib/libalpm/po/{ru_RU.po => ru.po} | 0 pactest/tests/upgrade011.py | 16 ++++++++++++++++ pactest/tests/upgrade040.py | 1 + pactest/tests/upgrade041.py | 3 ++- pactest/tests/{upgrade041.py => upgrade046.py} | 7 ++++--- po/LINGUAS | 6 +++--- po/{cs_CZ.po => cs.po} | 0 po/{pl_PL.po => pl.po} | 0 po/{ru_RU.po => ru.po} | 0 scripts/makepkg.sh.in | 6 +++--- src/pacman/pacman.c | 16 ++++++++++------ 17 files changed, 68 insertions(+), 26 deletions(-) rename lib/libalpm/po/{cs_CZ.po => cs.po} (100%) rename lib/libalpm/po/{pl_PL.po => pl.po} (100%) rename lib/libalpm/po/{ru_RU.po => ru.po} (100%) create mode 100644 pactest/tests/upgrade011.py copy pactest/tests/{upgrade041.py => upgrade046.py} (79%) rename po/{cs_CZ.po => cs.po} (100%) rename po/{pl_PL.po => pl.po} (100%) rename po/{ru_RU.po => ru.po} (100%) hooks/post-receive -- The official pacman repository

1 0

[pacman-dev] Fwd: [BUG] chk_filedifference is buggy!!
by Nagy Gabor 11 Feb '08

11 Feb '08

Part II [the real problem]. ----- Továbbított levél Nagy Gabor <ngaba(a)bibl.u-szeged.hu> címről ----- Dátum: Sun, 10 Feb 2008 14:40:42 +0100 Feladó: Nagy Gabor <ngaba(a)bibl.u-szeged.hu> Viszontválasz cím: Nagy Gabor <ngaba(a)bibl.u-szeged.hu> Tartalom: [BUG] chk_filedifference is buggy!! Címzett: Xavier <shiningxc(a)gmail.com> Hi! This is the next part of my previous e-mail. After some investigation I figured out that chk_filedifference is the reason of the bug: The different pB==NULL handling is a good indicator of the bug (which is totally needless in bugfree chk_filedifference): almost the same happens here. The problem is the "while(pA && pB)"; if we reach the end of pB first, then the remaining pA is cut down... As an illustration I attached an other failing pactest file, which also demonstrates this clearly (and tests a now not checked case). Bye ----- Vége a továbbított üzenetnek ----- ---------------------------------------------------- SZTE Egyetemi Könyvtár - http://www.bibl.u-szeged.hu This mail sent through IMP: http://horde.org/imp/

2 5

[pacman-dev] Fwd: [BUG] Serious problems with file relocation on upgrade
by Nagy Gabor 11 Feb '08

11 Feb '08

I think we should fix/discuss this before 3.1.2 release, because this is quite critical imho. Part I ----- Továbbított levél Nagy Gabor <ngaba(a)bibl.u-szeged.hu> címről ----- Dátum: Sat, 9 Feb 2008 18:07:28 +0100 Feladó: Nagy Gabor <ngaba(a)bibl.u-szeged.hu> Viszontválasz cím: Nagy Gabor <ngaba(a)bibl.u-szeged.hu> Tartalom: [BUG] Serious problems with file relocation on upgrade Címzett: Xavier <shiningxc(a)gmail.com> Hi! For more info see the attached patch. Bye ----- Vége a továbbított üzenetnek ----- ---------------------------------------------------- SZTE Egyetemi Könyvtár - http://www.bibl.u-szeged.hu This mail sent through IMP: http://horde.org/imp/

1 0

[pacman-dev] Differences between pacman and pacman-g2
by ciol 11 Feb '08

11 Feb '08

Hi, what are the differences between pacman and pacman-g2? Thanks.

3 4

[pacman-dev] memleak caused by "don't duplicate package in cache"
by Xavier 10 Feb '08

10 Feb '08

Previously, all installed packages were duplicated when added to the cache. in libalpm/add.c : 801 >-if(_alpm_db_add_pkgincache(db, newpkg) == -1) { And the _alpm_db_add_pkgincache function in cache.c duplicated the newpkg. I wanted to avoid this duplication with the following commit : http://projects.archlinux.org/git/?p=pacman.git;a=commit;h=8240da6cb3ff95ad… I simply removed the pkg_dup in that function. Since I removed a pkg_dup, I had to remove the corresponding pkg_free call also. Previously, the packages in the targets list were freed in the _alpm_trans_free function. And the duplicated package in the cache were freed in _alpm_db_free_pkgcache. Since the cache is freed only when alpm is released, which happens at the very end, I let the free there. So I removed it from _alpm_trans_free, which is called when a transaction is released. Now the ugly part begins. The targets are only added to the cache when they are installed, not when they are removed (obviously). That explains the condition I added in trans_free : + } else if (trans->type == PM_TRANS_TYPE_REMOVE || + trans->type == PM_TRANS_TYPE_REMOVEUPGRADE) { alpm_list_free_inner(trans->packages, (alpm_list_fn_free)_alpm_pkg_free); So, when a whole install transaction goes fine, without errors, everything works well. All targets are added to the cache, and are then all freed correctly by the _alpm_db_free_pkgcache function. However, when the transaction doesn't go correctly, the targets are loaded in memory, but they are not installed, and so not freed! All targets stay in memory, and cause a big memleak. For example, a conflict could be detected, and the transaction is aborted (as in sync400). But it might even be possible that a transaction gets aborted in the middle. Maybe because it ran out of memory, or because the user interrupted it, or whatever. So, for solving this issue, maybe we would need a way to track down which packages were loaded in the cache. That should allow us to free everything correctly, which doesn't seem possible currently. We could then free in the trans_free function all targets that are not in the pkg cache. And the remaining targets that are in the pkg cache will be freed when the cache is freed.

2 2

[pacman-dev] Thoughts of a 3.1.2 release
by Dan McGee 08 Feb '08

08 Feb '08

Here is the current git shortlog since the last release: $ git shortlog v3.1.1..maint Alex Merry (1): updatesync: incorrect package deletion logic Chantry Xavier (9): workaround for a gettext string starting with --. two string fixes. makepkg : improve determination of svn revision. Clarify the "cancel current operation" message. repo-remove: print an error in case of an empty db Clarify the "failed to add target" errors. add 'force' to PKGINFO, have repo-add respect it. Add new ChangeLog.proto file. Don't follow symlinks with -Qo. Dan McGee (7): makepkg: add check to ensure we have non-URL files in build dir Remove frontend translation of "debug:" message doc/makepkg.8: add missing '-' to manpage option makepkg: ensure binaries in /opt/* are stripped Add deprecation warnings to gensync and updatesync doc/makepkg: document --log, address locale issues pacman/util.c: add mdirname function Roman Kyrylych (1): Remove /bin/true from install.proto Given this list of changes, I think it would be prudent to think about a 3.1.2 release soon, although it is not something we need to rush out as there is nothing pressing like the provides logic prior to 3.1.1. Here are some issues I think we should address before prepping for release: http://bugs.archlinux.org/task/9362 - Any opinions here? Put them in the bug report. http://bugs.archlinux.org/task/9242 - Still not completely sure if this is easily solvable http://bugs.archlinux.org/task/9230 - Deals with makepkg/versionpkg stuff, should be an easy fix Please add any (constructive) comments you may have, and quote the relevant parts of this email. *Please* keep it limited to things that would make it into 3.1.2- if it is clearly something that can't fit in a maint release, I won't even bother responding. A second email will follow this one with some things that Xavier has brought up he thinks need addressing. Some of these are relevant for 3.1.2, others may be a bit further in the future. -Dan

3 3

[pacman-dev] GZip compression ratios
by Travis Willard 08 Feb '08

08 Feb '08

Just doing an update, and I noticed this: Targets: coreutils-6.10-1 bash-3.2.033-2 cairo-1.4.14-1 gtk2-2.12.7-1 gcc-libs-4.2.3-3 mpfr-2.3.1-1 gcc-4.2.3-1 mesa-7.0.3rc1-1 acroread-8.1.2-1 automake-1.10.1-2 kernel26-2.6.24-2 catalyst-8.01-3 curl-7.18.0-1 devtools-0.5-1 dhcpcd-3.2.1-1 e2fsprogs-1.40.5-1 faac-1.26-1 filesystem-2007.11-6 fakeroot-1.9.2-1 findutils-4.2.32-1 flex-2.5.33-4 librsvg-2.20.0-1 libxmu-1.0.4-1 gimp-2.4.4-1 git-1.5.4-1 gpgme-1.1.6-1 groff-1.19.2-4 kde-common-3.5.8-3 lm_sensors-3.0.1-1 kdebase-3.5.8-3 lftp-3.6.3-1 libgnomecups-0.2.3-1 libxml2-2.6.31-1 libgnomeprint-2.18.3-1 libgnomeprintui-2.18.2-1 libidl2-0.8.10-1 libmysqlclient-5.0.51-2 libtasn1-1.3-1 libtool-1.5.26-1 lua-5.1.3-1 lvm2-2.02.33-1 man-1.6f-2 man-pages-2.77-1 mysql-clients-5.0.51-3 nasm-2.01-1 orbit2-2.14.12-1 pcre-7.6-2 php-5.2.5-3 pil-1.1.6-4 postgresql-libs-8.3.0-1 sdl_mixer-1.2.8-2 shared-mime-info-0.23-1 snownews-1.5.8-1 spamassassin-3.2.4-2 sqlite3-3.5.5-1 sudo-1.6.9p12-1 tk-8.5.0-2 wget-1.11-1 which-2.19-2 xfsprogs-2.9.5-1 xine-lib-1.1.10-1 xorg-server-1.4.0.90-6 Total Download Size: 194.03 MB Total Installed Size: 194.39 MB Does gzip compression really give us so little as to only save 0.3 MB over uncompressed for so many packages? I figured the difference would be a bit more - does it suck for compressing binary data? Should we consider moving to a different, more compressed archive format? Or am I just making a mountain out of a molehill here? -- Travis

2 1