Wednesday, 16 January 2019

supported-network-client review

Hi all,

tl;dr drop jigit, could consider neomutt instead of mutt

I was looking at where irssi came from, and found supported-network-client. Saw
jigit in it, decided to give it a short review.

(tagged OK/RM/?? for keep/remove/maybe)

$ cat supported-network-client | sed 's#^#> #'
> = Clients =
> * irssi

OK Having a text IRC client makes sense I guess, though it would not
be my choice :)

> * avahi-utils

OK Useful to debug avahi issues I guess.

> = Download =
> * jigit # specialised Debian/Ubuntu CD image download

RM I'm not sure there's much of a use anymore, so I'd say let's drop it.

> = Mail =
> * mutt

?? We _could_ switch to neomutt, which is more advanced, and was packaged
as mutt for some time. The code base started out the same, but got quite
refactoring done recently, and there is progress in adding multi-account
support. It would pull in (lib)notmuch, though.

> * lbdb

OK Never used that, but sounds interesting.

debian developer - | - free software dev
ubuntu core developer i speak de, en

ubuntu-devel mailing list
Modify settings or unsubscribe at:

Monday, 14 January 2019

Backports and a Proposal for Changing the Process


Back in November 2018 [1] and subsequent requests since [2] [3], I made several
attempts to reach out to the Backports team on public lists to volunteer my
time and energy to work on the Backports queue and to clear them out, and to
get more information on what the team requires for someone to help with the
backports process.

With no public responses to my messages, the third message [3] I sent included
direct messages to the admins.  I had received only one response off-list, and
it was suggested through there that:

 1. The backports process in general is broken.

 2. Putting the burden on a tiny number of admins to do checking and uploading
    does not scale to the volume of requests

 3. Given points #1 and #2 my request to assist was not likely to be actioned

It was also stated that because the current process is broken, it no longer is
capable of being considered a valid approach to backports.

In ongoing research into all backport requests currently in the queue including
for now-EOL releases (bugs in the Backports targets projects that have yet to
be closed or acted on at all), I have come to the following conclusions:

 1. That the current process is indeed broken for Backports, concurring with
 the private opinions provided to me.  (With some smaller exceptions for
 certain packages, such as cockpit as an example, where developers directly
 handle their own requests.)

 2. That the current process for backporting things is not feasible for
 scaling, also concurring with the private opinions provided to me.

 3. That the vast overwhelming majority of backports requests are made by
 mostly 'random users' or users who are not 100% familiar with requirements
 for backporting or package versions to be included (including build and
 testing requirements).

 4. That the vast majority of requests do not have ample justifications tied
 to them other than "I want this version available"

In separate discussions with interested parties and DMB members off-list and
in IRC discussions privately, it was suggested that if the current process is
broken, we need to redesign it.

I am proposing that we change the process and how it's handled in a substantial
way, redefining the requirements for Backports and the process to be more

This proposal makes some key changes to the processes, in that:

 1. It moves uploading of backports from the small backporters team to the
 larger developer body, and removes entirely the "Please backport xxx" class
 of requests.

 2. It will retain the Backporters team's ability to review backports, and
 ultimately approve backports so they can be moved from the Upload queue into
 the specific repositories, in a manner similar to how the SRU team processes
 the SRU queue, but further restricts the requirements to require dedicated
 Ubuntu Developer (Team or Individual) backing.

 3. This retains the Backporters' privilege of review before releasing things
 into the -backports repository, in a manner similar to how SRUs would behave.
 (This might require some retooling behind the scenes for the upload queue

While this proposal changes how things're delegated and handled, this also
handles the problem of "too many requests" - if a request can only move forward
with an individual or team backing it and they're an established developer,
that solves many of the problems that the current system has shown.  This also
means that the number of things that needs actual approval from the Backports
team is limited, as well as the fact that the 'random backport request' won't
go through if it's otherwise not getting support from an established developer.

Please also note that while this proposal touches base on how I would envision
the process to operate, I welcome *all opinions and refinements to this
proposal and process*, as I intend this to only be the 'beginning' of a more
refined proposal or process declaration for changing the Backports process.

The following is my proposal in detail:

Backporting Requirements

The uploading of backports is now to be performed by Ubuntu developers. The ~motu team
can upload any backport, and we will request the DMB to extend PPU rights to apply to
all backports pockets too.

 1) Developers file requests in the regular Ubuntu project, try their best to
 ensure that the backport is good (build/install/run test, post in the bug
 confirming this has been done), and upload it to the queue. The "Continued
 Functionality of Reverse-Dependencies" requirement from [0] is to be relaxed.
 Each and every reverse dependency need not be tested; the uploader should use
 their judgement, which the backports team will need to concur with. This requirement
 has been responsbile for making it practically impossible to backport anything complex.
 1.5) People who need sponsoring can perform step 1) and subscribe
 ~ubuntu-sponsors *once there is a debdiff/package on the bug to upload*.
 2) The ~ubuntu-backporters team reviews uploads from the queue and accepts/rejects,
 in much the same way as the SRU team does currently.
 3) Any changes to the package which are required for backporting must be minor
 in nature or otherwise required, and will be reviewed specifically by the
 Backporters Team prior to backport acceptance.

 4) A backport request must specify the SOURCE release to backport a package
 from and the TARGET release being backpoted to.

 5) Both SOURCE and TARGET releases must be a currently-supported release of
 Ubuntu.  Requests to backport to or from EOL releases will be rejected.


An additional point of discussion is that if we can remove 'random end user
requesting' from the equation, that would also lighten up the backports
queues. When an end user wants to make a request, they should field the
request via or a similar mailing list for
community input on the request; if a developer or sponsor wants to assist
for that request, then with the revisions to the process above, the backport
process can move forward without major impact to the queue and without
adding additional major stressors to the Backporters team, as those with
upload rights would already be able to do the 'upload' steps.


Opinions, alterations, recommendations, changes, etc. are all welcome, as I
stated I intend this to more or less spark further discussion rather than be
accepted currently verbatim.

I hope that this will ultimately lead to improving the Backports process, as it
currently is defunct for the most part and does not (and as it currently is,
will not) be able to continue to process new Backport requests without radical
changes to the process.

(Note that parts of this proposal have had contributions from Iain Lane,
Robie Basak, and Seth Arnold, at my request, prior to my submitting this,
in order to better phrase and construct this proposal in an acceptable manner.)

Thomas Ward
Ubuntu Server Team Member
LP: ~teward





Tuesday, 8 January 2019

Re: Edubuntu 16.04 and beyond

Hi there, im worry about edubuntu and things going it around, would like
to work on it cause i think it would be great to continue this huge
effort and add support for even working on raspis and other SBCs, i know
could be a huge task which is now in few shoulders, here is one you can
count :)


ubuntu-devel mailing list
Modify settings or unsubscribe at:

Saturday, 5 January 2019

Disco Dingo test rebuilds

The first test rebuild of Disco Dingo was started on December 21 2018 for
all architectures, all components. The number of build time failures
unfortunately is again high, even higher than for the last Cosmic Cuttlefish
test rebuild.

Results (please also look at the superseded builds) can be found at

The report uses some additional color coding, marking packages different which
always failed to build, or where the build failure is no regression compared to

Additional build failures for packages in disco-proposed (not yet in disco)
can be found at

Please help fixing the build failures.

There is also a test rebuild using an early version of GCC 9, which will become
the default compiler for the 19.10 release. Results at


ubuntu-devel mailing list
Modify settings or unsubscribe at:

Friday, 21 December 2018

Re: samba 4.9 in disco

Upstream provided a patch that fixes the issue. This is the MP to land
it in ubuntu disco:

On Tue, Dec 4, 2018 at 3:05 PM Andreas Hasenack <> wrote:
> Hi,
> I just wanted to email the list explaining why samba 4.9 is not yet in
> disco. It's also blocking the ldb migration.
> The samba DEP8 tests pass, but one of the triggered tests (freeipa)
> actually showed what we think is a valid bug, or at least significant
> change in behavior, in samba[1].
> Basically, in a fresh install, if you have winbind running, smbd won't
> start, even in standalone mode (not part of a domain). This happens in
> debian as well, fedora, and possibly suse. There are several mailing
> list threads[2,3,4] about it.
> The freeipa dep8 tests caught it by accident really. It's not even a
> failure in dep8 itself (the freeipa tests always exit 0, something
> else I found out), but in setting up the test vm. We can workaround
> that by just not installing the package that pulls in winbind. Freeipa
> doesn't need it. That's what this MP[5] proposes. That would let samba
> migrate, but the bug[1] will still have to be addressed.
> I think we should not migrate samba as-is until [1] is addressed, or
> at least until there is a plan on how to address it. I'm continuing
> the investigation, and I wanted to communicate that it's a known issue
> and it's being worked on.
> 1.
> 2.
> 3.
> 4.
> 5.

ubuntu-devel mailing list
Modify settings or unsubscribe at:

Wednesday, 19 December 2018

Re: Backports Queue is Huge - Officially Volunteering to Help

Due to lack of response, I am emailing you, the administrators of the Ubuntu Backporters team, as well as CCing ubuntu-devel with this message.

It has been several weeks since my inquiry via into whether there is an application process or requirement to be part of the Backporters team to assist with clearing out the backports queue, and that I am volunteering my time to directly contribute in the backports process and to help clear out the backports queue and clean it up.

So far, I have yet to receive a response.  Therefore, I am forwarding my requests and inquiries directly to you.

I would like to volunteer my time to assist with handling backports and helping to clear the backports queue, as well as work on documenting the Backports process in more detail as what documentation does exist is limited.

The queue for the Backport requests is fairly massive, some of which haven't even been looked at in a VERY long time, and are either obsolete or requesting backports from now-EOL releases which need to be redone from scratch.  As such, volunteering my time to the task of assisting with the backports process and to clean out the backports queue is something that I would very much like to be able to do.  (This said, I do not have proper access to move along the backports that pass, nor do I have the access to close or invalidate requests which cannot be acted upon due to EOL-release-statuses or due to the requests not being tested, or other types of conflicts).


On 12/6/18 10:44 AM, Thomas Ward wrote:

In case it wasn't clear, I am officially volunteering to assist with clearing out the backports queue.

I have been working with the Server Team specifically with NGINX since 2014, but I am well versed in Ubuntu policies and how package processes work, and would like to volunteer to be part of the backporters team to help clear out the pending backports queues.  This way, Backports can be seen as a potentially viable method of getting newer software features into older releases where SRUs are not a viable solutions.


On 11/29/18 12:07 PM, Thomas Ward wrote:

I took a look at the backports projects today, and the queues there.  The backports queues seem to be pretty siaable, and nobody's really taking the time to take a look at them (73 in Xenial backports, 11 in Bionic, 100+ in Trusty, etc.).

I haven't taken a look in-depth on the backport requests yet, but the key thing I am seeing is that all the backporters are otherwise occupied in working on other tasks.

If the problem is nobody is stepping up to volunteer to take a peek, the question then becomes is it just a lack of volunteers with the proper knowledge, or is it a lack of people wanting to take a look, or is it a lack of volunteers with the proper permissions to do the backports?  (I'd be willing to volunteer some of my time out of each week (probably weekends in my case) to poke at the backports queues if I were considered an acceptable member for the team)

It'd also be nice to see what requirements are needed to consider someone to be a backporter, the documentation on this seems nonexistent as does process documentation.


Tuesday, 18 December 2018

Re: Changing $PATH for apt installs

On Tue, Dec 04, 2018 at 09:46:25PM +0100, Julian Andres Klode wrote:
> Hi folks,
> I'm planning to have apt set PATH to a sane value for running
> dpkg, so that maintainer scripts are executed in a sanitized
> environment. That value will be:
> PATH=/usr/sbin:/usr/bin:/sbin:/bin
> The effect:
> (1) There is no /usr/local, which prevents breakage from custom perl
> or python installation
> (2) /snap/bin is not included either. This means that packages migrating
> to snaps will have to provide compatibility links (scripts?) in /usr
> - IIRC, lxd already does so, I'm not sure about other libraries.
> Together, this ensures that deb packages only talk to deb packages.

This just landed in Debian unstable, and should hit disco in the
next 24 hours or so.
debian developer - | - free software dev
ubuntu core developer i speak de, en

ubuntu-devel mailing list
Modify settings or unsubscribe at: