On Wed, 2015-07-08 at 21:11 +0200, Tobias Klausmann wrote: > Hi! > > On Wed, 08 Jul 2015, Ciaran McCreesh wrote: > > On Wed, 8 Jul 2015 20:07:34 +0200 > > Tobias Klausmann <klaus...@gentoo.org> wrote: > > > In essence, assuming we can "just scale" to make CI work is > > > ignoring the matter of the slower archs. And I suspect the "it > > > works on amd64, fuck everyone else" is not something we want to > > > pick as a motto. > > > > "It works on amd64 on a clean build system" is a heck of a lot better > > than "it may or may not work on one developer's heavily modified > > box"... The point of testing is not to catch all problems. It's just > > there to catch some simple screwups, cheaply. > > Agreed. Still, in my experience, problems that are not seen on > amd64 are the vast majority of timesinks. Usually, by the time > non-amd64 shows up on a non-security bug, the Basic Bullshit™ has > been sorted. And even if it isn't: Arches are usually quick to > point it out and the rest of arches move on to the next bug. The > truly arch-dependent bugs are what wastes my time: > > For example: > > - dependencies not being keyworded for arch or ~arch but only > amd64/~amd64 > - dependencies not even building on ~arch, but on ~amd64 > - package assuming availability of gcc/ghc/Python-X.Y when > arch/~arch only has something for <Y or <X > - my favourite: assuming udev is at version X for arch/~arch when > it has been broken there for roughly twelve kernel versions due > to udev/systemd upstream not caring. The information is one > equery-y command line away, but no, let's file that bug. >
That's a failing of the arch team or the committer then - or whomever keyworded the package without testing the dependencies. That's why the keywording bugs happen when dependencies change - and yes, occasionally a dependency loses it's keywords and that may be where the issue comes from, I'm not sure. This used to be watched very closely, but I believe the tool being used broke at some point. What exactly do you mean, it's just one command line away but let's file the bug - yes a bug SHOULD be filed, so that the people know of the issue so it doesn't get repeated, over and over. > Having every arch team chase the deps for every package is very, > very frustrating, since it is so trivial a problem. We need a > tool that answers the question: "I want to mov cat/pkg-1.2.3 to > stable for arches a, b and c, what do I need?" for _every > package_. Some groups seem to have tooling for this, but it is > far from easily (obviously?) available, so every team gets to > re-discover dependency hell. Ruby is especially bad since > FEATURES=test make the depgraph explode (and sometimes circular). > > Regards, > Tobias > > The only fear I have about CI, is that we turn into every other distro out there where "it builds, ship it!" - I know I prefer to have our arm team actually test the packages more than just doing FEATURES=test (assuming the tests aren't broken on arm) emerge, although I know there are some people on the team who feel that it's too much to actually test all of the arm boards. For a long time, certain binary distros were compiling anything and everything, and if it built for other arches it was available. Even if there was no way it would possibly work on that arch. Regards, Steev
