Re: Refreshing mysql-connector-java
Hi Salvatore, On 04/06/2020 20:41, Salvatore Bonaccorso wrote: > On Mon, May 25, 2020 at 07:47:56PM +0200, Moritz Mühlenhoff wrote: >> On Mon, May 25, 2020 at 10:22:50AM +0200, Sylvain Beucler wrote: >>> Hi Security Team, >>> >>> What is your view on updating mysql-connector-java 5.1.42->5.1.49 for >>> Stretch? >> >> We can update to 5.1.49, yes. We've had to update it to new 5.1.x >> releases in the past and I don't remember any issues. The fact >> that there's zero information totally sucks, but there's nothing >> we can do either (apart from removing it as we did a year ago). >> >> Looking at the debdiff from >> https://www.beuc.net/tmp/debian-lts/mysql-connector-java/ >> the remaining change would be to change the version number to >> 5.1.49-1~deb9u1 and the targets distro to stretch-security. > > I'm a bit late to the party, but just want to give my 2 cents on the > versioning scheme. Agreed here to not use the really-something > variant. usually I think this is usefull when you have rebased > soemthing to a *higher* version, but need to rollback. Example: > > graphicsmagick/1.4+really1.3.35+hg16296-1 > > or > > lxc/1:3.1.0+really3.0.4-3 > > (other examples exists) OK. I had used +really for the ELTS package to test what I should do in the event that there would be objections or major delays in bumping to 5.1.49 in other suites, like e.g.: https://security-tracker.debian.org/tracker/source-package/tomcat7 7.0.56-3+really7.0.100-1+deb8u1 < 7.0.75-1 > So I think the proper version would be either what Moritz said, > 5.1.49-1~deb9u1 or 5.1.49-*0*+deb9u1. > > For practical reasons there is no difference, both work. usually it > just more points out what the upload does. 5.1.49-1~deb9u1 would give > more a hint like "this update is rebuild of 5.1.49-1 for stretch, > possibly minus/plus some additional changes". 5.1.49-0+deb9u1 (please > not the 0, not -1+deb9u1) means more something like "we imported > upstream 5.1.49 on top of the current packaging plus/minus probably > some additional changes". > > Personally I would go with 5.1.49-0+deb9u1 due to the meaning, there > are other source packages which follow this schema. Other do with the > ~debXuY variant. For both in any case we have 5.1.49-0+deb9u1 <= > 5.1.49-1 and 5.1.49-1~deb9u1 <= 5.1.49-1. > > And as usual there are as well excpetions. > > Anyway, I would suggest to not use the +really syntax. Certainly. I recently prepared a package with 5.1.49-1~deb9u1 (and I'm currently doing further testing) but I'll switch to 5.1.49-0+deb9u1 since there is no 5.1.49-1. Cheers! Sylvain
Re: Test failures in cups
Le jeudi, 4 juin 2020, 13.26:16 h CEST Utkarsh Gupta a écrit : > Hi again, > > On Thu, Jun 4, 2020 at 4:20 PM Utkarsh Gupta wrote: > > Your last upload of cups to oldoldstable, version 1.7.5-11+deb8u7, had > > one test failing: > > ``` > > httpAddrGetList(debian): FAIL > > ``` > > Was it supposed to fail? Is it OK? > > I think it's something with my schroot or something else. > Because the latest version (in Sid) also fails the same way for me but > passes CI. > So I think it has nothing to do with your previous upload. CUPS has a weird (= "which I haven't managed to understand properly") way of handling "localhost". In my (CUPS maintainer) experience, it has only ever properly built (with tests passing) under sbuild, never under other environments (notably, tests don't pass under pbuilder). I have tried to file an FTBR bug as #916433. In other words, I think CUPS does something not correctly around handling "localhost", but my C-fu is not sufficient to pinpoint what the problem precisely is, nor where it could be addressed. Help welcome! Regards, OdyX signature.asc Description: This is a digitally signed message part.
Re: Refreshing mysql-connector-java
Hi Security Team, On 05/06/2020 09:23, Sylvain Beucler wrote: > On 04/06/2020 20:41, Salvatore Bonaccorso wrote: >> On Mon, May 25, 2020 at 07:47:56PM +0200, Moritz Mühlenhoff wrote: >>> On Mon, May 25, 2020 at 10:22:50AM +0200, Sylvain Beucler wrote: Hi Security Team, What is your view on updating mysql-connector-java 5.1.42->5.1.49 for Stretch? >>> >>> We can update to 5.1.49, yes. We've had to update it to new 5.1.x >>> releases in the past and I don't remember any issues. The fact >>> that there's zero information totally sucks, but there's nothing >>> we can do either (apart from removing it as we did a year ago). >>> >>> Looking at the debdiff from >>> https://www.beuc.net/tmp/debian-lts/mysql-connector-java/ >>> the remaining change would be to change the version number to >>> 5.1.49-1~deb9u1 and the targets distro to stretch-security. >> >> I'm a bit late to the party, but just want to give my 2 cents on the >> versioning scheme. Agreed here to not use the really-something >> variant. usually I think this is usefull when you have rebased >> soemthing to a *higher* version, but need to rollback. Example: >> >> graphicsmagick/1.4+really1.3.35+hg16296-1 >> >> or >> >> lxc/1:3.1.0+really3.0.4-3 >> >> (other examples exists) > > OK. I had used +really for the ELTS package to test what I should do in > the event that there would be objections or major delays in bumping to > 5.1.49 in other suites, like e.g.: > https://security-tracker.debian.org/tracker/source-package/tomcat7 > 7.0.56-3+really7.0.100-1+deb8u1 < 7.0.75-1 > > >> So I think the proper version would be either what Moritz said, >> 5.1.49-1~deb9u1 or 5.1.49-*0*+deb9u1. >> >> For practical reasons there is no difference, both work. usually it >> just more points out what the upload does. 5.1.49-1~deb9u1 would give >> more a hint like "this update is rebuild of 5.1.49-1 for stretch, >> possibly minus/plus some additional changes". 5.1.49-0+deb9u1 (please >> not the 0, not -1+deb9u1) means more something like "we imported >> upstream 5.1.49 on top of the current packaging plus/minus probably >> some additional changes". >> >> Personally I would go with 5.1.49-0+deb9u1 due to the meaning, there >> are other source packages which follow this schema. Other do with the >> ~debXuY variant. For both in any case we have 5.1.49-0+deb9u1 <= >> 5.1.49-1 and 5.1.49-1~deb9u1 <= 5.1.49-1. >> >> And as usual there are as well excpetions. >> >> Anyway, I would suggest to not use the +really syntax. > > Certainly. I recently prepared a package with 5.1.49-1~deb9u1 (and I'm > currently doing further testing) but I'll switch to 5.1.49-0+deb9u1 > since there is no 5.1.49-1. I finished testing and I prepared the upload accordingly: https://www.beuc.net/tmp/debian-lts/mysql-connector-java/mysql-connector-java_5.1.49-0+deb9u1_amd64.changes https://www.beuc.net/tmp/debian-lts/mysql-connector-java/debdiff-stretch.txt Version scheme is changed, suite is stretch-security, and I made a minor change to debian/watch to track 5.x (not 8.x). Do you approve for upload? Cheers! Sylvain
Re: Test failures in cups
Hiya, On Fri, Jun 5, 2020 at 5:40 PM Didier 'OdyX' Raboud wrote: > > I think it's something with my schroot or something else. > > Because the latest version (in Sid) also fails the same way for me but > > passes CI. > > So I think it has nothing to do with your previous upload. > > CUPS has a weird (= "which I haven't managed to understand properly") way of > handling "localhost". In my (CUPS maintainer) experience, it has only ever > properly built (with tests passing) under sbuild, never under other > environments (notably, tests don't pass under pbuilder). I have tried to file > an FTBR bug as #916433. Aye, but weirdly, it's not even building in sbuild for me :/ Every version fails with the same test failure for me. If it builds for you/anyone, could you/someone sponsor my upload? Best, Utkarsh
Re: Bug#931376: debian-security-support: mention nodejs is not for untrusted content
Hi, On 20/02/20 11:14 pm, Holger Levsen wrote: > On Thu, Feb 20, 2020 at 06:08:52PM +0100, Emilio Pozuelo Monfort wrote: >> So we should add it to security-support-ended for those releases, and >> let it be supported in buster. > > done in > https://salsa.debian.org/debian/debian-security-support/commit/c9b3de34947bc13cad9f18a53d0fb7b512bff0e1 Shouldn't there be a follow up announcement on debian-lts-announce mailing list. --abhijith
Re: Bug#931376: debian-security-support: mention nodejs is not for untrusted content
Hi, On 05/06/2020 15:03, Abhijith PA wrote: > On 20/02/20 11:14 pm, Holger Levsen wrote: >> On Thu, Feb 20, 2020 at 06:08:52PM +0100, Emilio Pozuelo Monfort wrote: >>> So we should add it to security-support-ended for those releases, and >>> let it be supported in buster. >> >> done in >> https://salsa.debian.org/debian/debian-security-support/commit/c9b3de34947bc13cad9f18a53d0fb7b512bff0e1 > > Shouldn't there be a follow up announcement on debian-lts-announce > mailing list. I don't think so because it's been documented in the release notes since the beginning: https://www.debian.org/releases/jessie/amd64/release-notes/ch-information.en.html#libv8 Cheers! Sylvain
Re: Bug#931376: debian-security-support: mention nodejs is not for untrusted content
On 05/06/20 6:39 pm, Sylvain Beucler wrote: > Hi, > > On 05/06/2020 15:03, Abhijith PA wrote: >> On 20/02/20 11:14 pm, Holger Levsen wrote: >>> On Thu, Feb 20, 2020 at 06:08:52PM +0100, Emilio Pozuelo Monfort wrote: So we should add it to security-support-ended for those releases, and let it be supported in buster. >>> >>> done in >>> https://salsa.debian.org/debian/debian-security-support/commit/c9b3de34947bc13cad9f18a53d0fb7b512bff0e1 >> >> Shouldn't there be a follow up announcement on debian-lts-announce >> mailing list. > > I don't think so because it's been documented in the release notes since > the beginning: > https://www.debian.org/releases/jessie/amd64/release-notes/ch-information.en.html#libv8 Thank you for sharing this. --abhijith
