* Btrfs-progs 3.19rc1 issues
@ 2015-02-03 22:26 WorMzy Tykashi
2015-02-04 1:19 ` Qu Wenruo
2015-02-04 8:58 ` David Sterba
0 siblings, 2 replies; 3+ messages in thread
From: WorMzy Tykashi @ 2015-02-03 22:26 UTC (permalink / raw)
To: linux-btrfs@vger.kernel.org, David Sterba
Hi David,
I've been watching the 3.19.x branch with interest, and noticed that
you've tagged rc1. Unfortunately, I think I've found a few problems
with it. I will try to explain here:
For the record, I'm building using devtools (a set of clean chroot
build scripts) on an up-to-date Arch Linux box.
1) Building with the following:
./autogen.sh
configure --prefix="/usr"
make
...
make DESTDIR="/path/to/destdir" install
Results in binaries and libraries being installed to
/path/to/destdir/bin and /path/to/destdir/lib respectively.
If I want things to be installed into /path/to/destdir/usr/{lib,bin},
I have to 'export exec_prefix="/usr"'. That's not what I would expect.
Incidentally, --exec-prefix seems to have no effect, the same as --prefix.
2) No matter how you build, the installed btrfsck symlink points to
the build dir's btrfs binary. e.g.
$ ls -l bin/btrfsck
lrwxrwxrwx 1 wormzy users 52 Feb 3 21:14 bin/btrfsck ->
/build/btrfs-progs-git/pkg/btrfs-progs-git/
Assuming that btrfs and btrfsck will always be installed into the same
directory, it should just be a relative symlink to the btrfs binary.
3) By default, 'make test' tries to use installed btrfs-progs shared
object and btrfs-image, rather than the built ones:
$ make test
[TEST] fsck-tests.sh
[TEST] 001-bad-file-extent-bytenr
/build/btrfs-progs-git/src/btrfs-progs-unstable/btrfs-image: error
while loading shared libraries: libbtrfs.so.0: cannot open shared
object file: No such file or directory
failed to extract image
/build/btrfs-progs-git/src/btrfs-progs-unstable/tests/fsck-tests/001-bad-file-extent-bytenr/default_case.img
Makefile:159: recipe for target 'test' failed
make: *** [test] Error 1
...
$ export LD_LIBRARY_PATH="$(pwd):$LD_LIBRARY_PATH"
$ make test
[TEST] fsck-tests.sh
[TEST] 001-bad-file-extent-bytenr
[TEST] 002-bad-transid
[TEST] 003-shift-offsets
[TEST] 004-no-dir-index
[TEST] 005-bad-item-offset
[TEST] 006-bad-root-items
[TEST] 007-bad-offset-snapshots
[TEST] 008-bad-dir-index-name
[TEST] 009-no-dir-item-or-index
[TEST] 010-no-rootdir-inode-item
[TEST] 011-no-inode-item
[TEST] 012-leaf-corruption
./test.sh: line 40: btrfs-image: command not found
failed to extract leaf_corrupt_no_data_ext.btrfs-image
test failed for case 012-leaf-corruption
Makefile:159: recipe for target 'test' failed
make: *** [test] Error 1
...
$ export LD_LIBRARY_PATH="$(pwd):$LD_LIBRARY_PATH"
$ export PATH="$(pwd):$PATH"
$ make test
[TEST] fsck-tests.sh
[TEST] 001-bad-file-extent-bytenr
[TEST] 002-bad-transid
[TEST] 003-shift-offsets
[TEST] 004-no-dir-index
[TEST] 005-bad-item-offset
[TEST] 006-bad-root-items
[TEST] 007-bad-offset-snapshots
[TEST] 008-bad-dir-index-name
[TEST] 009-no-dir-item-or-index
[TEST] 010-no-rootdir-inode-item
[TEST] 011-no-inode-item
[TEST] 012-leaf-corruption
sudo: a password is required
sudo: a password is required
inode 1862 not recovered correctly
test failed for case 012-leaf-corruption
Makefile:159: recipe for target 'test' failed
make: *** [test] Error 1
The sudo thing has been discussed in another thread, so I'll not
comment on that. Thankfully, it will skip the test if sudo isn't
installed. Unfortunately sudo is installed when using Arch's devtools
scripts, so I usually force-skip this test by "rm -rf"-ing
tests/012-leaf-corruption before running 'make test'. I believe that
the PATH/LD_LIBRARY_PATH problem is still something that needs fixing
regardless.
I'm hoping these problems are just easily fixed bugs, but if I'm
misunderstanding something about the build process (especially
regarding --{exec-,}prefix), please let me know.
Cheers,
WorMzy
^ permalink raw reply [flat|nested] 3+ messages in thread* Re: Btrfs-progs 3.19rc1 issues
2015-02-03 22:26 Btrfs-progs 3.19rc1 issues WorMzy Tykashi
@ 2015-02-04 1:19 ` Qu Wenruo
2015-02-04 8:58 ` David Sterba
1 sibling, 0 replies; 3+ messages in thread
From: Qu Wenruo @ 2015-02-04 1:19 UTC (permalink / raw)
To: WorMzy Tykashi, linux-btrfs@vger.kernel.org, David Sterba
-------- Original Message --------
Subject: Btrfs-progs 3.19rc1 issues
From: WorMzy Tykashi <wormzy.tykashi@gmail.com>
To: linux-btrfs@vger.kernel.org <linux-btrfs@vger.kernel.org>, David
Sterba <dsterba@suse.cz>
Date: 2015年02月04日 06:26
> Hi David,
>
> I've been watching the 3.19.x branch with interest, and noticed that
> you've tagged rc1. Unfortunately, I think I've found a few problems
> with it. I will try to explain here:
>
> For the record, I'm building using devtools (a set of clean chroot
> build scripts) on an up-to-date Arch Linux box.
>
> 1) Building with the following:
>
> ./autogen.sh
> configure --prefix="/usr"
> make
> ...
> make DESTDIR="/path/to/destdir" install
>
> Results in binaries and libraries being installed to
> /path/to/destdir/bin and /path/to/destdir/lib respectively.
>
> If I want things to be installed into /path/to/destdir/usr/{lib,bin},
> I have to 'export exec_prefix="/usr"'. That's not what I would expect.
>
> Incidentally, --exec-prefix seems to have no effect, the same as --prefix.
>
>
> 2) No matter how you build, the installed btrfsck symlink points to
> the build dir's btrfs binary. e.g.
>
> $ ls -l bin/btrfsck
> lrwxrwxrwx 1 wormzy users 52 Feb 3 21:14 bin/btrfsck ->
> /build/btrfs-progs-git/pkg/btrfs-progs-git/
>
> Assuming that btrfs and btrfsck will always be installed into the same
> directory, it should just be a relative symlink to the btrfs binary.
>
>
> 3) By default, 'make test' tries to use installed btrfs-progs shared
> object and btrfs-image, rather than the built ones:
>
> $ make test
> [TEST] fsck-tests.sh
> [TEST] 001-bad-file-extent-bytenr
> /build/btrfs-progs-git/src/btrfs-progs-unstable/btrfs-image: error
> while loading shared libraries: libbtrfs.so.0: cannot open shared
> object file: No such file or directory
> failed to extract image
> /build/btrfs-progs-git/src/btrfs-progs-unstable/tests/fsck-tests/001-bad-file-extent-bytenr/default_case.img
> Makefile:159: recipe for target 'test' failed
> make: *** [test] Error 1
>
> ...
>
> $ export LD_LIBRARY_PATH="$(pwd):$LD_LIBRARY_PATH"
> $ make test
> [TEST] fsck-tests.sh
> [TEST] 001-bad-file-extent-bytenr
> [TEST] 002-bad-transid
> [TEST] 003-shift-offsets
> [TEST] 004-no-dir-index
> [TEST] 005-bad-item-offset
> [TEST] 006-bad-root-items
> [TEST] 007-bad-offset-snapshots
> [TEST] 008-bad-dir-index-name
> [TEST] 009-no-dir-item-or-index
> [TEST] 010-no-rootdir-inode-item
> [TEST] 011-no-inode-item
> [TEST] 012-leaf-corruption
> ./test.sh: line 40: btrfs-image: command not found
> failed to extract leaf_corrupt_no_data_ext.btrfs-image
> test failed for case 012-leaf-corruption
> Makefile:159: recipe for target 'test' failed
> make: *** [test] Error 1
>
> ...
>
> $ export LD_LIBRARY_PATH="$(pwd):$LD_LIBRARY_PATH"
> $ export PATH="$(pwd):$PATH"
> $ make test
> [TEST] fsck-tests.sh
> [TEST] 001-bad-file-extent-bytenr
> [TEST] 002-bad-transid
> [TEST] 003-shift-offsets
> [TEST] 004-no-dir-index
> [TEST] 005-bad-item-offset
> [TEST] 006-bad-root-items
> [TEST] 007-bad-offset-snapshots
> [TEST] 008-bad-dir-index-name
> [TEST] 009-no-dir-item-or-index
> [TEST] 010-no-rootdir-inode-item
> [TEST] 011-no-inode-item
> [TEST] 012-leaf-corruption
> sudo: a password is required
> sudo: a password is required
> inode 1862 not recovered correctly
> test failed for case 012-leaf-corruption
> Makefile:159: recipe for target 'test' failed
> make: *** [test] Error 1
>
> The sudo thing has been discussed in another thread, so I'll not
> comment on that. Thankfully, it will skip the test if sudo isn't
> installed. Unfortunately sudo is installed when using Arch's devtools
> scripts, so I usually force-skip this test by "rm -rf"-ing
> tests/012-leaf-corruption before running 'make test'.
I think this can be resolved in several ways:
1) sudo -v to update credentials. (workaround)
If using default timeout, you would have 5 minutes that doesn't need
password and can pass it.
But anyway, it's not a good idea since user needs extra operation and
that's current 'sudo -n' want to
avoid.
2) check by 'sudo -n -v' to ensure credentials before using sudo.
IMHO, this should be the best method. Automatically check the
credentials and if needs password,
just not use sudo and skip the tests.
Other bugs you reported really make sense.
Although not familiar with autoconfig staff, I'll try to fix it if possible.
Thanks,
Qu
> I believe that
> the PATH/LD_LIBRARY_PATH problem is still something that needs fixing
> regardless.
>
> I'm hoping these problems are just easily fixed bugs, but if I'm
> misunderstanding something about the build process (especially
> regarding --{exec-,}prefix), please let me know.
>
> Cheers,
>
>
> WorMzy
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 3+ messages in thread* Re: Btrfs-progs 3.19rc1 issues
2015-02-03 22:26 Btrfs-progs 3.19rc1 issues WorMzy Tykashi
2015-02-04 1:19 ` Qu Wenruo
@ 2015-02-04 8:58 ` David Sterba
1 sibling, 0 replies; 3+ messages in thread
From: David Sterba @ 2015-02-04 8:58 UTC (permalink / raw)
To: WorMzy Tykashi; +Cc: linux-btrfs@vger.kernel.org
On Tue, Feb 03, 2015 at 10:26:00PM +0000, WorMzy Tykashi wrote:
> I've been watching the 3.19.x branch with interest, and noticed that
> you've tagged rc1. Unfortunately, I think I've found a few problems
> with it. I will try to explain here:
Thanks for the early feedback, I did not manage to write the
announcement yesterday. The purpose of the release is to find the
problems that arise from the reworked build system. I'll look at the
issues.
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2015-02-04 8:58 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2015-02-03 22:26 Btrfs-progs 3.19rc1 issues WorMzy Tykashi
2015-02-04 1:19 ` Qu Wenruo
2015-02-04 8:58 ` David Sterba
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).