- Pacman-dev - lists.archlinux.org

Re: [pacman-dev] Fwd: Pacman translation into Polish
by Mateusz Jędrasik 15 Apr '07

15 Apr '07

Hi, It seems the pacman translation itself is all done and finished; There seems to be a minor glitch tho (at least from the ones I noticed), depicted on a screenshot which is available for viewing at http://szklo.eu.org/~imachine/tmp/pacman.png due to its size. Basically, the [###-] progress bar doesn't align properly next to the 'checking file conflicts' line. It's two characters to the left. I've tried simply adding two spaces to the translated text msgstr, but despite being a nasty 'hack' it doesn't fix the issue anyway. It would be great to resolve it. Cheers, //m. -- Mateusz Jędrasik <m.jedrasik(a)gmail.com> tel. +48(51)69-xxx-xx, +44(772)664-2342 http://imachine.szklo.eu.org

2 2

[pacman-dev] Southern Utah University Arch Linux Repository
by Thomas S Hatch 14 Apr '07

14 Apr '07

I am pleased to announce the SUU Arch Linux repository, this server is not only mirroring Arch, but it is running it as well, please add us to the repository and mirror lists lists for pacman. We have set up a full mirror so there are iso downloads as well. [testing] ftp://locke.suu.edu/linux/dist/archlinux/current/os/i686 [current] Server = ftp://locke.suu.edu/linux/dist/archlinux/current/os/i686 [extra] Server = ftp://locke.suu.edu/linux/dist/archlinux/extra/os/i686 [unstable] Server = ftp://locke.suu.edu/linux/dist/archlinux/unstable/os/i686 [community] Server = ftp://locke.suu.edu/linux/dist/archlinux/community/os/i686 and for x86_64 of course! -Thomas S Hatch Southern Utah University

2 2

[pacman-dev] Duplicated requiredby conclusion
by Nagy Gabor 12 Apr '07

12 Apr '07

Hi! Yes, we fixed this problem: We didn't check the existency of the entry before inserting it to the requiredby field. But how could duplicated entries appear? Update is a remove-then-install process, so we simply remove the package first (and removing it from requiredby fields), then install it (which is not installed now, so that is not listed in any requiredby fields). The answer: That remove process is not a real remove transaction (a pseudo transaction is created); look into add.c(389): ==== _alpm_trans_init(tr, PM_TRANS_TYPE_UPGRADE, ... ==== Wow, the transaction type is UPGRADE (this is mainly for logging imho). But look into trans.c/_alpm_trans_update_depends(342): ==== if(trans->type == PM_TRANS_TYPE_REMOVE) { void *data = NULL; rqdby = alpm_list_remove(rqdby, pkgname, _alpm_str_cmp, &data); FREE(data); deppkg->requiredby = rqdby; } else { if(!alpm_list_find_str(rqdby, pkgname)) { rqdby = alpm_list_add(rqdby, strdup(pkgname)); deppkg->requiredby = rqdby; } } ==== So, we want to add it, instead of removing. After adding "if(!alpm_list_find_str(rqdby, pkgname))", this is not so dangerous (but needless), but this a _very odd_ method. However, this is absolutely not safe yet: If the remove was successful, but we cannot install the package, we get false requiredby entries. Bye, Nagy Gabor

3 5

[pacman-dev] Crypto algorithms
by Dan McGee 12 Apr '07

12 Apr '07

We have a rather ragtag set of cryptography functions in use right now, and weird files being used (md5driver? wtf). Looking around I came across these LGPLed hash libraries that we can probably use in pacman. BeeCrypt- http://directory.fsf.org/security/crypt/BeeCrypt.html Documentation- http://beecrypt.sourceforge.net/doxygen/c/index.html Any reason not to go for this? I haven't looked super closely but I think it would make sense to clean this up a bit in order to allow for any future extensibility we may want. These seem like cleanly written algorithms that we can drop in to our code base as they are LGPL. Thoughts appreciated. Have to start cleaning somewhere. -Dan

8 15

[pacman-dev] Fwd: Pacman translation into Polish
by Mateusz Jędrasik 12 Apr '07

12 Apr '07

Hi, I have begun work on translating pacman 3 into the Polish language, supposing there is no ongoing work yet. The files I attach here are alpha at best (done halfway through pl_PL.po, without testing in actual pacman itself since its source build seems to have odd issues with linking pacman.static against libacl, which is, in fact, installed and likely working on my system), the reason why I announce this work is mostly so that other people do not choose to follow my footsteps redoing what is already done by me. I shall post the rest shortly; stay tuned. The attached file goes into src/pacman/po in pacman-3.0.1.tgz source tarfile. Work on the lib/libalpm/po/pl_PL.po file is underway. I have also sent this e-mail earlier however I see it has not yet reached the mailing lists (perhaphs because I wasn't subscribed to it at the time) and, willing to rather avoid somebody starting a Polish translation without knowing about my current efforts, I'm willing to risk being responsible for a duplicate copy on the mailing lists. Regards, //m. -- Mateusz Jędrasik <m.jedrasik(a)gmail.com> tel. +48(51)69-444-90, +44(772)664-2342 http://imachine.szklo.eu.org

3 5

[pacman-dev] Git tree update
by Andrew Fyfe 11 Apr '07

11 Apr '07

Just a quick update on what I'm currently working on... fakeroot - http://repo.or.cz/w/pacman.git?a=shortlog;h=fakeroot Rediffed with recent changes to makepkg (nudge nudge Dan ;P) autoconf_scripts - http://repo.or.cz/w/pacman.git?a=shortlog;h=autoconf_scripts The first stage to removing hard-coding of version numbers and paths. changes so far are: * add autoconf substitution for version number * add -V|--version options to scripts ToDo: * remove hard-coding of config files and paths * merge in gettext changes Andrew

1 0

[pacman-dev] CVS update of pacman-lib/scripts (makepkg)
by Dan McGee 11 Apr '07

11 Apr '07

Date: Wednesday, April 11, 2007 @ 12:41:29 Author: dan Path: /home/cvs-pacman/pacman-lib/scripts Modified: makepkg (1.67 -> 1.68) Fix FS #6872- CFLAGS were not being exported ---------+ makepkg | 4 ++++ 1 file changed, 4 insertions(+) Index: pacman-lib/scripts/makepkg diff -u pacman-lib/scripts/makepkg:1.67 pacman-lib/scripts/makepkg:1.68 --- pacman-lib/scripts/makepkg:1.67 Tue Apr 3 22:03:44 2007 +++ pacman-lib/scripts/makepkg Wed Apr 11 12:41:29 2007 @@ -885,6 +885,10 @@ unset LC_ALL LANG umask 0022 + # ensure CFLAGS and CXXFLAGS are used + export CFLAGS + export CXXFLAGS + #check for "exit on syntax error" shell option echo $SHELLOPTS | grep errexit 2>&1 >/dev/null set_e=$?

1 0

[pacman-dev] localdb dependency storing + function for depsearch
by Nagy Gabor 10 Apr '07

10 Apr '07

Hi! The first part is only a theoretical discussion only, because changing the db backend is not so easy ;-). There is nothing wrong with the current way, I just don't like it ;-), because it makes pacman's source more difficult to understand and we need some extra computation when resolving/modifying dependencies. I think storing storing "satisfied dependencies" to/'instead of' requiredby, because this is more plausible. This is the information what we need during package update and removal (if we check that any of the remaining packages satisfies this dependency). So we need to figure out dependencies (yes, more than one possible!) between the current package and its requiredby package, which is boring ;-) And %DEPENDS% should store all packages too which satisfies the dep. A 'depends' example: %DEPENDS% foo1: foo1 foo2<=1.0: foo2 provide_foo: foo3_0, foo3_1 foo4: BROKEN %REQUIREDBY% foo5: provide_foo2 foo5: foo5=1.0 ... ------------------------------------- A function for depsearch would be nice (this can be called from _alpm_depcheck and similar) + in case of searching other provider (before removal of package which may break a "providedep") for example Bye, ngaba

1 0

[pacman-dev] [BUG] pacman freezes and eats up all the cpu
by bardo 10 Apr '07

10 Apr '07

In a moment of distraction during a pacman -U, while it was doing the conflict checking, I removed the package I was installing from another console. The missing package was correctly detected, but then another error came up, and pacman hung taking the cpu to 100%. Even ctrl-c couldn't stop it, I had to kill it. Here's the log: [root@paradigm ~]# LANG=en_US pacman -U /home/bardo/packages/amsn-extras-svn/amsn-extras-svn-8414-1-i686.pkg.tar.gz loading package data... done. checking dependencies... done. cleaning up... done. (1/1) checking for file conflicts [####################] 100% error: failed to commit transaction (cannot open package file) error: failed to release transaction (could not commit transaction) [1]+ Stopped LANG=en_US pacman -U /home/bardo/packages/amsn-extras-svn/amsn-extras-svn-8414-1-i686.pkg.tar.gz [root@paradigm ~]# bardo

2 6

[pacman-dev] Arch neutrral packages
by Andrew Fyfe 10 Apr '07

10 Apr '07

Is it worth adding something like arch=(NOARCH) for packages that are arch neutral (ie they only contain text files, scripts...) so we don't have 2 identical packages for i686 and x86_64. Andrew

5 6