Am 06.05.2014 03:05, schrieb Charles Plessy: > Le Mon, May 05, 2014 at 08:56:48PM +0200, Bas Wijnen a écrit : >> >> I'm happy to see that there is consensus anyway that forwarding bugs upstream >> is the task of the maintainer. > > Hi all, > > being a package maintainer, I am always uncomfortable when I have the > impression that I am considered like a human patch-pushing machine that > extends > the impact of mass-scale patch producers. Luckily it is not happening often, > but please let's take a point of view that is less patch-centric and more > human-centric.
having more build dependencies exposes you to the risk that more things will break when these build dependencies are upgraded. you should be aware of this as a package maintainer. It very much depends on the upstream if a software is developed with a specific set of specific versions in mind, or with standards in mind. consider this when filing an ITP. > When the first mass rebuilds with GCC and porting issues came to Debian, I was > very impressed. Years later it became a routine and I sometimes feel that I > am > pressed by a machine. There is not much apparent coordination with the other > distributions (not our derivatives) that also conduce such large screens. This is wrong. And I would like you to better research such claims before posting these as facts. > Especially for the GCC updates, it sometimes happens that if I do nothing, > Fedora will do the same screen, send patches Upstream and I will only have to > package a new upstream release as usual. Just imagine Fedora would have the same mindset ... > Why don't we start to share the workload ? > It seems to be a race condition with a lot of duplicated work. maybe, but that's how distros work. Fedora 21 builds with GCC 4.9 as the default. Find out about their local patches and which ones are forwarded upstream. we could wait with a new update for the toolchain and other components until every upstream has adopted to it. I think that would leave us a couple of years behind. And I already got answers like "why fix it, it builds in Debian". > Not > to mention when Upstream himself follows the evolution of the toolchain. Really? This is certainly not the majority, and even in Debian there are package maintainers who refuse to look after build failures until the new toolchain is the default. Looking at the results of the last test rebuild [1], there are about half of the build failures caused by Debian itself: - mismatches in symbols files. This is a long standing issue, and I think it is wrong to include every exposed C++ symbol in the symbols file. This is an issue to discuss with the dpkg maintainers, and then with packagers. There are 35 ftbfs caused by this. - usage of -Werror in debian/rules. If a package maintainer wants to be more holy than the pope, fine. But then he should be able to keep up with this spirit. Unfortunately there are a few upstreams as well setting -Werror as the default. This counts for 18 build failures. Afaics, all other build failures are caused by more strict C++ requirements, the porting guide might give you some hints [2]. Test failures may point to wrong code, either in the package or generated by the toolchain, however the former is the more likely. The perl issue is analysed, the mysql issue is not, and I honestly don't care about issues like the one for 0ad. So, from my point of leaf packages with a lot of build-dependencies should only be packaged in Debian iff both the upstream and the package maintainers can keep up with the amount of ongoing changes. Matthias [1] https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=ftbfs-gcc-4.9;users=debian-...@lists.debian.org [2] http://gcc.gnu.org/gcc-4.9/porting_to.html -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53697458.2050...@debian.org
