Please stabilize app-office/libreoffice 3.3.1. Current state should be pretty good, all the relevant bugs we had were taken care of, no new ones popped up in the last few weeks. Dependencies should be fine too as far as I can see. This is also pretty important cause this will be our first stable release of libreoffice, which prepares the ground for deprecating app-office/openoffice (which has known security bugs, bug #352864) Reproducible: Always
also -bin ?
(In reply to comment #1) > also -bin ? Sure, but I've put that in the separate bug #358909, you're just to fast for me ;-)
in a configure phase: QA Notice: epause is not defined in EAPI=3, please file a bug at http://bugs.gentoo.org
Sorry, I really don't get how bug #358951 can be considered a dependency for this bug. This seem very arbitrary to me. It's a bug sure, but as dependency for stabilization?
(In reply to comment #4) > Sorry, I really don't get how bug #358951 can be considered a dependency for > this bug. This seem very arbitrary to me. It's a bug sure, but as dependency > for stabilization? First time stabilization. We'd rather have no open bugs in it.
(In reply to comment #5) > First time stabilization. We'd rather have no open bugs in it. No open bugs in a package the size of libreoffice? I go ahead and say that's simply not possible. This sort of QA problems would surely be nice to be solved, but as long as it's not preventing someone from building and running the package I don't see how this could be a blocker. Again: This seems awfully arbitrary to me, if we start to dig in the upstream bugzilla(s), I'm sure we'll find dozens of more severe and real issues. Having said that: Patches happily accepted ;-)
(In reply to comment #6) > (In reply to comment #5) > > First time stabilization. We'd rather have no open bugs in it. > > No open bugs in a package the size of libreoffice? I go ahead and say that's > simply not possible. > > This sort of QA problems would surely be nice to be solved, but as long as it's > not preventing someone from building and running the package I don't see how > this could be a blocker. Again: This seems awfully arbitrary to me, if we start > to dig in the upstream bugzilla(s), I'm sure we'll find dozens of more severe > and real issues. The "no bugs" requirement is not within the package itself (I know that's not possible), but with respect to bugs reported in the Gentoo bugzilla (bugs that affect our users and Gentoo QA in general). There is a clear policy about stabilization (read the devmanual for that, seems to be off-line atm). The reasoning behind the block is that at this point the arch teams still can force some/this level of QA on the development team. As soon we stabilize it and during stabilization of the next version someone mentions this, devs will argue that it was approved previous time and this bug would not be blocked again and the bug could wait for a very long time to be fixed (many bugs get this "treatment", making it for arch testers sometimes very laborious to stabilize a package as they also have to check the bug in previous versions or because of tests that fail). > Having said that: Patches happily accepted ;-) Sure, we'll wait while someone patches it. Got >100 other stabilization requests waiting, so we're not in a hurry. ;-)
(In reply to comment #7) > (In reply to comment #6) > > (In reply to comment #5) > > > First time stabilization. We'd rather have no open bugs in it. > > > > No open bugs in a package the size of libreoffice? I go ahead and say that's > > simply not possible. > > > > This sort of QA problems would surely be nice to be solved, but as long as it's > > not preventing someone from building and running the package I don't see how > > this could be a blocker. Again: This seems awfully arbitrary to me, if we start > > to dig in the upstream bugzilla(s), I'm sure we'll find dozens of more severe > > and real issues. > > The "no bugs" requirement is not within the package itself (I know that's not > possible), but with respect to bugs reported in the Gentoo bugzilla (bugs that > affect our users and Gentoo QA in general). Well, that sounds like a good definition for "arbitrary", blocking on minor niggles we see ourselves and closing the eyes to sea of software failure around us ;-) But I guess it's not THAT useful to continue this conversation. > There is a clear policy about stabilization (read the devmanual for that, seems > to be off-line atm). The reasoning behind the block is that at this point the > arch teams still can force some/this level of QA on the development team. As > soon we stabilize it and during stabilization of the next version someone > mentions this, devs will argue that it was approved previous time and this bug > would not be blocked again and the bug could wait for a very long time to be > fixed (many bugs get this "treatment", making it for arch testers sometimes > very laborious to stabilize a package as they also have to check the bug in > previous versions or because of tests that fail). I totally understand that. So this might be the perfect moment to explain that app-office/libreoffice actually is NO new package but the direct continuation of what we have now as app-office/openoffice. Some explanation for those not following the situation closely: We've been using Go-OO / ooo-build for our openoffice-packages for years, which has now emerged into the full Libreoffice project. Besides a bunch of extra features / linux integration work ooo-build (and now Libreoffice) are the only sane way to build OOo/Libreoffice on Linux. The consequence of this is: There won't be any more new releases for app-office/openoffice, users should move to app-office/libreoffice instead (which is also the direct successor feature-wise). That's also one of the very reasons for the stabilization wish: To officially deprecate app-office/openoffice (and remove it from the tree) and switch to libreoffice as default. I might also point out that the last app-office/openoffice in the tree has a bunch of known security problems, see bug #352864 In short: This is hardly a "normal" new package up for stabilization.
The QA problem is not important here so I don't consider it as a blocker. amd64 done
Myckel thanks for insisting on this policy, you are in general right, but Andreas' reasons are appealing and I agree with him here.
(In reply to comment #10) > Myckel thanks for insisting on this policy, you are in general right, but > Andreas' reasons are appealing and I agree with him here. NP, just a bit fed up with the many ebuilds that have issues. I know that this is a minor issue, and reading back that there are security issues with OO.o I think I was a bit to strict and Andreas' last post made me realise that.
So what keeps us from stabilizing x86, too? AT feedback?
(In reply to comment #12) > So what keeps us from stabilizing x86, too? AT feedback? Time. Libreoffice is not the only package that waits for stabilisation. I will try to do it this weekend, but no guarantee.
x86 stable, closing.
