git-ubuntu build

Sat Jun 10 13:41:13 UTC 2023

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.harrington at 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 at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
>

-- 
Neal McBurnett                 http://neal.mcburnett.org/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20230610/beb5220b/attachment.html>