Sam Hartman wrote: > > Hi. Thanks for all your help with the binary NMUs and for analyzing > my plans and giving suggestions.
Hi Sam > I'm assuming there are some complications I don't know about it as > debian-release currently has a block on krb5. I guess that's only because it's not ready to migrate yet anyway. > There are also a few complications I do know about in the form of > things in testing that still depend on libkrb53. My preference would > be to allow libkrb53 to stay ing testing as a binary package. It has > no file overlaps with the libraries in the 1.7 packages; it simply > contains two libraries that are no longer part of the package and > depends on the packages that contain the retained libraries. So, as > far as I can tell, if krb5 and libauthen-krb5-admin-perl migrate from > unstable to testing and libkrb53 is retained in testing, nothing > breaks. > There are builds of these in unstable that do not depend on libkrb53. > However there are build problems preventing builds on all > architectures. I've put the corresponding bugs in Cc so we can hopefully get input on whether it's better to remove them from testing for now or a fix is pending. > Package: gtorrent-viewer > As best I can tell this is just broken in unstable. Right, an upload that fixes it would be appreciated. > Root-system is newer in testing than unstable and has RC bugs open for > a long time in unstable. Should this be fixed from testing for now? > Package: libzephyr3-krb > Package: zephyr-server-krb > > Zephyr's Kerberos support has been broken for a while in testing, so > breaking libzephyr3-krb and zephyr-server-krb's dependencies in > testing won't be a big deal. The code doesn't work. Zephyr is > uninstallable and unbuildable in unstable. The version in > experimental builds and installs but the maintainer does not believe > it works. The maintainer is aware of the situation and has taken over > upstream development of the package. Non-backward compatible protocol > changes will be required. So, this is already kind of broken, isn't > getting fixed soon, but is under control as best it can be with > limited time. So this should probably be removed from testing for now. > I think moving krb5 into testing when its 10 days are up (or > relatively soon) would be good. This is in part because after I > reverted the symbols file change as we discussed, packages in unstable > are beginning to stall behind krb5. Since I think we can move it into > testing without breaking anything I think it is desirable to do so. > On the other hand I'll certainly understand if you want to wait until > more dependencies go away from libkrb53. Well, it would indeed be better to have some more reverse dependencies transitioned to krb5. > Also, as I said, I don't understand how this interacts with other > transitions. If you do think it makes sense to wait more than 10 days > before trying to migrate krb5, please let me know. In that case I'll > upload something based off 1.7 instead of 1.7~beta3. As I mentioned > earlier, there are no code changes with that upload so there's no > particular desire to do that before a testing migration. I'm not sure how long it will take still, though uploading the new version should be fine as I expect to have at least one other sourceful upload for (one? of) the above packages. Cheers Luk -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
