yes we should. next 2 weeks are busy, but then it should be better. i'll send you a pm.amigo wrote:Say aragon, since you are just around the corner from me, perhaps you'd like to get together over coffee some weekend?
i think i understand that oneI'd give a pretty Penny to make such a date with Joe -though I'd rather be around the corner from him instead of the other way around... AYYYY! Jalisco!
you know that if you use slackwares pkgtool you could eliminate many of those problems you encountered by building the packages thenBut when I'm doing the chrooted phase of my build, that isn't available. I could compile it ahead of time,
This is an oversight -I was adding support for 5 new package formats at once. But, it works here because I have all the pertinent optikns et in the conf file to use CWD for everything. Good catch!The first thing I noticed, testing in Puppy, was that the -C option doesn't work with -PET and -PET2. Some quick grepping shows that 15-make_package_pet does not use $PKG_DEST_DIR anywhere, so I figure that's the problem.
Very good to use a better package format. I'll post an attachment later with my hacked version of pkgtools which uses a more advanced database which supprts/is supported by the advanced database features of src2pkg -including compatibility with slapt-get/gslapt. I also have tools which generate a compile-order list from the package database.I didn't bother looking into it beyond that because I don't intend to use the .pet support anyway (I'm going with .tgz for now, and might come up with my own format later if that isn't good enough - binary packages aren't a big part of this project, I mainly just need to compile things and then log what goes where when they are installed).
Patches wil get you everywhere..."The second thing I noticed is that it doesn't have support for aufs. Normally in Puppy that's fine because it seems to use the fuse deal instead. But when I'm doing the chrooted phase of my build, that isn't available. I could compile it ahead of time, and probably will in the long run, but for now, I just rely on the native unionfs or aufs support in the host system's kernel. Since the version of Puppy I'm running uses aufs, src2pkg won't work with the -UNION option unless I patch it. It's a simple enough change that I'm wondering whether there is perhaps a reason it doesn't already support aufs? Is it known to be unstable when used with src2pkg? Or was this just an oversight? I've attached the patch I made, and have been using this to build my system and so far haven't really had any problems."
Using a real hard-disk installation is always best -especially for low-level stuff like glibc. To upgrade glibc on a running system, you need to go into runlevel 1 'maintenance mode' so that nothing which is using glibc is running. Even then, you may find that things are weird until you reboot.I did have an issue after installing glibc, but I'm not sure if that's due to aufs or not. It compiled and installed fine, but then something broke and anything that tried to view my active mounts (like running the "mount" command, or running "df") would segfault, and trying to view regions of the filesystem involved with the build would cause weird things to happen. I had a kernel oops in /var/log/messages about include/linux/dcache.h:324. But after a reboot everything was happy again, and no other packages had this problem (glibc continued to have it any time I tried again). I haven't had a chance yet to try compiling glibc from a native non-aufs system yet to compare against.
Yes, it does. And unionfs is probably not exactly the same as aufs. If you've got aufs working there with the patch, it should be trivial to incorporate aufs functionality.Third thing: I'm confused as to the purpose of $EXCL_DIR in 08D-union_root_install. Judging by the name, I would guess that it's meant to hide directories that you don't want to appear in the unioned filesystem. But that doesn't make sense to me, because the mount command has $EXCL_DIR at the bottom of the stack. When I tried building, I got errors relating to /dev, /proc, etcetera. I tried reordering it to put $EXCL_DIR between $PKG_DIR and / instead, and for good measure I added .wh.__dir_opaque files in each of the directories that were created in $EXCL_DIR, and then it worked. I attached the patch so you can better see what I did. Maybe I'm missing something? Or maybe unionfs via fuse handles the layering differently from how aufs does it.
I only recently worked on getting src2pkg to exit with intelligent status from wherever -glad you found a missing spot."Fourth thing: When given an unrecognized option, src2pkg exits with an error code of 0. Is that intentional? I attached a patch that tells it to use "exit 1" instead. This way if there's a glitch in one of my scripts so that they try passing something bogus to src2pkg an error will be detected.
src2pkg tries to be as generic as possible in its' defaults -anything outside those boundaries is worthy of documentation -that was the first emphasis of the src2pkg API. You can always use:"Fifth thing: Lots of packages provide a "make check" rule, but there doesn't seem to be a good way to run this short of making a .auto script and inserting it, which duplicates a lot of code. So I made a patch that adds a 'verify_build' function (in the /usr/libexec/src2pkg/07A-verify_build file). This function will run "$DEFAULT_MAKE_COMMAND check" or whatever has been defined in $VERIFY_COMMAND, logging the results if logging is enabled, and displaying a warning if it doesn't return 0. There is also an $EXIT_ON_VERIFY_FAILURE variable that when set to "YES" will tell it to exit if there is a failure. Running the check can be enabled by passing the -VER option to src2pkg (or setting VERIFY_BUILD="YES"), and $VERIFY_COMMAND can be set with the -t= or --test_build= option (which implies -VER). I've provided the patch, and also a separate patch for the man file (when it's decompressed). There are probably some example files or something that also need patching, and maybe the sample configuration file. I haven't actually gotten around to updating my build system to take advantage of this yet, so it hasn't been heavily tested. It does seem to work though.
I think I see an easy way to implement the 'no-dive' part -src2pkg has the '-s=??' option which lets you specify the subdir if it is not detected. Adding a 'none' option or inetgration with an existing option for cmake builds of USE_TOP_DIR.Sixth issue: Some packages (I forget the one I had this problem with) have their configuration in a subdirectory, but shouldn't actually be built from it. They want to be built from their main area with some options given to make (I think it was "make -c src"). The problem is that src2pkg sees the subdirectory and just dives in automatically, so that later when the makefile refers to something in the main area via a "..", it doesn't located it and errors (IIRC, at this point it was in the bind-mounted OBJ_DIR in the unioned environment). My quickfix for that was to edit my .auto script to "touch $SRC_DIR/Makefile" so that src2pkg would stay put. It would probably be better to have a commandline option or flag variable to tell it not to go into a subdirectory even if it finds one. So far I've only had this issue with the one package, so I haven't gotten around to implementing that.
Hmm, that sounds odd. Anytime you get strange or unexpected results, try building the package using one of the other INSTALL_TYPE options. The most accurate and safe is SAFE. REAL is the same thing but no backups/restoration is done! 100% invasive. UNION and JAIL will both occassionally fail. DESTDIR is the least reliable, but still most packages can be built as a normal user using the DEST option. The UNION option is, so far, more reliable than JAIL."Seventh thing: When using -JAIL instead of -UNION, it seems that programs that would have otherwise installed over a symlink to busybox (for example, /usr/bin/realpath), the package it creates includes /bin/busybox (but is otherwise normal and does include the actual file that it should have). Maybe that's one of the known flaws with the -JAIL method. Figured I'd point it out just in case.
Well, I'm putting very little energy into that. The only good reasons I can see (besides time) to support binary packages are for closed-source stuff and for embedded systems where it isn't practical to compile on the system itself. Well, and also for if you happen to have multiple systems that are all compiled the same way, so that you don't have to recompile multiple times.Hey Pizzasgood !
good to see you that you are doing a source build with tgz packages also
the format is well established any custom packages you make
will be very linux friendly
Thanks. I basically just copied the 07-compile_source file and hacked it into something that seemed like it worked the way I wanted. There's probably a lot of extra stuff that isn't really applicable, but not being very familiar with src2pkg's internals I didn't want to strip out too much.src2pkg tries to be as generic as possible in its' defaults -anything outside those boundaries is worthy of documentation -that was the first emphasis of the src2pkg API. You can always use:
MAKE_COMMAND='make all check'
Same for sequences like:
MAKE_COMMAND='make depend all'
That said, I'll definitely look hard at the patch and try to get the feature incorporated to work smoothly.
Code: Select all
SOURCE_NAME="realpath-0.1.tar.gz"
EXTRA_CONFIGS="--enable-dohicky"
MD5=5f56e159ffde60a4a5edd71c1f2db297
URLS=(
http://some_repo.com/pub/realpath-0.1.tar.gz
http://some_mirror.com/pub/realpath-0.1.tar.gz
)
WEB=http://www.realpath_website.com/Sure thing. I attached the simple realpath program I wrote.If you can give me an example source which is doing this, it would help. This sounds like a missing '-a' option to the 'cp' command somewhere... I'll have a look.
I know. It just doesn't work if it was compiled as a module and has not been loaded, so I was trying to come up with a way to check for that possibility that would also work through a chroot. I haven't come up with anything, so I'll just make sure to modprobe unionfs before I do that stage. Not a big deal.The reason that src2pkg looks at /proc/filesystems is because the feature unionfs(or aufs) feature my be *hard-linked* into the kernel insetad of as a module.
Code: Select all
if [ "$(grep unionfs /proc/filesystems)" ] || [ "$(find "/lib/modules/$(uname --kernel-release)/" -type f -name "unionfs*")" ]; then
echo "Found unionfs support";
fiI'll keep that in mind.Still, the use of any layered filesystem is 'iffy' for heavy development, as is the use of tmpfs. 'make check' can be a very intensive job -so can compiling with tests, debug or profiling features(try seamonkey).
Cool.I think I'll be able to work in the ability to run 'make check' as an option. The default should probably be to *not* do it, allowing you to enable it from the command-line when wanted.
That's based on home directories, right? I'll have to take a look. I was thinking of using that in case I need to do any goofy stuff that wouldn't be appropriate for src2pkg in general. It might be nice to have a global area for extensions, but maybe with an option for the user to disable them in case they want vanilla src2pkg behavior. Or maybe do it the other way, so that src2pkg will not surprise them if there are extensions they aren't aware of.Have you discovered the ability to use extensions with src2pkg? You can create scraps of code which will be run just before and/or after each of the named src2pkg build steps. This is a good way to add features which are not part of the main program, or to develop new code which might be included. A good example might be including some of the BK code for generating *.desktop files when the package doesn't already include one.
