Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 29 Jul 2018 19:38:42 +0300
From: Sergey Kurokhtin <>
Subject: Re: e2fsprogs package update


> I've started to pack the latest version (1.44.3) of the e2fsprogs for Owl.
> 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)?

I'm using VirtualBox VM with Owl current x86_64.
Sure i686 will be next step.

> > 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}

Got it. Thanks!

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:
> Maybe we should have just one -alt patch and that's all.

Ok. I'll take a look to the -alt patch.

> > Failed tests are
> >
> > f_opt_extent
> > m_hugefile
> > t_disable_mcsum_noinitbg
> > t_enable_mcsum
> 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.

I investigated the failing tests and here some results:

m_hugefile tries to create 4T file inside /tmp which is mounted into tmpfs.
So the following error occurs:
"m_hugefile/script: line 40: 104607 File size limit exceeded"
There are two possible solutions:
-- create test file outside /tmp;
-- skip this test if /tmp is mounted into tmpfs.
Something like this:
 df | grep '/tmp' | grep 'tmpfs' > /dev/null 2>&1 && ( echo "Skipped"; exit

Other tests could be fixed using corrections in the 'expect' files with
All calculations are correct but outcome from the e2fsprogs utilites
slightly different than it reflected in 'expect' files.

> 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
> I think --disable-defrag is fine for now, and this is something to
> revisit once we update glibc.

Ok, will do that way.

> Btw, do we really need to bzip RELEASE-NOTES?
> Long term, no.  But for now OK to keep the bzip2.

Got 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.


Will proceed with creating patches.


Content of type "text/html" skipped

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.