Hi Hideki, On 23/10/19 7:01 pm, Hideki Yamane wrote: > Hi, > >> == Ruby 2.7/2.8 Transition == >> >> - 2.8 *might* be too late for Bullseye; >> - We're conducting a sprint when 2.7 has an RC (or preferably a stable) release by Dec 2019. > Maybe it'd be better to discuss Ruby upstream, and why don't you try to > package 2.7 before RC? https://github.com/ruby/ruby/blob/v2_7_0_preview2/NEWS I *think* this was the plan. To put 2.7 (maybe RC) in experimental and start the whole chain. I, personally, could wait for a stable release as well. But don't mind otherwise either. Also, I'd rather prefer more people to have a say in here; maybe Antonio has a better and a structured plan for it? >> - Using cme (libconfig-model editor) to refresh debian/* files; works well for other teams. > Could you tell more detail, please? Yep. So there's often some old versioning[1] and old formatting in d/control and (less often) in d/copyright. This can all be fixed and checked by: cme update dpkg-copyright (checks and updates missing copyrights of various files (though a manual check later should be done)). cme update dpkg-control (fixes d/control via api.ftp-master.debian). cme fix dpkg (to remove d/compat; bump Standards-Version and debhelper-compat; et al). >> == Use Salsa CI == >> >> - We discussed to use Salsa CI but don't know who's willing to go ahead with it and how? >> - Maybe this could be discussed over the next IRC meet or the sprint next year. > Just adding debian/salsa-ci.yml file with disabling arch-depend tests > is enough? I did add debian/salsa-ci.yml to all 1400 repositories (and broke salsa!). Maybe some new ones would be remaining. Also, gem2deb now adds salsa-ci.yml by default. So this is done. Yay! :D Best, Utkarsh --- [1]: For instance, let's say d/control of some package say that it's build depends on rails (> 2:4.0.0-1); Now, that's obsolete because even oldoldstable has 2:4.1.8-1+deb8u4. Thus making no sense and can be removed safely.
Attachment:
signature.asc
Description: OpenPGP digital signature