Bug#720522: cannot NMU dgit using dgit
Joey Hess writes (Bug#720522: cannot NMU dgit using dgit): I have not actually tried to NMU dgit using dgit, but a look at the permissions of its git repository on dgit.debian.net leads me to believe this would fail. The repository is only writable by iwj:iwj. Yes, this is a bug. If dgit created that repository, it seems to need to be fixed to use more open permissions. Probably also passing --shared to git init --bare would be wise, to avoid some multi-writer git repository permissions gotchas. Yes. I have changed dgit to use a _template directory when creating new repos. That's in 0.8. I have also fixed up the existing repo (just the dgit.git for now). (If you'd like an NMU test of dgit, I'm happy to oblige, just send me a git patch to apply and upload..) Please go ahead, but into experimental. You will probably want to use 0.8 which I have just pushed. You should be able to make an empty NMU by just adding a debian/changelog entry. Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#720522: cannot NMU dgit using dgit
Ian Jackson wrote: Please go ahead, but into experimental. You will probably want to use 0.8 which I have just pushed. You should be able to make an empty NMU by just adding a debian/changelog entry. I did this successfully. However, my first build attempt failed because git-buildpackage wanted to be on an experimental branch rather than the sid branch dget clone set up. My next build failed because I ran dpkg-buildpackage in my usual way, which includes -I, and this excluded .gitignore from the tarball. The source consistency check then failed. So then I tried leaving -I off, but of course this included the whole .git directory in the tarball, which was clearly wrong. I then tried dgit build --git-ignore-branch. This built the right tarball, but I was a bit worried that dgit push might push to the sid branch, which I was currently on. I decided to go ahead with the push, on the basis that if I did something wrong you'd have a nice test case to fix in dgit.git. It seems to have done the right thing in the end. The rest of the push succeeded. Seems that some of this could be improved, but I don't know how, other than perhaps passing --git-ignore-branch to git-buildpackage by default. (Probably doesn't help that I have never bothered to learn git-buildpackage, since I considered it a fundamentally wrong approach to the problem, and insanely complicated for what it does. It is thus somewhat disconcerting to see it used in dgit..) -- see shy jo signature.asc Description: Digital signature
Bug#720522: cannot NMU dgit using dgit
Joey Hess writes (Re: Bug#720522: cannot NMU dgit using dgit): Ian Jackson wrote: Please go ahead, but into experimental. You will probably want to use 0.8 which I have just pushed. You should be able to make an empty NMU by just adding a debian/changelog entry. I did this successfully. However, my first build attempt failed because git-buildpackage wanted to be on an experimental branch rather than the sid branch dget clone set up. I guess this was using git-buildpackage directly ? dgit build would canonicalise experimental to sid and pass the result to git-buildpackage. My next build failed because I ran dpkg-buildpackage in my usual way, which includes -I, and this excluded .gitignore from the tarball. The source consistency check then failed. I guess this was dpkg-buildpackage directly. Yes, this is why I provided dgit build. So then I tried leaving -I off, but of course this included the whole .git directory in the tarball, which was clearly wrong. Yes. I then tried dgit build --git-ignore-branch. This built the right tarball, but I was a bit worried that dgit push might push to the sid branch, which I was currently on. I decided to go ahead with the push, on the basis that if I did something wrong you'd have a nice test case to fix in dgit.git. It seems to have done the right thing in the end. The rest of the push succeeded. Yes. It won't push to the wrong branch - it uses the value from the changelog, not the local git branch. Seems that some of this could be improved, but I don't know how, other than perhaps passing --git-ignore-branch to git-buildpackage by default. Perhaps that would be best. It would also avoid the need to try to canonicalise the suite name. (Probably doesn't help that I have never bothered to learn git-buildpackage, since I considered it a fundamentally wrong approach to the problem, and insanely complicated for what it does. It is thus somewhat disconcerting to see it used in dgit..) It's optional. If you use dgit sbuild it doesn't get used at all. dgit build uses git-buildpackage in a pretty simple mode. Maybe it would be best for it to just use dpkg-buildpackage directly now that dgit sbuild has much of the same infrastructure. Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#720522: cannot NMU dgit using dgit
Ian Jackson wrote: Joey Hess writes (Re: Bug#720522: cannot NMU dgit using dgit): Ian Jackson wrote: Please go ahead, but into experimental. You will probably want to use 0.8 which I have just pushed. You should be able to make an empty NMU by just adding a debian/changelog entry. I did this successfully. However, my first build attempt failed because git-buildpackage wanted to be on an experimental branch rather than the sid branch dget clone set up. I guess this was using git-buildpackage directly ? dgit build would canonicalise experimental to sid and pass the result to git-buildpackage. No, that was a straight dgit build. joey@gnu:~/tmp/dgit[sid]dgit build dh clean dh_testdir dh_auto_clean dh_clean gbp:error: You are not on branch 'dgit/experimental' but on 'dgit/sid' gbp:error: Use --git-ignore-branch to ignore or --git-debian-branch to set the branch name. git-buildpackage: failed command: git-buildpackage -us -uc --git-no-sign-tags '--git-builder=dpkg-buildpackage -i\\.git/ -I.git' '--git-debian-branch=dgit/experimental' dgit: subprocess failed with error exit status 1 My next build failed because I ran dpkg-buildpackage in my usual way, which includes -I, and this excluded .gitignore from the tarball. The source consistency check then failed. I guess this was dpkg-buildpackage directly. Yes, this is why I provided dgit build. Indeed. Although really it was a wrapper script I reflexively reach for, since it normally always works.. (Everything in that wrapper is obsoleted in one way or another by dgit though.) Seems that some of this could be improved, but I don't know how, other than perhaps passing --git-ignore-branch to git-buildpackage by default. Perhaps that would be best. It would also avoid the need to try to canonicalise the suite name. Seems like a win. (Probably doesn't help that I have never bothered to learn git-buildpackage, since I considered it a fundamentally wrong approach to the problem, and insanely complicated for what it does. It is thus somewhat disconcerting to see it used in dgit..) It's optional. If you use dgit sbuild it doesn't get used at all. dgit build uses git-buildpackage in a pretty simple mode. Maybe it would be best for it to just use dpkg-buildpackage directly now that dgit sbuild has much of the same infrastructure. My netbook doesn't have the grunt to run sbuild, but I think it's a fine alternative for many. I would be personally happier if dgit build ran as close to the dpkg-buildpackage bare metal as possible, since it would make the whole easier to understand. -- see shy jo signature.asc Description: Digital signature
Bug#720522: cannot NMU dgit using dgit
Joey Hess writes (Re: Bug#720522: cannot NMU dgit using dgit): Ian Jackson wrote: I guess this was using git-buildpackage directly ? dgit build would canonicalise experimental to sid and pass the result to git-buildpackage. No, that was a straight dgit build. Oh, sorry, I'm just being thick. Yes. My netbook doesn't have the grunt to run sbuild, but I think it's a fine alternative for many. I would be personally happier if dgit build ran as close to the dpkg-buildpackage bare metal as possible, since it would make the whole easier to understand. Right. Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#720522: cannot NMU dgit using dgit
Package: dgit Version: 0.2~0.1 Severity: normal I have not actually tried to NMU dgit using dgit, but a look at the permissions of its git repository on dgit.debian.net leads me to believe this would fail. The repository is only writable by iwj:iwj. If dgit created that repository, it seems to need to be fixed to use more open permissions. Probably also passing --shared to git init --bare would be wise, to avoid some multi-writer git repository permissions gotchas. (If you'd like an NMU test of dgit, I'm happy to oblige, just send me a git patch to apply and upload..) -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: i386 (i686) Kernel: Linux 3.10-2-686-pae (SMP w/2 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages dgit depends on: ii devscripts 2.13.2 ii dpkg-dev1.17.1 ii git [git-core] 1:1.8.4~rc2-1 ii git-core1:1.8.4~rc2-1 ii libdpkg-perl1.17.1 ii libwww-perl 6.05-1 ii perl5.14.2-21 Versions of packages dgit recommends: ii openssh-client [ssh-client] 1:6.2p2-6 dgit suggests no packages. -- no debconf information -- see shy jo signature.asc Description: Digital signature
