Re: status update: GNUstep library transition
[dropping the bug report from the Cc: list]
On 2006-10-14 03:23:16 -0400 Steve Langasek <vorlon@debian.org> wrote:
> On Fri, Oct 13, 2006 at 03:11:51PM -0400, Hubert Chan wrote:
>> Ugh. It looks like the GNUstep transition is being further held up by
>> recent NMUs:
>>
>> - gnustep-netclasses
>
> This doesn't hold anything up /further/, when this is the first build of the
> package that isn't uninstallable with the new gnustep... :)
I thought it would, since there's a version of gnustep-netclasses in testing. Anyways, if it doesn't hold it up, that's fine. If it does, you have the option of removing it from testing if you want.
> Anyway, if
> the NMU itself isn't broken, this should go in with another two days of
> aging. (If it is broken, that should be documented with an RC bug.)
Two more days? OK, I wasn't sure how much you fast-tracked these packages.
>> - steptalk (an NMU for a bug that's only one day old???)
[...]
> Please exercise more caution when sponsoring NMUs prepared by the submitters
> of bugs. It's clear that you didn't verify this bug yourself before
> uploading, and the most this upload has done is to delay the gnustep
> transition.
I was originally going to fire off an angry email to Adriaan and Philipp, bud decided against it. I can understand their rush to fix the bug, as Adriaan had done the previous NMU for our last transition, and the listed maintainer for that package is inactive. However, I want to echo Steve's request to exercise more caution in the future. For one thing, the packages were indeed buildable, as the latest versions of the GNUstep library packages did Provide: the old -dev package names. (The previous version of the library packages did not, which I assume is what is installed on Adriaan's machine.) As well, there were already binNMUs of the packages that were correctly built. And if you know that a package is part of a library transition, it is probably best to at least check with d-release and/or the library maintainer to see if some alternate arrangement has already been made. (In this case, I had already informed d-release that steptalk could be removed from testing.)
>> - cddb.bundle
>
>> Nothing depends on it, so it should be removable from testing for now.
>
> Should also be ready within two days.
OK, good.
>> vorlon, my understanding of the situation is that the removal of these
>> packages from testing, along with the others I mentioned in my previous
>> email (talksoup.app and meta-gnustep) should allow the transition of the
>> rest of the packages into etch in a few days (assuming everything is
>> built on all architectures). Does that match your understanding as
>> well?
>
> It does appear that removing these packages from etch would let the
> transition proceed, but I can't imagine why we would want to remove
> meta-gnustep from testing. That doesn't seem to make the gnustep packages
> in testing more releasable than the current set.
Currently, gnustep-core-devel, from meta-gnustep, depends on libgnustep-base1.11-dbg and libgnustep-gui0.10-dbg, which will no longer be available with the new GNUstep libraries. Which I think would prevent the migration to testing.
Again, if it really doesn't need to be removed, that's fine. But if it does hold up the transition, go ahead and remove it from testing.
Thanks
P.S. Gürkan, when you prepare a new meta-gnustep package, it's probably safe to remove the dependency on the -dbg packages, or at least bump them down to Recommends: or Suggests:, since they aren't strictly necessary now.
P.P.S. Steve, could I request a freeze exception for meta-gnustep: in the (seemingly likely) case that not all the GNUstep packages get through NEW before the freeze, would you (or aba) allow Gürkan to upload a new meta-gnustep that will depend only on the packages that made it into etch? I understand that he has been delaying an upload of meta-gnustep, so that he can include the stuff that's currently stuck in NEW, and not have to make too many uploads, but if it's too late for those to be included in etch, it would be good to at least have a meta-gnustep in etch that depends on the packages that do make it in.
--
Hubert Chan - email & Jabber: hubert@uhoreg.ca - http://www.uhoreg.ca/
PGP/GnuPG key: 1024D/124B61FA (Key available at wwwkeys.pgp.net)
Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA
Reply to: