bzr crashed when attempting to build a package for ppa

Bug #1897385 reported by Zakhar
18
This bug affects 4 people
Affects Status Importance Assigned to Milestone
bzr (Ubuntu)
Confirmed
Undecided
Unassigned

Bug Description

Hello,

No need to repeat here that the documentation to properly build a package is of appalling quality. That has been widely commented and is probably a major hurdle why people don't "package".

Sorry, so that being said, I am using the little documentation there is on those pages "Ubuntu packaging guide":

https://packaging.ubuntu.com/html/getting-set-up.html

Environment: On a fresh 20.04 I ran the command:

Steps to reproduce: (following the above documentation from a fresh 20.04)

sudo apt install gnupg pbuilder ubuntu-dev-tools apt-file

(Which pulled a gazillion packages... but ran successfully)

gpg and ssh keys steps where already done from 16.04 and the gpg key has been imported... this is anyway of no importance since the crash occurs much before we need that!

Then we move to page 4 of the documentation since this is for packaging "new software".

https://packaging.ubuntu.com/html/packaging-new-software.html

Now we install as instructed:

sudo apt-get install dh-make bzr-builddeb

Which successfully pulls another couple of packages.

Next step is to build a tar with all my files to compile. I use here the same commands that works fine with 16.04 and successfully produces a tar in /tmp/1fichierfs.tar

Then, as instructed I run:

bzr dh-make 1fichierfs 1.7.2~Focal /tmp/1fichierfs.tar

And immediately get a stacktrace:

$ bzr dh-make 1fichierfs 1.7.2~Focal /tmp/1fichierfs.tar
brz: ERROR: AttributeError: 'NoneType' object has no attribute 'initialize_on_transport'

Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/breezy/plugins/debian/dh_make.py", line 26, in _get_tree
    tree = workingtree.WorkingTree.open(".")
  File "/usr/lib/python3/dist-packages/breezy/workingtree.py", line 201, in open
    control = controldir.ControlDir.open(path, _unsupported=_unsupported)
  File "/usr/lib/python3/dist-packages/breezy/controldir.py", line 706, in open
    return klass.open_from_transport(t, probers=probers,
  File "/usr/lib/python3/dist-packages/breezy/controldir.py", line 736, in open_from_transport
    transport, format = _mod_transport.do_catching_redirections(
  File "/usr/lib/python3/dist-packages/breezy/transport/__init__.py", line 1613, in do_catching_redirections
    return action(transport)
  File "/usr/lib/python3/dist-packages/breezy/controldir.py", line 724, in find_format
    return transport, ControlDirFormat.find_format(transport,
  File "/usr/lib/python3/dist-packages/breezy/controldir.py", line 1166, in find_format
    raise errors.NotBranchError(path=transport.base)
breezy.errors.NotBranchError: Not a branch: "/tmp/build/".

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/breezy/plugins/debian/dh_make.py", line 37, in _get_tree
    a_controldir = controldir.ControlDir.open_from_transport(
  File "/usr/lib/python3/dist-packages/breezy/controldir.py", line 736, in open_from_transport
    transport, format = _mod_transport.do_catching_redirections(
  File "/usr/lib/python3/dist-packages/breezy/transport/__init__.py", line 1613, in do_catching_redirections
    return action(transport)
  File "/usr/lib/python3/dist-packages/breezy/controldir.py", line 724, in find_format
    return transport, ControlDirFormat.find_format(transport,
  File "/usr/lib/python3/dist-packages/breezy/controldir.py", line 1166, in find_format
    raise errors.NotBranchError(path=transport.base)
breezy.errors.NotBranchError: Not a branch: "/tmp/build/1fichierfs/".

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/breezy/commands.py", line 1016, in exception_to_return_code
    return the_callable(*args, **kwargs)
  File "/usr/lib/python3/dist-packages/breezy/commands.py", line 1202, in run_bzr
    ret = run(*run_argv)
  File "/usr/lib/python3/dist-packages/breezy/commands.py", line 759, in run_argv_aliases
    return self.run(**all_cmd_args)
  File "/usr/lib/python3/dist-packages/breezy/commands.py", line 784, in run
    return self._operation.run_simple(*args, **kwargs)
  File "/usr/lib/python3/dist-packages/breezy/cleanup.py", line 136, in run_simple
    return _do_with_cleanups(
  File "/usr/lib/python3/dist-packages/breezy/cleanup.py", line 166, in _do_with_cleanups
    result = func(*args, **kwargs)
  File "/usr/lib/python3/dist-packages/breezy/plugins/debian/cmds.py", line 1385, in run
    tree = dh_make.import_upstream(
  File "/usr/lib/python3/dist-packages/breezy/plugins/debian/dh_make.py", line 83, in import_upstream
    tree = _get_tree(package_name)
  File "/usr/lib/python3/dist-packages/breezy/plugins/debian/dh_make.py", line 42, in _get_tree
    branch = create_branch(to_transport.base,
  File "/usr/lib/python3/dist-packages/breezy/controldir.py", line 660, in create_branch_convenience
    controldir = klass.create(base, format, possible_transports)
  File "/usr/lib/python3/dist-packages/breezy/controldir.py", line 859, in create
    return format.initialize_on_transport(t)
AttributeError: 'NoneType' object has no attribute 'initialize_on_transport'

brz 3.0.2 on python 3.8.2 (Linux-5.4.0-48-generic-x86_64-with-glibc2.29)
arguments: ['/usr/bin/bzr', 'dh-make', '1fichierfs', '1.7.2~Focal',
    '/tmp/1fichierfs.tar']
plugins: bash_completion[3.0.2], changelog_merge[3.0.2],
    commitfromnews[3.0.2], cvs[3.0.2], darcs[3.0.2], debian[3.0.0],
    email[3.0.2], fastimport[3.0.2], launchpad[3.0.2], mtn[3.0.2],
    netrc_credential_store[3.0.2], news_merge[3.0.2], po_merge[3.0.2],
    propose[3.0.2], repodebug[3.0.2], stats[3.0.2], upload[3.0.2],
    weave_fmt[3.0.2]
encoding: 'utf-8', fsenc: 'utf-8', lang: 'fr_FR.UTF-8'

*** Bazaar has encountered an internal error. This probably indicates a
    bug in Bazaar. You can help us fix it by filing a bug report at
        https://bugs.launchpad.net/brz/+filebug
    including this traceback and a description of the problem.

------------------------

As if the poor quality of the documentation was not enough...

Fortunately it still works with my 16.04 and I could build (just to check it builds!) and upload the sources to my ppa where they built perfectly for Xenial/Bionic/Focal.

Unrelated to the current bug, the 16.04 commands fails the lintian step... which has the only consequence of having to wait for a "timeout" like 2 minutes. This is not an big issue anyway since the documentation is so bad, I have really no clue where to find leads to fix what Lintian is spitting at my face with the 18.04 iteration that works fine!

------------------------

This bud was probably automatically reported by apport, but I wanted to give you some context in the case that could help fixing things.

Attached a crash file about this bug.

Tags: bzr ppa
Revision history for this message
Zakhar (alainb06) wrote :
Revision history for this message
Zakhar (alainb06) wrote :

Hello, this report has stayed "undecided" / "unassigned" for 3 weeks now.

It makes the Ubuntu ppa documentation irrelevant: https://packaging.ubuntu.com/html/packaging-new-software.html

Was it the right place to post it or should I post it somewhere else, for instance "bzr developers"?

Revision history for this message
Andrei Miculita (andreimiculita) wrote :

Hello, as I see there is no way to go forward with that tutorial, and many people will probably end up here when following it, I was wondering if you've found any (3rd party) tutorial that actually works.

Revision history for this message
Zakhar (alainb06) wrote :

Hello Andrei, and thanks for your concern.

Unfortunately not, I didn't find any third party tutorial. This is an "official" one, not "community", since it is hosted on ubuntu.com, and tells us about ppa, which are a nice feature of Ubuntu.

I don't want to do a trial of intent here, but maybe Canonical is trying to kill ppa, same as they are killing .deb packaging in favour of snaps. IMHO this is a bad architectural choice!

I have no intention of doing a snap for my open source development. It is a fuse driver, and fuse is already slow enough having to cross boundaries between kernel and userland, I don't want to riddle it more with snap isolation (and I'm not even sure you can 'snap' such low level object).

I guess I'll have to do my own research to make it work again. The first bzr command fails :

bzr dh-make hello 2.10 hello-2.10.tar.gz

I am assuming it was creating the non existing bazaar repository from the tarball passed in the command. This feature may have been removed from bazaar, so I guess if I find how to do the same that should work.

For the ppa, in fact I don't need at all to build the .deb, it just builds in the process described by the tutoral so that you can check all goes well in the compile (make in my case). In fact you only need the signed source package (last commands) because for security reason, that is what you upload to the ppa that re-builds itself from source. But I guess you still need the bazaat repository to exist for that last command!

I do build debian packages for Raspberry Pi because there is no such thing as handy ppa, and I have a much simpler "tutorial"! But unfortuantely in the case of Raspberry Pi, either you trust I have not been a miscreant and take directly the .deb I offer, or you compile yourself from source. This is precisely what ppa avoid, and they also bring you auto upgrades with the rest of your system "for free".

So a question for bazaar guys: has the feature of creating a repository from a tarball been removed?.. The response might help "solving" the issue if there are now different options to pass.

Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in bzr (Ubuntu):
status: New → Confirmed
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.