Bug#828097: transition: tidy
Package: release.debian.org User: release.debian@packages.debian.org Usertags: transition X-Debbugs-CC: t...@packages.debian.org X-Debbugs-CC: tidy-ht...@packages.debian.org X-Debbugs-CC: rouss...@debian.org This week's upload of tidy-html5 to unstable started an unannounced library transition. Next time, please read this wiki page especially the Transitions subpage. https://wiki.debian.org/Teams/ReleaseTeam Also, I think it was an unnecessary clobber of the already existing tidy source package because I don't think we need both source packages in Debian. Here's my guess at the ben syntax: title = "tidy"; is_affected = .depends ~ /tidy/ | .build-depends ~ /libtidy-dev/; is_good = .depends ~ "libtidy5"; is_bad = .depends ~ "libtidy-0.99-0"; Thanks, Jeremy Bicha
Next d-i alpha release: late June
Hi, I've just checked with Ben, it seems we could be getting a 4.6 kernel suitable for testing (no regressions reported from previous version + mips* FTBFS fix) shortly. We could think about urgenting it into testing and releasing a new d-i early in the week, which seems OK on the -cd side too. Glibc maintainers (esp. Aurélien): you should then have a clear path for the new glibc in unstable. I'm not sure how much time it'll need to be ready, that's why I'd slightly prefer if we could go for a d-i release first (as outlined above). In case major blockers pop up, we would probably let you go ahead with the new glibc upload and postpone d-i until glibc reaches testing. Having checked with -release already, I'm freezing udebs right away. (Please cc me on replies.) KiBi. signature.asc Description: Digital signature
Processed: bind9: clamav with openssl 1.1: Doesn't find openssl
Processing control commands: > block 827061 by -1 Bug #827061 [release.debian.org] transition: openssl 827061 was blocked by: 827068 828082 827061 was not blocking any bugs. Added blocking bug(s) of 827061: 828083 -- 827061: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=827061 828083: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=828083 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed: bind9: FTBFS with openssl 1.1
Processing control commands: > block 827061 by -1 Bug #827061 [release.debian.org] transition: openssl 827061 was blocked by: 827068 827061 was not blocking any bugs. Added blocking bug(s) of 827061: 828082 -- 827061: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=827061 828082: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=828082 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Re: [debian-mysql] About packages that depend on mysql-* / mariadb / virtual-mysql-*
On Fri, Jun 24, 2016 at 07:53:56PM +0200, Julien Cristau wrote: > Please don't use virtual-foo for non-virtual packages, that way lies > madness and confusion and despair :) OK, but does anyone have any objection to the principle of my suggestion, even if we must use a different name?
Re: [debian-mysql] About packages that depend on mysql-* / mariadb / virtual-mysql-*
On Fri, Jun 24, 2016 at 14:55:34 +0100, Robie Basak wrote:
> On Wed, Jun 01, 2016 at 07:03:42PM +0200, Andreas Beckmann wrote:
> > 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.
>
> A thought from Norvald. Do we really need more metapackages? What if we
> converted the existing virtual-mysql-{server-client} virtual packages
> into metapackages generated from src:mysql-defaults instead?
>
> Then these would depend on "mariadb-server | mysql-server" etc. Existing
> packages would drop their preferred alternative and depend on
> "virtual-mysql-server" only. src:mysql-defaults would then have full
> control of the "default" just by swapping the alternatives.
>
> The benefit would be fewer meta/virtual -packages. Is there any use case
> that is not covered by this?
Please don't use virtual-foo for non-virtual packages, that way lies
madness and confusion and despair :)
Cheers,
Julien
signature.asc
Description: PGP signature
Re: [debian-mysql] About packages that depend on mysql-* / mariadb / virtual-mysql-*
On Wed, Jun 01, 2016 at 07:03:42PM +0200, Andreas Beckmann wrote:
> 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.
A thought from Norvald. Do we really need more metapackages? What if we
converted the existing virtual-mysql-{server-client} virtual packages
into metapackages generated from src:mysql-defaults instead?
Then these would depend on "mariadb-server | mysql-server" etc. Existing
packages would drop their preferred alternative and depend on
"virtual-mysql-server" only. src:mysql-defaults would then have full
control of the "default" just by swapping the alternatives.
The benefit would be fewer meta/virtual -packages. Is there any use case
that is not covered by this?
signature.asc
Description: PGP signature
Bug#815720: marked as done (transition: python3.5-only)
Your message dated Fri, 24 Jun 2016 11:52:47 +0200 with message-id <14ebaaaf-dfe8-4423-59b5-d6c97b13d...@debian.org> and subject line Re: Bug#815720: transition: python3.5-only has caused the Debian Bug report #815720, regarding transition: python3.5-only 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.) -- 815720: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=815720 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: transition python3-defaults now no longer depends on python3.4, making python3.5 the only supported python3 version. python3.4 should be removed before stretch is released (mostly by binNMUing, and then removing python3.4). not urgent, just adding this in the bug tracker. --- End Message --- --- Begin Message --- On 24/02/16 01:49, Matthias Klose wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: transition > > python3-defaults now no longer depends on python3.4, making python3.5 the only > supported python3 version. python3.4 should be removed before stretch is > released (mostly by binNMUing, and then removing python3.4). not urgent, just > adding this in the bug tracker. python3.4 just got removed from testing last night. Let's close this. Cheers, Emilio--- End Message ---
Bug#827964: marked as done (nmu: vim-command-t_4.0-1)
Your message dated Fri, 24 Jun 2016 11:50:39 +0200 with message-id and subject line Re: Bug#827964: nmu: vim-command-t_4.0-1 has caused the Debian Bug report #827964, regarding nmu: vim-command-t_4.0-1 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.) -- 827964: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=827964 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 -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hello, vim-command-t has stricter dependency requirements on the version of ruby under which it runs than specified in libruby2.3's shlibs/symbols files. As a result the package does not function when used with vim in unstable. Please rebuild vim-command-t against the latest ruby2.3-dev. nmu vim-command-t_4.0-1 . ANY . unstable . -m "Rebuild against current ruby2.3-dev" - -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (555, 'testing'), (520, 'unstable'), (510, 'experimental'), (500, 'unstable-debug') Architecture: amd64 (x86_64) Kernel: Linux 4.6.0-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) -BEGIN PGP SIGNATURE- iQIcBAEBCAAGBQJXa8SGAAoJENILQgJc2ie5y3EQAKQVTTHiWPVomzokYDbH0aXN YhXxh4IUsdOuJNbjcIVC01INLo16E1Glc4y5aIF7uQ1W2WqZkoVlH+2kcdNhnKfm HINg2een7nEDtSHTPEyoZnWtvQZVmGI2G22k1meL70h5P0YkCt7rRd3A7t0mXYmX fzT21lNDytbP8qIW108ciMgcWALWojxLSwhOuR9IuyJoZby7ITl1QCVDDO4P4cRB t0YZlc0dQ2SEl3F9CLTDdNB1muDY3Nb/91O8CLuem2Hxv3n32w6/MMH9Ek3PtYAS Rza5bgN15wGESrBP79JwIU38tKb03NqQ99oLLSZ2uTjKpDPYFl+fGpCfAAcXkY46 a3S1Z0/DH0HshwYrMWHx35lZE13rqoUzoW6vpxtA1p7PX/g8rhZeHhcch72PT58U 5Hw3MK2AqmyEyZSzGDuatgW9SKUydHeJFK63yfDskg8VXwCXIbmdAG85OFlZiQ5f KmqCaRQOcw1W5ix/YpcmB2qi+egckRhT1Yl4x93wgkClQypBJEd8NspAA6elHZbR f3lRYlt7caGqzmutJItiJvBp21IIlkufqtWELzeDBwFn0976YmUDT1AZWDBLvFu9 rf+8Dqy2N0llmd6EThLDuOQcLk/GYppLP5SsuxYcsdXHXAP/LrQewAnCEx9CuTke ZSMwso3Able1bmYwXB1t =VgfY -END PGP SIGNATURE- --- End Message --- --- Begin Message --- On 23/06/16 17:44, Sam Morris wrote: > On Thu, 2016-06-23 at 16:50 +0200, Emilio Pozuelo Monfort wrote: >> On 23/06/16 13:14, Sam Morris wrote: >>> Package: release.debian.org >>> Severity: normal >>> User: release.debian@packages.debian.org >>> Usertags: binnmu >>> >>> Hello, >>> >>> vim-command-t has stricter dependency requirements on the version >>> of >>> ruby under which it runs than specified in libruby2.3's >>> shlibs/symbols >>> files. As a result the package does not function when used with vim >>> in >>> unstable. >> >> Maybe it should have a stricter dependency? This sounds like a bug in >> the >> package (dependencies). >> >> Cheers, >> Emilio > > Yes, in the next version I upload I have tightened the dependency on > libruby2.3. But I'm waiting for a sponsor to upload that; in the > meantime, a rebuild will fix the package in unstable. Let's not workaround this with a binNMU. Cheers, Emilio--- End Message ---
Re: [Pkg-openssl-devel] Bug#827951: libssl udeb inclusion in Jessie
Le jeudi 23 juin 2016 à 23:13 +0200, jcris...@debian.org a écrit : > On Thu, Jun 23, 2016 at 12:55:54 +0200, Yann Soubeyrand wrote: > > > Le jeudi 23 juin 2016 à 11:20 +0200, k...@roeckx.be a écrit : > > > On Thu, Jun 23, 2016 at 10:58:54AM +0200, Yann Soubeyrand wrote: > > > > Package: openssl > > > > Severity: normal > > > > Version: 1.0.1t-1+deb8u2 > > > > X-Debbugs-CC: debian-release@lists.debian.org > > > > X-Debbugs-CC: debian-b...@lists.debian.org > > > > > > > > Hi, > > > > > > > > Marga Manterola provided a patch to build a libssl udeb as well as the > > > > libcrypto udeb that was included in Sid (#802591). Could this patch be a > > > > candidate for Jessie inclusion? If so, you can find a patch attached to > > > > this mail. > > > > > > Is there a reason why you would like it in jessie? Will the > > > installer start to make use of it? > > > > > > Kurt > > > > At the company I work for, we customize the installer to fit our needs > > and we make use of wget udeb's https support. It would make our task > > simpler not to have to maintain a modified version of openssl and wget > > packages. > > > That doesn't sound suitable for a stable update, sorry. > > Cheers, > Julien OK, I understand. Cheers Yann
