Bug#825808: marked as done (nmu: some ocaml rdeps)
Your message dated Wed, 1 Jun 2016 09:55:28 +0200 with message-id <574e94f0.5000...@debian.org> and subject line Re: Bug#825808: nmu: some ocaml rdeps has caused the Debian Bug report #825808, regarding nmu: some ocaml rdeps to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 825808: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=825808 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu nmu hol-light_20131026-1 . ANY . unstable . -m "Rebuild against current camlp5." nmu ledit_2.03-4 . ANY . unstable . -m "Rebuild against current camlp5." nmu utop_1.19.2-1 . ANY -amd64 -powerpc -s390x . unstable . -m "Rebuild against current liblambda-term-ocaml." nmu opam_1.2.2-5 . s390x . unstable . -m "Rebuild against current libdose3-ocaml." Looks like these have been missed after the last round of ocaml updates. Andreas --- End Message --- --- Begin Message --- On 31/05/2016 17:05, Emilio Pozuelo Monfort wrote: nmu hol-light_20131026-1 . ANY . unstable . -m "Rebuild against current camlp5." nmu ledit_2.03-4 . ANY . unstable . -m "Rebuild against current camlp5." nmu utop_1.19.2-1 . ANY -amd64 -powerpc -s390x . unstable . -m "Rebuild against current liblambda-term-ocaml." nmu opam_1.2.2-5 . s390x . unstable . -m "Rebuild against current libdose3-ocaml." Looks like these have been missed after the last round of ocaml updates. Cc'ing Mehdi and Stéphane, who normally handle ocaml binnmus. Done. Cheers, -- Stéphane--- End Message ---
Bug#825342: mips/mipsel: make sure all packages built with fpxx enabled
On 28/05/16 14:31, YunQiang Su wrote: > Oh, I need to remove gcc-4.9/gcc-5/gcc-6/gnat-4.9. Is gcc-snapshot needed? BTW are these the ones with affected static libraries, or all of them? Per your email, we should do the packages with static libraries first, and only then do the rest, IIUC. If that's too cumbersome to find, we can do all now and then rebuild the ones that are still using the old ABI because of static linking. Those shouldn't be too many anyway as we don't use static linking much. Cheers, Emilio
Bug#825342: mips/mipsel: make sure all packages built with fpxx enabled
On Wed, Jun 1, 2016 at 4:24 PM, Emilio Pozuelo Monfort wrote: > On 28/05/16 14:31, YunQiang Su wrote: >> Oh, I need to remove gcc-4.9/gcc-5/gcc-6/gnat-4.9. > > Is gcc-snapshot needed? It is not needed. Sorry forget to exclude it. > > BTW are these the ones with affected static libraries, or all of them? Per > your > email, we should do the packages with static libraries first, and only then do > the rest, IIUC. > These are all about static libraries, aka some static libraries from them are still not fpxx-enabled. > If that's too cumbersome to find, we can do all now and then rebuild the ones > that are still using the old ABI because of static linking. Those shouldn't be > too many anyway as we don't use static linking much. It is not difficult to detect static libraries. > > Cheers, > Emilio -- YunQiang Su
Regression in policykit-1 0.105-15~deb8u1 (Was Re: Bug#825512: jessie-pu: package policykit-1/0.105-15~deb8u1)
I want to inform the release team about the regression introduced in the new version of the package (#825956) which may be problematic if released along with the upcoming Debian 8.5.
texlive-bin not entering testing
Dear Release managers, I would like to get the TeX Live suite into testing, but it is still hanging in unstable due to: texlive-bin is not yet built on mips (and mipsel) ... (missing 2 binaries: libtexluajit-dev, libtexluajit2) This binary packages are disappearing, they cannot be build anymore successfully, and I would like to get rid of them. There are no reverse dependencies. What are the necessary steps to fix this problem? Request removal of the package from unstable first? ANy suggestion or help would be greatly appreciated Thanks a lot Norbert -- PREINING Norbert + TeX Live & Debian Developer + http://www.preining.info GPG: 0x860CDC13fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13
Re: texlive-bin not entering testing
On Wed, Jun 01, 2016 at 10:35:20PM +0900, Norbert Preining wrote: > I would like to get the TeX Live suite into testing, but it is > still hanging in unstable due to: > texlive-bin is not yet built on mips (and mipsel) ... > (missing 2 binaries: libtexluajit-dev, libtexluajit2) it's not due to that. > ANy suggestion or help would be greatly appreciated It's simply waiting on poppler, which should enter tomorrow. Those 2 binaries are ignored indeed: |texlive-bin (2015.20160222.37495-1 to 2016.20160513.41080-2): |Maintainer: Debian TeX Maintainers |12 days old (needed 5 days) |old binaries left on mips: libtexluajit-dev, libtexluajit2 (from 2015.20160222.37495-1) (but ignoring cruft, so nevermind) |old binaries left on mipsel: libtexluajit-dev, libtexluajit2 (from 2015.20160222.37495-1) (but ignoring cruft, so nevermind) | |Invalidated by dependency | ^^ |Depends: texlive-bin poppler (not considered) |Not considered If anything else blocks the migration it should be checked once the migration is considered. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Re: texlive-bin not entering testing
Hi Mattia, > It's simply waiting on poppler, which should enter tomorrow. Those 2 > binaries are ignored indeed: A.. and I thought the luajit stuff was the problem. Sorry for the noise and thanks for the explanation Norbert -- PREINING Norbert + TeX Live & Debian Developer + http://www.preining.info GPG: 0x860CDC13fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13
Re: About packages that depend on mysql-* / mariadb / virtual-mysql-*
Hi, On 11/04/16 22:38, Otto Kekäläinen wrote: > 1. MariaDB as default > > We shall not invent a new metapackage, but instead leverage on the > existing virtual-mysql-server/cllient package scheme. It was agreed > upon already back in 2013 and all upstreams and downstreams to date > follow the convention (including MariaDB, Percona, Oracle and even > mysql-wsrep). This scheme is both backwards compatible and future > proof if users combine vanilla Debian repositories with external > repositories. Using the existing scheme requries least effort to > extend, and as it involves least amount of change it is technically > also least risky in terms of regressions or other problems. > > As so, we now propose to mass file bugs about packages in Debian that > currently depend on mysql-* to depend on mariadb-* | virtual-mysql-* > instead. If nobody objects, I'll write about the intent to mass file > bug to debian-devel in a few days and then actually file the bugs in > 1-2 weeks. > > I have already documented it here: > https://wiki.debian.org/Teams/MySQL/virtual-mysql-server Any progress on this? Have you already filed bugs? > 2. mysql-common and configuration > > Both packages mysql-5.6 and mariadb-10.0 use mysql-common from > mysql-5.6. It will be split into a separate source package that is > independent of the mysql-5.6 source package (or any later version). > > Andreas B: Can you make an action point to yourself about issue 2? It > would help a lot if I am not alone responsible of implementing all > requested changes. I guess this is still pending? > 3. libmysqlclient.so.18 > > The pkg-mysql-maint team will continue to discuss this issue and get > back later with a suggestion on how to do it. Any update on this? Thanks, Emilio
Re: About packages that depend on mysql-* / mariadb / virtual-mysql-*
On 2016-06-01 18:50, Emilio Pozuelo Monfort wrote: > On 11/04/16 22:38, Otto Kekäläinen wrote: >> 1. MariaDB as default >> I have already documented it here: >> https://wiki.debian.org/Teams/MySQL/virtual-mysql-server > > Any progress on this? Have you already filed bugs? #815567 shows that virtual-mysql-server does not help with Build-Depends. >> 2. mysql-common and configuration >> Andreas B: Can you make an action point to yourself about issue 2? It >> would help a lot if I am not alone responsible of implementing all >> requested changes. > > I guess this is still pending? I prepared a prototype for a separate mysql-common package (and default-* packages) at git://git.debian.org/git/users/anbe/tmp/mysql-defaults.git but so far nobody had time to review it. Andreas
Re: Regression in policykit-1 0.105-15~deb8u1 (Was Re: Bug#825512: jessie-pu: package policykit-1/0.105-15~deb8u1)
On 01/06/16 14:46, Mert Dirik wrote: > I want to inform the release team about the regression introduced in the new > version of the package (#825956) which may be problematic if released along > with > the upcoming Debian 8.5. Thanks for the heads up. We'll take appropriate measures. Cheers, Emilio
Re: openjpeg / stretch
On 31/05/16 12:00, Mathieu Malaterre wrote: > [adding debian-release] > > Hi, > > On Thu, May 12, 2016 at 12:48 PM, Mathieu Malaterre wrote: >> Hi, >> >> On Thu, May 12, 2016 at 12:16 PM, Moritz Muehlenhoff wrote: >>> Hi, >>> in jessie we have the unfortunate situation of having two copies of >>> openjpeg in the archive src:openjpeg and src:openjpeg2. Can you get >>> rid of openjpeg for stretch? We accept two source packages for transition >>> purposes, but these need to be sorted out by the subsequent release. >> >> That does not seems doable [*]. openjpeg 1.x and openjpeg 2.x have >> different API, and it requires a significant effort to move from one >> API to the other. Without upstream help from each packages, this >> cannot possibly be done (at least by me). >> >> If someone wants to volunteer, some projects have successfully moved >> from openjpeg 1.x to openjpeg 2.x (from the top of my head: >> mupdf/gdal/leptonlib) so some projects may have code so that they >> compile against either openjpeg 1.x or openjpeg 2.x using #idef >> triggered during configuration time. >> >> The other option is to deactivate JPEG 2000 support from those >> packages. imagemagick (accidentally) removed support for JPEG 2000 >> (#773530) and no one complained so far. > > Actually the issue is maybe a little more than just a security > concern. See the bug report #825907. Is openjpeg not using versioned symbols? > I'll leave it to debian-release to decide the severity of this bug. > Meanwhile I'll track package(s) still using OpenJPEG 1.5.x API. You can do like it is being done for jasper: file bugs with severity:important against all the rdeps, telling them we want to remove openjpeg from Stretch for security reasons, and that the bugs will get bumped to RC in some time. Then we can see how things evolve and what to do next. See https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=jasper-rm;users=j...@debian.org https://release.debian.org/transitions/html/jasper-rm.html https://lists.debian.org/debian-release/2016/03/msg6.html How does that sound? Cheers, Emilio
Bug#825342: mips/mipsel: make sure all packages built with fpxx enabled
On 01/06/16 11:27, YunQiang Su wrote: > On Wed, Jun 1, 2016 at 4:24 PM, Emilio Pozuelo Monfort > wrote: >> On 28/05/16 14:31, YunQiang Su wrote: >>> Oh, I need to remove gcc-4.9/gcc-5/gcc-6/gnat-4.9. >> >> Is gcc-snapshot needed? > > It is not needed. Sorry forget to exclude it. > >> >> BTW are these the ones with affected static libraries, or all of them? Per >> your >> email, we should do the packages with static libraries first, and only then >> do >> the rest, IIUC. >> > > These are all about static libraries, aka some static libraries from > them are still not > fpxx-enabled. > >> If that's too cumbersome to find, we can do all now and then rebuild the ones >> that are still using the old ABI because of static linking. Those shouldn't >> be >> too many anyway as we don't use static linking much. > > It is not difficult to detect static libraries. OK. I have scheduled them all, with a lower priority so other uploads can be built as well. There were some problems though: W: can't get version info for firedns/mips W: can't get version info for firedns/mipsel W: can't get version info for geoclue/mips W: can't get version info for geoclue/mipsel W: can't get version info for libhtp/mips W: can't get version info for libhtp/mipsel Are those the right package names? For geoclue you may have meant geoclue-2. src:geoclue is no longer in unstable/testing. Cheers, Emilio
Re: About packages that depend on mysql-* / mariadb / virtual-mysql-*
2016-06-01 20:03 GMT+03:00 Andreas Beckmann : >>> I have already documented it here: >>> https://wiki.debian.org/Teams/MySQL/virtual-mysql-server >> >> Any progress on this? Have you already filed bugs? > > #815567 shows that virtual-mysql-server does not help with Build-Depends. Yes, we started discussing if an additional metapackage really is needed or not, but that didn't end in a clear conclusion. The main point in that bug is the version string, and I offered that I can bake a mariadb-server-core package that always depends on the latest package, at the moment mariadb-server-core-10.0. The alternative would be to have default-mysql-server-core that depends on mariadb-server-core-10.0. So we could do without new metapackages and utilize the already existing virtual-mysql-* scheme. >>> 2. mysql-common and configuration >>> Andreas B: Can you make an action point to yourself about issue 2? It >>> would help a lot if I am not alone responsible of implementing all >>> requested changes. >> >> I guess this is still pending? > > I prepared a prototype for a separate mysql-common package (and > default-* packages) at > git://git.debian.org/git/users/anbe/tmp/mysql-defaults.git > but so far nobody had time to review it. I didn't know you've done it. I'll review it now.
NEW changes in stable-new
Processing changes file: debian-installer_20150422+deb8u4_source.changes ACCEPT
