OK, I'm stuck. This sounds great, and just the sort of thing I want to do as a casual Ubuntu-oriented developer, but I keep running into roadblocks, and can't find any documentation.
I google "git-ubuntu" and find nothing more recent and relevant than this 2017 article: Developing Ubuntu using git | Ubuntu https://ubuntu.com/blog/developing-ubuntu-using-git It doesn't lead me immediately to anything I can just run. Nor does wajig search git-ubuntu or ChatGPT-4 or this: $ git ubuntu git: 'ubuntu' is not a git command. See 'git --help'. Next I try ` git clone lp:git-ubuntu` and get ssh: Could not resolve hostname lp: Temporary failure in name resolution ChatGPT suggests that perhaps I meant this: $ git clone --verbose https://git.launchpad.net/git-ubuntu:git-ubuntu Cloning into 'git-ubuntu'... Username for 'https://git.launchpad.net': It seems odd there would be a need to authenticate, and my first attempts at using an Ubuntu SSO credential failed there. So how does a guy who's forgotten most of what he ever learned about launchpad, bzr and Ubuntu source management catch up? Finally, perhaps it would help to take the Ubuntu/Debian developer documentation and load it into some large language model for easier natural language search? Ala one of these: How to implement Q&A against your documentation with GPT3, embeddings and Datasette https://simonwillison.net/2023/Jan/13/semantic-search-answers/ How to customize LLMs like ChatGPT with your own data and documents - TechTalks https://bdtechtalks.com/2023/05/01/customize-chatgpt-llm-embeddings/ Cheers, Neal On Fri, Jun 9, 2023 at 11:24 PM Bryce Harrington < bryce.harring...@canonical.com> wrote: > 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 > -- Neal McBurnett http://neal.mcburnett.org/
-- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel