On Fri, Jun 09, 2023 at 09:11:34PM -0700, Steve Langasek wrote: > On Wed, Jun 07, 2023 at 09:27:47PM -0700, Bryce Harrington wrote: > > On Wed, Jun 07, 2023 at 06:41:14PM -0700, Steve Langasek wrote: > > > It does not exist, actually! I recall we dropped it a few years ago, > > see see f2dc622e. > > $ git-ubuntu help > usage: git-ubuntu [-h] <command> ... > git-ubuntu: error: argument <command>: invalid choice: 'help' (choose from > 'build', 'build-source', 'import-local', 'import-ppa', 'lint', 'review', > 'clone', 'export-orig', 'import', 'importer-service-broker', > 'importer-service-poller', 'importer-service-worker', 'merge', > 'prepare-upload', 'queue', 'remote', 'submit', 'tag') > > ^^^^^ > $
Heh, that list is pretty out of date. build-source is gone, and I think review and lint are as well. There is still a 'build' module with some of the remaining code from the original build command, but you can see from the above commit that the hook for the command was removed. > > That said, though, I've wondered if 'build' may not necessarily be the > > ideal jargon, anyway. Since the (prepare-upload args) step can trigger > > a git push, and because this is done principly when uploading, it feels > > more like a submission-style workflow than a build; "build" also implies > > you're creating some form of artifact for local use, which in this case > > you're not, really. > > > So, I'd suggest that even though 'git-ubuntu build' is not used, you may > > still want to think more anyway about if there's a better term. > > Related commands: > > - dpkg-buildpackage > - debuild > - gbp buildpackage > - bzr builddeb > - sbuild > > So "build" is quite a strong theme in the existing tools. > > An interesting point, though, is that this makes me realize I would only > ever care about the sauce this provides when preparing a source package for > upload to Ubuntu, and not when I was trying to do a binary package build. > Another previous git-ubuntu subcommand was 'git-ubuntu build-source'. Do > you think that would be a better fit? That occurred to me too. We had subsumbed 'build-source' to 'build -S' since both commands used basically the same code just passing the -S along to the underlying tools. > I don't think 'submission-style' quite describes what I'm expecting to > achieve here. I might want to build a source package, then do a variety of > things with it before actually uploading it; e.g. run a debdiff against the > previous package to be sure it's actually a clean diff at that level, take > the source artifacts and do a test build, push to a ppa before pushing to > the Ubuntu archive, manually mangle the .changes file (rare, but I happen > to have just done this for a series of SRUs so that they would have complete > changelogs but not link to a whole list of unrelated bugs in the SRU > process), etc. And the target of the 'git push' may or may not be something > that we want to merge immediately, may or may not want to raise an MP for > immediately. Right, the point I was making there is that since the 'prepare-upload' step pushes the branch to Launchpad, I don't want or need to include that in my workflow until the end, after all that is done and I'm ready to do the .changes upload. Then I do one final debuild -S and run prepare-upload, verify it worked and check the .changes file has expected fields, and then I directly dput the .changes. I think of that as more of a submission-style procedure. But, there's more than one way to do this. I'm sure we all have unique workflows for how we prep source packages. Bryce -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
