On Sun, 2010-05-23 at 21:30 +0800, Andrew Lee wrote: > What is the current situation/plan with lxde's transition to testing?
Apologies for not getting back to you sooner. We've recently (finally) managed to narrow down the location / cause of the issue but haven't yet found a solution. Feel free to skip some of the explanation below; it's partly to make sure the details are documented, and in case they provide anyone with any inspiration. To recap, britney believes that migrating the new lxde packages to testing would cause the tasksel-meta-faux package to become uninstallable; t-m-f is a fake package which is injected in to the i386 packages files processed by britney, to ensure that all packages listed by tasksel as "core" to any task remain installable. Unfortunately attempts to reproduce the problem by other methods, such as installing the involved packages in testing chroots or force-migrating the packages in a test britney run and running edos-debcheck on the resulting packages file have been unsuccessful. I've managed to produce a "minimal" test-case, in that using "lxde-core, gnome-desktop-environment" and ignoring the other packages normally in t-m-f causes the issue. Considering the co-installability of those two packages leads to a sufficiently high number of packages being considered that britney's dependency resolver aborts the test; I've tried increasing the limit, but so far only with the same result after a longer wait. As the order in which packages are considered can make a difference to the number of packages which need to be checked I've also been experimenting with "expanding" g-d-e to its component packages but have not yet found an ordering which works. Maintaining this in the longer term would also not be ideal, as the list is generated from tasksel's data files, which include g-d-e, and is not explicitly ordered. I've confirmed that forcing lxde in to testing appears to produce no issues other than the tasksel-meta-faux uninstallability; the problem is that by doing so we would lose the ability to detect any further issues with the co-installability of the package set, as they would not increase the count of problems in testing. This mail has ended up being somewhat longer than I'd intended, but hopefully it's useful. Regards, Adam -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1274986121.7995.1177.ca...@kaa.jungle.aubergine.my-net-space.net