[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [Ceph-maintainers] Updated ceph backport



On 15.10.2014 21:18, Dmitry Smirnov wrote:
On Wed, 15 Oct 2014 21:03:02 Michael Tokarev wrote:
It doesn't build?  On many arches which debian supports.  That's the
only problem, -- basically,

Is far as I'm concerned it builds on all major architectures.
What could I possibly do about "BD-Uninstallable" on [armhf, mips, powerpc,
sparc]?

Your package does not build because of something.  At least maybe
some investigation is in order, instead of just ignoring the situation.

As for FTBFS on [s390] due to

     "virtual memory exhausted: Cannot allocate memory"

it may (or may not) be fixed on another build attempt but I doubt that I ever
have enough time to follow on such issues in backports unless they affect
[amd64] or [i386].


the backport doesn't exist this way, at
least that's how I see things.  Maybe I'm wrong, and if that's the
case, please correct me.

I respect your high quality standards but I'm not sure if I can keep up...

Ofcourse I was complaining in context of qemu backport.  And there,
I do care about "non-major" (it is not my word, it is your)
architectures, -- for example, many users use qemu on mips to
run x86 code, and many of them request the backport of new features.
I can't say to them "I don't care because there's some dependency
wchich is not mine and you're not upstream".  That'd be wrong, and
there's nothing about "high standards" in there.

Either you do care about the backport, and, at least, do the right thing
and mark cleanly that it will (or should) be available on that and that
arch -- so that others who use it know to enable it only on these
arches.  Or get the missing arches going somehow, by backporting
the missing deendencies (as I had to do too), or pinging other
maintainers or whatnot.

What I'm saying is that the current behavour isn't really the best one
to use, -- it really is "fire and forget", or "don't care".  There's
nothing about high standards really.

Thanks,

/mjt




Reply to: