- Arch-general - lists.archlinux.org

[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

[arch-general] libgcrypt.so.20 missing
by Mark E. Lee 16 Jan '14

16 Jan '14

Salutations! After an upgrade of my entire system, I am now unable to install packages or run any programs that depend on libgcrypt. I get the following error : libgrypt.so.20 not found. Looking at my pacman logs it seems that This error appeared after an update to pth (2.0.7-4 -> 2.0.7-5). I've downgraded the package but it doesn't seem to solve the issue. Regards, Mark -- Mark E. Lee <mark(a)markelee.com>

11 25

[arch-general] libgsf 1.14.28-1 - bug - gsf-libxml.h:26:25: fatal error
by David C. Rankin 15 Jan '14

15 Jan '14

All, Is this a bug or is it me. Looks like a bug in libgsf 1.14.28-1 in the header file: /usr/include/libgsf-1/gsf/gsf-libxml.h If you attempt to include this header file you receive the error: /usr/include/libgsf-1/gsf/gsf-libxml.h:26:25: fatal error: libxml/tree.h: No such file or directory #include <libxml/tree.h> ^ compilation terminated. Example: #include <stdio.h> #include <libxml/tree.h> void main (int argc, char *argv[]) { printf("testing include\n"); } 17:01 phoinix:/dat_e/tde/tstbld/tmp> gcc -o tst tst.c tst.c:3:25: fatal error: libxml/tree.h: No such file or directory #include <libxml/tree.h> ^ compilation terminated. If someone will confirm this is a bug and not me being dense -- I'll file it. -- David C. Rankin, J.D.,P.E.

1 1

[arch-general] Mirrors out of date
by Mark Lee 15 Jan '14

15 Jan '14

Salutations, Pardon me but does anyone know how mirrors are synced and flagged out of date? Regards, Mark -- Mark Lee <mark(a)markelee.com>

6 9

[arch-general] Is out of source building still recommended with cmake in PKGBUILD scripts
by David C. Rankin 15 Jan '14

15 Jan '14

All, Updating PKGBUILDs as specified in VCS_PKGBUILD_Guidelines, I have a svn based source that builds with cmake. In the past I have forced out of source building for all cmake built packages. e.g.: build() { cd $srcdir msg "Creating out-of-source build directory: ${srcdir}/${_builddir}" mkdir -p build cd build msg "Starting cmake..." cmake ${srcdir}/blah \ <snip> msg "Building - $pkgname..." make } In https://wiki.archlinux.org/index.php/VCS_PKGBUILD_Guidelines it specifies that "The local repo is left untouched, thus invalidating the need for a -build directory." Am I reading this correctly to say - "creating a separate out-of-source build directory is no longer required -- even for cmake built packages?" Or am I just confused again... -- David C. Rankin, J.D.,P.E.

3 3