Iain Lane: > Hey Niels, > > Thanks for the mail! > Hi Iain,
Thanks for your reply. :) > On Sun, Dec 30, 2018 at 07:13:00PM +0000, Niels Thykier wrote: >> Otherwise, check your britney configuration. If the path set for the >> "TESTING" configuration points to a standard APT mirror (with a Release >> file) you are unaffected by this mail. If it instead points to a file >> directory with some "Packages_X" files and a "Sources" file, you are >> using what I refer to as the "legacy package layout". > > In Ubuntu we use a legacy layout. Our b1 has a mode to assemble Packages > files for us: > > > https://bazaar.launchpad.net/~ubuntu-release/britney/britney1-ubuntu/view/head:/britney#L240 > > In short: > > - Concatenate main/universe/multiverse/restricted together. We have a > b2 modification¹ to enforce some additional restrictions on these > archive components, but at 'main' britney time we treat these the > same. Actually the b2 config doesn't mention these components at > all. > - ${SERIES}-proposed is a partial suite on top of ${SERIES}, so we > concatenate the Packages files together. (Same for ${SERIES}-updates > for the stable releases.) > Indeed, that looks very much like the legacy layout. But you do not use --control-files, which is great. :) > Do you know if the Release file handling that b2 currently has would > work for us? > There is one thing we need to to resolve and that is the partial suites. I thought you already had a patch for that in your fork (admittedly, solved in a more complicated way than I thought was necessary). Assuming that code works (commits being b144470 + 8fb3c78) you should be good to go. It would entirely remove the need for suite_arches plus pkg_lists in that britney script. However, you would need to: 1) convert to use the built-in handling of faux-packages and constraints. The hard part here is that you use ${unstable-version} a lot in FauxPackages so we might need to generate some additional support for that in britney2 and cherry-pick it. 2) Update the config a bit (that will be the trivial bit) to use the mirror directly and test it works. 3) Remove the legacy code and ARCHITECTURES config. Note: AFAICT, your fork already has the relevant code support the mirror layout including auto detection of ARCHITECTURES and COMPONENTS configuration from the Release file. On partial suites: I am happy to have better support for it in britney2 proper. We would need some test cases for it in britney2 or britney2-tests and then look at how we would solve it (I though we can do it easier than Colin Watson did - I still naively hope that it is simply a question of "not syncing removals" automatically). >> Request for info about your britney sources/configs/setups: >> ------------------------------------------------- >> We would very much like an updated list of links to your britney sources >> (e.g. forks/clones), configurations and setups. Our aim is to get a >> better understanding of what is out there and how you use britney. If >> you use britney to process data generated by other tools than the ones >> in use by Debian (like dak), it might be good to mention that as well. >> Please send this info to debian-release@lists.debian.org. > > b1: https://bazaar.launchpad.net/~ubuntu-release/britney/britney1-ubuntu > b2: https://code.launchpad.net/~ubuntu-release/britney/+git/britney2-ubuntu > > This template config is more or less up to date, but we have production > ones that are copies of this - sometimes the arches change between > releases, for example: > > https://git.launchpad.net/~ubuntu-release/britney/+git/britney2-ubuntu/tree/britney.conf > Thanks for those. :) > As you know, we badly need to rebase on a non-ancient britney. I got a > few commits rebased some time last year, but every single one was > conflicting so I eventually gave up. I'll try to find time to go again, > but this time I'll rebase *our* stuff on top of our fork point first to > reduce down to the minimal number of commits (and submit to you whatever > can be), which will make fewer commits to rebase but with bigger > conflicts... > > Cheers, > Apologies; we have not been making it easy. I know britney has seen a lot of refactoring/changes lately, which is not helping you in the short term but it has fixed (and will soon fix a few more) some long standing annoyances plus hopefully soon enable us to be (partially) vendor neutral in most of britney. Thanks, ~Niels
signature.asc
Description: OpenPGP digital signature
