On 5 February 2011 08:34, David C. Rankin wrote:

(1) use vbox?

or

(2) use a chroot?

(2) pacman -S devtools extra-i686-build (in PKGBUILD dir) That makes use of mkarchroot and makechrootpkg [1], which makes use of chroot. They are right, some KDE3 applications where no amount of configuration helps only build properly in a clean chroot, without the KDE4 stuff around. https://wiki.archlinux.org/index.php/DeveloperWiki:Building_in_a_Clean_Chroo...

On 05/02/11 11:48, David C. Rankin wrote:

On 02/04/2011 07:21 PM, Ray Rashif wrote:

...

On 5 February 2011 08:34, David C. Rankin wrote:

...

(1) use vbox?

or

(2) use a chroot?

(2)

pacman -S devtools extra-i686-build (in PKGBUILD dir)

That makes use of mkarchroot and makechrootpkg [1], which makes use of chroot.

They are right, some KDE3 applications where no amount of configuration helps only build properly in a clean chroot, without the KDE4 stuff around.

https://wiki.archlinux.org/index.php/DeveloperWiki:Building_in_a_Clean_Chroo...

Thank you Ray, I'll get it setup.

Just a note on devtools, /usr/bin/communitypkg conflicts with the same package from aurtools. I removed aurtools, but wonder if a conflicts() shouldn't be added to the devtools PKGBUILD?

Nope... aurtools is not a supported package. And I have no idea why it has communitypkg in it. Allan

On 02/04/2011 09:19 PM, David C. Rankin wrote:

21:02 archangel:/dat_e/david/bld/tmp/kdebase> sudo makechrootpkg -r /dat_e/david/bld ==> Making package: trinity 9999-1.0 (Sat Feb 5 03:02:26 UTC 2011) ==> Checking Runtime Dependencies... ==> Checking Buildtime Dependencies... ==> Retrieving Sources... ==> Extracting Sources... ==> Starting build()... CMake Error: The source directory "/build" does not appear to contain CMakeLists.txt. Specify --help for usage, or press the help button on the CMake GUI. Aborting... Build failed, check /dat_e/david/bld/copy/build

I see that /dat_e/david/bld/copy holds a copy of the chroot and /dat_e/david/bld/copy/build holds the PKGBUILD pkg, and src dirs. But cmake is obviously not happy with the setup. CMakeList.txt is in my source kdebase dir, but not the root or copy directories created by mkarchrootpkg. Is there something I need to modify or change in PKGBUILD or the mkarchroot setup to have it work with cmake??

Any help appreciated.

I think this has to do with the fact that I'm building from a svn tree and not a tarball. The existing kdebase directory I'm building from look like this: <snip> drwxr-xr-x 6 david david 4096 Jan 25 13:46 libkonq drwxr-xr-x 7 david david 4096 Jan 25 13:46 nsplugins drwxr-xr-x 5 david david 4096 Jan 25 13:46 pics -rw-r--r-- 1 david david 127 Oct 11 16:53 AUTHORS -rw-r--r-- 1 david david 7480 Jan 25 13:47 CMakeLists.txt -rw-r--r-- 1 david david 18273 Jan 18 09:52 COPYING -rw-r--r-- 1 david david 20403 Jan 18 09:52 COPYING-DOCS -rw-r--r-- 1 david david 4077 Jan 25 13:47 ConfigureChecks.cmake -rw-r--r-- 1 david david 7966 Jan 18 09:52 INSTALL -rw-r--r-- 1 david david 429 Oct 11 16:53 Mainpage.dox -rw-r--r-- 1 david david 514 Oct 11 16:53 Makefile.am.in -rw-r--r-- 1 david david 451 Oct 11 16:53 Makefile.cvs -rw-r--r-- 1 david david 1547 Feb 4 13:07 PKGBUILD -rw-r--r-- 1 david david 9035 Jan 18 09:52 README -rw-r--r-- 1 david david 2914 Oct 11 16:53 README.pam -rw-r--r-- 1 david david 3056 Jan 25 13:47 config.h.cmake -rw-r--r-- 1 david david 811 Oct 11 16:53 configure.in.bot -rw-r--r-- 1 david david 8591 Oct 11 16:53 configure.in.in -rw-r--r-- 1 david david 333 Oct 11 16:53 kde.pamd -rw-r--r-- 1 david david 266 Oct 11 16:53 kde3 -rw-r--r-- 1 david david 347 Oct 11 16:53 kdebase.lsm -rw-r--r-- 1 david david 214 Oct 11 16:53 kscreensaver.pamd -rwxr-xr-x 1 david david 2410 Oct 11 16:53 mkpamserv -rw-r--r-- 1 david david 20934 Jan 18 09:52 startkde How do I tell makechrootpkg to use the files in the same directory as the PKGBUILD? In the PKGBUILD I simply have: source=() for the source with works fine when running makepkg, but is somehow failing to copy the files to /dat_e/david/bld/copy/build/ when run with makechrootpkg. It is like I need a way to tell makechrootpkg to send source=(all files in the same dir as PKGBUILD) to makepkg. I could specify an explicit list of directories and files in the PKGBUILD source(), but that seems strange. What say the gurus? -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com

On 02/06/2011 10:49 AM, Tavian Barnes wrote:

On 4 February 2011 23:02, David C. Rankin wrote:

...

How do I tell makechrootpkg to use the files in the same directory as the PKGBUILD? In the PKGBUILD I simply have:

Why is the checkout in the same directory as the PKGBUILD? Have a look at /usr/share/pacman/PKGBUILD-svn.proto, and every -svn package in the repos/AUR. The checkout happens into src/trinity (for example), which is copied to src/trinity-build, where the build takes place.

Tavian, thanks for your suggestion. For trinity, the whole svn tree is already on my computer: ~/tbld/trinity ~/tbld/trinity/dependencies ~/tbld/trinity/dependencies/tqtinterface ~/tbld/trinity/dependencies/arts ~/tbld/trinity/kdelibs <snip> I have the PKGBUILDs each trinity module directory (eg. {tqtinterface,arts,kdelibs,etc...} ) So there is no 'svn checkout' performed from within the PKGBUILDs. For example, each directory is similar to the following: 20:35 alchemy:~/tbld/trinity/kdelibs> ls -1 admin arts cmake dcop <snip> CMakeLists.txt <snip> PKGBUILD <snip> From ${srcdir}, cmake is called by: cmake ../ This fails with makechrootpkg because nothing gets copied to the chroot. Is there a way to fix this? -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com

On 02/06/2011 09:05 PM, Ray Rashif wrote:

On 7 February 2011 10:38, David C. Rankin wrote:

...

This fails with makechrootpkg because nothing gets copied to the chroot. Is there a way to fix this?

Yes, the copying is "hardcoded". Things in the source array are copied, and along with those additionally the changelog and install scriptlet. See line 170 onwards of makechrootpkg.

Unfortunately, aside from directly editing makechrootpkg itself, I don't see how to 'fix' this. Maybe if you changed the way you're going about doing the builds..but I'll have to look a little deeper to actually comment any further.

Thanks Ray, I could shoot myself. I originally did the PKGBUILDs to do a svn checkout in src, but then didn't want to re-download a complete copy of the tree every time makepkg was run. I was using a snvversion test on the .svn/entries to see if a new version existed, but that didn't do what I wanted. The good news is that adding the code to the PKGBUILD to have them do a svn checkout is a simple 5-10 lines at the top of each PKGBUILD. My overall goal was to write a shell script that would take the standard trinity svn checkout, add the PKGBUILDs, then loop through the modules in the proper build order to provide a complete build of trinity for those that don't want to use the binary packages. Easier on the dev to. Just kick off a build, go do something else, check back, still running, go do something else.... or stop and fix what broke. I guess I was using a 'tree' focused approach: Saying "I have the tree", now let's do PKGBUILDs for the tree and then tie them together with a master build script. The alternative would be the PKGBUILD focused approach: Saying "Let's build PKGBUILDs to retrieve their part of Trinity via svn and if we build them all, then we will have the whole svn tree after we build the las module. I originally shied away from this approach in order to use the simple 'svn up *' in the trinity base directory to coordinate updates to all modules and eliminate the possibility that the download of a single module and update there may put it out of sync with the rest of the tree if dependent packages below it received updates relied upon by the module you are working on. The makearchroot tool may be what drives me back to this approach. I can get i686 done in VBox, but I can't do x86_64 in Virtualbox even on a 64-bit box. So makearchroot work for the 'in source' build would be ideal. Too bad I can't just define srcdir as '../' such that the existing svn source would get into the chroot. Ideas? -- David C. Rankin, J.D., P.E.