Quoting gregor herrmann (2016-08-01 20:51:56) > On Fri, 29 Jul 2016 09:54:49 +0200, Lucas Nussbaum wrote: > > > Source: license-reconcile > > Version: 0.11 > > Severity: serious > > Tags: stretch sid > > User: debian...@lists.debian.org > > Usertags: qa-ftbfs-20160728 qa-ftbfs > > Justification: FTBFS on amd64 > > > > Hi, > > > > During a rebuild of all packages in sid, your package failed to build on > > amd64. > > > > > # Failed test at t/09-nolicense.t line 13. > > > # Compared $data->[0]{"copyright"}[0] > > > # got : 'Copyright: 1992-1993 The Regents of the University of > > > California. All rights reserved.' > > > # expect : 'Copyright: 1992, 1993 The Regents of the University of > > > California. All rights reserved' > > > # Looks like you failed 1 test of 2. > > > t/09-nolicense.t .......... > > > Smells like that's caused by changes in licensecheck which now uses > String::Copyright which "serializes in normalized format".
That's what I smell too. > In general I think that license-reconcile needs an active maintainer, > in cooperation with the moving underlying parts, or it needs to be > removed. Doing emergency cleanups on each new failure is not > sustainable. Agreed. In my defense (I have taken over as upstream of licensecheck and am the author of String::Copyright), the "old" licensecheck had no guarantee about its output format and did not even document every change to it, which I believe has changed going forward. Progress of licensecheck is intended to generally not break existing use (e.g. for its commandline options) but will not promise to guarantee identical output - especially not where change is considered an improvement like in this specific case of normalizing lists of years as the (in some cases only slightly) more compact ranges of years. String::Copyright and/or licensecheck now by default normalizes to ranges when possible. They might later grow an option to instead normalize to lists of years (i.e. expand to _avoid_ any year ranges, as I believe was an older GNU recomendation). If someone feels the need also for a "leave as-is" option then please file a bugreport about that against either of those separate packages, but prepare to dig up some strong arguments, as I do not expect to easily be convinced that there is any benefit in that. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private
signature.asc
Description: signature