Re: Preferred git branch structure when upstream moves from tarballs to git
> "Ansgar" == Ansgar writes:
Ansgar> On Fri, 2019-05-03 at 17:39 +0100, Ian Jackson wrote:
>> Ansgar writes ("Re: Preferred git branch structure when upstream
>> moves from tarballs to git"):
>> > On Fri, 2019-05-03 at 15:59 +0100, Ian Jackson wrote:
>> > > Ansgar writes ("Re: Preferred git branch structure when
>> upstream > > moves from tarballs to git"): > > > How do you
>> update the package to a new upstream release?
>> > >
>> > > The same way you would with whatever tools you are currently
>> > > using for > > that task. dgit is not a git delta management
>> tool. For the > > maintainer, dgit replaces dput, not gbp pq or
>> git-dpm or quilt.
>> >
>> > The question was to illustrate that dgit forces you to learn
>> about > branches, merging, ... There is no workflow with dgit
>> that doesn't > require this; when not using dgit, this isn't
>> required.
>>
>> This is so wrong it is very perplexing to me.
Ansgar> Yet you confirm exactly what I am saying...
I'm having a bit of trouble here and am hoping you can help us out.
Ian asked what git workflow it is that you're talking about where people
can deal with commit push and pull and don't need to know more.
I didn't see a clear answer to that.
Which debian packaging workflow do you believe has that property?
Re: Handling Japanese new era "令和 (Reiwa)"
On Tue, 9 Apr 2019 10:18:24 +0900 Hideki Yamane wrote: > I've noticed that Japan renews its era from 平成 (Heisei) to 令和 (Reiwa) > (U+32FF) at 1st May and it's necessary to update some packages to deal > with it. Status update... --- needs info --- * python - https://bugzilla.redhat.com/show_bug.cgi?id=1694518 --- not yet --- * openjdk-8: 8u212-b01-2 is NEW - https://ftp-master.debian.org/new/openjdk-8_8u212-b01-2.html - openjdk-8: Please update to 8u212-b03 to deal with Japanese New ERA "令和 (Reiwa)" https://bugs.debian.org/927857 * IME (Input Method Editor) - anthy: not yet * "Natural language processing" Japanese dictionaries - juman: not yet - ipadic: not yet - mecab-ipadic: not yet - mecab-jumandic: not yet - mecab-naist-jdic: not yet - naist-jdic not yet - unidic-mecab: not yet * poppler-data: upstream have not dealt with it yet --- done in experimental (= hard to go into buster) --- * icu: https://bugs.debian.org/927933 --- done in sid (= needs unblock) --- * unicode-data: fixed in unstable 12.1.0~pre1-2 - https://tracker.debian.org/news/1038353/accepted-unicode-data-1210pre1-1-source-all-into-experimental/ - https://tracker.debian.org/news/1038838/accepted-unicode-data-1210pre1-2-source-all-into-unstable/ + however, it causes some FTBFS and needs patches * fonts-ipaexfont: fixed in unstable 00401-1 - https://tracker.debian.org/news/1039012/accepted-fonts-ipaexfont-00401-1-source-into-unstable/ * openjdk-11: fixed in unstable 11.0.3+7-1 - https://tracker.debian.org/news/1038318/accepted-openjdk-11-11037-1-source-into-unstable/ --- done for buster --- * libreoffice: fixed in buster 1:6.1.5-3 and stretch-backports - https://tracker.debian.org/news/1037917/accepted-libreoffice-1615-3-source-into-unstable/ - https://tracker.debian.org/news/1038417/accepted-libreoffice-1615-3bpo91-source-into-stretch-backports-backports-policy-stretch-backports/ * mozc: fixed in buster 2.23.2815.102+dfsg-4 - https://tracker.debian.org/news/1038054/accepted-mozc-2232815102dfsg-4-source-amd64-all-into-unstable/ * ddskk: fixed in buster 16.2-7 - https://tracker.debian.org/news/1037952/accepted-ddskk-162-7-source-all-into-unstable/ * skkdic: fixed in buster 20190217-2 - https://tracker.debian.org/news/1037904/accepted-skkdic-20190217-2-source-all-into-unstable/ * glibc: fixed in unstable 2.28-9 - https://tracker.debian.org/news/1038848/accepted-glibc-228-9-source-into-unstable/ - unblock request: https://bugs.debian.org/928404 -- Regards, Hideki Yamane henrich @ debian.org/iijmio-mail.jp
Re: Preferred git branch structure when upstream moves from tarballs to git
Sam Hartman writes: > I'm having a bit of trouble here and am hoping you can help us out. > Ian asked what git workflow it is that you're talking about where people > can deal with commit push and pull and don't need to know more. > > I didn't see a clear answer to that. > Which debian packaging workflow do you believe has that property? There is no need for a vendor branch if only the packaging information is kept in the repository, i.e. only debian/. In particular there is no need for branches or merges for regular updates (i.e. not based on an older release). This is also what pretty much every other distribution seems to be doing, for example Fedora, Gentoo, Ports (BSD), Arch Linux, Void Linux. It would be easier if there was even more separation between packaging and upstream source, e.g. base/src (upstream source), base/debian (packaging information), and possibly other directories below base for build artifacts (instead of unpredictable locations under base/debian). Which leads back to the beginning of the subthread[1]. [1] https://lists.debian.org/debian-devel/2019/04/msg00462.html Ansgar
Re: Preferred git branch structure when upstream moves from tarballs to git
> "Ansgar" == Ansgar writes: Ansgar> Sam Hartman writes: >> I'm having a bit of trouble here and am hoping you can help us >> out. Ian asked what git workflow it is that you're talking about >> where people can deal with commit push and pull and don't need to >> know more. >> >> I didn't see a clear answer to that. Which debian packaging >> workflow do you believe has that property? Ansgar> There is no need for a vendor branch if only the packaging Ansgar> information is kept in the repository, i.e. only debian/. Ansgar> In particular there is no need for branches or merges for Ansgar> regular updates (i.e. not based on an older release). OK, I didn't hear that as an answer but think I'm coming to the same conclusion that Ian did after reading your mail. It sounds like you are talking about having the Debian packaging in a separate repository from upstream. Do I correctly understand the model you are talking about? I'm not trying to be dense here. I'm 85% sure I'm correct here but would like te bring that up to 100%
Re: Preferred git branch structure when upstream moves from tarballs to git
Sam Hartman writes: >> "Ansgar" == Ansgar writes: > > Ansgar> Sam Hartman writes: > >> I'm having a bit of trouble here and am hoping you can help us > >> out. Ian asked what git workflow it is that you're talking about > >> where people can deal with commit push and pull and don't need to > >> know more. > >> > >> I didn't see a clear answer to that. Which debian packaging > >> workflow do you believe has that property? > > Ansgar> There is no need for a vendor branch if only the packaging > Ansgar> information is kept in the repository, i.e. only debian/. > Ansgar> In particular there is no need for branches or merges for > Ansgar> regular updates (i.e. not based on an older release). > > OK, I didn't hear that as an answer but think I'm coming to the same > conclusion that Ian did after reading your mail. > It sounds like you are talking about having the Debian packaging in a > separate repository from upstream. > Do I correctly understand the model you are talking about? Sure. I'll point to [1] for what complexity this avoids. Try explaining that to someone without advanced Git knowledge... [1] https://manpages.debian.org/unstable/git-debrebase/git-debrebase.5.en.html Note that CVS already had a mechanism for tracking upstream releases (vendor branches); I'm not sure how widely they were used, but as far as I understand they were usually seen as advanced use of CVS. Git makes maintaining such vendor branches easier (better merging), and some workflows for Debian packaging result in trivial merges, but it is very confusing when something unexpected happens. Ansgar
