control: tags -1 -moreinfo control: tags -1 -unreproducible control: retitle -1 import-orig silently fails to commit debian/ on guitarix
Hi, On Wed, Nov 15, 2017 at 05:16:29PM +0100, Víctor Cuadrado Juan wrote: > > > On 15/11/17 17:00, Guido Günther wrote: > > Hi, > > On Wed, Nov 15, 2017 at 04:21:58PM +0100, Víctor Cuadrado Juan wrote: > >> > >> > >> On 15/11/17 15:53, Guido Günther wrote: > >>> Hi, > >>> On Wed, Nov 15, 2017 at 03:02:33PM +0100, Víctor Cuadrado Juan wrote: > >>>> > >>>> > >>>> On 14/11/17 22:47, Guido Günther wrote: > >>>>> Hi, > >>>>> > >>>>> This wired and I wouldn't expect uncommitted changes but since I don't > >>>>> know about your setup and what you're doing (the upstream repo > >>>>> e.g. already has the version you're trying to import) you'd have to > >>>>> provide better instructions to reproduce and tell me what you actually > >>>>> think is wrong. > >>>> With git-buildpackage 0.8.12.2 in Stretch, if I take Debian's guitarix up > >>>> until 0.35.6, I can do > >>>> > >>>> gbp --import-orig --uscan --merge-mode=replace > >>>> > >>>> and it will correctly import the new 0.36.0 upstream version, merge it > >>>> to master > >>>> and preserve the already existing contents at debian/*. > >>>> > >>>> With git-buildpackage 0.9.2 (today in Testing and Unstable), doing the > >>>> same > >>>> will overwrite the contents at debian/* with upstream sources, contrary > >>>> to > >>>> what --merge-mode=replace should do. > >>> > >>> That would be a grave bug. Can you still reproduce it? If so please send > >>> me the refs of the branches (master and upstream) before you run uscn so > >>> I can try to reproduce. > >>> > >>>> Sadly I wanted to keep working on guitarix and submit a new upload, so I > >>>> already committed 0.36.0 to the guitarix repo at > >>>> https://anonscm.debian.org/cgit/pkg-multimedia/guitarix.git/ . > >>>> > >>>>> Can you reproduce this with other packages? > >>>> > >>>> I tried to reproduce it with git-buildpackage 0.9.1 against python-pyo > >>>> and > >>>> lv2proc packages, and it worked fine. > >>>> > >>>> So if you see no problem on gbp output as said, feel free to close the > >>>> bug. > >>>> Maybe it was a fluke caused by several people working in guitarix's > >>>> repo. > >>> > >>> See above. Can you try to pass me the commits (or even better prepare a > >>> repo in the exact state) that I need to run gbp import-orig against? I > >>> tried several variants here but it always worked (as it did with the > >>> test run on the rest of the archive on my last sweep). Even the debian/ > >>> tree from your logs (c4a8a211261fc53b556732b1b724f938060d0135) is the > >>> same one that my invocation uses as is the parent commit on upstream. > >>> > >>> If you could provide more information on how to reproduce this that'd be > >>> great. If not let's close this for the moment. Should you hit that again > >>> please tar the _whole_ git repo and send me link so I can infer things > >>> from the reflog. > >>> > >>> Cheers, > >>> -- Guido > >>> > >> > >> I have taken https://anonscm.debian.org/cgit/pkg-multimedia/guitarix.git/ > >> and do `git reset --hard`, deleted tags and removed the debian remote to > >> have > >> it look as it was before importing upstream's 0.36.0, and I can > >> reproduce > > > > That's what I did yesterday. > > > >> the bug in it: > >> > >> git clone https://github.com/viccuad/example-bug-gbp && cd > >> example-bug-gbp > >> git fetch origin upstream:upstream pristine-tar:pristine-tar > >> gbp import-orig --pristine-tar --uscan --merge-mode=replace # or auto, > >> is the same > >> # notice that debian/* has changes to be committed > >> > >> I will delete that repo once this bug is closed/fixed. > > > > Thanks. But then again, same output as in my previous > > attempts. Everything looks fine. Is it possible that you're somehow > > picking old gbp code from a pip install or similar? What's in your > > gbp.conf? Can you make sure with "strace -e file -s2048 <command>" that > > the right gbp and git are being used? > > > > Cheers, > > -- Guido > > > > Sadly I keep reproducing it in a fresh Sid VM, with no gbp.conf > (see attached file with strace output). I can reproduce this now in a clean sid chroot. Thanks a lot! -- Guido
