Bug#1028602: transition: gnustep-base, gnustep-gui
Control: tags -1 = confirmed On 2023-01-13 15:15:10 +0200, Yavor Doganov wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: transition > X-Debbugs-Cc: pkg-gnustep-maintain...@lists.alioth.debian.org > Control: affects -1 + src:gnustep-base src:gnustep-gui > > Dear Release team, > > We would like your permission to carry out a GNUstep transition (two > libraries simultaneously with one round of binNMUs): > > libgnustep-base1.28 -> 1.29 > libgnustep-gui0.29 -> 0.30 Please go ahead. Cheers -- Sebastian Ramacher
Bug#1028602: transition: gnustep-base, gnustep-gui
Control: tags -1 trixie On 2023-01-29 09:41:30 +0200, Yavor Doganov wrote: > Sebastian Ramacher wrote: > > On 2023-01-13 15:15:10 +0200, Yavor Doganov wrote: > > > I realise we are already late and in all likelihood we've missed > > > the last bookworm train, which is rather unpleasant for us and > > > GNUstep users but entirely our fault. > > > > I am not quite sure what you mean with unpleasant. What would be > > unpleasant for GNUstep users? > > I meant that in case the transition is postponed to trixie, bookworm > will ship with old releases of core GNUstep. It happened for bullseye > when I missed to inform upstream about Debian's freeze/release > schedule. This time the upstream releases were made in time but we > failed to meet the deadline again. That's unfortunate timing and it's too late. Let's do this transition early in the trixie release cycle. Cheers -- Sebastian Ramacher
Bug#1028602: transition: gnustep-base, gnustep-gui
Sebastian Ramacher wrote: > On 2023-01-13 15:15:10 +0200, Yavor Doganov wrote: > > I realise we are already late and in all likelihood we've missed > > the last bookworm train, which is rather unpleasant for us and > > GNUstep users but entirely our fault. > > I am not quite sure what you mean with unpleasant. What would be > unpleasant for GNUstep users? I meant that in case the transition is postponed to trixie, bookworm will ship with old releases of core GNUstep. It happened for bullseye when I missed to inform upstream about Debian's freeze/release schedule. This time the upstream releases were made in time but we failed to meet the deadline again.
Bug#1028602: transition: gnustep-base, gnustep-gui
Control: tags -1 moreinfo On 2023-01-13 15:15:10 +0200, Yavor Doganov wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: transition > X-Debbugs-Cc: pkg-gnustep-maintain...@lists.alioth.debian.org > Control: affects -1 + src:gnustep-base src:gnustep-gui > > Dear Release team, > > We would like your permission to carry out a GNUstep transition (two > libraries simultaneously with one round of binNMUs): > > libgnustep-base1.28 -> 1.29 > libgnustep-gui0.29 -> 0.30 > > I realise we are already late and in all likelihood we've missed the > last bookworm train, which is rather unpleasant for us and GNUstep > users but entirely our fault. I am not quite sure what you mean with unpleasant. What would be unpleasant for GNUstep users? Cheers > In case it's not possible to do it now > (after tiff/poppler) then please have us in mind for the early stages > of the trixie development cycle. > > gnustep-base/1.29.0-1 is available in experimental, not yet built on > mipsen, ppc64el and s390x. But note that 1.28.1-2 was built in > unstable on all release architectures; 1.29.0 is essentially the same > except the version bump (the damage done was corrected; see #1028189). > > gnustep-gui/0.30.0-1 is also available in experimental, not yet built > on ppc64el and s390x but I do not expect any problems there. > > While build-testing all rdeps on amd64, the following problems were > observed: > > agenda.app #1028185 gnustep-gui bug, will be fixed with next upload > gnustep-dl2 #1028577 fixed locally; needs a sourceful upload > pantomime#1028578 likewise > sope #1028579 patch sent to the BTS; needs a sourceful upload > > In addition, gnustep-back will require a sourceful upload (that is > always the case). > > The automatic ben trackers at release.d.o look fine. > -- Sebastian Ramacher
Bug#1028602: transition: gnustep-base, gnustep-gui
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition X-Debbugs-Cc: pkg-gnustep-maintain...@lists.alioth.debian.org Control: affects -1 + src:gnustep-base src:gnustep-gui Dear Release team, We would like your permission to carry out a GNUstep transition (two libraries simultaneously with one round of binNMUs): libgnustep-base1.28 -> 1.29 libgnustep-gui0.29 -> 0.30 I realise we are already late and in all likelihood we've missed the last bookworm train, which is rather unpleasant for us and GNUstep users but entirely our fault. In case it's not possible to do it now (after tiff/poppler) then please have us in mind for the early stages of the trixie development cycle. gnustep-base/1.29.0-1 is available in experimental, not yet built on mipsen, ppc64el and s390x. But note that 1.28.1-2 was built in unstable on all release architectures; 1.29.0 is essentially the same except the version bump (the damage done was corrected; see #1028189). gnustep-gui/0.30.0-1 is also available in experimental, not yet built on ppc64el and s390x but I do not expect any problems there. While build-testing all rdeps on amd64, the following problems were observed: agenda.app #1028185 gnustep-gui bug, will be fixed with next upload gnustep-dl2 #1028577 fixed locally; needs a sourceful upload pantomime#1028578 likewise sope #1028579 patch sent to the BTS; needs a sourceful upload In addition, gnustep-back will require a sourceful upload (that is always the case). The automatic ben trackers at release.d.o look fine.
