On Sun, Jul 28, 2019 at 06:21:57PM +0200, Helmut Grohne wrote:
> Hi Ted,
>
> On Sun, Jul 28, 2019 at 10:04:48AM -0400, Theodore Y. Ts'o wrote:
> > Yes, I had noticed that this was breaking some of the ports build as
> > well, and so I have a similar patch in my tree already. I was going
> > to wait a few days to see if there were any other issues, and to allow
> > 1.45.3-3 to enter testing before I was going to do another upload. Is
> > it urgent for you such that you would prefer an upload sooner?
>
> If you defer it, I'll have to add the patch to rebootstrap.git and later
> revert it. That's unfortunate, but certainly possible. I'll need some
> fix (either in e2fsprogs or rebootstrap), because otherwise I'm blind to
> later failures. Knowing your plans is key here. I'll assume that you
> defer it unless you mail back with 12h.
When I say "defer" I mean for less than a week. 3 days so e2fsprogs
can enter testing, and then usually with the greater exposure, more
bugs get reported, and then a handul of days for me to fix up problems
and re-upload. If I re-upload now, it resets the unstable->testing
countdown timer, and it further bloats things like
snapshots.debian.org. I've already uploaded 3 releases in 3 days, so
I figured it might be considered polite if a batched up some changes
instead of continuing to follow a "add a git commit, push a debian
package release" pattern.
How critical is it for rebootstrap.git to be returning a problem for a
handful days? I guess I'm missing something about why a few days of
it reporting breakage is such a big issue?
> It just occured to me that there might be a simpler implementation
> (untested):
>
> override_dh_auto_test:
> dh_auto_test -- V=1
Possibly. I'm still waiting back from the ia-64 porting folks about
why the m_hugefile test is failing when run on the ia-64 buildd, but
it works just fine when I run it on a ia-64 development machine. So I
may need to do something special for ia-64, and I haven't yet decided
how to pass in some kind of request (probably using an environment
variable, but I haven't decided for sure yet) so that we skip the
m_hugefile test on ia-64. (I'm guessing it's due to lack of disk
space, since it requires 1.1G of space in /tmp to run the test, but
I'm not 100% sure.)
So that's another issue that's pending a debian package release, and
another reason why it didn't seem like breaking cross builds for a few
days is such an unacceptable tragedy? I do like to batch up fixes,
instead of rolling new releases every day or two.
Cheers,
- Ted
