© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
1b1ed1a
(Get the code!)
There seems to be a ton of confusion here. I have commented to various people on IRC as they have asked me. But the messages don't seem to have been received. I'll try and summarize my opinion here.
0. I asked for a link to document upstream's rejection of this patch in comment 33 and on IRC[1].
1. It seems inappropriate for an SRU affecting users to be blocked on an unrelated FTBFS fix for the development release, such as in this case where the build for the actual fix in the development release has got caught up with the transition to gcc-7. I would not block the progress of the SRU on this.
2. However, if the fixing of the development release is trivial, then I'd expect it to be done to minimise risk to users in the future, in the spirit of the SRU policy. In other words, if it takes just half an hour of developer time, can we just do it? If what I think is the most appropriate fix for the development release turns out to be non-trivial, then sure, we can proceed with the SRU without it.
3. To fix this in the development release, I suggested a minimal distro patch that stops warning->error for non-bugs is OK to fix this and suggested that you could look at a recent and similar fix in squid3 for an example[2].
4. In response to the debdiff in comment 38, I said that I didn't understand why you didn't follow my previous suggestion, and that the approach there is not suitable for the development release since it would hold back the gcc-7 transition rather than progressing it[3].
[1] https:/
[2] https:/
[3] https:/
To make progress, in the first instance, please work on 3. If it turns out to be non-trivial, please talk to me again. I'd also appreciate you resolving 0 but I don't think that's a blocker right now.