- Arch-general - lists.archlinux.org

[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

[arch-general] difference between arch-nspawn and mkarchroot?
by David C. Rankin 17 Jan '14

17 Jan '14

Devs, DeveloperWiki:Building_in_a_Clean_Chroot notes that updating the chroot is now done by: arch-nspawn $CHROOT/root pacman -Syu instead of mkarchroot -u $CHROOT/root Checking the help for both files I note (1) the -u option is dropped from mkarchroot, and (2) the help output for both arch-nspawn and mkarchroot are identical. So what is the difference between the two? -- David C. Rankin, J.D.,P.E.

2 3

[arch-general] Xen VGA passthrough unbind VGA from nouveau
by Dimitris Zervas 16 Jan '14

16 Jan '14

Hello, I am on latest kernel 3.12.6-1-ARCH with xen 4.3.1-2 with an i7-3820 and Asus P9X79 Deluxe with 16GB ram. I have 2 graphics cards, an EVGA 9800GT and an Asus GTX660 Ti. I want to passthrough the 660 to a win 7 domain. The problem is that whatever I do (pciback or pci-stub), nouveau detects the 660 normally and when I try to unbind it throws up a kernel panic. What I did with pci-stub: added pci-stub to Modules in mkinitcpio added pci-stub.ids=my:id With pciback: The same steps with pci-stub... A solution is to blacklist nouveau, but I want X server running on my 9800 (Arch on two monitors and windows to the other). Another problem I faced when I blacklisted nouveau, is that the domain is created, but I can only see output on VNC and not on the attached monitor, but it could be that I booted from windows CD (not installed system). not sure. I would be glad if anyone has advice on how to make xen work with nvidia propriety drivers (for 3d acceleration), but that's not my main problem right now. I think that a lot of people have run to the same problem (but googling did not help....), and that's why I'm using the mailing list. Thank you.

1 0

[arch-general] on reboot: systemd[1]: Started Generate shutdown-ramfs - hung (hard reset required)
by David C. Rankin 16 Jan '14

16 Jan '14

All, After doing a system update today, I rebooted. The system hung on reboot requiring a hard reset. It has never done this in the past (20 or so reboots). Checking through the log I find: Jan 16 12:43:19 phoinix systemd[1]: Stopping system-netctl.slice. Jan 16 12:43:19 phoinix systemd[1]: Removed slice system-netctl.slice. Jan 16 12:43:19 phoinix mysqld[311]: 140116 12:43:19 InnoDB: Shutdown completed; log sequence number 7507539 Jan 16 12:43:20 phoinix mysqld[311]: 140116 12:43:20 [Note] /usr/bin/mysqld: Shutdown complete Jan 16 12:43:20 phoinix systemd[1]: Stopped MariaDB database server. Jan 16 12:44:03 phoinix systemd[1]: Started Generate shutdown-ramfs. Jan 16 12:44:09 phoinix systemd[1]: Started Generate shutdown-ramfs. Jan 16 12:44:19 phoinix systemd[1]: Started Generate shutdown-ramfs. Jan 16 12:44:20 phoinix systemd[1]: Started Generate shutdown-ramfs. Jan 16 12:44:22 phoinix systemd[1]: Started Generate shutdown-ramfs. Jan 16 12:44:23 phoinix systemd[1]: Started Generate shutdown-ramfs. Jan 16 12:44:24 phoinix systemd[1]: Started Generate shutdown-ramfs. Jan 16 12:44:26 phoinix systemd[1]: Started Generate shutdown-ramfs. Jan 16 12:44:36 phoinix systemd[1]: Started Generate shutdown-ramfs. Jan 16 12:44:38 phoinix systemd[1]: Started Generate shutdown-ramfs. -- Reboot -- So the box hung on shutdown at 12:44:03 and it just sat there until I did a hard reset (pushed the reset button). Has anybody experienced a similar hang on reboot? I welcome suggestions since this box is at a remote location and I need to insure a clean remote reboot. What else to check? -- David C. Rankin, J.D.,P.E.

1 0