Bug#823002: transition: nvidia-cuda-toolkit 7.5
On 2016-04-30 00:06, Mattia Rizzolo wrote: > [ off-list, as I'd kinda prefer avoid disturbing the RT with this ] > > On Fri, Apr 29, 2016 at 10:43:36PM +0200, Andreas Beckmann wrote: >> eztrace-contrib, hwloc-contrib and pycuda are fine and just need a >> binNMU (maintainer-uploaded since this involves non-free). > > Is somebody planning to do these? > I know pochu doesn't do them, and I know you did some manual binNMU in > the past (so did I), also, I noticed all of them saw a recent maintainer > upload. > > Is the plan poking the maintainers and have them make a regular upload > of them (2 out of 3 being from sthibaut should make this easy), or > should somebody build a manual binNMU? Samuel or I will take care of these. Andreas
Bug#823002: transition: nvidia-cuda-toolkit 7.5
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Forwarded: https://release.debian.org/transitions/html/auto-nvidia-cuda-toolkit.html Hi, the next release of nvidia-cuda-toolkit/non-free has arrived in experimental and is ready for upload to unstable. eztrace-contrib, hwloc-contrib and pycuda are fine and just need a binNMU (maintainer-uploaded since this involves non-free). starpu-contrib needs a sourceful upload to switch from gcc-4.9 to gcc-5 (the previous toolkit version didn't support gcc-5). Samuel will do this quickly. Andreas
Re: Bug#746005: guile-2.0 migration
On Fri, 29 Apr 2016, Emilio Pozuelo Monfort wrote: > We talked about this on the RT meeting yesterday and agreed to bump > this to RC again. We wouldn't like to release Stretch with guile-1.8 > just for lilypond's sake, and it is better to act now that there's > plenty of time before the freeze so that a new version can be uploaded > (possibly to experimental for the time being) and fixes can be > applied. OK. Basically, there's no way that 2.18 will be fixed to work with Guile 2.0, but assuming that 2.20 gets released before stretch, this will be workable. > We can discuss this again later in the cycle if necessary, though > hopefully lilypond can get in shape and we won't need to do that :) Well, the shape that will be required is the release of a stable lilypond release which supports guile. Hopefully soon. > There have been plenty of 'unstable' releases (last one was 2.19.40 > just a few days ago) and those have a --with-guile2 configure switch. > It may be a good idea to upload that to experimental with guile 2.0 > support? Sure, but this won't fix the version of lilypond in unstable. [I at least do not have the time to support a development release of lilypond through the lifetime of a stable release.] Are auto-removals from testing currently off? [Basically, I'd like to avoid having lilypond removed from testing until we're closer to the release if that's at all possible.] -- Don Armstrong https://www.donarmstrong.com A Bill of Rights that means what the majority wants it to mean is worthless. -- U.S. Supreme Court Justice Antonin Scalia
Re: Bug#746005: guile-2.0 migration
Control: severity -1 serious Hi, We talked about this on the RT meeting yesterday and agreed to bump this to RC again. We wouldn't like to release Stretch with guile-1.8 just for lilypond's sake, and it is better to act now that there's plenty of time before the freeze so that a new version can be uploaded (possibly to experimental for the time being) and fixes can be applied. We can discuss this again later in the cycle if necessary, though hopefully lilypond can get in shape and we won't need to do that :) On 09/12/15 21:02, Don Armstrong wrote: > On Wed, 09 Dec 2015, Emilio Pozuelo Monfort wrote: >> On 06/05/15 16:41, Don Armstrong wrote: >>> Control: severity -1 important >>> >>> On Tue, 05 May 2015, Rob Browning wrote: Don Armstrong writes: > At this juncture, I'm OK with expending the effort myself to keep > guile-1.8 working with lilypond as the sole reverse dependency if that's > what is required. [Unfortunately, I don't have enough time or expertise > to actually solve the issues with the newer versions of guile, though.] For the record, I'm fine with letting 1.8 stay for now. I imagine Don and I can handle any serious problems, and hopefully we won't need it too much longer. >>> >>> Thanks. I'm going to downgrade this for the time being. I'm going to try >>> to keep on top of this as the development of squeeze progresses; feel >>> free to re-ping whenever. >> >> Squeeze? Did you mean Stretch? :) > > Yes, sorry. > >> How is this looking? I saw some commits on the upstream git repo >> mentioning guile 2.0. If you're unsure about this, maybe we could have >> the unstable 2.19.x series uploaded to experimental, built against >> guile-2.0, to make some progress, get some feedback, etc? > > I haven't re-pinged them recently, but they were making some progress > last time I checked. > > Rebuilding for experimental makes some sense to keep on top of this, > though as I remember, it built, but then didn't always work properly. > > [I'm running chronically short on time though, so I've sort of just been > letting this sit until a new release comes out.] There have been plenty of 'unstable' releases (last one was 2.19.40 just a few days ago) and those have a --with-guile2 configure switch. It may be a good idea to upload that to experimental with guile 2.0 support? Cheers, Emilio
