[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 23 Jul 2018 13:21:58 +0200
From: Solar Designer <solar@...nwall.com>
To: owl-dev@...ts.openwall.com
Subject: Re: e2fsprogs package update
Hi,
On Mon, Jul 23, 2018 at 01:24:30PM +0300, Sergey Kurokhtin wrote:
> It's nice to become a part of the Owl team.
Thank you for joining us.
All - although the future of Owl is still unclear (as per the recent
discussion on owl-users), Sergio wanted to help and I thought why not.
I also still (co-)administer some Owl installs where things like e.g.
newer OpenSSL are needed anyway (and I now have 1.0.2o in /opt), so why
not make them standard for others to maybe use as well. It's probably
comparable effort anyway.
> I've started to pack the latest version (1.44.3) of the e2fsprogs for Owl.
I had suggested e2fsprogs to Sergio as his first package to update
mostly for him to get started. OpenSSL might be next, which is more
important but also trickier (to be discussed in a separate thread).
Sergio, which version of Owl are your test builds on? Also, x86_64 or
i686 (you'll need to test both, but it's OK to work on one arch first)?
> Here some technical questions appeared during the building process:
>
> 1. e2fsprogs-1.44.3 can't be built without the '-std=gnu99' (or c99) key in
> CFLAGS.
>
> e2freefrag.c: In function 'scan_online':
> e2freefrag.c:202:36: error: 'ULLONG_MAX' undeclared (first use in this
> function)
> e2freefrag.c:202:36: note: each undeclared identifier is reported only once
> for each function it appears in
>
> Is it correct to add this key to the .spec file as shown below:
>
> %build
> export CC="%__cc -std=gnu99"
>
> or it should be specified in the other place?
Please add the option to this line, which we already have in the spec:
%{expand:%%define optflags %optflags -Wall}
> 2. Just two patches of five from the previous package version are applied
> correctly during the RPM building.
>
> Succeeded:
> e2fsprogs-1.41.5-owl-blkid-env.diff
> e2fsprogs-1.41.5-owl-tests.diff
>
> Failed:
> e2fsprogs-1.41.14-owl-warnings.diff
> e2fsprogs-1.41.14-up-fix-computation.diff
> e2fsprogs-1.41.5-alt-fixes.diff
>
> So, should I try to implement those patches or just skip it?
> I think the latter is more preferable :)
We should minimize our differences from some upstream except where those
differences are closely related to our project's important differences
from other Linux distros. With lots of minor differences, we end up
spending more time on future maintenance and/or make future updates less
frequently. So yes, we should mostly drop patches. (Also, the "-up"
patch is back-ports from upstream, and should not be needed on newer
upstream versions because those changes had already been made upstream.)
The question is which upstream. I suggest that for some packages we
pick ALT Linux as upstream. Maybe all those where Dmitry V. Levin is
the maintainer. And he is for e2fsprogs, so we need to take a look:
http://sisyphus.ru/en/srpm/Sisyphus/e2fsprogs
Maybe we should have just one -alt patch and that's all.
> 3. 'make check' shows 344 test succeeded and 4 failed.
> Failed tests are
>
> f_opt_extent
> m_hugefile
> t_disable_mcsum_noinitbg
> t_enable_mcsum
>
> Should I investigate why those tests are failed or modify them like
> 'bigarray' test in the e2fsprogs-1.41.5-owl-tests patch to suppress error
> messages?
Probably both investigate and, upon confirmation that these are expected
failures in our case, modify them to suppress the error return codes
(not messages). And then revisit them as we update the kernel, etc., as
I suspect some would no longer be expected failures for us later.
> 4. The e4defrag uses the fallocate64() function which is absent in our
> library. We have fallocate() and posix_fallocate() only. The macros
> generating the error message is
>
> #ifndef HAVE_FALLOCATE64
> #error fallocate64 not available!
> #endif /* ! HAVE_FALLOCATE64 */
>
> What's the best way to fix it? I added the key '--disable-defrag' to the
> configure in the .spec file to build package for now.
I think --disable-defrag is fine for now, and this is something to
revisit once we update glibc.
> 5. I spotted the small issue with RELEASE-NOTES - it's the hard-link to the
> doc/RelNotes/v1.44.3.txt. So the 'bzip -9k' fails during the RPM building
> because of two links to the file. This issue fixed by adding '-f' key to
> the bzip command in .spec.
> Btw, do we really need to bzip RELEASE-NOTES?
Long term, no. But for now OK to keep the bzip2.
We may get rid of those bzip2's of some documentation files (or maybe
change them to xz) for many packages at once.
> 6. There are many warnings like shown below
>
> In file included from ../../lib/ext2fs/ext2fs.h:97:0,
> from mkquota.c:15:
> ../../lib/ext2fs/hashmap.h:21:9: warning: unknown option after '#pragma GCC
> diagnostic' kind [-Wpragmas]
>
> during the make process. This issue don't fail the make process but looks
> not good.
> So how I can suppress or fix it?
I don't know where -Wpragmas is enabled. If it's enabled as part of our
-Wall, then adding -Wno-pragmas to that line might help.
Otherwise it's OK to leave this as-is for now (with the warnings), and
expect they will be gone once we update gcc.
Thanks again,
Alexander
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
