=== guiverc2 is now known as guiverc
seb128hum, does anyone here has experience migration a vcs from bzr to git which has tag names including '~' and ':' which are invalid to git and any hint how to deal with those?11:33
ginggsseb128: fwiw, the convention in debian is to transform ~ to _ and : to %11:56
Unit193Last time I did conversions, I used bzr-fastimport or whatnot, but a patched version or else bad things would happen.  It had an option to rewrite tag names I believe.  brz is the python3 version, but I don't believe those bugs were ever fixed...11:59
bdrungseb128, I converted a lot of bzr repositories to git recently.12:04
rbasakseb128: more details on the standard escaping scheme: https://dep-team.pages.debian.net/deps/dep14/12:11
seb128bdrung, ginggs, rbasak, thanks!12:29
seb128Unit193, I guess I will need to try that12:48
seb128bzr2git doesn't seem to handle the tags issue12:48
seb128WARNING: not creating tag b'refs/tags/1:102.9.0+build1-0ubuntu1' as its name would not be valid in git.12:49
bdrungseb128, maybe as workaround: add tags in bzr with the renamed charaters. Then convert.12:50
seb128bdrung, bzr fast-export has a '--rewrite-tag-names', I'm trying that12:51
seb128WARNING: tag b'refs/tags/1:102.9.0+build1-0ubuntu1' is exported as b'refs/tags/1_102.9.0+build1-0ubuntu1' to be valid in git.12:52
bdrungseb128, great!12:53
seb128Unit193, thanks, you don't have an updated version that applies to the current version by any chance? ;)13:03
Unit193Thankfully I haven't had to touch bzr in a few years.13:04
seb128Unit193, the issue was fixed in the bazaar ubuntu package but seems to have regresser in breezy, I ended up doing the import in a bionic container...14:37
seb128bdrung, bzr2git worked fine at the end, I just added --rewrite-tag-names to l115 of the script, I don't know if it's right in every case but it worked for thunderbird14:39
bdrungseb128, it's probably a good default for importing it into git15:02
vorlonrbasak: out of curiousity, what does git-ubuntu do if an initial upload of a package has its Vcs-Git* fields in .changes?15:30
vorlonrbasak: if I'm uploading a new package, maybe I want the rich history to be present from the beginning :-)15:31
rbasakI think it'll ignore it. I hadn't really covered that edge case, sorry.15:39
rbasakAlso, there's a bug that the import fails to push if there's only one upload. Sorry!15:40
-ubottu:#ubuntu-devel- Launchpad bug 2012626 in git-ubuntu "Importer fails to push when there's only one upload" [High, Triaged]15:40
rbasakIt's because then the changelog notes ref doesn't exist, because that's based on diff to previous.15:40
rbasakIt is definitely a bug that I need to fix, but a bit of a low priority.15:40
vorlonrbasak: ack :)16:25
bdrungrbasak, is that answer https://bugs.launchpad.net/ubuntu/+source/tzdata/+bug/2012599/comments/36 sufficient?16:39
-ubottu:#ubuntu-devel- Launchpad bug 2012599 in tzdata (Ubuntu Kinetic) "tzdata 2023a/2023b/2023c release - Egypt restoring DST" [Critical, Triaged]16:39
rbasakbdrung: the issue is that you're bundling changes in SRUs which, while they may be correct and appropriate to make in an SRU, effectively attempts to bypass SRU review because they're bundled as part of other changes, instead of having the opportunity for proper review, justification, and planning for QA as they would do in separate SRU bugs.16:48
rbasakeg. if the translations are wrong and you decided to fix them, then great, but then "Update debconf template and translations to 2023c-2" is *not* the appropriate way to describe that.16:49
bdrungrbasak, valid point that the explanation of the change isn't that well formulated.16:51
rbasakbdrung: every deliberate change that is visible to users should have its own referenced SRU bug with an SRU justification16:52
bdrungrbasak, and I should have put those in two lines. The "Update debconf template" is just by running the build.16:52
rbasak(but just running debconf-updatepo is fine without its own SRU bug of course. Just a note in debian/changelog as you did is fine)16:54
rbasakI'm sorry if that seems like a lot of work. But I don't think it's appropriate to make changes to stable releases without careful consideration of each change being reviewed by the SRU team. Using documentation in individual bugs is how we do that. That's how the policy stands today.16:55
rbasakWe do not try to fix every single bug in SRUs either - because it's a lot of work for two competent to have confidence and take reasonable steps to ensure we won't regress users. I think that's a reasonable position for us to take.16:56
rbasakfor two competent developers16:56
rbasakI have to EOD now. But I did just accept python-tz to Jammy and Kinetic - thank you for that!16:58
bdrungrbasak, would you be okay if I would open two more bug reports with the reasoning and reference them in the changelog or do you prefer to defer those regression fixed for another round of SRUs?17:00
bdrungsince these are IMO regression fixes of previous updates/SRUs.17:01
rbasakbdrung: I think that's up to you. It depends on SRU review of the justification of those separate fixes as to how long they'll take, I think.18:14
rbasakbdrung: I think SRU policy/procedure _requires_ separate bugs for separate fixes. But it's up to you what fixes you want to propose.18:14
rbasakbdrung: if you propose them, then we might discuss the details after review. But without seeing the justification and any discussion, the SRU team isn't in a position to make a decision.18:15
rbasakbdrung: I suppose if we want the SRU to land quickly, then it be better to defer them to a future round.18:25
rbasakAnd I need to spend more time on other things :-/18:25
Unit193seb128: Yeah, it was in universe so I had access to it. :D21:29

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!