+1 maintenance report

[Dan Bungert]

For +1 last week I focused on transitions + one other task.

= python3-launchpadlib (LP: #2050186) =
There was a report in IRC with a build log showing a dependency problem.
python-launchpadlib uploaded with an additional dependency declared on
python3-six.

= tinyxml2 =
Through no-change rebuilds this was largely resolved.  The packages outstanding
are ros-ros-comm and ros-diagnostics (which depends on ros-ros-comm).  There
was a lot of noise during this, such as time spent on kodi which turned out to
be a removal followed by adding it back to the archive the next day, but this
really was mostly just rebuilds once all the buttons were clicked.

== ros-ros-comm (LP: #2051585) ==
ros-ros-comm is complicated by usage of python concepts deprecated in py3.1 and
now finally removed.  This is made worse by the current state of py3.12, so
even testing changes here is something of a challenge.

I have a patch going for this, but with the testing challenges I don't yet know
if it is complete.  I am leaving the bug assigned to myself.

= hiredis =
Again, largely no-change rebuilds.  An interesting detail here is that the
timing of the last round of hiredis builds meant that ppc64el just narrowly
missed getting the new version of hiredis.
https://ubuntu-archive-team.ubuntu.com/transitions/html/auto-hiredis.html was
quite help in understanding these architecture differences that appear to just
have been rooted in the timing of the build.

== ntopng (LP: #2051300, LP: #2051302) ==
ntopng needed two bugs fixed:
* Fix FTBFS due to issue in coffeescript
* Fix FTBFS due to use of deprecated sphinx add_stylesheet
Upload done for that.

== ruby-hiredis (LP: #2051580) ==
This needs some help as well, and is not yet complete. Two unit tests are
failing now, test_nil / test_null_multi_bulk, and it's not clear to me why they
regressed.

-Dan

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

Re: Question to flavours: touch-base on flavour participation for 23.10!

[Dan Simmons]

Thanks for the message Graham. On behalf of the Lubuntu team we are a go 
for the 23.10 cycle.


Take Care.

Dan

On 5/3/23 11:11, Graham Inggs wrote:

Hello flavours!

As we do around the start of every new cycle, I am reaching out to all
the current official Ubuntu flavours to confirm active participation
in the upcoming Ubuntu release - 23.10.

Working towards a release requires a lot of effort, so we'd like to
make sure all the flavours are ready, properly staffed and have enough
time allocated to make 23.10 happen for their users. This is why,
similarly to last year, I will need a confirmation follow-up message
about Mantic Minotaur participation from every flavour, that is:

  * Edubuntu
  * Kubuntu
  * Lubuntu
  * Ubuntu Budgie
  * Ubuntu MATE
  * Ubuntu Unity
  * Ubuntucinnamon
  * Ubuntukylin
  * Ubuntustudio
  * Xubuntu

If you have any concerns regarding your participation, feel free to
reach out to me or anyone else from the ubuntu-release team.

Thank you!

Graham


--
@kc2bez:matrix.org
@kc2bez on Telegram
@kc2bez on libera.chat IRC

9150 77E7 6EFC 53F7 5CBC
6EB9 98D2 9485 5C5A 7872


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

Re: Question about submitting patches for repositories on Launchpad

[Dan Bungert]

On Thu, Mar 30, 2023 at 05:34:10PM +, Alexander Koskovich wrote:
> I submitted my patch to the 'master' branch since that looked to be active
> development, ubuntu/devel seemed abandoned.
> https://code.launchpad.net/~nexusprism/curtin/+git/curtin/+merge/439880

Hi Alexander,

Thanks for the merge proposal.  I have responded with some feedback, so we can
continue the discussion there.

-Dan

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

Re: Possibility of accepting a network-based installer of Ubuntu as an official flavor?

[Dan Bungert]

> > On Fri, 24 Feb 2023 at 04:54, Aaron Rainbolt  wrote:
> > > I've seen more than one person annoyed by the fact that the mini.iso
> > > netinstaller is no more.

> > > The "flavor" would be able to be held in a
> > > very small ISO file (preferably CD sized), and it would download and
> > > install all of the packages that make up the Ubuntu system at runtime.
> > > This would allow a user to install Ubuntu or any desired flavor thereof
> > > using a single installation medium, rather than having to flash an ISO
> > > every time they want to make a drive install a different flavor. The new
> > > installation would be entirely up-to-date from the get-go, and it would
> > > enable the use of existing small storage media for those users who don't
> > > have sufficiently sized optical discs or flash drives.

Hi Aaron,

As Lukasz mentioned, I've been looking at relevant things, and expect that we
can have the first version of ubuntu-mini-iso running this cycle.  I missed
feature freeze, so I'll be filing that exception :).

Lukasz wrote a perfect summary of the work so far, so I'll quote it here:
> > The ubuntu-mini-iso is a small bootable iso that can be either
> > downloaded and used on a CD/USB-drive or even via UEFI HTTP that
> > brings up a dynamic TUI menu of what Ubuntu images you want to
> > download/install to your target system. It uses simplestreams to
> > select which images, so it'll be quite customizable regarding the
> > selection. The difference is that it then downloads the
> > iso-of-interest into memory and chain-boots into it, allowing the
> > installation of any image as one would normally do. This has some
> > limitations of course, since it needs sufficiently enough RAM.

So I think that will address much of what you were aiming for.

Size: the bootleg builds I'm doing of this are around 140 MiB, I expect the
official builds to produce a similar answer.  It could potentially be smaller,
the size today is dominated by use of the existing Ubuntu initrd with a few
things added on top. (compare to the size of /boot/initrd.img)

Download at runtime: ubuntu-mini-iso achieves this by presenting a menu of ISOs
that we could download, then with the user selection, reserving some memory,
downloading that ISO, and then kexecing to it.

ISOs in the menu: there is a casper hook that downloads simplestream json data
and hands it to the menu application, a small ncurses app that analyzes the
json, finds what ISOs to offer, and does so.  The user chooses an entry from
the menu, that info is handed back to the casper scripts, which download it and
we chain boot.

That menu could be extended for Flavors support, perhaps conceptually similar
to how flavors are shown today on https://releases.ubuntu.com/.  The relevant
code is at: https://github.com/canonical/mini-iso-tools
It's not necessary to build an ISO to start playing with the menu, if you
download that, get the dependencies installed, `make run`, and you can see what
the menu looks like.

If you're interested to help, Aaron, a good starting point would be to add
entries to https://github.com/canonical/mini-iso-tools/blob/main/json.c#L27 to
teach the menu how to read the simplestreams for the flavors.

The existing menu can fit on a single screen, so if we start adding flavors I
think it will need some nested menu support, but that's achievable.

I have done a hacked test run of having this new mini-iso chainboot to lubuntu
22.04.2 and it all works fine.

-Dan

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

Updated parameter

[Dan Moore]

Team, 
I don't think a server OS should suspend when closing the laptop lid.  
I'd like /etc/systemd/logind.conf to have HandleLidSwitch=ignore in the Ubuntu 
Server installation media.  
Thanks, Dan-- 
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

+1 Maintenance Report

[Dan Bungert]

+1, week of Nov-14

Worked on universe packages affected by python3.11

# aiocoap #

fails with python 3.11
Package goes poking around the unittest.case._Outcome object, which was changed
in https://github.com/python/cpython/issues/75039

Sent upstream a workaround for the _Outcome problems.
https://github.com/chrysn/aiocoap/pull/289
And documented other test failures, which will need resolving for this package
to pass ADT.
https://github.com/chrysn/aiocoap/pull/290

# cloudpickle LP: #1996655 / debbug 1024205 #

* backported 2 commits to fix ADT failures.  Also needs python-psutil from
  proposed.
* Uploaded and forwarded to Debian, but this failed to build for other reasons
  as it is broken with python 3.11.0-3 but not 3.11.0-1
* Reuploaded with another backported commit for 3.11.0-3 compat.
* other packages need cloudpickle - dask, donfig

# device-tree-compiler LP: #1996949 / debbug 1015271 #

* Package needs update to handle the typical python version transitions
* dt-schema needs an updated device-tree-compiler providing the python 3.11
  version of _libfdt.

# diffoscope LP: #1996926 / debbug 1024335 #

* Reported test failure upstream

# django-assets LP: #1996828 / debbug 1024287 #

* Fails on some changes to the re module, apply a patch proposed upstream and
  uploaded and forwarded to Debian.

# python-clevercsv #

* Known failing upstream 
https://github.com/alan-turing-institute/CleverCSV/issues/74
* deepdiff needs clevercsv.

# retests #

* retested with extra triggers
  * abydos
  * aggdraw
  * pyerfa
  * astroalign
  * aplpy
  * augur
  * azure-kusto-python
  * billiart
  * bcolz
  * bottleneck
  * busco
  * cachelib
  * celery
  * citeproc-py
  * createrepo-c
  * cyvcf2
  * dasbus
  * dateparser
  * deap
  * dipy
  * django-simple-captcha
* retest
  * advocate
  * atropos
  * azure-uamqp-python
  * bitstruct
  * bolt
  * booth
  * brotli
  * cheetah
  * comitup
  * cython
  * djangorestframework-gis
  * dnarrange
  * dodgy
  * dolfin
  * dpdk

-Dan

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

+1 Maintenance Report

[Dan Bungert]

NBS says that ffmpeg still needs some help, so I mostly looked at that.

# aiscm (LP: #1989369) #

I have proposed this for removal.  Steve L did some work on this front, but it
needs a bit more upstream work and that hasn't happened yet.

# audacity (LP: #1983862) #

This is unfortunately in a pretty bad spot.  To complete ffmpeg 5 we need a
fixed Audacity.  Upstream just did the ffmpeg 5 relevant work recently, but
that change doesn't apply well to the current Audacity version.

Also, there was a bit of controversy around telemetry, enough to see some
community forks of Audacity started (they seem to have fizzled out).
Per https://github.com/audacity/audacity/discussions/889 upstream has indicated
an adjusted plan that is focused on error reporting and update checking, both
of which have cmake options available.  It would be prudent to verify the
telemetry claims.

While work has started to get the latest version of Audacity in Debian,
https://salsa.debian.org/multimedia-team/audacity/-/commit/5a547d41d23f22db517415c22d3e934fd132e0ce
clearly more is needed as that does not yet build on Sid, let alone Kinetic.
Erich Eickmeyer and I both spent some time nudging that build forward.
(https://salsa.debian.org/multimedia-team/audacity/-/merge_requests/1)

About the build failures, upstream was given a relevant bug during the Impish
timeframe. https://github.com/audacity/audacity/issues/2354

On the LP I've outlined some proposals about what to do next, but it seems that
removal is likely despite it's high-profile status.

# notcurses (LP: #1989390) #

v3.0.7 had a test failure on s390x, upstream already resolved that.
Cherry-pick that fix, upload, and notcurses has migrated, removing one more
from the FFMPEG NBS list.

# performous-composer (LP: #1989501) #

I worked on performous during my last +1, and had assumed at the time that this
was the same source package, but that is not the case.

Upstream bug filed, which was responded to within the hour.  performous and
performous-composer have some shared code history, so a merge of the relevant
changes may be feasible.
https://github.com/performous/composer/issues/45

# libdlna (LP: #1989616) #

This package was dropped from Debian a long time ago.  With no reverse depends
and upstream stating that "libldna development is currently discontinued", I
have recommended removal.

# qtav / matrix-mirage (LP: #1989613) #

"QtAV is no longer maintained" per
https://github.com/wang-bin/QtAV/blob/master/.github/ISSUE_TEMPLATE#L19

It does have a reverse dependency from matrix-mirage, which itself
pseudo-unmaintained.  Also, these packages are either Orphaned in Debian or on
their way.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1004628#16
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1013409

Please see the LP for a longer form answer, but I believe that removal is the
right choice.

# libde265 #

Simply needed a no-change rebuild to let the examples package pick up the new
libswscale6.  Migrated, removing one more from the FFMPEG NBS list.

# other ffmpeg stragglers #

* openscenegraph (LP: #1989620) - removed from Testing, needs non-trivial
  upstream work similar to other ffmpeg 5 changes
  https://github.com/openscenegraph/OpenSceneGraph/issues/
* libopenjfx-jni (LP: #1990019) - has dodged removal from Testing as of yet,
  same story of non-trival upstream changes needed

# kiwi vs kexec-tools (LP: #1988966) #

One binary package on kiwi needs a kexec-tools with risc-v support, and there
is a patch floating around, but my read on the mailing list comments suggested
that we didn't want the patch yet.  Instead I have elected to drop the risc-v
build of kiwi-dracut-oem-dump, which should be restored when kexec-tools risc-v
is in order.  Uploaded and migrated.

# dolfin vs fenics and mshr #

Local testing indicated that mshr needed a rebuild to match the dolfin upload.
No-change rebuild uploaded for mshr, which should resolve autopkgtests for both
mshr and fenics when triggered appropriately and allow dolfin to migrate.

-Dan

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

+1 maintenance report

[Dan Bungert]

I was on +1 this week.  I focused exclusively on the ffmpeg transition.
Thanks to William Wilson and Brian Murray for retest, rebuild, and sponsored
uploads.

# xpra (LP: #1982418) ##

Upstream had fixes for FFMPEG 5 compatability across a few commits.  Cherry
pick relevant stuff, upload by way of sponsor.  Patch forwarded to Debian.

# xmms2-plugin-avcodec (LP: #1982419) #

Upstream had a straightforward single commit.  Cherry pick, debdiff in sponsor
queue.  Patch forwarded to Debian.

# vtk7 (LP: #1982514) #

vtk7 is sadly quite behind upstream, and attempting to merge individual fixes
is not at all clear that it will be correct.  I did my work the same time Peter
Green was doing so for Debian, and came to the same conclusion.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1004793#23

Not entirely sure what to do next.  Simply grabbing the latest version of
ffmpeg-affected source files and dropping it into the codebase does build.

# unpaper (LP: #1982594) #

A newer version of unpaper is in the deferred queue currently and does build
for Kinetic and Sid.  I suggest we sync that, when available.

# shotdetect (LP: #1982598) #

The fixes for FFMPEG 5 look non-trivial and upstream doesn't have this
implemented yet.  No rdeps on shotdetect outside of a suggests on a
metapackage, possibly should remove shotdetect.

# retroarch (LP: #1982606) #

Upstream is quite active and the upstream version has a fix, but the changes
aren't even close to applying to the codebase in the archive.
"Fixed" by disabling FFMPEG usage.  Affected functionality listed
here: https://docs.libretro.com/library/ffmpeg/
Uploaded by way of sponsor.

# qtox #

Builds fine, fails in autopkgtest due to needing another package from proposed.
Moved onward with an extra trigger on chromaprint.

# pqiv (LP: #1982779) #

Just needed rebuild.  Upload by way of sponsor.

# performous (LP: #1982781, LP: #1982860) #

While there is a version in experimental, it isn't required to get this to
build with FFMPEG 5.  Cherry-picked a commit from upstream and extended it just
a little to get this buildinging.

Also needed a ppc64el fix
https://salsa.debian.org/games-team/performous/-/merge_requests/1

Uploaded by way of sponsor, patch for the FFMPEG part forwarded to Debian.

# motion (LP: #1982886) #

Backported commit, in sponsor queue, forwarded to Debian.

# minidlna (LP: #1982890) #

Just needs no change rebuild.  In sponsor queue.

# RISC-V rebuilds #

A few packages built fine, except for some temporary non-availability of the
new FFMPEG packages in proposed for RISC-V.  On rebuild they were fine.
* loudgain
* lynkeos.app
* mediastreamer2
* mgba
* moc
* mpv

# brief looks #

* mplayer - upstream 1.5 version has support for ffmpeg 5
* octave-video (LP: #1982875) Not able to find any work upstream on a
  transition.
* olive-editor (LP: #1982869) Upstream is focused on a new 0.2 version, which
  looks like it would be fine with FFMPEG 5.
* lives - Upstream is aware but a compatible version is not yet ready.
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1013421
* qtav (LP: #1982609) Upstream work started upstream on FFMPEG 5.
* openboard (LP: #1982784) Builds with upstream PR, which is not yet merged.
  At quick glance, PR looks similar to what other projects are doing.

-Dan

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

pytest-7

[Dan Bungert]

Hi ubuntu-devel,

I have opened LP: #1981475 requesting the sync of pytest 7 from Debian.
Doing so will add build failures for about 5% of the packages that depend on
pytest, and a few dozen more autopkgtest failures not already covered by failed
builds.

If anyone has concerns, please let me know.

I will require sponsorship for this, so if you're interested in assisting, that
would be appreciated.

https://bugs.launchpad.net/ubuntu/+source/pytest/+bug/1981475

Thanks!

-Dan

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

Re: systemd-oomd issues on desktop

[Dan Streetman]

On Fri, Jun 10, 2022 at 2:16 PM Sebastien Bacher  wrote:
>
> Le 09/06/2022 à 21:19, Dan Streetman a écrit :
> > Personally, I think this is the correct option. 1GB is not a good
> > default swap size.
>
> Did we ever consider doing the same than fedora is doing there?
>
> https://fedoraproject.org/wiki/Changes/SwapOnZRAM

compressed swap is generally good, when used lightly, and both zram
and zswap are good options, however each has significant downsides.
For zram, the downside is the unpredictability of pages that need to
be swapped, meaning some pages might be very poorly compressible; it
would be better to simply write out such pages to disk, but zram (when
acting as a swap device) isn't able to 'reject' poorly compressible
pages, which means the actual performance improvements of zram can be
highly variable depending on workload. Alternately zswap is able to
'reject' poorly compressible pages (i.e. let them get written to
disk), but the downside is you actually must have real disk swap
configured (because of how zswap is designed, using the 'frontswap'
hook); it can't do memory-only swap compression like zram.

One downside of both approaches (assuming a zram system also has
'fallback' real disk swap) is zram/zswap will fill up with swapped
pages (by design, obviously). If they get filled up (even partially)
with pages that really don't need to be accessed for a long time,
those compressed pages will stick around in memory, taking up space,
when it would have been better to simply write them out to disk. This
is particularly problematic once zram or zswap become 'full'. For
systems with *only* zram swap, this isn't an issue, since the only
options are 1) the page is in ram uncompressed or 2) the page is in
zram compresssed, which is why zram is particularly well suited to
embedded/iot systems without any disk swap.

The fedoraproject page there does lay out the comparison quite well,
but I'm not so sure enabling either by default for all users would be
appropriate. Also, I moved on from being an active zswap maintainer
years ago, so it's possible things have changed.

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

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

Re: systemd-oomd issues on desktop

[Dan Streetman]

On Fri, Jun 10, 2022 at 11:25 AM Steve Langasek
 wrote:
>
> On Fri, Jun 10, 2022 at 11:40:52AM +0200, Julian Andres Klode wrote:
> > On Thu, Jun 09, 2022 at 03:19:36PM -0400, Dan Streetman wrote:
>
> > > > I think that either option (1) or (3) would be the most reasonable --
> > > > maybe trying (1) first and falling back to (3) if necessary. If anyone
> > > > has an opinion on this, or can think of other options, I would
> > > > appreciate the input.
>
> > > Was systemd-oomd enabled by default for a specific reason? The kernel
> > > is quite able to handle oom situations itself, and has been for years,
> > > so while I'm not trying to suggest systemd-oomd is without any use
> > > case, I'm skeptical that systemd-oomd should be enabled *by default*.
> > > I think it's more likely to behave better when enabled to address a
> > > specific system use case, and leave the default behavior of handling
> > > oom to the kernel.
>
> > No what the kernel does is it starts stuttering, the system becomes
> > unresponsive and eventually needs a hard reset maybe.
>
> > The bug reports we see show that systemd-oomd is working correctly:
> > The browser gets killed, the system remains responsive without having
> > become unresponsive as would be the usual case.
>
> If systemd-oomd is killing in-use processes before the user is bothered by
> the sluggishness, then it's not working correctly.
>
> It's difficult to ensure the oom killer is working "correctly" given such a
> soft definition, but I agree that the increase in user complaints on 22.04
> indicate we haven't found the right balance yet.

I haven't looked at the details of how systemd-oomd works, exactly,
nor what the default config is, but I'd suggest the foundations team
take a close look at it from a perspective of what issue you want to
'fix' - if that issue is avoiding 'swap hell', then look at
systemd-oomd from the perspective of being able to detect high (and
'high' is a subjective term that will differ across systems),
sustained (another subjective term) swap reads and writes (and even
then, it's not always as simple as 'application X is causing heavy
swapping'). If the issue is avoiding actual ENOMEM errors, look at
systemd-oomd from the perspective of total free system memory (e.g. is
the system in direct reclaim?).

I have absolutely no doubt that systemd-oomd is better suited than the
kernel to handling oom conditions, when systemd-oomd is configured
properly for the system workload; I'm much more skeptical that
systemd-oomd can be generically configured to handle detecting "out of
memory" for any system workload if configured with generic defaults.

>
> --
> Steve Langasek   Give me a lever long enough and a Free OS
> Debian Developer   to set it on, and I can move the world.
> Ubuntu Developer   https://www.debian.org/
> slanga...@ubuntu.com vor...@debian.org
> --
> ubuntu-devel mailing list
> ubuntu-devel@lists.ubuntu.com
> Modify settings or unsubscribe at: 
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

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

Re: systemd-oomd issues on desktop

[Dan Streetman]

On Thu, Jun 9, 2022 at 4:05 PM Steve Langasek  wrote:
>
> On Thu, Jun 09, 2022 at 03:19:36PM -0400, Dan Streetman wrote:
> > > 4. Increase swap on Ubuntu. I am adding this for completeness, but I
> > > doubt this is a viable option.
>
> > Personally, I think this is the correct option. 1GB is not a good
> > default swap size.
>
> Could you elaborate why?  This default was arrived at some time ago with
> input from the kernel team regarding the fact that the kernel behaves best
> when it has some swap space but shouldn't necessarily have a lot.

Because swap isn't only used when there is pressure on anonymous
pages, and over time, anonymous pages from applications that don't
access all their memory often can wind up swapped out. The amount of
'useful' swap on a system is absolutely a function of the specific
system's workload as well as overall memory, so coming up with a
default that is 'best' for all systems is no easy task; however IMHO
using an absolute value (e.g. 1GB) is definitely not the 'best'
default; a percentage of total memory, or stepped values based on
system memory ranges (similar to how kdump calculates the amount of
memory to reserve for the kdump kernel) is almost certainly a better
approach.

For some background that might help, when the system experiences
'memory pressure' (in the context of performing swap), it only means
the number of free pages has fallen below the 'high' watermark. At
this point, kswapd is engaged to (in the background) start finding
ways to increase the number of free pages. It (mostly) does this is by
looking through *both* the pagecache as well as anonymous pages, and
attempts to find pages that it can free. The value of 'swappiness'
controls how much it attempts to find pages of each type; a value of
100 means kswapd will look equally at anonymous and pagecache pages,
while by default swappiness is 60, meaing kswapd will try harder to
evict pagecache pages than swapping anonymous pages.

What that means is that swap can be used up over time, even on a
system where there is never any memory pressure from anonymous pages.
As a simple example, setup a system with 1GB swap, and 16GB of ram,
then run:
$ stress-ng -m 1 --vm-bytes 12G --vm-hang 3600 &
( wait 20-30 seconds for the pages to be allocated )
$ sudo dd if=/dev/zero of=/randomfile bs=1024k count=12k
$ for i in {1..10}; do cat /randomfile > /dev/null ; free -h ; done

That will 1) allocate 12G of anonymous pages that the application
isn't using, 2) create a file larger than the remaining free memory,
and 3) cause memory pressure on the pagecache, which (over time)
causes the anonymous pages to get swapped out. Note that at no time
was there any anonymous page memory pressure - meaning, the amount of
anonymous pages was always multiple G lower than the total amount of
memory.

A quick test for me shows I'm able to fill up the entire 1GB of swap
in just a few runs:
   totalusedfree  shared  buff/cache   available
Mem:15Gi12Gi   170Mi   2.0Mi   3.3Gi   3.1Gi
Swap:  1.0Gi35Mi   988Mi
   totalusedfree  shared  buff/cache   available
Mem:15Gi12Gi   161Mi   2.0Mi   3.3Gi   3.1Gi
Swap:  1.0Gi39Mi   984Mi
   totalusedfree  shared  buff/cache   available
Mem:15Gi11Gi   147Mi   0.0Ki   3.8Gi   3.6Gi
Swap:  1.0Gi   519Mi   504Mi
   totalusedfree  shared  buff/cache   available
Mem:15Gi11Gi   158Mi   0.0Ki   4.2Gi   4.1Gi
Swap:  1.0Gi   1.0Gi  0B

Also note this *in no way* should be taken as a suggestion that
'swappiness' should be reduced; that is *absolutely* not what I'm
saying and would be a mistake to lower it (by default).

Also I think the discussion of default swap size is (almost)
completely separate from the discussion of systemd-oomd; I think the
current default is set so low that it it's aggravating systemd-oomd's
behavior, but I don't think increasing the default swap size is a
singular 'fix' for any/all issues with systemd-oomd.

>
> If we think 1GB is a wrong value, we should change it from 22.04.1
> forward...  but don't have a good way to automatically change the allocation
> for existing installs.  Fortunately, our use of swap files mean it's
> possible for the end user to non-destructively increase their swap space,
> but I wouldn't be comfortable with us doing this automatically as part of a
> release upgrade or in an SRU!
>
> --
> Steve Langasek   Give me a lever long enough and a Free OS
> Debian Developer   to set it on, and I can move the world.
> Ubuntu Developer   https://www.debian.org/
> sla

Re: systemd-oomd issues on desktop

[Dan Streetman]

On Thu, Jun 9, 2022 at 3:03 PM Nick Rosbrook
 wrote:
>
> Hi,
>
> During the 22.04 cycle, we enabled systemd-oomd [1] by default on
> desktop. Since then, there have been reports of systemd-oomd killing
> user applications too frequently (e.g. browsers, IDEs, and gnome-shell
> in some cases). In addition to a couple of LPs [2][3], I have heard
> these reports by word-of-mouth, and there have been discussions on
> internal Mattermost. A common theme in these reports is that e.g.
> Chrome is killed "suddenly" without any other observable symptoms of
> the system nearing OOM.
>
> For more context, systemd-oomd basically has two methods for deciding
> a unit's cgroup is a candidate for OOM kill:
>
> 1. When total system memory usage _and_ swap usage both exceed
> SwapUsedLimit (90% by default, and on Ubuntu) [4], monitored cgoups
> with greater than 5% swap usage become OOM kill candidates, and
> cgroups with the highest swap usage are acted on first.
>
> 2. When a unit's cgroup memory pressure exceeds MemoryPressureLimit
> [5] for at least MemoryPressureDurationSec [6], monitored descendant
> cgroups will be acted on starting from the ones with the most reclaim
> activity to the least reclaim activity.
>
> In the reports I refer to above, applications are being killed due to
> (1). In practice, the SwapUsedLimit might be too easy to reach on
> Ubuntu, largely because Ubuntu provides just 1GB of swap. Since we
> follow the suggestion of setting ManagedOOMSwap=kill on the root slice
> [7], every cgroup is eligible for swap kill. When this condition is
> met, user applications like browsers are going to be killed first.
>
> While investigating [2], we patched upstream systemd-oomd to fix how
> "used memory" was calculated, and we brought the patch into Jammy.
> This may have helped the situation a bit, but it does not appear this
> was enough to fix the issue entirely.
>
> Given the current situation, I think we should re-consider how
> systemd-oomd is configured on Ubuntu. These are the options that come
> to mind:
>
> 1. Increase SwapUsedLimit (again, currently at 90%). I think this is
> probably the safest change, but it is not clear to me how significant
> of an impact this would have.
>
> 2. Set ManagedOOMSwap more selectively. Again, we currently follow the
> recommendation of setting ManagedOOMSwap=kill on the root slice
> (-.slice), so every descendant cgroup is a candidate for swap kill. It
> _might_ be effective to say "do not swap kill cgroups descendant of
> user's app.slice". The downsides of this approach would be that the
> configuration does not scale well (i.e. a lot more configuration
> needed to get the proper swap kill "coverage"), and this may just
> place the problem onto a different class of processes.
>
> 3. Do not enable swap kill at all. This would mean systemd-oomd would
> only act when memory pressure limits are reached. Given Ubuntu's swap
> configuration, does it make sense for systemd-oomd to act on high swap
> usage?
>
> 4. Increase swap on Ubuntu. I am adding this for completeness, but I
> doubt this is a viable option.

Personally, I think this is the correct option. 1GB is not a good
default swap size.

>
> I think that either option (1) or (3) would be the most reasonable --
> maybe trying (1) first and falling back to (3) if necessary. If anyone
> has an opinion on this, or can think of other options, I would
> appreciate the input.

Was systemd-oomd enabled by default for a specific reason? The kernel
is quite able to handle oom situations itself, and has been for years,
so while I'm not trying to suggest systemd-oomd is without any use
case, I'm skeptical that systemd-oomd should be enabled *by default*.
I think it's more likely to behave better when enabled to address a
specific system use case, and leave the default behavior of handling
oom to the kernel.

>
> Thanks,
>
> Nick 'enr0n' Rosbrook
>
> [1] https://www.freedesktop.org/software/systemd/man/systemd-oomd.service.html
> [2] https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1966381
> [3] https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1972159
> [4] 
> https://www.freedesktop.org/software/systemd/man/oomd.conf.html#SwapUsedLimit=
> [5] 
> https://www.freedesktop.org/software/systemd/man/oomd.conf.html#DefaultMemoryPressureLimit=
> [6] 
> https://www.freedesktop.org/software/systemd/man/oomd.conf.html#DefaultMemoryPressureDurationSec=
> [7] 
> https://www.freedesktop.org/software/systemd/man/systemd-oomd.service.html#Usage%20Recommendations
>
> --
> ubuntu-devel mailing list
> ubuntu-devel@lists.ubuntu.com
> Modify settings or unsubscribe at: 
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

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

Re: Bileto

[Dan Streetman]

On Mon, Jun 6, 2022 at 5:18 PM Sergio Durigan Junior
 wrote:
>
> On Thursday, June 02 2022, Dan Streetman wrote:
>
> > How do I get access to bileto? Everyone in canonical product engineering
> > seems to use this system but I've never had access. Is it restricted to
> > only some canonical employees?
>
> Hey Dan,
>
> I remember gaining access to bileto automatically when I became a Core
> Dev.  I didn't have to ask permission to anyone.

Looking at the LP team that (I think?) controls Bileto access, i.e.
~bileto-users, I appear to be already in that team...which I never
realized. However, I've even if I do magically have access to use
Bileto, I never knew that, and I still don't know how I can actually
'use' (i.e. upload anything to) it...

is there some docs on how to 'use' bileto?

>
> Cheers,
>
> --
> Sergio
> GPG key ID: E92F D0B3 6B14 F1F4 D8E0  EB2F 106D A1C8 C3CB BF14

-- 
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

Bileto

[Dan Streetman]

How do I get access to bileto? Everyone in canonical product engineering
seems to use this system but I've never had access. Is it restricted to
only some canonical employees?

Thanks!
-- 
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

Re: isc-dhcp: should we start phasing it out?

[Dan Streetman]

On Tue, May 24, 2022 at 5:06 AM Dimitri John Ledkov
 wrote:
>
> On Mon, 16 May 2022 at 20:22, Dan Streetman  wrote:
> >
> > On Mon, May 16, 2022 at 3:06 PM Steve Langasek
> >  wrote:
> > >
> > > Hi Andreas,
> > >
> > > On Mon, May 16, 2022 at 02:34:30PM -0300, Andreas Hasenack wrote:
> > > > Alternatives that come to mind are:
> > > > - kea, of course (from ISC). dhcp server only.
> > > > - dnsmasq (for small installations?), also server
> > > > - systemd-networkd itself obviously does the client part
> > > > - others?
> > >
> > > > isc-dhcp is such a classic that it is undoubtedly referenced in many
> > > > places, so phasing it out might be difficult. On the server, Kea is
> > > > not a drop-in replacement.
> > >
> > > As I mentioned at
> > > <https://lists.debian.org/debian-devel/2022/05/msg00047.html>, isc-dhcp is
> > > no longer used out of the box as the DHCP client in Ubuntu, on either
> > > desktop or server; server uses systemd-networkd's internal dhcp client
> > > implementation, and desktop uses NetworkManager's.
> >
> > There are still users of 'dhclient', especially in some cloud environments.
> >
> > I suspect there will be a demand for it until someone updates systemd
> > to be able to replace its functionality, with something like:
> >
> > $ networkctl dhclient eth0
> >
> > That would require an upstream discussion to figure out the exact
> > usage and implement it, of course.
>
> $ sudo netplan set ethernets.eth0.dhcp4=true; sudo netplan apply

that's permanent, though. I think the use case (at least a significant
amount, if not majority amount) is for transient dhcp on an interface.
For example, I want to run dhcp on eth1 but I don't want that happen
next boot, just temporarily right now.

>
> Maybe we want to add `--apply` flag.
>
> A networkctl command that creates an ephemeral .network file in /run
> and reconfigures the link might be ok as well, similar to what
> systemd-run does. But I very much prefer netplan.
>
> >
> > > The only reason that
> > > isc-dhcp is still installed by default is for the initramfs: because we
> > > support nfsroot, iscsi, remote disk unlock via dropbear, etc.
> > >
> > > Several suggestions of path forward on support for dhcp in the initramfs, 
> > > in
> > > no particular order:
> > >
> > >  - work with klibc upstream to extend ipconfig to be a suitable DHCP 
> > > client
> > >for the initramfs (requires DHCP support)
> > >
> > >  - migrate to a systemd-based initramfs everywhere, and use 
> > > systemd-networkd
> > >
>
> We already have some netplan compatibility in our initramfs. At one
> point I was experimenting to add full netplan & networkd to the
> initramfs, but that side project stalled.
>
> The largest chunks of work to switch to systemd-based initramfs would
> be migrating installer initramfs features (casper &
> cloud-initramfs-tools).
>
> --
> okurrr,
>
> Dimitri
>
> > >  - Repackage isc-dhcp to provide an 'isc-dhcp-initramfs' package that no
> > >longer provides integration with the main system, so that it can 
> > > continue
> > >to be used for initramfs without having a large ongoing support surface
> > >(but, this doesn't remove the need for security support)
> > >
> > >
> > > > We also have the udebs, but with subiquity being the installer now we
> > > > probably don't need to worry about these anymore?
> > >
> > > We definitely don't need to worry about udebs in future Ubuntu releases;
> > > they aren't even built in Launchpad in the current series.
> > >
> > > > rdeps at 
> > > > https://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.kinetic/rdepends/isc-dhcp/
> > >
> > > > Removing isc-dhcp would also allow us to reduce the need of old compat
> > > > src:bind9-libs package, probably even drop it.
> > >
> > > Ugh
> > >
> > > > Could we perhaps start with phasing out the client, get its rdeps to
> > > > use alternatives, and then stop building it, and eventually get to the
> > > > server? This could be a lot of work, as I said, isc-dhcp is a classic,
> > > > but if upstream is shifting its focus elsewhere, soon we will be
> > > > alone.
> > >
> > > I think you'll find that phasing out the client is much more work than
> > >

Re: isc-dhcp: should we start phasing it out?

[Dan Streetman]

On Mon, May 16, 2022 at 3:06 PM Steve Langasek
 wrote:
>
> Hi Andreas,
>
> On Mon, May 16, 2022 at 02:34:30PM -0300, Andreas Hasenack wrote:
> > Alternatives that come to mind are:
> > - kea, of course (from ISC). dhcp server only.
> > - dnsmasq (for small installations?), also server
> > - systemd-networkd itself obviously does the client part
> > - others?
>
> > isc-dhcp is such a classic that it is undoubtedly referenced in many
> > places, so phasing it out might be difficult. On the server, Kea is
> > not a drop-in replacement.
>
> As I mentioned at
> , isc-dhcp is
> no longer used out of the box as the DHCP client in Ubuntu, on either
> desktop or server; server uses systemd-networkd's internal dhcp client
> implementation, and desktop uses NetworkManager's.

There are still users of 'dhclient', especially in some cloud environments.

I suspect there will be a demand for it until someone updates systemd
to be able to replace its functionality, with something like:

$ networkctl dhclient eth0

That would require an upstream discussion to figure out the exact
usage and implement it, of course.

> The only reason that
> isc-dhcp is still installed by default is for the initramfs: because we
> support nfsroot, iscsi, remote disk unlock via dropbear, etc.
>
> Several suggestions of path forward on support for dhcp in the initramfs, in
> no particular order:
>
>  - work with klibc upstream to extend ipconfig to be a suitable DHCP client
>for the initramfs (requires DHCP support)
>
>  - migrate to a systemd-based initramfs everywhere, and use systemd-networkd
>
>  - Repackage isc-dhcp to provide an 'isc-dhcp-initramfs' package that no
>longer provides integration with the main system, so that it can continue
>to be used for initramfs without having a large ongoing support surface
>(but, this doesn't remove the need for security support)
>
>
> > We also have the udebs, but with subiquity being the installer now we
> > probably don't need to worry about these anymore?
>
> We definitely don't need to worry about udebs in future Ubuntu releases;
> they aren't even built in Launchpad in the current series.
>
> > rdeps at 
> > https://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.kinetic/rdepends/isc-dhcp/
>
> > Removing isc-dhcp would also allow us to reduce the need of old compat
> > src:bind9-libs package, probably even drop it.
>
> Ugh
>
> > Could we perhaps start with phasing out the client, get its rdeps to
> > use alternatives, and then stop building it, and eventually get to the
> > server? This could be a lot of work, as I said, isc-dhcp is a classic,
> > but if upstream is shifting its focus elsewhere, soon we will be
> > alone.
>
> I think you'll find that phasing out the client is much more work than
> phasing out the server, given the ways the client is integrated in other
> packages.
>
> > Reverse-Depends
> > * cloud-init
>
> Another example of client integration that's going to require attention;
> cloud-init uses isc-dhcp-client to be able to query specific dhcp attributes
> in early boot used to identify the cloud metadata service.
>
> > * dracut-network
> > * isc-dhcp-client-ddns [amd64 arm64 armhf ppc64el s390x]
> > * libguestfs0 [amd64 arm64 armhf ppc64el s390x]
> > * netscript-2.4
> > * network-manager [amd64 arm64 armhf ppc64el s390x]
>
> I think network-manager's dependency on isc-dhcp-client is vestigial.  You
> will not find any instances of isc-dhcp-client running on an Ubuntu 22.04
> desktop system.
>
> Cheers,
> --
> Steve Langasek   Give me a lever long enough and a Free OS
> Debian Developer   to set it on, and I can move the world.
> Ubuntu Developer   https://www.debian.org/
> slanga...@ubuntu.com vor...@debian.org
> --
> ubuntu-devel mailing list
> ubuntu-devel@lists.ubuntu.com
> Modify settings or unsubscribe at: 
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

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

Re: Question to flavors: touch-base on flavor participation for 22.10!

[Dan Simmons]

Apologies for the delay. On behalf of the Lubuntu team we will be participating 
in 22.10. Thanks for checking in.

Dan

On 5/11/22 05:40, Graham Inggs wrote:

Hello flavors!

As we do around the start of every new cycle, I am reaching out to all
the current official Ubuntu flavors to confirm active participation in
the upcoming Ubuntu release - 22.10.

Working towards a release requires a lot of effort, so we'd like to
make sure all the flavors are ready, properly staffed and have enough
time allocated to make 22.10 happen for their users. This is why,
similarly to last year, I will need a confirmation follow-up message
about kinetic participation from every flavor, that is:

  * Kubuntu
  * Xubuntu
  * Ubuntu Studio
  * Lubuntu
  * Ubuntu Kylin
  * Ubuntu MATE
  * Ubuntu Budgie

If you have any concerns regarding your participation, feel free to
reach out to me or anyone else from the ubuntu-release team.

Thank you!

Graham


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

Re: [ubuntu/kinetic-proposed] bluez 5.64-0ubuntu2 (Accepted)

[Dan Bungert]

On Fri, May 13, 2022 at 10:39:54PM +0200, Sebastien Bacher wrote:
> Hey Brian,
> 
> I noticed that upload and I'm curious about the motivation. It's really
> early in the cycle and we will get bluez updates and time for archive
> rebuilds later on so I guess the aim is not to get packages built with a new
> LTO by release time. Did we have a buggy LTO version in the archive and are
> we rebuilding things with a fixed version? Which packages do need a rebuild
> and do we need to organize the rebuilds with the owning teams?
> 
> Cheers,
> Sebastien Bacher
> 
> Le 13/05/2022 à 21:56, Brian Murray a écrit :
> > bluez (5.64-0ubuntu2) kinetic; urgency=medium
> > 
> >* No change rebuild to pickup a new version of LTO.
> > 
> > Date: Fri, 13 May 2022 12:36:19 -0700
> > Changed-By: Brian Murray 
> > Maintainer: Ubuntu Bluetooth team 
> > https://launchpad.net/ubuntu/+source/bluez/5.64-0ubuntu2

Hi Seb,

Brian uploaded this at my behest.

If you were to build with LTO against
/usr/lib/x86_64-linux-gnu/bluetooth/plugins/sixaxis.a, which can be found in
libbluetooth-dev, then you would see an error like:

fatal error: bytecode stream in file
‘/tmp/tmphqmwfhcw/archive-1/sixaxis_la-sixaxis.o’ generated with LTO
version 11.2 instead of the expected 11.3

I did some work last week detecting cases like this and requesting rebuilds.
My view on this was that if we built these proactively, we might prevent some
FTBFS.  So not so much a buggy LTO as a mismatched one.

Real-world example of this sort of problem, when attempting to build gyoto
against liblorene-dev:
https://autopkgtest.ubuntu.com/results/autopkgtest-kinetic/kinetic/amd64/g/gyoto/20220503_215822_37721@/log.gz
lto1: fatal error: bytecode stream in file
‘/usr/lib/x86_64-linux-gnu/lorene/Lib/liblorene_g.a’ generated with LTO
version 11.2 instead of the expected 11.3

-Dan

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

Re: Proposal: move byobu (and run-one) to universe

[Dan Streetman]

On Tue, May 10, 2022 at 3:41 PM Brian Murray  wrote:
>
> On Tue, May 10, 2022 at 02:55:43PM -0400, Dan Streetman wrote:
> > On Wed, May 4, 2022 at 11:22 AM Paride Legovini  wrote:
> > >
> > > Hi -devel,
> > >
> > > The status of src:byobu appears to be less than ideal, and this has been
> > > the case for several cycles now. I think we should consider moving it
> > > from main to universe in kinetic. The general feedback from the Server
> > > Team about this proposal is positive. We are not aware of anything
> > > specific that could be broken or degraded by the change, however we'd
> > > like to hear feedback from other developers and users before proceeding.
> > > This is also tracked in [0].
> >
> > just for clarification, besides being installed by default on servers
> > (due to being seeded in ubuntu-server) the only other effect that
> > demoting the package from main to universe would have is that the
> > server team would no longer monitor its LP bugs, right?
>
> No, because the package is available in main for a supported release
> (Ubuntu 22.04) the server team would need to continue to monitor its LP
> bugs (by being subscribed to the package) until the last supported
> release that included the package in main is out of standard support.
> This way they can catch and resolve any serious issues with the package.

so the only practical effect of the demotion (besides the server team
ending their package bug monitoring in 5+ years) would be it is not
installed by default on servers?

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

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

Re: Proposal: move byobu (and run-one) to universe

[Dan Streetman]

On Wed, May 4, 2022 at 11:22 AM Paride Legovini  wrote:
>
> Hi -devel,
>
> The status of src:byobu appears to be less than ideal, and this has been
> the case for several cycles now. I think we should consider moving it
> from main to universe in kinetic. The general feedback from the Server
> Team about this proposal is positive. We are not aware of anything
> specific that could be broken or degraded by the change, however we'd
> like to hear feedback from other developers and users before proceeding.
> This is also tracked in [0].

just for clarification, besides being installed by default on servers
(due to being seeded in ubuntu-server) the only other effect that
demoting the package from main to universe would have is that the
server team would no longer monitor its LP bugs, right? If that's the
case, from looking at the patching history since focal, it doesn't
look like much has been done to it, so the only real effect from the
demotion would be byobu not being included by default in ubuntu-server
installs, right?

>
> Rationale:
>
>  - Upstream has very little activity [1];
>  - Bugs filed against the project are mostly not watched/triaged;
>  - Bugs filed against the package do get triaged but are never
>prioritized, and fixes are normally not SRUed;
>  - I don't think the package would have the MIR requirements [4] today;
>  - Possibly anecdotal: I don't think the package has widespread usage.
>
> Currently we have:
>
> $ reverse-depends -c main byobu
> * ubuntu-server
> * ubuntu-server-raspi [arm64 armhf]
> * ubuntu-wsl [amd64 arm64]
>
> so we'd only need to change the seeds to demote.
>
> Side effects:
>
> The run-one package is seeded as a dependency of byobu, it has no other
> reverse dependencies in main. To be evaluated if it makes sense to
> explicitly seed it or demote it too.
>
> Paride
>
> [0] https://bugs.launchpad.net/ubuntu/+source/byobu/+bug/1965944
> [1] https://code.launchpad.net/~kirkland/byobu/trunk
> [2] https://bugs.launchpad.net/byobu/+bugs?orderby=-id=0
> [3]
> https://bugs.launchpad.net/ubuntu/+source/byobu/+bugs?orderby=-id=0
> [4] https://wiki.ubuntu.com/MainInclusionProcess
>
> --
> ubuntu-devel mailing list
> ubuntu-devel@lists.ubuntu.com
> Modify settings or unsubscribe at: 
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

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

+1 maintenance report

[Dan Bungert]

I was on +1 this week.  Here are my notes.

# cyrus-common - LP: #1971469 #

cyrus-common had test failures around usage of EVP_PKEY_base_id.  The usage of
this function seems to have changed somewhat, and cyrus-common was not using it
in a method consistent with the v3 OpenSSL manpage for EVP_PKEY_base_id.  That
manpage suggests instead using EVP_PKEY_is_a for checking key types in this
scenario, which seems to work well.

Status: Forwarded upstream, merged to Debian (Thanks Yadd) and autosynced.

Jammy Status: the affected code was introduced as part of 3.5, and the version
of cyrus-common in Jammy is 3.4.3.  I see no reason to believe that a SRU would
be needed.

# osmo-mgw - LP: #1971620 #

osmo-mgw turned out to have different behavior if you had systemd installed in
the build environment, and by default schroot does not.  If systemd is present,
it causes an unexpected file to appear in the list of files to install, then
dh_missing complains.

Status: Fix proposed to Debian and also listed at above LP.

# gyoto vs lorene - LP: #1971735 #

gyoto had a LTO version conflict with a .a file found in liblorene-dev.
The symptom of that is:

lto1: fatal error: bytecode stream in file ‘/path/to/foo.a’ generated with LTO
version 11.2 instead of the expected 11.3

By rebuilding liblorene-dev, I could use that for a working gyoto build.
However, this suggests a category problem with .a files.  See below.

Status: Uploaded (Thanks Graham)

# LTO vs .a files #

Existing .a files in packages built with LTO could trigger the above problem.
I wrote some tooling to go looking for such things.
https://github.com/dbungert/lto-rebuild-detect

Getting the LTO version was harder than expected - lto-dump doesn't expose it
yet, so doing so requires a patched lto-dump or manual parsing of the info.
(no thanks!)

That said, it was still possible to detect this problem.

for each deb containing a .a file
for each .a file
run lto-dump from the correct version of gcc
look for a errors 'generated with LTO version X instead of ...'

It's not enough to just check the lto-dump return code, since it can fail for
other reasons - for example, lto-dump will fail on object files in .a files
in golang-golang-x-tools-dev, but the error is probably not LTO:

  lto-dump-11: error: /tmp/tmp38g9q35d/archive-2/_go_.o: file not recognized

Based on this script, for AMD64 only looking at -dev packages, I found a few
candidates of packages I expect need a rebuild:

  libbenchmark-dev
  libbluetooth-dev
  libdpdk-dev
  libhts-dev
  liblorene-dev
  libngtcp2-crypto-gnutls-dev
  libunwind-dev
  libunwind-setjmp0-dev
  libwmf-dev
  libwvstreams-dev
  slurm-wlm-basic-plugins-dev

(What's the best way to request sponsorship of a small batch of rebuilds?)

# retest items #

I didn't spend too much time trying to do retests - the queues have been awful
this week - but did request a few:
* cif-api
* yaz

# other things #

* armci-mpi - I was able to verify the test failures but didn't get too far
  with it.  ppc64el and s390x failures look different.  s390x looks like an
  endianness problem maybe.

* android-platform-system-core - problem with debug flags?  Looks like this:
  https://sourceware.org/bugzilla/show_bug.cgi?id=24756

-Dan

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

Re: Application for per-package upload rights for openvswitch and ovn packages

[Dan Streetman]

On Mon, Mar 14, 2022 at 7:45 AM Frode Nordahl  wrote:
>
> Hello fellow hackers,
>
> I hereby put forward my application for per-package upload rights for the 
> Open vSwitch and OVN packages [0].

after a vote on the mailing list and then at the 2022-04-04 DMB
meeting, your application for PPU rights for the openvswitch and ovn
packages was unanimously approved. Congratulations!

>
> I would like my application to be considered in the next developer board 
> meeting on 2022-03-21 at 1900 UTC.
>
> 0: https://wiki.ubuntu.com/fnordahl/uppuapp
>
> --
> Frode Nordahl
> --
> Devel-permissions mailing list
> devel-permissi...@lists.ubuntu.com
> Modify settings or unsubscribe at: 
> https://lists.ubuntu.com/mailman/listinfo/devel-permissions

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

Re: Call for votes: Developer Membership Board restaffing

[Dan Streetman]

On Tue, Mar 29, 2022 at 10:22 AM Robie Basak  wrote:
>
> On Tue, Mar 29, 2022 at 10:14:06AM -0400, Dan Streetman wrote:
> > Do you have evidence that has actually happened to anyone in this
> > case? I was able to vote quite easily, and it seems (from your ML
> > comments) that both Christian and yourself were as well, and Christian
> > provided explicit steps earlier in this email thread.
>
> The low turnout so far suggests that there might be a problem. I've
> additionally had one piece of feedback ending in "...so I gave up. Maybe
> others did too"[1].
>
> > Can you clarify what will happen at the announced end of the election
> > tomorrow? Will the election end, or will you extend it? What is the
> > criteria you will use to decide to extend or adjust the election?
> > What's the next steps if the election is extended?
>
> I have yet to decide. Feedback from others appreciated.
>
> One thing I might try to do

whatever you decide to do, my feedback is that you should decide it
and announce it, with specific details, before the previously-stated
end of the election. If you feel the election process must change, I
personally trust you to make a good decision on what new
rules/procedures need to be adjusted for this election (but as
previously stated I also pretty strongly feel that the election should
end at its previously stated end date).

After the modified election rules/process are announced, including a
new end date (if applicable), I suggest not making any more changes.

> is arrange a mailshot directly myself -
> perhaps using my @canonical.com address - since I think that might get
> through to Gmail users OK. This would be just to alert the electorate to
> the existing posts to ubuntu-devel-announce@ and ubuntu-devel@. I could
> just provide archive links. I can't differentiate between people who
> have voted and people who have not, so this would have to go to everyone
> I have down as eligible (for whom I have a valid address).
>
> Robie
>
> [1] With my help in identifying the correct alias this person reports
> they have now voted, so that's good.

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

Re: Call for votes: Developer Membership Board restaffing

[Dan Streetman]

On Tue, Mar 29, 2022 at 9:45 AM Robie Basak  wrote:
>
> On Tue, Mar 29, 2022 at 09:19:31AM -0400, Dan Streetman wrote:
> > For example, in this situation; carrying out an election really
> > shouldn't be an exceptional event.
>
> Normally it isn't. Previous elections have run smoothly and with no
> issues that I'm aware of.
>
> However we now have an interaction between the following exceptional
> situations, none of which were predicted:
>
> 1) The sudden apparent inability to send out announcements in the usual
> way.
>
> 2) The sudden (for us) change in CIVS to require email pre-approval.
>
> 3) Our existing email-gathering system means that people now don't
> necessarily know their own ballot email alias and figuring that out is
> particularly difficult.
>
> This is exceptional and requires exceptional consideration. Nothing we
> might have had in rules or policies previously could reasonably have
> predicted this.
>
> You seem to be suggesting that the current situation demonstrates that
> the existing documentation, process or policy around running a DMB
> election is somehow inadequate. But since this exceptional situation
> couldn't reasonably have been accommodated in hindsight, I don't think
> this is the case.
>
> > My feedback would be that this election should stick to the process
> > already in place at the start of the election. There should be no
> > changes to the process while the election is ongoing. If you think the
> > election process should change, that should be discussed, agreed on,
> > and documented. Then the next election can use the new process.
>
> Thank you for your feedback.
>
> > Can you imagine if a government decided to change the election process
> > during an election?
>
> For a fair comparison, you'd have to imagine what would happen if during
> a government election it turned out that most of the electorate found
> themselves unable to receive a ballot and therefore couldn't vote.

Do you have evidence that has actually happened to anyone in this
case? I was able to vote quite easily, and it seems (from your ML
comments) that both Christian and yourself were as well, and Christian
provided explicit steps earlier in this email thread.

Can you clarify what will happen at the announced end of the election
tomorrow? Will the election end, or will you extend it? What is the
criteria you will use to decide to extend or adjust the election?
What's the next steps if the election is extended?

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

Re: Call for votes: Developer Membership Board restaffing

[Dan Streetman]

On Tue, Mar 29, 2022 at 8:57 AM Robie Basak  wrote:
>
> On Tue, Mar 29, 2022 at 06:14:27AM -0400, Dan Streetman wrote:
> > Where are the rules/policies written down about how elections should
> > be handled?
>
> The first time I ran an election I couldn't find much documentation at
> all, so I tried to follow what I could see of what had been done before,
> fixed up the voter email gathering code, and documented everything at:
>
> https://wiki.ubuntu.com/DeveloperMembershipBoard/KnowledgeBase#Running_a_DMB_election
>
> Note though that I documented what I considered to be best practice,
> based on what had been done before as well as feedback. It's not a rule
> or policy as such. Nor do I think it's necessary to be that.
>
> This time I'm mostly following that documentation, adapting as I think
> appropriate for the current situation (eg. three seats vacated, not
> because their terms expired, etc, required changes in wording).
>
> > We should have the process written down somewhere so there
> > is not ambiguity like this.
>
> In this case I don't think it would necessarily be appropriate to
> blindly follow a written rule or policy.
>
> The goal is to ensure that everyone considers the outcome to be fair and
> appropriate. It's not possible to have a written policy to cover every
> possible exceptional case. This situation is exceptional, and may
> warrant taking some exceptional action to ensure that we don't
> inappropriately exclude anyone. Ideally, if we did decide to handle
> something differently as an exception,

It really concerns me that so many of our processes are so ad-hoc.
Blindly following rules is obviously bad, but it's equally bad to have
to discuss every action and gain consensus. We shouldn't have to carry
on a discussion every time something unexpected comes up, and we
should have someone who is willing (and empowered) to handle minor
administrative decisions. I don't think most people actually care
about process administrivia, and IMHO introducting too much
administriva only serves to turn people off of contributing.

For example, in this situation; carrying out an election really
shouldn't be an exceptional event. The rules/policies for how to do
that should be clearly documented and one person should be able to
carry out the election without needing to guess about things, or
needing to have a discussion about how the election process should be
modified while the election is going on.

> we would all be unanimous about
> the appropriateness of doing that. This is why I'm asking for feedback
> here.

My feedback would be that this election should stick to the process
already in place at the start of the election. There should be no
changes to the process while the election is ongoing. If you think the
election process should change, that should be discussed, agreed on,
and documented. Then the next election can use the new process.

Can you imagine if a government decided to change the election process
during an election?

>
> On Tue, Mar 29, 2022 at 06:17:23AM -0400, Dan Streetman wrote:
> > On Tue, Mar 29, 2022 at 6:14 AM Dan Streetman  wrote:
> > Also, I think we should probably remove ubuntu-devel-announce from
> > this discussion?
>
> Agreed. I mistakenly included it in my previous reply and cancelled the
> post there after it was held for moderation. I've now cut down the Cc:
> list. I think it's fine to limit the discussion to ubuntu-devel@ as all
> nominees and the electorate are expected to be in here. Nonwithstanding
> deliverability problems, but I don't expect that to affect any other
> Ubuntu lists differently.
>
> Robie

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

Re: Call for votes: Developer Membership Board restaffing

[Dan Streetman]

On Tue, Mar 29, 2022 at 6:14 AM Dan Streetman  wrote:
>
> On Tue, Mar 29, 2022 at 6:02 AM Robie Basak  wrote:
> >
> > On Wed, Mar 23, 2022 at 12:51:52PM +0100, Christian Ehrhardt wrote:
> > > If you happen to activate the "wrong" email you'll just see:
> > >
> > > ```
> > >   Email address successfully activated.
> > > ```
> > >
> > > But if you activate the right one (just as Robie said, usually the
> > > @ubuntu.com one) you'd in the Web UI of CIVS right after clicking
> > > "Complete activation" see this:
> > >
> > > ```
> > > Email address successfully activated.
> > >   Pending poll invitations:
> > > Ubuntu Developer Membership Board restaffing
> > > ```
> > >
> > > The latter line is a link leading you to your vote.
> >
> > Thank you Christian for detailing this. Hopefully this has helped others
> > vote.
> >
> > So far the turnout is considerably lower than the previous election two
> > years ago. Last time there were 54/173 votes cast at the time the poll
> > closed. For the CIVS poll in progress I can't see who voted (or how) but
> > the control page does show me the count. So far we have 23/174.
> >
> > We've had a couple of hurdles:
> >
> > 1) This extra opt-in step means that the electorate no longer get the
> > poll request directly to their inbox. We're relying on them seeing the
> > ubuntu-devel-announce@ notifications, or subsequent traffic to
> > ubuntu-devel@.
> >
> > 2) Recently Gmail seems to have adjusted things which has caused
> > deliverability problems to @gmail.com addresses (and presumably other
> > addresses hosted by Google). IS has made some adjustments to try to
> > help, but it's unclear to me if they worked because overnight I received
> > ~373 "unsubscribe" notifications to ubuntu-devel-owner@ all at once,
> > predominantely relating to @gmail.com addresses. It seems likely to me
> > that these are a result of the deliverability problems. So it's not
> > clear to me that all of the electorate is actually even aware of the
> > election. Of course there are surely many more ubuntu-devel@ subscribers
> > than those eligible to vote, so the number of unsubscribes doesn't
> > actually mean anything.
> >
> > I'd appreciate feedback on how to proceed.
>
> Where are the rules/policies written down about how elections should
> be handled? We should have the process written down somewhere so there
> is not ambiguity like this.

Also, I think we should probably remove ubuntu-devel-announce from
this discussion?

>
> > For example, together with
> > some specific action to draw the attention of the electorate, I could
> > extend the voting period if that would be considered helpful.
> >
> > On the other hand, it would be helpful to get the replacement DMB
> > members resolved as soon as possible. Perhaps the current vote count can
> > be considered enough to not make a big difference to the outcome, given
> > that there's no particular reason for bias in those that might not have
> > received the announcement?
> >
> > Robie
> > --
> > Ubuntu-devel-discuss mailing list
> > ubuntu-devel-disc...@lists.ubuntu.com
> > Modify settings or unsubscribe at: 
> > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

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

Re: Call for votes: Developer Membership Board restaffing

[Dan Streetman]

On Tue, Mar 29, 2022 at 6:02 AM Robie Basak  wrote:
>
> On Wed, Mar 23, 2022 at 12:51:52PM +0100, Christian Ehrhardt wrote:
> > If you happen to activate the "wrong" email you'll just see:
> >
> > ```
> >   Email address successfully activated.
> > ```
> >
> > But if you activate the right one (just as Robie said, usually the
> > @ubuntu.com one) you'd in the Web UI of CIVS right after clicking
> > "Complete activation" see this:
> >
> > ```
> > Email address successfully activated.
> >   Pending poll invitations:
> > Ubuntu Developer Membership Board restaffing
> > ```
> >
> > The latter line is a link leading you to your vote.
>
> Thank you Christian for detailing this. Hopefully this has helped others
> vote.
>
> So far the turnout is considerably lower than the previous election two
> years ago. Last time there were 54/173 votes cast at the time the poll
> closed. For the CIVS poll in progress I can't see who voted (or how) but
> the control page does show me the count. So far we have 23/174.
>
> We've had a couple of hurdles:
>
> 1) This extra opt-in step means that the electorate no longer get the
> poll request directly to their inbox. We're relying on them seeing the
> ubuntu-devel-announce@ notifications, or subsequent traffic to
> ubuntu-devel@.
>
> 2) Recently Gmail seems to have adjusted things which has caused
> deliverability problems to @gmail.com addresses (and presumably other
> addresses hosted by Google). IS has made some adjustments to try to
> help, but it's unclear to me if they worked because overnight I received
> ~373 "unsubscribe" notifications to ubuntu-devel-owner@ all at once,
> predominantely relating to @gmail.com addresses. It seems likely to me
> that these are a result of the deliverability problems. So it's not
> clear to me that all of the electorate is actually even aware of the
> election. Of course there are surely many more ubuntu-devel@ subscribers
> than those eligible to vote, so the number of unsubscribes doesn't
> actually mean anything.
>
> I'd appreciate feedback on how to proceed.

Where are the rules/policies written down about how elections should
be handled? We should have the process written down somewhere so there
is not ambiguity like this.

> For example, together with
> some specific action to draw the attention of the electorate, I could
> extend the voting period if that would be considered helpful.
>
> On the other hand, it would be helpful to get the replacement DMB
> members resolved as soon as possible. Perhaps the current vote count can
> be considered enough to not make a big difference to the outcome, given
> that there's no particular reason for bias in those that might not have
> received the announcement?
>
> Robie
> --
> 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

-- 
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

Re: Call for votes: Developer Membership Board restaffing

[Dan Streetman]

On Tue, Mar 29, 2022 at 6:02 AM Robie Basak  wrote:
>
> On Wed, Mar 23, 2022 at 12:51:52PM +0100, Christian Ehrhardt wrote:
> > If you happen to activate the "wrong" email you'll just see:
> >
> > ```
> >   Email address successfully activated.
> > ```
> >
> > But if you activate the right one (just as Robie said, usually the
> > @ubuntu.com one) you'd in the Web UI of CIVS right after clicking
> > "Complete activation" see this:
> >
> > ```
> > Email address successfully activated.
> >   Pending poll invitations:
> > Ubuntu Developer Membership Board restaffing
> > ```
> >
> > The latter line is a link leading you to your vote.
>
> Thank you Christian for detailing this. Hopefully this has helped others
> vote.
>
> So far the turnout is considerably lower than the previous election two
> years ago. Last time there were 54/173 votes cast at the time the poll
> closed. For the CIVS poll in progress I can't see who voted (or how) but
> the control page does show me the count. So far we have 23/174.
>
> We've had a couple of hurdles:
>
> 1) This extra opt-in step means that the electorate no longer get the
> poll request directly to their inbox. We're relying on them seeing the
> ubuntu-devel-announce@ notifications, or subsequent traffic to
> ubuntu-devel@.
>
> 2) Recently Gmail seems to have adjusted things which has caused
> deliverability problems to @gmail.com addresses (and presumably other
> addresses hosted by Google). IS has made some adjustments to try to
> help, but it's unclear to me if they worked because overnight I received
> ~373 "unsubscribe" notifications to ubuntu-devel-owner@ all at once,
> predominantely relating to @gmail.com addresses. It seems likely to me
> that these are a result of the deliverability problems. So it's not
> clear to me that all of the electorate is actually even aware of the
> election. Of course there are surely many more ubuntu-devel@ subscribers
> than those eligible to vote, so the number of unsubscribes doesn't
> actually mean anything.
>
> I'd appreciate feedback on how to proceed.

Where are the rules/policies written down about how elections should
be handled? We should have the process written down somewhere so there
is not ambiguity like this.

> For example, together with
> some specific action to draw the attention of the electorate, I could
> extend the voting period if that would be considered helpful.
>
> On the other hand, it would be helpful to get the replacement DMB
> members resolved as soon as possible. Perhaps the current vote count can
> be considered enough to not make a big difference to the outcome, given
> that there's no particular reason for bias in those that might not have
> received the announcement?
>
> Robie
> --
> Ubuntu-devel-discuss mailing list
> ubuntu-devel-disc...@lists.ubuntu.com
> Modify settings or unsubscribe at: 
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

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

Re: Nominations: Developer Membership Board

[Dan Streetman]

On Thu, Mar 17, 2022 at 7:57 PM Seth Arnold  wrote:
>
> On Thu, Mar 17, 2022 at 12:09:27PM -0700, Brian Murray wrote: > On Thu, Mar 
> 17, 2022 at 02:54:02PM -0400, Dan Streetman wrote:
> > Haven't there problems with reaching the number of votes necessary for a
> > quorum in the past? I'd rather see the team reduce in size[1] so that its
> > easier for applications to be approved.
>
> An alternative is changing quorum rules to eg "at least three voters"
> and then even if N of the M team members are missing, it's much less
> disruptive to the prospective new developers.

For those who may not have seen it, I wrote a draft charter for the
backports team:
https://wiki.ubuntu.com/UbuntuBackports/Charter

I really think the DMB needs something like this, especially 1)
control of its own membership and 2) a SINGLE Administrator to resolve
policy interpretation disputes. Normal DMB members should be able to
focus ONLY on the actual mission of the DMB, not on administrative
stuff (unless they actually WANT to focus on admin work).

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

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

Re: Nominations: Developer Membership Board

[Dan Streetman]

On Thu, Mar 17, 2022 at 3:09 PM Brian Murray  wrote:
>
> On Thu, Mar 17, 2022 at 02:54:02PM -0400, Dan Streetman wrote:
> > On Thu, Mar 17, 2022 at 9:40 AM Onno Benschop  wrote:
> > >
> > > One way to leverage these volunteers is to deputise them and have them 
> > > participate in the activities as a shadow member.
> >
> > Personally, I don't know where the fixed size of the DMB came from;
> > there's nothing magic about 7 people. I suppose the TB controls this
> > currently though, so the DMB would either need to write up a full
> > charter that includes control over the membership size, or ask the TB
> > to adjust the size.
> >
> > I don't see any particular reason to fix the size at 7, and I'd quite
> > like it if the team grew in size.
>
> Haven't there problems with reaching the number of votes necessary for a
> quorum in the past? I'd rather see the team reduce in size[1] so that its
> easier for applications to be approved.

What I meant was that if *more* than 7 people are interested in
joining the team, we shouldn't necessarily turn people away just
because we have a fixed size limit. I don't mean that we should fix
the limit at a larger size.

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

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

+1 maintenance report

[Dan Bungert]

I was on +1 for Monday and Tuesday.  Here are my notes.

# mariadb #

Debbug 1005950 was tracking openssl 3 and mariadb-10.6.  The discussion there
is that OpenSSL is officially part of ver 10.8 and 10.9+, but some backport
work was done and uploaded to Experimental.  Debian upstream is working on this
(thanks Otto), but there is some additional test flakiness, so I have proposed
skipping another test in that test suite.  LP: #1964045 and MR on Salsa, under
discussion.

# qt6-base #

Michael Hudson-Doyle outlined a plan for qt6-base last week, I just went and
did it.  LP: #1964273, MR on Salsa, debbug open.

# other things I looked at quickly #

* tpm2-tss-engine - left alone, already on the removal list - LP: #1959414
* opa-ff - left alone, LP: #1960841 - to quote Simon Chopin:
  "Having linux-tools-common Providing linux-cpupower would allow us to keep
  the aforementioned packages in sync with Debian without introducing a delta."
* surf - had an autopkgtest failure on arm64.  Here are the log differences
  between good and bad cases.  A new version of webkit2gtk has been uploaded so
  unsure if this is still relevant.
  bad:
Could not determine the accessibility bus address
Cannot get default EGL display: EGL_BAD_PARAMETER
Cannot create EGL context: invalid display (last error: EGL_SUCCESS)
Too few characters detected (0)
  good:
Estimating resolution as 123
Text has 1763 characters and 6 detected errors
* softhsm2 - digging into the test failures shows many instances of the
  following - TestsNoPINInitBase.cpp 124 setUp() failed.
  There is some talk of openssl3 work upstream
  https://github.com/opendnssec/SoftHSMv2/pull/633

-Dan

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

Re: Call for nominations: Developer Membership Board

[Dan Streetman]

On Wed, Mar 9, 2022 at 9:19 AM Sebastien Bacher  wrote:
>
> Hey Robie and DMB members,
>
> Le 01/03/2022 à 16:51, Robie Basak a écrit :
> > Candidates must expect to be able to attend the majority of DMB
> > meetings. Currently these take place on IRC, are scheduled on alternate
> > Mondays with each meeting alternating between 1600 UTC and 1900 UTC, and
> > last around an hour.
>
> Following the recent emails stating that we don't have enough candidate
> I'm going to drop a note about ^
>
> I was pondering sending my application, I'm busy but I think it's
> important that we have a function DMB, but that 'must expect' statement
> convinced me to not.

I will comment here only to say that statement does not reflect my
opinion at all, and was not discussed with the other DMB members
before Robie sent it. I have absolutely no idea whether that statement
is simply Robie's opinion, or actual policy of the DMB.

Personally I do not think new members should be expected to attend the
majority of DMB meetings; I think it's 100% fine for members to
participate asynchronously using the mailing list (or proxy voting,
but with ML voting, I don't really see the need for proxy voting).

> I try to lock the 17h30-20h to be able to have some family time and
> that's not something I'm wanting to compromise on at this point.
>
> I might not be the only one in that situation, since we are short on
> candidate maybe it would help to try to be less rigid on that
> requirement? (being open to different times? allow members to skip and
> vote via email? ...)
>
> Cheers,
> Sebastien Bacher
>
>
> --
> ubuntu-devel mailing list
> ubuntu-devel@lists.ubuntu.com
> Modify settings or unsubscribe at: 
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

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

Re: Call for nominations: Developer Membership Board

[Dan Streetman]

On Tue, Mar 8, 2022 at 9:44 PM Seth Arnold  wrote:
>
> On Tue, Mar 08, 2022 at 10:37:07AM -0500, Dan Streetman wrote:
> > In any case, all this formality really is exhausting and I don't care
> > to pursue it, since you seem to be saying that I can't call for a DMB
>
> I've been having this thought a lot the last few years.
>
> A lot of the Ubuntu structures feel like they may have had a place in the
> early days, when there were thousands of enthusiasts all contributing at
> once and trying to coordinate how they were going to do all that.
>
> Now it feels like we've got the ossified remains of a lot of committees
> and teams and boards and I just don't know how much of it is still
> relevant to the Ubuntu of today. Every piece serves a role so it's not
> like I can just point to any one specific thing and say we ought to scrap
> it, but I remember watching what felt like dozens of DMB meetings where
> not enough members showed up, not enough members voted, and the poor
> applicants could go weeks or months (or more?) without an answer.
>
> That kills enthusiasm.
>
> I'm sorry that I don't have a solution to recommend but I think I'd like
> to suggest that we try stepping back from bureaucracy when opportunities
> arise.

Thanks Seth, I think that summarizes my frustrations extremely well.

I don't know if I have the energy to step back into working on the
DMB, but I am trying to pre-emptively address this with my proposed
charter for the backports team (in case you haven't seen it):
https://wiki.ubuntu.com/UbuntuBackports/Charter

Essentially, what I see as absolutely critical to Ubuntu teams is for
the team members to focus on the team *mission*, and appoint *one*
person as administrator to handle all the administrivia/bureaucracy.
The *mission* of the DMB has become completely and totally lost in the
needless administration of rules, and that only serves to make the
problem worse as the (volunteer!) team members lose interest.

I think at this point, the DMB desperately needs a charter, so these
team-wide discussions about administration can end, and an
administrator to take responsibility (and have authority) to make sure
the team makes progress on its mission.

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

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

Re: Call for nominations: Developer Membership Board

[Dan Streetman]

On Tue, Mar 8, 2022 at 9:20 AM Robie Basak  wrote:
>
> On Tue, Mar 08, 2022 at 08:56:23AM -0500, Dan Streetman wrote:
> > I would like to officially call for a DMB vote on extending DMB
> > eligibility to members of the ~ubuntu-sru-developers team.
>
> Previous discussion and decision here:
> https://lists.ubuntu.com/archives/technical-board/2020-January/002464.html
>
> It's been pointed out recently that it's the TB that runs the DMB
> election, even if the administrative work has been delegated to the DMB
> (and then to me).
>
> I concluded the previous discussion on the basis of having found
> consensus within the DMB (you weren't on the DMB at the time) and on the
> basis of no objection from the TB, who were copied in to the thread.
>
> If you want the eligibility criteria changed contrary to that previous
> discussion and decision, I think it'd need to be a TB policy decision

Well, that seems a whole lot like it's simply your opinion.

In any case, all this formality really is exhausting and I don't care
to pursue it, since you seem to be saying that I can't call for a DMB
vote on this, even though the previous decision was decided entirely
by DMB members.

> since it'd be contrary to the opinion of a bunch of people in that
> thread (and therefore there wouldn't be consensus, unless their
> positions have changed or you persuade them otherwise). You can take it
> to the TB mailing list and/or add the item to the TB agenda here:
>
> https://wiki.ubuntu.com/TechnicalBoardAgenda
>
> Robie

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

Re: Call for nominations: Developer Membership Board

[Dan Streetman]

On Tue, Mar 8, 2022 at 8:52 AM Robie Basak  wrote:
>
> On Tue, Mar 01, 2022 at 03:51:22PM +, Robie Basak wrote:
> > Three members - Simon Quigley, Eric Desrochers and Rafael David Tinoco -
> > have recently vacated their seats on the DMB. Subsequently, this email
> > is a call for nominations to fill their vacated seats.
>
> We don't yet have enough nominations to fill the seats that are up for
> election. In recent years the DMB has routinely been short-staffed,
> blocking us from being able to appoint more Ubuntu developers.
>
> If you are a core dev or MOTU, please consider spending one hour every
> other Monday to help others join us by nominating yourself for a seat on
> the DMB[1].

I would like to officially call for a DMB vote on extending DMB
eligibility to members of the ~ubuntu-sru-developers team.

>
> Thanks,
>
> Robie
>
> [1] 
> https://lists.ubuntu.com/archives/ubuntu-devel-announce/2022-March/001305.html
> --
> ubuntu-devel mailing list
> ubuntu-devel@lists.ubuntu.com
> Modify settings or unsubscribe at: 
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

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

Re: Ubuntu-dev-tools' "pull-lp-source" not overriding default configurations?

[Dan Streetman]

I'd recommend opening a bug with this info on launchpad.

On Mon, Feb 28, 2022 at 10:36 AM Hariri, Nader
 wrote:
>
> Hi,
>
> According to the manpages, "pull-lp-source" script should parse environment 
> variables or devscripts file to override package-wide variables.
>
> However, this is not working for me. For instance, when I set the environment 
> variables to:
>
>
> export PULL_LP_SOURCE_MIRROR="https://de.mirrors.clouvider.net/ubuntu;
> export UBUNTUTOOLS_UBUNTU_MIRROR="https://de.mirrors.clouvider.net/ubuntu;
> export PULL_PKG_UBUNTU_MIRROR="https://de.mirrors.clouvider.net/ubuntu;
>
> export UBUNTUTOOLS_MIRROR_FALLBACK=no
>
>
> the script does not try to fetch the package from the mirror I have 
> specified, and falls back to the default mirror even though I have specified 
> it not to:
>
>
> $ ubuntu-dev-tools-0.188/pull-lp-source -v --download-only dash
> pullpkg options: {'login': False, 'verbose': 1, 'download_only': True, 
> 'mirror': None, 'no_conf': False, 'no_verify_signature': False, 'status': [], 
> 'arch': 'amd64', 'pull': 'source', 'distro': 'ubuntu', 'security': False, 
> 'upload_queue': False, 'package': 'dash', 'release': None, 'version': None, 
> 'ppa': None}
> Found dash 0.5.11+git20210903+057cd650a4ed-3 in jammy
> Downloading dash_0.5.11+git20210903+057cd650a4ed-3.dsc from ports.ubuntu.com 
> (0.002 MiB)
> [=>]100%
> Public key not found, could not verify signature
> Downloading dash_0.5.11+git20210903+057cd650a4ed.orig.tar.xz from 
> ports.ubuntu.com (0.127 MiB)
> [=>]100%
> Downloading dash_0.5.11+git20210903+057cd650a4ed-3.debian.tar.xz from 
> ports.ubuntu.com (0.041 MiB)
> [=>]100%
> --download-only specified, not extracting
>
>
> What am I missing?
>
> Thanks,
> Nader
> --
> ubuntu-devel mailing list
> ubuntu-devel@lists.ubuntu.com
> Modify settings or unsubscribe at: 
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

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

+1 maintenance report

[Dan Bungert]

+1 maintenance report Jan-31 to Feb-4-2022

# rebuilds #

facter - In sponsor queue.  LP: #1959700
rhash - In sponsor queue.  LP: #1959840

# hydra #

At the start of my week, Simon Chopin pinged me and asked that I take a look at
hydra.  I found that this FTBFS was due to some unforunate misconfiguration of
include paths, which caused a limits.h file from memcached to be included
instead of /usr/include/limits.h.  LP: #1959622 uploaded (thanks Simon),
merged upstream, bug forwarded to Debian (debbug 1004707).

# opensurgsim #

When facter is rebuilt, opensurgsim will be the last package to depend on
libyaml-cpp0.6.  It's got some messy build failures seemingly around changes in
libeigen3.  I poked at it a bit but decided this one was beyond me.
LP: #1959839

Sent upstream two unrelated fixes while attempting to build upstream main
branch on Jammy.  Opened an issue for this one.
https://github.com/simquest/opensurgsim/issues/5

# validns #

I updated a test that was looking for a specific error string to tolerate both
pre-openssl3 and openssl3 error strings.  LP: #1959855, forwarded to upstream,
Simon uploaded and also fixed my incorrect series in the changelog.

# bobcat vs icmake #

I looked into bobcat as another package to try to help with the NBS report and
libssl.  I found that icmake is having some problems here.  With some valgrind
debugging I was able to slightly improve things, but not enough to get bobcat
building correctly on the problem arch, s390x.  Forwarded to Debian
(debbug 1004986), LP: #1960082.  Tony Mancill reviewed my work so far and plans
to upload icmake to Debian, but further fixes will be needed to get a valid
binary package for bobcat.

-Dan

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

Re: MOTU application: Frank Heimes (fheimes)

[Dan Streetman]

On Mon, Jan 17, 2022 at 2:57 AM Frank Heimes  wrote:
>
> Dear DMB,
> I hereby apply to become a MOTU (and Ubuntu Contributing Developer).

Hello, sorry for the delay!

At the DMB meeting 2022-01-24, as well as from DMB member votes by
email after the meeting, your application for Ubuntu Contributing
Developer was unanimously approved. Congratulations!

As mentioned during the meeting, we hope to see your reapplication for
MOTU (and/or other application) in the near future.

Thanks!

>
> My application can be found at:
> https://wiki.ubuntu.com/FrankHeimes/MOTU
>
> I've also added an entry for my application to the DMB agenda (for the 
> 2022-01-24 meeting).
>
> Thank you,
> Frank
>
>
> Ubuntu on s390x Blog -- ubuntu-on-big-iron.blogspot.com
> --
> Devel-permissions mailing list
> devel-permissi...@lists.ubuntu.com
> Modify settings or unsubscribe at: 
> https://lists.ubuntu.com/mailman/listinfo/devel-permissions

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

Re: slurm-client build script

[Dan Bungert]

On Thu, Jan 20, 2022 at 06:29:42AM -0500, John Yost wrote:
> Hi Everyone,
> I want to build the 21.08.5 slurm-client installer for Ubuntu 18.04.
> Could you please share the build script?

Hi John,

In Debian & Ubuntu style packaging, there is a source package that contains
both the upstream source and the package build script.

To obtain the source package, you may find the `pull-lp-source` script helpful.
You can find that in the `ubuntu-dev-tools` package.

After that, have a look at:
https://www.debian.org/doc/manuals/maint-guide/build.en.html#completebuild
Please mind the requirements for installing `build-essential` and the
package-specific build dependencies.

Optional: if you think you will be doing more of this sort of backporting, look
into `sbuild` - https://wiki.ubuntu.com/SimpleSbuild - it's wonderful for this
sort of thing but does require some setup.

-Dan

-- 
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

Re: Change unattended-upgrades from Depends to Recommends on ubuntu-server-minimal

[Dan Streetman]

On Tue, Jan 11, 2022 at 6:12 PM Michael Hudson-Doyle
 wrote:
>
> So I think we should probably change the server-minimal seed to only 
> recommend, not depend, on unattended-upgrades. Changing to a hard dependency 
> was not intended when I wrote that seed and a change like this should 
> probably be a conscious thing.
>
> On Thu, 6 Jan 2022 at 22:25, John Chittum  wrote:
>>
>> Going to backtrack slightly to answer Matthew's question:
>>
>>> Why is Jammy Server semantically different from Cloud images or
>>> Container images?
>>
>>
>> The Cloud Image and the LXD Container image are the same. Both are generated 
>> by the `ubuntu-cpc` project, and thus take the same initial paths in 
>> `livecd-rootfs` for choosing seed and base install packages. Neither install 
>> `ubuntu-server-minimal` at this time.
>>
>> There were decisions made (predating me on CPC) that the cloud image (and 
>> lxd rootfs) would be separate entities from the Server product. I'm not 
>> going to weigh in on correctness, but they are separate products at this 
>> point.
>
>
> It would be super great to consolidate the vaguely-but-not-quite overlapping 
> "external product"/"livecd-rootfs project"/"seed definitions" stuff but there 
> are subtleties all over :/ Something for a sprint, a marker pen and a very 
> large sheet of paper.
>
>> From Steve:
>>
>>> First, I think unattended-upgrades should be directly seeded everywhere; its
>>> inclusion in the images should not be a side-effect of including
>>> software-properties.
>>
>>
>> On one hand, I generally agree with this statement.
>
>
> Me too.
>
>>
>> It seems odd that it is not directly seeded in the cloud images. the LXD 
>> container, I'm a little less worried about, and I'd almost argue the 
>> opposite -- that in a container image `unattended-upgrades` should not be 
>> installed by default. Or, if it is, the default settings are to not be 
>> running. That fits more to the current world stance on containers (you don't 
>> upgrade them, you replace them). For instance, the Docker container does not 
>> have it installed. From the Impish container (which i have handy)
>>
>> docker run -it --rm ubuntu /bin/bash
>> root@671453626e88:/# dpkg -l | grep unattended
>
>
> Docker images should definitely not have it installed, seeing is there is no 
> generic mechanism for having it _do_ anything in docker containers. lxd 
> containers are a bit different.
>
>>
>> This gets into some of the limitations put in place by livecd-rootfs when 
>> creating images. There is a mapping of $PROJECT to $SEED done in 
>> livecd-rootfs/live-build/auto/config. And cloud-images, while having their 
>> own seed, appear to be using ubuntu.$SUITE/server, and then additional 
>> meta-packages and seed files. the relevant code is here:
>>
>> https://git.launchpad.net/livecd-rootfs/tree/live-build/auto/config#n893
>>
>> The gist is anything built by the ubuntu-cpc starts from the server seed, 
>> then runs the seed task minimal, standard, and cloud-image, then installs 
>> the meta-package ubuntu-minimal. It's certainly different than the server 
>> path, and should be different considering the use cases.
>>
>> From Dan:
>>
>>> And that isn't necessarily a bad choice - large deployments
>>> really *do not* want software changing outside of predefined
>>> maintenance windows, where actual admins are online to handle any kind
>>> of issues caused by the upgrades. That's obviously not the only case
>>> where unattended upgrades are not desirable, but a very frequent and
>>> large example.
>>
>>
>> I very much agree with the ease of removal and the large scale deployments. 
>> Previous life, I was one of those people, doing exactly quarterly updates, 
>> and our initial Ubuntu image deployed by our IT department did not have 
>> unattended-upgrades installed. I'm also thinking about things in a cloud 
>> context, where the approach has been that servers are not "pets." I'd say 
>> that statement is not a universal truth, but is a good starting point for 
>> considering the importance of unattended-upgrades in a cloud context.
>
>
> The larger scale the deployment, the more expertise we can assume on the part 
> of the deployer though.

Please don't assume that. There are lots of people in Canonical with
real direct experience with large scale customer deployments; you
should ask them directly instead of making any assumptions.

> I think the defaults have to be 

Re: Ubuntu LTS20.04 - wireguard package

[Dan Streetman]

On Tue, Jan 11, 2022 at 12:35 PM Jeffrey Walton  wrote:
>
> On Tue, Jan 11, 2022 at 8:36 AM Dan Streetman  wrote:
> > ...
> > > Fedora has a 6 month release cycle. Each version you are on has the
> > > latest releases of its packages and gets full updates. And in 6 months
> > > you move onto the next stable version. At the 6 month release in the
> > > life cycle, you simply run dnf-system-upgrade [1] and you are on the
> > > next version of Fedora. dnf-system-upgrade is a lot like a Ubuntu
> > > dist-upgrade.
> >
> > Just to clarify, what you are describing about Fedora is EXACTLY the
> > same for Ubuntu...6 month release cycle, latest packages in each
> > release, full updates (for at least 9 months), upgrade with a single
> > command at each 6 month release. The 'dnf-system-upgrade' sounds more
> > like the 'do-release-upgrade' command, not 'apt dist-upgrade' (though
> > both are similar).
>
> Yes, you're right. do-release-upgrade looks like the similar command.
>
> Do you know if do-release-upgrade will move from one LTS version to
> another? I usually select Ubuntu LTS when I want long term stability,
> like over 3 or 5 years. In fact, my main desktop machine is Ubuntu
> 18.04 LTS.

Yes, the /etc/update-manager/release-upgrades file contains a 'Prompt'
setting that controls if do-release-upgrade will upgrade to the next
LTS release or the next 'normal' release.

This blog post has some more detailed info; though the post is
obviously almost 2 years old, I think it's all still relevant/correct:
https://ubuntu.com/blog/how-to-upgrade-from-ubuntu-18-04-lts-to-20-04-lts-today


>
> Fedora does not really offer long term stability. Fedora is more
> suited for the latest stable release every 6 months. Select it when
> you want as close to the bleeding edge as possible while staying
> stable.
>
> Jeff

-- 
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

Re: Ubuntu LTS20.04 - wireguard package

[Dan Streetman]

On Mon, Jan 10, 2022 at 6:17 PM Jeffrey Walton  wrote:
>
> On Mon, Jan 10, 2022 at 2:02 PM Filip Menke  wrote:
> >
> > Is there a reason why the wireguard package is outdated and no updates are 
> > available through the standard update process(apt-get update / upgrade)?
> >
> > Users must update the package manually and from a security perspective a 
> > VPN server should be always up to date otherwise the system could be 
> > vulnerable..
>
> Related, if you want the latest version of a package like Wireguard
> (or GCC, or Python, or Perl, ...), then you might want to look at
> Fedora.
>
> Fedora has a 6 month release cycle. Each version you are on has the
> latest releases of its packages and gets full updates. And in 6 months
> you move onto the next stable version. At the 6 month release in the
> life cycle, you simply run dnf-system-upgrade [1] and you are on the
> next version of Fedora. dnf-system-upgrade is a lot like a Ubuntu
> dist-upgrade.

Just to clarify, what you are describing about Fedora is EXACTLY the
same for Ubuntu...6 month release cycle, latest packages in each
release, full updates (for at least 9 months), upgrade with a single
command at each 6 month release. The 'dnf-system-upgrade' sounds more
like the 'do-release-upgrade' command, not 'apt dist-upgrade' (though
both are similar).

>
> I really like Fedora's model, the use of SELinux in enforcing mode,
> and Fedora's desire to provide the latest versions of software. In
> fact, I run Fedora Workstations to test the latest GCC compilers, and
> Fedora Servers when I need a web server.
>
> I no longer bother with CentOS or Red Hat servers. I can't stand that
> antique software that makes you use Software Collections (SCL) to get
> something semi-modern. I gave up on CentOS and Red Hat servers when
> trying to get Mediawiki running on them. CentOS and Red Hat servers
> with their old software was just too much work.
>
> I also use Ubuntu workstations and servers. But every now and again
> you want the latest software for a server, and that's when you want to
> consider Fedora.
>
> [1] https://docs.fedoraproject.org/en-US/quick-docs/dnf-system-upgrade/
>
> Jeff
>
> --
> 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

-- 
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

Re: Change unattended-upgrades from Depends to Recommends on ubuntu-server-minimal

[Dan Streetman]

On Thu, Dec 16, 2021 at 6:18 PM Steve Langasek
 wrote:
>
> Matthew, Jay, thanks for pressing on this.
>
> On Tue, Dec 14, 2021 at 05:36:15PM -0800, Jay Vosburgh wrote:
> > Steve Langasek  wrote:
>
> > >Hi Matthew,
>
> > >On Tue, Dec 14, 2021 at 03:28:32PM +1300, Matthew Ruffell wrote:
>
> > >It's not necessary to remove the unattended-upgrades package in order to
> > >achieve this.  unattended-upgrades is configurable, and it's sufficient to
> > >set 'APT::Periodic::Unattended-Upgrade "0";' in
> > >/etc/apt/apt.conf.d/20auto-upgrades (or, in a separate file that sorts
> > >lexically after, if that works better for the user's configuration
> > >management system) to disable unattended-upgrades at runtime.
>
> > >Therefore I do not think we should relax the dependency for this use case.
>
> >   It is a change in the expectations and established practice for
> > enterprise deployments who manage their own upgrades (i.e., currently
> > they can simply remove unattended-upgrades and require no further action
> > ever).
>
> While this may be the case, I don't think the Ubuntu development team was
> consulted before this became "established practice", either.  I certainly
> would have given the same answer then as now: opting out of
> unattended-upgrades should be done by configuring the software, not by
> removing packages from the system.

Hmm.

I'm going to reply here by asking "What Would Linus Do" (I'm from the
"south" in the USA so the phrase is borrowed from WWJD, though I'm not
religious and not implying anything religious here...)

I think there is a relevant youtube video that might answer that question here:
https://youtu.be/qHGTs1NSB1s?t=42

I suspect you might already be aware of that clip ;-)

In any case, I think we really should consider his statement; he wants
the distribution to be "easy" so he can "get on with [his] life".

Just like Linus, users of Ubuntu also want the distribution to "be
easy" so they can "get on with their [business]". If the easiest and
simplest way to avoid unexpected package upgrades is to uninstall
unattended-upgrades, that's what they are going to do, and it doesn't
particularly matter if we would prefer that they manually figure out
how to configure U-A to not actually run instead of uninstalling it.

Stated more simply, do you think Linus would want to take the time to
understand how to configure U-A not to run instead of simply
uninstalling it?

We might want all our users to take the time to understand the nuances
of our "required" software, but they won't. Not all of them. We should
consider the impact on them in this situation.

Also note I'm not making any kind of statement about U-A itself; there
is obvious and significant benefit to having security (and other)
updates automatically installed; I'm only talking about Ubuntu users
who have made the choice to opt-out of what U-A provides, for whatever
reason. And that isn't necessarily a bad choice - large deployments
really *do not* want software changing outside of predefined
maintenance windows, where actual admins are online to handle any kind
of issues caused by the upgrades. That's obviously not the only case
where unattended upgrades are not desirable, but a very frequent and
large example.

>
> >   Is there a benefit to having u-u dependent on the server-minimal
> > metapackage?
>
> In general, I would say the benefit is reduced overall proliferation of
> variations of installs wrt what software is or isn't installed.
>
> >   Is there a risk that package upgrades to u-u could reenable it?
>
> There is always risk of bugs.  Not respecting user configuration on upgrade
> is unambiguously a bug.  It is not a class of bug we are particularly likely
> to see in well-maintained core packages in Ubuntu (nor do we have a history
> of such bugs occurring).
>
>
> On Wed, Dec 15, 2021 at 05:40:21PM +1300, Matthew Ruffell wrote:
>
> > Our Enterprise users with larger deployments may not want to risk having the
> > package installed, since a package upgrade might overwrite the configuration
> > file or accidentally trigger the apt-daily-upgrade.timer, which could lead 
> > to
> > unplanned upgrades and service restarts taking place.
>
> They've chosen to use Ubuntu as their OS, and at the end of the day they
> need to have SOME trust in their OS provider.  I see no reason to be more
> concerned about this entirely hypothetical class of bug being introduced
> than any other.
>
> Also I would note that the apt-daily-upgrade timer is shipped in the apt
> package, not in unattended-upgrades...
>
> > There is also a distinct lack of consistency as well.
>
> > For example, on Jammy Desktop:
>
> > $ sudo apt remove unattended-upgrades
> > Reading package lists... Done
> > Building dependency tree... Done
> > Reading state information... Done
> > The following packages will be REMOVED:
> >   unattended-upgrades
> > 0 upgraded, 0 newly installed, 1 to remove and 18 not upgraded.
> > After this operation, 446 kB disk 

Re: Core Dev application: Paride Legovini (paride)

[Dan Streetman]

On Fri, Dec 3, 2021 at 8:20 AM Paride Legovini  wrote:
>
> Dear DMB,
>
> I hereby apply to become a Core Developer:

At the DMB meeting on 2021-12-13, as well as after the meeting in
email to the mailing list, your application for Ubuntu Core Developer
was unanimously approved (excluding abstentions).

Congratulations!

>
> https://wiki.ubuntu.com/ParideLegovini/UbuntuCoreDeveloperApplication
>
> I have added myself to the agenda for the 2021-12-13 meeting.
>
> Thanks you,
>
> Paride
>
> --
> Devel-permissions mailing list
> devel-permissi...@lists.ubuntu.com
> Modify settings or unsubscribe at: 
> https://lists.ubuntu.com/mailman/listinfo/devel-permissions

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

Re: Ubuntu Server Developer application

[Dan Streetman]

On Wed, Dec 1, 2021 at 5:48 PM Athos Ribeiro
 wrote:
>
> Hello,
>
> I hereby apply for membership as an Ubuntu Server package set uploader.

At the DMB meeting on 2021-12-13, by unanimous vote your application
was approved. Congratulations!

>
> My application is available at
>
> https://wiki.ubuntu.com/AthosRibeiro/UbuntuServerDeveloperApplication
>
> I have added an entry for my application to the DMB meeting agenda for
> 2021-12-13 at
>
> https://wiki.ubuntu.com/DeveloperMembershipBoard/Agenda
>
> Best regards,
>
> --
> Athos Ribeiro
>
> --
> Devel-permissions mailing list
> devel-permissi...@lists.ubuntu.com
> Modify settings or unsubscribe at: 
> https://lists.ubuntu.com/mailman/listinfo/devel-permissions

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

Re: Setting NotAutomatic for hirsute+1-proposed

[Dan Streetman]

On Fri, Dec 10, 2021 at 9:10 AM Robie Basak  wrote:
>
> On Thu, Dec 09, 2021 at 04:27:31PM +, Colin Watson wrote:
> > This is now ready to use from the Launchpad point of view.  There's a
> > "proposed_not_automatic" flag on distro series exported over the API; if
> > this is set to True, Launchpad writes "NotAutomatic: yes" and
> > "ButAutomaticUpgrades: yes" to the Release file.  We've also arranged
> > for *-proposed to be pinned to 500 in launchpad-buildd, so Launchpad
> > builds will ignore this; I can't speak for other build environments.
> >
> > Thus, from the Launchpad point of view this is ready to use, although
> > somebody may want to check the behaviour of things like sbuild and
> > pbuilder first.
>
> Thank you Colin for the work!
>
> If sbuild/pbuilder need adjusting, then maybe we need to do that and
> then give developers some time to update their chroots so that we don't
> break them (in non-obvious ways) all at once.
>
> Another thought is that if there turns out to be an unintended
> consequence for users enabling jammy-proposed (after Jammy's release),
> then we'll have done that to them in an LTS instead of hitting an
> interim release first.

This is certainly a concern for me...this kind of change seems like
it's more appropriate for an interim release.

> That might adversely affect SRU verification
> workflow. But given that jammy-proposed is (after release) specifically
> for opt-in and more-risky-than-stable testing, perhaps that doesn't
> warrant delaying until Keen.
>
> --
> technical-board mailing list
> technical-bo...@lists.ubuntu.com
> https://lists.ubuntu.com/mailman/listinfo/technical-board

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

Re: Setting NotAutomatic for hirsute+1-proposed

[Dan Streetman]

On Mon, Dec 13, 2021 at 9:04 AM Colin Watson  wrote:
>
> On Mon, Dec 13, 2021 at 08:32:53AM -0500, Dan Streetman wrote:
> > Just to clarify, people won't need to manually specify all
> > dependencies, right? For example, if testing the 'systemd' package
> > from -proposed, simply doing 'apt install systemd/jammy-proposed'
> > would install the proposed version of systemd *and also* the proposed
> > version of libsystemd0?
>
> That's how it behaves in my tests, yes - if a dependency imposes a
> version constraint requiring a lower-priority version, then apt tries to
> satisfy it.
>
> > Also, is this really needed? Is it really so hard for people to just do:
> >
> > $ sudo add-apt-repository -p proposed
> >
> > ...install proposed package(s) normally and do tests...
> >
> > $ sudo add-apt-repository -r -p proposed
>
> This has been an issue on and off for at least a decade, so my
> impression is that we have solid empirical evidence that this is indeed
> too hard for many testers in practice.

Ok, but the (non-graphical) method of enabling/disabling the proposed
pocket is quite painful on focal and earlier, so maybe now that users
can simply use add-apt-repository to enable/disable it with a 1-line
command, it might not be as much of an issue?

Updating the 'EnableProposed' wiki page might help, since currently it
seems hugely over-complicated and out of date.

Anyway, if the change is made so apt treats the proposed pocket the
same as the backports pocket, i assume (hope) all new systems will
have the proposed pocket enabled by default in their sources.list?

>
> --
> Colin Watson (he/him)  [cjwat...@ubuntu.com]
>
> --
> technical-board mailing list
> technical-bo...@lists.ubuntu.com
> https://lists.ubuntu.com/mailman/listinfo/technical-board

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

Re: Setting NotAutomatic for hirsute+1-proposed

[Dan Streetman]

On Thu, Dec 9, 2021 at 11:27 AM Colin Watson  wrote:
>
> On Wed, Feb 03, 2021 at 11:12:57AM +, Iain Lane wrote:
> > I think the Launchpad support is still missing, although we started on
> > this several years ago. That will need to be picked up and finished off:
> >
> >   https://bugs.launchpad.net/launchpad/+bug/1016776
> >
> > That bug report talks about doing it pre-release (for devel only) but I
> > think I'm now in favour of doing it always, and the proposed
> > implementation in there would allow that. For devel, the main reason is
> > that I frequently come across users who have misunderstood what proposed
> > is for and manually enabled it themsleves, resulting in various degrees
> > of brokenness on their systems and bug reports that take developers'
> > time to triage and eventually close. These are not (always) people who
> > have updated from a previous release, where we could have had tools
> > disable -proposed for them, but also people who have explicitly turned
> > it on after installing a daily out of an attempt to help test the
> > upcoming release.
> >
> > On the client side, as Robie says, we will at least need to update
> > documentation. I'm also not sure what update-manager will do if there
> > are NotAutomatic updates present. It might need some tweaking to show
> > them differently. This could be checked by looking at something in
> > -backports, which is already present with these flags set.
> >
> > And finally, there's some implication for package builds; both Launchpad
> > buildds and other builders would need to ignore this. Launchpad does
> > this for -backports currently, i.e. -backports builds get Build-Depends
> > from -backports wholesale; hoepfully that means the buildd side isn't
> > too hard because we can reuse that.
>
> This is now ready to use from the Launchpad point of view.  There's a
> "proposed_not_automatic" flag on distro series exported over the API; if
> this is set to True, Launchpad writes "NotAutomatic: yes" and
> "ButAutomaticUpgrades: yes" to the Release file.  We've also arranged
> for *-proposed to be pinned to 500 in launchpad-buildd, so Launchpad
> builds will ignore this; I can't speak for other build environments.

Just to clarify, people won't need to manually specify all
dependencies, right? For example, if testing the 'systemd' package
from -proposed, simply doing 'apt install systemd/jammy-proposed'
would install the proposed version of systemd *and also* the proposed
version of libsystemd0?

Also, is this really needed? Is it really so hard for people to just do:

$ sudo add-apt-repository -p proposed

...install proposed package(s) normally and do tests...

$ sudo add-apt-repository -r -p proposed

>
> Thus, from the Launchpad point of view this is ready to use, although
> somebody may want to check the behaviour of things like sbuild and
> pbuilder first.
>
> Somebody in ~techboard would need to make the actual change, if you
> think it's appropriate.  For example, the following in "lp-shell
> production devel" would do it for all supported Ubuntu series:
>
>   for name in ("bionic", "focal", "hirsute", "impish", "jammy"):
>   series = lp.distributions["ubuntu"].getSeries(name_or_version=name)
>   series.proposed_not_automatic = True
>   series.lp_save()
>
> --
> Colin Watson (he/him)  [cjwat...@ubuntu.com]
>
> --
> technical-board mailing list
> technical-bo...@lists.ubuntu.com
> https://lists.ubuntu.com/mailman/listinfo/technical-board

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

Re: Add ubuntu-advantage-tools to Recommends on ubuntu-minimal

[Dan Streetman]

On Tue, Nov 23, 2021 at 4:51 AM Lucas Moura  wrote:
>
> Hi everyone,
>
> Recently, we have received a request about moving ubuntu-advantage-tools from 
> Depends to Recommends on ubuntu-minimal and update-manager as can be seen 
> here:
> https://bugs.launchpad.net/ubuntu/+source/ubuntu-advantage-tools/+bug/1950692
>
> The problem today of ubuntu-advantage-tools sitting on Depends is that 
> removing this package will also trigger the removal of several core Ubuntu 
> packages on the system as well.

This isn't the *only* problem, as on do-release-upgrade all those
packages will be silently re-installed, e.g.:
https://bugs.launchpad.net/ubuntu/+source/netplan.io/+bug/1845234

I'd support the change to Recommends for ubuntu-advantage-tools, and
also netplan.io.

>
> We want to ask for opinions of this change to other Ubuntu developers, to see 
> if we are not missing any other aspect around the original decision to 
> include the package into Depends.
>
> Best regards,
> Lucas Moura
> --
> ubuntu-devel mailing list
> ubuntu-devel@lists.ubuntu.com
> Modify settings or unsubscribe at: 
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

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

Re: git-ubuntu rich history beta

[Dan Streetman]

On Wed, Oct 13, 2021 at 12:52 PM Robie Basak  wrote:
>
> git-ubuntu is now able to accept rich history directly from any uploader.
>
> The CLI is in beta and subject to change. Feedback appreciated!
>
> # Summary
>
> sudo snap refresh --beta git-ubuntu  # beta channel snap required

sorry to bring this up.

I recently reinstalled my system (hardware upgrades) and I have
completely removed snap, and I don't plan to reinstall it or use any
snaps in the future. Is there any place I can get 'git-ubuntu' without
using snaps?

>
> git ubuntu clone foo
> cd foo
> 
> dpkg-buildpackage  $(git ubuntu prepare-upload args)
> 
>
> Alternatively, if you don't use dpkg-buildpackage, you can prepare your
> source upload as usual, use
> `git ubuntu prepare-upload mangle <../changes file here>` to add the
> extra headers, sign (or re-sign) the changes file with `debsign` and
> then upload as usual.
>
> # CLI Design
>
> Ubuntu developers tend to have complex and custom workflows. To try and
> support them all, I've started by implementing the low level first. I
> didn't want to wrap everything and assume that you generate the changes
> file in some particular way. The `prepare-upload` subcommand is intended
> for integration and wrapping by your own tooling. I suggest you make an
> alias or wrapper script to operate it in the way that you want.
>
> Eventually I expect a high level CLI such as `git ubuntu submit` to do
> all the work for you, but I want to get the low level stuff right first.
>
> # Details of what the subcommands do
>
> There are two subcommands being added here: `git ubuntu prepare-upload
> args` and `git ubuntu prepare-upload mangle`. Both will push the current
> branch to a personal remote (defaulting to your personal Launchpad
> namespace that `git ubuntu clone` sets up named after your Launchpad
> username; details overridable with `--remote` and `--branch`). After
> that, `args` will output the required additional changes file headers in
> a form suitable for `dpkg-buildpackage`. `mangle` will instead replace
> an existing changes file to add the headers, stripping the signature if
> it was signed (as the alteration requires re-signing).
>
> # Details of the changes file headers
>
>  * Vcs-Git: points to the git repository where the rich history can be
>found.
>
>  * Vcs-Git-Ref: the ref which when fetched contains the rich history.
>
>  * Vcs-Git-Commit: the commit hash of your rich history. This must match
>your upload.
>
> When git-ubuntu imports your upload, it will look in the location
> specified by these headers for the rich history. If present and if they
> match your upload, then it will use your commit instead of synthesizing
> its own.
>
> # Caveats
>
>  * If empty directories exist in your source, then your rich history
>will likely mismatch and will be rejected. A synthesized commit will
>be used instead. git-ubuntu will warn you if this is about to happen
>if you used `git-ubuntu clone`. See LP: #1917877 for details and a
>workaround.
>
>  * Note that error paths are not currently well handled. I intend to fix
>these before a final release. I'd appreciate feedback on what edge
>cases you hit, so I can make sure I handle those.
>
>  * For now, only Launchpad git URLs are accepted to avoid the risk from
>a malicious git repository host. `git-ubuntu prepare-upload` will
>check that the URL will be acceptable.
> --
> ubuntu-devel mailing list
> ubuntu-devel@lists.ubuntu.com
> Modify settings or unsubscribe at: 
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

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

+1 maintenance report

[Dan Bungert]

Hi All,

### crowdsec ###

I started this last cycle, a month ago, and wanted to continue now that we're
in the JJ cycle.  This boils down to the golang-github-docker-docker-dev
package containing some vendored source, which causes problem for crowdsec, but
unvendoring that means other packages need changes.  I continued on this topic
and produced a workable package set requiring changes to 12 packages in total,
using a mix of changes to build-depends, syncing a new version from Debian, and
removing vendored source from two packages.  Two other packages are listed in
reverse build depends but are unaffected by the unvendoring.  I'm attempting to
get this fix set started by upstreaming build-dep changes to Debian, since that
is compatible both with the current docker.io and a devendored version.
LP: #1946376 has more details.

### firewalld ###

Network-manager configuration seems to be conflicting with some of the
integration tests.  Setting more configuration has allowed the failing
integration test to pass.  Upstream process started:
https://github.com/firewalld/firewalld/pull/880

Patch uploaded by LocutusOfBorg, thanks for the prompt upload!
Thanks also to TJ, who had this bug all but figured out.
LP: #1945596 has more details.

### thin-provisioning-tools ###

A no-change rebuild failed, seemingly for g++ 11 where the original version was
done with g++ 10.  LP: #1950028 opened.

-Dan

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

Re: OpenSSL 3.0 transition plans

[Dan Streetman]

On Thu, Oct 7, 2021 at 10:31 AM Simon Chopin  wrote:
>
> Hi all,
>
> As some of you might have surmised, we're planning to move to OpenSSL
> 3.0 [0] for 22.04. This new major release brings of course some new
> things, but also breaks API and ABI.

If/when we get to 3.0, please do let upstream systemd know, as Ubuntu
is the last blocker holding up the transition from gcrypt over to
openssl in systemd.
https://github.com/systemd/systemd/pull/14743#issuecomment-748078464


>
> We intend to update the openssl package to 3.0.0 as soon as possible in
> the 22.04 cycle, provided that all the build-rdepends of libssl-dev in
> main are ready for the transition. You'll find at [1] the latest test
> rebuild, where you'll find that around 35 rdeps from main, and ~180
> packages from universe fail to build. This test build has been done in
> the PPA schopin/openssl-3.0.0 [2], which you can use to test your
> packages against.
>
> If you'd like to help out (please do ;-)), I've started filing bugs
> against the various packages that fail, using the tag
> 'transition-openssl3-jj' [3] to track it all. Please use this tag when
> working on this issue. You'll find resources to migrate codebases from
> 1.1 in the OpenSSL man pages[4].
>
> As stated, the transition should only take place if main is ready for
> it. As far as universe is concerned, in an ideal world all the 180
> packages above would be fixed in time for the release. However, if not
> so, we'll either remove the package from the release or, if *really*
> necessary, would introduce a compatibility openssl-1.1 package. The
> latter option is of course highly undesirable.
>
> When we'll upload the new version of openssl to the archive, existing
> packages should still be installable as the binaries for libssl1.1 will
> be kept around as long as they're depended on. However, the autopkgtests
> of packages lagging in the transition, or even of their rdeps, might
> start to fail if they build the tests during the autopkgtests. If that's
> the case, you might want to get the package rebuilt against OpenSSL3 and
> rerun the tests with all-proposed=1.
>
> Cheers,
> Simon Chopin
>
> [0]: https://www.openssl.org/blog/blog/2021/09/07/OpenSSL3.Final/
> [1]: https://people.canonical.com/~schopin/rebuilds/openssl-3.0.0-impish.html
> [2]: https://launchpad.net/~schopin/+archive/ubuntu/openssl-3.0.0
> [3]: https://bugs.launchpad.net/ubuntu/+bugs?field.tag=transition-openssl3-jj
> [4]: https://www.openssl.org/docs/manmaster/man7/migration_guide.html
>
> --
> ubuntu-devel mailing list
> ubuntu-devel@lists.ubuntu.com
> Modify settings or unsubscribe at: 
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

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

+1 report

[Dan Bungert]

Hi All,

I was on +1 this week.  I had hoped to get a bit more +1 done but release prep
will not be denied.

### rust-alacritty-terminal ###

I looked at this and judged that it wasn't helping, due to failure to build, no
binaries, no reverse depends.  Removed as requested in LP: #1946008.

### rust-proc-macro2 ###

This was given a quick retest (thanks Graham) but it's still failing
consistently.  This package attemps to use a byte span facility and the numbers
don't match up.  Basic builds with raw upstream source and non-Ubuntu rust
stack see fine.  Filed LP: #1946613

### crowdesc ###

This one seems to have a build conflict with the vendored source contained in
golang-github-docker-docker-dev.  I ran thru a proposed test rebuild to remove
this vendored source from golang-github-docker-docker-dev (LP: #1946376),
however this apparently was added in the first place to fix a podman build, so
I think there are more packages that I didn't find in reverse depends.  I
suggest this be looked at during the JJ cycle.

### paperwork ###

I gave this some test rebuilds on armhf.  Upstream is able to reproduce this
now as well.
https://gitlab.gnome.org/World/OpenPaperwork/paperwork/-/issues/981

-Dan

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

Re: SRU developer application

[Dan Streetman]

On Thu, Aug 5, 2021 at 10:10 AM Heitor Alves de Siqueira
 wrote:
>
> Hi,
>
> I would like to apply for the SRU Developer role, and have added myself to the
> DMB agenda for the meeting on the 23rd of August.
>
> My application can be found here:
> https://wiki.ubuntu.com/halves/sru-developer

At today's DMB meeting, the board voted unanimously to approve your
application for Ubuntu SRU Developer.

Congratulations!

>
> Cheers,
> Heitor
>
> --
> Devel-permissions mailing list
> devel-permissi...@lists.ubuntu.com
> Modify settings or unsubscribe at: 
> https://lists.ubuntu.com/mailman/listinfo/devel-permissions

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

Re: Plan to reform the Ubuntu Backporters Team [was: Proposal: sunset the backports pockets]

[Dan Streetman]

On Mon, Aug 9, 2021 at 5:51 PM Dan Streetman  wrote:
>
> On Wed, Jul 28, 2021 at 11:40 AM Dan Streetman  wrote:
> >
> > On Wed, Jul 28, 2021 at 10:20 AM Robie Basak  wrote:
> > >
> > > On Thu, Jul 22, 2021 at 05:00:26PM -0400, Dan Streetman wrote:
> > > > So as far as next steps based on your proposal, it seems like:
> > >
> > > I detailed the next steps specifically in my proposal but focused on
> > > slightly different things, so I appreciate you laying out your
> > > perspective also. What you suggest here is essentially the same anyway.
> >
> > sorry yes you did, agreed that my list was essentially the same as yours
> >
> > >
> > > > 1) Open call for initial volunteers
> > > > - I volunteer for the leadership role (at least for the initial
> > > > re-establishment), assuming there are no objections
> > >
> > > Looks like there have been no objections. To be clear, I understand that
> > > you're also volunteering for the day-to-day role?
> >
> > yes
> >
> > >
> > > > - mapreri volunteers for day-to-day role (thanks Mattia!)
> > > > - this email thread seems like a good enough call to the community for
> > > > anyone else who wants to volunteer, either in a leadership role or
> > > > day-to-day role
> > >
> > > +1. It appears that Mattia and Dan are currently the only volunteers.
> > >
> > > > 2) Administrative changes to ~ubuntu-backporters
> > > > - I don't see any public documentation on an existing process for
> > > > membership changes to ~ubuntu-backporters, so I assume your proposal
> > > > along with the disussion here is enough justification to ask the TB to
> > > > make the changes, assuming there is no objection from the TB of
> > > > course, or from existing active members (Laney I assume all this
> > > > sounds ok to you?)
> > >
> > > There has been no objection, so I intend to make the changes as agreed
> > > in this thread as soon as ~techboard gets control of the team. Since
> > > there is consensus here, I see no need to ask for TB permission
> > > specifically (or, if you prefer to consider it this way, I will use my
> > > TB hat to JFDI).
> > >
> > > I haven't managed to reach ScottK who currently owns the
> > > ~ubuntu-backporters team. However he stepped away from Ubuntu
> > > development quite a long time ago, and I don't think he would have any
> > > objection to handing over the reins to ~techboard. So I filed
> > > https://answers.launchpad.net/launchpad/+question/698165 yesterday to
> > > request this change.
> > >
> > > Assuming the change is made, following my proposal detail, I intend to
> > > remove everyone from ~ubuntu-backports and add Dan as its sole admin,
> > > and then let Dan take it from there (I assume he will add Mattia as a
> > > team member, and maybe Iain).
> > >
> > > If we can't have ~ubuntu-backporters, I suppose I could register
> > > ~ubuntu-backporters2 and swap the queue ACLs over, but this seems
> > > unlikely (and suboptimal).
> >
> > +1 all sounds good to me
> >
> > >
> > > > 3) New team has initial public irc meeting (and email/chat
> > > > communication as needed) to make any process reforms (membership,
> > > > backports process, etc)
> > > > 4) update public documentation
> > > > 5) New team starts work on reviewing backports
> > > >
> > > > does that seem correct?
> > >
> > > This sounds good to me. These steps 3-5 would be for you (Dan) to
> > > organise.
> >
> > I'm fine with Mattia's suggestion for the first irc mtg the week of
> > Sept 6-10; my TZ is us/eastern (currently UTC-4) so my preference
> > would be anytime between 12:00 and 22:00 UTC, but I could push that a
> > bit earlier or later if needed.
> >
> > mapreri, teward, any preference on the day and/or time for the first
> > mtg? Does Wed, Sept 8 at 14:00 UTC sound ok?
>
> It sounds like both of you prefer this time or (preferably) later, so
> would Sept 8 at 16:00 UTC be agreeable for you? That's right in the
> middle of my day.
>
> Iain, and Robie if you plan to join, would that work for you as well?

Assuming there's no objecting to the proposed time, Sept 8 at 16:00
UTC, I've added it to the Ubuntu Fridge, and created an initial agenda
page:
https://wiki.ubuntu.com/UbuntuBackports/Agenda

Please feel free to update the agenda page with any topics anyone
thinks should be discussed at the meeting, and/or just show up to the
meeting to discuss anything - I think there are a few main items we
should talk about at this first meeting, but I don't think we
necessarily need a strict agenda.

Thanks!

>
> >
> > >
> > > Thanks,
> > >
> > > Robie

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

Re: Results of archive rebuild against OpenSSL3

[Dan Streetman]

On Tue, Aug 10, 2021 at 4:09 AM Simon Chopin  wrote:
>
> Hello,
>
> As some of you may be aware, the OpenSSL project is working towards a
> major OpenSSL 3.0 version, which will not be ABI compatible with
> the current 1.1 branch[0]. They have recently released a first Release
> Candidate version[1], and in order to prepare for a stable release, I've
> uploaded a version of this release candidate on a PPA, based on the
> Debian Experimental version[2].
>
> I have also uploaded to this PPA all packages currently in impish that
> have a direct reverse-dependency on libssl-dev, to assess the amount of
> breakage such a transition would bring. You'll find the result at [3],
> but please bear in mind that it is a really rough experiment, so it's
> likely that I've missed some dependencies, or that some build failures
> aren't related to OpenSSL at all.
>
> Note that there aren't any concrete plans for OpenSSL3 in Ubuntu *yet*,
> so don't panic. This work has been done in order to assess the amount of
> work involved in such migration.

So, is this planned for the 22.04 release?

Back in 18.04, there was a similar abi-breaking change between 1.0 and
1.1, and the resulting conflict between the libssl-dev and
libssl1.0-dev packages was quite painful to many people and never
actually resolved:
https://bugs.launchpad.net/ubuntu/+source/openssl1.0/+bug/1794589

I would hate to see that happen again in 22.04.

>
> Also, since the rebuild has been done in a PPA, I had to tweak the
> report script quite a bit, so some of its features might not have been
> working properly.
>
> Cheers,
> Simon
>
> [0]: https://wiki.openssl.org/index.php/OpenSSL_3.0
> [1]: https://www.openssl.org/blog/blog/2021/06/17/OpenSSL3.0ReleaseCandidate/
> [2]: 
> https://launchpad.net/~schopin/+archive/ubuntu/openssl3/+sourcepub/12547808/+listing-archive-extra
> [3]: https://people.canonical.com/~schopin/rebuilds/openssl3-impish.html
>
> --
> ubuntu-devel mailing list
> ubuntu-devel@lists.ubuntu.com
> Modify settings or unsubscribe at: 
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

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

Re: Plan to reform the Ubuntu Backporters Team [was: Proposal: sunset the backports pockets]

[Dan Streetman]

On Wed, Jul 28, 2021 at 11:40 AM Dan Streetman  wrote:
>
> On Wed, Jul 28, 2021 at 10:20 AM Robie Basak  wrote:
> >
> > On Thu, Jul 22, 2021 at 05:00:26PM -0400, Dan Streetman wrote:
> > > So as far as next steps based on your proposal, it seems like:
> >
> > I detailed the next steps specifically in my proposal but focused on
> > slightly different things, so I appreciate you laying out your
> > perspective also. What you suggest here is essentially the same anyway.
>
> sorry yes you did, agreed that my list was essentially the same as yours
>
> >
> > > 1) Open call for initial volunteers
> > > - I volunteer for the leadership role (at least for the initial
> > > re-establishment), assuming there are no objections
> >
> > Looks like there have been no objections. To be clear, I understand that
> > you're also volunteering for the day-to-day role?
>
> yes
>
> >
> > > - mapreri volunteers for day-to-day role (thanks Mattia!)
> > > - this email thread seems like a good enough call to the community for
> > > anyone else who wants to volunteer, either in a leadership role or
> > > day-to-day role
> >
> > +1. It appears that Mattia and Dan are currently the only volunteers.
> >
> > > 2) Administrative changes to ~ubuntu-backporters
> > > - I don't see any public documentation on an existing process for
> > > membership changes to ~ubuntu-backporters, so I assume your proposal
> > > along with the disussion here is enough justification to ask the TB to
> > > make the changes, assuming there is no objection from the TB of
> > > course, or from existing active members (Laney I assume all this
> > > sounds ok to you?)
> >
> > There has been no objection, so I intend to make the changes as agreed
> > in this thread as soon as ~techboard gets control of the team. Since
> > there is consensus here, I see no need to ask for TB permission
> > specifically (or, if you prefer to consider it this way, I will use my
> > TB hat to JFDI).
> >
> > I haven't managed to reach ScottK who currently owns the
> > ~ubuntu-backporters team. However he stepped away from Ubuntu
> > development quite a long time ago, and I don't think he would have any
> > objection to handing over the reins to ~techboard. So I filed
> > https://answers.launchpad.net/launchpad/+question/698165 yesterday to
> > request this change.
> >
> > Assuming the change is made, following my proposal detail, I intend to
> > remove everyone from ~ubuntu-backports and add Dan as its sole admin,
> > and then let Dan take it from there (I assume he will add Mattia as a
> > team member, and maybe Iain).
> >
> > If we can't have ~ubuntu-backporters, I suppose I could register
> > ~ubuntu-backporters2 and swap the queue ACLs over, but this seems
> > unlikely (and suboptimal).
>
> +1 all sounds good to me
>
> >
> > > 3) New team has initial public irc meeting (and email/chat
> > > communication as needed) to make any process reforms (membership,
> > > backports process, etc)
> > > 4) update public documentation
> > > 5) New team starts work on reviewing backports
> > >
> > > does that seem correct?
> >
> > This sounds good to me. These steps 3-5 would be for you (Dan) to
> > organise.
>
> I'm fine with Mattia's suggestion for the first irc mtg the week of
> Sept 6-10; my TZ is us/eastern (currently UTC-4) so my preference
> would be anytime between 12:00 and 22:00 UTC, but I could push that a
> bit earlier or later if needed.
>
> mapreri, teward, any preference on the day and/or time for the first
> mtg? Does Wed, Sept 8 at 14:00 UTC sound ok?

It sounds like both of you prefer this time or (preferably) later, so
would Sept 8 at 16:00 UTC be agreeable for you? That's right in the
middle of my day.

Iain, and Robie if you plan to join, would that work for you as well?

>
> >
> > Thanks,
> >
> > Robie

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

Re: Plan to reform the Ubuntu Backporters Team [was: Proposal: sunset the backports pockets]

[Dan Streetman]

On Fri, Jul 30, 2021 at 12:11 PM Robie Basak  wrote:
>
> Hi Iain,
>
> Perhaps I see the situation differently from you. From my perspective,
> this is an extraordinary intervention "from above" by consensus from
> Ubuntu developers. The backporters team has been unable to act for an
> extended period of time, and when threatened with closure, nobody from
> the team has been able to volunteer to continue in any role, let alone a
> leadership role. Others _have_ volunteered; therefore the team is being
> replaced.
>
> Nothing stops previous team members from continuing, subject to any
> requirements from _new_ team leadership, but they haven't even
> volunteered to continue. From my perspective they have effectively
> resigned through their extended absence.
>
> On Fri, Jul 30, 2021 at 02:24:31PM +0100, Iain Lane wrote:
> > > Assuming the change is made, following my proposal detail, I intend to
> > > remove everyone from ~ubuntu-backports and add Dan as its sole admin,
> > > and then let Dan take it from there (I assume he will add Mattia as a
> > > team member, and maybe Iain).
> >
> > To be honest, I think you could - and I'd prefer it if you would - leave
> > this up to the team, especially if there are newly active members.
>
> From my perspective, this would be as if people who have neglected[1]
> matters for years, and effectively blocked progress, would be retaining
> their ability to block progress. This is why I'm against your
> suggestion.
>
> IMHO, previous team members who have not participated in this thread
> should therefore no longer have the status of being in the team. I agree
> with you to leave membership up to the team, but I might differ from you
> in that I want this to be up to the *new team*, not people who have
> their name attached but haven't done anything for the team in multiple
> years and are not stepping up to do so now. IMHO the old and inactive
> team members should, due to neglect[1], have no more say than the wider
> set of Ubuntu developers in this matter. I value their experience and
> opinions, but the final decision making should no longer be up to them
> due to their extended absence. IMHO, any previous backporters team
> member who doesn't want this to happen has had multiple opportunities to
> step up or speak up, and has not done so.
>
> You, Iain, are an exception because you have actually participated in
> the conversation. Thank you :)
>
> Further IMHO, I think having old inactive members there is harmful. For
> example, for years people have been blocked on backports under the
> illusion that the team exists and team members just need to appear to
> review and approve their stuff. In reality, the team ceased to exist
> years ago; it was just Launchpad that was behind. If the team membership
> in Launchpad had been empty accordingly, we'd probably have sought to
> address the situation much sooner.
>
> So, my proposal is to empty the team membership, _once_, as part of this
> revitalisation. IMHO, only those volunteering to do the whole task of
> resurrecting the backports process (so far that's just Dan) should
> really have a decision making power here, since they are the only ones
> actually taking responsibility. Then the new team members will manage
> the team membership list as they feel appropriate.
>
> > I'd like to talk with the new team about this, but I'm personally not
> > interested in participating in the current process. It's broken by
> > design IMO. I'd be interested in participating in creating a reformed
> > process and more than happy to explain to the team what I consider to be
> > wrong with the way things are now, but I'll probably not be leading any
> > reform efforts myself just for spoons reasons. On that basis I'd be OK
> > stepping down from being an administrator, and possibly leaving the team
> > altogether, depending on what the active members consider their
> > priorities to be.
>
> Thank you for staying involved! Under my proposal I would expect you to
> end up being re-added, but I think that would/should be entirely up to
> the new team to decide. Specifically this is because if you're unable to
> help drive the reform, then that's fine but I think that also means that
> you cannot also be a decision-maker as to whether you get re-added or
> not. That would be up to those who _are_ driving the reform, since part
> of their remit and responsibility is to drive the process for team
> membership.
>
> >   Again I'd prefer to work that out with the team rather
> > than the new owners doing this 'from above'.
>
> IMHO, that ship has sailed. The "from above" approach has become
&g

+1 maintenance report

[Dan Bungert]

+1 Maintenance Report
Dan Bungert, Jul-26-2021 - Jul-30-2021

# breezy #

Since Christian's report, Chris MacNaughton stopped by one of the LPs and
pointed to https://bugs.launchpad.net/ubuntu/+source/breezy/+bug/1932313 ,
which had some good info.  The recent python change where '.' in sys.path
can cause problems for module loading definitely affects breezy.  I was able to
verify that newer pythons, including main as of Tuesday, do not have this
resolved.  On the python mailing list was a discussion and a test case,
https://www.reportlab.com/ftp/timport-310b1.py
I spent some time cleaning that up but I found in my testing of the reportlab
case that it demonstrates a slightly different bug - their test case changes
from failing with the affected python versions to erratic failure, whereas
breezy seems ok with the good python versions and not erratic.

Suggested next steps are to extract a test case for submission to upstream
matching the breezy scenario, and consider incorporating a workaround like
https://bugs.launchpad.net/ubuntu/+source/breezy/+bug/1932313/comments/7

# delve #

Delve is failing on a test introduced with a new feature with version 1.6.1,
but only on arm.  I traced backwards thru the failing case (using delve) quite
a bit and eventually found that it was attempting to dump the mappings listed
in smaps, and on which mapping it was failing.  Delve does some filtering to
reduce which mappings get dumped - smaps does have a "dd" flag that is intended
to say "do not include area into core dump", but vvar in this case doesn't have
the flag, and it's working OK on older kernels.  Opened launchpad and upstream
issue with this information.  Upstream is considering also filtering on the
"pf" flag, which is present in the vvar mapping info on the failing kernels.

https://bugs.launchpad.net/ubuntu/+source/delve/+bug/1938474
https://github.com/go-delve/delve/issues/2630

# ncbi-blast+ vs cct #

The upstream change to ncbi-blast+ at 2.11 talks about some multithread
changes.  Like ginggs, I could see extended test times on cct (consistently 2x
in my case compared to ncbi-blast+ 2.10) but nowhere close to the extreme that
is seen in official autopkgtests.  I experimented with values of --cpus for
autopkgtest qemu, but didn't find anything interesting there.

ncbi-blast+ 2.12 is out but not yet in Debian.  I did a quick take getting 2.12
ncbi-blast+ packaged to see if that was better, but that failed with some
mbedtls link errors and I lost interest.

# golang-testify vs golang-github-uber-go-atomic #

golang-testify 1.6.1-2 had been blocked due to what looked like a test
regresion in go-atomic.  Really it seems to have been go 1.16 related.

The listed test failure in the logs
Error: "missing $GOPATH\n" does not contain
"struct containing nocmp cannot be compared"
was fixed upstream in version 1.8.0 of go-atomic.
https://github.com/uber-go/atomic/issues/82

I was able to get this to migrate by manual construction of retest URLs so that
testify was triggered with go-atomic 1.8.0.  Thanks bdmurrary for retest help.

# python-xarray #

I started looking at this and got as far as reproducing the issue, but that's
about it.  Upstream has 0.19 released, maybe that will help?

-Dan

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

Re: Plan to reform the Ubuntu Backporters Team [was: Proposal: sunset the backports pockets]

[Dan Streetman]

On Wed, Jul 28, 2021 at 10:20 AM Robie Basak  wrote:
>
> On Thu, Jul 22, 2021 at 05:00:26PM -0400, Dan Streetman wrote:
> > So as far as next steps based on your proposal, it seems like:
>
> I detailed the next steps specifically in my proposal but focused on
> slightly different things, so I appreciate you laying out your
> perspective also. What you suggest here is essentially the same anyway.

sorry yes you did, agreed that my list was essentially the same as yours

>
> > 1) Open call for initial volunteers
> > - I volunteer for the leadership role (at least for the initial
> > re-establishment), assuming there are no objections
>
> Looks like there have been no objections. To be clear, I understand that
> you're also volunteering for the day-to-day role?

yes

>
> > - mapreri volunteers for day-to-day role (thanks Mattia!)
> > - this email thread seems like a good enough call to the community for
> > anyone else who wants to volunteer, either in a leadership role or
> > day-to-day role
>
> +1. It appears that Mattia and Dan are currently the only volunteers.
>
> > 2) Administrative changes to ~ubuntu-backporters
> > - I don't see any public documentation on an existing process for
> > membership changes to ~ubuntu-backporters, so I assume your proposal
> > along with the disussion here is enough justification to ask the TB to
> > make the changes, assuming there is no objection from the TB of
> > course, or from existing active members (Laney I assume all this
> > sounds ok to you?)
>
> There has been no objection, so I intend to make the changes as agreed
> in this thread as soon as ~techboard gets control of the team. Since
> there is consensus here, I see no need to ask for TB permission
> specifically (or, if you prefer to consider it this way, I will use my
> TB hat to JFDI).
>
> I haven't managed to reach ScottK who currently owns the
> ~ubuntu-backporters team. However he stepped away from Ubuntu
> development quite a long time ago, and I don't think he would have any
> objection to handing over the reins to ~techboard. So I filed
> https://answers.launchpad.net/launchpad/+question/698165 yesterday to
> request this change.
>
> Assuming the change is made, following my proposal detail, I intend to
> remove everyone from ~ubuntu-backports and add Dan as its sole admin,
> and then let Dan take it from there (I assume he will add Mattia as a
> team member, and maybe Iain).
>
> If we can't have ~ubuntu-backporters, I suppose I could register
> ~ubuntu-backporters2 and swap the queue ACLs over, but this seems
> unlikely (and suboptimal).

+1 all sounds good to me

>
> > 3) New team has initial public irc meeting (and email/chat
> > communication as needed) to make any process reforms (membership,
> > backports process, etc)
> > 4) update public documentation
> > 5) New team starts work on reviewing backports
> >
> > does that seem correct?
>
> This sounds good to me. These steps 3-5 would be for you (Dan) to
> organise.

I'm fine with Mattia's suggestion for the first irc mtg the week of
Sept 6-10; my TZ is us/eastern (currently UTC-4) so my preference
would be anytime between 12:00 and 22:00 UTC, but I could push that a
bit earlier or later if needed.

mapreri, teward, any preference on the day and/or time for the first
mtg? Does Wed, Sept 8 at 14:00 UTC sound ok?

>
> Thanks,
>
> Robie

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

Re: Plan to reform the Ubuntu Backporters Team [was: Proposal: sunset the backports pockets]

[Dan Streetman]

On Wed, Jul 21, 2021 at 6:11 AM Robie Basak  wrote:
>
> Thank you for volunteering! As we have at least one qualified person
> committed, I'd be very happy to see the backports pocket continue. As a
> concrete proposal, I suggest we do this by reforming ~ubuntu-backporters
> as follows.
>
> In particular I wanted to enumerate a specific transition plan and the
> reformed team's responsibities below, since my opinion on sunsetting the
> backports pocket is only moot if this actually happens.
>
> Feedback appreciated!
>
> # Team Roles
>
> For clarity, initially there will be two roles in the team: 1) a
> leadership role, driving re-establishment and reform; 2) people doing
> the regular day-to-day work, such as reviews.
>
> I think the first role could only effectively be taken by suitably
> qualified, existing and established Ubuntu developers. We'll see if
> there are any other volunteers, and if there are, see if there is
> consensus that they can also take on the role.
>
> The second role would be open to anyone who meets the requirements of
> the new process, which is yet to be defined.
>
> To get started I suggest continuing the old process, while allowing for
> the new team's leadership to drive process reform.
>
> # Transition Plan
>
>  * This entire plan is predicated on there being at least one suitably
>qualified, experienced and established Ubuntu developer committed to
>taking on both roles. So far, that's Dan, but others may join him.
>
>  * ~techboard takes ownership of ~ubuntu-backporters.
>
>  * Existing but inactive team members are removed.
>
>  * Those that we have agreed will take on the first role are added as
>team admins.
>
>  * Those still active in the team and are willing to do the second role
>(if any; I think only Iain qualifies if he is willing) are added as
>regular team members.
>
>  * A process for future management of team membership would be up to the
>team itself to establish.
>
> # Team responsibilities
>
> Here I've tried to define what we need, rather than specify how the
> backporters team will deliver it. I'd prefer to leave the team to drive
> that. For example, Gunnar asked some good questions in the thread; I've
> deliberately not answered those, leaving that for the backporters team
> to figure out later as part of the process reform.
>
>  * Establish and manage an effective process to handle backport
>requests. Any review process must accept or reject every backport
>request on its technical merit, and be neutral to who is requesting
>it[1].
>
>  * Maintain the backports pocket based on this process, making sure that
>all requests receive an appropriate answer in a reasonable amount of
>time.
>
>  * Maintain quality in the backports pocket, where the definition of
>quality is driven by the team, but defined by consensus within the
>wider Ubuntu developer community.
>
>  * Handle your own process reform and membership management, but making
>sure that any responsibility can be carried by any contributor who
>demonstrates the required capacity and competence. Specifically,
>since the DMB has never managed membership of ~ubuntu-backporters,
>there is no requirement for the DMB to be involved. Unless you want
>to delegate that, in which case that's a conversation to have with
>the DMB.
>
> How does this sound? Feedback appreciated.

I'm in agreement with everything.

So as far as next steps based on your proposal, it seems like:

1) Open call for initial volunteers
- I volunteer for the leadership role (at least for the initial
re-establishment), assuming there are no objections
- mapreri volunteers for day-to-day role (thanks Mattia!)
- this email thread seems like a good enough call to the community for
anyone else who wants to volunteer, either in a leadership role or
day-to-day role
2) Administrative changes to ~ubuntu-backporters
- I don't see any public documentation on an existing process for
membership changes to ~ubuntu-backporters, so I assume your proposal
along with the disussion here is enough justification to ask the TB to
make the changes, assuming there is no objection from the TB of
course, or from existing active members (Laney I assume all this
sounds ok to you?)
3) New team has initial public irc meeting (and email/chat
communication as needed) to make any process reforms (membership,
backports process, etc)
4) update public documentation
5) New team starts work on reviewing backports

does that seem correct?

>
> Robie
>
>
> [1] To be clear, I believe that the current process requires
> sponsorship/upload of a suitable backport, and the backporters team only
> reviews once an upload has taken place. I am not

Re: Proposal: sunset the backports pockets

[Dan Streetman]

On Tue, Jul 20, 2021 at 8:38 AM Gunnar Hjalmarsson  wrote:
>
> On 2021-07-20 13:58, Dan Streetman wrote:
> > Yes, objection here. The backports pocket is still in use.
> >
> > If I understand correctly, as discussed in much greater length in
> > other posts in this thread, the sole problem with the backports
> > process is lack of time for the Ubuntu Backports Team to actually
> > review uploads to the -backports pocket.
> >
> > If that's the case, then the Canonical Sustaining Engineering Group
> > is happy to take that over (since 'sustaining' the stable releases
> > is...our job), please feel free to ping me about ACLs and process
> > tooling for approving -backports uploads and we'll start reviewing
> > the queues.
>
> That sounds promising, Dan.
>
> As regards uploads in the queues, I had a quick look yesterday. I found
> one item in bionic and four ones in focal. But only one (1) item had a
> reference to a bug report with the expected justification, test results etc.
>
> But then we have all the backport requests which are not yet uploaded:
>
> https://bugs.launchpad.net/bionic-backports
>
> https://bugs.launchpad.net/focal-backports
>
> <https://wiki.ubuntu.com/UbuntuBackports> gives the impression that the
> uploads should be carried out by an ~ubuntu-backporters member in
> connection with the review.
>
> So if the Canonical Sustaining Engineering Group steps up — which is
> excellent, of course — there still seems to be room for clarification of
> the process.
>
> * Who can/should upload?
>
> * Should sponsorship be sought for uploads to the -backports queues?

definitely good points to clarify, we should probably move any
clarifications over to rbasak's new thread

>
> --
> Cheers,
>
> Gunnar Hjalmarsson
> https://launchpad.net/~gunnarhj

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

Re: Proposal: sunset the backports pockets

[Dan Streetman]

On Mon, Jul 19, 2021 at 8:06 AM Robie Basak  wrote:
>
> Dear Ubuntu Developers,
>
> As far as I am aware, the Ubuntu Backports Team has been inactive for
> years now, and backports requests and uploads just languish in
> Launchpad. Thomas Ward last proposed an effort to revitalise it over two
> years ago, but with no response. I believe he's no longer available to
> contribute now.
>
> My concern is that the backports documentation and process still exist,
> so users and contributors are being misled into thinking that something
> will happen, when it won't.
>
> I would be very happy for the backports process to continue, but I think
> it's time to accept that it isn't happening, call a spade a spade, and
> shut the process down and document this properly to stop misleading
> users about it.
>
> For example, I just handled LP: #1902198 having received an out-of-band
> ping, and looking at https://bugs.launchpad.net/focal-backports there
> are multiple recent requests that we know are not going to be answered
> from a backports pocket perspective.
>
> Any objections? If you do object, please provide an alternative proposal
> that will mean that users stop getting misled.

Yes, objection here. The backports pocket is still in use.

If I understand correctly, as discussed in much greater length in
other posts in this thread, the sole problem with the backports
process is lack of time for the Ubuntu Backports Team to actually
review uploads to the -backports pocket.

If that's the case, then the Canonical Sustaining Engineering Group is
happy to take that over (since 'sustaining' the stable releases
is...our job), please feel free to ping me about ACLs and process
tooling for approving -backports uploads and we'll start reviewing the
queues.

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

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

+1 maintenance report

[Dan Bungert]

+1 Maintenance Report
Dan Bungert, Jun-03-2021 - Jun-04-2021

This go round I tried to focus more on moving a larger set of packages forward
and depend more on upstream to help debug issues.  A lot of the time was thus
transforming autopkgtest failures and generating more generic failure
scenarios.

### thin ###

I decided to start by continuing on this one, which mwhudson and sarnold had
looked at previously.
The new (failing) version adds file lib/rack/handler/thin.rb

  debian? one failure in CI that still has logs and it doesn't look similar
  upstream? no relevant bugs I could find
  previous version? Problem since v1.8.0, v1.7.2 is fine, assume it's related
  to the thin.rb above
  hirsute? yes, with v1.8.0

I let this one test in the background but quite frankly forgot about it as I
investigated ...

### prometheus ###

Worked once in January, and has failing since.
https://github.com/prometheus/prometheus/issues/8403
https://github.com/prometheus/prometheus/pull/8538

Golang 1.16 related, and since fixed upstream.

Filed
https://bugs.launchpad.net/ubuntu/+source/prometheus/+bug/1930752
so that this info would be shown in the update-excuses report.

### picolibc ###

No builds had been attempted for a while.
Fails with some exciting macro expansion magic.
../../../newlib/libc/include/ssp/ssp.h:47:52: error: expected declaration 
specifiers or ‘...’ before numeric constant
   47 | #define __ssp_bos0(ptr) __builtin_object_size(ptr, 0)
  |^
../../../newlib/libc/include/ssp/string.h:52:7: note: in expansion of macro 
‘__ssp_bos0’
   52 | ((__ssp_bos0(dst) != (size_t)-1) ? \
  |   ^~
[...]

I was able to reproduce the issue as well based on upstream code and an amd64
target, so I opened an issue there:
https://github.com/picolibc/picolibc/issues/127

### golang-yaml.v2 ###

This one was listed as blocking some other packages, so I dug into them first.

### golang-github-nicksnyder-go-i18n.v2 ###

go-i18n seems to have been bit by a change in the error text in golang 1.16.

filed bug upstream:
https://github.com/nicksnyder/go-i18n/issues/259
opened:
https://bugs.launchpad.net/ubuntu/+source/golang-github-nicksnyder-go-i18n.v2/+bug/1930776

I debated sending a MP with a fix, but there were multiple solutions to
the problem and none of them seemed to hard, so I decided to let
upstream handle it in a way they prefer.

### golang-github-prometheus-common ###

Another prometheus related package, with similar results - issue fixed
upstream, we just need to pick up the new version someday.

https://github.com/prometheus/common/issues/267
fixed in 10e1378a4a94394e5671c529b7d87833c2b70d13

Filed this to track:
https://bugs.launchpad.net/ubuntu/+source/golang-github-prometheus-common/+bug/1930772

### back to golang-yaml.v2 ###

Now with a belief that yaml.v2 was unrelated to the test failures on
promethus-common and i18n.v2, I came back to yaml.v2, where I could see
test failures locally that I couldn't find a record of in ubuntu/debian
autopkgtest.

That failure had to do with dh-golang copying source around, where it ran into
a conflict where it tried to copy a directory to where a symlink to said
directory already existed.  A simple fix to trim the symlinks that dh-golang
wanted gone anyway improved the situation and got yaml.v2 building for me.

MP opened:
https://salsa.debian.org/go-team/packages/dh-golang/-/merge_requests/17
debbug opened:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989477
launchpad opened against golang-yaml.v2:
https://bugs.launchpad.net/ubuntu/+source/golang-yaml.v2/+bug/1930928

### nodejs vs node-d3-transition ###

LocutusOfBorg had investigated this and opened an issue upstream:
https://github.com/d3/d3-transition/issues/126

There hadn't been much movement on that, so I decided to generalize the bug a
bit and reproduce the issue with non-Ubuntu nodejs infrastructure.  I wasn't
able to see an amd64 failure in that case, but could consistently see an arm64
failure on a different test.  Existing upstream bug updated with this info.

-Dan

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

Re: nfs-common won't restart all services after upgrade

[Dan Streetman]

On Thu, May 13, 2021 at 8:34 AM Andreas Hasenack  wrote:
>
> Hi,
>
> tl;dr
>
> I filed https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/1928259 
> found while testing 
> https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/1927745 and 
> verifying that rpc.gssd was not restarted after a package upgrade. Which 
> means the fix wasn't available until the service was restarted manually.
>
>
> # Troubleshooting story
>
> I was testing 
> https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/1927745, and while 
> the fix is correct, it didn't always "stick" after I upgraded the packages.
>
> Further troubleshooting showed that some of the NFS services are not 
> restarted after a package upgrade, under a specific condition which took a 
> while to figure out.
>
> Many services make up a NFS server or client, so sometime ago debian decided 
> to wrap them all around a systemd service called nfs-utils.service,

actually upstream added the service, not debian
http://git.linux-nfs.org/?p=steved/nfs-utils.git;a=commit;h=c0512981b7e10487378e5c6fec5d7d72dd4f7e1a

It certainly doesn't appear to be right way to handle
management/coordination of the various services, but probably the
discussion should involve upstream to figure out the proper way to
redesign things.

> which is a bit fake, used just to coordinate all the real services. Its 
> header explains it:
> $ systemctl cat nfs-utils.service
> # /lib/systemd/system/nfs-utils.service
> [Unit]
> Description=NFS server and client services
> # This service should never be stopped, only restarted.
> # When it is re-started, all other services which declare
> # themselves to be "PartOf" this service will also be
> # restarted. Thus
> #   systemctl restart nfs-utils
> # will restart all daemons which are part of nfs-utils
> # and which are running.  This is useful after a software
> # update.
>
> # This is a "service" rather than "target" so that we
> # don't need to say "systemctl restart nfs-utils.target".
> [Service]
> Type=oneshot
> RemainAfterExit=yes
> ExecStart=/bin/true
>
> d/rules has these, and we can see it does not enable nfs-utils.service, but 
> asks for it to be restarted on upgrade:
> dh_systemd_enable -p nfs-common nfs-client.target
> dh_systemd_enable -p nfs-kernel-server nfs-server.service
> dh_installinit -pnfs-common -R
> dh_systemd_start -p nfs-common --restart-after-upgrade nfs-utils.service
> dh_systemd_start -p nfs-kernel-server --restart-after-upgrade 
> nfs-server.service
>
> And this "fake" service really can't be enabled:
> $ sudo systemctl enable nfs-utils.service
> The unit files have no installation config (WantedBy, RequiredBy, Also, Alias
> settings in the [Install] section, and DefaultInstance for template units).
> (...long explanation follows this output ...)
>
> We get this during package install:
> Setting up nfs-common (1:1.3.4-2.1ubuntu5.3) ...
> nfs-utils.service is a disabled or a static unit not running, not starting it.
>
> Even when upgrading:
> Setting up nfs-common (1:1.3.4-2.1ubuntu5.4) ...
> nfs-utils.service is a disabled or a static unit not running, not starting it.
>
> This is because the service is not enabled.
>
> Critically for the bug I'm fixing, rpc.gssd is not restarted, so the fix 
> isn't applied :/
> Before upgrade:
>   442 ?Ss 0:00 /usr/sbin/blkmapd
>  7146 ?Ss 0:00 /usr/sbin/rpc.gssd
>  7399 ?Ss 0:00 /usr/sbin/rpc.idmapd
>  7406 ?Ss 0:00 /usr/sbin/rpc.mountd --manage-gids
>  7400 ?Ss 0:00 /usr/sbin/rpc.svcgssd
> After pkg upgrade:
>   442 ?Ss 0:00 /usr/sbin/blkmapd
>  7146 ?Ss 0:00 /usr/sbin/rpc.gssd
>  8421 ?Ss 0:00 /usr/sbin/rpc.idmapd
>  8422 ?Ss 0:00 /usr/sbin/rpc.mountd --manage-gids
>  8420 ?Ss 0:00 /usr/sbin/rpc.svcgssd
>
> If I do a manual "sudo systemctl start nfs-utils.service" (or restart) before 
> upgrading the package, then all these processes are restarted after the 
> package upgrade, because deb-systemd-invoke sees nfs-utils.service as 
> "started". From its code:
> # If the job is disabled and is not currently running, the job is not started 
> or restarted.
> # However, if the job is disabled but has been forced into the running state, 
> we *do* stop
> # and restart it since this is expected behaviour for the admin who forced 
> the start.
> # We don't autostart static units either.
>
> I filed https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/1928259 and 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=988430.
>
> Some ideas I'm considering:
> a) just do a systemctl start before the #DEBHELPER# marker, like this:
> --- a/debian/nfs-common.postinst
> +++ b/debian/nfs-common.postinst
> @@ -43,6 +43,10 @@ case "$1" in
> if [ -f /lib/init/rw/sendsigs.omit.d/statd ]; then
> mv /lib/init/rw/sendsigs.omit.d/statd /run/sendsigs.omit.d/statd
> fi
> +
> +# always "start" nfs-utils.service, so package 

Re: Packaging policy discussion: After=network-online.target

[Dan Streetman]

On Wed, May 12, 2021 at 3:52 AM Christopher James Halse Rogers
 wrote:
>
> Hello everyone,
>
> There's an nfs-utils SRU¹ hanging around waiting for a policy decision
> on use of the After=network-online.target systemd unit dependency. I'm
> not an expert here, but it looks like part of my SRU rotation today is
> starting the discussion on this so we can resolve it one way or another!

Goodness this email thread has a lot of different directions.

Just a few observations that might help:

1) what does it actually mean for systemd-networkd to consider
networking 'online'?

To be specific, 'network-online.target' simply calls
'systemd-networkd-wait-online' which has its own man page which is
very descriptive about what exactly it waits for.

To briefly summarize, It means all systemd-networkd managed interfaces
that are 'required for online' have reached a setup state of
'configured' or 'failed' and at least one managed interface has
reached operational state of 'degraded' or higher. Any interfaces that
should not be required should have their .network file include
'RequiredForOnline=no' in their [LINK] section (see man
systemd.network). The 'degraded' state of an interface means it has
carrier and a valid local link address (the next step up is 'routable'
which means it has a routable address configured).

Note that systemd-networkd isn't the only provider of network
management; NetworkManager also does and it also has a service
implementing (or more accurately WantedBy) network-online.target,
which is NetworkManager-wait-online.service. That very likely has a
different definition of exactly what it means for the network to be
'online'.

2) what's the downside of something requiring network-online.target?

The only downside is the delay of the service(s) that is/are
configured with After=network-online.target. Any such service will be
delayed at boot until the network manager (whatever it is) decides the
network is "up" (as mentioned above). However, that of course also
delays any services which order themselves after the delayed
service(s).

To the end user, this typically is seen as a 'hang' during boot. The
specific reason is there are services/targets that order themselves
after network-online.target, that also are ordered before services
that provide user login. In a default cloud image system, the specific
packages that introduce this problem are cloud-init and open-iscsi.

For example here is the startup plot of a plain hirsute cloud-init vm,
with the only modification being adding a second interface (with no
connection to anything) and adding systemd-networkd config to start
dhcp on the second interface (which of course will delay the network
starting since the dhcp will never get an answer). You can see that
systemd-user-sessions is delayed until after network-online.target,
which 'hangs' the boot:
https://people.canonical.com/~ddstreet/startups/startup-plain.svg

And here is the same vm, with cloud-init and open-iscsi removed. Note
that network-online.target isn't in the units started at boot, so
there is no delay for anything.
https://people.canonical.com/~ddstreet/startups/startup-without-cloud-init-open-iscsi.svg

And again, but with a simple service 'dummy.service' that does nothing
and has Wants=network-online.target and WantedBy=multi-user.target
(this service pulls network-online.target into the units started at
boot). This shows that systemd-user-sessions isn't delayed, and so
login is not delayed and there is no 'hang' during boot, but the
network-online target is delayed, as expected; it just has no impact
on how long boot takes to reach user login.
https://people.canonical.com/~ddstreet/startups/startup-without-cloud-init-open-iscsi-with-network-online.svg

Finally to illustrate the boot ordering problems that open-iscsi
introduces, the dummy.service is changed to want network-online.target
and remote-fs-pre.target, and order itself between those, just as
open-iscsi does (specifically, After=network-online.target and
Before=remote-fs-pre.target):
https://people.canonical.com/~ddstreet/startups/startup-without-cloud-init-open-iscsi-dummy-delay.svg

Note that this isn't *necessarily* a bug in open-iscsi, as it kind of
makes sense; if user login does in fact require an iscsi-mounted
directory, then systemd-user-sessions should be ordered after
open-iscsi, and of course open-iscsi requires networking to work.
However, there clearly is subtlety in the reality of the dependency
chain that the current implementation doesn't have, for example even
if there are no iscsi mounts at all, open-iscsi adds this boot
ordering that delays user login until after network-online.

The cloud-init package introduces a similar ordering, but is much more
blunt about it; the cloud-init.service includes
After=systemd-network-wait-online.service and
Before=systemd-user-sessions.service.

To clarify, *any* package with systemd services/targets might
introduce unit ordering similar to this at boot time, so this 

Re: Question to flavors: touch-base on flavor participation for 21.10!

[Dan Simmons]

On 5/14/21 5:57 AM, Lukasz Zemczak wrote:
> 
> Hello flavors!
> 
> As we do around the start of every new cycle, I am reaching out to all
> the current official Ubuntu flavors to confirm active participation in
> the upcoming Ubuntu release - 21.10.
> 
> Working towards a release requires a lot of effort, so we'd like to
> make sure all the flavors are ready, properly staffed and have enough
> time allocated to make 21.10 happen for their users. This is why,
> similarly to last year, I will need a confirmation follow-up message
> about impish participation from every flavor, that is:
> 
>  * Kubuntu
>  * Xubuntu
>  * Ubuntu Studio
>  * Lubuntu
>  * Ubuntu Kylin
>  * Ubuntu MATE
>  * Ubuntu Budgie
> 
> If you have any concerns regarding your participation, feel free to
> reach out to me or anyone else from the ubuntu-release team.
> 
> Thank you!
> 
> Cheers,
> 
> --
> Łukasz 'sil2100' Zemczak
>  Foundations Team
>  lukasz.zemc...@canonical.com
>  www.canonical.com
> 
> --
> ubuntu-devel mailing list
> ubuntu-devel@lists.ubuntu.com
> Modify settings or unsubscribe at: 
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
> 

On behalf of the Lubuntu team I formally declare that we will be
participating in the 21.10 cycle. I will be acting as release manager
for this cycle but if for some reason I am not available Thomas Ward
(teward) or Walter Lapchynski (wxl) are my backups.

Dan
-- 
@kc2bez on Telegram
@kc2bez on Freenode IRC

9150 77E7 6EFC 53F7 5CBC
6EB9 98D2 9485 5C5A 7872

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

+1 maintenance report

[Dan Bungert]

+1 Maintenance Report
Dan Bungert, Week of May-03-2021

This was my first go at +1!
Thanks to RikMills, racb, and seb128 for retest help this week.

### ui-utilcpp ###

I started looking into this, got as far as concluding that there were
some rpc differences at play between Debian & Ubuntu, then looked at
rdepends and concluded that there weren't many packages looking at this.
Moved on at that point.

### xfig ###

Local tests fine, there is a valgrind complaint which I chased for a
while before concluding that the ghostscript library that xfig is using
has some valgrind magic in there.  My hunch is that the valgrind stuff
is a false positive and just not interacting well with the valgrind
settings on ghostscript / this xfig test.  It bugs me that this seems to
test fine for Debian but not for Ubuntu but I currently lack a better
answer.

I was able to verify at least that this doesn't seem to be something
that could be remediated by big_packages:
autopkgtest -- qemu --ram-size=600 --cpus=1
passed for me.

### sshuttle ###

This one helped me learn about the hints system for big_packages /
long_tests.  sshuttle was already in long_tests but hadn't been properly
rerun since start of impish (ignoring transient test failures on
04-27-2021).  Simple retests here are fine, but the tests take almost 5
hours and involve a lot of waiting on timeouts so I filed LP: #1927757
to help document the aspiration to speed this up.

### openmolcas ###

I couldn't reproduce the builder problems, but I could produce other
test suite failures.  Fixed what I could reproduce and sent MP and a
Debian bug to document it (debbug: #988161).

### security item ###

There was another item in a universe package that I chased down that I
ended up emailing Debian Security about.  I'm not sure how big the issue
is but I'm also not sure how public it should be so I'll leave it at
that for now.

### other ###

lava vs qemu - I peeked briefly and looped some tests locally in the
background and concluded that it just needed some retest clicks, looks
like others have that moving forward.

-Dan

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

Re: firebird3.0 install on Ubuntu 16.04.7 LTS (Xenial Xerus)

[Dan Streetman]

On Sat, Apr 24, 2021 at 10:21 AM Thomas Ward  wrote:
>
> And once more, ESM rears its head.
>
> ESM comes with no community support.  Support for ESM releases is for *paid 
> Canonical support via Ubuntu Advantage subscriptions*.

Just to clarify this slightly, ESM does not come with any
(non-security) bug-fix support, even paid ESM. ESM provides updates to
fix security-related issues/bugs. Both community support, as well as
paid UA contract support (for non-security bug fixes), end when a
release reaches End of Standard Support.

> The Community Council clarified this with Canonical who will be putting out a 
> more descriptive document explaining ESM and this information.  None of the 
> prior releases RE: ESM had any details about End of Standard Support - thats 
> a new thing that was recently added to releases.  So yes ESM repos will get 
> you additonal security patches but it won't extend to community support - 
> that will require paid Canonical contracts.
>
> 16.04 to 18.04 is a valid upgrade path so d-r-u will work. But you will still 
> need to upgrade to 18.04 and I recommend doing that sooner than later.
>
>
> Thomas
>
>
>  Original message 
> From: Ralf Mardorf 
> Date: 4/24/21 10:09 (GMT-05:00)
> To: ubuntu-devel-discuss@lists.ubuntu.com
> Subject: Re: firebird3.0 install on Ubuntu 16.04.7 LTS (Xenial Xerus)
>
> On Fri, 23 Apr 2021 17:27:30 -0400, Thomas Ward wrote:
> >Be aware though: 16.04.7 goes past End of Standard Support this month
> >- you should consider upgrading 16.04 to 18.04 before the end of
> >standard support happens.
>
> Doesn't do-release-upgrade after April work anymore? I suspect that it
> at least does work until April 2023, when Ubuntu 18.04 standard support
> ends. If a release upgrade isn't needed, 16.04 should be (more or
> less) good until April 2024. Am I mistaken?
>
> "Is Ubuntu 16.04 LTS still supported beyond April 2021?
>
> Ubuntu 16.04 LTS will still be supported beyond its free initial
> five-year maintenance period in April 2021, as it transitions to the
> extended security maintenance phase - with three additional years of
> security ensured.
>
> Learn more about Ubuntu 16.04 LTS moving to ESM  ›
> Free for personal use
>
> Canonical provides Ubuntu Advantage Essential subscriptions, which
> include ESM, free of charge for individuals on up to 3 machines. For
> our community of Ubuntu members we will gladly increase that to 50
> machines. Your personal subscription will also cover Livepatch. Get ESM
> now" - https://ubuntu.com/security/esm
>
> --
> 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
> --
> 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

-- 
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

Re: DKMS upload rights application

[Dan Streetman]

On Tue, Apr 6, 2021 at 10:53 AM Marcelo Henrique Cerri
 wrote:
>
> Hi,
>
> I would like to announce my application for membership in the DKMS
> package set uploader team. My application can be found at:
>
> https://wiki.ubuntu.com/MarceloCerri/DkmsUploadApplication

After a unanimous +4 vote, mhcerri has been added to the
ubuntu-kernel-dkms-uploaders team.

Congratulations!

>
> I have added myself to the agenda for the DMB meeting at:
>
> https://wiki.ubuntu.com/DeveloperMembershipBoard/Agenda
>
> Thanks you!
>
> --
> Regards,
> Marcelo
>
> --
> Devel-permissions mailing list
> devel-permissi...@lists.ubuntu.com
> Modify settings or unsubscribe at: 
> https://lists.ubuntu.com/mailman/listinfo/devel-permissions

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

Re: Application for membership in DKMS packageset uploader team

[Dan Streetman]

At the Nov 16 meeting of the DMB, we unanimously approved sforshee's
application to join the (newly created) Ubuntu Kernel DKMS Uploaders
team, with permission to upload packages in the (newly created)
kernel-dkms packageset.

Congratulations!


On Mon, Oct 26, 2020 at 10:43 AM Seth Forshee
 wrote:
>
> Hi,
>
> I would like to announce my application for membership in the yet to be
> created DKMS packageset uploader team, which was approved at the
> 2020-07-13 DMB meeting:
>
> https://irclogs.ubuntu.com/2020/07/13/%23ubuntu-meeting.html
>
> My application can be found here:
>
> https://wiki.ubuntu.com/SethForshee/DkmsUploadApplication
>
> I have added myself to the agenda for the DMB meeting on 2020-11-16.
>
> Thanks in advance!
>
> Seth
>
> --
> Devel-permissions mailing list
> devel-permissi...@lists.ubuntu.com
> Modify settings or unsubscribe at: 
> https://lists.ubuntu.com/mailman/listinfo/devel-permissions

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

Re: PerPackageApplication OpenStack package set

[Dan Streetman]

I'm happy to announce Chris's successful application for upload rights
for the OpenStack package set!

Congratulations, Chris.

On Wed, Sep 23, 2020 at 11:34 AM Chris MacNaughton
 wrote:
>
> Hi,
>
> I'd like to announce that I am applying for per-package upload rights for the 
> OpenStack package set. My application wiki page can be found here:
>
> https://wiki.ubuntu.com/ChrisMacNaughton/OpenStackDeveloperApplication#preview
>
> My plan is to take my application into consideration in the next DMB meeting 
> on Monday 2020-10-05 19:00 UTC (13 days from today).
>
> Thanks in advance!
> Chris MacNaughton
>
> --
> Devel-permissions mailing list
> devel-permissi...@lists.ubuntu.com
> Modify settings or unsubscribe at: 
> https://lists.ubuntu.com/mailman/listinfo/devel-permissions

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

Re: SRU shift report: 2020-09-23

[Dan Streetman]

On Fri, Sep 25, 2020 at 10:11 AM Robie Basak  wrote:
>
> Hi Thomas,
>
> On Thu, Sep 24, 2020 at 08:02:23AM -0400, Thomas Ward wrote:
> > Original SRU 'justification' written in the bug[1] states the regression
> > risk is "There should be none."  As you stated elsewhere, "none" is not
> > a valid risk justification.
> >
> > Further, they're waiting for this to be done in Debian as well (see [2])
> > so it does indeed need a wait on this going forward because it needs to
> > be fixed in another spot - that blocks SRU processing, but if we're
> > going to be nitpicky as we should be, you should probably "block" also
> > on the lack of a justification - as "there should be none" is not really
> > a valid potential analysis.
>
> Agreed.
>
> For new contributors I try to be more slack in what I accept. Though not
> in what I land - I'll spend the time taking the role of the developer,
> fixing up the SRU documentation and the upload as necessary to meet our
> standards first. This is in the hope that they'll contribute again and
> learn our processes over time.
>
> Of course SRU team members are all capable core devs and so we can
> always just take over the work and fix up whatever we think necessary.
> But for regular uploaders, what pains me about doing this is that it
> seems like it wastes time - it'd be quicker overall for the uploader to
> do it since they already know all the details, rather than me having to
> infer it all first. It's so much quicker and easier to review and
> understand things when the person who already knows all the details has
> written it down. And if I want something changed substantially, then I
> also want an ack from the uploader for my proposal to make sure it still
> meets their expectations and needs, and also that the final accepted
> upload has had a proper review from both the uploader and the SRU
> reviewer. And so that necessiates more round trips.
>
> When I first joined the SRU team and asked about this, I remember a
> colleague pointing out that as there are far fewer SRU team members than
> uploaders,

that's true; of the official list of members:
https://launchpad.net/~ubuntu-sru/+members

Only 6 are part of the SRU Vanguard schedule:
https://wiki.ubuntu.com/StableReleaseUpdates#Publishing

And all 6 of those members are directly involved in the development
release cycle, so in the month (or two...) leading up to each release,
they (understandably) are very busy and the SRU upload queue reviews
get less attention. This has been frustrating for SRU uploaders (like
me) in the past.

And of course, 6 reviewers is a small number, especially when they all
have very demanding work besides reviewing SRU uploads.  Maybe it's
time to increase the number of SRU team members? It would be
especially helpful if there was at least 1 SRU team member that wasn't
directly involved in the development cycle. That would reduce the
workload on the other SRU members during development cycle "crunch
time", and improve SRU review delays, which can be important since
stable releases need to continue getting bugfixes even during
development release months.

> it makes much more sense for the uploaders to do the parts
> that both groups can do, and keep the SRU team focused on reviews rather
> than forever fixing things up.
>
> In practice I try to find some kind of balance. If it's a trivial
> oversight I'm happy to fix things up myself[1].
>
> I write this to try and explain my expectations better to everyone.
> Nothing above is aimed at you specifically Thomas - IIRC your SRU
> uploads are exemplary :)
>
> Robie
>
> [1] As an aside, when fixing up others' uploads I always find it
> difficult to balance the need to credit the uploader appropriately
> against attributing my unagreed changes to their name in the changelog
> entry. What if I want to completely reword the changelog text, for
> example? Should I then seek their approval but cost the review another
> feedback cycle? But anyway, I try my best to get the balance right.
> --
> ubuntu-devel mailing list
> ubuntu-devel@lists.ubuntu.com
> Modify settings or unsubscribe at: 
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

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

Re: Running autopkgtests from PPA on real infrastructure

[Dan Streetman]

On Wed, Sep 16, 2020 at 12:07 PM Olivier Tilloy
 wrote:
>
> On Wed, Sep 16, 2020 at 5:13 PM Iain Lane  wrote:
> >
> > On Tue, Sep 15, 2020 at 03:53:01PM +0200, Lukas Märdian wrote:
> > > * Upload your package (incl. debian/tests/*) to your PPA
> > > * Get a core-dev/MOTU to trigger the test for you, via this URL scheme:
> > > https://autopkgtest.ubuntu.com/request.cgi?release=RELEASE=ARCH=SRCPKG
> > > *=LPUSER/PPA*=SRCPKG/VERSION
> > > * Check the results via this URL scheme:
> > > https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-RELEASE-LPUSER-PPA/
> >
> > I would dearly love to improve this situation. I could imagine (easier)
> > a CLI tool to help you
> >
> >   (1) submit requests,
> >
> >   (2) view them [the swift software we use to store/retrieve results has
> >   an API],
>
> I wrote a couple of scripts that cater well for my particular use
> cases: I build multiple versions of firefox, thunderbird and
> chromium-browser in various PPAs, and I wanted to be able to request
> tests for a particular version prefix (potentially spanning several
> releases) in a given PPA, and to quickly view a summary of the test
> results.
> The code is at https://code.launchpad.net/~osomon/+git/ubuntu-scripts,
> and the interesting scripts are request-autopkgtests.py and
> display-filtered-autopkgtests-results-summary.py.
>
> Example use case:
>
>   ./request-autopkgtests.py ppa:ubuntu-mozilla-security/ppa firefox 81
>   # after all the tests have completed (check periodically at
> http://autopkgtest.ubuntu.com/running)
>   ./display-filtered-autopkgtests-results-summary.py
> ppa:ubuntu-mozilla-security/ppa firefox bionic 20200916
>
> I use those scripts daily and they're a big time saver.
> Suggestions and improvements welcome, and I'm happy to work towards
> having them owned and maintained by ~ubuntu-dev if they can be of use.

We (support) have a similar script; since nobody on my team has bileto
access, autopkgtests from ppas would be essentially unusable to us (or
at least, me) without this scripting.
https://git.launchpad.net/ubuntu-support-tools/tree/autopkgtest-manager/autopkgtest-manager

However, I think the real problem is autopkgtest-cloud, which is in
desperate need of updates to provide not only access to ppa-run tests,
but better ways to view test results (probably in addition to
improvements to autopkgtest itself). I did set up my own
autopkgtest-cloud instance a while ago - which was a lot harder than i
expected - but haven't had time to work on improving it since. I
wonder if it's worth improving autopkgtest-cloud, or if we should
think about moving to something else like Jenkins?

>
> > or (harder, better) an extension to the web frontend so that PPA results
> > are displayed like distro ones.
> >
> > Just mentioning this in case anyone gets excited about helping with the
> > tooling. I'd love to put this on my list, but someone else picking it up
> > would make it happen sooner. :)
>
> Cheers,
>
>  Olivier
>
> --
> ubuntu-devel mailing list
> ubuntu-devel@lists.ubuntu.com
> Modify settings or unsubscribe at: 
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

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

Re: Compiling system for Ubuntu

[Dan Kegel]

Here's the rough recipe for building ubuntu 18.04's systemd (well, or
anything, really):

Start a clean ubuntu 18.04 system (perhaps with lxd), then:
sudo apt update
sudo apt dist-upgrade
sudo apt install devscripts
sudo apt build-dep systemd
apt source systemd
cd systemd-237
debuild -b -uc -us
cd ..

That takes 20 minutes or so to run, and should generate a handful of .deb's
in the parent directory, including systemd.

You can then compare the results with the system's systemd package, e.g.
mkdir tmp
cd tmp
apt download systemd
cd ..
sudo apt install diffoscope
diffoscope tmp/systemd_237-3ubuntu10.42_amd64.deb
systemd_237-3ubuntu10.42_amd64.deb

In my case, there were quite a few differences, not sure why.
Nevertheless, I blindly did
  sudo dpkg -i systemd_237-3ubuntu10.42_amd64.deb
to install the result over the system's systemd, and the container did not
explode and catch fire :-)

You should be able to apply your patch immediately before the debuild step.

- Dan

- Dan


On Sat, Sep 12, 2020 at 10:14 AM rafi Moor  wrote:

>
>
>
>
> Hello,
>
>
>
> I’m trying here after getting no answers in Ubuntu forums.
>
>
>
> I have hard time compiling some Ubuntu packages from source.
>
> I now try to compile systemd. On Ubunu 18.04 I've used apt source to get
> the source that is supposed to include Ubunu patches. After compilation, I
> replace libsystemd-shared-237.so with the one I've compiled. Programs that
> are linked with this shared object complain about reference to undefined
> symbol sd_bus_enqueue_for_read. using readelf I can see that the original
> library has this symbol but the new one doesn't. I've tried to apply
> CVE-2020-1712-2.patch but then the compilation fails on missing function
> bus_message_ref_queued(). This function is included in systemd version 246
> but not in 237 which is the version on Ubuntu 18.04.
>
> How can I compile systemd so that I get files identical to those of Ubuntu
> 18.04?
>
> Thanks
> Rafi
> --
> 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
>
-- 
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

Re: default algorithm in package zram-config 0.5

[Dan Streetman]

On Mon, Jun 8, 2020 at 6:40 PM Mitch 74  wrote:
>
> I know about the setting, that's why I mentioned changing the default -
> lzo is a wee bit outdated now, while lz4 is built into the kernel now so
> there's little chance of it not working out of the box. Moreover it's
> not about changing the default in zram

Why do you want to change the default in Ubuntu but not in the upstream kernel?

> , only in the package zram-config
> (i.e. when setting it up).
>
> Le 09/06/2020 à 00:33, Dan Streetman a écrit :
> > On Mon, Jun 8, 2020 at 3:42 PM Mitch 74  wrote:
> >> Hello,
> >>
> >> Considering that now lz4 is by default enabled in kernel, wouldn't it be
> >> better to use it as a compression algorithm in zram instead of lzo?
> > the zram default upstream is still lzo (lzo-rle).  you can select zram
> > alg for each device, at /sys/block/zramN/comp_algorithm, before you
> > initialize it.
> >
> >> Regards
> >>
> >> Mitch 74
> >>
> >>
> >> --
> >> 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

-- 
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

Re: default algorithm in package zram-config 0.5

[Dan Streetman]

On Mon, Jun 8, 2020 at 3:42 PM Mitch 74  wrote:
>
> Hello,
>
> Considering that now lz4 is by default enabled in kernel, wouldn't it be
> better to use it as a compression algorithm in zram instead of lzo?

the zram default upstream is still lzo (lzo-rle).  you can select zram
alg for each device, at /sys/block/zramN/comp_algorithm, before you
initialize it.

>
> Regards
>
> Mitch 74
>
>
> --
> 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

-- 
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

Re: Ubuntu Studio Packageset application for Erich Eickmeyer

[Dan Streetman]

(resending to lists as I forgot to include them on cc of original email)

On Thu, Apr 9, 2020 at 11:22 AM Erich Eickmeyer
 wrote:
>
> Hi DMB,
>
> I have added myself to the agenda for the April 20th DMB meeting to
> apply for upload rights to the Ubuntu Studio packageset at the
> urging/bidding of SEVERAL people. :)

Sorry for the delay in announcing.

At the April 20 meeting of the DMB, eeickmeyer received 4 +1 votes and
is now a member of ~ubuntu-studio-uploaders.  Congratulations!

>
> Application at https://wiki.ubuntu.com/Eickmeyer/PPUApplication2
>
> See you all then,
> Erich
> 
> Erich Eickmeyer
> Project Leader
> Ubuntu Studio
>
> ubuntustudio.org
>
>
> --
> Devel-permissions mailing list
> devel-permissi...@lists.ubuntu.com
> Modify settings or unsubscribe at: 
> https://lists.ubuntu.com/mailman/listinfo/devel-permissions

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

Re: package set application for ~ubuntu-mozilla-uploaders

[Dan Streetman]

On Fri, Apr 3, 2020 at 11:42 AM Olivier Tilloy
 wrote:
>
> Hi DMB,
>
> I hereby request membership in the ~ubuntu-mozilla-uploaders team (mozilla 
> package set).

Sorry for the delay in announcing.

At the April 20 meeting of the DMB, osomon received 4 +1 votes and is
now a member of ~ubuntu-mozilla-uploaders.  Congratulations!

>
> I have added myself to the agenda, hopefully my application can be reviewed 
> and discussed, not at the next meeting on Monday (too short a notice), but at 
> the following one on the schedule, on the 20th of April.
>
> My application: 
> https://wiki.ubuntu.com/OlivierTilloy/MozillaPackageSetApplication
>
> Regards,
>
>  Olivier
> --
> Devel-permissions mailing list
> devel-permissi...@lists.ubuntu.com
> Modify settings or unsubscribe at: 
> https://lists.ubuntu.com/mailman/listinfo/devel-permissions

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

Re: Adjusting what fstypes df displays

[Dan Streetman]

On Fri, May 29, 2020 at 12:39 AM Bryce Harrington
 wrote:
>
> These days, df displays a lot of mount points, due to the increased use
> of non-consumable filesystems such as tmpfs and squashfs.  This clutter
> is particularly noticeable using df in Ubuntu, due to the increased
> popularity of snaps, but the general problem affects all Linux distros,
> and shows up in other commands such as lsblk, blkid, fdisk -l, and
> mount.
>
> A commonly documented user customization[1] is to use aliases, e.g.:
>
> alias df='df -h -x squashfs -x tmpfs -x devtmpfs'
> alias lsblk='lsblk -e 7'
>
> df's upstream is aware of the issue, and would like to address it in
> their code.  They've considered a number of solutions[2], but do not
> appear to have come to a consensus as of yet.  Among the raised concerns
> are variations in distro requirements, and providing an ability for
> users to override/customize the exclusions.
>
> A solution I am considering to propose would add an environment
> variable, DF_EXCLUDE_FSTYPES, that df would treat similar to the -x
> flag.
>
>
> I've drafted a POC implementation for df here:
>
>   
> https://github.com/bryceharrington/coreutils/commit/cc372d778b44abcf81af42743a5174685f9bb4db
>
>
> Here's what it does inside a container...
>
> Before:
>
> $ df
> Filesystem   1K-blocks  Used Available Use% Mounted on
> default/containers/coreutils  24891008   2258816  22632192  10% /
> none   492 4   488   1% /dev
> udev  32862724 0  32862724   0% /dev/tty
> tmpfs  100 0   100   0% /dev/lxd
> /dev/nvme0n1p2   982940092 348781368 584158392  38% 
> /home/bryce/pkg
> tmpfs  100 0   100   0% 
> /dev/.lxd-mounts
> tmpfs 32892912 0  32892912   0% /dev/shm
> tmpfs  6578584   224   6578360   1% /run
> tmpfs 5120 0  5120   0% /run/lock
> tmpfs 32892912 0  32892912   0% 
> /sys/fs/cgroup
> tmpfs  6578580 0   6578580   0% 
> /run/user/1001
>
> After:
>
> $ export DF_EXCLUDE_FSTYPES=tmpfs,devtmpfs,squashfs
>
> $ df
> Filesystem   1K-blocks  Used Available Use% Mounted on
> default/containers/coreutils  24891008   2258816  22632192  10% /
> /dev/nvme0n1p2   982940092 348781372 584158388  38% 
> /home/bryce/pkg
>
> (It's even more drastic on my desktop - from 39 lines down to 6.)
>
> For Ubuntu, DF_EXCLUDE_FSTYPES could be set in the global profile (under
> /etc/profile.d/ perhaps?)  This would make it straightforward to add
> new non-consumable filesystems that may crop up down the road.  Perhaps
> other tools could use a similar/same env var approach, giving us a
> uniform way to control fs listings in the distro.
>
> Two alternate approaches I'm weighing are a config file in /etc, or just
> a package patch to carry in coreutils, but the env var approach feels
> like it would be more flexible to users and hopefully more suitable for
> upstream.  Before I forward it upstream, though, what does ubuntu-devel@
> think?

I agree on the pain of df output pollution, for sure.  And patching df
would help; though as you mentioned it's not the only tool affected,
e.g. lsblk, and IMO mount output is even worse.

While I'm +1 on adding an easy way to hide them, I'm -1 on hiding all
squashfs and tmpfs from everyone *by default*.  I think that will lead
to a lot of confusion.  But that's just my opinion.

Also re: using an env var, keep in mind there are quite a few
environments that won't keep profile vars, e.g. sudo, lxc exec, etc.
It could be quite confusing for 'df' to show one thing, and 'sudo df'
something else.




>
> Thanks,
> Bryce
>
>
>
> 1:  Google shows many links, here's a sample:
>
> https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1756595
> 
> https://askubuntu.com/questions/1029493/how-can-i-stop-snaps-from-listing-in-df
> 
> https://clintonminton.com/how-to-clean-up-snap-and-loop-devices-from-df-output-in-ubuntu-18-04/
>
> Note that one drawback to this approach is it's not overrideable, i.e.:
>
> $ alias df='df -h -x squashfs -x tmpfs -x devtmpfs'
> $ df -t tmpfs
> df: file system type ‘tmpfs’ both selected and excluded
>
> 2: Ideas the maintainers discussed include omitting read-only devices,
> or ones with non-consumable storage, or with <1% usage.  They also
> discussed maintaining a simple list of excludable "lesser" file
> systems, possibly stored in a user's ~/.dfrc or ~/.shellrc.
>
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=37702
>
> 3:  We exclude squashfs,tmpfs,devtmpfs in our nagios packaging, where
> these were generating false-positive 'disk full' alerts:
>
> 

Re: RFC: Ubuntu HA resource-agents supportability

[Dan Streetman]

On Wed, Apr 29, 2020 at 11:13 PM Rafael David Tinoco
 wrote:
>
> On 29/04/2020 00:10, Rafael David Tinoco wrote:
>
> Dan, Billy, and all...
>
> part of the result from this thread is at:
>
> https://discourse.ubuntu.com/t/ubuntu-ha-pacemaker-resource-agents-supportability/
>
> And the fence agents can be found over here
>
> https://discourse.ubuntu.com/t/ubuntu-ha-pacemaker-fence-agents-supportability/15768
>
> The same (as bellow) applies to this list.

I'm +1 on the discussion there, for resource and fence agents.  I
think splitting them up makes a lot of sense to better categorize them
by supportability.


>
>
> and will at the Ubuntu Server Guide for 20.04 (Ubuntu HA session being 
> finished).
>
> I changed wording to guarantee this is seen as a community effort and to 
> differentiate from any Ubuntu Advantage offering.
>
> Categories are:
>
> Resource Agents: [main]
> Resource Agents: [universe]
> Resource Agents: [universe]-community
> Resource Agents: [non-supported]
> Resource Agents: [deprecated]
>
>
> From now on, in my head, we're 1:1 with Ubuntu Advantage in nomenclature. 
> Note that resource-agents are in [main] and fence-agents are in [universe]. 
> Despite that, the list is what defines our efforts for support - server & SEG 
> - on those, at least until I split all agents into more packages.
>
> I'm creating another discourse for fencing-agents as well, same thing.
>
> Please give me your +1 if possible, and feel free to -1 with suggestions.
>
> Cheers,
>
> -rafaeldtinoco
>
> On 07/04/2020 23:47, Rafael David Tinoco wrote:
>
> I added a few comments below, otherwise all the categories look
> reasonable to me, thanks!
>
> Thanks for the feedback Dan!
>
>

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

Re: nvidia-340 incapable of single user mode in 20.04

[Dan Kegel]

440 ought to work with that card, if I'm reading this right:
https://www.nvidia.com/Download/driverResults.aspx/159360/en-us
- Dan

On Fri, Apr 24, 2020 at 4:30 PM Dimitri John Ledkov  wrote:

> On Mon, 20 Apr 2020 at 20:53, Jack Howarth
>  wrote:
> >
> >   I am finding on a 2008 MacPro with GTX680 that the installation of
> the nvidia-340 package under Ubuntu 20.04 prevents single user mode boots
> from working. While the nvidia-340 driver works fine from a normal boot,
> when 'single' is added before 'quiet' in the grub kernel arguments, the
> boot produces a black screen that never returns the expected single user
> mode prompts.
> >  A parallel test with current Ubuntu 18.04 with either the stock
> nvidia-340 340.107-0ubuntu0.18.04.4 package or the
> nvidia-graphics-drivers-340 340.108-0ubuntu0.18.04.1 show both of them can
> successfully boot into single user mode.
> > Jack
>
> nvidia-340 is a very old version of nvidia.
>
> 20.04 LTS has: nvidia-driver-390, nvidia-driver-435, nvidia-driver-440.
>
> Can you please use Super to search and launch "additional drivers"
> select 440 driver and install and try that one? It is the recommended
> version of nvidia on 20.04 LTS. Or whichever is highest and supports
> your nvidia card.
>
> --
> Regards,
>
> Dimitri.
>
> --
> 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
>
-- 
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

Re: RFC: Ubuntu HA resource-agents supportability

[Dan Streetman]

On Tue, Apr 7, 2020 at 10:47 PM Rafael David Tinoco
 wrote:
>
> > I added a few comments below, otherwise all the categories look
> > reasonable to me, thanks!
>
> Thanks for the feedback Dan!
>
> > > clvm- clvmd daemon (cluster logical vol manager)
> >
> > Was clvm dropped from lvm2?
> > https://launchpad.net/ubuntu/+source/lvm2/2.03.02-2ubuntu1
> > I haven't used clustered lvm myself; maybe it was just rolled into lvm2.
>
> LVM2 can use lvmlockd (lvm2-lockd in Focal) now for VG access coordination: 
> It can use either dlm (dlm-controld) or sanlock (sanlock) as lock managers. 
> It is not a cmdline level based locking, as clvm was. AND it supports lvmetad.
>
> I believe we will continue seeing dlm as the lock manager as it uses 
> underlying corosync for messaging, same one as pacemaker, thus allowing the 
> same dlm to support gfs2, for example.
>
> > > docker  - docker container resource agent
> >
> > as cpaelzer said, docker itself shouldn't be in the fully supported list.
> >
>
> Yep, changed it already!
>
> > > lxc - allows LXC containers to be managed by the 
> > > cluster
> >
> > presumably, this includes lxc and lxd?
>
> That's actually a really good question. I flagged LXC resource here ("fully 
> supported agents - containers") and LXD resource agent in the "best effort - 
> registration agents" section.
>
> I explain:
>
> * We do have ocf_heartbeat_lxd resource:
>
> Just a service agent to tell the cluster (through CIB attributes) how many 
> containers are running in that node. Pacemaker pengine decisions can be made 
> out of that CIB attribute (to compile decision taking).
>
> For LXD, it seems it uses RAFT through its internal SQLite database for 
> clustering consensus. AND it controls all its own internal resources... so 
> not sure there would be any advantage in creating a pacemaker agent for LXD.
>
> Its quite a long discussion whether to rely on Paxos/Raft/Zab protocols or a 
> "totem single ring" protocol + fencing mechanisms like corosync & pacemaker 
> do... But I think its not worth pursuing a lxd agent if we are not managing 
> multiple resources in big resource groups and clusters.
>
> * We also have ocf_heartbeat_lxc resource: Basically manages lxc containers.
>
> Since LXD is light years in front of pacemaker + lxc I believe, IMO, the 
> strategy here should be to support users of the ocf lxc agent (if any) and 
> point them at lxd clustering.
>
> I could even move lxc agent to "best effort" as our strategy is targeted to 
> lxd.

While lxc is still supported in Xenial, if we're talking only about
future direction, then I absolutely agree.

I also agree it's probably better to allow lxd to manage its
clustering itself, instead of with a pacemaker agent.

>
> > > exportfs- nfs exports (not the nfs server)
>
> That’s a nice catch, I'm supporting NFS HA so I should support this together 
> as it specifies the exported directories. We can configure one per running 
> agent and give it the same fsid for example. Moving to supported.
>
> > wouldn't this be fully supported?
> >
> > > fio - fio instance
> > > galera  - galera instance
> > > garbd   - galera arbitrator instance
> > > jboss   - JBoss application server instance
> > > jira- JIRA server instance
> > > kamailio- kamailio SIP proxy/registrar instance
> > > mariadb - MariaDB master/slave instance
> > > nagios  - nagios instance
> > > ovsmonitor  - clone resource to monitor network bonds on diff
> > > nodes
> > > pgagent - pgagent instance
> > > pgsql   - pgsql database instance
> >
> > shouldn't this be in fully supported?
>
> Pgsql is in [universe]. Unless SEG supports pgsql "by default", do you ?

We're talking about postgresql right?  It's definitely supported (it's
in main), and from a quick look at cases, it gets quite a bit of
support requests, especially around cluster management.

>
> > also Brett (I added to cc) brought up that resource-agents-paf might
> > be worth considering supporting:
> > https://launchpad.net/ubuntu/+source/resource-agents-paf
>
> Also in [universe]. Opened for discussions for pgsql.

Right exactly, Brett was suggesting it may be worth considering this
for main as well.  Just wanted to let you know in case you had any
opinions on it and FYI (and we'll be coming t

Re: RFC: Ubuntu HA resource-agents supportability

[Dan Streetman]

On Tue, Apr 7, 2020 at 7:24 PM Seth Arnold  wrote:
>
> On Tue, Apr 07, 2020 at 03:54:11PM -0400, Dan Streetman wrote:
> > > Xen - xen unprivileged domains
> >
> > as cpaelzer mentioned, Xen should probably move up to the 'best
> > effort' section; this was just moved out of main in focal.
>
> Xen's status before focal was awkward: the source package and libxen were
> in main because libvirt depended upon them. However, the hypervisor and
> related utilities were in universe and not supported.
>
> I'm not sure where exactly this Xen resource agent should be placed on
> the list -- but in practice, Xen wasn't in main, and that may influence
> your thinking.

From UA perspective looking back at support requests, there have been
only a small handful of cases involving Xen hypervisor itself.  There
are quite a few cases where we fixed the Xen guest code in the kernel,
but that's of course different.

So while I would still recommend putting Xen into the 'best effort'
section, in practice it's likely to make little to no difference for
UA.

>
> Thanks

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

Re: RFC: Ubuntu HA resource-agents supportability

[Dan Streetman]

On Tue, Mar 31, 2020 at 1:09 AM Rafael David Tinoco
 wrote:
>
> Hello,
>
> As many as you know I'm currently revamping Ubuntu High Availability
> Packages
>
> For 20.04, considered HA (or HA related) packages are:
>
> - Core packages:
>
>   - libqb
>   - kronosnet
>   - corosync
>   - pacemaker
>   - resource-agents
>   - fence-agents
>   - crmsh
>   - cluster-glue
>   - drbd-utils
>   - dlm
>   - gfs2-utils
>
> - "Deprecated" packages:
>
>   - heartbeat
>   - keepalived
>   - ocfs2-tools
>
> - Not in "main" packages:
>
>   - pcs (will likely replace crmsh in near future)
>   - csync2
>   - corosync-qdevice
>   - fence-virt
>   - sbd
>   - booth
>
> - Related packages:
>
>   - multipath-tools
>   - open-iscsi
>   - sg3-utils
>   - targetcli-fb
>   - tgt (we're trying to deprecate in favor of LIO)
>   - lvm2
>
> For now, until Beta Freeze, we've been trying to catch up with upstream
> latest
> releases and, from now on, I'm going through existing opened bugs and
> addressing
> them with latest fixes (from upstream) + any needed fix to address the bugs
> (done to kronosnet, with FFE opened, and corosync, about to merge fixes to
> it).
>
> Next step is to document in Server Guide all supported scenarios for HA
> related
> packages. The intention here is to describe exact set of scenarios that we
> know
> are good for the perfect behavior of clustering software AND which scenarios
> we
> cannot support.
>
> OBS: This includes the need, or not, to have odd number of nodes/votes, to
> have
> or not proper fencing mechanisms (and which fencing mechanisms to support)
> AND,
> finally, what *resource agents* to support.
>
> I'll probably ask other feedback soon, but, for this moment, I'm asking
> comments
> for the list of resource agents bellow. I tried to split and explain what
> the
> resources are used for and if they are supported in Ubuntu or not (or if the
> related managed service is in [main] or in [universe]).
>
> So please, take some time to provide feedback about this list, whether we
> should
> move resources from one category to the other. *NOTE* that I'm not giving
> the
> "fence agents" list yet. That will be another list.
>
> I'm particularly interested in feedback from @jamespage and @ddstreet as
> they
> probably have good intel about resources usage BUT anyone is welcome to
> provide
> comments!
>
> Thank you very much in advance!

I added a few comments below, otherwise all the categories look
reasonable to me, thanks!

>
>  RFC: Ubuntu HA resource-agents supportability
>
> #
> ## FULLY SUPPORTED (managed service is likely in main or is important
> enough)
> #
>
> # trivial agents
>
> Delay   - test resource for introducing delay
> MailTo  - sends email to a sysadmin whenever a takeover
> occurs
> ClusterMon  - runs crm_mon to a html page from time to time
> HealthCPU   - measures CPU idling and updates #health-cpu attr
> HealthIOWait- measures CPU idling and updates #health-iowait
> attr
> HealthSMART - measures CPU idling and updates #health-smart attr
>
> # services
>
> apache  - apache web server instance
> dovecot - dovecot IMAP/POP3 server instance
> dhcpd   - chrooted ISC dhcp server instance
> mysql   - MySQL database instance
> mysql-proxy - MySQL proxy instance
> named   - bind/named server instance
> nfsnotify   - nfs sm-notify reboot notifications daemon
> nfsserver   - nfs server resource
> nginx   - Nginx web/proxy server instance
> postfix - postfix mail server instance
> rabbitmq-cluster- cloned rabbitmq cluster instance
> remote  - pacemaker remote resource agent
> rsyncd  - rsyncd instance
> rsyslog - rsyslogd instance
> slapd   - stand-alone LDAP daemon instance
> Squid   - squid proxy server instance
> vsftpd  - vsftpd server instance
>
> # storage
>
> Raid1   - software RAID (MD) devices on shared storage
> iscsi   - local iscsi initiator and its conns to targets
> iSCSILogicalUnit- iSCSI logical units
> iSCSITarget - iSCSI target export agent (implementation: tgt,
> lio)
> LVM - LVM volume as an HA resource
> LVM-activate- LVM activation/deact work for a given VG
>   (lvmlockd+LVM-activate OR clvm+LVM-activate)
> Filesystem  - filesystem on a shared storage medium
> symlink - symbolic link
> ZFS - ZFS pools import/export
>
> # locking & reservations
>
> controld- distributed lock manager for clustered FSs
> clvm- clvmd daemon (cluster logical vol manager)

Was clvm dropped from lvm2?

Re: AMD GPU vault install

[Dan Kegel]

> DKMS make.log for amdgpu-17.40-492261 for kernel 5.3.0-40-generic (x86_64)
> /var/lib/dkms/amdgpu/17.40-492261/build/include/kcl/kcl_pci.h:7:5: error: 
> conflicting types for ‘pci_enable_atomic_ops_to_root’

Sounds like you downloaded amdgpu-pro some time ago, and are trying to
install an old version on a system with a new kernel?

If so, please try downloading a newer amdgpu-pro.
- Dan

On Mon, Feb 24, 2020 at 2:42 PM  wrote:
>
> Hello,
> maybe you can use these information about my vault installation with amd 
> gpupro driver.
> My listings were in attachment.
>
> greetings,
> Mr. Faiss
>
> --
> 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

-- 
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

Re: LateX in default Ubuntu 20.04 installation

[Dan Kegel]

It is a bit hard to find.
https://help.ubuntu.com/stable/ubuntu-help/report-ubuntu-bug.html.en
mentions running ubuntu-bug, and that should work; just give the name
of the package as an argument.
- Dan

On Mon, Feb 24, 2020 at 2:42 PM Petr Schuchmann
 wrote:
>
> Hello,
>
> I asked question on AskUbuntu, they said that 20.04 is offtopic. I asked on 
> launchpad https://answers.launchpad.net/ubuntu/+question/688917, but they 
> adviced to report a bug. I couldn't find a link to create new bug report. It 
> seems that bugs are created only via real crash and Apport or I am blind. So 
> this is my last try to help improve Ubuntu and maybe get answer.
>
> Thank you.
> Kind regards.
> P.S.
> --
> 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

-- 
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

Fwd: Call for votes: Developer Membership Board restaffing

[Dan Streetman]

I noticed that my reply to ubuntu-devel-announce was rejected, so just
to make everyone aware of my reply to the announcement, I am
forwarding it to ubuntu-devel.

@rbasak, for future DMB elections, I suggest you cc the ubuntu-devel
list, so people have a chance to reply with questions for candidates.

-- Forwarded message -
From: Dan Streetman 
Date: Fri, Feb 14, 2020 at 9:52 AM
Subject: Re: Call for votes: Developer Membership Board restaffing
To: Robie Basak 
Cc: , devel-permissions



On Fri, Feb 14, 2020 at 9:38 AM Robie Basak  wrote:
>
> The Developer Membership Board (DMB) has started a restaffing vote for
> the seven members whose terms are expiring. The DMB is responsible for
> reviewing and approving new Ubuntu developers. It evaluates prospective
> Ubuntu developers and decides when to entrust them with developer
> privileges. There are eight candidates:
>
> Łukasz Zemczak (sil2100)
> Dan Streetman (ddstreet)
> Simon Quigley (tsimonq2)
> Thomas Ward (teward)
> Eric Desrochers (slashd)
> Micah Gersten (micahg)

Hello @micahg, and thank you for your service on the DMB for all these
years (since 2011)!

However, I can't help but take note that even though you are a DMB
member, you did not attend a single DMB meeting in 2019.  Since quorum
has been a serious problem for the DMB, could you please provide some
insight about why you want to remain on the board, and what your
thoughts are about improving meeting attendance in the future?

Thanks!

> Rafael D. Tinoco (rafaeldtinico)
> Robie Basak (rbasak)
>
> The vote closes on 2020-02-21 at approximately 18:00 UTC.
>
> Ballots are being mailed to all members of ~ubuntu-dev who have a public
> email address visible in Launchpad or who have linked GPG keys that
> verify against their Launchpad accounts. If you are a member of
> ~ubuntu-dev and don't receive a ballot, please contact me privately.
>
> On behalf of the DMB,
> Robie Basak
> --
> Devel-permissions mailing list
> devel-permissi...@lists.ubuntu.com
> Modify settings or unsubscribe at: 
> https://lists.ubuntu.com/mailman/listinfo/devel-permissions

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

Re: Call for nominations: Developer Membership Board

[Dan Streetman]

On Sat, Feb 8, 2020 at 8:26 PM Seth Arnold  wrote:
>
> On Fri, Feb 07, 2020 at 09:21:10AM +0100, Christian Ehrhardt wrote:
> > P.S. Just an opinion and entirely up to you, the alternating meeting time
> > is hard to plan for everyone.
>
> I haven't kept close track of the meetings but my impression is that most
> of them end with "well, there's no quorum, sorry you showed up,

I have kept close track, and unfortunately the DMB only reached quorum
38.46% of the time in 2019 (10 of 26 meetings).

> lets do
> this next time or over email".

Email voting has been done by the DMB very rarely; for example, there
is currently a vote by email pending since Feb 3 (6 days ago), after a
7 day period for any questions from the DMB (Jan 27 - Feb 3), and only
2 DMB members have provided a vote so far.

>
> It's hard to have enthusiasm for this.

I agree.

>
> Can we replace the meeting with something else entirely, something that
> fits better into the schedules of distributed, busy, people?

I have submitted myself as a nominee for the DMB, and if elected (if
there are enough interested candidates to have an election) I hope to
help improve this process.

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

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

Re: libssl or libssl-dev metapackage?

[Dan Kegel]

As far as I know, libssl-dev is stable.
The -dev suffix just means it provides development files, e.g. .h and .pc
files.
On any particular Ubuntu version, it only gets micro updates, and no
experimental ones.
- Dan


On Wed, Dec 11, 2019 at 11:02 AM Brylie Christopher Oxley 
wrote:

> Hello,
>
> I am contributing to an install script that relies on libssl. The script
> is currently hard-coding for libssl release numbers and adding
> conditional checks for each published version. I have suggested that we
> instead use the libssl-dev or openssl metapackage. The concern with
> libssl-dev is that there might be experimental releases under that alias.
>
> Is there a libssl alias or some other way to get only stable libssl
> releases?
>
> Kind regards,
>
> Brylie
>
>
> --
> 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
>
-- 
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

Re: Question on apt-get update

[Dan Kegel]

On Wed, Sep 25, 2019 at 6:19 AM kavitha R  wrote:
> When we run "apt-get update", does it download all the packages information 
> that will be stored in /var/lib/apt/lists/* _Packages file?

I think so.  You could use tcpdump or wireshark to confirm.

> Why do we store the package full description in a different file?

Possibly because apt was written in 1998 and it seemed like a good
idea at the time?

-- 
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

Re: Question on apt-get update

[Dan Kegel]

On Wed, Sep 25, 2019 at 6:19 AM kavitha R  wrote:
> How does apt-cache create and updates the local package cache? Is it periodic 
> or manual? As far as my investigation, it is manual (apt-get update).

It can be manual; if a package like unattended-upgrades is installed,
it can run apt-get update periodically; see
https://wiki.debian.org/UnattendedUpgrades

-- 
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

Re: Application for Contributing Developer: Seyeong Kim

[Dan Streetman]

Congratulations Seyeong!

On Mon, Jul 1, 2019 at 11:46 AM Eric Desrochers
 wrote:
>
> Hello everyone,
>
> Please congratulate Seyeong Kim (xtrusia) on his today's successful 
> contributing developer application !
>
> On behalf of the DMB,
>
> Eric Desrochers (slashd)
>
> On Thu, Jun 20, 2019 at 8:27 PM Seyeong Kim  wrote:
>>
>> Hello
>>
>> I would like to apply for Contributing Developer.
>>
>> My application is here
>> https://wiki.ubuntu.com/xtrusia/contributingdeveloper
>> --
>> Devel-permissions mailing list
>> devel-permissi...@lists.ubuntu.com
>> Modify settings or unsubscribe at: 
>> https://lists.ubuntu.com/mailman/listinfo/devel-permissions
>
> --
> ubuntu-devel mailing list
> ubuntu-devel@lists.ubuntu.com
> Modify settings or unsubscribe at: 
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

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

Re: how sudo handles $HOME

[Dan Streetman]

On Thu, May 16, 2019 at 6:35 AM Carl Friis-Hansen
 wrote:
>
> On 5/16/19 3:03 AM, Alex Murray wrote:
> >
> > On Wed, 2019-05-15 at 02:42:56 +0930, Dan Streetman wrote:
> >
> >> in Ubuntu, sudo retains the calling user's $HOME
> >>
> >> this is different from upstream sudo as well as all other UNIXes and
> >> even the sudo documentation we provide.  Should we remove our custom
> >> patch that adds this behavior?
> >
> > I would argue that our current behaviour provides a more usable default
> > (eg. running vim via sudo uses your own configuration so you don't have
> > to maintain a copy of it in /root) and in the case of a machine with
> > multiple sudo users, they all get to use their own configuration rather
> > than a single configuration under /root.
> >
> > However, it does diverge from upstream and so for new users this creates
> > a surprising situation if they are used to and expect the upstream
> > behaviour - (see comments 6 and 7 in
> > https://bugs.launchpad.net/ubuntu/+source/sudo/+bug/760140) - plus it
> > seems we do not document this change in the man page and so we are
> > creating even more surprises for our users.
> >
> >  From a security point of view I do not see any advantage from either
> > behaviour, so it is really more a usability question IMO.
> >
> >>
> >> for reference and more details on downsides of our current sudo behavior, 
> >> see:
> >> https://bugs.launchpad.net/ubuntu/+source/sudo/+bug/1556302
> >>
> >> Note that I have kind-of hijacked the bug, as I believe the issue is
> >> larger than the python-based example in that bug.
> >>
> >> Also as I commented in that bug, I do not recommend changing the
> >> behavior for existing releases.  But I do think we should change the
> >> behavior starting in Eoan and future releases.
> >
> > I agree if this is changed we should not try and SRU it back.
> >
> I would say let it remain user's home for editor configs.
> You could always use option -i in case you want root home.

That is a significant upside to current behavior; but please don't
forget about the downside of accessing editor configs under sudo:
root-owned editor config files, e.g.:
https://bugs.launchpad.net/ubuntu/+source/sudo/+bug/1556302/comments/9

For some users, this is a simple fix of running sudo chown.  For users
simply following online directions though, the errors resulting from
this can be quite frustrating and confusing.  Try googling for 'root
owned emacs.d' or 'root owned viminfo', e.g.:
http://blog.robertelder.org/vim-forgets-copy-buffer-on-reopen/

For those that commonly use fresh vms or containers, root-owned editor
config files can be a common occurance/annoyance.

>
> --
>-=oOOo=-
>  Carl Friis-Hansen
>  https://carl-fh.com/
>  https://dronehyr.se/
>  Phone: +46 372 775199
>-=oOOo=-
>
> --
> 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

-- 
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

Re: how sudo handles $HOME

[Dan Streetman]

Good question.

I've cc'ed sudo-users, so the question to the upstream sudo list can
be summarized as:
How likely would it be for upstream sudo to add HOME to env_keep by default?

We ask because Ubuntu carries a patch that adds HOME to env_keep,
unlike the default upstream, or any other Linux/Unix.  We are
considering removing that patch, to match upstream defaults, of *not*
including HOME in env_keep.

More details are in this bug:
https://bugs.launchpad.net/ubuntu/+source/sudo/+bug/1556302

On Thu, May 16, 2019 at 5:10 AM Robie Basak  wrote:
>
> On Tue, May 14, 2019 at 01:12:56PM -0400, Dan Streetman wrote:
> > in Ubuntu, sudo retains the calling user's $HOME
> >
> > this is different from upstream sudo as well as all other UNIXes and
> > even the sudo documentation we provide.  Should we remove our custom
> > patch that adds this behavior?
>
> Does upstream have a position on this question, apart from our
> observation of their current default?
>
> For example: what if we changed it back, then someone persuaded upstream
> to flip the default? That would cause disruption to our users twice. Can
> we ensure, before reverting to their default, that upstream have no
> intention of changing it?
>
> Robie

-- 
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

how sudo handles $HOME

[Dan Streetman]

in Ubuntu, sudo retains the calling user's $HOME

this is different from upstream sudo as well as all other UNIXes and
even the sudo documentation we provide.  Should we remove our custom
patch that adds this behavior?

for reference and more details on downsides of our current sudo behavior, see:
https://bugs.launchpad.net/ubuntu/+source/sudo/+bug/1556302

Note that I have kind-of hijacked the bug, as I believe the issue is
larger than the python-based example in that bug.

Also as I commented in that bug, I do not recommend changing the
behavior for existing releases.  But I do think we should change the
behavior starting in Eoan and future releases.

-- 
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

Re: Removal of libllvm4.0 from disco/universe

[Dan Kegel]

Quicker approach:
realizing that the package you want is gone but not forgotten :-),
download the debs from
https://launchpad.net/ubuntu/disco/amd64/clang-format-4.0/1:4.0.1-10build1
and
https://launchpad.net/ubuntu/cosmic/amd64/libllvm4.0/1:4.0.1-10build1
and install them with
  sudo dpkg -i libllvm4.0_4.0.1-10build1_amd64.deb
clang-format-4.0_4.0.1-10build1_amd64.deb
and Bob's your uncle.
- Dan

-- 
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

Re: Removal of libllvm4.0 from disco/universe

[Dan Kegel]

For what it's worth, I just forward-ported 3.9 from xenial to disco
because the alternative was reformatting a bazillion lines of
source code.  It wasn't too hard, just had to do 'apt source clang-format'
on an ubuntu 18.04 box, transfer the source to a 19.04 box,
install gcc 7 and make three little changes to the package, to wit:
http://kegel.com/linux/llvm-ubu1904.patch

There's probably a PPA somewhere with older versions of clang-format,
but if there isn't, I could create one.
- Dan

-- 
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

Re: Improving the Sponsorship Queue and Other Reports (WAS: Re: State of the Sponsorship Queue - Can we get it to 0?)

[Dan Streetman]

On Tue, Apr 23, 2019 at 11:27 PM Simon Quigley  wrote:
>
> Hello Sebastien,
>
> On 4/23/19 4:47 AM, Sebastien Bacher wrote:
> > Hey Simon,
> >
> > Le 21/04/2019 à 00:12, Simon Quigley a écrit :
> >> Today I spent a few hours sifting through the sponsorship queue. I
> >> sponsored everything I could review and was comfortable sponsoring, and
> >> asked for changes on many bug reports. The queue started out at about 70
> >> (I didn't catch the exact number) and is now down to 13.
> >
> > Good work, it's nice to see some sponsoring activity :-)
>
> Thanks (to Robie and Gunnar as well)!
>
> >> One of the most common changes I requested was that people edit bug
> >> descriptions to follow the SRU template for bugs which have sponsorship
> >> requests open for stable releases. Perhaps a message recommending that
> >> could be added to Brian's automatic reply bot.
> >
> > I'm not sure I agree with that being enough of a reason to get them out
> > of the sponsoring queue though. Did you unsubscribe sponsors? Or marked
> > them incomplete? It would be nice to keep those on the list in some way
> > because they can still be useful.
> >
> > Depending of the fix I sometime do edit the description myself the
> > upload rather than bouncing back to the contributor.
> >
> > While it's nicer when the bug is ready/needs to work, I don't think
> > enforcing roundtrips over 'paperwork' always benefits the project. When
> > a fix makes sense and addresses a real issue which is easy to verify it
> > can be less effort for everyone to have the sponsor go the extra mile.
> >
> > (in some cases it's not obvious how the bugs can be triggered/tested,
> > then it makes sense to ask for the details and set as incomplete though).
>
> While I agree with Robie that we have limited contributors working on
> the queue (I have noticed more activity lately from others, thank you!),
> my rationale was to review it purely with an Ubuntu Sponsors Team hat on
> while I was getting the queue to a manageable point; a package is either
> ready to sponsor (sometimes with fix-ups) or it isn't. Sometimes, I can
> understand what a patch is doing by reviewing it, but I would like to
> understand the wider ramifications (if any) from the person that
> reported it. While I recognize this isn't always the case, getting their
> feedback from what can otherwise be a terse bug report has, in my
> experience at least, led to a higher quality paperwork end result.
> Perhaps this is because most of the items I have dealt with recently
> either have an Ubuntu Developer, a Canonical employee, a Debian
> Developer, and/or upstream working on them.
>
> I would like to address the wider point here, though. Right now we have
> no way to leave a comment directly on the sponsorship queue, much like
> we do with MoM, which would solve this. We have sorting, but the CSS
> (while not entirely important) looks outdated. While I could spend a day
> or two polishing that page specifically, and make it look presentable
> with all the fields we would need, we have several other pages that are
> in a similar state. Here are a few examples:
> https://people.canonical.com/~ubuntu-archive/pending-sru.html
> https://people.canonical.com/~ubuntu-archive/phased-updates.html
> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html

I've also been thinking of creating modern (dynamic) interfaces to this info.

>
> These pages are quite scattered; while outputs can come from different
> machines (I have no idea what this looks like internally at Canonical,
> this is just a guess) and different sources (Britney, sru-report, etc.),
> it would be nice to bookmark *one* page that has each of these as clean,
> modern-looking, and consistent pages as sub-pages. From there, we could
> generate reports, perhaps similar to the Debian Maintainer Dashboard.
>
> I understand this might seem like a significant undertaking, and I am
> willing to do the work in order to make this happen, but I would like to
> have the conversation about whether others would find this useful.
> Please let me know if you are an Ubuntu Developer who would like this
> (or if you object to it, more importantly), and I can create an initial
> specification and mockup to send back to this thread.
>
> Thanks!
>
> --
> Simon Quigley
> tsimo...@ubuntu.com
> tsimonq2 on freenode and OFTC
> 5C7A BEA2 0F86 3045 9CC8
> C8B5 E27F 2CF8 458C 2FA4
>
> --
> ubuntu-devel mailing list
> ubuntu-devel@lists.ubuntu.com
> Modify settings or unsubscribe at: 
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

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