Friday, 15 January 2021

+1 Duty Report

Hi,
on this +1 Duty I was first looking for some things stuck in proposed that I'd
usually would not unblock, but still might have an advantage since they are
close to packages I often work with. From there I regularly checked excuses
for the usual identify test/build issues or add retry triggers.
But for the major efforts I wanted to try something else this time (last
time I was looking at plenty of low hanging fruits), so I picked a few that
seemed to become long debug-fests. Thereby this time the list isn't as long
as usual (also I got quite some NMI's), so I worked on:


#1 - GPSD dependencies
This came in as a sync from Debian and I've in the past worked on that for
Chrony. But being a sync the soname bump seems to have gone unnoticed. Sadly
some of the dependencies are of rather poor quality so it is almost expected
that they need some help.

I found some related issues about a new symbol that in the past got dropped
and now reintroduced with different arguments - fixed Debians .symbols file
for that.

Furthermore plenty of packages (since it is a transition that got fully synced)
blocked on this implicitly. There was a dependency chaing gpsd -> direwolf ->
hamlib -> 3 FTBFSes.
ppc64:
https://launchpad.net/ubuntu/+source/grig/0.8.1-3build1
https://launchpad.net/ubuntu/+source/qsstv/9.4.4-1build2
arm64

https://launchpad.net/ubuntu/+source/fldigi/4.1.14-1build1

Resolving these would unblock plenty of packages.
The "fix" if you want to call it that was easy, it seems those three builds
died in a hiccup on the 6th of January without a build log. A simple retry of
the builds got them working and with it plenty of other packages to migrate.

Another dependency of it around hamlib needed builds and tests but those
resolved just fine without further help. The next blocker it was entangled
with is src:mapnik that moved from 3.0 to 3.1. Several dependent packages
needed rebuilds - Locutus was faster on triggering those rebuilds.
But the transition now needed some cleanup of "old binaries left" which were
not automatically done, so I pinged ubuntu-AA about it.

Various small transitions are intertwined atm, this story continues below around
gstreamer, octave, gdal and a few others.


#2 dpdk-kmods
This is code that was once in DPDK but now is split into a separate package
by upstream. It also came in via a sync and first if all needed to be accepted
from hirsute-new so I started with some IRC pings.

After that everything else got resolved by time and it migrated into
hirsute-release.


# gst-plugins-bad blocks plenty of things

While skimming over excuses I found that a no change rebuild of
https://launchpad.net/ubuntu/+source/gst-plugins-bad1.0/1.18.2-1ubuntu2
had FTBFS on s390x and ppc64el.

In turn that blocked opencv, and that blocked digikam, gdal, ros-vision-opencv,
pytorch, actiona, .... TL;DR Plenty of (usually unwatched) packages that could
benefit from this being resolved.

The log first shows a red herring with a failing test, but that RC is ignored.
Later on and even more suspicious is dh_gstscancodecs which leads to a core
dump.

Those two are on identical source, but two months apart from each other.
https://launchpad.net/ubuntu/+source/gst-plugins-bad1.0/1.18.1-1ubuntu1/+build/20200835
https://launchpad.net/ubuntu/+source/gst-plugins-bad1.0/1.18.2-1ubuntu2/+build/20721799

I've tracked this down to one particular lib "libgstlv2.so" that was crashing
gst-codec-info-1.0 of pkg gstreamer-dev. At that time vorlon send a mail on his
+1 and he had looked at (and found) the same.

Locutus pinged me that he was looking at the case as well. At about the same
time we worked together and identified libsord 0.16.4-1 -> 0.16.6-1 to be the
critical update.
I compiled various sord from git and found it isn't the sord version, but the
toolchain. gcc-9 works all the time, while gcc-10 -O2 and higher break.
Further debugging showed that -fno-schedule-insns2 is enough to get it working.

That is small enough for a fix so I was prepping bugs and an upload to resolve
things for now.
=> https://bugs.launchpad.net/ubuntu/+source/gcc-10/+bug/1911142
=> https://gitlab.com/drobilla/sord/-/issues/1

Overall this is involved not only in gpsd, but also gdal and a bunch of
other transitions. Due to that I can't pretend to have done all of that alone -
plenty of people were involved turning knobs here and there. But eventually
things resolved \o/ and that is what matters.

=> https://launchpad.net/ubuntu/+source/sord/0.16.6-1ubuntu1
=> https://launchpad.net/ubuntu/+source/gst-plugins-bad1.0/1.18.2-1ubuntu2


# octave

This built fine
https://launchpad.net/ubuntu/+source/octave/6.1.1~hg.2020.12.27-3
But had autopkgtest regressions on all architectures
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-hirsute/hirsute/amd64/o/octave-parallel/20210108_160028_6467e@/log.gz
These tests belong to src:octave-parallel
It was already triggered by several people with custom triggers around other
octave-* things like:
octave/6.1.1~hg.2020.12.27-3 octave-parallel/4.0.0-2build1
octave-struct/1.0.16-8

Unfortunately if you just install things in hirsute or debian-sid the test
works fine. So much for debugging. But OTOH on autopkgtest.ubuntu.com it keeps
failing even with all-proposed.

Upgrading from manual tests to autopkgtest but in local VMs works for
hirsite as-is as well as hirsute-proposed and a selection of just
octave,octave-parallel,octave-struct.

Worth to note, on armhf this worked just fine on autopkgtest.u.c
The debugging of this went on and on - so I created a bug to track what I've
found to share it with other debuggers and be visible due to the update-excuse
tag.
=> https://bugs.launchpad.net/ubuntu/+source/octave-parallel/+bug/1911400

I had some fun debugging this and after some TIL and a long strange trip
it turned out to be rather easy. This is a lib for parallelization and
in the new version it fails on 1 vcpu - so it needs to be marked as big_package.
Nevertheless - since it is a regression from our POV - I also filed an
upstream bug about it.
=> https://savannah.gnu.org/bugs/index.php?59869
The MP to mark it as huge is here:
=> https://code.launchpad.net/~paelzer/autopkgtest-cloud/+git/autopkgtest-cloud/+merge/396300

After that was merged I did some custom triggers to get the set of packages
tested together as needed. And I checked the test log if they used the new
instance - they did and results finally went good unblocking many other things
that were indirectly linked.

Just when I thought things were happy I got told that a new dependency came in.
Thanks for shattering my hopes Rick :-P. This was an installability issue on
riscv64 between nheko/fmtlib which was taken care of by vorlon/Rik/Gianfranco
while it was nighttime for me. But this story seems to continue.
After that was resolved a new plasma-workspace joined the entanglement party.

But finally at the end of this week all of those bits moved in the next run
of britney. \o/


# dune-* FTFBS

A bunch of dune-* packages were blocked on one of them failing to build.
The reason was an unclear segfault that seemed to be flaky. I found that
Locutus has already uploaded a delta to "Reduce parallelism to 3 in arm64"
only to now have it fail on armhf and ppc64.

I didn't reach him, so I gave things a try in a PPA if that change would
help all architectures. But it still failed with that change (flaky, not 100%).

Rebuilds as-is fail (2/2) and lowering the parallel on all arch does not
fix armhf (which formerly built fine). This really seems to be a huge
flaky-fest or a situation that got worse with recent toolchains.

To crank it up a bit I was doing various other test builds but all of them
were flaky. In a discussion on #ubuntu-release the last theory was that
(other than retrying forever) using gcc-9 might help as it did in other cases.


... it feels like not that much as usual, but still progress being
made at least.
See you next week.


--
Christian Ehrhardt
Staff Engineer, Ubuntu Server
Canonical Ltd

--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Thursday, 14 January 2021

Re: Announcing the Ubuntu Metrics project, and calling for collaborators

read; good work :)

On Wed, Jan 13, 2021 at 6:00 PM Iain Lane <laney@ubuntu.com> wrote:
Hi all,

This is something I've been working on in the background for a few weeks
and I'm ready to ask for collaborators now.

We now have an instance of Grafana and InfluxDB available to the Ubuntu
project for the community to use to better track metrics about its work. 
It is available on the web at:

  https://ubuntu-release.kpi.ubuntu.com/

(there are currently two dashboards: a second one is for the *staging*
autopkgtest instance - "soon"™ to start learning about the production
one too)

I've written some initial collectors to grab some data to show everyone
what kinds of things can be done. Once there's more data being gathered
we can organise things into different dashboards in a way that makes
sense for your team.

Some things it might be useful to have

  - Bug statistics for groups of packages / packagesets / those
    subscribed to by a team
  - Number of CC / TB / release / archive team bugs which are waiting
    for action
  - Packages stalled in -proposed
  - Size of devel-proposed
  - Size / age of ISO images
  - Maybe something about the health of the community?
  - ...

Or I know some folks at Canonical have some of these things in internal
dashboards already, so maybe consider what can be moved over here.

The code is here:

  https://github.com/ubuntu/ubuntu-release-metrics/

and I'm keen to share access and review burden with—at least
initially—any Ubuntu Developer (~ubuntu-dev member) who wants to get
involved. Especially since I know I'm not the bestest Grafana wizard
around the place. 🙃

Let me know by private mail if you want to join the team, and also we
can use this thread to collect ideas.

Finally, thanks to Canonical IS for setting this all up for us to use,
and dealing patiently with me for the lengthy period where I didn't
really know what we wanted or what I was asking for/talking about. 😬💚

Cheers,

--
Iain Lane                                  [ iain@orangesquash.org.uk ]
Debian Developer                                   [ laney@debian.org ]
Ubuntu Developer                                   [ laney@ubuntu.com ]
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Wednesday, 13 January 2021

Re: helping golang-golang-x-sys to migrate

On Wed, Jan 13, 2021 at 07:56:38AM -0500, Reinhard Tartler wrote:
> Another week has passed, and the original issues seem to have been resolved
> by retrying. Thanks for everyone involved in that.
>
> In the mean time, a new test regression occurred at
> https://autopkgtest.ubuntu.com/packages/victoriametrics/hirsute/amd64, log
> can be seen at
> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-hirsute/hirsute/amd64/v/victoriametrics/20210107_084114_85c06@/log.gz
>
> 2021-01-07T08:40:46.015Z info VictoriaMetrics/lib/mergeset/table.go:203 table
> "/tmp/autopkgtest.a1SU4e/autopkgtest_tmp/_build/src/github.com/VictoriaMetrics/VictoriaMetrics/lib/storage/TestStorageRegisterMetricNamesConcurrent/indexdb/1657E67DA0CA2C97"
> has been opened in 0.002 seconds; partsCount: 0; blocksCount: 0,
> itemsCount: 0; sizeBytes: 0
> storage_test.go:699: unexpected error: error in SearchMetricNames:
> cannot search for tsids, since more than 2 concurrent searches are
> performed during -1610008847.000 secs; add more CPUs or reduce query
> load
> --- FAIL: TestStorageRegisterMetricNamesConcurrent (0.49s)
>
>
> I suppose the testsuite is running on a machine with only 2 CPUs and
> expects more ressources? I've retriggered the test but I'm concerned this
> excercise might be a waste of resources. Does anyone share this concern
> and/or has any thoughts on how to avoid this?

While the victoriametrics test passed in its latest run, its worth
mentioning that you can control the size of machine upon which the tests
are run[1] by updating the autopkgtest-cloud code.

[1] https://wiki.ubuntu.com/ProposedMigration#autopkgtests

Cheers,

Brian

> Best,
> -rt
>
> On Thu, Jan 7, 2021 at 11:31 AM Reinhard Tartler <siretart@gmail.com> wrote:
>
> > Cool, thanks.
> >
> > IT seems we have an additional failure now at
> > https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-hirsute/hirsute/amd64/v/victoriametrics/20210107_084114_85c06@/log.gz
> > -- the relevant part might be this one:
> >
> > 2021-01-07T08:40:46.015Z info VictoriaMetrics/lib/mergeset/table.go:203 table "/tmp/autopkgtest.a1SU4e/autopkgtest_tmp/_build/src/github.com/VictoriaMetrics/VictoriaMetrics/lib/storage/TestStorageRegisterMetricNamesConcurrent/indexdb/1657E67DA0CA2C97" has been opened in 0.002 seconds; partsCount: 0; blocksCount: 0, itemsCount: 0; sizeBytes: 0
> > storage_test.go:699: unexpected error: error in SearchMetricNames: cannot search for tsids, since more than 2 concurrent searches are performed during -1610008847.000 secs; add more CPUs or reduce query load
> > --- FAIL: TestStorageRegisterMetricNamesConcurrent (0.49s)
> >
> >
> > Maybe the test machine doesn't have enough CPUs for these tests? Can we
> > retry the failing tests on larger machines?
> >
> > -rt
> >
> > On Thu, Jan 7, 2021 at 3:32 AM Lukasz Zemczak <
> > lukasz.zemczak@canonical.com> wrote:
> >
> >> Hey Reinhard,
> >>
> >> I see that at least golang-github-canonical-go-dqlite seems like a
> >> good candidate to hint with a force-reset-test - I'll do that later
> >> today (as it only passed *once* in its whole testing history, so it's
> >> not a reliable testsuite).
> >> I have retried one of the failures there and will try seeing if the
> >> other failures make any sense.
> >>
> >> Cheers,
> >>
> >> On Sun, 3 Jan 2021 at 22:11, Reinhard Tartler <siretart@gmail.com> wrote:
> >> >
> >> > Hi folks,
> >> >
> >> > I couple of golang packages I care deeply about are stuck in
> >> hirsute-proposed due to autopkgtest failures that I had a hard time
> >> understanding. I've come to the conclusion that the problem must be related
> >> to
> >> https://people.canonical.com/~ubuntu-archive/proposed-migration/hirsute/update_excuses.html#golang-golang-x-sys
> >> >
> >> > It seems that there are regressions in the following packages:
> >> >
> >> > - golang-github-canonical-go-dqlite
> >> > - golang-github-lucas-clemente-quic-go
> >> > - golang-google-grpc
> >> >
> >> > I'm not familiar with those testsuites, but on the first look, there
> >> might be timing issues.
> >> >
> >> > I'd appreciate some thoughts/comments on helping golang-golang-x-sys
> >> migrate to hirsute.
> >> >
> >> > Thanks!
> >> >
> >> > --
> >> > regards,
> >> > Reinhard
> >> > --
> >> > ubuntu-devel mailing list
> >> > ubuntu-devel@lists.ubuntu.com
> >> > Modify settings or unsubscribe at:
> >> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
> >>
> >>
> >>
> >> --
> >> Łukasz 'sil2100' Zemczak
> >> Foundations Team
> >> lukasz.zemczak@canonical.com
> >> www.canonical.com
> >>
> >
> >
> > --
> > regards,
> > Reinhard
> >
>
>
> --
> regards,
> Reinhard

> --
> ubuntu-devel mailing list
> ubuntu-devel@lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

--
Brian Murray

--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: helping golang-golang-x-sys to migrate

Another week has passed, and the original issues seem to have been resolved by retrying. Thanks for everyone involved in that.


2021-01-07T08:40:46.015Z	info	VictoriaMetrics/lib/mergeset/table.go:203	table "/tmp/autopkgtest.a1SU4e/autopkgtest_tmp/_build/src/github.com/VictoriaMetrics/VictoriaMetrics/lib/storage/TestStorageRegisterMetricNamesConcurrent/indexdb/1657E67DA0CA2C97" has been opened in 0.002 seconds; partsCount: 0; blocksCount: 0, itemsCount: 0; sizeBytes: 0      storage_test.go:699: unexpected error: error in SearchMetricNames: cannot search for tsids, since more than 2 concurrent searches are performed during -1610008847.000 secs; add more CPUs or reduce query load  --- FAIL: TestStorageRegisterMetricNamesConcurrent (0.49s)  

I suppose the testsuite is running on a machine with only 2 CPUs and expects more ressources? I've retriggered the test but I'm concerned this excercise might be a waste of resources. Does anyone share this concern and/or has any thoughts on how to avoid this?

Best,
-rt

On Thu, Jan 7, 2021 at 11:31 AM Reinhard Tartler <siretart@gmail.com> wrote:
Cool, thanks.


2021-01-07T08:40:46.015Z	info	VictoriaMetrics/lib/mergeset/table.go:203	table "/tmp/autopkgtest.a1SU4e/autopkgtest_tmp/_build/src/github.com/VictoriaMetrics/VictoriaMetrics/lib/storage/TestStorageRegisterMetricNamesConcurrent/indexdb/1657E67DA0CA2C97" has been opened in 0.002 seconds; partsCount: 0; blocksCount: 0, itemsCount: 0; sizeBytes: 0      storage_test.go:699: unexpected error: error in SearchMetricNames: cannot search for tsids, since more than 2 concurrent searches are performed during -1610008847.000 secs; add more CPUs or reduce query load  --- FAIL: TestStorageRegisterMetricNamesConcurrent (0.49s)  

Maybe the test machine doesn't have enough CPUs for these tests? Can we retry the failing tests on larger machines?

-rt

On Thu, Jan 7, 2021 at 3:32 AM Lukasz Zemczak <lukasz.zemczak@canonical.com> wrote:
Hey Reinhard,

I see that at least golang-github-canonical-go-dqlite seems like a
good candidate to hint with a force-reset-test - I'll do that later
today (as it only passed *once* in its whole testing history, so it's
not a reliable testsuite).
I have retried one of the failures there and will try seeing if the
other failures make any sense.

Cheers,

On Sun, 3 Jan 2021 at 22:11, Reinhard Tartler <siretart@gmail.com> wrote:
>
> Hi folks,
>
> I couple of golang packages I care deeply about are stuck in hirsute-proposed due to autopkgtest failures that I had a hard time understanding. I've come to the conclusion that the problem must be related to https://people.canonical.com/~ubuntu-archive/proposed-migration/hirsute/update_excuses.html#golang-golang-x-sys
>
> It seems that there are regressions in the following packages:
>
> - golang-github-canonical-go-dqlite
> - golang-github-lucas-clemente-quic-go
> - golang-google-grpc
>
> I'm not familiar with those testsuites, but on the first look, there might be timing issues.
>
> I'd appreciate some thoughts/comments on helping golang-golang-x-sys migrate to hirsute.
>
> Thanks!
>
> --
> regards,
>     Reinhard
> --
> ubuntu-devel mailing list
> ubuntu-devel@lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel



--
Łukasz 'sil2100' Zemczak
 Foundations Team
 lukasz.zemczak@canonical.com
 www.canonical.com


--
regards,
    Reinhard


--
regards,
    Reinhard

Announcing the Ubuntu Metrics project, and calling for collaborators

Hi all,

This is something I've been working on in the background for a few weeks
and I'm ready to ask for collaborators now.

We now have an instance of Grafana and InfluxDB available to the Ubuntu
project for the community to use to better track metrics about its work.
It is available on the web at:

https://ubuntu-release.kpi.ubuntu.com/

(there are currently two dashboards: a second one is for the *staging*
autopkgtest instance - "soon"™ to start learning about the production
one too)

I've written some initial collectors to grab some data to show everyone
what kinds of things can be done. Once there's more data being gathered
we can organise things into different dashboards in a way that makes
sense for your team.

Some things it might be useful to have

- Bug statistics for groups of packages / packagesets / those
subscribed to by a team
- Number of CC / TB / release / archive team bugs which are waiting
for action
- Packages stalled in -proposed
- Size of devel-proposed
- Size / age of ISO images
- Maybe something about the health of the community?
- ...

Or I know some folks at Canonical have some of these things in internal
dashboards already, so maybe consider what can be moved over here.

The code is here:

https://github.com/ubuntu/ubuntu-release-metrics/

and I'm keen to share access and review burden with—at least
initially—any Ubuntu Developer (~ubuntu-dev member) who wants to get
involved. Especially since I know I'm not the bestest Grafana wizard
around the place. 🙃

Let me know by private mail if you want to join the team, and also we
can use this thread to collect ideas.

Finally, thanks to Canonical IS for setting this all up for us to use,
and dealing patiently with me for the lengthy period where I didn't
really know what we wanted or what I was asking for/talking about. 😬💚

Cheers,

--
Iain Lane [ iain@orangesquash.org.uk ]
Debian Developer [ laney@debian.org ]
Ubuntu Developer [ laney@ubuntu.com ]

Tuesday, 12 January 2021

Re: Fwd: Private home directories for hirsute onwards

Just to follow up on this thread - since there was no opposition to this
proposal, I have uploaded updated adduser and shadow packages to
hirsute-proposed to support setting the mode of home directories to 750
by default when they are created via either adduser or useradd.

Let me know if you encounter any significant issues :)

On Mon, 2020-11-30 at 16:54:08 +1030, Robie Basak wrote:

> Forwarding here in case there are Ubuntu developers who might want to
> comment but don't read the ubuntu-devel-discuss@ list.
>
> Since there's already a thread there, I suggest replying there if you
> want to reply to avoid splitting the discussion.
>
> There's also a cross-post to
> https://discourse.ubuntu.com/t/private-home-directories-for-ubuntu-21-04-onwards/19533
>
> HTH,
>
> Robie
>
> ----- Forwarded message from Alex Murray <alex.murray@canonical.com>
> -----
>
> Date: Thu, 26 Nov 2020 13:00:52 +1030
> From: Alex Murray <alex.murray@canonical.com>
> To: ubuntu-devel-discuss@lists.ubuntu.com
> Subject: Private home directories for hirsute onwards
> User-agent: mu4e 1.4.13; emacs 28.0.50
>
> Hi folks,
>
> After more than 14 years[1] of debate, I propose that it is time we
> moved ahead and stopped creating home directories as world-readable on
> Ubuntu for hirsute onwards. The old arguments from the bug referenced in
> [1] mainly centered on the convenience of this feature when considered
> in regards to a shared desktop machine with multiple user accounts
> wanting to easily share files with one-another. However, a lot of things
> have changed in the last 14 years, not least of which that Ubuntu has a
> significant customer and user-base in the public cloud and server
> space. For these users, there is generally 1 admin account and perhaps a
> number of less privileged worker accounts, and so world-readable home
> directories now present more like a footgun than a feature - in this
> case, if a worker account is compromised, an attacker could now more
> easily access sensitive data from the other worker accounts or the admin
> account. Whilst the Ubuntu Security team does a great job of staying on
> top of security updates and keeping the distro packages as secure as
> possible, there will always be instances[2] where for whatever reason
> machines are not kept up-to-date or weak passwords are used and so they
> become compromised. We should therefore be taking an approach to limit
> access in this unlikely event.
>
> The other part of the past argument for this was that knowledgeable
> users / sysadmins will be aware of this default and will change it if
> they deem necessary. Whilst I am sure that we do have many knowledgeable
> users, we have many more who simply are deploying Ubuntu to solve other
> tasks - and I think it goes against the usability proposition of Ubuntu
> in these cases to expect admins to make this change. Instead we can
> ensure these deployments limit the chance for sensitive information to
> be compromised by changing this default.
>
> It should be noted too that from a regression point-of-view, changing
> this default will also not affect any permissions on existing installs
> (if it was perhaps decided to SRU this change back to older releases) or
> on upgrades - only if new users are created will they then have these
> more restrictive permissions. By making this change now, this also gives
> 3 development releases and 2 interim releases to work through any
> unforseen issues etc before landing in an LTS release. Without some
> widespread testing it is not possible to know in advance all of the
> possible use-cases that have depended on this behaviour which may then
> have issues so I feel now is the time to make such a change so we can
> determine any appropriate work-arounds and associated documentation etc
> as needed.
>
> As such, for a concrete proposal, I suggest changing /etc/adduser.conf
> to specify DIR_MODE=0750 instead of the current DIR_MODE=0755 - this
> will ensure any users created via adduser have their home-directory
> non-readable and non-executable by others.
>
> In the case of useradd[3] (the low-level util) this is a bit trickier -
> whilst the documentation suggests we can set HOME_MODE in
> /etc/login.defs this does not appear to be respected and only if we set
> say UMASK=027 in /etc/login.defs and then create a user
> (useradd -m -d /home/test test) does the home dir have the expected
> permissions. However, modifying the default umask has other consequences
> so I am not suggesting we consider that at this point. So this will need
> some more investigation, for now I would like to focus on adduser as
> this is the documented approach for adding new Ubuntu users .
>
> If you want to try this yourself, you can simply:
>
>
> # ensure future users homes are safe
> sudo sed -i s/DIR_MODE=0755/DIR_MODE=0750/ /etc/adduser.conf
>
> # then get your own house in order
> chmod 750 $HOME
>
>
> In regards to things to watch out for, one use-case that I have come
> across myself is libvirt VMs where the disk image is stored in your home
> directory - these become unreadable now to the libvirt-qemu user and so
> you can't launch these anymore 🙁 - however, there is a simple fix for
> this 🙂 - you can use an ACL entry to re-enable this access for just the
> libvirt-qemu user:
>
> setfacl -m u:libvirt-qemu:rx $HOME
>
> (or you could just store your images under /var/lib/libvirt/images)
>
> I suspect this ACL approach may be needed for other common use-cases but
> like I said above this remains to be seen so any testing others could
> give of this would be really appreciated in helping to decide whether to
> try and proceed with this change.
>
> Finally, if there is a strong case for deployments who rely on the
> existing functionality (say universities etc) where having to manually
> roll-back the setting on each machine install would be painful, we could
> look at adding some functionality to the installer/preseed/whatnot to
> create initial users etc with the old permissions.
>
> Thanks for taking the time to read this - any constructive feedback is
> welcome.
>
> Thanks,
> Alex
>
>
>
> [1] https://bugs.launchpad.net/ubuntu/+source/adduser/+bug/48734
> [2]
> https://ruffell.nz/reverse-engineering/writeups/2020/10/27/analysis-of-the-dovecat-and-hy4-linux-malware.html
> [3] https://manpages.ubuntu.com/manpages/hirsute/en/man8/useradd.8.html
>
> --
> Ubuntu-devel-discuss mailing list
> Ubuntu-devel-discuss@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
>
> ----- End forwarded message -----


--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: +1 maint - phpunit 9 bootstrap proposal

On Tue, Jan 12, 2021 at 04:24:39PM -0800, Steve Langasek wrote:
> On Mon, Jan 11, 2021 at 08:48:15PM -0800, Bryce Harrington wrote:
> > phpunit has been stuck in a 8.5 -> 9.5 transition, which blocks other
> > things. I'd like to propose we back out 9.5 and bootstrap to 9.0, and
> > *then* to 9.5.
> >
> >
> > In looking at the phpunit builds on update_excuses, phpunit 9.5 fails to
> > build due to three of its dependencies, which themselves are failing to
> > build because they in turn have phpunit 9.x as build dependencies.
> > E.g.:
> >
> > phpunit unsatisfiable Build-Depends(-Arch) on amd64: php-codecoverage (>= 9)
> >
> > php-codecoverage 9.2.5+dfsg-2 shows "Missing build dependencies: phpunit (>= 9)"
> >
> > (Near as I can tell, the packages depend on phpunit only for
> > running the testsuite in debian/rules' override_dh_auto_test. The
> > packages don't appear to actually depend on any code from phpunit.)
> >
> > Debian did not jump straight from 8.5 to 9.5, but rather went through
> > the intermediate versions in Experimental. It looks like phpunit 9.0.0
> > might be new enough to satisfy various built requirements, without
> > having too intensive build requirements itself.
> >
> > RAOF suggested one option might be to do similarly - remove phpunit from
> > -proposed, stage the intermediary pieces in a PPA, and then
> > source+binary copy them into the archive. I've staged the pieces, with
> > their testsuites disabled, here:
> >
> > https://launchpad.net/~bryce/+archive/ubuntu/phpunit-bootstrap/+packages
>
> Thanks. Since it's not possible to tell as a non-owner whether a given ppa
> is suitable as a source for binary copies to the Ubuntu archive (and by
> default it isn't), I've used the packages here as a guide for replaying the
> bootstrap in the main archive. phpunit 9.x is now built in the main
> archive:
>
> https://launchpad.net/ubuntu/+source/phpunit/9.0.0-1build1
>
> and as soon as it publishes and php-phpspec-prophecy-phpunit +
> php-codecoverage have had a chance to rebuild, I believe I'll be able to
> copy back the newer synced packages to hirsute-proposed to let them all
> build.

Excellent!

Fwiw, I'm not sure if there might be some additional subsequent
bootstrapping needed between 9.0 and 9.5. Debian had several versions
of phpunit in experimental as they worked through rebuilding
dependencies. So far though, the bootstrapping has only required
bypassing testsuites of dependencies that pop up.

Note there is also one new package added, I unfortunately didn't note
the name and it's off update_excuses now, but it'll probably show up.
Since all this is in universe, I don't think that'll cause issues.

Bryce

--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel