- Arch-general - lists.archlinux.org

[arch-general] Uninstalling single package from i686 archroot without cleaning
by David C. Rankin 30 Jan '14

30 Jan '14

All, The i686 archroot on the x86_64 box worked perfectly building i686 TDE. However, as I tweak packages, I need to 'uninstall' a package from the rw-layer without cleaning the entire archroot. Since this is i686 on a x86_64 box how do I properly chroot the archroot so that I can run pacman -R package name? Can I somehow: mount --bind some_dev $CHROOT/dev mount -t proc none $CHROOT/proc mount -t sysfs none $CHROOT/sys cd $CHROOT some_chroot_cmd So that the i686 system will be functional enough to remove a package? I have seen the Arch64_FAQ page discussing the linux32 wrapper working with i686 chroots created by installing with i686 ISO "quickinstall", but this setup is just an i686 archroot. (will it work?) I want to avoid cleaning the archroot or deleting and recreating a new one just to test minor changes to package content adjustments due the setup requiring several hundred dependencies and packages to rebuild. What say the experts? -- David C. Rankin, J.D.,P.E.

2 2

[arch-general] Is there a shortcut to defining PKGBUILD groups=() dependencies?
by David C. Rankin 29 Jan '14

29 Jan '14

All, For TDE I have several PKGBUILD groups for installation defined: tde-base : minimum possible install (up to tdebase) tde-core : 'tde-base' + common additional packages tde-dev : 'tde-core' + development bindings and packages tde-extra : 'tde-core' + additional desktop features tde-multimedia : 'tde-core' + all AV and CD/DVD apps (amarok, kaffeine, etc.) tde-complete : 'tde-extra' + all building packages I define what belongs in each group by including every group a package belongs to in the groups=() array. For example, if I want k3b included in every install except 'tde-base' I then just define the groups array for k3b as follows: groups=('tde-core' 'tde-dev' 'tde-extra' 'tde-multimedia' 'tde-complete') I am just wondering if a shortcut exits somewhere, like some meta-file that holds relationships between groups? Is there some way at the group level to some way to say group 'tde-base' automatically gets included when 'tde-core' is chosen and that 'tde-core' gets included when 'tde-extra' is chosen? I haven't found anything that says that, but I didn't entirely understand what some of the 'meta' packages for kde4 were doing and thought I would check. -- David C. Rankin, J.D.,P.E.

1 0

[arch-general] Kernel 3.13
by Jonathan Hudson 28 Jan '14

28 Jan '14

When you upgrade to kernel 3.13, pacman considerately informs you that you must have a keyboard hook in mkinitcpio.conf. What you're not told is that if you have an AT keyboard, you also need to ensure that the atkbd module is loaded, otherwise you probably won't have a working keyboard on reboot. -jh

8 10

[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