Bug#931003: Bug#931003: Removed package(s) from unstable
Thanks for your answer. That the Makefile, if present, should work is certainly a reasonable expectation, but as far as I can see, it isn't a license requirement. Note that the GPL also explicitly states that the program is provided without warranty of any kind (clause 11 in GPLv2, 15 in GPLv3), that is, if it doesn't build, you're on your own. Your quote says that the build scripts are part of the source code, but doesn't give them any special status: a bug in the Makefile is the same as a bug in a source file. So I'd say that if the Makefile is broken (and you say it "may or may not work" so that isn't even sure?), that's a bug, but not a license violation. I am not a lawyer, so this is just my opinion. Gerardo Il giorno gio 6 mag 2021 alle ore 10:47 Santiago Vila ha scritto: > > On Thu, May 06, 2021 at 09:50:43AM +0200, Gerardo Ballabio wrote: > > Santiago Vila wrote: > > > Among those packages there is even a GPL violation in gcc-8-cross, > > as the FTBFS problem happens because the Makefile is buggy (the GPL > > says packages must be distributed with a working Makefile). > > > > I was very surprised to read that. I just reread the GPL and could not > > find that condition. Could you please direct me to where it says so? > > As far as I understand, the GPL doesn't (and shouldn't) even require > > that packages have a Makefile at all. Indeed, I believe there are > > plenty of GPL'd software that use other build systems. > > And any requirement that software may not have bugs is of course > > unenforceable. > > Sorry, I didn't mean to say that packages should include a Makefile. > I meant that the Makefile, if present, should *work*. > > Quoting GPL-2: > > The source code for a work means [...] plus the scripts used to > control compilation and installation of the executable. > > This is a general reference to whatever procedure a program may have > to be built. If the program normally needs a Makefile, you have to > provide the Makefile, and I guess that it's reasonable to assume that > the Makefile should work, because the purpose is to enable anybody > who receives the source code to build the program. > > In the case of gcc-8-cross, there is a Makefile which may or may not > work: > > https://jenkins-1.reliable-builds.org/job/gcc-8-cross/ > > which I consider a GPL violation. > > Thanks.
Bug#931003: Bug#931003: Removed package(s) from unstable
On Thu, May 06, 2021 at 09:50:43AM +0200, Gerardo Ballabio wrote: > Santiago Vila wrote: > > Among those packages there is even a GPL violation in gcc-8-cross, > as the FTBFS problem happens because the Makefile is buggy (the GPL > says packages must be distributed with a working Makefile). > > I was very surprised to read that. I just reread the GPL and could not > find that condition. Could you please direct me to where it says so? > As far as I understand, the GPL doesn't (and shouldn't) even require > that packages have a Makefile at all. Indeed, I believe there are > plenty of GPL'd software that use other build systems. > And any requirement that software may not have bugs is of course > unenforceable. Sorry, I didn't mean to say that packages should include a Makefile. I meant that the Makefile, if present, should *work*. Quoting GPL-2: The source code for a work means [...] plus the scripts used to control compilation and installation of the executable. This is a general reference to whatever procedure a program may have to be built. If the program normally needs a Makefile, you have to provide the Makefile, and I guess that it's reasonable to assume that the Makefile should work, because the purpose is to enable anybody who receives the source code to build the program. In the case of gcc-8-cross, there is a Makefile which may or may not work: https://jenkins-1.reliable-builds.org/job/gcc-8-cross/ which I consider a GPL violation. Thanks.
Bug#931003: Bug#931003: Removed package(s) from unstable
Santiago Vila wrote: > Among those packages there is even a GPL violation in gcc-8-cross, as the FTBFS problem happens because the Makefile is buggy (the GPL says packages must be distributed with a working Makefile). I was very surprised to read that. I just reread the GPL and could not find that condition. Could you please direct me to where it says so? As far as I understand, the GPL doesn't (and shouldn't) even require that packages have a Makefile at all. Indeed, I believe there are plenty of GPL'd software that use other build systems. And any requirement that software may not have bugs is of course unenforceable. Gerardo
Bug#931003: Bug#931003: Removed package(s) from unstable
On Tue, May 04, 2021 at 11:48:09AM +0100, peter green wrote: > > This was automatically closed by ftpmaster because the package was > > removed from unstable, but this still does not fix the FTBFS problem > > in stable. > > Unfortunately I don't think a proper fix will be forthcoming, upstream > has abandoned the crate in question. It does not need to be a perfect fix. It is enough that dpkg-buildpackage exits with status 0. If the tests are no longer valid, disabling them should be much better than nothing, because packages in stable must build in stable. > > There are already 74 packages which FTBFS in stable (by my count), > > Do you have a list? Last time I tried this is what I found: https://people.debian.org/~sanvila/ftbfs-in-buster/ Among those packages there is even a GPL violation in gcc-8-cross, as the FTBFS problem happens because the Makefile is buggy (the GPL says packages must be distributed with a working Makefile). > Are the stable release managers open to patches fixing such issues? In my experience, usually yes, because packages in stable must build in stable. Thanks.
Bug#931003: Bug#931003: Removed package(s) from unstable
This was automatically closed by ftpmaster because the package was removed from unstable, but this still does not fix the FTBFS problem in stable. Unfortunately I don't think a proper fix will be forthcoming, upstream has abandoned the crate in question. Afaict the only purpose this package serves in buster is to satisfy the dependencies of "librust-encoding-rs+simd-dev" and "librust-encoding-rs+simd-accel-dev" neither of which have any reverse dependencies. it looks like "librust-encoding-rs+simd-dev" and "librust-encoding-rs+simd-accel-dev" were dropped in unstable by the rust-encoding-rs upload 0.8.15-2 just prior to the buster release, but these changes did not make it into buster. There are already 74 packages which FTBFS in stable (by my count), Do you have a list? Are the stable release managers open to patches fixing such issues? (note that FTBFS indications on reproducible builds are IME not reliable, I have seen plenty of FTBFS on there that look like either resource exhaustion or quirks of the particular builders they are using, they also report FTBFS even on architectures where a package has no binaries in Debian) it would be much better if every mantainer cared about their own packages. For the most part maintainers care for their packages in testing/unstable, then when a stable release happens things get frozen. So normally packages that built successfully in test rebuilds during the freeze should continue to build successfully throughout the releases stable lifecycle. Unfortunately firefox/thunderbird support lifecycles combined with it being one of the most security-sensitive packages in Debian requires periodic updates to new firefox/thunderbird release series even in stable releases, that in turn has lead to new major versions of rustc being uploaded even during freezes and even to stable releases. The rust team has been struggling for lack of manpower, particularly experienced manpower for some time. I've been trying to help where I can but I'm still a relative newcomer to rust (though I understand the rust packaging system a lot better than I did 6 months ago). I do wonder if it would make sense to use seperate package names for the rust backports done to support firefox/thunderbird updates in stable so the rest of the rust ecosystem is not affected. ccing the release team and the mozilla maintainers to see if they have any input on this.
