Just version update. In release-1.4.txt is a note that xfs-related things need updates. Was trivial, just renaming the ebuild, changing download-location and S-var. You need to mask >=sys-apps/xfsprogs-20020124 Shall I do this with the other xfs-related things as well? (acl, attr, dmapi, xfsdump)
Created attachment 4256 [details] xfsprogs-2.0.3.ebuild
Sounds great :) go ahead and submit them. I'll mask them, as to my knowledge they depend on specific kernel patches too correct? THX
Created attachment 4259 [details] xfsprogs-2.0.3.ebuild Better use this one (changed download-location to a more permanent one as they might remove it from the latest-dir soon)
Created attachment 4260 [details] acl-2.0.18.ebuild
Created attachment 4261 [details] attr-2.0.9.ebuild
Created attachment 4262 [details] dmapi-2.0.5.ebuild
Created attachment 4263 [details] xfsdump-2.1.5.ebuild
Okay, here come the other xfs-stuff updates. if they should go into portage as default, don't forget to mask the date-versioned ebuilds.
seems as though there's a xfsprogs-2.2.2 and 2.0.3 isn't in the current dir just in the lastest dir
Ok updated to xfsprogs-2.2.2 and commited the packages are now masked for testing THX
They doesn't work fine for me actually: acl,attr,dmapi and xfsprogs will create wrong links on filesystem, causing xfsdump to be unable to compile. in example: output of ls -l /usr/lib/*attr* lrwxrwxrwx 1 root root 56 Oct 3 13:16 libattr.a -> /var/tmp/portage/attr-2.0.9/image//usr/libexec/libattr.a lrwxrwxrwx 1 root root 57 Oct 3 13:16 libattr.la -> /var/tmp/portage/attr-2.0.9/image//usr/libexec/libattr.la lrwxrwxrwx 1 root root 12 Oct 3 13:16 libattr.so -> libattr.so.1 lrwxrwxrwx 1 root root 16 Oct 3 13:16 libattr.so.1 -> libattr.so.1.0.1 -rw-r--r-- 1 root root 10542 Oct 3 13:16 libattr.so.1.0.1 the same happen for dmapi and acl and xfsprogs: all libraries links are wrong. Bye, Alessandro
I totally reworked these ebuilds as they were horribly out of date....hopefully I fixed the simlinks :)
confirmed: symlinks are now okay. thank you :)
now masked by new arch testing keywords, please read the following to unmask: Another important snippet. If you want to unmask all ~x86 KEYWORDSed ebuilds, add the following to your /etc/make.conf: ACCEPT_KEYWORDS="~x86" ACCEPT_KEYWORDS is incremental like USE so it *will* keep the existing "x86" that is defined in your profile. This can also be done using the environment for temporary testing purposes: # export ACCEPT_KEYWORDS="~x86" (or "~ppc" or "~sparc", etc.)
