Summary: | ebuild for xfsprogs | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Hanno Böck <hanno> |
Component: | New packages | Assignee: | Brad Cowan (RETIRED) <bcowan> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | alessandro.pisani |
Priority: | High | ||
Version: | 1.4_rc1 | ||
Hardware: | x86 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
xfsprogs-2.0.3.ebuild
xfsprogs-2.0.3.ebuild acl-2.0.18.ebuild attr-2.0.9.ebuild dmapi-2.0.5.ebuild xfsdump-2.1.5.ebuild |
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.) |
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)