Summary: | =sys-fs/xfsdump-3.1.8 emitting multiple warnings, fails to emerge with =sys-fs/xfsprogs-5.2.1 and sys-apps/util-linux-2.34-r2 | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Jason Chan <graysonchsi> |
Component: | Current packages | Assignee: | Gentoo's Team for Core System packages <base-system> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | bugtrack, crabbedhaloablution, gentoo, gmt, it, kdvgent, pacho, redblade7, toralf |
Priority: | Normal | Keywords: | PATCH |
Version: | unspecified | ||
Hardware: | AMD64 | ||
OS: | Linux | ||
URL: | https://www.mail-archive.com/openembedded-devel@lists.openembedded.org/msg65431.html | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 704336 | ||
Attachments: |
Preliminary patch for emerging =sys-fs/xfsdump-3.1.8 with >=sys-fs/xfsprogs-5.2.0
../xfsdump-3.1.8/temp/environment file Failed emerge log Successful emerge log sys-fs/xfsdump-3.1.8 xfsdump-2019.5.20 ebuild Make xfsdump compatible with newer versions of xfsprogs just refreshed the no-symlink.patch refreshed and used web.archive.org to show issue since oss.sgi.com has been down xfsdump-2019.5.20-avoid-deprecated.patch |
Description
Jason Chan
2019-09-01 23:04:32 UTC
Created attachment 588672 [details]
../xfsdump-3.1.8/temp/environment file
Created attachment 588674 [details]
Failed emerge log
Created attachment 588676 [details]
Successful emerge log
Created attachment 589672 [details]
sys-fs/xfsdump-3.1.8
Same error. uuid.h unusable
Folks, I can confirm problem. It related with https://bugs.gentoo.org/631594 I say about libuuid. I got same error as Jason Chan. With best wishes - Y.D. Yuriy's patch W4M to get xfsdump building. But the build sure looks a mess... not at all sure I would want to rely on xfsdump in the first place, after seeing all those warnings :) (In reply to Greg Turner from comment #6) > Yuriy's patch correction: Jason's patch. Created attachment 595060 [details]
xfsdump-2019.5.20 ebuild
With these in ${FILESDIR}
xfsdump-2019.5.20-compat-with-xfsprogs-5.2.0-and-up.patch
xfsdump-2019.5.20-no-symlink.patch
xfsdump-2019.5.20-prompt-overflow.patch
xfsdump-3.1.6-linguas.patch
Created attachment 595062 [details, diff]
Make xfsdump compatible with newer versions of xfsprogs
The ebuild requires >=xfsprogs-5.2.0 so there's no check if it should be applied or not
Created attachment 595064 [details, diff]
just refreshed the no-symlink.patch
Created attachment 595066 [details, diff]
refreshed and used web.archive.org to show issue since oss.sgi.com has been down
Good to hear that it's actually working for other people! Given that the last release was two years ago, I've made an ebuild of a 2019/05/20 snapshot from https://git.kernel.org/pub/scm/fs/xfs/xfsdump-dev.git/. The only issue I had was xfsdumping/restoring a mounted filesystem; files that were open and modified during the backup (Firefox cache, text files) were missing, expected. Created attachment 599356 [details, diff] xfsdump-2019.5.20-avoid-deprecated.patch This patch comes from https://lore.kernel.org/linux-xfs/a5dc4615-ed91-803e-56a2-1cf5637285d6@sandeen.net/t/ (I had to trivially tweak it by hand to avoid a duplicate hunk which could probably be avoided by dropping something from the ebuild patchset). Gets xfsdump ebuild building again vs. latest and worstest ~amd64. From a fresh Gentoo install compiled this weekend I see that the file /usr/include/xfs/xfs_fs.h from sys-fs/xfsprogs-5.4.0 differs from the file of the last stable kernel sources, sys-kernel/gentoo-sources-4.19.86, that I am using /usr/src/linux-4.19.86-gentoo/fs/xfs/libxfs/xfs_fs.h. Two of the relevant changes that I see are that the kernel has the names of types xfs_bstat_t and xfs_fsop_geom_v1_t for the structs xfs_bstat and xfs_fsop_geom_v1 respectively. I saw that xfs_bstat_t was removed from linux sources https://github.com/torvalds/linux/commit/6f71fb683879c78ba356ca78f2972289443f26eb#diff-49d176a1f8b65915721068b08e59c642 and I beleave that xfs_fsop_geom_v1_t was removed in an older commit, but the 4.19 have them both https://github.com/torvalds/linux/blob/v4.19/fs/xfs/libxfs/xfs_fs.h As the last stabe version of the gentoo-sources is now (2019-01-05 00:53 UTC) sys-kernel/gentoo-sources-4.19.86, may be the xfsprogs should have dependencies of the right kernel versions, and, as a consequence, would have ~x86 and ~amd64 keyworkds. These changes, perhaps, won't cause any harm, but other that we didn't see may do. Or am I mistaken because these kind of differences would never cause problems? Hmm, if this is true, may be other packages existst on the same situation? *** Bug 692972 has been marked as a duplicate of this bug. *** The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=4995538f727b3fbea1b4628b72159c34e78598a1 commit 4995538f727b3fbea1b4628b72159c34e78598a1 Author: Thomas Deutschmann <whissi@gentoo.org> AuthorDate: 2020-02-14 13:47:44 +0000 Commit: Thomas Deutschmann <whissi@gentoo.org> CommitDate: 2020-02-14 13:55:09 +0000 sys-fs/xfsdump: bump to v3.1.9 Closes: https://bugs.gentoo.org/693296 Package-Manager: Portage-2.3.88, Repoman-2.3.20 Signed-off-by: Thomas Deutschmann <whissi@gentoo.org> sys-fs/xfsdump/Manifest | 1 + sys-fs/xfsdump/files/xfsdump-3.1.9-fix-docs.patch | 22 +++++++ .../xfsdump/files/xfsdump-3.1.9-no-symlink.patch | 26 ++++++++ .../files/xfsdump-3.1.9-prompt-overflow.patch | 14 +++++ ...ump-3.1.9-skip-inventory-debian-subfolder.patch | 18 ++++++ sys-fs/xfsdump/xfsdump-3.1.9.ebuild | 69 ++++++++++++++++++++++ 6 files changed, 150 insertions(+) |