January 2014 - Arch-general - lists.archlinux.org

[arch-general] Howto setup i686 archroot on x86_64 box? (not linux32 chroot)
by David C. Rankin 27 Jan '14

27 Jan '14

All, I have built all x86_64 packages in an archroot on my x86_64 box. I would like to set up and i686 archroot on the same box to build the i686 packages on the same box due to build times dropping from about 8 hours on i686 to less than 3 on the x86_64 box. I am unclear how best to do it -- or if it is doable. I've read https://wiki.archlinux.org/index.php/Arch64_FAQ about multilib with ~/.makepkg.i686.conf and a true linux32 chroot setup, but none of those are specific to the archroot setup. Both seem like they would work, but don't know if they are the right choice for build the 110 packages TDE requires. I would like to do this in an archroot if possible. I use the "Classic Way" of handling the build specified in https://wiki.archlinux.org/index.php/DeveloperWiki:Building_in_a_Clean_Chro…. All dependency packages are installed in the rw layer of the chroot with the first package built, a [local] repo is created under $CHROOT/root/repo, and as packages are built, they are installed, the resulting package is copied to $CHROOT/root/repo, and the repo index is updated with repo-add, and the process repeats with the next package until the build of TDE is complete. (that chroot is usually used to finish and tweaks needed for that set of package, then deleted and a new archroot created for the next major set of updates) It seems like setting up another archroot, and installing multilib would allow an archroot to work, but how would you tell makechrootpkg to build the i686 version instead of the x86_64 version. I don't want to have to modify the PKGBUILDs or do a significant re-write of the build script that automates the build, but if it is as simple as changing the makechrootpkg call, that would be a simple config-file fix. How best to handle this? (or just use the old i686 box and run it overnight?) -- David C. Rankin, J.D.,P.E.

2 4

[arch-general] daemontools in official repositories
by Amit Aryeh Levy 27 Jan '14

27 Jan '14

Hi all, In 2007, djb's daemontools and djbdns packages was removed from the official repositories "burdensome" "license requirements for binary distribution" (https://www.archlinux.org/news/djbdns-and-daemontools-to-be-moved-to-unsupp…). However, at the end of that year (2007-12-28) djb released daemontools and djbdns into the public domain - http://cr.yp.to/distributors.html. Could we move daemontools and djbdns back into the official repositories from AUR? Cheers! Amit

1 0

[arch-general] /usr/bin/makepkg: eval: line 2180: unexpected EOF while looking for matching `}'
by David C. Rankin 26 Jan '14

26 Jan '14

Guys, I have a build that completes successfully, but the package is empty (other than .PKGINFO and .MTREE). The build output contains the following: /usr/bin/makepkg: eval: line 2180: unexpected EOF while looking for matching `}' /usr/bin/makepkg: eval: line 2181: syntax error: unexpected end of file ==> Making package: tde-adept 14.0.0-1 (Fri Jan 24 19:41:55 CST 2014) ==> Retrieving sources... -> Found applications-adept.tar.gz ==> Validating source files with md5sums... applications-adept.tar.gz ... Passed /usr/bin/makepkg: eval: line 2180: unexpected EOF while looking for matching `}' /usr/bin/makepkg: eval: line 2181: syntax error: unexpected end of file I have checked forums, etc. and this usually means you have missed a closing ' or " somewhere in the pkgbuild and it is causing problems in makepkg. I have checked the pkgbuild closely and run namcap and it doesn't report any problems. Is there something obvious below, or is this a bug? The PKGBUILD is: # Maintainer: David C. Rankin <drankinatty at gmail dot com> pkgname=tde-adept pkgver=14.0.0 pkgrel=1 pkgdesc="TDE adept Advanced Package Management Tool - Trinity upstream GIT version" arch=('i686' 'x86_64') url="http://scm.trinitydesktop.org/scm/git/${pkgname#*-}" license=('GPL') groups=('tde-dev' 'tde-complete') depends=('tde-tdebase') makedepends=('pkgconfig' 'autoconf') # optdepends=() provides=("${pkgname#*-}") options=('staticlibs' 'libtool' '!emptydirs') # install='pkgname.install' source=("applications-${pkgname#*-}.tar.gz") md5sums=('4beffd7764446ae737e70c36084bdc4e') build() { cd ${srcdir} ## Set up environment msg "Setting PATH, Trinity Environment variables" # Source the QT and TDE profile [ "$QTDIR" = "" ] && . /etc/profile.d/tqt3.sh # or tqt3.sh [ "$TDEDIR" = "" ] && . /etc/profile.d/trinity.sh # or tde.sh ## Generate config files and update with autoreconf cd ${srcdir}/${pkgname#*-} msg "Copying system libtool files...." cp /usr/share/aclocal/libtool.m4 ./admin/libtool.m4.in cp /usr/share/libtool/config/ltmain.sh ./admin msg "Running make -f admin/Makefile.common ...." make -f admin/Makefile.common ## configure msg "Configuring - ${pkgname}..." ./configure \ --prefix=${TDEDIR} \ --with-qt-dir=${QTDIR} \ --with-qt-includes=${QTDIR}/include \ --with-qt-libraries=${QTDIR}/lib \ --with-extra-includes="/usr/include/tqt:/usr/include/tqt/Qt" \ --with-extra-libs=${TDEDIR}/lib/trinity \ --sysconfdir=${TDEDIR}/etc \ --localstatedir=/var \ --enable-debug=full msg "Building - ${pkgname}..." make $NUMJOBS } package() { msg "Packaging - $pkgname-$pkgver" cd "${srcdir}/${pkgname#*-}" make -j1 DESTDIR="$pkgdir" install } -- David C. Rankin, J.D.,P.E.

3 3

[arch-general] Is there a burning tool able to replace K3b?
by Ralf Mardorf 26 Jan '14

26 Jan '14

Hi, a short question but a long story, perhaps somebody could give some hints. To stop a green drive spinning up and down again and again I removed gvfs from my machine, but each time I used K3b seemingly a KDE thingy makes my drive spin up and down again and again until I reboot. Is anybody aware if developers of desktop environments care about things like green drives, optional vs hard dependencies? I also noticed that if using a desktop environment's GUI editor as root this could cause serious issues nowadays. Am I the only one who tries to get rid of desktop environments and the software, such as the desktop environment's editors? I'm experimenting with getting rid of Xfce and I'm testing Jwm at the moment, but generating the menu is PITA and to find good replacements for editors, file browsers etc. isn't easy. Does anybody know burning software that is nearly as comfortable as K3b is, but that doesn't need GNOME or KDE dependencies? Regards, Ralf

9 10

[arch-general] Deploy Arch linux to many virtual machines
by Кравец Роман 24 Jan '14

24 Jan '14

Hello! Could you please me. Me need install very much virtual machines with Arch linux. In Centos I can use kickstart and put in parameter on boot over PXE. How I can make auto-installation over PXE in Arch?

5 10

[arch-general] python-dbus upgrade 1.20-2 fails
by Mark Lee 23 Jan '14

23 Jan '14

Salutations, Upgrading from python-dbus-1.20-1 to 1.20-2 on Arch Linux 64 bit fails with the following error: ------ error: failed to commit transaction (conflicting files) python-dbus: /usr/lib/python3.3/site-packages/dbus/__pycache__/__init__.cpython-33.pyc exists in filesystem python-dbus: /usr/lib/python3.3/site-packages/dbus/__pycache__/_compat.cpython-33.pyc exists in filesystem python-dbus: /usr/lib/python3.3/site-packages/dbus/__pycache__/_dbus.cpython-33.pyc exists in filesystem python-dbus: /usr/lib/python3.3/site-packages/dbus/__pycache__/_expat_introspect_parser.cpython-33.pyc exists in filesystem python-dbus: /usr/lib/python3.3/site-packages/dbus/__pycache__/_version.cpython-33.pyc exists in filesystem python-dbus: /usr/lib/python3.3/site-packages/dbus/__pycache__/bus.cpython-33.pyc exists in filesystem python-dbus: /usr/lib/python3.3/site-packages/dbus/__pycache__/connection.cpython-33.pyc exists in filesystem python-dbus: /usr/lib/python3.3/site-packages/dbus/__pycache__/decorators.cpython-33.pyc exists in filesystem python-dbus: /usr/lib/python3.3/site-packages/dbus/__pycache__/exceptions.cpython-33.pyc exists in filesystem python-dbus: /usr/lib/python3.3/site-packages/dbus/__pycache__/lowlevel.cpython-33.pyc exists in filesystem python-dbus: /usr/lib/python3.3/site-packages/dbus/__pycache__/proxies.cpython-33.pyc exists in filesystem python-dbus: /usr/lib/python3.3/site-packages/dbus/__pycache__/service.cpython-33.pyc exists in filesystem python-dbus: /usr/lib/python3.3/site-packages/dbus/__pycache__/types.cpython-33.pyc exists in filesystem python-dbus: /usr/lib/python3.3/site-packages/dbus/mainloop/__pycache__/__init__.cpython-33.pyc exists in filesystem python-dbus: /usr/lib/python3.3/site-packages/dbus/mainloop/__pycache__/glib.cpython-33.pyc exists in filesystem Errors occurred, no packages were upgraded. ------ Regards, Mark -- Mark Lee <mark(a)markelee.com>

3 2

[arch-general] Initial build of TDE R14 without hal dependency - Complete
by David C. Rankin 22 Jan '14

22 Jan '14

All, The initial update and build of the Trinity Desktop Environment (TDE) upcoming R14.0.0 release is complete without hal dependency. (x86_64 packages) We will need to locate server space to host initial packages for testing. See the list of completed packages here: https://wiki.archlinux.org/index.php/Trinity#Complete_packages_.28current.29 Current size requirements for the packages is 301M. If you have server space available, please contact me directly. -- David C. Rankin, J.D.,P.E.

1 0

[arch-general] Does something in makepkg now remove '*.a' files automatically during package?
by David C. Rankin 20 Jan '14

20 Jan '14

All, This may be ridiculous, if so I apologize in advance, but something is stripping 'lib*.a' files from completed packages between the time of calling package() and the final package being compressed. Building tdelibs, the following files are produced and installed by package() in ${pkgdir}: /opt/trinity/lib/libtdefakes_nonpic.a /opt/trinity/lib/libtdefakes_pic.a /opt/trinity/lib/libtdefakes.so.14.0.0 /opt/trinity/lib/libtdefakes.so.14 /opt/trinity/lib/libtdefakes.so /opt/trinity/lib/libtdefakes.la The PKGBUILD options are: options=('libtool' '!makeflags' '!strip') The package() function is: package() { msg "Packaging - $pkgname-$pkgver" cd ${srcdir}/build make -j1 DESTDIR="$pkgdir" install } The trinity-tdelibs.install is: post_install() { ldconfig &> /dev/null } post_upgrade() { post_install } post_remove() { post_install } I know libtdefakes_nonpic.a and libtdefakes_pic.a were installed by make -j1 DESTDIR="$pkgdir" install from the build log: -- Installing: /build/tde-tdelibs/pkg/tde-tdelibs/opt/trinity/lib/libtdefakes_nonpic.a -- Installing: /build/tde-tdelibs/pkg/tde-tdelibs/opt/trinity/lib/libtdefakes_pic.a -- Installing: /build/tde-tdelibs/pkg/tde-tdelibs/opt/trinity/lib/libtdefakes.so.14.0.0 -- Installing: /build/tde-tdelibs/pkg/tde-tdelibs/opt/trinity/lib/libtdefakes.so.14 -- Installing: /build/tde-tdelibs/pkg/tde-tdelibs/opt/trinity/lib/libtdefakes.so -- Installing: /build/tde-tdelibs/pkg/tde-tdelibs/opt/trinity/lib/libtdefakes.la However, the '.a' files are not present in the final tdelibs package: tar -tJf tde-tdelibs-14.0.0-1-x86_64.pkg.tar.xz | grep tdefakes tar: Ignoring unknown extended header keyword 'SCHILY.fflags' tar: Ignoring unknown extended header keyword 'SCHILY.fflags' tar: Ignoring unknown extended header keyword 'SCHILY.fflags' tar: Ignoring unknown extended header keyword 'SCHILY.fflags' tar: Ignoring unknown extended header keyword 'SCHILY.fflags' tar: Ignoring unknown extended header keyword 'SCHILY.fflags' tar: Ignoring unknown extended header keyword 'SCHILY.fflags' tar: Ignoring unknown extended header keyword 'SCHILY.fflags' opt/trinity/lib/libtdefakes.so opt/trinity/lib/libtdefakes.so.14.0.0 opt/trinity/lib/libtdefakes.so.14 opt/trinity/lib/libtdefakes.la So both /opt/trinity/lib/libtdefakes_nonpic.a and /opt/trinity/lib/libtdefakes_pic.a were at some point stripped from the final package. How did they get removed from the package? What did it? If I'm just being dense, sorry for the noise, but a polite pointing to a link or some explanation would greatly be appreciated. I also know that this stripping of '.a' files did NOT occur a year or so ago, because tdelibs packages built with the same PKGBUILD contain the missing files: tar -tJf tde-tdelibs-3.5.14_dev-1-x86_64.pkg.tar.xz | grep tdefakes tar: Ignoring unknown extended header keyword `SCHILY.fflags' tar: Ignoring unknown extended header keyword `SCHILY.fflags' tar: Ignoring unknown extended header keyword `SCHILY.fflags' tar: Ignoring unknown extended header keyword `SCHILY.fflags' tar: Ignoring unknown extended header keyword `SCHILY.fflags' tar: Ignoring unknown extended header keyword `SCHILY.fflags' tar: Ignoring unknown extended header keyword `SCHILY.fflags' opt/trinity/lib/libtdefakes.so opt/trinity/lib/libtdefakes_pic.a opt/trinity/lib/libtdefakes_nonpic.a opt/trinity/lib/libtdefakes.la opt/trinity/lib/libtdefakes.so.4 opt/trinity/lib/libtdefakes.so.4.2.0 What say the experts? -- David C. Rankin, J.D.,P.E.

3 3

[arch-general] Updated TDE build underway for Arch (hal no longer required)
by David C. Rankin 19 Jan '14

19 Jan '14

All, I am in the process of updating the build scripts for TDE for the upcoming release of R14 which is the first full release of TDE that eliminated dependency on hal. The official release of R14 should occur within the next two weeks. Time permitting, we should have all PKGBUILDS for TDE on arch complete by mid-February. I am updating https://wiki.archlinux.org/index.php/Trinity as time permits. TDE will install in /opt/trinity. If you have any suggestion or pointers for the build or if you are interested in the project, feel free to contact me directly. -- David C. Rankin, J.D.,P.E.

1 0

[arch-general] namcap - project in /opt, custom rules file - base on elffiles.py or rpath.py?
by David C. Rankin 18 Jan '14

18 Jan '14

Guys, I am trying to learn how to create custom rules for checking tde packages installed in /opt. I would like to create a custom rules file that would allow use of namecap -e elfpaths,rpath -r tdepaths and have it verify files placed in valid directories. I have looked at elffiles.py and rpath.py as templates, but not coding in python, I don't know which would serve as the best template, or if it matters. It looks like elffiles.py validates file/binary locations with rpath.py handles libraries. I've looked at the Namcap wiki and still have questions. Would one (elffiles.py or rpath.py) be better than the other for this purpose or should I build a custom rule from each. New to namecap, that's why I'm asking. -- David C. Rankin, J.D.,P.E.

1 0