Bug#949227: fixed in python-pysaml2 4.5.0-7
On 2/19/20 2:02 PM, Santiago Vila wrote: > On Wed, Feb 19, 2020 at 10:10:27AM +0100, Thomas Goirand wrote: > >> Thanks, but I don't need you to micro-manage the bugs in the BTS for me. > > I'm not really micro-managing anything for you. I'm just making sure > that the information in the BTS is correct. Not necessarily for you, > but for anybody working on QA issues (which may be anybody, not just you). > >> FYI, the package has been uploaded to security-master, and will soon >> reach the security repositories, which is why I didn't care much about >> this bug being closed (and I prefer it to be closed, so it isn't "on my >> way" when reviewing the team's bug list). > > Glad to know a fixed version has been uploaded to security, but I'm > sure there must be already some BTS tag for that (for example, "pending" > or "fixed"), which will help you to put bugs "outside your way" > without incorrectly closing them. > > There is a reason why we use the changelog as the preferred method to > close bugs: We do it to ensure that the bug is only closed when a > fixed version is actually available in the archive, so that bugs are > not closed in error. > > This is valid for unstable, but also for stable and for security. > > So, if you did a security upload and wrote a Closes statement in the > changelog, then the thing you should not care much is really about it > being open. > > Thanks. Santiago, Your lecturing is kind of frustrating. What you wrote above, I know it, and you are right and accurate. We simply have a difference in how we see things. Let me attempt to explain. You view the BTS as the state of things for packages. I view it as a helper for my maintainer's job. This is the source of many of the exchanges (and sometimes, disagreement) we had. I hope these words will help you understand that both yours and my point of view are valid, but very different. Though like it or not, in Debian, it is up to the maintainer to decide how to manage his bugs. I will not play BTS ping-pong (we both have better things to do), though I still would have prefer this bug to not be "on my way" when I review things I have to do on my packages, because at this point, I am considering my work on this specific issue as "done". Adding a pending tag could do, but that's more work, and precious time that I very much prefer wasting arguing with you :) (just joking...) Cheers, Thomas Goirand (zigo) P.S: Thanks for your work in Debian, and maintaining key packages for so long...
Bug#949227: fixed in python-pysaml2 4.5.0-7
On Wed, Feb 19, 2020 at 10:10:27AM +0100, Thomas Goirand wrote: > Thanks, but I don't need you to micro-manage the bugs in the BTS for me. I'm not really micro-managing anything for you. I'm just making sure that the information in the BTS is correct. Not necessarily for you, but for anybody working on QA issues (which may be anybody, not just you). > FYI, the package has been uploaded to security-master, and will soon > reach the security repositories, which is why I didn't care much about > this bug being closed (and I prefer it to be closed, so it isn't "on my > way" when reviewing the team's bug list). Glad to know a fixed version has been uploaded to security, but I'm sure there must be already some BTS tag for that (for example, "pending" or "fixed"), which will help you to put bugs "outside your way" without incorrectly closing them. There is a reason why we use the changelog as the preferred method to close bugs: We do it to ensure that the bug is only closed when a fixed version is actually available in the archive, so that bugs are not closed in error. This is valid for unstable, but also for stable and for security. So, if you did a security upload and wrote a Closes statement in the changelog, then the thing you should not care much is really about it being open. Thanks.
Bug#949227: fixed in python-pysaml2 4.5.0-7
On 2/18/20 1:26 PM, Santiago Vila wrote: > reopen 949227 > found 949227 4.5.0-4 > fixed 949227 4.5.0-7 > retitle 949227 python-pysaml2: FTBFS in buster because of expired certificate > thanks > > Reopening because packages in stable *must* build in stable. > In fact, it fails right now, without waiting to 2020-11-28. > > Error message says something like this: > > ToOld: Metadata not valid anymore, it's only valid until 2020-02-10T09:59:21Z > > Full log available here: > > https://tests.reproducible-builds.org/debian/rbuild/buster/amd64/python-pysaml2_4.5.0-4.rbuild.log.gz > > Thanks. > Santiago, Thanks, but I don't need you to micro-manage the bugs in the BTS for me. FYI, the package has been uploaded to security-master, and will soon reach the security repositories, which is why I didn't care much about this bug being closed (and I prefer it to be closed, so it isn't "on my way" when reviewing the team's bug list). Cheers, Thomas Goirand (zigo)
Bug#949227: fixed in python-pysaml2 4.5.0-7
reopen 949227 found 949227 4.5.0-4 fixed 949227 4.5.0-7 retitle 949227 python-pysaml2: FTBFS in buster because of expired certificate thanks Reopening because packages in stable *must* build in stable. In fact, it fails right now, without waiting to 2020-11-28. Error message says something like this: ToOld: Metadata not valid anymore, it's only valid until 2020-02-10T09:59:21Z Full log available here: https://tests.reproducible-builds.org/debian/rbuild/buster/amd64/python-pysaml2_4.5.0-4.rbuild.log.gz Thanks.
