control: merge -1 846543 On 2016-12-11 09:54:42 [+0100], Michael Meskes wrote:
> What are you trying to do here? Reopen 828267 and merge with itself? > There is no other bug mentioned. What do I miss? Yeah. Not very smart. I intended to merge it with 846543. > > from the change [0] you use say that a compatible API is used but the > > CFLAG change makes no sense. This is probably a miss understanding. > > Care to explain? The CFLAG change did make the package compile, install > and run, so why reopen the bug? The bug was created and it was mentioned that this package needs changes in order to get it compiled against the new openssl ABI which is in experimental. Your upload of the "fixed" package was performed on 2016-10-30 and was built against openssl 1.0.2. So even if you would have done nothing, your package would been built successfully *but* against a 1.0.2. The test should have been done against the version in experimental. On 2016-11-01 openssl 1.1.0 was uploaded to unstable. From this point in time your package would have fail to build. So I *think* the change in the CFLAGS is a nop. > > You > > have two choices: > > ... > > Says who? Again, without any explanation as to why, I don't see any > reason to act. So the bug was created because the package did not compile against openssl 1.1.0 and now #846543 was created which mostly a dupe of this one. That means you have a valid RC bug which should be solved in order to get this package ready for the release and I mentioned two options people are doing. Most of what I wrote is from the transition bug #827061. The libssl1.0-dev is provided by openssl 1.0.2 and is intended to provide the 1.0.2 API for package which can't be fixed in time for release. > Michael Sebastian