Processed: affects 903656
Processing commands for cont...@bugs.debian.org: > affects 903656 src:publicsuffix Bug #903656 [release.debian.org] stretch-pu: package publicsuffix/20180523.2326-0+deb9u1 Added indication that 903656 affects src:publicsuffix > thanks Stopping processing here. Please contact me if you need assistance. -- 903656: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=903656 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#903671: autopkgtest excuses in tracker should also link to the packages
On Thu, Jul 12, 2018 at 09:11:19PM +0200, Paul Gevers wrote: > Hi Adrian, Hi Paul, > On 12-07-18 20:48, Adrian Bunk wrote: > > Example: > > https://tracker.debian.org/pkg/python3-defaults > > > > Lines like: > > autopkgtest for aodh/6.0.0-7: amd64: Regression ♻ > > > > The "amd64" and "Regression" are already links (to ci.debian.org). > > > > It would be useful if the package name "aodh" would also become > > a link pointing at https://tracker.debian.org/pkg/aodh since > > this is the central place for finding related information like > > bugs or buildd logs. > > I like the idea, but there are more consumers of the excuses. So what > makes tracker special? The links for ci.debian.net (Not ci.debian.org) > are justified because that is where the tests run. >... what makes tracker special is that it is the place for getting all information about a package on one page. > Paul cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Bug#903671: autopkgtest excuses in tracker should also link to the packages
Hi Adrian, On 12-07-18 20:48, Adrian Bunk wrote: > Example: > https://tracker.debian.org/pkg/python3-defaults > > Lines like: > autopkgtest for aodh/6.0.0-7: amd64: Regression ♻ > > The "amd64" and "Regression" are already links (to ci.debian.org). > > It would be useful if the package name "aodh" would also become > a link pointing at https://tracker.debian.org/pkg/aodh since > this is the central place for finding related information like > bugs or buildd logs. I like the idea, but there are more consumers of the excuses. So what makes tracker special? The links for ci.debian.net (Not ci.debian.org) are justified because that is where the tests run. RT, what do you think? Paul signature.asc Description: OpenPGP digital signature
Bug#903671: autopkgtest excuses in tracker should also link to the packages
Package: release.debian.org Severity: wishlist User: release.debian@packages.debian.org Usertags: britney Example: https://tracker.debian.org/pkg/python3-defaults Lines like: autopkgtest for aodh/6.0.0-7: amd64: Regression ♻ The "amd64" and "Regression" are already links (to ci.debian.org). It would be useful if the package name "aodh" would also become a link pointing at https://tracker.debian.org/pkg/aodh since this is the central place for finding related information like bugs or buildd logs.
Bug#903656: stretch-pu: package publicsuffix/20180523.2326-0+deb9u1
On Thu 2018-07-12 11:25:58 -0400, d...@fifthhorseman.net wrote: > Package: release.debian.org > Severity: normal > Tags: stretch > User: release.debian@packages.debian.org > Usertags: pu > Control: affects -1 publicsuffix > > Please consider an update to publicsuffix in debian stretch. > > This package reflects the state of the network, and keeping it current > is useful for all the packages that depend on it. > > The debdiff from the previous version in stretch is not attached because it > was being rejected as spam. > > This proposed release is also available at the > "publicsuffix_debian/20180523.2326-0+deb9u1" tag on the "debian/stretch" > branch at > the git repo for publicsuffix packaging: > > https://salsa.debian.org/debian/publicsuffix > > Please followup on this ticket to confirm whether I should upload this > revision to stretch. I've tried multiple times now to attach the debdiff to this bug report, and it continues to be rejected as spam by bugs.debian.org with this message: <903...@bugs.debian.org>: host buxtehude.debian.org[209.87.16.39] said: 550 malware detected: Sanesecurity.Jurlbl.db3039.UNOFFICIAL: message rejected (in reply to end of DATA command) Since that's failing, i'll just post it publicly on the web. You can retrieve the debdiff at: https://dkg.fifthhorseman.net/publicsuffix_20180218.2049-0+deb9u1_20180523.2326-0+deb9u1.debdiff.gz It has a sha256sum of: 8cbafa1ef6fac079f3a32ba88c5fd1bb4bb43335feb4ff3e16fdfbd3df7a069f Apologies for the inconvenience. --dkg signature.asc Description: PGP signature
Processed: stretch-pu: package publicsuffix/20180523.2326-0+deb9u1
Processing control commands: > affects -1 publicsuffix Bug #903656 [release.debian.org] stretch-pu: package publicsuffix/20180523.2326-0+deb9u1 Added indication that 903656 affects publicsuffix -- 903656: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=903656 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#903656: stretch-pu: package publicsuffix/20180523.2326-0+deb9u1
Package: release.debian.org Severity: normal Tags: stretch User: release.debian@packages.debian.org Usertags: pu Control: affects -1 publicsuffix Please consider an update to publicsuffix in debian stretch. This package reflects the state of the network, and keeping it current is useful for all the packages that depend on it. The debdiff from the previous version in stretch is not attached because it was being rejected as spam. This proposed release is also available at the "publicsuffix_debian/20180523.2326-0+deb9u1" tag on the "debian/stretch" branch at the git repo for publicsuffix packaging: https://salsa.debian.org/debian/publicsuffix Please followup on this ticket to confirm whether I should upload this revision to stretch.
Processed: block 903630 with 903636
Processing commands for cont...@bugs.debian.org: > block 903630 with 903636 Bug #903630 [ejabberd] erlang-p1-xmpp 1.2.2 breaks ejabberd 18.04 903630 was not blocked by any bugs. 903630 was not blocking any bugs. Added blocking bug(s) of 903630: 903636 > thanks Stopping processing here. Please contact me if you need assistance. -- 903630: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=903630 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#903636: RM: ejabberd-contrib/0.2018.04.28~dfsg0-2
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: rm Due to #903028, ejabberd-contrib is currently not compatible with ejabberd anymore and it is unclear if/when that will be fixed. As this is currently blocking ejabberd's transition to testing I would like to have ejabberd-contrib removed from their now and not wait until autoremoval kicks in. Regards, Philipp
NEW changes in stable-new
Processing changes file: debian-installer-netboot-images_20170615+deb9u4_all.changes ACCEPT
Bug#901015: transition: protobuf
On Thursday 12 July 2018 01:57 PM, László Böszörményi (GCS) wrote: > How quick do you need to solve this GitLab update? I guess, quick. We are not able to backport some complex security fixes to gitlab 8.13 in stretch. Security team wants to remove gitlab 8.13 from stable and I'd like to provide an update path via stretch-backports before it is removed. So the sooner we can provide, the better :) signature.asc Description: OpenPGP digital signature
Bug#901015: transition: protobuf
[Removed the Security Team Cc, they were relevant for backporting protobuf to Stretch, not for updating it in Sid.] On Thu, Jul 12, 2018 at 10:14 AM Pirate Praveen wrote: > On Fri, 6 Jul 2018 10:55:03 +0200 > =?UTF-8?B?TMOhc3psw7MgQsO2c3rDtnJtw6lueWkgKEdDUyk=?= wrote: > > The most problematic point is the protobuf-c dependency package. It > > was developed (and packaged) by one of us (an other DD), Robert S. > > Edmonds. It is the most complete C language implementation of Protocol > > Buffers. While it has a newer upstream release in Git than the > > packaged version, it's still not compatible with protobuf 3.6.0.1 > > which is in experimental. [...] > What do you think about providing protobuf3.0 in parallel to updating > protobuf to 3.6? That way we can move ahead with gitlab and provide more > time for either updating protobuf-c or porting packages to protobluff. > We can drop protobuf3.0 when protobuf-c issue is resolved. Actually I would like to investigate every possibility. 1) Check the list of protobuf-c main contributors[1] if any of them can / want to continue its development. 2) Try to update protobuf-c for version 3.6 of protobuf, but I can't be its upstream developer on the long run. 3) Patch protobuf-c to use the implementation of scoped_array in Boost. 4) At least check the required porting needs of dependencies to protobluff. Ask their maintainers if they want / can do the porting. Maybe they know other alternatives. If these fail and RMs ACK to carry two versions of protobuf then of course, do it. Emilio? How quick do you need to solve this GitLab update? I guess, quick. Cheers, Laszlo/GCS [1] https://github.com/protobuf-c/protobuf-c/graphs/contributors
Bug#901015: transition: protobuf
On Fri, 6 Jul 2018 10:55:03 +0200 =?UTF-8?B?TMOhc3psw7MgQsO2c3rDtnJtw6lueWkgKEdDUyk=?= wrote: > The most problematic point is the protobuf-c dependency package. It > was developed (and packaged) by one of us (an other DD), Robert S. > Edmonds. It is the most complete C language implementation of Protocol > Buffers. While it has a newer upstream release in Git than the > packaged version, it's still not compatible with protobuf 3.6.0.1 > which is in experimental. > Main reason is that scoped_array (a class template to store pointers > to a dynamically allocated array) is removed from newer protobuf > releases, still protobuf-c still would like to use it. While Boost has > a similar (same?) scoped_array implementation since its 1.49 version, > I highly doubt protobuf-c should be altered to use that. As I can't > reach Robert for about nine months and I don't see any life sign from > him either, protobuf-c definitely needs a new upstream maintainer with > internal protobuf knowledge. > > Of course, several other C implementation of protobuf exist. > PBC[1] seems to be dead for more than a year now and does _not_ have a > code generator. > Nanopb[2] is a trim down version for 32 bits and microcontrollers only. > protobluff[3] seems to be the most viable alternative. It's modular, > seems to be in development and integrates with the upstream code > generator. > None of these are packaged as I know. > > But why is all the fuzz you may ask. The protobuf-c library is used by > several big / important projects. Like Knot DNS (a high-performance > DNS server, knot), CRIU (Checkpoint/Restore In Userspace, criu) and > PostGIS (geographic objects support for PostgreSQL, postgis) - > maintained by people like Ondřej Surý and Carnil (Salvatore > Bonaccorso), ones that I bow before them for their knowledge. These > packages and others would break with starting the protobuf transition > without protobuf-c being updated. Porting these to protobluff might be > an even bigger task. László, What do you think about providing protobuf3.0 in parallel to updating protobuf to 3.6? That way we can move ahead with gitlab and provide more time for either updating protobuf-c or porting packages to protobluff. We can drop protobuf3.0 when protobuf-c issue is resolved. Thanks Praveen signature.asc Description: OpenPGP digital signature
Processed: block 901015 with 900621
Processing commands for cont...@bugs.debian.org: > block 901015 with 900621 Bug #901015 [release.debian.org] transition: protobuf 901015 was not blocked by any bugs. 901015 was blocking: 900522 Added blocking bug(s) of 901015: 900621 > thanks Stopping processing here. Please contact me if you need assistance. -- 901015: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=901015 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
