On 2013-10-22 08:05:08, Ian Jackson wrote: > retitle 727053 quilt fixup fails in dirty (built) trees > thanks > > So, thanks for your report. Looking at the git tree and the uploaded > files, I have repro'd what I think is at the root of your problem.
Great! > I think the error you must have originally had (which prevented your > non-dry-run push) was due to your working tree being dirty when you > ran dgit push. Specifically, git-buildpackage would have left the > build products, debhelper log, and so forth. Hummm... I am really not sure about this. I believe that git-buildpackage builds in a completely different directory, after git-export'ing the repository, so there shouldn't be any such cruft around... > A workaround would be to run debian/rules clean before dgit push. > Also, I think using one of dgit's build wrappers would have avoided > the problem. ... furthermore, I couldn't use dgit's build wrapper because I use a combination of pbuilder/cowbuilder with git-buildpackage to build packages in a sid chroot (still running this server in wheezy here). So those packages were not even built within the same environment, so I strongly doubt those files were present. > Nevertheless, I think this is suboptimal and I have therefore > developed what seems to be a fix. 0.16 will have it. Okay. It would have helped a lot if the error message would have been clearer - I couldn't even understand the diff presented: what it was diffing, or why, or why it was an error, or how to fix it. > Thanks for providing that repro recipe. Unfortunately it's not > entirely accurate because using --dry-run prevents dgit from doing its > usual quilt fixup step. That means that the messages you get are > expected but not very helpful. 0.16 will have a new --damp-run mode > which is willing to make local changes, which will naturally produce a > more accurate transcript when things aren't working. That's a great idea. > I'm just about to finish up and push 0.16. Sweet! > The results of your attempts to manually fix things up for > bugs-everywhere aren't ideal. I don't know if the clone will work > after your package comes out of NEW. Could you let me know when it is > out of NEW and I'll check ? I will do my best to remember this. > If it doesn't work, I'd appreciate it if you'd give me your blessing > to upload an empty NMU (that is, an NMU with only a version number > bump) using dgit. This will allow me to check that the change I have > made in dgit 0.16 actually fixes your problem in your workflow, and > also make sure that the dgit-repos and archive have corresponding > contents. If this is OK, please let me know what version number I > should use for the upload. I subscribe to the "LowNMU" policy, but even without that, you have my full blessing. I believe a -1.0 suffix would be fine. > Alternatively, if you plan to make another upload yourself, with dgit, > then if we're lucky that will work. Awesome, I will let you know in any case. I suspect the package may have trouble getting through NEW, mainly because I feel I may have overlooked some things in the package, so I may very well have to do that upload again. :) Thanks for the great and quick followup! A. -- Antoine Beaupré +++ Réseau Koumbit Networks +++ +1.514.387.6262 #208 --------------------------------------------------------------------
pgporblk3TuOX.pgp
Description: PGP signature
