Control: severity -1 important (see below why...) In data lunedì 20 novembre 2017 20:05:20 CET, Emilio Pozuelo Monfort ha scritto: > Control: severity -1 serious > > On Wed, 06 Sep 2017 21:34:47 +0200 Pino Toscano <pino@debian.org> wrote: > > Hi, > > > > In data domenica 27 agosto 2017 16:01:25 CEST, Sylvestre Ledru ha scritto: > > > Source: kdevelop > > > Severity: normal > > > > > > Hello, > > > > > > Currently, we have 6 versions of the llvm toolchain in the archive. > > > I would like to move to 3 versions (4.0, 5.0 and snapshot, aka 6.0) > > > > > > Could you please update your package to use 4.0 (or, better, 5.0 which will be released very > > > soon)? > > > > Sure, but only after the versions available build and work at least on > > all the release architectures. So far, llvm 3.9 is still affected by > > #866354, since it did not build fine again since then -- this is > > holding kdevelop in unstable for more than 2 months, and I really would > > like to get it into testing. > > > > I see that each of the llvm sources has various bugs, FTBFSes, cmake > > issues, and so forth... as a suggestion from a bystander, what about > > focusing on at most 3 versions of llvm in the archive, instead of > > upload every version available (and then have to cleanup llvm users > > periodically, like with bugs like this)? > > > > > I will update the severity of this bug at the end of September > > > > Doing that with the current state of llvm versions would be a bad idea. > > It should be fine now with 4.0. Would be good if this could move to either > unversioned llvm/clang (which defaults to 4.0 now) or to versioned 4.0. Bumping > to serious as we want to remove 3.8 soon to reduce the high number of llvm > versions that we currently ship. IMHO, if the goal would really be getting rid of old llvm versions in the archive, then (as I wrote above) the llvm maintainers ought to a) fix the latest stable (= 5.0) b) switch llvm-defaults to the above llvm got versioned symbols, so loading two llvm versions in the same process (hello, mesa), although it is ugly. This should allow kdevelop to switch back to llvm-defaults, even if llvm maintainers should care a bit more about it, instead of almost letting it rot... Anyway, I just lowered the severity of this bug to important, so kdevelop 5.2 can migrate to testing. Yes, it is an important update (merged kdevplatform, so the separate source can be dropped), so I really it to reach testing. Because of another issue in the past, related to llvm (#866354), kdevelop 5.1.x was stuck in unstable for basically 2 months. I don't want llvm to get in the way of kdevelop, once again. -- Pino Toscano
Attachment:
signature.asc
Description: This is a digitally signed message part.