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:
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':
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/
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.harrington@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/
