- Pacman-dev - lists.archlinux.org

[pacman-dev] bzip2 package compression
by Mark Constable 07 Dec '08

07 Dec '08

I changed these in /etc/makepkg.conf to bz2 variants ages ago and assumed that the resulting packages would be bzip2 compressed. When I double checked the packages they were still only gzip compressed even though the extension was tar.bz2. Everything works so I didn't pick it up but I'd be interested in the bandwidth saving from bzip2 compression. PKGEXT='.pkg.tar.bz2' SRCEXT='.src.tar.bz2' DB_COMPRESSION='bz2' Is there a reason that a -cjf is not used in makepkg ? % grep bsdtar /usr/bin/makepkg cmd="bsdtar -x -f $file" ;; if ! bsdtar -czf "$pkg_file" $comp_files *; then bsdtar -xOf "$old_file" .PKGINFO > "$pkginfo" || continue if ! bsdtar -czLf "$pkg_file" ${pkgname}; then --markc

2 3

[pacman-dev] [Fwd: [arch-general] PKGBUILD and DOS line endings]
by Allan McRae 07 Dec '08

07 Dec '08

Should we be handling this issue? Allan -------- Original Message -------- Subject: [arch-general] PKGBUILD and DOS line endings Date: Sat, 6 Dec 2008 15:32:26 +0100 From: Alessandro Doro <ordo.ad(a)gmail.com> Reply-To: General Discusson about Arch Linux <arch-general(a)archlinux.org> To: arch-general(a)archlinux.org I found in AUR a PKGBUILD with DOS line endings. See what happens: $ makepkg : command not found ==> ERROR: An unknown error has occured. Exiting... makepkg simply sources "$BUILDSCRIPT" and bash treats '\r' literally. The PKGBUILD maintainer is surely to be blamed and I don't think that `makepkg' should try to catch this error (sorry for some innocent user). Just wanted to expose this "feature". bye

3 2

[pacman-dev] PKGBUILD.proto
by Jud 06 Dec '08

06 Dec '08

Hi, Dan suggested I send this to the pacman-dev list. After completing some research and asking alot of questions I present some minor changes to PKGBUILD.proto supplied as a .diff to be merged after your approval. I believe it helps the intended audience create a better PKGBUILD in less time according to the latest Arch Packaging Standards. Cheers Jud Inline: --- PKGBUILD.proto 2008-12-05 23:32:33.000005000 +1000 +++ PKGBUILD.proto.new 2008-12-05 23:37:45.374547000 +1000 @@ -3,13 +3,15 @@ # NOTE: Please fill out the license field for your package! If it is unknown, # then please put 'unknown'. -# Contributor: Your Name <youremail(a)domain.com> + +# Contributor: Your Name <youremail(a)domain.com> # Use dots only to reduce spam + pkgname=NAME -pkgver=VERSION +pkgver=VERSION # Note: if pkgver is '0.99-10' then use an underscore, i.e. '0.99_10' pkgrel=1 pkgdesc="" -arch=() -url="" +url="http://ADDRESS/" +arch=('i686' 'x86_64') license=('GPL') groups=() depends=() @@ -20,17 +22,13 @@ replaces=() backup=() options=() -install= -source=($pkgname-$pkgver.tar.gz) -noextract=() -md5sums=() #generate with 'makepkg -g' +install=(${pkgname}.install) +source=(http://ADDRESS/TO/FILE/${pkgname}-${pkgver}.tar.gz) +md5sums=() # Generate with 'makepkg -g' build() { - cd "$srcdir/$pkgname-$pkgver" - - ./configure --prefix=/usr + cd ${srcdir}${pkgname}-${pkgver} + ./configure --prefix=usr make || return 1 - make DESTDIR="$pkgdir/" install + make DESTDIR=${pkgdir} install || return 1 } - -# vim:set ts=2 sw=2 et:

4 3

[pacman-dev] [PATCH] makepkg: save and restore shell options before and after build()
by Dan McGee 05 Dec '08

05 Dec '08

Fix the issue uncovered by FS#12344. In this instance, the dotglob shopt was being set in the build() function but never cleared, causing issues in the remaining parts of the makepkg script. Signed-off-by: Dan McGee <dan(a)archlinux.org> --- scripts/makepkg.sh.in | 4 ++++ 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/scripts/makepkg.sh.in b/scripts/makepkg.sh.in index 4cc255c..25e4cc8 100644 --- a/scripts/makepkg.sh.in +++ b/scripts/makepkg.sh.in @@ -675,6 +675,8 @@ run_build() { # ensure all necessary build variables are exported export CFLAGS CXXFLAGS MAKEFLAGS CHOST + # save our shell options so build() can't override what we need + local $shellopts=$(shopts -p) local ret=0 if [ "$LOGGING" = "1" ]; then @@ -695,6 +697,8 @@ run_build() { else build 2>&1 || ret=$? fi + # reset our shell options + eval "$shellopts" if [ $ret -gt 0 ]; then error "$(gettext "Build Failed.")" -- 1.6.0.4

3 4

[pacman-dev] [translation] Update Italian translation
by Giovanni Scafora 04 Dec '08

04 Dec '08

Hi guys, there is an update Italian translation of pacman. Thanks. -- Arch Linux Developer (voidnull) AUR & Pacman Italian Translations Microdia Developer http://www.archlinux.it

1 0

[pacman-dev] [PATCH] contirb/pactree: fix option parsing
by Allan McRae 04 Dec '08

04 Dec '08

The option parsing was catching any "-d" in an arguement so packages with this in their name did not work. Also removed commented code line that appears to be inserted during testing Signed-off-by: Allan McRae <allan(a)archlinux.org> --- contrib/pactree | 3 +-- 1 files changed, 1 insertions(+), 2 deletions(-) diff --git a/contrib/pactree b/contrib/pactree index d9fa8b3..df53671 100755 --- a/contrib/pactree +++ b/contrib/pactree @@ -208,11 +208,10 @@ for (( n=0 ; n < $len_options ; n++ )); do continue fi - if [[ "${options[$n]}" =~ -d[[:digit:]]* || "${options[$n]}" == "--depth" ]]; then + if [[ "${options[$n]}" =~ -d[[:digit:]]+ || "${options[$n]}" == "--depth" ]]; then if [[ "${options[$n]#-d}" =~ [[:digit:]]+ ]]; then max_depth="${options[$n]#-d}" elif [[ ${options[$((n+1))]} =~ [[:digit:]]+ ]]; then -# if [ ${options[$((n+1))]} -eq ${options[$((n+1))]} 2>/dev/null ]; then max_depth="${options[$((n+1))]}" unset options[$((n+1))] ((++n)) -- 1.6.0.4

2 1

[pacman-dev] [GIT] The official pacman repository branch, maint, updated. v3.2.1-22-ga1f7c83
by dan＠archlinux.org 03 Dec '08

03 Dec '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 a1f7c83dbf3bce492163362d2896e3a4176be616 (commit) via 6d8a6aef094c162f46a8b9be6a118a502fabca61 (commit) via b99bebc008dcf944a88f99bb44ac9029557e4149 (commit) from a50b067470a8046dabdff66f6266d2208b2f8372 (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 ----------------------------------------------------------------- ----------------------------------------------------------------------- Summary of changes: PKGBUILD.proto | 1 + lib/libalpm/be_files.c | 5 ++++- lib/libalpm/delta.c | 15 +++++++++++++++ src/pacman/callback.c | 1 + 4 files changed, 21 insertions(+), 1 deletions(-) hooks/post-receive -- The official pacman repository

1 0

[pacman-dev] [GIT] The official pacman repository branch, master, updated. v3.2.1-52-g61c6552
by dan＠archlinux.org 03 Dec '08

03 Dec '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, master has been updated via 61c6552862345cb155903cd1566f1cef5c527a94 (commit) via a1f7c83dbf3bce492163362d2896e3a4176be616 (commit) via 6d8a6aef094c162f46a8b9be6a118a502fabca61 (commit) via b99bebc008dcf944a88f99bb44ac9029557e4149 (commit) via a50b067470a8046dabdff66f6266d2208b2f8372 (commit) via 346139298bc547d1cbeb5d41f2067577b96ff1fa (commit) via f7192b595881103f145a118d63d1b342ffd740b4 (commit) from 9394f229a0328228e810b7d4588b24643b42df6a (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 61c6552862345cb155903cd1566f1cef5c527a94 Merge: 9394f229a0328228e810b7d4588b24643b42df6a a1f7c83dbf3bce492163362d2896e3a4176be616 Author: Dan McGee <dan(a)archlinux.org> Date: Tue Dec 2 22:15:02 2008 -0600 Merge branch 'maint' Conflicts: lib/libalpm/dload.c ----------------------------------------------------------------------- Summary of changes: PKGBUILD.proto | 1 + lib/libalpm/be_files.c | 11 +++++++---- lib/libalpm/delta.c | 15 +++++++++++++++ lib/libalpm/dload.c | 10 ++++------ scripts/makepkg.sh.in | 2 +- src/pacman/callback.c | 1 + src/pacman/pacman.c | 46 ++++++++++++++++++++++++++++++++++------------ src/pacman/sync.c | 3 ++- 8 files changed, 65 insertions(+), 24 deletions(-) hooks/post-receive -- The official pacman repository

1 0

[pacman-dev] [PATCH] Add optdepends to PKGBUILD.proto
by Allan McRae 03 Dec '08

03 Dec '08

Signed-off-by: Allan McRae <allan(a)archlinux.org> --- PKGBUILD.proto | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/PKGBUILD.proto b/PKGBUILD.proto index 3265530..eddcf75 100644 --- a/PKGBUILD.proto +++ b/PKGBUILD.proto @@ -14,6 +14,7 @@ license=('GPL') groups=() depends=() makedepends=() +optdepends=() provides=() conflicts=() replaces=() -- 1.6.0.4

2 1

[pacman-dev] Package/database signing
by Gerhard Brauer 02 Dec '08

02 Dec '08

(I hope i don't triple-post this mail, sorry) Hi, i took this mail from arch-dev-public and arch-general discussion about "Can we trust our mirrors" Am Mon, 1 Dec 2008 11:06:02 -0600 schrieb "Aaron Griffin" <aaronmgriffin(a)gmail.com>: > > There's too much talk on this idea. Before we go ahead and do this, > could someone submit this patch to the pacman-dev list, so the pacman > developers can give it a once-over. Just make sure to let them know > that this is a temporary solution. I attach my patch to repo-add and a pacman download script to explain how things *could* be done. A proof of concept, working and tested on my local repo. > Additionally - where will gpg get the key from on gerolde? Shouldn't > this be configurable, or even set via an optarg to the -s param? In my environment the signing key is getting from my sec-keyring, cause i start repo-add under my UID. It's the default key in gpg.conf if you have more than one key. And of cource: on gpg command line the key could be selected by several criteria, also from a special keyring. Keyring or keys must kept secure of cource, so mostly the are in $HOME/.gpg This is only a concept for signing the package db for the repos. These database files are created only on gerolde (?) an should be signed only there and from the process which creates the database. This is repo-add. #Q: Which key, where does it come from, how to prevent this key(s)? I would assume only one secret key for database signing. AFAIK from Pierre repo-add is under normal procedures not called directly by the developers, only from upload/build scripts. So one solution maybe: create a dedicated user. repo-add then is running *only* under this UID. The secret key could be in the $HOME of this user, so it's secured from other access. Only god mode users on gerolde could "see" it, and maintain it (revoke, renew, etc.). In the scripts which called repo-add (or if single users must call repo-add directly) we could call it with su or sudo. Without special key selecting then the key is took from $repo-add-userid's keyring and cause it's the only keys it is automatically the default key. #Q: How to implement this in pacman on users side? In my test i use the pacman.conf option XferCommand and a special download script for. I call it like this: XferCommand = /tmp/pacsigdl %o %u Each download is checked if this is a *.db.tar,gz. If yes, the file is verified with the public key part from above. If verification is ok then pacman continues with this db file as usual, if verification failed pacman ignores the downloaded (corrupted) file and signals this for this special repo db (but continues with the rest of a -Syu). No new database for a repo -> no new packages to download/install. That way with XferCommand is not a real solution: a) It makes pacman intern downloading (libalpm) obsolete. b) Downloads for *all** packages(incl. database files) must be handled with wget or curl, which produces verbose or zero output which breaks our normal pacman output. c) The verifying part should not be delegated to the user. Ideally pacman would handle this process itself. (I'm nor a c programmer). #Q: Must we real use gpg command line? Must we use gpg? My experience with other Trust-Solutions are low. Also it seems that there are no good libraries to gpg for accessing functions from c programs. http://www.gnupg.org/related_software/libraries.en.html Thomas(brain0) mentions for ex. gnutls or openssl If we could integrate gpg (command-line or by lib) better in our framework then i think: gpg is a good, well known solution. #Q: Signing only the database is not secure! Yes, it would currently only secure our package hash/checksum functions against manipulations, not the packages itself. But IMHO it's a good starting point to get forward. Ideally we must sign the db files also when we sometimes have a super dupper package signing framework ;-) So let's start (and gain experience) fist with the db files. Currently our check-sums(md5) are only download check-sums. They could be manipulate (and therefor easily the corresponding package) on each station after the db leaves gerolde. From a secure view the checksums are useless. If we sign our db file we secure the checksums against manipulating. Not the packages itself. But package manipulating is a lot more difficult to do as in our current situation. And we could switch to a better package check summing solution than md5sum to gain more secure against package manipulation. Ideally we come some day to a framework were also the packages are signed by packagers/developers. Some days. Next step. That are my thoughts on this thing. Surely not complete. (Sorry for my not good English ;-) I attach also a tar archive with a) a repo-add patch and b) a download script for using in pacman.conf) Regards Gerhard

1 0