Bug#813721: transition: libsodium
On Thu, Feb 4, 2016 at 6:55 PM, Emilio Pozuelo Monfort wrote: > On 04/02/16 18:48, László Böszörményi (GCS) wrote: >> A small transition of libsodium. It has soname 13 in Sid and 18 in >> experimental. > > Go ahead. It was strage as -2 was compiled on all architectures in experimental, but a no change -3 failed on non-x32/x64 ones. This is now fixed and libsodium built on all architectures in Sid. The binNMUs may start. Thanks, Laszlo/GCS
Re: Kernel version for stretch
On Tue, 2016-02-02 at 07:34 +, Niels Thykier wrote: [...] > > Greg's new policy is to pick the first Linus release in each year for > > longterm maintenance. The longterm branch for 2016 is based on Linux > > 4.4, released at the end of week 1 (10th January). By the time stretch > > is released, 4.4 will be quite old (the same problem squeeze and wheezy > > had, requiring many driver backports). > > > > Would you prefer that we moved future freezes (i.e. Buster and later), > so we could always rely on Greg's branch? Yes, I would. > Not knowing Linux's LTS planning: > > * Does Greg do an LTS *every* year? OR, He has done so every year since 2008, except for 2010. Following discussion at last year's kernel summit, he agreed to start an LTS branch from the first release of each year, which should be within the first 9 weeks of the year. [...] > @Kernel+d-i - What is your take on the following: > > * How long will it take to have the new release ready? > - That is, the latency between the 22nd and us having it in unstable. Usually we would upload a new upstream release to experimental and wait for at least the first stable update before uploading to unstable. That means a delay of about 3 weeks. But we could decide to take the risk of uploading early to unstable, even starting with release candidates to flush out bugs that will affect Debian users. > - How certain are we on the 22nd being the actual release date? I thought that 10 week cycles were rare, but I checked this and now I'm much less confident. Rounding to the nearest week, the distribution of release cycle lengths from 3.2 to 4.4 inclusive, is: 8 weeks: * ( 1) 9 weeks: ** (10) 10 weeks: ** (10) 11 weeks: ** ( 2) (I chose this range to exclude the 3.1 release delayed by the kernel.org compromise.) So it seems quite possible that 4.10 could be released later in January or in February. [...] > * How difficult/disruptive do you expect the migration to linux 4.10 > will be? > - Is this something we can reasonably do within a month? 2 months? Migration from what, 4.9? > - Can we plan ahead to reduce the time / issues? Maybe use > linux pre-releases? Yes, that's an option. Thanks to early integration testing (linux- next), Linux release candidates are less of a risk than they used to be. > - If we start this, is it in anyway reasonable to do a roll-back > within 2-3 weeks? (I am guessing "no", but I figured I'd ask.) I think it would be doable, but it would probably require the earlier kernel version to be re-uploaded as a new source package to satisfy dak. > * If we were to stick with 4.4, what we will be missing out on? > - Are there any planned/known "must haves"? Primarily hardware support - we would likely need to backport support for newer GPUs, Ethernet, wifi and SCSI controllers in PCs and for new ARM-based SoCs and platforms. > - How long does Greg's LTS last? We would spend at least a year of > it before January 22nd 2017. About 15 months. > > (By the way, I haven't seen the stretch freeze dates announced > > anywhere; I only found them on a wiki page. A new "Bits from the > > release team" seems to be overdue.) > > > > Ben. > > > > A bits is indeed overdue. The announcement happened in the Release Team > talk at DebConf15. Thanks. I knew I had seen dates somewhere, and that must have been where I saw them. Ben. -- Ben Hutchings It is a miracle that curiosity survives formal education. - Albert Einstein signature.asc Description: This is a digitally signed message part
Re: Kernel version for stretch
On Thu, Feb 4, 2016 at 11:45 AM, Antonio Terceiro wrote: > Yet another data point: Ruby makes stable releases every Christmas Wine also plans their freeze in the fall now, which ended up in a release near Christmas this year. If the same holds this year, that will be too late for the Debian freeze. Best wishes, Mike
Bug#796835: release.debian.org: Transition: ncurses-6.0
On 24/08/15 20:17, Sven Joachim wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: transition > X-Debbugs-CC: ncur...@packages.debian.org > Control: block 230990 by -1 > > For quite some time, ncurses had the option to be built with a new ABI > that enables applications to use mouse wheels, among other good things > (see #230990). Switching to this ABI had been stalled due to the lack > of symbol versioning and the rather large number of ncurses' reverse > dependencies, with quite a few libraries among them. > > In the latest ncurses release (6.0), symbol versioning was added to the > libraries, and we would like to see ncurses' reverse dependencies to be > rebuilt during the Stretch release cycle so that the long requested ABI > change becomes possible after the Debian 9 release. > > The new ncurses version has already migrated to testing, and there is no > hurry to rebuild reverse dependencies right away, but I would like to > see a mass rebuild some time before the Stretch freeze and set up a > tracker in the meantime. > > Suggested ben file (only lightly tested, please check): > > title = "ncurses-6.0"; > is_affected = .depends ~ /libncursesw?5|libtinfo5/; > is_good = .depends ~ /libncursesw?5 \(>= 6|libtinfo5 \(>= 6/; > is_bad = .depends ~ /libncursesw?5 \(>= 5|libtinfo5(,|$)|libtinfo5\(>= 5/; This is basically done. There's just 4store missing, which FTBFS on arm64. Also there is joe which got built against the old ncurses on i386 by the maintainer. Unfortunately that doesn't prevent migration, so that's likely to happen again. Cheers, Emilio
Processed: starpu-contrib: FTBFS: undefined reference to `leveldb::DB::Open
Processing control commands: > block 813128 by -1 Bug #813128 [release.debian.org] transition: openmpi 813128 was blocked by: 813725 813722 813724 813128 was not blocking any bugs. Added blocking bug(s) of 813128: 813731 > block 813542 by -1 Bug #813542 [release.debian.org] transition: nvidia-cuda-toolkit 813542 was not blocked by any bugs. 813542 was not blocking any bugs. Added blocking bug(s) of 813542: 813731 -- 813128: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=813128 813542: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=813542 813731: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=813731 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed: gyoto: FTBFS: gyoto.C: Error initializing libgyoto
Processing control commands: > block 813128 by -1 Bug #813128 [release.debian.org] transition: openmpi 813128 was blocked by: 813724 813722 813128 was not blocking any bugs. Added blocking bug(s) of 813128: 813725 -- 813128: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=813128 813725: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=813725 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed: adios: FTBFS with openmpi 1.10
Processing control commands: > block 813128 by -1 Bug #813128 [release.debian.org] transition: openmpi 813128 was blocked by: 813722 813128 was not blocking any bugs. Added blocking bug(s) of 813128: 813724 -- 813128: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=813128 813724: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=813724 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#813721: transition: libsodium
Control: tags -1 confirmed On 04/02/16 18:48, László Böszörményi (GCS) wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: transition > > A small transition of libsodium. It has soname 13 in Sid and 18 in > experimental. > > Affected packages are: > dnscrypt-proxy > fastd > netsniff-ng > python-nacl > zeromq3 > > Package maintainers noted ten days ago and confirmed my tests that > those can be safely binNMUed. This also mean that libsodium library > packages are co-installable. Go ahead. Cheers, Emilio
Bug#813721: transition: libsodium
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition A small transition of libsodium. It has soname 13 in Sid and 18 in experimental. Affected packages are: dnscrypt-proxy fastd netsniff-ng python-nacl zeromq3 Package maintainers noted ten days ago and confirmed my tests that those can be safely binNMUed. This also mean that libsodium library packages are co-installable. Ben file: title = "libsodium; is_affected = .depends ~ "libsodium13" | .depends ~ "libsodium18"; is_good = .depends ~ "libsodium18"; is_bad = .depends ~ "libsodium13";
Processed: Re: Bug#813721: transition: libsodium
Processing control commands: > tags -1 confirmed Bug #813721 [release.debian.org] transition: libsodium Added tag(s) confirmed. -- 813721: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=813721 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed: aces3: FTBFS on powerpc
Processing control commands: > block 813128 by -1 Bug #813128 [release.debian.org] transition: openmpi 813128 was not blocked by any bugs. 813128 was not blocking any bugs. Added blocking bug(s) of 813128: 813722 -- 813128: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=813128 813722: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=813722 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#813100: transition: libopenobex
On 04/02/16 18:18, Mattia Rizzolo wrote: > On Thu, Feb 04, 2016 at 05:48:32PM +0100, Emilio Pozuelo Monfort wrote: >> On 30/01/16 01:18, Nobuhiro Iwamatsu wrote: >>> Hi, Andreas. >>> >>> Thanks for this mail and work! >>> I was just thinking the migration of this broken library. >> >> Unfortunately the versioned -dev package means every rdep needs a sourceful >> upload to build against the new version. It'd be good to switch to an >> unversioned -dev... > > umh, actually, there is a 'Provides: libopenobex-dev', shouldn't be that > enough for this? Yes. Though as you say... > From what I can see no rdep use the unversioned virtual package, but > this could be a good occasion to have them switch to it? Packages still need sourceful uploads, and unless it is pointed to them, I bet they will switch to libopenobex2-dev, requiring yet another change when the SONAME changes again. So it'd be good to explicitly mention the unversioned libopenobex-dev build-dependency. Cheers, Emilio
Bug#813100: transition: libopenobex
On Thu, Feb 04, 2016 at 05:48:32PM +0100, Emilio Pozuelo Monfort wrote: > On 30/01/16 01:18, Nobuhiro Iwamatsu wrote: > > Hi, Andreas. > > > > Thanks for this mail and work! > > I was just thinking the migration of this broken library. > > Unfortunately the versioned -dev package means every rdep needs a sourceful > upload to build against the new version. It'd be good to switch to an > unversioned -dev... umh, actually, there is a 'Provides: libopenobex-dev', shouldn't be that enough for this? From what I can see no rdep use the unversioned virtual package, but this could be a good occasion to have them switch to it? -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: http://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Uploading linux (4.3.5-1)
I intend to upload linux version 4.3.5-1 to unstable on Friday or Saturday. This includes a few security fixes and many other bug fixes. There is no ABI change. Ben. -- Ben Hutchings Beware of bugs in the above code; I have only proved it correct, not tried it. - Donald Knuth signature.asc Description: This is a digitally signed message part
Processed: Re: Bug#812887: transition: iptables
Processing commands for cont...@bugs.debian.org: > tags 812887 + pending Bug #812887 [release.debian.org] transition: iptables Added tag(s) pending. > thanks Stopping processing here. Please contact me if you need assistance. -- 812887: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=812887 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#811207: marked as done (transition: libcutl)
Your message dated Thu, 4 Feb 2016 17:52:48 +0100 with message-id <56b381e0.7060...@debian.org> and subject line Re: Bug#811207: transition: libcutl has caused the Debian Bug report #811207, regarding transition: libcutl 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.) -- 811207: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=811207 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 Mini-transition of libcutl. It has 1.8 soname in Sid and 1.9 in experimental, but I plan to upload soname 1.10 version. May I upload it directly to Sid or should I target experimental first? The only affected binary is odb which can be binNMUed. Libraries are co-installable. Ben file: title = "libcutl; is_affected = .depends ~ "libcutl-1.8" | .depends ~ "libcutl-1.9" | .depends ~ "libcutl-1.10"; is_good = .depends ~ "libcutl-1.10"; is_bad = .depends ~ "libcutl-1.8" | .depends ~ "libcutl-1.9"; --- End Message --- --- Begin Message --- On 18/01/16 15:16, Jonathan Wiltshire wrote: > On 2016-01-18 13:23, László Böszörményi wrote: >> On Sat, Jan 16, 2016 at 11:34 PM, Jonathan Wiltshire wrote: >>> On 2016-01-16 20:17, Laszlo Boszormenyi (GCS) wrote: [...], but I plan to upload soname 1.10 version. May I upload it directly to Sid or should I target experimental first? The only affected binary is odb which can be binNMUed. Libraries are co-installable. >>> >>> If you have tested odb and it builds correctly with the new library, you may >>> upload directly to sid. >> Yes, of course I've tested odb and it built correctly. Uploaded >> libcutl 1.10 to Sid and built / installed on all primary >> architectures; expect mips where it's still scheduled. > > Thanks, scheduled with --extra-depends. This seems to be over. Closing. Cheers, Emilio--- End Message ---
Bug#813100: transition: libopenobex
Control: tags -1 confirmed On 30/01/16 01:18, Nobuhiro Iwamatsu wrote: > Hi, Andreas. > > Thanks for this mail and work! > I was just thinking the migration of this broken library. Unfortunately the versioned -dev package means every rdep needs a sourceful upload to build against the new version. It'd be good to switch to an unversioned -dev... Also please file bugs against the rdeps so they get their build-dep updated. c.f. https://release.debian.org/transitions/html/auto-libopenobex.html Cheers, Emilio
Processed: Re: Bug#813100: transition: libopenobex
Processing control commands: > tags -1 confirmed Bug #813100 [release.debian.org] transition: libopenobex Added tag(s) confirmed. -- 813100: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=813100 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#761128: transition: oce
Control: tags -1 = confirmed pending On 10/05/15 18:10, Emilio Pozuelo Monfort wrote: > On 09/05/15 21:26, Jonathan Wiltshire wrote: >> Hi, >> >> On Wed, Sep 10, 2014 at 11:45:48PM +0200, D. Barbier wrote: >>> I would like to upload oce 0.16 into unstable, it is currently in >>> experimental. This source package provides several development >>> libraries, their soname version have been bumped. >> >> Would you be in a position to upload to unstable very soon? > > The package failed to build on arm64 and mips (and ppc64el but it hasn't ever > been built there). That should probably be fixed in experimental before the > transition is started. > > Also, have the reverse dependencies been build-tested against the new oce? Looks like this has been started and is almost done. Cheers, Emilio
Processed: Re: Bug#761128: transition: oce
Processing control commands: > tags -1 = confirmed pending Bug #761128 [release.debian.org] transition: oce Added tag(s) confirmed and pending; removed tag(s) jessie-ignore and moreinfo. -- 761128: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=761128 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Re: Kernel version for stretch
On Thu, Feb 04, 2016 at 10:18:44AM +0100, Raphael Hertzog wrote: > On Tue, 02 Feb 2016, Niels Thykier wrote: > > > Greg's new policy is to pick the first Linus release in each year for > > > longterm maintenance. The longterm branch for 2016 is based on Linux > > > 4.4, released at the end of week 1 (10th January). By the time stretch > > > is released, 4.4 will be quite old (the same problem squeeze and wheezy > > > had, requiring many driver backports). > > > > Would you prefer that we moved future freezes (i.e. Buster and later), > > so we could always rely on Greg's branch? Not knowing Linux's LTS planning: > > As another data point, I'd like to point out that our freeze/release > schedule also means that we miss most of the benefit from Django's LTS > release. They have an LTS release every two years and they push it out > roughly at the same time than we do with our stable release. > > Maybe it would make sense to have a general policy of aiming to accept > LTS releases during the freeze, or even in the first point update. > We could upload pre-release of upcoming LTS versions before the freeze > (or early in the freeze)... Yet another data point: Ruby makes stable releases every Christmas, what is usually after the freeze; that means that we often release Debian stable with a version of Ruby that was release 2 Christmas ago. e.g. Jessie was released on April 2015 with the stable version of Ruby (2.1) that was released on December 2013. That is not bad per se as by the time we release that stable Ruby version has been very well tested and had already a couple of maintainace releases. But it also means that there is less overlap between our stable maintainance window and the upstream maintainance window for that version. -- Antonio Terceiro signature.asc Description: PGP signature
Bug#797926: marked as done (transition: openssl: remove SSLv3 methods)
Your message dated Thu, 4 Feb 2016 09:45:08 + with message-id <20160204094508.ga6...@chase.mapreri.org> and subject line Re: Bug#797926: transition: openssl: remove SSLv3 methods has caused the Debian Bug report #797926, regarding transition: openssl: remove SSLv3 methods 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.) -- 797926: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=797926 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: release.debian.org Hi, I would like to remove the last support for SSLv3 in openssl. This means that I'll be dropping 3 symbols from the shared library: SSLv3_method(); SSLv3_server_method(); SSLv3_client_method(); Those can still be used to set up SSLv3 connections, while using the SSLv23_* methods won't talk SSLv3. This change will result in the define OPENSSL_NO_SSL3_METHOD becoming defined. Some software in Debian already checks for either that define or the presence of the functions to enable support for it or not. I find those changes very unfortunate, they should just have dropped SSLv3 support completly. My question is how you want to proceed with this. I see a few options: - Change the soname, rebuild everything against that new soname. - Just drop the symbols, adding Breaks on at least some packages like curl and python that are known to need a rebuild against the changed headers. As far as I know all the major packages making use of those symbols should be fixed now, or have a fix available. Kurt --- End Message --- --- Begin Message --- On Mon, Feb 01, 2016 at 11:57:55PM +0100, Emilio Pozuelo Monfort wrote: > On 01/02/16 18:14, Mattia Rizzolo wrote: > > If I'm looking right at this transition the only remaining package is > > pbbam, where the maintainer-built binary was built against the old > > libssl. > > > > Please binNMU it. > > > > Does it being ma:same implies you should binNMU all archs to preserve > > coinstallability? > > Rebuilt on amd64 and i386. thanks also to your other binNMU of rem, this is now done. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: http://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature --- End Message ---
Re: Kernel version for stretch
On Tue, 02 Feb 2016, Niels Thykier wrote: > > Greg's new policy is to pick the first Linus release in each year for > > longterm maintenance. The longterm branch for 2016 is based on Linux > > 4.4, released at the end of week 1 (10th January). By the time stretch > > is released, 4.4 will be quite old (the same problem squeeze and wheezy > > had, requiring many driver backports). > > Would you prefer that we moved future freezes (i.e. Buster and later), > so we could always rely on Greg's branch? Not knowing Linux's LTS planning: As another data point, I'd like to point out that our freeze/release schedule also means that we miss most of the benefit from Django's LTS release. They have an LTS release every two years and they push it out roughly at the same time than we do with our stable release. Maybe it would make sense to have a general policy of aiming to accept LTS releases during the freeze, or even in the first point update. We could upload pre-release of upcoming LTS versions before the freeze (or early in the freeze)... Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: http://www.freexian.com/services/debian-lts.html Learn to master Debian: http://debian-handbook.info/get/
