ppa-dev-tools 0.6.0 release

[Bryce Harrington]

The `ppa tests` command received a bunch of bug fixes to autopkgtest
trigger URL generation and test result processing, along with some
noteworthy packaging advancements in this 0.6 release.

ppa-dev-tools is a Launchpad API client that lets you create and manage
Personal Package Archives (PPAs) from the command-line, run autopkgtests
against them, and check results.  E.g.:

  $ ppa create my-ppa
  $ dput *.changes ppa:/my-ppa
  $ ppa wait my-ppa
  $ ppa tests my-ppa
  $ ppa destroy my-ppa

There's multiple ways to install:

By Snap...
  $ sudo snap install ppa-dev-tools

By PPA...
  $ sudo add-apt-repository -ys ppa:bryce/ppa-dev-tools
  $ sudo apt-get install ppa-dev-tools

By PIP...
  $ pip install ppa-dev-tools

By source...
  $ git clone https://git.launchpad.net/ppa-dev-tools
  $ cd ppa-dev-tools
  $ sudo python3 ./setup.py install


Notable changes from 0.5 to 0.6
---

With this release comes some significant improvements in packaging of
ppa-dev-tools, including completion of the transition to modern Python
build packaging and dropping of the old setup.py approach.  Of even more
note, ppa-dev-tools is now included in Debian testing, so can now be
installed directly on that operating system; hopefully soon it will be
available from Ubuntu oracular as well.

Meanwhile, the snap packaging has been significantly improved, including
snapshot builds, builds for all supported architectures, better handling
of Launchpad credentials, and a registered alias for the 'ppa' command.

Several irregularities were found in various corner cases with the
parsing, processing, and display of test results for the `ppa tests`
command.  These are fixed and the testsuite expanded to cover a wider
variety of test (mis-)behaviors.  The --package argument now filters the
results as well as the triggers, which will be helpful for users of PPA
containing many packages.

As well, the `ppa tests` command's handling of triggers has received
some fixes that were causing them to not be displayed in some
circumstances, or to be improperly encoded for some package version
numbers.

Thanks to all the contributors to this release: Alberto Contreras,
Alexandre Detiste, Heinrich Schuchardt, Mitchell Dzurick, Nathan Pratta
Teodosio, Simon Chopin and Benjamin Drung.


For more information about ppa-dev-tools, including reporting bugs and
proposing changes via git, please visit the Launchpad project page:

  https://launchpad.net/ppa-dev-tools

Bryce


Issues fixed in this release


* DeprecationWarning: pkg_resources is deprecated as an API. The 
'ppa-dev-tools==0.5.0' distribution was not found
  (LP: #2055636)
* ppa tests --packages still shows test result from other packages
  (LP: #2025483)
* Tests result duplicated
  (LP: #2038649)
* ppa-dev-tools shows failing tests even though they are passing in the log
  (LP: #2043505)
* Duplicated test URLs and no all-proposed URLs
  (LP: #2044608)
* ppa put invalid subcommand
  (LP: #2066884)
* ppa wait waits on cancelled builds
  (LP: #2067268)
* Incomplete packages listing - bionic not included
  (LP: #2038651)
* Try to get results from a serie not available in the ppa
  (LP: #2043595)
* ppa suggests status is a possible argument command
  (LP: #2067271)
* Consider adopting build, poetry or hatch as packaging system
  (LP: #1989617)
* Support subtest status 'FLAKY'
  (LP: #1989650)
* "ppa-dev-tools.ppa tests" fails to trigger build
  (LP: #2049105)
* small help for comfort until --credentials isn't needed anymore
  (LP: #2051235)
* The following error shows as passed: ERROR: testbed failure: unexpected eof 
from the testbed
  (LP: #2065754)


Shortlog of changes since 0.5.1
---

Alberto Contreras (1):
  doc: remove invalid ppa put example

Alexandre Detiste (1):
  replace mock by unittest.mock from standard library

Bryce Harrington (46):
  Include ESM releases in allowed list of triggers.
  results: Add test case for show_results()
  results: Avoid printing excessive duplicate results
  NEWS: Set version
  ppa: Fix the all-proposed link
  ppa: Fix f-string for how to add the ppa
  processes: Include output when raising ReturnCode
  trigger: Refactor object generation into new get_triggers()
  trigger: Refactor trigger display logic to new show_triggers()
  trigger: Rename series_codename to just series
  trigger: Improve Trigger class docs
  tests: Implement test_get_results()
  results: Fix invalid url generation for get_results()
  Rename exception to PpaNotFoundError
  ppa: Use standard error codes for exit conditions
  ppa: Catch exceptions for issues when reading config files
  tests: Expand test cases for test_to_dict()
  tests: Add test case for to_bullet_tree()
  test_result: Add subtest cases to test_to_bullet_tree()
  result: Display status line for failed subtests
  result: Reorder to_b

+1 Maintenance Report

[Bryce Harrington]

[Shorter week than usual due to holiday.]

An unusual amount of tmpfail and timeouts this week.  This may be due to
an infrastructure problem, as discussed in this bug:

https://bugs.launchpad.net/auto-package-testing/+bug/2067074

It could be specific to autopkgtest, or more general, but that needs
analysis, and probably by someone with access to the machinery.

I retriggered a boatload of failed tests that appear to be due to this
problem, and 99% of the time that worked; this was the bulk of my time
spent this stint.  Some of these tmpfails were associated with
transitions, and I have a few additional details to note, below.


### Perl Transition ###

There is currently a minor -4 to -5 update to Perl, which afaict is just
Debian tweaking some architecture settings, but it's kicked off a ton of
tests (the Perl ecosystem is a big one), many of which failed due to the
tmpfail issue above.  I've retriggered all the affected tests but there
may be some residual work.  However, Debian has tended to do multiple
Perl updates per cycle, so I didn't want to spend too much time on that.
There may be more substantial updates in coming months.

Anyway, got all these passing ⚠️  -> ✅ for perl/5.38.2-5:  alice,
aptitude-robot, carton, chemonomatopist, config-package-dev, dh-octave,
dh-sysuser, distro-info, freecontact, hamlib, inspircd, io-stringy,
libacme-eyedrops-perl, libalgorithm-combinatorics-perl,
libalgorithm-munkres-perl, libapache-session-perl,
libcompress-raw-zlib-perl, libconfig-augeas-perl,
libconfig-identity-perl, ,libconfig-json-perl,
libconfig-model-itself-perl, libfile-remove-perl, libfile-util-perl,
libfile-which-perl, libfile-zglob-perl, libfilesys-statvfs-perl,
libnumber-recordlocator-perl, libredis-fast-perl


### Pytest Transition ###

This is messier, with pytest moving from 7.x to 8.x bringing breaking
API changes that have busted a lot of packages.  The upstream changelog
lists a number of "Breaking Changes", so presumably syncs/merges will be
needed.  But there are actually several situations going on:

  * tmpfails.  As mentioned above.  I've retriggered most of these, and
some of them then passed:
- h5py [oracular/s390x]
- ipyparallel [oracular/armhf]
- ipyparallel [oracular/s390x]

  * i386 missing deps.  Not sure if these should all just be
force-badtest hinted or if something more involved is needed, but I
didn't dig into this.  The packages affected here are:
- asdf-astropy/0.6.1-1 (fails on i386 only)
- asdf-standard/1.1.1-1
- asdf-transform-schemas/0.5.0-1
- astroml/1.0.2-4
- ccdproc/2.4.2-1
- feature-check/2.1.0-2build1
- ginga/5.0.1-1
- gwcs/0.21.0-1
- gwcs/0.21.0-
- ndcube/2.2.0-1
- pytest-arraydiff/0.6.1-3
- pyvo/1.5.1-1

  * dcmstack: Needs merged; debian's update should fix the issue.

  * jupyter-client: There is a new 8.x upstream, which Debian is
packaging experimentally in git, but no updates in recent months.
Probably worth discussion with Doko / Debian.
https://qa.debian.org/cgi-bin/vcswatch?package=jupyter-client

  * Other API breaks.  Remaining packages don't have ubuntu delta so
autosync, and same errors occur in Debian.


### httpx ###

This is the source of blockage for a number of python modules,
flask-sqlalchemy, etc.  The errors tend to be proxy errors and timeouts
on socket connections.  Retriggering them hasn't seemed to resolve
them.  I poked around upstream and in debian but whatever is going on
seems to be unique to us.

My guess it is some conflict with how the httpx proxy's tests are
interacting with our infrastructure squid.  Near as I can tell this
worked with httpx/0.26.0-2 and regressed with 0.27, so it seems likely
to be a change in this release.  The changelog for
0.27 (https://github.com/encode/httpx/releases/tag/0.27.0) has only 3
entries, one of which is a fix to make http1 work, which appears to have
been an issue with squid in the distant past.  

I think this may need someone more conversant in autopkgtest
infrastructure to examine.


### ubuntu-release-upgrader ###

The i386 failure was marked version=blacklisted, result=denylisted, and
the log error text suggested contacting Ubuntu QA.  I did so, and Brian
Murray removed it from never_run and requeued the test which then passed.


### Recipes ###

Below are some commands I've collected that can sometimes produce
easily actionable tasks (retriggers, etc.)

retry-autopkgtest-regressions \
--log-regex 'Temporary failure resolving' \
--min-age 2
retry-autopkgtest-regressions \
--force-cached --min-age 2 \
--log-regex 'FAIL timed out'
retry-autopkgtest-regressions \
--force-cached --min-age 2 \
--log-regex 'Unable to connect to ftpmaster'

The above commands generally don't produce anything, but when they do
the item invariably can be simply retriggered and will pass.


retry-autopkgtest-regressions \
--force-cached \
--only-unknown

This is the power tool this week, for 

Re: +1 maintenance report

[Bryce Harrington]

Heya Benjamin,

Just wanted to followup in sharing the spreadsheet as it is so far.
Thanks again for all the suggestions!

https://docs.google.com/spreadsheets/d/1wLOIM-mkN02O-n84YXAOMC6MjEetCyID5JMonEAZSIU

Definitely let me know if you stumble across other useful things, or
even just have ideas/wishlists for capabilities you wish we had for
dealing with these things.

Bryce

On Wed, Jan 03, 2024 at 11:54:47AM +, Benjamin Drung wrote:
> Hi Bryce,
> 
> On Fri, 2023-12-15 at 15:54 -0800, Bryce Harrington wrote:
> > Heya Benjamin,
> > 
> > Quick question for you.  I'm collecting a list of tools people are
> > finding useful or interesting for doing +1 maintenance.  Can you mention
> > any such scripts you used on your rotation this week?  I'm in particular
> > looking for weird/random/unusual stuff, personal or one-off codes, etc.
> 
> I cannot remember using weird/random/unusual stuff. I used the usual
> suspects: looked at the reports in the browser, used Launchpad and
> tracker.debian.org, salsa.debian.org, git-ubuntu, sbuild, dput.
> 
> > Thanks!
> > Bryce
> > 
> > On Fri, Dec 15, 2023 at 04:46:08PM +0100, Benjamin Drung wrote:
> > > Hi,
> > > 
> > > I had a +1 maintenance shift this week. Due to remaining work on apport,
> > > sickness, and a vacation day, I spent less time on it. Therefore the
> > > report is shorter than desired. Here is the report in Markdown format:
> > > 
> > > * **python-aioice**: Retried python-aiortc test on armhf and s390x (they
> > > failed on installation) but it still fails. This is caused by python3-
> > > aiortc depending on python3-av < 11 (but having 11.0.0-1). python-aiortc
> > > needs to be updated to 1.5.0-3 but that fails to build (due to depending
> > > on python3-av < 11).
> > > 
> > > * **dh-make-golang**: Created [dh-make-golang 0.6.0-2 fails to build
> > > from
> > > source](https://bugs.launchpad.net/debian/+source/dh-make-golang/+bug/2046369
> > > )
> > > 
> > > * **debvm**: Created [debvm 0.2.13 autopkgtest fails on
> > > ppc64el](https://bugs.launchpad.net/ubuntu/+source/debvm/+bug/2046544)
> > > and forwarded to Debian
> > > 
> > > * **python-rtree**: autopkgtest failed on i386 due to installation
> > > dependency issue. Tried with migration-reference/0 where it failed as
> > > well. Then python-rtree migrated.
> > > 
> > > * **python-mceliece**: Documented [python-mceliece 0~20230612.1-1 FTBFS
> > > due to missing
> > > libmceliece1](https://bugs.launchpad.net/ubuntu/+source/python-mceliece/+bug/2046548
> > > )
> > > 
> > > * **python-lib25519**: Document [python-lib25519 0~20230630.1-1 FTBFS
> > > due to missing lib25519-
> > > 1](https://bugs.launchpad.net/ubuntu/+source/python-lib25519/+bug/2046550
> > > )
> > > 
> > > * **python-libais**: Fixed Python 3.12 related failures and uploaded
> > > 0.17+git.20190917.master.e464cf8-4 to Debian unstable
> > > 
> > > * **python-svg.path**: Add patch to use better than nothing font and
> > > upload 6.3-2 to unstable to unblock pillow 10.1.0-1
> > > 
> > > -- 
> > > Benjamin Drung
> > > Debian & Ubuntu Developer
> > > 
> > > -- 
> > > ubuntu-devel mailing list
> > > ubuntu-devel@lists.ubuntu.com
> > > Modify settings or unsubscribe at: 
> > > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
> 
> -- 
> Benjamin Drung
> Debian & Ubuntu Developer

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

Re: +1 maintenance report

[Bryce Harrington]

Heya Benjamin,

Quick question for you.  I'm collecting a list of tools people are
finding useful or interesting for doing +1 maintenance.  Can you mention
any such scripts you used on your rotation this week?  I'm in particular
looking for weird/random/unusual stuff, personal or one-off codes, etc.

Thanks!
Bryce

On Fri, Dec 15, 2023 at 04:46:08PM +0100, Benjamin Drung wrote:
> Hi,
> 
> I had a +1 maintenance shift this week. Due to remaining work on apport,
> sickness, and a vacation day, I spent less time on it. Therefore the
> report is shorter than desired. Here is the report in Markdown format:
> 
> * **python-aioice**: Retried python-aiortc test on armhf and s390x (they
> failed on installation) but it still fails. This is caused by python3-
> aiortc depending on python3-av < 11 (but having 11.0.0-1). python-aiortc
> needs to be updated to 1.5.0-3 but that fails to build (due to depending
> on python3-av < 11).
> 
> * **dh-make-golang**: Created [dh-make-golang 0.6.0-2 fails to build
> from
> source](https://bugs.launchpad.net/debian/+source/dh-make-golang/+bug/2046369
> )
> 
> * **debvm**: Created [debvm 0.2.13 autopkgtest fails on
> ppc64el](https://bugs.launchpad.net/ubuntu/+source/debvm/+bug/2046544)
> and forwarded to Debian
> 
> * **python-rtree**: autopkgtest failed on i386 due to installation
> dependency issue. Tried with migration-reference/0 where it failed as
> well. Then python-rtree migrated.
> 
> * **python-mceliece**: Documented [python-mceliece 0~20230612.1-1 FTBFS
> due to missing
> libmceliece1](https://bugs.launchpad.net/ubuntu/+source/python-mceliece/+bug/2046548
> )
> 
> * **python-lib25519**: Document [python-lib25519 0~20230630.1-1 FTBFS
> due to missing lib25519-
> 1](https://bugs.launchpad.net/ubuntu/+source/python-lib25519/+bug/2046550
> )
> 
> * **python-libais**: Fixed Python 3.12 related failures and uploaded
> 0.17+git.20190917.master.e464cf8-4 to Debian unstable
> 
> * **python-svg.path**: Add patch to use better than nothing font and
> upload 6.3-2 to unstable to unblock pillow 10.1.0-1
> 
> -- 
> Benjamin Drung
> Debian & Ubuntu Developer
> 
> -- 
> 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: Retention period for autopkgtest test logs

[Bryce Harrington]

On Tue, Sep 26, 2023 at 04:53:05PM -0700, Steve Langasek wrote:
> On Mon, Sep 25, 2023 at 03:22:59PM -0700, Bryce Harrington wrote:
> > Moreover, there are other use cases beyond test failure fixing.
> > Consider MREs and SRUs, where you prepare a package in a PPA, and run
> > autopkgtest as part of the criteria for having the package be accepted.
> 
> For the record, I don't believe the SRU team has ever asked for pre-upload
> autopkgtests as a condition of an MRE.

That's not correct, there's been at least one recent MRE I'm aware of
that did this:
https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/2027079

It'd be reasonable to expect more along these lines.  But MREs are just
one of several use cases I outlined.  PPA+autopkgtest is a handy
service and flexible for a number of different workflows.

> Given the frequency with which autopkgtest infrastructure gets overloaded, I
> generally take the view that ppa autopkgtest runs should be kept to a
> minimum because the results don't transfer to the main archive and all have
> to be run again, and it's the second run that actually matters for
> proposed-migration.

Well, that's moving the goalposts on this argument - the original
concern was regarding test log retention for already-run PPA tests, not
whether autopkgtesting against PPAs is useful at all or just contributes
to overloading the infrastructure.  That's an entirely different
question, but I'd push back on that too.

Tests run against PPAs are processed at a lower default priority than
the primary archive.  So, assuming you're queuing a test run that is
destined to fail, doing so in a PPA actually *helps* the infrastructure
load balance when is in an overloaded state.  Not to mention, that
uploading a broken test for one package risks causing any of its
dependencies to also run into trouble, which can cause a cascade of
people retriggering things to try to figure out what introduced the
problem.

Ultimately, our goal here is to ensure the highest quality of Ubuntu
possible.  Obviously none of us wish to logjam Britney by pushing it
beyond its capabilities.  But if that is indeed a risk, wouldn't it be
better to strengthen Britney rather than weaken our testing processes?

Anyway, this is way more verbose than I intended.  I of course
understand there's trade-offs and that tech can have weird and
unexpected limitations.  My original question was just why 8 weeks was
felt preferrable to a larger number.  If there's a strong reason for
that, we'll just have to live with it, but to me 26 weeks would seem
like it'd be long enough to avoid most of the (admittedly outlier)
issues I could imagine.

Bryce

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

Re: Retention period for autopkgtest test logs

[Bryce Harrington]

On Mon, Sep 25, 2023 at 04:02:28PM -0300, Andreas Hasenack wrote:
> Hi,
> 
> On Mon, Sep 25, 2023 at 3:56 PM Steve Langasek
>  wrote:
> >
> > On Mon, Sep 25, 2023 at 11:17:50AM -0700, Bryce Harrington wrote:
> > > On Mon, Sep 25, 2023 at 10:23:36AM -0700, Brian Murray wrote:
> > > > Currently test results and log files for autopkgtest runs are kept until
> > > > the release for which the test was run reaches its End of Life. This is
> > > > also true for autopkgtest runs for packages in PPAs and the Ubuntu QA
> > > > team thinks we should not be keeping these for such a long period of
> > > > time.
> >
> > > > We plan to automatically remove test results for PPAs which ran more
> > > > than 8 weeks ago. Does 8 weeks seem like too short of a period to
> > > > anybody?
> >
> > > It does feel a bit short; prior results can sometimes be interesting for
> > > comparison purposes,
> >
> > Why would your baseline be a ppa build >8 weeks old, as opposed to a run in
> > the Ubuntu archive?  8 weeks is a long time to be iterating in a PPA without
> > uploading it to the devel series.
> >
> > I have no opinion about whether longer than 8 weeks is ok for autopkgtest
> > result retention.  But it seems alarming to me that we would have
> > out-of-archive development branches lasting 2 months.
> 
> There are PPAs for customer engagements that are long-lived. DEP8
> results might be important for some of those.

Indeed, not to mention the public server-backports PPA that we
maintain.  I don't know that we've particularly leaned on the
autopkgtest service for such PPAs (although perhaps we should).

But the specific use case Steve discussed is that of running autopkgtest
iteratively to diagnose a test failure, with the aim of getting it
uploaded to the -devel series.  Ideally, such a basic task should not
take more than a couple days, so in that sense 8 weeks seems more than
ample.

In practice, though, so many weird things can happy to cause delay.
Consider if you need to consult Debian or upstream about a test failure;
it may take a few weeks to get a reply, so your 2-day task may have a
lengthy wait in the middle of it.  If the test failure is caused by
something fixed in a dependency, you might like to wait for that
dependency to be released.  Even just getting sidetracked by some other
priority is not unheard of.  When you come back to the issue later in
the cycle, if your log links no longer work, that'd be a bit annoying.

Moreover, there are other use cases beyond test failure fixing.
Consider MREs and SRUs, where you prepare a package in a PPA, and run
autopkgtest as part of the criteria for having the package be accepted.
The acceptance process can take upwards of several weeks, during which
time the test results will be highly relevant, particularly if when the
package finally does get uploaded to the archive and hits a test failure
unexpectedly.

For the server team, we generally run PPA autopkgtests against even
packages intended for -devel, as part of our MP review process.
Normally, this process takes only a couple days, but again there are
many outliers where things drag out.

Transitions and flaky test debugging are other situations where having
test logs available for a longer period of time might be helpful.

So, this is why 8 weeks feels a bit short.  Not due to typical use cases
but rather the a-typical ones.

Bryce

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

Re: Retention period for autopkgtest test logs

[Bryce Harrington]

On Mon, Sep 25, 2023 at 10:23:36AM -0700, Brian Murray wrote:
> Currently test results and log files for autopkgtest runs are kept until
> the release for which the test was run reaches its End of Life. This is
> also true for autopkgtest runs for packages in PPAs and the Ubuntu QA
> team thinks we should not be keeping these for such a long period of
> time.
> 
> We plan to automatically remove test results for PPAs which ran more
> than 8 weeks ago. Does 8 weeks seem like too short of a period to
> anybody?

It does feel a bit short; prior results can sometimes be interesting for
comparison purposes, although even that value diminishes quickly over
time.  Is there a strong reason to favor 8 weeks vs. say 26 weeks
(i.e. our development cycle length)?

Bryce


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

ppa-dev-tools 0.5.0 released

[Bryce Harrington]

This 0.5 release of ppa-dev-tools includes a number of usage
conveniences people have requested, and some important fixes.


There's multiple ways to install:

By Snap...
  $ sudo snap install ppa-dev-tools
  $ sudo snap alias ppa-dev-tools.ppa ppa

By PPA...
  $ sudo add-apt-repository -ys ppa:bryce/ppa-dev-tools
  $ sudo apt-get install ppa-dev-tools

By PIP...
  $ pip install ppa-dev-tools

By source...
  $ git clone https://git.launchpad.net/ppa-dev-tools
  $ cd ppa-dev-tools
  $ sudo python3 ./setup.py install


Notable changes from 0.4 to 0.5
---

It is now possible to create PPAs under a different team's ownership via
the `--owner` option:

$ ppa create --owner foobar my-ppa

As a convenience, this can also be specified in ppa address form, i.e.:

$ ppa create ppa:foobar/my-ppa

Furthermore, most places that take a PPA address will also take a full
URL, including URLs ending with /+packages.  For example, all of these
are accepted as valid PPA specifiers:

$ ppa wait my-ppa
$ ppa wait myself/my-ppa
$ ppa wait ppa:myself/my-ppa
$ ppa wait https://launchpad.net/~myself/+archive/ubuntu/my-ppa
$ ppa wait https://launchpad.net/~myself/+archive/ubuntu/my-ppa/
$ ppa wait https://launchpad.net/~myself/+archive/ubuntu/my-ppa/+packages


Private PPA support is now available via the `--private/--public`
arguments, allowing toggling a PPA's privacy, if allowed by Launchpad.
For example:

$ ppa create --private ppa:myself/my-private-ppa


It is now possible to save and load Launchpad OAuth credentials, to
permit use of ppa-dev-tools in situations where you can't use
launchpadlib's automatic authentication mechanics.  A new command is
added to dump the credentials from an authenticated session:

$ ppa credentials
Launchpad credentials written to credentials.oauth

You can then load them via a new `--credentials` global argument, for
example:

$ ppa --credentials ./credentials.oauth create ppa:myteam/myppa

Credentials can also be supplied via an LP_CREDENTIALS environment
variable.  Thanks to Massimiliano Girardi for this feature.


The `ppa wait` behavior has changed to display just a screenful of
status while waiting on builds.  The old behavior, where status updates
are printed to stdout and scrolled, is still available via the --log
option.

Also, the `wait` command now supports a 'name' configuration parameter
that allows specifying a single source package to wait on.  The
'wait_max_age_hours' parameter makes it consider only uploads within the
given timeframe.  The 'exit_on_only_build_failure' parameter makes the
wait exit if the only jobs that it is monitoring are failed builds.
These options are aimed to facilitate CI/CD integration, but can also
improve performance of the waiting operation on larger PPAs.


This release provides an important bugfix, enabling the `ppa tests`
command to properly parse and handle newer format autopkgtests.  The log
files for tests run on Ubuntu lunar and newer are prefixed with a
timestamp that caused `ppa tests` to misread the subtest name.  The
timestamps are now recognized and subtest names parsed properly.
(LP: #2025484)

Other bugfixes have focused on improvements to input and error handling
for a variety of conditions that have come up in practice.  This
includes some more robust handling of errors generated during Launchpad
outages or other glitches (LP: #1997122).


For more information about ppa-dev-tools, including reporting bugs and
proposing changes via git, please visit the Launchpad project page:

  https://launchpad.net/ppa-dev-tools

Bryce

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

[Bryce Harrington]

# Plus One Maintenance for Week of Sep 04-08, 2023 #

Here's notes for what I've worked on.  Since Monday was a holiday for
me, I also had a shortened week.

The previous +1 maintenance report (by Benjamin Drung) is here:
https://lists.ubuntu.com/archives/ubuntu-devel/2023-September/042775.html


## sphinx cluster ##

* dolfin: All architectures had hit timeout failure issues on basic
  autopkgtest.  I retriggered and they passed.  I then retriggered with
  sphinx-rtd-theme and a few other packages to clear the update excuse.

* fenics-dolfinx: Same as dolfin, and basic retriggers also passed.
  Then also retriggered against sphinx-rtd-theme & co. successfully.

* pyfai: Test failure on armhf (only).
  - Appears to be a known-issue upstream, with a fix and a new release
that landed in Debian just last week.
  - I confirmed the necessary patch is present in 2023.08, and sync'd
the package (it has no Debian delta).

* sphinx-rtd-theme: With the above items resolved, sphinx-rtd-theme
  migrated successfully.


## multipath-tools ##

fence-agents had an autopkgtest failure on ppc64el.  A simple retrigger
enabled it to pass, allowing multipath-tools to migrate.


## rust-ahash ##

jbicha already reported the FTBFS to Debian, as it also affects them.
I've filed a bug report on our end, LP: #2034621.


## exec-path-from-shell-el ##

FTBFS trying to install deps, I'm gathering its trying to download from
the internet?  Debian hits same issue.  I suspect we just need to give
Lyx a -userdir.  I've filed update-excuse LP: #2034630.


## gpsim-doc ##

FTBFS writing to a non-existant directory.  This uses Lyx to build the
docs, which requires write access to $HOME/.lyx, but $HOME is
deliberately set to undefined so this breaks.  Same issue affects
Debian.  For now I've filed update-excuse LP: #2034631


## Django cluster ##

* senlin-dashboard FTBFS: Doesn't impact Debian (yet) but they haven't
  built against the newer Django afaict.  Filed LP: #2034629 for
  tracking.

* masakari-dashboard FTBFS: Different errors, but same situation as
  senlin-dashboard of failure after minor Debian update that they build
  only against the old Django.  Mentioned on same bug as above.



## Stats ##

2023-09-05  239 update excuse records found
2023-09-06  214 update excuse records found
2023-09-07  210 update excuse records found
2023-09-08  206 update excuse records found

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

Re: +1 maintenance report (14/Aug - 18/Aug)

[Bryce Harrington]

On Mon, Aug 21, 2023 at 09:47:18AM -0700, Steve Langasek wrote:
> On Mon, Aug 21, 2023 at 10:16:31AM +0800, Shengjing Zhu wrote:
> > + golang-github-protonmail-go-crypto
> >   The error message says "out of memory". I can reproduce this on a VM with
> >   500M memory.
> >   It's because the testdata in TestSymmetricDecryptionArgon2 uses a large
> >   memory exponent parameter.
> >   It's same as https://github.com/ProtonMail/go-crypto/pull/178 (But this
> >   bug is only for 32bit arch, and is fixed in this package). 
> >   TestSymmetricDecryptionArgon2 is passed on 32bit arch, but only fails on
> >   arm64 and s390x.  Maybe the autopkgtest VM for these two architectures
> >   has less memory?  even less than armhf (I know it is lxd container
> >   instead VM, but not sure about the memory configurations).
> 
> >   LP: #2032145
> 
> The armhf lxd containers do not have hard partitioning of memory
> allocations, so *generally* tests on armhf will have more memory available
> than on other architectures.  But that memory is also shared across tests,
> so "noisy neighbor" effect is more of a problem.

Is there a technique for identifying when this may be the case, when
we're troubleshooting armhf-specific issues?

You know, it would be super useful if we had a handbook of architectures
for our autopkgtest infrastructure, that explains both the fundamental
differences between the architectures (e.g. cpu-specific uniquenesses)
and the implementational characteristics of how it's set up in Canonical
infrastructure (e.g. the memory configuration strategy with the armhf
lxd containers).  Does a doc like this already exist?

For new +1 maintainers this might help with some of the sense of
overwhelm one gets, but also even for experienced folks having itemized
lists of idiosyncrasies could help jog the memory.  (And as the
infrastructure evolves it could help communicate what's changed, and/or
identify more ways to improve...)

Bryce

-- 
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 MP workflows in Launchpad

[Bryce Harrington]

On Thu, Jun 29, 2023 at 09:13:01PM +0200, Sebastien Bacher wrote:
> Hey Bryce,
> 
> Le 29/06/2023 à 20:12, Bryce Harrington a écrit :
> > I do love automation, however I think we shouldn't rule out letting this
> > be somewhat manual.  I.e. we already tell non-git-ubuntu sponsorees to
> > manually sub ubuntu-sponsors:
> > 
> >https://wiki.ubuntu.com/MOTU/Contributing
> >"Set the bug to Status "Confirmed". Assign to "Nobody". Subscribe the
> >ubuntu-sponsors team to add your bug to the Sponsorship Queue."
> > 
> > So we could just have the docs direct them to add both ~ubuntu-sponsors
> > *and*  ~ubuntu-sponsors-reporter, and it wouldn't be inconsistent with
> > established procedures.
> 
> The fact that it matches the existing situation doesn't make it the right
> outcome though...

Oh 100% agreed there.  Unsubscribing is a poor way to track state, and
can be lossy in multiple ways, as you point out.  But there is value in
having similar processes work in consistent fashion.

> In practice we often have bugs where the contributor did what was asked to
> address the reviewers feedback but forgot to subscribe back the sponsors.
> With the current workflow we have very little visibility on those cases and
> they often end up lost in the launchpad noise.
>
> It would be nice if we had a way to at least query for those bugs so we
> could review recent activity and see if there are cases were sponsors should
> be subscribed back and hadn't...

Yes, this is a good illustration of the point I made about there being
essentially two different states needing tracked, with this describing
the review state for the MP.  In a bug-centric workflow, we would be
able to set the bug to "Incomplete (without response)" which
automatically gets set to "Incomplete (with response)" once there's a
new comment on the bug.  To the user the "reporter status" is just
"Incomplete" in both cases, yet for the reviewer there are actually two
substates - "with response" and "without response" - that can be queried
for, so we can review recent activity and make adjustments to the
visible state.

Something equivalent to that but for Launchpad MP's would be very
helpful, and would give us a better workflow than the one we have using
subscription/unsubscription.  Unfortunately, I'm not sure if this is
doable with how Launchpad MPs work currently.

Bryce

-- 
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 MP workflows in Launchpad

[Bryce Harrington]

On Thu, Jun 29, 2023 at 03:18:27PM +0100, Robie Basak wrote:
> # The "grabbing" of review slots
>
> This is the immediate problem.
>
> The sponsorship queue displays git-ubuntu MPs for which ~ubuntu-sponsors
> has a review slot. But if a member of the team votes (eg. "Needs
> Information"), then Launchpad replaces the review slot reviewer with
> that individual. Then ~ubuntu-sponsors is no longer a reviewer, so the
> MP disappears from the sponsorship queue, never to reappear unless
> someone adds an ~ubuntu-sponsors slot manually.

The proposed solution of adding ~ubuntu-sponsor-reporter (either
manually by the sponsoree or via some sort of automation) would indeed
resolve this slot-stealing glitch in the workflow.  I agree it's worked
well for the server team and fits our workflow rather well.

However, as you point out, this does create a secondary issue of making
it harder to make things disappear from the sponsorship queue
_intentionally_.  For the server team workflow, the unclosable cruft
seems to be a minor annoyance we just live with, but the volume we deal
with is relatively small and we've got informal ways to connect
our small number of internal reviewers and reviewees so the problem is
not hard for us to work around.

For the patch pilot workflow, the volume is higher and the number of
reviewers broader, so I suspect a harder-to-make-things-disappear
issue might present as much if not more pain than the slot-stealing
glitch.

> It needs to be possible for a git-ubuntu MP to end up in the sponsoring
> queue. This should happen automatically for contributors who won't be
> aware of any process that we decide, but do manage to figure out how to
> submit the MP against a git-ubuntu branch.

I do love automation, however I think we shouldn't rule out letting this
be somewhat manual.  I.e. we already tell non-git-ubuntu sponsorees to
manually sub ubuntu-sponsors:

  https://wiki.ubuntu.com/MOTU/Contributing
  "Set the bug to Status "Confirmed". Assign to "Nobody". Subscribe the
  ubuntu-sponsors team to add your bug to the Sponsorship Queue."

So we could just have the docs direct them to add both ~ubuntu-sponsors
*and* ~ubuntu-sponsors-reporter, and it wouldn't be inconsistent with
established procedures.

Obviously we want to avoid overwhelming new contributors with too many
knobs, as that can lead to confusion and error, but adding reviewer
slots is ameniable to documentation like we've done with the Ubuntu
Maintainers' Handbook, and even scripted (ex. git-ubuntu's MP proposal
filing functionality).

One could argue also that having it be a manual knob has some
edificational benefit since, as you also point out, as one gains
experience one might seek reviews/approvals from specific teams instead
of or in addition to patch pilot.

Anyway, I'm all for automation but here I think we needn't rush into
that, as IMHO doing it manually isn't too horrible and may have
benefits.


> When patch piloting, a sponsor may need to leave a vote on an MP such as
> "Needs Fixing". Once the contributor has fixed the MP, we need to ensure
> that MP is on the sponsorship queue (whether or not it was temporarily
> removed).

This is a very salient issue, and brings up a point I think warrants
further attention and discussion.  Indeed, I think this question of
capturing a Pilot's evaluation is *the* most important point needing
addressed.

The status tracking for MPs provided by Launchpad is quite limited
(for appropriate reasons), and the permissions to alter the state is
quite restricted (also for appropriate reasons).  So I don't see
solutions easily at hand.  But at least the needs are apparent.

The way the Patch Pilot program is designed, the concept is for one
pilot to handoff to the next once their shift is over, as opposed to an
arrangement where, for example, a pilot would take ownership of a
sponsorship request and shepherd it all the way from cradle to grave.
Yes, many of us have been doing that anyway, and some might argue
that's an overall better process, but it's not how the project has been
formally defined to work.

So, that means one pilot might identify some extra task for an MP, but
then they'll de-shift, and a subsequent pilot evaluates if that task is
done, and so on.  This style of status wants to be tracked per-MP rather
than per-reviewer, which goes against LP's MP workflow.


A second obvious need is that there's really two separate statuses to
track - one for the overall MP state from the submitter's perspective,
and a second for the pilotability MP state, from the patch pilot program
perspective.  These two states are interrelated and one can probably be
inferred from the other, but it's worth recognizing that notionally
they're conceptually distinct.

For example, a not at all uncommon case is an MP for a change in Ubuntu
that instead needs to be sent to Debian or upstream.  From a patch pilot
POV we evaluate and decide that needs done, and then we want to close it
out since no further 

Re: git-ubuntu build

[Bryce Harrington]

On Fri, Jun 09, 2023 at 09:11:34PM -0700, Steve Langasek wrote:
> On Wed, Jun 07, 2023 at 09:27:47PM -0700, Bryce Harrington wrote:
> > On Wed, Jun 07, 2023 at 06:41:14PM -0700, Steve Langasek wrote:
> 
> > It does not exist, actually!  I recall we dropped it a few years ago,
> > see see f2dc622e.
> 
> $ git-ubuntu help
> usage: git-ubuntu [-h]  ...
> git-ubuntu: error: argument : invalid choice: 'help' (choose from 
> 'build', 'build-source', 'import-local', 'import-ppa', 'lint', 'review', 
> 'clone', 'export-orig', 'import', 'importer-service-broker', 
> 'importer-service-poller', 'importer-service-worker', 'merge', 
> 'prepare-upload', 'queue', 'remote', 'submit', 'tag')
> 
> ^
> $

Heh, that list is pretty out of date.  build-source is gone, and I think
review and lint are as well.  There is still a 'build' module with some
of the remaining code from the original build command, but you can see
from the above commit that the hook for the command was removed.

> > That said, though, I've wondered if 'build' may not necessarily be the
> > ideal jargon, anyway.  Since the (prepare-upload args) step can trigger
> > a git push, and because this is done principly when uploading, it feels
> > more like a submission-style workflow than a build; "build" also implies
> > you're creating some form of artifact for local use, which in this case
> > you're not, really.
> 
> > So, I'd suggest that even though 'git-ubuntu build' is not used, you may
> > still want to think more anyway about if there's a better term.
> 
> Related commands:
> 
>  - dpkg-buildpackage
>  - debuild
>  - gbp buildpackage
>  - bzr builddeb
>  - sbuild
> 
> So "build" is quite a strong theme in the existing tools.
>
> An interesting point, though, is that this makes me realize I would only
> ever care about the sauce this provides when preparing a source package for
> upload to Ubuntu, and not when I was trying to do a binary package build. 
> Another previous git-ubuntu subcommand was 'git-ubuntu build-source'.  Do
> you think that would be a better fit?

That occurred to me too.  We had subsumbed 'build-source' to 'build -S'
since both commands used basically the same code just passing the -S
along to the underlying tools.

> I don't think 'submission-style' quite describes what I'm expecting to
> achieve here.  I might want to build a source package, then do a variety of
> things with it before actually uploading it; e.g. run a debdiff against the
> previous package to be sure it's actually a clean diff at that level, take
> the source artifacts and do a test build, push to a ppa before pushing to
> the Ubuntu archive, manually mangle the .changes file (rare, but I happen
> to have just done this for a series of SRUs so that they would have complete
> changelogs but not link to a whole list of unrelated bugs in the SRU
> process), etc.  And the target of the 'git push' may or may not be something
> that we want to merge immediately, may or may not want to raise an MP for
> immediately.

Right, the point I was making there is that since the 'prepare-upload'
step pushes the branch to Launchpad, I don't want or need to include
that in my workflow until the end, after all that is done and I'm ready
to do the .changes upload.  Then I do one final debuild -S and run
prepare-upload, verify it worked and check the .changes file has
expected fields, and then I directly dput the .changes.  I think of that
as more of a submission-style procedure.

But, there's more than one way to do this.  I'm sure we all have unique
workflows for how we prep source packages.

Bryce

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

Re: git-ubuntu build

[Bryce Harrington]

On Wed, Jun 07, 2023 at 06:41:14PM -0700, Steve Langasek wrote:
> Hi folks,
> 
> As git-ubuntu sees increasing use, including for such things as requests for
> sponsorship of Debian merges, I've had an itch to scratch regarding the
> complexity of passing correct flags to dpkg-buildpackage, so I spent some
> time prototyping a git-ubuntu wrapper for it.
> 
> bzr-builddeb hasn't been useful for general work on Ubuntu packages for
> quite a while, but the behavior of this wrapper is inspired by it. 
> Hopefully some of you will find using this tool pleasantly familiar!
> 
> The intent is that this will eventually become a git-ubuntu subcommand,
> though there are some namespace questions to sort out first - the obvious
> name for such a command IMHO would be 'git-ubuntu build' but that already
> exists and does other things.

It does not exist, actually!  I recall we dropped it a few years ago,
see see f2dc622e.  I recall at the time it was intended to one day bring
it back, but the plan was to reimplement - as you're doing - but also
build it up from first principles with ample test case coverage.  The
original subcommand lacked tests, but tried to do a bit too much (it
included wrapping lxd, running lint, etc.) and the lack of tests made
maintenance a bit scary.  So, I'd encourage making matching tests as you
go.  :-)

That said, though, I've wondered if 'build' may not necessarily be the
ideal jargon, anyway.  Since the (prepare-upload args) step can trigger
a git push, and because this is done principly when uploading, it feels
more like a submission-style workflow than a build; "build" also implies
you're creating some form of artifact for local use, which in this case
you're not, really.

So, I'd suggest that even though 'git-ubuntu build' is not used, you may
still want to think more anyway about if there's a better term.


> From initial feedback, I know a lot of developers are using sbuild to build
> their source packages rather than invoking dpkg-buildpackage directly.  I
> would like to provide a corresponding wrapper for sbuild as a next step - I
> would suggest this should eventually be called 'git-ubuntu sbuild'.
> 
> Anyway, I've been using this script in anger for a week, so I'd like to
> welcome other folks to give it a try now as well.
> 
> To get started:
> 
>  git clone lp:git-ubuntu
>  cd git-ubuntu
>  sudo mk-build-deps -i -r . (or: sudo apt build-dep .)
>  export PATH=$PATH:$(pwd)/sandbox
> 
>  then cd to a git-ubuntu repo, and:
> 
>  gu-build
> 
> Note that this calls the equivalent of `git-ubuntu prepare-upload args`
> under the hood, so will push to a launchpad branch under your user.
> 
> Why this is useful:
> 
> - the syntax 'dpkg-buildpackage $(git-ubuntu prepare-upload args)' is
>   onerous and repetitive - but we want to encourage inclusion of these
>   headers in .changes files, as this lets us automate closure of git-ubuntu
>   MPs
> - there are certain options that can be inferred as correct for any
>   git-ubuntu repo (-i -I)
> - orig.tar.xz should be reconstituted or downloaded when needed, without
>   extra commands (we have pristine-tar branches in git-ubuntu which often
>   save having to do a duplicate download; having to clone a git repository
>   *and* apt source the package is meh)
> - getting the correct options to dpkg-buildpackage by hand for a package
>   merge is tedious; this automates -v and -sa arguments.

Very cool, and I'll have to look at what you're doing to automate the
-sa arguments, I hadn't figured out a good solution there.

Btw, you may already be doing this but I've found in scripting this
myself that it's worthwhile to check the $(git ubuntu prepare-upload
args) run for exit codes before passing its output along; there are
situations where it fails.

In addition, I always do a grep "^Vcs-Git" on the produced changes file,
since if prepare-upload fails (or you're using an old git-ubuntu version
that doesn't have it), you can accidentally end up producing a valid
.changes file that doesn't have the Vcs info.

Bryce

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

Re: What's going on with proposed migration?

[Bryce Harrington]

On Thu, Feb 16, 2023 at 07:57:45PM -0500, Sergio Durigan Junior wrote:
> On Thursday, February 16 2023, Brian Murray wrote:
> 
> > First off I want to apologize for not sending this earlier. The Ubuntu
> > QA team was focused on restoring the service but could have been more
> > communicative regarding what was going on.
> >
> > In brief there was an outage with some underlying infrastructure
> > provided by Canonical IS which took us a little while to catch and then
> > a while longer to work around due to a multitude of failures. However,
> > the set of failures we encountered have exposed some issues with
> > the service running the autopkgtests which we plan to address in the
> > near future.
> 
> Thanks for your and the QA team's work on this, Brian.

Agreed, keeping infrastructure running happily makes all of our jobs
easier and more efficient.

> > If anybody is interested in the potentially boring nitty-gritty details
> > I'd be happy to send a follow up email.
> 
> I'm personally interested in the details, and I also think it's a good
> idea to leave a more detailed record for posterity.

Ditto, and I'd be keen to hear things us devs could do to help minimize
or avoid problems in the future.  E.g. things to avoid or check for when
writing autopkgtests?

Bryce

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

Re: PSA: autopkgtest environment behavior change

[Bryce Harrington]

On Fri, Feb 03, 2023 at 11:38:13AM -0800, Brian Murray wrote:
> I recently discovered that autopkgtests which are getting OOM killed
> were behaving differently. Paride and I have tracked this down to a
> change in systemd's behavior[1] which results in the testbed exiting
> abnormally. I've temporarily[2] modified[3] our autopkgtest code in
> production so that this will not be considered a "testbed" failure which
> will prevent packages with autopkgtests that are OOM killed from running
> repeatedly.
> 
> I mention it because the log files for tests in this situation have
> changed and have become less informative. Looking the log file[4] for
> r-cran-rstanarm you'll see the following:
> 
> autopkgtest [18:46:11]: test run-unit-test: ---]
> autopkgtest [18:46:12]: test run-unit-test:  - - - - - - - - - - results
> - - - - - - - - - -
> run-unit-testFAIL non-zero exit status 255
> 
> Which is less helpful than the previous "Killed signal terminated"
> message. So when looking at proposed migration please keep this in mind.

Does the backend have any visibility into detecting when OOM killer was
triggered?

Bryce

> Additionally, since we are talking about tests running out of memory I
> wanted to mention that with the qemu backend it is possible to adjust
> the amount of memory your virtual machine has using the "--ram-size"
> argument. For example if I want to see if having more memory will allow
> a test to pass I'll use the following before adding it to big_packages:
> 
> autopkgtest --apt-upgrade r-cran-rstanarm --shell-fail -- qemu
> --ram-size=8192 --cpus=4 /srv/vms/autopkgtest-lunar-amd64.img
> 
> Finally, one benefit of this is that it became somewhat easier to find a
> bunch of packages that would pass if given more memory. I've
> investigated several of them and added them to 'big_packages'. If the
> developers on +1 maintenance next week could look at the following list
> it would be helpful!
> 
> amd64-igraph
> amd64-juce
> amd64-libgd2
> amd64-libthrust
> amd64-mariadb
> amd64-mariadb-10.6
> amd64-nvidia-cuda-samples
> amd64-openjdk-8
> 
> [1]
> https://github.com/systemd/systemd-stable/commit/0db0562852aafd89c84bf12cdf3de770898048d1
> [2] I've spoken with the Foundations team and they plan on uploading a
> new systemd.
> [3]
> https://git.launchpad.net/~ubuntu-release/autopkgtest/+git/development/commit/?id=842ca0f4bd78a6b0a7c1b484f7da242581651804
> [4]
> https://autopkgtest.ubuntu.com/results/autopkgtest-lunar/lunar/amd64/r/r-cran-rstanarm/20230203_185207_c0b1c@/log.gz
> 
> Have a great weekend!
> --
> 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

[Bryce Harrington]

Plus One Maintenance for Week of Jan 23-27, 2023

Here's notes for what I've worked on.  Interspersed are some items that
may need further attention; sorry they're not flagged but hopefully my
notes may be of some use.



### node* cluster ###

nodejs is transitioning from 18.7.0 to 18.13.0.

* Latest version of npm hadn't run tests against nodejs 18.13, so I've
  done a broad retrigger against that and node-undici.  Succeeded.
* node-help-me needed node-mqtt retriggered, then migrated successfully
* node-rechoir needed node-liftoff and node-webpack retriggered;
  both passed successfully, and node-rechoir migrated.

The following were just out of date on ABI, so I did no-change rebuilds:

* node-coveralls rebuilt as 3.1.1-2build1
* node-json5 rebuilt as 2.2.3+dfsg-1build1
* node-readable-stream rebuilt as 3.6.0+~cs3.0.0-4build1
* node-ts-jest rebuilt as 29.0.3+~cs0.2.6-1build1

Those four packages all built successfully, and their basic autopkgtests
succeeded with the old nodejs.  I retriggered them all against the
new nodejs, and they all passed successfully as expected.

node-solid-keychain and node-trust-webcrypto are unmaintained upstream
and in fact the latter is flagged by upstream as recommended not to use
due to potential security issues.  I filed a removal request for both
packages (LP: #2003831), and vorlon dropped them from the archive.

nodejs is now unblocked and is marked as "Will attempt migration."


### rubocop cluster ###

* ruby-rubocop-ast showed an implicit dependency between
  ruby-rubocop-ast rubocop.  I retriggered all the tests for rubocop
  with ruby-rubocop-ast added as a trigger.
  - This appears to have succeeded, and  ruby-rubocop-ast is now marked
as "Will attempt migration" \o/

With that fixed, it looks like rubocop itself is also marked as "Will
attempt migration".

A few other *rubocop* packages that were blocked by the above two also
look likely to migrate now.

This entire cluster successfully migrated Thursday.


### ipython cluster ###

* ipywidgets was blocked by migration issue in q2-feature-table.
  Retriggering that cleared it, and ipywidgets successfully migrated.
* python-pweave had an armhf migration error, but jbicha successfully
  retriggered it to pass for ipython.
* python-qtconsole 5.4.0-1 hadn't been triggered against the new
  ipython.  I've done the retrigger, with triggers for other depends in
  proposed.
* ipython itself I've retriggered against other python components in
  proposed.

This entire cluster successfully migrated Thursday.


### python3-defaults cluster ###

python3 has been undergoing transition from 3.10 to 3.11.  There's about
four dozen remaining migration issues, I pitched in on a few:

* python-django-tagging needed sync'd; succeeded.
* guake on arm64 needed retrigger with gobject-introspection; succeeded.
* q2cli needed retriggered with python3-defaults on arm64; succeeded.
* siconos on amd64 and arm64 needed retriggers; succeeded.
* python-configshell-fb needed retriggered with python3-defaults; succeeded.
* python-exchangelib needed retriggered with python3-defaults on all
  arches; succeeded.
* python-xmlrunner needed retriggered with python3-defaults on all
  arches; succeeded.
* fastapi needed retriggered with python3-defaults on all
  arches; succeeded.
* conda-package-streaming needed retriggered with python3-defaults on all
  arches; succeeded.
* dypi 1.5.0-7ubuntu1 was merged by graham inggs to fix tests, but
  needed retriggered with python3-defaults.
* breezy 3.3.2-1ubuntu1 was introduced by Paride to disable flaky test
  plugins.  This needed retriggered with python3-defaults on all arches,
  but also seems to still be flaky at least on amd64, so I also
  retriggered the test for that arch a couple more times.  Appears to
  have finally resolved.

* deepnano/s390x:
  - Debian has marked this package for removal.  It has been failing in
testing and they no longer include it in CI.  It's unmaintained
since 2017, and also depends on unmaintained package theano.  See
Debian bugs #1026539, #1027215.
  - I didn't file a removal request, but suspect we should...
* pytorch:
  - There's a new 1.13.1 release that probably updates it to python
3.11.  Debian hasn't merged that yet but there is some discussion to
do so.  See LP: #2002685
  - It looks like pytorch was removed from the archive instead (see LP:
#2003960).  There are a few other pytorch packages that may also
#need attention.
* ceph:
  - We're ahead of Debian with 17.2.0
  - There are newer releases upstream, 17.2.[1-5]
https://ceph.com/en/news/blog/2022/v17-2-1-quincy-released/
https://ceph.com/en/news/blog/2022/v17-2-2-quincy-released/
https://ceph.com/en/news/blog/2022/v17-2-3-quincy-released/
https://ceph.com/en/news/blog/2022/v17-2-4-quincy-released/
https://ceph.com/en/news/blog/2022/v17-2-5-quincy-released/
  - See LP: #1998958 "[SRU] ceph 17.2.5"
  - However, the real issue is python3.11 support is missing, 

Re: OpenLDAP 2.6 transition

[Bryce Harrington]

On Tue, Nov 22, 2022 at 01:37:40PM -0800, Steve Langasek wrote:
> On Tue, Nov 22, 2022 at 09:17:55AM -0800, Bryce Harrington wrote:
> > On Mon, Nov 21, 2022 at 03:41:23PM -0800, Steve Langasek wrote:
> > > Hi Sergio,
> 
> > > On Mon, Nov 21, 2022 at 06:32:39PM -0500, Sergio Durigan Junior wrote:
> > > > Hello,
> 
> > > > This is a heads up that the OpenLDAP 2.6 transition has started.  I have
> > > > just uploaded the package to lunar-proposed and will be performing
> > > > no-change uploads to its reverse dependencies soon.
> 
> > > > The list of packages that are going to be affected by this transition
> > > > can be obtained by running:
> 
> > > >   $ reverse-depends -r lunar src:openldap
> 
> > > > I did a mass-rebuild of said packages in a bileto PPA and everything
> > > > looks good (aside from some unrelated FTBFSes).
> 
> > > I would ask you to hold off right now on doing no-change rebuilds of any
> > > packages currently in -proposed.  There are in-progress language 
> > > transitions
> > > for perl, python, and R, and rebuilding all the openldap language bindings
> > > right now will entangle all of those transitions and likely make it harder
> > > to get them migrated.
> 
> > It would be great if these kinds of activities were mentioned on the
> > release schedule:
> 
> > https://discourse.ubuntu.com/t/lunar-lobster-release-schedule/27284
> 
> These are not scheduled transitions; this is the contents of the Debian sync
> when the archive opened.

Given that these unplanned transitions created a clog that is forcing an
indefinite delay to a planned transition, and indeed is causing
migration delays to other assorted package uploads more generally,
allowing these large language runtime transitions to occur at the same
time seems suboptimal.

If it's not specifically intended to have that happen, perhaps it would
be worth considering switching some of these languages to sync block at
the start of the cycle?  That would permit better coordination for when
they kick off.  This approach has proven workable and effective with
other language runtimes that had clog problems in the past.

Bryce

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

Re: OpenLDAP 2.6 transition

[Bryce Harrington]

On Mon, Nov 21, 2022 at 03:41:23PM -0800, Steve Langasek wrote:
> Hi Sergio,
> 
> On Mon, Nov 21, 2022 at 06:32:39PM -0500, Sergio Durigan Junior wrote:
> > Hello,
> 
> > This is a heads up that the OpenLDAP 2.6 transition has started.  I have
> > just uploaded the package to lunar-proposed and will be performing
> > no-change uploads to its reverse dependencies soon.
> 
> > The list of packages that are going to be affected by this transition
> > can be obtained by running:
> 
> >   $ reverse-depends -r lunar src:openldap
> 
> > I did a mass-rebuild of said packages in a bileto PPA and everything
> > looks good (aside from some unrelated FTBFSes).
> 
> I would ask you to hold off right now on doing no-change rebuilds of any
> packages currently in -proposed.  There are in-progress language transitions
> for perl, python, and R, and rebuilding all the openldap language bindings
> right now will entangle all of those transitions and likely make it harder
> to get them migrated.

It would be great if these kinds of activities were mentioned on the
release schedule:

https://discourse.ubuntu.com/t/lunar-lobster-release-schedule/27284

Bryce

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

Re: ppa-dev-tools 0.3 release

[Bryce Harrington]

On Sat, Oct 29, 2022 at 10:32:37AM -0700, Bryce Harrington wrote:
> ppa-dev-tools is a Launchpad API client that lets you create and manage
> Personal Package Archives (PPAs) from the command-line.  E.g.:
> 
>   $ ppa create my-ppa
>   $ dput *.changes my-ppa
>   $ ppa wait my-ppa
>   $ ppa destroy my-ppa
> 
> This 0.3.0 release also generates Autopkgtest trigger URLs you can use
> to run DEP8 tests against a PPA's packages, and then tracking the
> running status and test results.
> 
>   $ ppa tests my-ppa
> 
> I'll be giving a lightning talk on Tuesday to explain its functionality,
> and am in the Server Team's room for the week if you want to chat.
> 
> Website: https://launchpad.net/ppa-dev-tools
> 
> 
> 
> ### DEB Installation ###
> 
> A PPA with .deb packages are available for Ubuntu.
> 
>   $ sudo add-apt-repository -yus ppa:bryce/ppa-dev-tools
>   $ sudo apt-get install ppa-dev-tools
>   $ ppa --version
>   ppa 0.3.0
> 
> 
> ### PIP Installation ###
> 
> Alternatively, the package and its dependencies can be satisfied via PIP
> for a user installation:
> 
>   $ pip install .
>   $ ppa --version
>   ppa 0.3.0
> 
> 
> ### SNAP Installation ###
> 
>   $ sudo snap install ppa-dev-tools

Correction, this should be:

$ sudo snap install ppa-dev-tools --devmode --edge

Apologies for the confusion.  It'll move to strict confinement in a
future release.

Bryce

>   $ ppa --version
>   ppa 0.3.0
> 
> 
> ### SOURCE Installation ###
> 
> The git repository is on Launchpad.  See INSTALL.md for pre-requisites,
> and README.md for usage directions.
> 
>   $ git clone https://git.launchpad.net/ppa-dev-tools 
>   $ cd ppa-dev-tools
>   $ sudo python3 ./setup.py install
>   $ ppa --version
>   ppa 0.3.0
> 
> 
> Bryce

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

ppa-dev-tools 0.3 release

[Bryce Harrington]

ppa-dev-tools is a Launchpad API client that lets you create and manage
Personal Package Archives (PPAs) from the command-line.  E.g.:

  $ ppa create my-ppa
  $ dput *.changes my-ppa
  $ ppa wait my-ppa
  $ ppa destroy my-ppa

This 0.3.0 release also generates Autopkgtest trigger URLs you can use
to run DEP8 tests against a PPA's packages, and then tracking the
running status and test results.

  $ ppa tests my-ppa

I'll be giving a lightning talk on Tuesday to explain its functionality,
and am in the Server Team's room for the week if you want to chat.

Website: https://launchpad.net/ppa-dev-tools



### DEB Installation ###

A PPA with .deb packages are available for Ubuntu.

  $ sudo add-apt-repository -yus ppa:bryce/ppa-dev-tools
  $ sudo apt-get install ppa-dev-tools
  $ ppa --version
  ppa 0.3.0


### PIP Installation ###

Alternatively, the package and its dependencies can be satisfied via PIP
for a user installation:

  $ pip install .
  $ ppa --version
  ppa 0.3.0


### SNAP Installation ###

  $ sudo snap install ppa-dev-tools
  $ ppa --version
  ppa 0.3.0


### SOURCE Installation ###

The git repository is on Launchpad.  See INSTALL.md for pre-requisites,
and README.md for usage directions.

  $ git clone https://git.launchpad.net/ppa-dev-tools 
  $ cd ppa-dev-tools
  $ sudo python3 ./setup.py install
  $ ppa --version
  ppa 0.3.0


Bryce


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

[Bryce Harrington]

### Gnumeric ###

Version 1.12.53-1 added a --with-long-double option to configure, but
this FTBFS on ppc64el due to (I guess) some differences in how long
doubles are defined on that architecture, which breaks some macros that
use the GNM_const() macro.  I've filed update excuse bug #1991706.

It wasn't obvious to me how the macro itself should be fixed, but for
now I've just reverted the newly added --with-long-double option.  I
notice Debian has the same build failure so we can re-enable the option
when this gets further investigation.

At time of writing, gnumeric was still in the unapproved queue
(https://launchpad.net/ubuntu/kinetic/+queue?queue_state=1_text=gnumeric)
however I've verified in a PPA that it builds ok now
(https://launchpad.net/~bryce/+archive/ubuntu/gnumeric-fix-lp1991706)
so I believe gnumeric 1.12.53-1ubuntu1 should migrate successfully.


### node-resolve (and node-*) ###

There are a handful of node-* packages that seem interdependent with
each other.  I retriggered the lot of them, and at least that got
node-resolve to successfully migrate.  Seems to have partially cleared a
few others.

node-qs and node-yarnpkg test failures are blocking node-deep-equal, and
once that migrates it looks like a lot of other node-* packages should
migrate as well.  Their test logs show they're blocked on missing
modules but I think that may now be resolved.  I've retriggered these
three packages in combination together in case they're mutually
dependent (the test logs indicate dependency issues rather than actual
test code failure).


### Loggerhead ###

2.0.0-1 was supposed to include a fix for the autopkgtest issue we saw
regarding missing modules, however we still see the same issue in our
testing.  Debian released 2.0.0-2 which I gather fixed an issue
preventing the tests from running.  I've syncpackage'd this in for us,
however from Debian's CI it looks like it may still get hung up on
pygments; if that also happens for us, this may need to have
python3-pygments added as a Depends in d/t/control for the autopkgtest.

I filed update-excuse bug LP: #1991613 with the above info.


### scikit-learn ###

This package hits a 'bus error' on armhf.  This issue seems not to have
a bug report in Debian, however bus errors are mentioned on both Deb:
#1008369 and #1003165. Both bugs have extensive discussion, however it's
unclear if a fix is in sight; main suggestions appear to be to drop the
architecture or skip the test case.  Those may not be this same issue
though; it seems "Bus error" is a generic error that's been happening
for other tests on armhf.  Upstream is also aware of armhf tests being
in a really bad state.

A previous +1'r also suggested skipping the failing test, so I've gone
ahead and added test_dist_metrics to appropriate sections of both
d/rules and d/t/python3, and uploaded this as 1.1.2+dfsg-5ubuntu1.
Since the testsuite bails as soon as it hits the first bus error, it's
possible there will be subsequent tests failing the same way, in which
case maybe just keep adding excludes.

I've filed update-excuse bug LP: #1991621 with the above info.


### update-manager / gnome-flashback ###

Retriggered and it passed and migrated.
https://autopkgtest.ubuntu.com/packages/update-manager/kinetic/armhf


### lastz ###

FTBFS on riscv64.  A simple rebuild succeeded, and enabled the package
to migrate successfully.


### snowflake ###

FTBFS on riscv64.  A simple rebuild succeeded, and enabled the package
to migrate successfully.


### vectorscan ###

Filed update excuse LP: #1991622 with notes from previous +1'rs.
Debian sees the same issue and already has a bug report.


### gensio / ser2net ###

I filed update-excuse LP: #1991617 with the notes from previous +1'rs
but didn't have time to dig into it.

Bryce

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

Re: +1 Maintenance Report

[Bryce Harrington]

On Fri, Jul 01, 2022 at 11:54:12AM -0700, Steve Langasek wrote:
> On Fri, Jul 01, 2022 at 01:40:53PM -0500, William Wilson wrote:
> > Steve,
> 
> > Thank you for your work on this. I apologize for the lack of detail in my
> > earlier email. In order to get g-g-j-pgtype to build in my PPA with
> > g-g-j-pgx version 3.x, I had to change a line in d/control. I changed the
> > dependency "golang-github-jackc-pgx-v4-dev" to
> > "golang-github-jackc-pgx-dev" which is the name of the binary package from
> > version 3.x. It then built successfully in a PPA:
> > https://launchpad.net/~jawn-smith/+archive/ubuntu/devel-proposed/+packages
> 
> > So I may have misunderstood Bryce's instructions. I was under the
> > impression I could:
> 
> >1. Build the modified pgtype package with the dependency change (and
> >some version number like 1.10.0-0ubuntu1)
> >2. Build the pgx package now that the pgtype package is no longer in NEW
> >3. Re-sync the pgtype package from Debian and have it build with the now
> >available pgx-v4 package
> 
> > Is this not correct? If this is correct can you please delete the pgtype
> > package again so I can upload the modified version?
> 
> Yes, the above is all correct but was not apparent to me given that Bryce
> referred to version 1.10.0-3 and you appeared to be confirming that you got
> this version building.  I think it's fine for you to upload this to the
> archive as 1.10.0-3ubuntu1, and then we can copy-package 1.10.0-4 over it.

Sorry, yes that was a bit ambiguous.  By 'prepare' I was trying to imply
that's where some delta might be introduced, but the version number did
sound like I might be suggesting a sync.  In any case, glad to see it was
enough clue to get William on the path to a solution.  And thanks again
for the quick response, Vorlon.

Bryce

> There should be no blockers for you uploading 1.10.0-3ubuntu1 to the archive
> at your pleasure, as it's > the 1.10.0-3 that's currently in -proposed.
> 
> > On Fri, Jul 1, 2022 at 1:32 PM Steve Langasek 
> > wrote:
> > 
> > > On Fri, Jul 01, 2022 at 11:28:25AM -0700, Steve Langasek wrote:
> > > > > So, I think the bootstrap solution might be:
> > >
> > > > >   1. Verify that g-g-j-pgtype (1.10.0-3) actually does build
> > > > >  successfully against g-g-j-pgx-dev (3.6.2-2).  (This is probably
> > > > >  best to verify in a PPA.)  If so, then...
> > >
> > > > >   2. Request an Archive Admin to delete from -proposed:
> > > > >  - golang-github-jackc-pgtype (1.10.0-4) source & binary
> > > > >  - golang-github-jackc-pgx (4.15.0-4) source & binary
> > >
> > > > >   3. Prepare and upload g-g-j-pgtype (1.10.0-3), and verify it
> > > > >  builds ok.  Then proceed with syncpackage on both packages to 
> > > > > pull
> > > > >  in the newer versions.
> > >
> > > > Of course, when an in-archive bootstrap is possible, this is always
> > > nicer!
> > >
> > > > Since William has already confirmed that the above works, I'm not 
> > > > waiting
> > > > for him to ask on Monday and have done the above.
> > >
> > > However, it doesn't appear to have worked in the archive.
> > >
> > > https://launchpad.net/ubuntu/+source/golang-github-jackc-pgtype/1.10.0-3/+build/24130112
> > > shows the package is dep-wait on golang-github-jackc-pgx-v4-dev, from the
> > > newer golang-github-jackc-pgx that we're trying to bootstrap.
> > >
> > > So I'll hand this back over to y'all to debug and tell me what's missing 
> > > :)
> > >
> > > --
> > > 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
> 
> 
> -- 
> 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

> -BEGIN PGP SIGNATURE-
> 
> iQIzBAABCgAdFiEErEg/aN5yj0PyIC/KVo0w8yGyEz0FAmK/QswACgkQVo0w8yGy
> Ez1cqA//ZcLjLnsYRtIpmlU4mWc4hbMUMOxRn7HIuUfaSswwslMEmiyf1vWq9uzX
> JN3ehmwabNSTOdLp2bwuG/oav9x+14nwRZNBOEi7v34nVyVRw87OkX8cPlf6dsXe
> WIN/XpjeU9sMXvzqskANHNybUIJF/SGcEqUnUT/D6Fex/NP8Yp29tYftE2vXpZ6h
> 10ZtzHd3DhOwndL2iyV3H/B9yQ+e+aKPSHhcHA6YnSN8neCAzaAwKarpZLTR+8CD
> 3T8SAUHxbBfSYT2eBEiqhKbGFsYYC7ZEOWXfhyXkISXO/AoYdqL8ufYN1zMt/UfZ
> 7fr/GMFb24qNDde4ipv57DIq4j5PW4L6ImuwhRPwVcwQ2bT+PUgFHMZiFH622mB/
> v3RLAPII03S2fgEB+YIYV+8feHAkUxrOVLa+2P1U6eonqFQqu5vVeUqb7Lcd5VzV
> a0kk6Jkiie34lD1PqENtDdUtRV1DKXEtUq7XCrdUzJmMUrwT3BgSL9qHMmm7VDpa
> 

+1 Maintenance Report

[Bryce Harrington]

As William Wilson and Graham Inggs mentioned, there seems to be a higher
than usual amount of FTBFS compared with autopkgtest failures.  There
doesn't seem to be a common pattern going on, just a lot of package
ecosystems in flux.  Like them, I focused mostly on FTBFS issues, and a
little attention on the sponsoring queue.

(There are also a large number of NBS package issues currently, although
I didn't look at them.  Several transitions like icu, libphobos2,
libpoppler118, and libqgis appear to be in process.)


### riscv64 ftbfs ###

Bunch of packages were failing to build on riscv64, but succeeded on
retry:

  - rust-fd-find
  - mathcomp-zify
  - mathcomp-finmap
  - mathcomp-bigenough
  - mathcomp-algebra-tactics
  - rust-xcb
  - rust-idna
  - rust-tokio-util
  - libmseed
  - gsequencer

gsequencer took a suprisingly long amount of time to rebuild (nearly a
full day), and I suspect its prior failure could easily have just been
hw/nw flakiness during such a long run.


### xnee / dia (libpoppler transition) ###

xnee (riscv64) was ftbfs due to missing build dependency on dia-common.
Dia was ftbfs due to needing updated for the new poppler API.  I pulled
a patch from an upstream PR that fixed it:

https://gitlab.gnome.org/GNOME/dia/-/merge_requests/88

With dia successfully migrated, I rebuilt xnee for riscv64 and that also
succeeded and xnee appears like it should migrate over the weekend.


### pdf2djvu (libpoppler transition) ###

I sponsored Nathan Teodosio's fix for pdf2djvu to update pdf2djvu to the
new poppler API, similar to dia.
(LP: #1980518)


### debian-goodies (merge sponsorship) ###

Nathan Teodosio also had a merge proposed for debian-goodies, just
carrying a single bit of delta forward.  I sponsored the upload.
(LP: #1979538)


### anacron (merge sponsorship) ###

Another merge uploaded for nteodosio.  (LP: #1977739)


### mkosi ##

Succeeded on retrigger for ppc64el and migrated successfully.
I suspect it was just test flakiness on the hw.


### redis-py-cluster ###

Test failure resolved on retrigger, and migrated successfully.


### bibtool / texlive-base ###

texlive-base was blocked by test failure with bibtool.  It passed
on retrigger however texlive-base is still bocked by
auto-multiple-choice and latexml which I didn't investigate.


### node-zx and node-core-js ###

node-core-js is missing node-zx as build dependency.  node-zx FTBFS due
to a test case that is trying to access example.com.  I disabled the
test case and enabled node-zx to build and migrate; node-core-js also
succeeded in its build at that point.  I tried to flag the issue for
upstream (https://github.com/google/zx/issues/462), which they've closed
as fixed but I don't think they understood the issue.


### node-babel7 ###

This is failing its autopkgtest due to "RangeError: Invalid array
length".  I filed update excuse LP: #1980411 for it, and filed a
corresponding bug with upstream.  It affects Debian too but didn't spot
a patch or bug report there or upstream for it.


### libxcrypt, kopanocore and apache2 ###

Test failure for apache2 on s390x.  The error shown in the log is:

Forbidden
You don't have permission to access this resource.Reason: Cannot perform 
Post-Handshake Authentication.

However, in my experience the autopkgtests around apache2 seem
especially flaky and resolve on a retrigger or two, and indeed the
retrigger has passed.

kopanocore also has a test failure blocking libxcrypt, but on amd64.  It
also appears to be a service detection issue, and possibly also just
flaky so I retriggered it and it also passed.

libxcrypt also shows perl as blocking on autopkgtests on all arches.  
I didn't invesgitate this one; it doesn't look like a flaky test, but
rather something with missing perl packages in the archive.  I'm
guessing Perl is in a transition, and eventually the perl dependencies
will become available, at which point libxcrypt should complete its
migration.


### oscrypto and androguard ###

androguard's v3.4.0~a1-2 FTBFS is due to dependence on oscrypto, which
itself FTBFS due to an SSL 3 incompatibility.  This is fixed upstream,
and there's a cherrypickable patch, but I think it might be preferable
to wait for upstream's 1.3.0 release to be included in Debian and let it
sync in.

I filed LP: #1980298 as update-excuse for tracking, and pinged Debian
about the solution to the FTBFS, since it affects them too.


### pygments / pytest ###

pygments is stuck in Dependency Wait due to it requiring pytest 7,
however we're on pytest 6, and moving to 7 seems like a bold jump, since
pytest is used by a couple thousand packages.  I think pygments will
need to wait until pytest is ready to be transitioned.  I filed
update-excuse LP: #1980296 to track.


### mkdocstrings / pymdown-extensions ###

The -proposed versions for mkdocstrings-python-handlers and
mkdocstrings-python-legacy are FTBFS due to requiring newer
mkdocstrings, however that package is ftbfs due to now requiring

Re: +1 Maintenance Report

[Bryce Harrington]

On Fri, Jul 01, 2022 at 11:34:13AM -0500, William Wilson wrote:
> Greetings ubuntu-devel,
> 
> This week I was on +1 maintenance and I noticed an odd circular dependency
> between two packages.
> 
>- Package golang-github-jackc-pgtype is in NEW and is dependency wait on
>golang-github-jackc-pgx-v4-dev.
>- Package golang-github-jackc-pgx-v4-dev is a new binary package to be
>built from src:golang-github-jackc-pgx as it migrates from major version v3
>to v4.
>- src:golang-github-jackc-pgx can not build any v4 binaries without
>golang-github-jackc-pgtype-dev, which is built from
>src:golang-github-jackc-pgtype
> 
> 
> The TL;DR of this is that src:golang-github-jackc-pgtype cannot build
> without binaries from src:golang-github-jackc-pgx, which cannot build
> without binaries from src:golang-github-jackc-pgtype, and thus there is a
> circular dependency.
> 
> Are there any methods for dealing with this type of circular dependency? In
> Debian I can see they did a binary-only upload to fix this, but as far as I
> know there is no such thing in Ubuntu.

Right, that's not generally an available option for us.  The two
approaches I've had success with are a) bypassing test-during-build, and
b) bootstrapping from earlier versions.  Towards the end of this page is
a section on handling circular dependencies that explain these two:


https://github.com/canonical/ubuntu-maintainers-handbook/blob/main/ProposedMigration.md1

In this case, it doesn't look like the dependency is due to testing so
option (b) may be worth looking at.  It appears that g-g-j-pgtype
used to depend on g-g-j-pgx-dev, at version 1.10.0-3, which is currently
available in kinetic.

So, I think the bootstrap solution might be:

  1. Verify that g-g-j-pgtype (1.10.0-3) actually does build
 successfully against g-g-j-pgx-dev (3.6.2-2).  (This is probably
 best to verify in a PPA.)  If so, then...

  2. Request an Archive Admin to delete from -proposed:
 - golang-github-jackc-pgtype (1.10.0-4) source & binary
 - golang-github-jackc-pgx (4.15.0-4) source & binary

  3. Prepare and upload g-g-j-pgtype (1.10.0-3), and verify it
 builds ok.  Then proceed with syncpackage on both packages to pull
 in the newer versions.

If step #1 does *not* work, then the problem is more complex.  It might
be worth checking in with the Debian maintainer for ideas at that point.

Bryce

> I briefly thought about combining the packages, but that is not idea
> for a few reasons:
>
>1. It breaks our golang-github-- packaging convention.
>2. It would install possibly un-needed source code on people's machines
>if they install the combined package but really only needed one.
> 
> Now for the report of things I was able to solve: I usually focus mainly on
> failed tests, but I noticed there were quite a few FTBFS packages, so I
> decided to focus on those.
> 
> libdigidoc - openssl v3 related regression. This is fixed in Ubuntu and I
> have created a QA upload for Debian. This will be sponsored by ginggs.
> 
> rinutils - filed https://launchpad.net/bugs/1980243 and
> https://bugs.debian.org/1014169 to explain that it needs new dependencies
> packaged
> 
> golang-github-masterminds-sprig - I fixed a regression in this package
> which unblocked:
> * golang-step-crypto
> * golang-step-cli-utils
> * golang-github-smallstep-certificates
> Thanks to seb128 for helping shepherd some of these binary packages through
> the NEW queue
> 
> golang-oras-oras-go - Fixed a regression in Ubuntu and forwarded to Debian
> 
> golang-mongodb-mongo-driver - Fixed a regression in Ubuntu (and forwarded
> to Debian) which unblocks:
> * golang-github-go-openapi-strfmt
> * golang-github-go-openapi-validate
> * golang-github-go-openapi-runtime
> 
> golang-github-openshift-imagebuilder: Fixed regression in Ubuntu and
> forwarded to Debian
> 
> scamper - Fixed a regression in Ubuntu and forwarded to Debian
> 
> Thank you for reading,
> 
> William 'jawn-smith' Wilson

> -- 
> 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: pv (a pipeline progress indicator) in main?

[Bryce Harrington]

Thanks all, good feedback both on some items to check into and general
interest in seeing this go into main.  Also has been some good off-list
feedback on some logistics details.  I think the general sense is we'll
move forward with it, but first need to digest the input as a team and
plan out our next actions.

Bryce

On Fri, Apr 22, 2022 at 09:58:14AM -0700, Bryce Harrington wrote:
> The Ubuntu Server team is looking at several potential items to promote
> to main, including cli admin tools that might have broad usefulness.
> One of these we're on the fence about and would like broader input.
> 
> pv, 'Pipe Viewer' is a command line utility that essentially copies
> stdin to stdout, and displays an animated progress bar.
> 
> Standard example is compressing a large file, e.g.:
> 
>   $ pv Mail/spam.assassin  | gzip > /tmp/spam.gz
>   31.3MiB 0:00:01 [31.3MiB/s] [===> ] 31% 
> ETA 0:00:02
> 
> pv can also be used in the middle of pipelines (although since it
> doesn't know the stream's size it can't estimate % progress):
> 
>   $ mysqldump -uroot -p database1 | pv | gzip -9 > database1.sql.gz
>   53.7MiB 0:00:01 [29.7MiB/s] [ <=>   
>   ]
> 
> Overview: https://catonmat.net/unix-utilities-pipe-viewer
> Man page: https://linux.die.net/man/1/pv
> LP page:  https://launchpad.net/ubuntu/+source/pv
> 
> 
> Googling indicates that pv comes up very commonly as a general purpose
> solution to displaying progress, although there do appear to be
> main-provided solutions for at least some common situations.  For simply
> copying files, there is already rsync which has --progress and --status
> options.  For creating tarballs, tar has a --checkpoint option, though
> it's not fancy.  For copying streams, dd is in main, which has a
> status=progress option that animates the bytes copied (but not %'s or
> visual bars).
> 
> That said, pv looks like it would be a relatively light addition to
> main; it's written in C, appears to have an active upstream, and looks
> pretty self-contained.  A MIR for pv looks like it would be reasonably
> straightforward to file.  With it in main, other packages could rely on
> having it available for providing progress info, and would make it more
> at hand for scripting, tutorials/howto's, tech support, etc.
> 
> 
> Does this look useful enough to you that it should be made available by
> default?  Are there alternatives you feel would be better to look at?
> Or other considerations that need made before deciding?
> 
> Thanks,
> Bryce
> 
> 
> 

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

pv (a pipeline progress indicator) in main?

[Bryce Harrington]

The Ubuntu Server team is looking at several potential items to promote
to main, including cli admin tools that might have broad usefulness.
One of these we're on the fence about and would like broader input.

pv, 'Pipe Viewer' is a command line utility that essentially copies
stdin to stdout, and displays an animated progress bar.

Standard example is compressing a large file, e.g.:

  $ pv Mail/spam.assassin  | gzip > /tmp/spam.gz
  31.3MiB 0:00:01 [31.3MiB/s] [===> ] 31% 
ETA 0:00:02

pv can also be used in the middle of pipelines (although since it
doesn't know the stream's size it can't estimate % progress):

  $ mysqldump -uroot -p database1 | pv | gzip -9 > database1.sql.gz
  53.7MiB 0:00:01 [29.7MiB/s] [ <=> 
]

Overview: https://catonmat.net/unix-utilities-pipe-viewer
Man page: https://linux.die.net/man/1/pv
LP page:  https://launchpad.net/ubuntu/+source/pv


Googling indicates that pv comes up very commonly as a general purpose
solution to displaying progress, although there do appear to be
main-provided solutions for at least some common situations.  For simply
copying files, there is already rsync which has --progress and --status
options.  For creating tarballs, tar has a --checkpoint option, though
it's not fancy.  For copying streams, dd is in main, which has a
status=progress option that animates the bytes copied (but not %'s or
visual bars).

That said, pv looks like it would be a relatively light addition to
main; it's written in C, appears to have an active upstream, and looks
pretty self-contained.  A MIR for pv looks like it would be reasonably
straightforward to file.  With it in main, other packages could rely on
having it available for providing progress info, and would make it more
at hand for scripting, tutorials/howto's, tech support, etc.


Does this look useful enough to you that it should be made available by
default?  Are there alternatives you feel would be better to look at?
Or other considerations that need made before deciding?

Thanks,
Bryce





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

[Bryce Harrington]

## +1 Maintenance Docs ##

I've collected notes about proposed migration here:

   
https://github.com/canonical/ubuntu-maintainers-handbook/blob/main/ProposedMigration.md

This provides some explanations of phrases on the update-excuses page
that may be unclear to new +1 maintainers, and some tips for circular
dependencies and so on.  Suggestions to improve are welcome.


## Node ##

- NOT FINISHED (AA attention needed)

These fail only on i386, and should probably be hinted.

  * node-domino/2.1.6~ds-4
  * node-n3/1.13.0+~1.2.3+~1.10.4-1
  * node-node-forge/1.2.1~dfsg-2
  * node-normalize-range/0.1.2-3
  * node-regenerate-unicode-properties/10.0.1+ds-2
  * node-regjsgen/0.7.0+ds-1
  * node-require-relative/0.8.7+~0.8.0-1
  * node-urlgrey/1.0.0+~1.1.3-1
  * node-which-module/2.0.0-3
  * node-regenerate-unicode-properties/10.0.1+ds-2


## node-configurable-http-proxy / 4.5.0+~cs15.1.4-3

One of the errors this was encountering was fixed by Debian in the -4
package, so I sync'd it in.  The remaining errors appear to be proxy
issues which I'm not certain how to resolve but filed update-excuse bug
#1967024.


## node-eslint-visitor-keys / 3.3.0+~0.0.51-1

There was a -2 version in Debian.  I was not able to reproduce the error
locally, but felt the Debian update would resolve the issue.  I sync'd
it in, and it did indeed resolve the issue and allowed the package to
migrate.


## node-espree / 9.3.1~dfsg-1

This was blocked by node-eslint-visitor-keys, and with that resolved
(above), this also migrated successfully.


## node-regenerate-unicode-properties / 10.0.1+ds-2

The error showed the test dependencies were out of date with the
archive.  I retriggered using excuses-kicker, and all the tests
succeeded except for i386; I added this package to the above list for
getting a hint added.


## node-regexpu-core / 4.8.0-4

This is blocked by node-regenerate-unicode-properties, which now just
needs its j386 build failure hinted (above), and then should migrate.


## node-puppeteer / 13.1.0+dfsg-4

node-puppetteer has a versioned dependency on chromium and
chromium-sandbox, neither of which we carry in main or universe.
I filed LP: #1967048 to remove the binaries (thanks Christian!)

I've also forwarded to Debian a request (Deb: #1008812) to adjust the
dependencies.  Depending on their response, this package may need to
have a sync block added in the future at some point.


## node-nan / 2.15.0-1 on s390x

One test case fails due to what looks to me like an endian issue with
the test's usage of node's Buffer() class.  I reported the issue
upstream, filed an update-excuse bug on our end (LP: #1967589), and
disabled the test case for now.


## node-babel7 / 7.17.5+~cs214.260.190-1

- NOT SOLVED

There's several newer versions available from Debian.
Debian saw the same issue in their CI against the same version:
https://ci.debian.net/data/autopkgtest/unstable/amd64/n/node-babel7/19570001/log.gz

There seem to be only a few versions where things worked properly,
(e.g. see also Deb: #1007845) and those seem to not be cases that
included chalk so maybe the underlying issue remains unaddressed.


## bbswitch ##

Was an 'Only Unknown' failure, resolved by a basic retrigger.


## exim4 / ppc64el ##

I suspect this was just hitting a flaky test, but was blocking a dozen
other packages.  A 12-package retrigger on this arch passed, and
unblocked those packages.


## apache2 ##

A lot of tests get triggered from apache2 updates, and invariably there
are some flaky tests.  I did basic retriggers until all of these
succeeded and allowed apache2 to migrate.


## NBS ##

I uploaded no-change rebuilds of the 11 NBS packages to a PPA; 4 of
these build successfully, so I uploaded the no-change rebuilds to jammy:

 libosmocore - 1.6.0-3build1
 osmo-pcu - 0.8.0-3build3
 mbedtls - 2.28.0-1build1
 ncbi-vdb - 2.11.2+dfsg-4build2

libosmocore and mebdtls successfully transitioned.  The other two are
still in proposed but I ran out of +1 maint time before I could
investigate, so leaving for next person and hoping they're at least
nudged forward.

The PPA used for this (and the other 7 failures) can be viewed at:
  https://launchpad.net/~bryce/+archive/ubuntu/nbs-retry





Lastly, through the week I POC'd some code for parsing build logs,
gathering info into a more useful struct, and printing as JSON, YAML, or
text:


  ## Grab a build log
  $ curl  --output my_buildlog.txt.gz
  $ gunzip my_buildlog.txt.gz

  ## All data in text format
  $ parse-buildlog my_buildlog.txt
  ...
  ...

  ## Just the metadata info, in json
  $ parse-buildlog -r json -s metadata data/example-buildlog-00.txt
  {
  "metadata": {
  "Source Version": "0.10-3",
  "Distribution": "impish-proposed",
  "Build Architecture": "amd64",
  "Timestamp": "Thu, 27 May 2021 19:49:15 +",
  "Build Type": "binary",
  "Machine Architecture": "amd64",
  "Version": "0.10-3",
  "url": 

Re: +1 Maintenace Report

[Bryce Harrington]

On Fri, Dec 10, 2021 at 03:04:18PM -0800, Steve Langasek wrote:
> On Fri, Dec 10, 2021 at 02:06:27PM -0800, Bryce Harrington wrote:
> > There are also a bunch that fail on i386-only.  I don't know if i386 is
> > relevant for node-*; if not then perhaps these fails can be overridden?
> > Several are failing on 'code 14' (dunno what that is) or might be flaky
> > fails.
> 
> >   * node-caniuse-db
> >   * node-json-loader
> >   * node-unicode-match-property-value-ecmascript
> >   * node-unicode-property-aliases
> >   * node-unicode-property-value-aliases
> >   * node-unicode-property-value-aliases-ecmascript
> >   * node-unicode-canonical-property-names-ecmascript
> >   * node-unicode-property-aliases-ecmascript
> 
> The vast majority of node packages are Architecture: all, so there's no
> value in testing them on i386.  We don't even build i386 binaries of nodejs;
> we just unfortunately don't have a reliable way to skip testing of all of
> these packages.
> 
> node-ast-types in the release pocket passed because it's successfully but
> uselessly testing against the amd64 build of nodejs in the test environment. 
> But in -proposed, the package has more test dependencies which are not
> cross-installable.
> 
> I've gone through update_excuses and added hints to ignore all i386-only
> autopkgtest failures for node packages.

Hi Steve,

Here are some additional node packages which are failing only on i386.
These could use similar treatment as the above.  Thanks ahead of time.

  * node-domino/2.1.6~ds-4
  * node-n3/1.13.0+~1.2.3+~1.10.4-1
  * node-node-forge/1.2.1~dfsg-2
  * node-normalize-range/0.1.2-3
  * node-regenerate-unicode-properties/10.0.1+ds-2
  * node-regjsgen/0.7.0+ds-1
  * node-require-relative/0.8.7+~0.8.0-1
  * node-urlgrey/1.0.0+~1.1.3-1
  * node-which-module/2.0.0-3

Bryce

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

[Bryce Harrington]

On Thu, Mar 17, 2022 at 02:04:49PM +, Robie Basak wrote:
> On Wed, Mar 16, 2022 at 11:15:40AM +0800, Onno Benschop wrote:
> > One way to leverage these volunteers is to deputise them and have them
> > participate in the activities as a shadow member.
> > 
> > That way you have the opportunity to train these people and share the load
> > across more individuals.
> 
> I think this is a good idea and is related to a thought I'd had which
> gives me a good opportunity to share.
> 
> When, on occasion, we've had to say no to a candidate, I see that as a
> failure on the part of the DMB. Ideally, by the time someone has
> applied, they're already ready. If it turns out that they're not, then
> we've misled them into thinking they were ready, and that's on us to
> fix. What can we do to adjust the process to prevent that happening next
> time?
> 
> What if we were to change the process so that every applicant is given a
> nominated person to review their current status and make a
> recommendation prior to allocating themselves a regular application
> meeting? I had thought that maybe DMB members could volunteer for this
> role, but Onno's point above is a good one and really any qualified
> Ubuntu developer (who presumably already has the permission being
> applied for) could also volunteer.

The server team has some processes around collectively mentoring our
prospective packageset/MOTU/SRU candidates, including checklists of
skills to master, experiences to gain, and so forth.  The team members
can also provide motivation, moral support, and advice based on their
own experiences in the process.  I suspect other teams have similar
process-fu for helping their members' successes in applying.

Where attention might be most needed is with individuals that want to
engage in the DMB processes but whom aren't themselves members of any
such groups.  They probably face a mentoring deficit that might make
their applications harder for the DMB to process.

The DMB-provided mentor/buddy being suggested here would be helpful in
both cases but may be of particularly added value in this latter
situation.

Bryce

> It would still be the DMB making the final decision in the usual way.
> And the volunteer would only be making a recommendation; nothing would
> stop the applicant from proceeding with an application meeting anyway,
> and they could even decline having this type of mentor if they really
> want (perhaps they are already talking to someone less formally or
> simply don't like this approach).
> 
> But this way we might be able to get appropriate course correction much
> earlier, should that be necessary.
> 
> In a way, endorsements might exactly be such written recommendations;
> the problem tends to occur when an applicant struggles to get someone to
> look at their application as a whole; for example if they aren't well
> connected to other Ubuntu developers, or if each existing sponsor has
> only seen a subset of their work, and so is only providing a partial
> endorsement. So maybe an explicit, nominated person who will look at the
> big picture perspective would help.
> 
> Another issue might be volunteers who push their nominated applicants
> harder than what the DMB requires (bad for the applicant; might put them
> off) or not hard enough (which would then fail to address my problem
> statement). This might therefore need careful calibration and oversight
> to mitigate.
> 
> Thoughts?
> 
> 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

Re: +1 maintenance report

[Bryce Harrington]

On Fri, Feb 18, 2022 at 05:14:46PM +, Robie Basak wrote:
> I was on +1 maintenance this week.
> 
> It's been a long time (years) since I last did this. I'm not sure I had
> a good feel for what would be useful to work on, so rather than spending
> time changing my mind constantly I just focused on what I saw
> regardless.
> 
> There seem to be a lot of delays waiting on amd64 dep8 tests. Near the
> start of the week there were 6705 tests in the queue. At the end of the
> week there are 4643. But still the queueing time is generally over a
> week. It would be nice if I could see what entries in the queue were
> submitted manually by others. This doesn't seem to be presented at
> https://autopkgtest.ubuntu.com/running. Christian thought this
> information was available in the associated json output, but I haven't
> looked into this.
> 
> On the topic of delays, I feel like I've only just gotten into a lot of
> this. Because of the lag between taking some action and seeing the
> result, I ended up with many pending items at any given time, because
> most of the time all other items would be waiting on something before I
> could proceed further with them. So I'd look for something else. So, as
> I am writing up my week, I am finding many loose ends that I did not
> resolve because I had started them but then previously blocked items
> needed attention again.

That does seem to be a pretty good description of the +1 maintenance
experience.  :-)

I imagine every +1'er has their own strategy for dealing with that
chaotic workflow.  What I do is create a bulleted list of every package
I touch, noting the action I take, next steps depending on outcome,
theories on what's wrong, and the ultimate resolution (if any).

> In general I'd have liked to have seen more coordination with others on
> what is going on. Sometimes I might spend an hour tracking something
> down, coming to a conclusion about what action is necessary to take, and
> then finding that somebody had already figured this out, done it and the
> appropriate rebuild or dep8 retry was in progress or in a queue
> somewhere. This is frustrating. I'd prefer to spend my efforts on
> something nobody else is looking at. But there isn't any clear process
> to determine what that is.

A process I've seen others use, and that I've adopted myself, is to file
bugs tagged update-excuse, and use the bug report for tracking findings
and next-actions and such.  This seems to work well for the more
challenging transition items, but is overkill for smaller stuff where it
just needs a customized retriggering or a straightforward patch.

But unfortunately, for that smaller stuff we have poor transparency into
what's currently running.  Since britney can sometimes take a few hours
in its processing cycle even for simple things, that creates a big
window for people to submit redundant retriggers.

Sometimes I wonder if we directed some of the +1 effort towards tool
improvements if we could get a better workflow, or maybe even automate
away some of the tasks.


> I found a common use case was that I'd know the binary or source package
> names for extra things in proposed to retry failing dep8 tests against.
> But looking up all the versions, converting to source package names and
> URL-encoding manually was tedious. retry-autopkgtest-regressions in
> ubuntu-archive-tools didn't seem suitable for this, and nor could I find
> anything in ubuntu-helpers, so I knocked something up for this use case:
> https://git.launchpad.net/~ubuntu-server/+git/ubuntu-helpers/tree/rbasak/autopkgtest-urls
> I just give it the source or binary package names I want, and it looks
> up the details from a chdist and outputs the retry URLs.

Yeah I also made a tool for that (I'm sure others have as well).  Mine
is at:

https://launchpad.net/~bryce/+git/excuses-kicker

It uses a downloaded autopkgtest.db to identify other packages that the
given package has been triggered with before, looks up if those packages
have versions in -proposed, and then constructs URLs including triggers
for those packages.

  $ excuses-kicker -a amd64 php-doctrine-dbal
  
https://autopkgtest.ubuntu.com/request.cgi?release=jammy=amd64=php-doctrine-dbal=php-doctrine-dbal%2F3.3.2%2Bdfsg-1ubuntu1=php-doctrine-persistence%2F2.3.0-2ubuntu2=symfony%2F5.4.4%2Bdfsg-1ubuntu2=orafce%2F3.18.1-1=doctrine%2F2.11.1%2Bdfsg-1ubuntu1=php-nesbot-carbon%2F2.55.2-1=php-twig%2F3.3.8-2=php-doctrine-data-fixtures%2F1.5.2-1=gtk4%2F4.6.1%2Bds-1=php8.1%2F8.1.2-1build1=php-symfony-security-acl%2F3.3.0-1=postgresql-14%2F14.2-1=link-grammar%2F5.10.2~dfsg-2ubuntu1=php-psr-log%2F3.0.0-1=php-doctrine-cache%2F2.1.1-3ubuntu1

There's also options to add/remove triggers to customize things a bit.
It's still missing a few features and the docs are poor so I hesistate
to recommend it broadly but I've found this tool quite effective at
sorting out a lot of the run-of-the-mill migration problems I run into.

Bryce

-- 
ubuntu-devel mailing list

Re: Should we change the behaviour of -P for lsblk in util-linux for Jammy?

[Bryce Harrington]

On Thu, Feb 17, 2022 at 01:00:07PM +1300, Matthew Ruffell wrote:
> Hi all,
> 
> I'm looking for a bit of advice about landing a new feature in util-linux, as
> things have gotten a little complicated, and with feature freeze looming, a
> second opinion would be much appreciated.
> 
> e.g. lsblk -P now outputs LOG_SEC instead of LOG-SEC.
>
> So, what I need advice on is the next steps. Should we:
> 
> 1) Do nothing, accept 2.32.2 behaviour for -P in Jammy, which is a change from
> Focal/Impish, and will abruptly change again with the release of 2.38 likely 
> to
> land in KK. MAAS and Curtin are already fixed, no issues there, users must
> upgrade to latest stable MAAS and curtin on Jammy release. Older Curtin and 
> MAAS
> will break.
>
> 2) Backport the new 10+ commits into 2.27.2 in Jammy and hope we don't cause 
> any
> regressions with the significant amount of code being changed. We keep the 
> same
> behaviour that users expect from Focal/Impish, and users can now use
> -y / --shell if they want. Older MAAS and Curtin continue to work.
> 
> 3) Revert the single patch which caused all of this,
> 58b510e580 libsmartcols: sanitize variable names on export output
> which is a tidier and well tested solution, and drop the patch when util-linux
> is rebased to 2.38 in KK. This keeps existing behaviour in Focal/Impish, and
> enables older MAAS and Curtin to keep working.
> 
> I'm leaning toward suggesting 3) at this stage, but this is mostly to keep
> existing users happy on their older versions of MAAS.

I think your hunch for #3 does sound like the safer approach to me as
well.  Unless there's a huge number of users asking for the new feature,
those who do need it can either wait until it's generally available, or
use a workaround with some awk filters or whatnot.

Bryce

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

Re: nfs-utils update status

[Bryce Harrington]

On Thu, Feb 10, 2022 at 10:54:18AM -0300, Andreas Hasenack wrote:
> - it's my opinion that debian and ubuntu need the new version sooner
> rather than later. I'm actively working on bringing it into ubuntu,
> based on the exp package from debian. My branch is currently at [10],
> with a PPA at [11]. The delta we had was basically zeroed, due to a
> combination of upstream changes and debian changes.

> - we need a plan for an upgrade path. Some choices:
>   1 - do nothing but release notes

>   2 - detect if /etc/default/nfs-* have changes, and warn in that case,
> asking the user to move the changes over to /etc/nfs.conf

>   3 - to help with above, also ship fedora's script and let the user
> know it exists and could be used. Maybe even run it and place the
> output somewhere temporary for analysis

>   4 - actually run fedora's conversion script in postinst, and let the
> user know it was done and ask them to double check


As a user, I'd definitely like option 3 better than 1 or 2.

nfsconvert.py looks like it has ample error checking, so presumably if
you went with option 4, any failures will be detectable and the upgrade
could fallback to option 3.

If you do go with option 4, it may be wise to make sure nfs-util's
apport hook can capture that script's output on failure, and capture
both the old and new config files.

Bryce

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

Re: software-properties SRU stopped due to odd bug

[Bryce Harrington]

On Mon, Dec 13, 2021 at 03:50:10PM +1300, Robert Ancell wrote:
> Hi all,
> 
> I have a software-properties SRU [1] in bionic that has phasing stopped due
> to an error [2].
> 
> The stack trace is showing the following (new) code is failing:
> 
> di = distro_info.UbuntuDistroInfo()
> releases = di.get_all(result="object")
> 
> with the error:
> 
> AttributeError: 'UbuntuDistroInfo' object has no attribute 'get_all'
> 
> This is very confusing, since the code from this (from the distro-info
> library) is essentially:
> 
> class DistroInfo:
> def get_all(self, result="codename"):
> ...
> 
> class UbuntuDistroInfo(DistroInfo):
> def __init__(self):
> super().__init__("Ubuntu")
> 
> i.e. I can't see any reason why the `di` object would not have a get_all()
> method. Running software-properties and various test scripts on a bionic VM
> I haven't been able to reproduce any such issues.
> 
> Theories that have been proposed:
> - The user is actually running an older version of disto-info that was from
> before this method was added (in distro-info 0.15).
>   - Seems unlikely since there are error cases in which the install was
> done with a bionic image.
> - The user has a locally installed version of distro-info.
>   - Stacktraces shows the system installed version, the appropriate version
> of the binary installed, no PYTHONPATH set.
> - A .pyc is being used that doesn't match the source.
>   - Since installs have been from bionic media, it seems impossible that an
> older .pyc could be created.
> - Other code has removed this method.
>   - Method is being accessed immediately, no other code seen in source that
> could do this.
> - Memory corruption.
>  - Too many cases for error to be random, not seeing other similar issues.
> 
> Does anyone have any ideas about what might be going on?

Could it be an old pip-installed version of distro-info?
(C.f. LP: #1848829, #1874250)

Bryce

> --Robert
> 
> [1] https://launchpad.net/ubuntu/+source/software-properties/0.96.24.32.18
> [2]
> https://errors.ubuntu.com/problem/477791e8cc662f8dca46050bb638e273028a522f

> -- 
> 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: +1 Maintenace Report

[Bryce Harrington]

On Fri, Dec 10, 2021 at 03:04:18PM -0800, Steve Langasek wrote:
> On Fri, Dec 10, 2021 at 02:06:27PM -0800, Bryce Harrington wrote:
> >   * node-ast-types:
> > - Single failure on i386, probably flaky test
> > - I tried retriggering the i386 run, but probably needs reset
> >   * node-recast:
> > - Depends on node-ast-types (above)
> 
> > There are also a bunch that fail on i386-only.  I don't know if i386 is
> > relevant for node-*; if not then perhaps these fails can be overridden?
> > Several are failing on 'code 14' (dunno what that is) or might be flaky
> > fails.
> 
> >   * node-caniuse-db
> >   * node-json-loader
> >   * node-unicode-match-property-value-ecmascript
> >   * node-unicode-property-aliases
> >   * node-unicode-property-value-aliases
> >   * node-unicode-property-value-aliases-ecmascript
> >   * node-unicode-canonical-property-names-ecmascript
> >   * node-unicode-property-aliases-ecmascript
> 
> The vast majority of node packages are Architecture: all, so there's no
> value in testing them on i386.  We don't even build i386 binaries of nodejs;
> we just unfortunately don't have a reliable way to skip testing of all of
> these packages.
> 
> node-ast-types in the release pocket passed because it's successfully but
> uselessly testing against the amd64 build of nodejs in the test environment. 
> But in -proposed, the package has more test dependencies which are not
> cross-installable.
> 
> I've gone through update_excuses and added hints to ignore all i386-only
> autopkgtest failures for node packages.
> 
> > The last piece is "lintian-brush", which I started working on as well,
> > but it looks like it's grown additional test failures, and wonder if it
> > needs newer breezy changes, yet again.  This package sounds like it's
> > very specific to Debian package maintenance.  Do we use it in Ubuntu
> > package maintenance?
> 
> I've only ever heard of this package in the context of the breezy ecosystem
> being stuck in -proposed.  I don't think it's widely used in Debian either. 
> It's certainly something we could drop from the release if it's broken.

Yes, I do think dropping it would be beneficial.  It's not an end-user
tool so if we're not using it either, then there's not much value in
having it relative to the +1 maintenance time it seems to require.

Other rdepends of breezy sound like they do have some plausible use
cases, but in general the ecosystem seems to require a lot of attention
to keeping it untangled.  Dropping a few of the more problematic pieces,
like lintian-brush, may help alleviate this.
 
> > ### NBS ###
> > 
> > I worked a bit on a script to extract the list of faulty packages for
> > NBS and do no-change rebuilds in a PPA.  Using the results from that, I
> > attempted the following NBS fixes:
> > 
> >   * biboumi:
> > - d/control needed to specify libidn-dev instead of libidn11-dev
> 
> I was puzzled to see this on your list because I had been looking at it and
> didn't notice any problems wrt wrong build-deps.  It appears libidn11-dev
> despite its name depends on libidn-dev (i.e. it's a transitional package)
> and biboumi in -proposed is built against the correct version of libidn,
> it's just blocked by botan not being migratable - which is a ppc64el build
> failure.

It would be useful to have a way to track next actions like that on the
NBS page itself.  Can LP #'s be associated with it like the excuses page?

Bryce

> 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

> -BEGIN PGP SIGNATURE-
> 
> iQIzBAABCgAdFiEErEg/aN5yj0PyIC/KVo0w8yGyEz0FAmGz3OwACgkQVo0w8yGy
> Ez34WQ//Rue9lbeJAgaYgKewLFrTZIiSYjIZ+KUHOJnbCxLZNir86A+lcFXec8M/
> IArJimWY2WijV9iW4SEmq5tSyByRSGcFZ3MlKS0Y05TLP38KA+FQXE/aF/ZsSkdu
> 2mkqg8DmdRTso85XRw9jel8P8M7OFOWqL63/wXoEUdQ+QfWjX+yqOT21k164EEcV
> fyuvwp8Hn0MMgt+CRL8HaFF+YAfv/Fv2fZ5h/Lzu++RaJkanc2ppkfIGgCS/BcrV
> 6fBR8Jlu0qSyGS5tCzrMFtrjL8wihss/pirsLO53Jd3Vc05380PpnFxpi25eh+lB
> pMDmqXxjPtBQVhMUn10iXmDwepZOtqv1tIjhtejmwYM6EX/cDCVJEcBpDpb7PlHH
> V6eNBgoBoC/iiw+A41sdoy6m8Q1tOeYg1uhDbPw35Bp3u/FWR5HtX+CatyshhBwe
> OJH2r9CnANusbhl5DIBdrY/0SQAhawgTKoY5ACEyXRmU/HqoS/NBm0kC2GJLrXnA
> AUk3fDVg9IJz6mRPGdG59pV+T4MLDRoceEsbKMZW0xb2f4HEcgOWJuFZxovTowP+
> /nD5LXStnH0/uJ17tt+B9uk0bN7AwNwaMtE1v1zLjefesdmgP7VOODcQ5a1KvUdO
> p2DtQLvcfG66tMGsCDONGhClNqFRmX8Eu8tTbYeanIIyAoSW6Mw=
> =NOhd
> -END PGP SIGNATURE-


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

+1 Maintenace Report

[Bryce Harrington]

The areas I focused on for my +1 week were node-*, breezy & co, and NBS.

### Node ###

Hundreds of node-* packages were stuck in migration at the start of the
week.  The vast majority of these were blocked by a circular build
dependency situation between this set of packages:

  * node-tap
  * node-tap-parser
  * node-istanbul
  * node-js-yaml

The solution was to soften the Breaks for the latter package and then
rebuild and retrigger the set.  This cleared the circular dependency and
triggered dozens of node-* packages to successfully transition on their
own.  Many more transitioned with manual rebuilds and/or retriggers,
including npm.

Now that node-tap and node-tap-parser are transitioned, I've sync'd a
new node-js-yaml on top of my temporary fix.  This new version adds
another break against a new version of node-gulp-concat, which I've also
sync'd.

There's still a bunch of node packages that still need attention:

  * node-nodemailer:
- Encountering one test failure due to missing DKIM-Signature on a
  test email.
  * node-matrix-js-sdk:
- Missing build dependencies: node-matrix-org-olm
- There is no package 'node-matrix-org-olm' in debian or ubuntu.
- Nothing Depends on node-matrix-js-sdk afaict, so if it is blocking
  anything, perhaps its binaries could be removed for now?
  * node-trust-keyto:
- Error: Cannot find module '@trust/keyto'
  * node-domino:
- Tests here need reset since it flakily failed once
  * node-ast-types:
- Single failure on i386, probably flaky test
- I tried retriggering the i386 run, but probably needs reset
  * node-recast:
- Depends on node-ast-types (above)

There are also a bunch that fail on i386-only.  I don't know if i386 is
relevant for node-*; if not then perhaps these fails can be overridden?
Several are failing on 'code 14' (dunno what that is) or might be flaky
fails.

  * node-caniuse-db
  * node-json-loader
  * node-unicode-match-property-value-ecmascript
  * node-unicode-property-aliases
  * node-unicode-property-value-aliases
  * node-unicode-property-value-aliases-ecmascript
  * node-unicode-canonical-property-names-ecmascript
  * node-unicode-property-aliases-ecmascript


### Breezy ###

Between myself and several other +1'ers chipping away at this in the
past, breezy itself has been fixed and updated to the latest version,
and packages that required the latest version have updated and
transitioned.  This week I worked on some of the remnants:

* debmutate:
  - AttributeError: 'Deb822' object has no attribute 'order_last'.  This
API is in a newer version of debian-python than we carry.  I
reverted the change for now, it can be dropped once debian-python
gets its update.
  - Fixed some Test cases that break when the package has a 'ubuntu' version
string.  This may need better attention later, but works for now.

* breezy-loom:
  - Builds fine, but the autopkgtests fail miserably against the latest
version of breezy.
  - Filed LP: #1953549 to demote breezy-loom to -proposed until upstream
has an update that will work with breezy.  We can re-add it cheaply
then, so demoting it should help enable breezy to migrate.

The last piece is "lintian-brush", which I started working on as well,
but it looks like it's grown additional test failures, and wonder if it
needs newer breezy changes, yet again.  This package sounds like it's
very specific to Debian package maintenance.  Do we use it in Ubuntu
package maintenance?


### NBS ###

I worked a bit on a script to extract the list of faulty packages for
NBS and do no-change rebuilds in a PPA.  Using the results from that, I
attempted the following NBS fixes:

  * biboumi:
- d/control needed to specify libidn-dev instead of libidn11-dev
  * cataclysm-dda:
- No-change rebuild to remove dependence on ttf-unifont
  * collectd:
- No-change rebuild for libssl3
  * flint:
- No-change rebuild to update from libntl43 to libntl44


### Rebuilds / Retriggers ###

Most of these just needed simple rebuilds or retriggers.  Some needed
excuses-kicker to generate the right set of trigger commands:

  * twine
  * gnome-user-docs
  * ubuntu-docs
  * vdeplug-agno
  * rust-parking-lot
  * xapian-bindings
  * node-mdn-browser-compat-data


### Summary ###

2021-12-06 1970 update excuse records found
2021-12-07 1401
2021-12-08 1415
2021-12-09 1404
2021-12-10 1282

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

Re: PHP 8.1 transition plan

[Bryce Harrington]

On Thu, Oct 21, 2021 at 12:03:58PM -0700, Steve Langasek wrote:
> Thanks, Bryce.
> 
> On Thu, Oct 21, 2021 at 11:28:10AM -0700, Bryce Harrington wrote:
> > Hi devs,
> 
> > I've started on the php 8.1 transition, details are here:
> 
> >   https://wiki.ubuntu.com/ServerTeam/Transition/Php8.1
> >   
> > https://people.canonical.com/~ubuntu-archive/transitions/html/html/php8.1.html
> 
> > I anticipate this PHP update will be straightforward; the challenge will
> > be getting it completed prior to the OpenSSL 3.0 transition starting, as
> > the two certainly have potential for intertwining.  The OpenSSL
> > transition starts the week of Nov 4th, so that gives 2 weeks, which is a
> > bit tight for transitioning php but potentially doable if no major
> > troubles crop up.
> 
> The entanglement is expected to be minimal.  If the transitions overlap, php
> does not have to be rebuilt against openssl 3 right away, and not doing so
> will not block migration of openssl 3 to the release pocket (because
> migrating it will not remove, or cause uninstallability of, the libssl1.1
> binary packages); and if php8.1 does end up built against openssl 3 (e.g.
> because php8.1 has to be reuploaded to fix a bug), we will hopefully not see
> openssl 3 blocking it in -proposed for too long (the longest delay with
> openssl 3 is likely to be resolving autopkgtest regressions in the
> reverse-dependencies, which may involve tracking down and ignoring test
> failures from packages that aren't yet ported to openssl 3).

Ah, that assessment is good to hear.

One other note is that our current php8.0 does not support OpenSSL 3.0,
but php8.1 does.  However, there's a workaround patch for php8.0 if
needed.

> > The php8.1 language runtime itself has been uploaded to -proposed for
> > universe; it won't migrate to release until the full transition is
> > complete.  php8.0 will remain in the archive until that point.
> 
> I actually can't see any reason that it would block in -proposed for the
> transition as a whole, can you clarify?

Sorry, what I should have said is it won't move to *main* until the
transition is complete.

What's keeping it in -proposed presently is a build issue for armhf due
to a couple unsupported assembly calls (details in wiki).

> > I've updated php-defaults in -proposed to set 8.1 as the default.  This
> > allows no-change rebuilds of various php components to build against
> > that version.  This rebuilding of the PHP ecosystem is what consumes
> > most of the time for this transition, and of course help's always
> > welcome.
> 
> php-defaults of course will block for a while :)
> 
> 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

> -BEGIN PGP SIGNATURE-
> 
> iQIzBAABCgAdFiEErEg/aN5yj0PyIC/KVo0w8yGyEz0FAmFxuZgACgkQVo0w8yGy
> Ez24IhAAhPc3rL5g316gStN67DrbPnkfuhRvBpdcsZzIoVkVvWv7EWL6PtSGBTUa
> tVAaaR1QU23L8H7vSOCayhdWumRSZuZhiNXGj+wm1KDv9HC1VyrocW0VJoSC/Nm/
> d2FWa9PFgNCaqju5TMmA0O7hOYH/uL0WWG6s6TTVf//upRp5Le0t2zha0kny6nuw
> xwq52gV9eEbzLS8nWjHRsefK2vmuFh4kcKQvU3TjIci6UCRPBKOApl1Ir81lsm7u
> mpzRVSjFcJgrn4vE7g8ELbMIPLCgx1bUduGbzjLQPMnolw9rKw1RhxxFx9rCX6l+
> BC1hHy3oKaYvbRSOsZxR96B4FnC7VgHtC2MZCitRLLdcstlfwH1ftHJ/fZQbq2kp
> W2I9x4MshBCv56fRs6jf2yDkHNqdoYrROmHYl8D5/N6O+gTvH+wu4PxWjvMCf2q5
> XjcyjMLzPMCC0NDErZZ/5CfRw/WT3blPVlYOXQIUaKNBRG60P0DahvkI4TQfYEiS
> ZU1xt53uvQZZVycO0gazFx6Jj44PDdU1NznDrycfWJq4D+BIf7U5FnV3M91/WCc+
> d/KgtgzbulZHnp8oWUsq/CgHVN3bIC11/EvDxP0RFm4JF5HsQHVrsrt6hoT8w3ks
> xkdK3XUfQS/QniL+djPetZr2eYswvzTcxoi/v2XutsxG3HnhUUE=
> =qzOl
> -END PGP SIGNATURE-


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

PHP 8.1 transition plan

[Bryce Harrington]

Hi devs,

I've started on the php 8.1 transition, details are here:

  https://wiki.ubuntu.com/ServerTeam/Transition/Php8.1
  https://people.canonical.com/~ubuntu-archive/transitions/html/html/php8.1.html

I anticipate this PHP update will be straightforward; the challenge will
be getting it completed prior to the OpenSSL 3.0 transition starting, as
the two certainly have potential for intertwining.  The OpenSSL
transition starts the week of Nov 4th, so that gives 2 weeks, which is a
bit tight for transitioning php but potentially doable if no major
troubles crop up.

The php8.1 language runtime itself has been uploaded to -proposed for
universe; it won't migrate to release until the full transition is
complete.  php8.0 will remain in the archive until that point.

I've updated php-defaults in -proposed to set 8.1 as the default.  This
allows no-change rebuilds of various php components to build against
that version.  This rebuilding of the PHP ecosystem is what consumes
most of the time for this transition, and of course help's always
welcome.

Bryce

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

[Bryce Harrington]

For release week, with stuff mostly in freeze I opted to focus time on a
few of the older update-excuse issues to help move them forward.  This
was a rather short +1 week for me anyway due to holidays, meetings, and
other competing end-of-release priorities.  I'll be doing migration work
the next few weeks anyway for the php 8.1 transition, so can followup
then.



[LP: #1937256]  paperwork: autopkgtest armhf regression: Libinsane

Registered upstream project, and added link to the upstream bug that
Graham identified.  Upstream has reproduced and is actively working on
it.  Meanwhile, Debian has implemented a workaround in their 2.0.3-2
release.  

I did a syncpackage on it, but it was too late for inclusion in impish.
However, it got accepted to jammy-proposed, and I believe it should pass
on its own.  Once it does, this bug can be closed.



[LP: #1915312] dub:  autopkgtest regression and gcc-11 FTBFS

Verified the suggested patch builds locally.  Packaged it in a PPA.
Once freeze lifts, this can be retargeted to JJ and uploaded.



[LP: #1918287] node-pbkdf2:  autopkgtest fails in hirsute on s390x for 3.1.1-1

Registered upstream project, and added link to the upstream bug that
Balint filed.  No activity by upstream so far.

I retriggered the test on the off chance it works now, as the last test
run was against hirsute.



[LP: #1937173, #1932313] breezy:  FTBFS breezy 3.2.1-1

breezy has been failing its upstream testsuite for quite a while,
and it has been blocking several other packages from migrating, like
breezy-debian and lintian-brush.

A number of us +1'ers have been chipping away at this, narrowing the
problem to some changes in import behavior with python 3.9.5; I devoted
the remainder of my week chasing down solutions to the rest of the test
failures.  There's still one error I don't quite understand, that has to
do with overridden import logic, which I suspect is a weird enough
corner case that we can just skip until upstream has a chance to sort it
out properly.

I'm going to hold off on uploading the fixed breezy until the archive
opens up more fully, so I can test against jammy's python version.

Bryce

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

[Bryce Harrington]

On Mon, Oct 11, 2021 at 06:47:45AM -0700, Simon Chopin wrote:
> Hi Robie,
> 
> Quoting Robie Basak (2021-10-11 12:39:00)
> > I think it's worth noting what happened with nodejs in Bionic:
> >
> > https://bugs.launchpad.net/ubuntu/+source/nodejs/+bug/1779863
> > https://bugs.launchpad.net/ubuntu/+source/nodejs/+bug/1794589
> >
> > Summary: nodejs incorporated the version of openssl it gets built with
> > into its ABI, causing incompatibility between binary modules built in
> > different places if they mismatch, contrary to ecosystem expectations.
> > Upstream therefore considers[1] the openssl version that must be used
> > "locked" for a particular nodejs version. But if we use the version
> > upstream wants, and that differs from our "default" version, then the
> > resulting co-installability conflict between the two -dev packages
> > results in users complaining about that instead.
> >
> > It might be worth someone looking into this early in order to try to
> > avoid or mitigate a recurrence of this kind of issue.
> 
> (my apologies, this mail will likely contain quite a few links)
> 
> I looked a little bit into this, and as of 8 hours ago, the embedded copy
> of OpenSSL has been updated to version 3.0.0[0]. They have an open issue
> tracking the OpenSSL 3.0 support situation[1], and their technical
> committee has a document specifiying which OpenSSL release is supported
> for a given NodeJS version[2].
> 
> According to this comment[3] it seems they don't plan on supporting
> OpenSSL 3.0 in the 16.x branch, but rather in the 17.x which will have
> its first release next week according to their release schedule[4].
> Sadly, the new 17.x branch isn't planned as an LTS one.
> 
> Looking inwards, we currently ship a NodeJS version based on the 12.x
> branch, and Debian seems to be planning[5] a transition towards the 14.x
> branch. None of which support OpenSSL 3.0.
> 
> Unless I'm missing something, I see the following options, in no
> particular order:
> 
> (a) Remove NodeJS from the archive. Had to be mentioned, but I don't
>   think it's realistic ;-)
> 
> (b) Keep in sync with Debian, use the 14.x branch, but keep OpenSSL 1.1.1
> in the archive via a compat package.
> (b') The same but using the embedded copy of OpenSSL (if even possible?).
> 
> (c) Use NodeJS v17.x in JJ (when it's out), with OpenSSL 3.0. This would 
> entail
> doing the transition on our own, and it basically would be EOL two
> months after the JJ release.
> 
> (d) Track the NodeJS master branch in JJ and update NodeJS to the official
> version 18.0 a few days after our release of 22.04.
> 
> (e) Use 16.x + OpenSSL3 patches. I'm not entirely sure whether this
> would create the same issues as mentioned by Robie, as the support
> for a linked 3.0.0 is documented in [2].
> 
> I feel like (b) is our safest bet. If we go this route, we'll want to
> make sure that libssl-dev and libssl1.1-dev are coinstallable, as it was
> apparently a painpoint in the previous OpenSSL transition.
> 
> I welcome any other options or perspectives on the issue :)

Yeah none of those seem ideal, but I can't think of anything to add to
your list.

A couple additional factors come to mind, although maybe you've already
taken them into account.  First, nodejs tutorials commonly have the
reader use the platform nodejs to bootstrap to a newer nodejs for actual
development.  So, better to be consistent and stable than latest in
greatest.  Second, nodejs is in universe, so that affects its support
situation differently than if it were in main.  So, best not to expect
very heavy maintenance activity post-release.

v14 hits upstream EOL in 2023-04-30, which seems suboptimal for
supportability.  Initial release for v18 (final) isn't scheduled until
2022-03-19, so while that might be feasible for 22.04.1 it isn't an
option for the 22.04.0 image.  It looks like Fedora moved to nodejs v16
for their Fedora 35 release [0], and plan to adopt OpenSSL 3 for 36 [1],
although they have already run into at least one incompatibility [2].
Anyway, makes me a bit curious about feasibility of (e).

Bryce

[0]: 
https://fedoraproject.org/wiki/Releases/35/ChangeSet#Node.js_16.x_by_default
[1]: https://fedoraproject.org/wiki/Changes/OpenSSL3.0
[2]: https://www.spinics.net/lists/fedora-devel/msg291957.html


> Cheers,
> Simon
> 
> [0]: 
> https://github.com/nodejs/node/commit/66da32c045035cf2710a48773dc6f55f00e20c40
> [1]: https://github.com/nodejs/node/issues/29817
> [2]: https://github.com/nodejs/TSC/blob/main/OpenSSL-Strategy.md
> [3]: https://github.com/nodejs/node/issues/40106#issuecomment-937718359
> [4]: https://github.com/nodejs/Release#release-schedule
> [5]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989266#10
> 
> -- 
> 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 

Re: +1 Maintenance Report

[Bryce Harrington]

On Thu, Sep 23, 2021 at 09:10:31PM +0530, Utkarsh Gupta wrote:
> Hello,
> 
> On Thu, Sep 23, 2021 at 7:57 PM Graham Inggs  wrote:
> > python-meshio
> > =
> > python-meshio's autopkgtest on s390x has been failing since 4.3.11-1.
> > I found bryceh had looked at this previously in LP: #1939057.  I then
> > found utkarsh2102 had reported an issue upstream, so I left a link in
> > the LP bug.  I was able to bisect and find the commit which broke the
> > test and left a comment in the upstream issue.
> 
> Whilst working through this, do you happen to know "what" exactly
> happened? I took a look but unsure how things are now breaking in the
> s390x environment.

Looking at the commit Graham points to at the upstream bug, there
appears to be a change from using np.uint32() to .astype(" -- 
> 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

[Bryce Harrington]

Since it's just been a month since my last +1 rotation, I tried to focus
on following up on past stuff and getting more update-excuse bugs filed.


### emscripten ###

Tests for 2.0.12~dfsg-2ubuntu1 failed due to llvm compatibility issues.
Debian has incremented this package a few times in experimental, and I
found their first increment, 2.0.13-1, resolved the compatibility
issue.  I sync'd that version in and emscripten migrated successfully.


### libreoffice vs. openjdk-12 ###

Test was failing on armhf but passed on retrigger.  Both
libreoffice/1:7.1.5~rc2-0ubuntu1 and openjdk-12 are migrated in impish.


### wpewebkit ###

A simple rebuild succeeded, and the package migrated successfully.


### websockify ###

A simple rebuild succeeded, and the package migrated successfully.


### ovn / 21.06.0-0ubuntu1 build failure on armhf ###

A simple rebuild succeeded, and the package migrated successfully.

(I found a comment in upstream's bug tracker suggesting the testsuite is
known to be a bit flaky, but nothing tangible enough worth filing a bug
about...)


### node-rollup-plugin-node-polyfills and ts-node ###

Both of these packages seem to just have flaky tests, and migrated
successfully on retriggering.  I suspect adjustment to timeouts might
resolve the flakiness if it resurfaces, and opened bug LP: #1938948 on
that note.


### aodh / 1:12.0.0+git2021072116.10383f4d-0ubuntu2 ###

The upstream requires.txt had a depends on sqlalchemy 1.4 which is not
available yet.  I proposed a MP to remove the versioned depends, which
was accepted and landed (thanks Corey!)  aodh has migrated successfully
in impish.


### node-websocket-driver ###

The issue here is just that there's a warning emitted during testing
that trips autopkgtest's "any stderr is fail" rule.  I opened LP:
#1938949 with a modification of the test to filter the warning, but
before uploading would like to get a sanity check from someone else that
papering this over is a good enough workaround.  (Feel free to upload
this yourself if you agree.)


### crash / 7.3.0-1ubuntu1 test failure on ppc64el ###

Guessing this was just a race condition with the archive; it wanted a
version of linux-image that wasn't available when the test executed.
Whatever the cause, a simple rebuild succeeded and allowed crash to
migrate.


### breezy ###

Since several things are backed up on breezy (including silver-platter,
breezy-debian, etc.), I followed on from work by Dan and Christian and
spent some time studying the package internals.  I expanded on Dan's
partial-fix to address a couple more test cases.  Essentially, python
has recently changed where '.' in sys.path causes issues with module
loading; Dan's fix is to substitute CWD here, and that fixed a number of
problems; my addition was to update a few test cases that were expecting
'.' in error messages to instead accept '.*' so they'll match the CWD.

The remaining test failures appear to be caused by something in some
code that manually creates a module-space, 'breezy.testingplugins' and
then inserts synthetic modules into it.  Maybe whatever changed for
handling '.' affected artificial module loading functionality as well?

Dan suggested extracting a test case to send upstream might be useful.
breezy/plugin.py:_load_plugin_module() might be the place to start for
that.


### python-meshio / 4.4.6-1 test failure on s390x ###

Guessing a tolerance value used in a test is triggering some data type
oddity on s390x.  I filed update-excuse bug LP: #1939057 for tracking
this.


### mutter on armhf ###

Successfully migrated on a simple retrigger.

The stacking/override-redirect.metatest test seems to pass or fail about
50/50, so seems to have something non-deterministic going on.  vanvugt
notes it occurs upstream as well.  I filed LP: #1939058 for an
update-excuse next time it happens.  If it does, maybe the testcase
could be disabled until there's an upstream fix?


### mesa vs. mutter on ppc64el ###

After mutter itself migrated, it hit a test failure with mesa on
ppc64el.  Something to do with missing drivers for the Clutter backend.
I didn't have time to investigate, but retriggered it in case it's just
something else being flaky.


### thin / 1.8.0-1 test failure on armhf ###

The issue here has to do with the squid proxy on armhf.  I'm not sure
how to debug this one, but someone familiar with squid's configuration
on armhf probably could.  Opened update-excuse bug LP #1939086.


### gauche-gtk ###

Heather's analysis suggested this project may be abandoned and perhaps
should be dropped.  This seems sensible to me as well.  There are some
rdepends that would need dealt with as well, notably wiliki, scmail, and
skktools.  wiliki hasn't been updated since precise, and scmail since
natty.  skktools is just a suggests.  There's several other gauche-*
source and binary packages but I verified none have rdepends beyond this
set.

I think a good next action would be to file removal requests for wiliki,
scmail, 

Re: Proposal: sunset the backports pockets

[Bryce Harrington]

On Mon, Jul 19, 2021 at 11:25:48AM -0700, Erich Eickmeyer wrote:
> So, yes, I will block a so-called "improvement" when it comes down to 
> quitting 
> vs exhausting all other options, because, in my opinion, quitting is not an 
> option.

Totally get what you're saying Erich, and exactly right that users need
avenues for getting formally backported software on Ubuntu.  This is a
situation I've found myself in on both sides: as an upstream maintainer
wanting to get new releases out to LTS users, and as a distro developer
handling ubuntu-backports requests.  You're right that the bottleneck in
the process is a huge hinderance.  There are other fundamental
challenges to it, such as backporting applications that need updated
dependencies too (which is not at all uncommon).

And I get what you're saying about throwing babies out with bathwater
and the desire to "never give up".

But I'd point out the Big-Picture Goal here is getting properly vetted
software backports out to users.  For that, there are *many* options
(snaps, PPAs, SRU process refinements, docker, et al) that have come
about since the initial introduction of -backports.  There are pros/cons
to these, of course, but at a system level I'd argue that these other
options may be why demand for (and interest in maintaining)
ubuntu-backports dried up.  The other options solve problems -backports
can't, or are more convenient or more flexible.

So, I would suggest viewing this not as "quitting" but rather a
recognization that ubuntu-backports hasn't worked as a process, and that
letting it go will open space for other ideas to thrive.  We may be
better off to invest our limited time and attention by contributing to
the backporting processes that are already attracting volunteer
attention.

Bryce

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

[Bryce Harrington]

Due to last week's holidays and Portland on fire (...again), I
timeshifted my +1 work a couple days.  Here's what I got to:


### kopanocore ###

This was blocking openldap, which Sergio is working on getting
transitioned.  One of this package's extensions is in PHP, and needed
updated for PHP 8.  Upstream has a patch to add PHP 8 support, but we're
a few major releases behind so was not trivial to backport.  But with
that done now the package successfully builds and is ready to migrate
with openldap.


### virtuoso ###

This also blocked the openldap migration.  The problem was that upstream
had IEEE floating point fallback code for unrecognized architectures,
and it didn't recognize any of ours.  Removing the fallback solved the
issue and allowed this to migrate.


### openldap ###

Additionally, I did retriggers for some packages that are part of the
openldap migration, which should now migrate when openldap does.

Sergio indicated that mutter seems to be the last thing blocking
Openldap from migrating.  He pinged Marco Trevisan on the Desktop Team
to investigate.


### gudev-sharp-1.0 ###

We have two versions of gudev-sharp-* in the archive, and they both have
a binary of the same name so they conflict with each other.  Near as I
can tell both are dead and unused by anything.  I filed LP: #1933887 to
remove the -1 package, which should be enough to resolve the problem,
though TBH I think both source packages could go.


### movim ###

The binaries for movim and its depends were removed due to php 8
issues.  It is probably fine if the movim source package were removed as
well, though in theory when debian updates to php 8 I expect they'll
make the determination whether to update movim to php 8 or drop it
themselves.


### pcp ###

This was lacking a riscv64 binary for its dependency libbpfcc because
libbpfcc intentionally excludes that architecture.  I uploaded a change
to do similarly for pcp, and requested an AA to remove the risc pcp
binary but in checking with debian they opted to instead make
python3-bpfcc a B-D conditional.  pcp has now migrated successfully.


### libpgjava ###

This and libscram-java are wanting to bring in a new package dependency
libstringprep-java.  It was in Debian new, but they've recently accepted
it so now it's waiting in Ubuntu's new queue.  Thanks go to
LocutusOfBorg for explaining the situation.  For tracking purposes on
this I've filed LP: #1933555.


### Breezy-debian ###

This appears to be ftbfs due to needing the newer breezy to build.
breezy is getting investigated via LP: #1932313.  I poked a bit but
discovered nothing to add to the conversation.


### emscripten ###

This is FTBFS due to an LLVM version compatibility issue, which I think
may be resolved by syncing in a newer version from Debian experimental.
Unfortunately, in building this locally there are new errors during the
tests about not finding module 'wasm2c'.  The testsuite takes a long
time to run so I didn't get very deep on this, but I think this wasm2c
module might relate to the wabt package, which also has a new version
in experimental.  So maybe a next action might be to grab 
wabt 1.0.21-1, build it, and then build emscripten 2.0.12~dfsg-2ubuntu1
against that.  If that works, then sync wabt from experimental into
-proposed, wait for it to build and then do the same for emscripten.


### picolibc ###

"undefined reference to `__iob'" etc. during autopkgtest for 1.6.2-1.
I didn't have a chance to dig into this, but looks to be worth reporting
upstream.


### Retriggers / Rebuilds ###

In addition to the above, I did the usual bulk retriggers and rebuilds,
and got the following packages to migrate:

 √ bluez
 √ rbac-client-clojure
 √ ubiquity
 √ python-django
 √ libpfm4

Bryce

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

Re: PHP 8.0 transition plan

[Bryce Harrington]

PHP 8.0 has now transitioned in Impish, and php 7.4 is removed.

In addition to the language runtime itself, we also worked out the
issues in various PHP ecosystems built on it.  Numerous packages needed
patched or remerged to support version 8.0.

Most of the required changes ended up being pretty straightforward -
adjusting to new function declaration syntax styles, dropping use of
deprecated code, fixing test cases, etc.

If you find a package you're working on is failing due to something
php-related (such as an language binding extension), it's worth checking
if it has been updated for php8.0 and if not, first look for
bugs/branches upstream, as often the php 8 work has been done but just
not yet landed/released.

Thanks go to Utkarsh for tons of help with this migration and to Brian
Murray and Steve Langasek for admin assistance.

Bryce

On Wed, May 12, 2021 at 09:12:03AM -0700, Bryce Harrington wrote:
> Hi devs,
> 
> For impish the server team will be transitioning PHP to 8.0 over the
> coming weeks. (LP: #1927264) [0]
> 
> Since version 7.0, upstream PHP has adopted a regular release cadence[1],
> with one release per year. Each release is supported for 2 years, plus a
> third year of security critical fixes. PHP 8.0 was available last cycle
> but since changes from 7.4 to 8.0 were significant[2], we opted to postpone
> it to the 21.10 cycle and focused instead on resolving some phpunit
> 8.5->9.5 transition troubles. Landing PHP 8.0 this cycle will enable it
> to receive testing in a release prior to 22.04 LTS.
> 
> php8.0 has now been sync'd into impish from Debian experimental and set
> as the default PHP.  This breaks the PHP stack[3] and starts the actual
> transition.
> 
> Most or all of the PHP stack will need rebuilt at this point. This is
> phased due to package dependencies - for the php7.4 transition we
> started with php-propro, php-apcu, and php-msgpack; followed by
> php-apcu-bc, php-imagick, and php-igbinary; and then the rest of the
> stack. I anticipate php8.0's transition will proceed similarly.
> 
> Typically during PHP transitions, packages will fail to build or fail
> autopkgtests. Deprecated functionality[4] has been a common case and
> likely will be so for php8.0 as well[5]. There may also be
> phpunit-related issues in packages that didn't get re-built or re-tested
> since phpunit 9.5 transitioned.
> 
> Thanks,
> Bryce
> 
> 0: https://wiki.ubuntu.com/ServerTeam/Transition/Php8.0
> 1: https://www.php.net/supported-versions.php
> 2: https://stitcher.io/blog/new-in-php-8
> 3: 
> https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#php-defaults
> 4: https://wiki.php.net/rfc/deprecations_php_7_4
> 5: https://stitcher.io/blog/new-in-php-8
> 
> -- 
> 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

Movim / Laravel (PHP)

[Bryce Harrington]

We intend to drop Movim and Laravel from the archive to facilitate the
PHP 8.0 transition.  If this impacts you or others you're in contact
with please let me know.

As mentioned previously, Symfony has been the main blocker for the PHP
8.0 transition.  We've resolved the build and test issues; once
this is released a number of remaining PHP packages should transition.

Laravel is a web framework built atop Symfony.  Movim is an app built
atop Laravel.  I don't think many users depend on this from our archive;
most install guides direct users to install from php composer.

We might bring Laravel and Movim back after PHP has transitioned, but
I'd like to get a better sense of whether there's a demand for it.  So
if you use it or know someone that does, and would prefer to consume it
from the archive rather than via compose, please let me know.

Thanks,
Bryce

https://bugs.launchpad.net/ubuntu/+source/php-laravel-framework/+bug/1931315

On Mon, Jun 07, 2021 at 09:07:47AM -0700, Bryce Harrington wrote:
> Update on status on the PHP 8 transition:
> 
> In addition to the core PHP language components, there are several
> sub-transitions needed for the various ecosystems written in the
> language.  One of these, a web framework called Symfony, is our main
> blocker right now; it was stuck in a circular build dependency with
> Twig, but that was resolved last week, and now its a matter of sorting
> out test and api/abi inconsistencies with Doctrine and various other
> packages.  We're working actively on this.
> 
> Any package mentioning symfony in update_excuses or log files is likely
> tied up with the above, and there won't be much to do for them until
> symfony is sorted out.
> 
> There are also some other PHP packages with unrelated build or test
> issues.  These are mostly either due to using pre-PHP8 syntax that needs
> cleaned up (sometimes there are patches upstream), or dependency issues
> with another package that needs updated to PHP 8.
> 
> Bryce
> 
> On Fri, May 14, 2021 at 08:54:45PM -0700, Bryce Harrington wrote:
> > Hi mwhudson,
> > 
> > The other day you mentioned you'd be on +1 duty next week and expressed
> > interest in how the php transition is going.
> > 
> > Here's a wiki page with the current state of things:
> > 
> > https://wiki.ubuntu.com/ServerTeam/Transition/Php8.0
> > 
> > I've put in rebuilds for most of the stack by now, and a healthy chunk
> > has at least built and entered -proposed, and some has fully migrated.
> > A bunch of stuff is blocked by php-apcu and if that can migrate, a lot
> > more of the stack should migrate too.  The task here is getting symfony
> > and php-doctrine-cache to migrate, but they have some non-obvious test
> > failures that need investigation.
> > 
> > For items in that list that are FTBFS I've done some preliminary
> > investigation and noted possible solutions.  Some of these will be
> > pretty easy to fix.
> > 
> > The stuff under To Review probably just need nochange rebuilds but I
> > haven't had a chance yet to look through them.
> > 
> > I'll be out first half of Monday but will continue on this transition
> > through the rest of the week.
> > 
> > Bryce
> > 
> > On Wed, May 12, 2021 at 09:12:03AM -0700, Bryce Harrington wrote:
> > > Hi devs,
> > > 
> > > For impish the server team will be transitioning PHP to 8.0 over the
> > > coming weeks. (LP: #1927264) [0]
> > > 
> > > Since version 7.0, upstream PHP has adopted a regular release cadence[1],
> > > with one release per year. Each release is supported for 2 years, plus a
> > > third year of security critical fixes. PHP 8.0 was available last cycle
> > > but since changes from 7.4 to 8.0 were significant[2], we opted to 
> > > postpone
> > > it to the 21.10 cycle and focused instead on resolving some phpunit
> > > 8.5->9.5 transition troubles. Landing PHP 8.0 this cycle will enable it
> > > to receive testing in a release prior to 22.04 LTS.
> > > 
> > > php8.0 has now been sync'd into impish from Debian experimental and set
> > > as the default PHP.  This breaks the PHP stack[3] and starts the actual
> > > transition.
> > > 
> > > Most or all of the PHP stack will need rebuilt at this point. This is
> > > phased due to package dependencies - for the php7.4 transition we
> > > started with php-propro, php-apcu, and php-msgpack; followed by
> > > php-apcu-bc, php-imagick, and php-igbinary; and then the rest of the
> > > stack. I anticipate php8.0's transition will proceed similarly.
> > > 
> > > Typically during PHP transi

Re: PHP 8.0 transition plan

[Bryce Harrington]

Update on status on the PHP 8 transition:

In addition to the core PHP language components, there are several
sub-transitions needed for the various ecosystems written in the
language.  One of these, a web framework called Symfony, is our main
blocker right now; it was stuck in a circular build dependency with
Twig, but that was resolved last week, and now its a matter of sorting
out test and api/abi inconsistencies with Doctrine and various other
packages.  We're working actively on this.

Any package mentioning symfony in update_excuses or log files is likely
tied up with the above, and there won't be much to do for them until
symfony is sorted out.

There are also some other PHP packages with unrelated build or test
issues.  These are mostly either due to using pre-PHP8 syntax that needs
cleaned up (sometimes there are patches upstream), or dependency issues
with another package that needs updated to PHP 8.

Bryce

On Fri, May 14, 2021 at 08:54:45PM -0700, Bryce Harrington wrote:
> Hi mwhudson,
> 
> The other day you mentioned you'd be on +1 duty next week and expressed
> interest in how the php transition is going.
> 
> Here's a wiki page with the current state of things:
> 
> https://wiki.ubuntu.com/ServerTeam/Transition/Php8.0
> 
> I've put in rebuilds for most of the stack by now, and a healthy chunk
> has at least built and entered -proposed, and some has fully migrated.
> A bunch of stuff is blocked by php-apcu and if that can migrate, a lot
> more of the stack should migrate too.  The task here is getting symfony
> and php-doctrine-cache to migrate, but they have some non-obvious test
> failures that need investigation.
> 
> For items in that list that are FTBFS I've done some preliminary
> investigation and noted possible solutions.  Some of these will be
> pretty easy to fix.
> 
> The stuff under To Review probably just need nochange rebuilds but I
> haven't had a chance yet to look through them.
> 
> I'll be out first half of Monday but will continue on this transition
> through the rest of the week.
> 
> Bryce
> 
> On Wed, May 12, 2021 at 09:12:03AM -0700, Bryce Harrington wrote:
> > Hi devs,
> > 
> > For impish the server team will be transitioning PHP to 8.0 over the
> > coming weeks. (LP: #1927264) [0]
> > 
> > Since version 7.0, upstream PHP has adopted a regular release cadence[1],
> > with one release per year. Each release is supported for 2 years, plus a
> > third year of security critical fixes. PHP 8.0 was available last cycle
> > but since changes from 7.4 to 8.0 were significant[2], we opted to postpone
> > it to the 21.10 cycle and focused instead on resolving some phpunit
> > 8.5->9.5 transition troubles. Landing PHP 8.0 this cycle will enable it
> > to receive testing in a release prior to 22.04 LTS.
> > 
> > php8.0 has now been sync'd into impish from Debian experimental and set
> > as the default PHP.  This breaks the PHP stack[3] and starts the actual
> > transition.
> > 
> > Most or all of the PHP stack will need rebuilt at this point. This is
> > phased due to package dependencies - for the php7.4 transition we
> > started with php-propro, php-apcu, and php-msgpack; followed by
> > php-apcu-bc, php-imagick, and php-igbinary; and then the rest of the
> > stack. I anticipate php8.0's transition will proceed similarly.
> > 
> > Typically during PHP transitions, packages will fail to build or fail
> > autopkgtests. Deprecated functionality[4] has been a common case and
> > likely will be so for php8.0 as well[5]. There may also be
> > phpunit-related issues in packages that didn't get re-built or re-tested
> > since phpunit 9.5 transitioned.
> > 
> > Thanks,
> > Bryce
> > 
> > 0: https://wiki.ubuntu.com/ServerTeam/Transition/Php8.0
> > 1: https://www.php.net/supported-versions.php
> > 2: https://stitcher.io/blog/new-in-php-8
> > 3: 
> > https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#php-defaults
> > 4: https://wiki.php.net/rfc/deprecations_php_7_4
> > 5: https://stitcher.io/blog/new-in-php-8
> > 
> > -- 
> > 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: PHP 8.0 transition plan

[Bryce Harrington]

On Tue, May 18, 2021 at 12:15:41PM +0200, Sebastien Bacher wrote:
> Hey Bryce,
> 
> I noticed from the proposed-migrations team report that the libsoup2.4
> tests were failing and that it needed updated depends. I tried to
> rebuild it but it Build-Depends on php-xmlrpc which is still available
> but depends on php8.0-xmlrpc which isn't existing
>
> Checking salsa it seems the binary has been removed from php8.0, the
> commit doesn't include any explanation of why though so I'm unsure if
> that's a bug or wanted?
> https://salsa.debian.org/php-team/php/-/commit/97dee5b
> 
> Any recommendatiob on what should I do for libsoup there?

Yeah, looks like that stems from this earlier commit in that tree:

  
https://salsa.debian.org/php-team/php-defaults/-/commit/fa0bf419fc4ea521d712e4a9449abaaf910367d8

Debian appears to also register the missing dependency for php-xmlrpc
2:8.0+80~exp1 to non-existing php8.0-xmlrpc:

  https://packages.debian.org/experimental/php-xmlrpc

From upstream there is mention of this change:

  https://php.watch/versions/8.0/xmlrpc

At this point my guess is that upstream may want to consider migrating
to one of the suggested alternative libraries.  None of them appear
packaged for ubuntu, and I'm not spotting in debian an identified
transition path.

libsoup appears to be the only rdepends of this in our archive.  I
spotted this upstream commit that seems to suggest upstream already is
moving away from it for libsoup 3.x?

  
https://gitlab.gnome.org/GNOME/libsoup/-/commit/4217855114d1357eb16c5cf663b2fa09a6e6bd3c

Looks like libsoup3 is beta (i.e. 2.99.5 released a couple weeks ago) so
would it be worth looking at merging that from upstream?  If not,
perhaps you could consider backporting the above commit to remove the
xmlrpc support?

HTH,
Bryce

> Thanks,
> Sebastien
> 
> Le 15/05/2021 à 05:54, Bryce Harrington a écrit :
> > For items in that list that are FTBFS I've done some preliminary
> > investigation and noted possible solutions.  Some of these will be
> > pretty easy to fix.
> 
> -- 
> 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: PHP 8.0 transition plan

[Bryce Harrington]

On Mon, May 17, 2021 at 03:52:17PM +1200, Michael Hudson-Doyle wrote:
> On Sat, 15 May 2021 at 15:54, Bryce Harrington <
> bryce.harring...@canonical.com> wrote:
> 
> > Hi mwhudson,
> >
> > The other day you mentioned you'd be on +1 duty next week and expressed
> > interest in how the php transition is going.
> >
> > Here's a wiki page with the current state of things:
> >
> > https://wiki.ubuntu.com/ServerTeam/Transition/Php8.0
> >
> > I've put in rebuilds for most of the stack by now, and a healthy chunk
> > has at least built and entered -proposed, and some has fully migrated.
> > A bunch of stuff is blocked by php-apcu and if that can migrate, a lot
> > more of the stack should migrate too.  The task here is getting symfony
> > and php-doctrine-cache to migrate, but they have some non-obvious test
> > failures that need investigation.
> >
> 
> So what seems to be going on here is that php-apcu-bc is not going to be
> updated for PHP 8.0 (https://github.com/krakjoe/apcu-bc/issues/34) and so
> should be removed from the archive (the package currently in
> impish-proposed has a patch to only build for php 7 and so is almost empty).

There's also an unreleased 1.0.5-13:

https://salsa.debian.org/php-team/pecl/php-apcu-bc/-/blob/7fc1aad5b4ac1378fac4f705fb4f1ae7776a63eb/debian/changelog

I see one of the changes here hardcodes the package to php7.4, so it
definitely does appear this package is no longer relevant for impish.

> Its only reverse-build-depends are ... symfony and php-doctrine-cache (and
> it has no reverse-depends at all, only a reverse recommends from php-apcu
> which presumably should also be removed).

Thanks, I've applied and uploaded this change for php-apcu.
 
> Dropping the build-dependency from symfony leaves this failure:
> 
> Running src/Symfony/Component/HttpFoundation tests
> PHPUnit 9.5.2 by Sebastian Bergmann and contributors.
> 
> Runtime:   PHP 8.0.5
> Configuration: /<>/phpunit.xml.dist
> Warning:   Your XML configuration validates against a deprecated schema.
> Suggestion:Migrate your XML configuration using
> "--migrate-configuration"!
> 
> Testing /<>/src/Symfony/Component/HttpFoundation
> .   61 / 1233 (
>  4%)
> .  122 / 1233 (
>  9%)
> .  183 / 1233 (
> 14%)
> .  244 / 1233 (
> 19%)
> ..S..  305 / 1233 (
> 24%)
> .  366 / 1233 (
> 29%)
> .  427 / 1233 (
> 34%)
> .  488 / 1233 (
> 39%)
> .  549 / 1233 (
> 44%)
> .  610 / 1233 (
> 49%)
> .  671 / 1233 (
> 54%)
> .  732 / 1233 (
> 59%)
> .  793 / 1233 (
> 64%)
> .  854 / 1233 (
> 69%)
> .  915 / 1233 (
> 74%)
> ..
> Legacy deprecation notices (4)
> KO src/Symfony/Component/HttpFoundation
> PHP Fatal error:  Cannot use int as default value for parameter $with_cas
> of type bool in
> /usr/share/php/PHPUnit/Framework/MockObject/MockClass.php(51) : eval()'d
> code on line 141

Ah, yes there were a bunch of these int/bool issues during the phpunit
8.5 transition last cycle, this should be straightforward to fix.

> php-doctrine-cache still ftbfs without the build-dep, like this:
> 
> There were 2 failures:
> 
> 1)
> Doctrine\Tests\Common\Cache\MemcacheCacheTest::testSetContainsFetchDelete
> with data set "null" (null)
> Scalar and array data retrieved from the cache must be the same as the
> original, e.g. same type
> Failed asserting that false is identical to null.
> 
> /<>/tests/Doctrine/Tests/Common/Cache/CacheTest.php:35
> 
> 2) Doctrine\Tests\Common\Cache\MemcacheCacheTest::testUpdateExistingEntry
> with data set "null" (null)
> Scalar and array data retrieved from the cache must be the same as the
> original, e.g. same type
> Failed asserting that false is identical to null.
> 
> /<>/tests/D

Re: PHP 8.0 transition plan

[Bryce Harrington]

Hi mwhudson,

The other day you mentioned you'd be on +1 duty next week and expressed
interest in how the php transition is going.

Here's a wiki page with the current state of things:

https://wiki.ubuntu.com/ServerTeam/Transition/Php8.0

I've put in rebuilds for most of the stack by now, and a healthy chunk
has at least built and entered -proposed, and some has fully migrated.
A bunch of stuff is blocked by php-apcu and if that can migrate, a lot
more of the stack should migrate too.  The task here is getting symfony
and php-doctrine-cache to migrate, but they have some non-obvious test
failures that need investigation.

For items in that list that are FTBFS I've done some preliminary
investigation and noted possible solutions.  Some of these will be
pretty easy to fix.

The stuff under To Review probably just need nochange rebuilds but I
haven't had a chance yet to look through them.

I'll be out first half of Monday but will continue on this transition
through the rest of the week.

Bryce

On Wed, May 12, 2021 at 09:12:03AM -0700, Bryce Harrington wrote:
> Hi devs,
> 
> For impish the server team will be transitioning PHP to 8.0 over the
> coming weeks. (LP: #1927264) [0]
> 
> Since version 7.0, upstream PHP has adopted a regular release cadence[1],
> with one release per year. Each release is supported for 2 years, plus a
> third year of security critical fixes. PHP 8.0 was available last cycle
> but since changes from 7.4 to 8.0 were significant[2], we opted to postpone
> it to the 21.10 cycle and focused instead on resolving some phpunit
> 8.5->9.5 transition troubles. Landing PHP 8.0 this cycle will enable it
> to receive testing in a release prior to 22.04 LTS.
> 
> php8.0 has now been sync'd into impish from Debian experimental and set
> as the default PHP.  This breaks the PHP stack[3] and starts the actual
> transition.
> 
> Most or all of the PHP stack will need rebuilt at this point. This is
> phased due to package dependencies - for the php7.4 transition we
> started with php-propro, php-apcu, and php-msgpack; followed by
> php-apcu-bc, php-imagick, and php-igbinary; and then the rest of the
> stack. I anticipate php8.0's transition will proceed similarly.
> 
> Typically during PHP transitions, packages will fail to build or fail
> autopkgtests. Deprecated functionality[4] has been a common case and
> likely will be so for php8.0 as well[5]. There may also be
> phpunit-related issues in packages that didn't get re-built or re-tested
> since phpunit 9.5 transitioned.
> 
> Thanks,
> Bryce
> 
> 0: https://wiki.ubuntu.com/ServerTeam/Transition/Php8.0
> 1: https://www.php.net/supported-versions.php
> 2: https://stitcher.io/blog/new-in-php-8
> 3: 
> https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#php-defaults
> 4: https://wiki.php.net/rfc/deprecations_php_7_4
> 5: https://stitcher.io/blog/new-in-php-8
> 
> -- 
> 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

PHP 8.0 transition plan

[Bryce Harrington]

Hi devs,

For impish the server team will be transitioning PHP to 8.0 over the
coming weeks. (LP: #1927264) [0]

Since version 7.0, upstream PHP has adopted a regular release cadence[1],
with one release per year. Each release is supported for 2 years, plus a
third year of security critical fixes. PHP 8.0 was available last cycle
but since changes from 7.4 to 8.0 were significant[2], we opted to postpone
it to the 21.10 cycle and focused instead on resolving some phpunit
8.5->9.5 transition troubles. Landing PHP 8.0 this cycle will enable it
to receive testing in a release prior to 22.04 LTS.

php8.0 has now been sync'd into impish from Debian experimental and set
as the default PHP.  This breaks the PHP stack[3] and starts the actual
transition.

Most or all of the PHP stack will need rebuilt at this point. This is
phased due to package dependencies - for the php7.4 transition we
started with php-propro, php-apcu, and php-msgpack; followed by
php-apcu-bc, php-imagick, and php-igbinary; and then the rest of the
stack. I anticipate php8.0's transition will proceed similarly.

Typically during PHP transitions, packages will fail to build or fail
autopkgtests. Deprecated functionality[4] has been a common case and
likely will be so for php8.0 as well[5]. There may also be
phpunit-related issues in packages that didn't get re-built or re-tested
since phpunit 9.5 transitioned.

Thanks,
Bryce

0: https://wiki.ubuntu.com/ServerTeam/Transition/Php8.0
1: https://www.php.net/supported-versions.php
2: https://stitcher.io/blog/new-in-php-8
3: 
https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#php-defaults
4: https://wiki.php.net/rfc/deprecations_php_7_4
5: https://stitcher.io/blog/new-in-php-8

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

[Bryce Harrington]

Here's my report for the week of April 5-9.


### mash (and kleborate) ###

Debian had dropped the armhf support from the package, but we were still
building and testing the armhf binary package.  This was removed
(LP: #1922802) and mash 2.2.2+dfsg-2build1 was able to migrate.

It looks like this also permitted kleborate 2.0.1-1 to migrate as well.


### securefs ###

securefs / 0.11.1+ds-3 test failure on amd64

A test case was writing to a "tmp" dir before it had been created (by
one of the other test cases).  (The ordering of test cases might be
platform-specific or perhaps arbitrary?)  I patched the test to create
tmp if it doesn't already exist.  With the fix, migrated as
0.11.1+ds-3ubuntu1.


### rainloop ###

rainloop / 1.14.0-3 build failure on amd64

The problem was due to node-pikaday installing pikaday.css in /usr/share
now, instead of /usr/lib.  rainloop also needed a build-depend on
node-jquery.  I've uploaded 1.14.0-3ubuntu1 but it's not processed yet.



### Regular +1 Maintenance ###

These test failures were blocking the glibc update, but passed after a
simple retriggering:

  * pyfuse3
  * pymca
  * python-biopython
  * r-bioc-destiny
  * ruby-hitimes
  * tcpslice

These migrated after retriggering with a few other packages from
proposed:

  * privoxy / 3.0.32-1ubuntu1 on armhf
  * pytorch / 1.7.1-7 on armhf
  * golang-github-coreos-pkg / 4-3 on armhf
  * golang-github-hashicorp-memberlist / 0.1.7-1ubuntu1 on arm64
  * golang-github-valyala-gozstd / 1.9.0+ds-7 on ppc64el
  * cl-trivial-garbage / 20200801.git2319892-1 on amd64

These were failing testing due to timeouts, but passed and completed
migration when retriggered:

  * pytorch / 1.7.1-7
  * nanoc / 4.11.14-4ubuntu1

These build failures resolved with a simple rebuild:

  * irpas / 0.10-8ubuntu1
  * pexpect / 4.8.0-1 build failure on amd64



### Notes on Remaining Items ###

The rest of these I stared at a bit but didn't have time to fully
investigate, so leave these notes for the next shift.

  * img2pdf / 0.4.0-1 build failure on amd64:
- 52 test cases failed, mostly due to one problem fixed by 
  https://paste.ubuntu.com/p/rt6b7pgTRk/.
- I didn't figure out the last 4 test case failures, but there may
  be more clues to glean from:
  https://gitlab.mister-muffin.de/josch/img2pdf/issues/85

  * sshuttle / 1.0.5-1ubuntu1 test failure on amd64,ppc64el,s390x
- Looks like tests are taking too long to run, so maybe it needs
  big_packages or long_test set in autopkgtest-cloud?

  * cct (with ncbi-blast+ and kleborate)
- I thought getting mash and kleborate to migrate would enable this
  one to go, however this also is hitting a test timeout so perhaps
  could also need hinted as long_test?

  * dogtag-pki test failure on s390x
- Timo and Lukas had debugged this previously, and raised the issue
  with upstream, who introduced a fix in the package 389-ds-base
  1.4.4.11-1, but even with that version, no dice.  But it still
  appears to be something pkispawn-related.
- https://github.com/389ds/389-ds-base/issues/4563
- 
https://github.com/389ds/389-ds-base/commit/2ccd0bed4e60e44303d5f1cf96bd30572ffea85b

  * phpmyadmin / 4:5.0.4+dfsg2-2 test failure on s390x:
- Two test cases in the ImportShpTest.php plugin fail.
- I didn't get a chance to work on this, but have dealt with several
  PHP + s390x test errors in the past.  They've typically been
  endianness issues of some sort, which we've worked around by
  disabling the test case.  However, for phpmyadmin it may be worth
  reproducing on s390x and digging in more.

  * diaspora-installer / 0.7.14.0+debian2 test failure on ppc64el:
- This ruby package seems not to be able to find mimemagic (0.3.5),
  maybe it needs to build-depend on ruby-mimemagic?  Not sure
  though - I don't reproduce the failure on amd64 with ruby-mimemagic
  uninstalled, so might be something more ppc64el-specific.


-
Monday:233 update excuse records found
Tuesday:   220 update excuse records found
Wednesday: 184 update excuse records found
Thursday:  249 update excuse records found
Friday:188 update excuse records found
-

Bryce

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

Re: +1 maint - phpunit 9 bootstrap proposal

[Bryce Harrington]

With the php-http-request2 fix, phpunit successfully transitioned.
A bunch of php stuff went through after that.

Bryce

On Fri, Feb 12, 2021 at 06:13:46PM -0800, Bryce Harrington wrote:
> On Wed, Feb 03, 2021 at 11:19:13AM -0800, Bryce Harrington wrote:
> > On Wed, Jan 27, 2021 at 05:50:14PM -0800, Bryce Harrington wrote:
> > > On Wed, Jan 27, 2021 at 01:40:48PM -0800, Bryce Harrington wrote:
> > > > Brief update:
> > > > 
> > > > I've gotten most everything passing now, except composer and
> > > > php-http-request2.
> > > > 
> > > > My best guess is that these two packages' test case failures are due to
> > > > changed behavior in array behavior, however I've not had any luck so far
> > > > diagnosing what's causing the failure.  I can reproduce the failures for
> > > > php-http-request2 locally, but composer passes without issue when run
> > > > locally.  None of the issues appear to be reported anywhere else, and
> > > > both packages are passing Debian's CI without issue.
> > > > 
> > > > I'm not sure how much more time I want to invest in debugging these, and
> > > > might consider suggesting to just disable the wayward tests just to get
> > > > phpunit across the finish line.  Advice and/or help would be welcome.
> > > 
> > > For composer, I've filed:
> > > https://github.com/composer/composer/issues/9654
> > 
> > I've uploaded the fix for composer and it's now passing its tests.
> > 
> > Now just php-http-request2 remains for unblocking phpunit.
> > 
> 
> I got php-http-request2 sorted today.  It had 25 test cases using old
> phpunit syntax that needed updated in order to work with phpunit 9.5.
> 
> I think phpunit and the various php bits dependent on it should finally
> migrate now.  I'll check in on it next week.
> 
> Bryce
> 
> > > > Bryce
> > > > 
> > > > On Tue, Jan 19, 2021 at 03:55:54PM -0800, Bryce Harrington wrote:
> > > > > On Tue, Jan 12, 2021 at 05:08:26PM -0800, Bryce Harrington wrote:
> > > > > > On Tue, Jan 12, 2021 at 04:24:39PM -0800, Steve Langasek wrote:
> > > > > > > On Mon, Jan 11, 2021 at 08:48:15PM -0800, Bryce Harrington wrote:
> > > > > > > > phpunit has been stuck in a 8.5 -> 9.5 transition, which blocks 
> > > > > > > > other
> > > > > > > > things.  I'd like to propose we back out 9.5 and bootstrap to 
> > > > > > > > 9.0, and
> > > > > > > > *then* to 9.5.
> > > > > 
> > > > > Hi Steve,
> > > > > 
> > > > > I worked a bit Friday retriggering the remaining packages, which
> > > > > got these to pass:
> > > > > 
> > > > >   php-guzzlehttp-psr7, phpdox, php-amqplib, 
> > > > > php-laravel-lumen-framework,
> > > > >   phpcpd
> > > > > 
> > > > > Over the weekend it looks like there was a re-trigger of the whole php
> > > > > stack (or at least the phpunit-using portion of it), for phpunit 
> > > > > 9.5.1-1
> > > > > I guess.  This added a few more packages with issues, but they just
> > > > > needed retriggers.
> > > > > 
> > > > > Today I reviewed the remainder, and note below what looks like needs
> > > > > done to resolve them.
> > > > > 
> > > > > composer (2.0.8-2):
> > > > >   - Errors:
> > > > > + Failed asserting that 'Undefined index: file' matches PCRE 
> > > > > pattern
> > > > >   "/(File format not recognized|Unrecognized archive format)/i".
> > > > > + Failed asserting that 'Undefined index: file' contains "is not 
> > > > > a zip
> > > > >   archive".
> > > > > + Undefined index: file
> > > > >   - "Undefined index" suggests the test is trying to read an array
> > > > > element that doesn't exist.  All three tests appear to be 
> > > > > expecting
> > > > > an error message that isn't present in an array.
> > > > >   - Not finding any indication of these errors reported upstream or in
> > > > > Debian.
> > > > >   - autopkgtest passes locally for me.
> > > > >   - I'm not sure what is wrong here...
> > > > > 
> > > > > √ php-arthurhoa

Re: +1 maintenance report

[Bryce Harrington]

On Mon, Feb 15, 2021 at 05:36:15PM +0100, Jan Ceuleers wrote:
> On 13/02/2021 04:49, Seth Arnold wrote:
> > Could we build a retriggerbot that smashes the retry button three times
> > before bothering any humans about failed tests?

Actually, we can be a lot more precise than that; see below.

> > Hitting retry is often the first troubleshooting step people take; I've
> > heard tests may be retried something like ten times by different people,
> > each of whom was taking a reasonable enough "first debugging step"
> > without noticing that other people have also done the same.
> 
> Not an Ubuntu developer but I do work as a quality manager. Not sure
> whether my list post will be accepted, so I'm copying you.
> 
> The assumption underlying your suggestion is that tests that
> intermittently fail do so because of intermittent failures in the test
> environment rather than due to actual bugs that manifest themselves only
> intermittently (such as race conditions).
> 
> This is fine if you have evidence that the assumption holds in a
> sufficiently large majority of cases.


It's certainly true that "randomly retry tests" has proven to be an
effective way to get things unblocked.  No denying that.

In this particular situation, though, what I did was scanned build logs
for certain phrases such as 'Unable to connect to ftpmaster', 'Temporary
failure resolving', etc. that tend to be strong indicators of
environment problems rather than test problems.  There are a few other
good heuristics like tests that fail on only one architecture and pass
on all the others, or that are FTBFS on just one arch and haven't been
rebuilt in >15 days.  I also suspect some arch's may be more likely to
see environmental failures than others, but I don't have conclusive data
there yet.  And yes, obviously if someone's already retriggered the test
within the past few days and it still failed, there's little need to
retry that specific set of retriggers on that migration item again.

So, I strongly agree with Seth that there's some good automation
potential in retriggering things; plus, I think we can be even more
precise in how this is done by looking at what's causing these kinds of
failures, and then hopefully use resources more efficiently.

Bryce

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

Re: +1 maint - phpunit 9 bootstrap proposal

[Bryce Harrington]

On Wed, Feb 03, 2021 at 11:19:13AM -0800, Bryce Harrington wrote:
> On Wed, Jan 27, 2021 at 05:50:14PM -0800, Bryce Harrington wrote:
> > On Wed, Jan 27, 2021 at 01:40:48PM -0800, Bryce Harrington wrote:
> > > Brief update:
> > > 
> > > I've gotten most everything passing now, except composer and
> > > php-http-request2.
> > > 
> > > My best guess is that these two packages' test case failures are due to
> > > changed behavior in array behavior, however I've not had any luck so far
> > > diagnosing what's causing the failure.  I can reproduce the failures for
> > > php-http-request2 locally, but composer passes without issue when run
> > > locally.  None of the issues appear to be reported anywhere else, and
> > > both packages are passing Debian's CI without issue.
> > > 
> > > I'm not sure how much more time I want to invest in debugging these, and
> > > might consider suggesting to just disable the wayward tests just to get
> > > phpunit across the finish line.  Advice and/or help would be welcome.
> > 
> > For composer, I've filed:
> > https://github.com/composer/composer/issues/9654
> 
> I've uploaded the fix for composer and it's now passing its tests.
> 
> Now just php-http-request2 remains for unblocking phpunit.
> 

I got php-http-request2 sorted today.  It had 25 test cases using old
phpunit syntax that needed updated in order to work with phpunit 9.5.

I think phpunit and the various php bits dependent on it should finally
migrate now.  I'll check in on it next week.

Bryce

> > > Bryce
> > > 
> > > On Tue, Jan 19, 2021 at 03:55:54PM -0800, Bryce Harrington wrote:
> > > > On Tue, Jan 12, 2021 at 05:08:26PM -0800, Bryce Harrington wrote:
> > > > > On Tue, Jan 12, 2021 at 04:24:39PM -0800, Steve Langasek wrote:
> > > > > > On Mon, Jan 11, 2021 at 08:48:15PM -0800, Bryce Harrington wrote:
> > > > > > > phpunit has been stuck in a 8.5 -> 9.5 transition, which blocks 
> > > > > > > other
> > > > > > > things.  I'd like to propose we back out 9.5 and bootstrap to 
> > > > > > > 9.0, and
> > > > > > > *then* to 9.5.
> > > > 
> > > > Hi Steve,
> > > > 
> > > > I worked a bit Friday retriggering the remaining packages, which
> > > > got these to pass:
> > > > 
> > > >   php-guzzlehttp-psr7, phpdox, php-amqplib, php-laravel-lumen-framework,
> > > >   phpcpd
> > > > 
> > > > Over the weekend it looks like there was a re-trigger of the whole php
> > > > stack (or at least the phpunit-using portion of it), for phpunit 9.5.1-1
> > > > I guess.  This added a few more packages with issues, but they just
> > > > needed retriggers.
> > > > 
> > > > Today I reviewed the remainder, and note below what looks like needs
> > > > done to resolve them.
> > > > 
> > > > composer (2.0.8-2):
> > > >   - Errors:
> > > > + Failed asserting that 'Undefined index: file' matches PCRE pattern
> > > >   "/(File format not recognized|Unrecognized archive format)/i".
> > > > + Failed asserting that 'Undefined index: file' contains "is not a 
> > > > zip
> > > >   archive".
> > > > + Undefined index: file
> > > >   - "Undefined index" suggests the test is trying to read an array
> > > > element that doesn't exist.  All three tests appear to be expecting
> > > > an error message that isn't present in an array.
> > > >   - Not finding any indication of these errors reported upstream or in
> > > > Debian.
> > > >   - autopkgtest passes locally for me.
> > > >   - I'm not sure what is wrong here...
> > > > 
> > > > √ php-arthurhoaro-web-thumbnailer (2.0.3+dfsg-1):
> > > >   - Passed with phpunit 9.5.0-5, but is failing now with 9.5.1-1 on
> > > > arm64 only
> > > >   - Failures are network issues trying to connect to gravatar.com.
> > > > Previous failures haven't hit this before, so is unusual.
> > > >   - Re-triggered testrun as-is in case it's just a network issue
> > > >   - PASSED
> > > > 
> > > > √ php-crypt-gpg (1.6.4-1):
> > > >   - Passed with phpunit 9.5.0-5, but is failing now with 9.5.1-1 on
> > > > arm64 only
> > > >   - Failing testcase with error abo

+1 maintenance report

[Bryce Harrington]

Two priorities I focused on this week were getting ruby unblocked, and
drive phpunit towards completion.  In addition, I got about 80 other
packages to migrate via rebuilds and retriggers.

### Ruby / Rubygems / Rails ###

The Ruby transition has been gridlocked due to Node stuff, so I gave
this some priority attention this week.  tldr; I got the Node stuff
sorted but there's still some Ruby stuff to be done.

Ruby is blocked by rubygems, which is blocked by rails, which is blocked
by node-rollup.  Node-rollup's transition involved a few things, but the
key piece was node-rollup-plugin-node-resolve, which had a Breaks on the
exact version of rollup that is currently in hirsute.  This created a
situation where node-rollup FTBFS because it requires both rollup and
node-rollup-plugin-node-resolve, but could not have both installed
simultaneously due to the Breaks.  I softened the Breaks to allow
hirsute's rollup, which enabled node-rollup to build.

With that achieved, I was able to get rails to rebuild, and that allowed
a TON of ruby-* packages to retrigger and pass their autopkgtests.  A
few of these failed due to the usual intermittent network/hw issues, and
I got those resolved.

But for rails, there's still a handful of ruby-* packages needing
followup work.  Half a dozen of these show some sort of issue with
missing directory app/assets/javascripts/application.js; these probably
all share the same root cause.  There's a few more with other assorted
unrelated problems.

rubygems is only blocked by rails, so hopefully once rails clears,
rubygems will too.  I've retriggered its tests but think it may need to
wait until after rails.

ruby2.7 looks a lot closer to being ready to migrate now.  It's still
waiting on some armhf test results, but the only package that still has
problems is puma 4.3.6.  The test logs for puma on arm64 and amd64 show
different failures.  There is a puma 5.2.1 released upstream, and the
bug tracker shows work has been done on issues with similar error logs,
so there may be fixes available upstream.

For ruby-defaults, I retriggered the 15 or so packages listed with it
and rubygems, etc., but most did not pass and will need further
investigation.  The issues in the logs aren't obvious to me.



### PhpUnit ###

phpunit is transitioning from 8.5 to 9.5, which required some
bootstrapping work previously, but was down to three packages with
issues at the start of the week.

Two packages just required retriggers with the right versions of various
things.  The third package, php-http-request2/2.3.0-1ubuntu2, required a
bit more attention due to failures in 25 unit tests.

Upstream has released a new 2.4.2 version, which has some updates for
changes in PHP itself, but doesn't have updates needed for phpunit 9.

Fortunately, the updates were straightforward to figure out - there were
three (long-deprecated) PHPUnit functions that have been dropped with
PHPUnit 9.  I fixed these in the 25 test cases and uploaded
2.3.0-1ubuntu3 with the patches.

With this fixed, I believe phpunit should finally complete its
transition.  I'll check back on it next week to be sure.


### Regular +1 Maintenance ###

Along with the above, I did the usual labor of rebuilds and retriggers.


These had network, DNS, or test timeout issues.  I retriggered them and
they migrated:

apport/2.20.11-0ubuntu57 test failures on amd64
libreoffice/1:7.0.4~rc2-0ubuntu2 test failures on ppc64el
python3-lxc/1:3.0.4-1ubuntu8 test failures on arm64
automake-1.16/1:1.16.3-2ubuntu1 test failure on amd64
libinsane/1.0.9-2 on s390x
ocrmypdf/10.3.1+dfsg-1 on amd64
sshuttle/1.0.4-1ubuntu4 test failure on amd64
pcs/0.10.8-1 on amd64
dolfin/2019.2.0~git20201207.b495043-4 on armhf
julia/1.5.3+dfsg-2 on ppc64el
rtags/2.38-3 on amd64
rhonabwy/0.9.13-1 on armhf
r-cran-rsvd/1.0.3-3build1 on armhf
r-cran-sf/0.9-6+dfsg-2 on armhf
nbsphinx/0.8.0+ds-1 on armhf


These were FTBFS, but appear to just be due to flaky hardware or
something.  A simple rebuild got them sorted, and they were able to
progress to running autopkgtests:

flightgear-data/1:2020.3.6+dfsg-1 build failure on amd64
libblockdev/2.25-1 build failure on riscv64
mu-editor/1.0.3+dfsg-2 build failure on amd64
botch/0.23-1 build failure on riscv64
neutron/2:17.1.0+git2021012815.0fb63f7297-0ubuntu2 build failure on amd64
trapperkeeper-scheduler-clojure/1.1.3-3 build failure on amd64
phpmyadmin/4:5.0.4+dfsg2-2 build failure on amd64
glewlwyd/2.5.2-1 build failure on amd64
twitter-bootstrap4/4.5.2+dfsg1-6 build failure on amd64
safe-rm/1.1.0-2 build failure on riscv64
golang-github-hashicorp-go-plugin/1.0.1-3 build failure on amd64
node-katex/0.10.2+dfsg-8 build failure on amd64
gitbatch/0.5.0-3 build failure on riscv64
vue.js/2.6.12+dfsg-3 build failure on amd64
node-mini-css-extract-plugin/1.3.3-1 build failure on amd64


This next set had test failures due to 

Re: +1 maint - phpunit 9 bootstrap proposal

[Bryce Harrington]

On Wed, Jan 27, 2021 at 05:50:14PM -0800, Bryce Harrington wrote:
> On Wed, Jan 27, 2021 at 01:40:48PM -0800, Bryce Harrington wrote:
> > Brief update:
> > 
> > I've gotten most everything passing now, except composer and
> > php-http-request2.
> > 
> > My best guess is that these two packages' test case failures are due to
> > changed behavior in array behavior, however I've not had any luck so far
> > diagnosing what's causing the failure.  I can reproduce the failures for
> > php-http-request2 locally, but composer passes without issue when run
> > locally.  None of the issues appear to be reported anywhere else, and
> > both packages are passing Debian's CI without issue.
> > 
> > I'm not sure how much more time I want to invest in debugging these, and
> > might consider suggesting to just disable the wayward tests just to get
> > phpunit across the finish line.  Advice and/or help would be welcome.
> 
> For composer, I've filed:
> https://github.com/composer/composer/issues/9654

I've uploaded the fix for composer and it's now passing its tests.

Now just php-http-request2 remains for unblocking phpunit.

Bryce

> > Bryce
> > 
> > On Tue, Jan 19, 2021 at 03:55:54PM -0800, Bryce Harrington wrote:
> > > On Tue, Jan 12, 2021 at 05:08:26PM -0800, Bryce Harrington wrote:
> > > > On Tue, Jan 12, 2021 at 04:24:39PM -0800, Steve Langasek wrote:
> > > > > On Mon, Jan 11, 2021 at 08:48:15PM -0800, Bryce Harrington wrote:
> > > > > > phpunit has been stuck in a 8.5 -> 9.5 transition, which blocks 
> > > > > > other
> > > > > > things.  I'd like to propose we back out 9.5 and bootstrap to 9.0, 
> > > > > > and
> > > > > > *then* to 9.5.
> > > 
> > > Hi Steve,
> > > 
> > > I worked a bit Friday retriggering the remaining packages, which
> > > got these to pass:
> > > 
> > >   php-guzzlehttp-psr7, phpdox, php-amqplib, php-laravel-lumen-framework,
> > >   phpcpd
> > > 
> > > Over the weekend it looks like there was a re-trigger of the whole php
> > > stack (or at least the phpunit-using portion of it), for phpunit 9.5.1-1
> > > I guess.  This added a few more packages with issues, but they just
> > > needed retriggers.
> > > 
> > > Today I reviewed the remainder, and note below what looks like needs
> > > done to resolve them.
> > > 
> > > composer (2.0.8-2):
> > >   - Errors:
> > > + Failed asserting that 'Undefined index: file' matches PCRE pattern
> > >   "/(File format not recognized|Unrecognized archive format)/i".
> > > + Failed asserting that 'Undefined index: file' contains "is not a zip
> > >   archive".
> > > + Undefined index: file
> > >   - "Undefined index" suggests the test is trying to read an array
> > > element that doesn't exist.  All three tests appear to be expecting
> > > an error message that isn't present in an array.
> > >   - Not finding any indication of these errors reported upstream or in
> > > Debian.
> > >   - autopkgtest passes locally for me.
> > >   - I'm not sure what is wrong here...
> > > 
> > > √ php-arthurhoaro-web-thumbnailer (2.0.3+dfsg-1):
> > >   - Passed with phpunit 9.5.0-5, but is failing now with 9.5.1-1 on
> > > arm64 only
> > >   - Failures are network issues trying to connect to gravatar.com.
> > > Previous failures haven't hit this before, so is unusual.
> > >   - Re-triggered testrun as-is in case it's just a network issue
> > >   - PASSED
> > > 
> > > √ php-crypt-gpg (1.6.4-1):
> > >   - Passed with phpunit 9.5.0-5, but is failing now with 9.5.1-1 on
> > > arm64 only
> > >   - Failing testcase with error about invalid GPG password.
> > >   - Re-triggering as-is, to rule out flaky test environment
> > >   - PASSED
> > > 
> > > php-doctrine-dbal (2.12.1-1):
> > >   - The build logs indicate the autopkgtest failed, but the results show
> > > no errors, just warnings.
> > >   - Running autopkgtest locally shows two errors in DBAL's
> > > PortabilityTest.php
> > > + Debian's 0002-Revert-Update-PHPUnit-to-9.2.patch is altering
> > >   PortabilityTest.php.  With this patch disabled, these tests pass,
> > >   however there's then a different error, permission denied trying
> > >   to chattr on /tmp/doctrine_failed_connection_292.

Re: +1 maint - phpunit 9 bootstrap proposal

[Bryce Harrington]

On Wed, Jan 27, 2021 at 01:40:48PM -0800, Bryce Harrington wrote:
> Brief update:
> 
> I've gotten most everything passing now, except composer and
> php-http-request2.
> 
> My best guess is that these two packages' test case failures are due to
> changed behavior in array behavior, however I've not had any luck so far
> diagnosing what's causing the failure.  I can reproduce the failures for
> php-http-request2 locally, but composer passes without issue when run
> locally.  None of the issues appear to be reported anywhere else, and
> both packages are passing Debian's CI without issue.
> 
> I'm not sure how much more time I want to invest in debugging these, and
> might consider suggesting to just disable the wayward tests just to get
> phpunit across the finish line.  Advice and/or help would be welcome.

For composer, I've filed:
https://github.com/composer/composer/issues/9654

> Bryce
> 
> On Tue, Jan 19, 2021 at 03:55:54PM -0800, Bryce Harrington wrote:
> > On Tue, Jan 12, 2021 at 05:08:26PM -0800, Bryce Harrington wrote:
> > > On Tue, Jan 12, 2021 at 04:24:39PM -0800, Steve Langasek wrote:
> > > > On Mon, Jan 11, 2021 at 08:48:15PM -0800, Bryce Harrington wrote:
> > > > > phpunit has been stuck in a 8.5 -> 9.5 transition, which blocks other
> > > > > things.  I'd like to propose we back out 9.5 and bootstrap to 9.0, and
> > > > > *then* to 9.5.
> > 
> > Hi Steve,
> > 
> > I worked a bit Friday retriggering the remaining packages, which
> > got these to pass:
> > 
> >   php-guzzlehttp-psr7, phpdox, php-amqplib, php-laravel-lumen-framework,
> >   phpcpd
> > 
> > Over the weekend it looks like there was a re-trigger of the whole php
> > stack (or at least the phpunit-using portion of it), for phpunit 9.5.1-1
> > I guess.  This added a few more packages with issues, but they just
> > needed retriggers.
> > 
> > Today I reviewed the remainder, and note below what looks like needs
> > done to resolve them.
> > 
> > composer (2.0.8-2):
> >   - Errors:
> > + Failed asserting that 'Undefined index: file' matches PCRE pattern
> >   "/(File format not recognized|Unrecognized archive format)/i".
> > + Failed asserting that 'Undefined index: file' contains "is not a zip
> >   archive".
> > + Undefined index: file
> >   - "Undefined index" suggests the test is trying to read an array
> > element that doesn't exist.  All three tests appear to be expecting
> > an error message that isn't present in an array.
> >   - Not finding any indication of these errors reported upstream or in
> > Debian.
> >   - autopkgtest passes locally for me.
> >   - I'm not sure what is wrong here...
> > 
> > √ php-arthurhoaro-web-thumbnailer (2.0.3+dfsg-1):
> >   - Passed with phpunit 9.5.0-5, but is failing now with 9.5.1-1 on
> > arm64 only
> >   - Failures are network issues trying to connect to gravatar.com.
> > Previous failures haven't hit this before, so is unusual.
> >   - Re-triggered testrun as-is in case it's just a network issue
> >   - PASSED
> > 
> > √ php-crypt-gpg (1.6.4-1):
> >   - Passed with phpunit 9.5.0-5, but is failing now with 9.5.1-1 on
> > arm64 only
> >   - Failing testcase with error about invalid GPG password.
> >   - Re-triggering as-is, to rule out flaky test environment
> >   - PASSED
> > 
> > php-doctrine-dbal (2.12.1-1):
> >   - The build logs indicate the autopkgtest failed, but the results show
> > no errors, just warnings.
> >   - Running autopkgtest locally shows two errors in DBAL's
> > PortabilityTest.php
> > + Debian's 0002-Revert-Update-PHPUnit-to-9.2.patch is altering
> >   PortabilityTest.php.  With this patch disabled, these tests pass,
> >   however there's then a different error, permission denied trying
> >   to chattr on /tmp/doctrine_failed_connection_292.db.  Still, this
> >   looks like the right path to investigate
> >   - Also, there is a new 3.0.0-1 in debian experimental
> > 
> > php-http-request2 (2.3.0-1ubuntu2):
> >   - Reproduced same 25 testsuite failures locally in lxc.
> > Offhand, I am wondering if these are due to phpunit api changes?
> >   - Debian is also seeing autopkgtest failures with this package,
> > although their errors look like phpunit framework issues.
> >   - There is a new upstream version 2.4.2 (not yet in Debian) with some
> > php version updates.  Might be worth pulling that version in.
> > 
> > php-league-flysy

Re: +1 maint - phpunit 9 bootstrap proposal

[Bryce Harrington]

Brief update:

I've gotten most everything passing now, except composer and
php-http-request2.

My best guess is that these two packages' test case failures are due to
changed behavior in array behavior, however I've not had any luck so far
diagnosing what's causing the failure.  I can reproduce the failures for
php-http-request2 locally, but composer passes without issue when run
locally.  None of the issues appear to be reported anywhere else, and
both packages are passing Debian's CI without issue.

I'm not sure how much more time I want to invest in debugging these, and
might consider suggesting to just disable the wayward tests just to get
phpunit across the finish line.  Advice and/or help would be welcome.

Bryce

On Tue, Jan 19, 2021 at 03:55:54PM -0800, Bryce Harrington wrote:
> On Tue, Jan 12, 2021 at 05:08:26PM -0800, Bryce Harrington wrote:
> > On Tue, Jan 12, 2021 at 04:24:39PM -0800, Steve Langasek wrote:
> > > On Mon, Jan 11, 2021 at 08:48:15PM -0800, Bryce Harrington wrote:
> > > > phpunit has been stuck in a 8.5 -> 9.5 transition, which blocks other
> > > > things.  I'd like to propose we back out 9.5 and bootstrap to 9.0, and
> > > > *then* to 9.5.
> 
> Hi Steve,
> 
> I worked a bit Friday retriggering the remaining packages, which
> got these to pass:
> 
>   php-guzzlehttp-psr7, phpdox, php-amqplib, php-laravel-lumen-framework,
>   phpcpd
> 
> Over the weekend it looks like there was a re-trigger of the whole php
> stack (or at least the phpunit-using portion of it), for phpunit 9.5.1-1
> I guess.  This added a few more packages with issues, but they just
> needed retriggers.
> 
> Today I reviewed the remainder, and note below what looks like needs
> done to resolve them.
> 
> composer (2.0.8-2):
>   - Errors:
> + Failed asserting that 'Undefined index: file' matches PCRE pattern
>   "/(File format not recognized|Unrecognized archive format)/i".
> + Failed asserting that 'Undefined index: file' contains "is not a zip
>   archive".
> + Undefined index: file
>   - "Undefined index" suggests the test is trying to read an array
> element that doesn't exist.  All three tests appear to be expecting
> an error message that isn't present in an array.
>   - Not finding any indication of these errors reported upstream or in
> Debian.
>   - autopkgtest passes locally for me.
>   - I'm not sure what is wrong here...
> 
> √ php-arthurhoaro-web-thumbnailer (2.0.3+dfsg-1):
>   - Passed with phpunit 9.5.0-5, but is failing now with 9.5.1-1 on
> arm64 only
>   - Failures are network issues trying to connect to gravatar.com.
> Previous failures haven't hit this before, so is unusual.
>   - Re-triggered testrun as-is in case it's just a network issue
>   - PASSED
> 
> √ php-crypt-gpg (1.6.4-1):
>   - Passed with phpunit 9.5.0-5, but is failing now with 9.5.1-1 on
> arm64 only
>   - Failing testcase with error about invalid GPG password.
>   - Re-triggering as-is, to rule out flaky test environment
>   - PASSED
> 
> php-doctrine-dbal (2.12.1-1):
>   - The build logs indicate the autopkgtest failed, but the results show
> no errors, just warnings.
>   - Running autopkgtest locally shows two errors in DBAL's
> PortabilityTest.php
> + Debian's 0002-Revert-Update-PHPUnit-to-9.2.patch is altering
>   PortabilityTest.php.  With this patch disabled, these tests pass,
>   however there's then a different error, permission denied trying
>   to chattr on /tmp/doctrine_failed_connection_292.db.  Still, this
>   looks like the right path to investigate
>   - Also, there is a new 3.0.0-1 in debian experimental
> 
> php-http-request2 (2.3.0-1ubuntu2):
>   - Reproduced same 25 testsuite failures locally in lxc.
> Offhand, I am wondering if these are due to phpunit api changes?
>   - Debian is also seeing autopkgtest failures with this package,
> although their errors look like phpunit framework issues.
>   - There is a new upstream version 2.4.2 (not yet in Debian) with some
> php version updates.  Might be worth pulling that version in.
> 
> php-league-flysystem (1.1.3-2):
>   - Timestamp discrepancy on file in filesystem.  Same issue seen on
> all arch's.
>   - Debian is seeing same issue in their autopkgtests.
>   - Fixed in 1.1.3-3.  This should sync in when it's migrated in Debian.
> 
> php-net-ldap2 (2.2.0-3ubuntu3):
>   - The test failures here are fixed in 2.2.0-6 from -proposed
>   - The ubuntu delta is safe to drop - it's just compatibility fixups
> for earlier phpunit problems.
>   - I've retriggered with php-net-ldap2 from -proposed
> 
> php-twig (2.14.1-1):
>   - Fixed in 2.14.1-2:
>

Re: +1 maintenance report (dogtag-pki vs 389-ds-base)

[Bryce Harrington]

On Fri, Jan 22, 2021 at 08:08:45AM -0800, Brian Murray wrote:
> On Thu, Jan 21, 2021 at 03:25:02PM -0500, Sergio Durigan Junior wrote:
> > On Thursday, January 21 2021, Timo Aaltonen wrote:
> > 
> > > On 21.1.2021 18.59, Lukas Märdian wrote:
> > >> NO - dogtag-pki vs ['389-ds-base/1.4.4.9-1build2',
> > >> 'net-snmp/5.9+dfsg-3ubuntu1']
> > >>
> > >> So I had a closer look into the dogtag-pki failure on s390x. I could
> > >> easily reproduce the problem inside a s390x LXD container, but
> > >> wasn't able to isolate the root cause... After quite some
> > >> investigation I was able to produce a debug trace of the problem,
> > >> and to me it looks like the issue is actually not inside this
> > >> package, but rather inside the LDAP server (i.e. 389-ds-base), as
> > >> the debug log shows an "SEVERE: Unable to modify o=pki-tomcat-CA:
> > >> netscape.ldap.LDAPException: error result (1); Operations error",
> > >> i.e. "Internal Server Error"
> > >> (https://docs.oracle.com/cd/E19957-01/816-5618-10/netscape/ldap/LDAPException.html#OPERATION_ERROR
> > >> ).
> > >>  I
> > >> do not really understand why the LDAP server would behave
> > >> differently on s390x than on all the other architectures, but I
> > >> guess this is for another time...
> > >>
> > >> Debug log: https://paste.ubuntu.com/p/vx9JB6VTjF/
> > >> 
> > >
> > > This seems to go back to at least 389-ds-base 1.4.4.4, probably
> > > longer. Would be useful to know where it regressed.
> > >
> > > As to why it only happens on s390x my guess would be that it's related
> > > to endianness (it's big-endian). Upstream tests only on amd64 (LE).
> > 
> > I'm also very interested in solving this, because it's blocking net-snmp
> > and a bunch of other packages from migrating.
> > 
> > Last week I did some investigation and pretty much stopped at the same
> > point as Lukas did.  I wasn't able to pinpoint exactly what the root
> > cause is, but Timo's guess is a good starting point.
> > 
> > I fiddled a bit with autopkgtest.db and confirmed that the failures
> > started with 389-ds-base/1.4.4.4-1:
> > 
> >   sqlite> SELECT test.package, result.version, result.triggers, 
> > result.exitcode FROM result INNER JOIN test ON test.id = result.test_id 
> > where test.package = 'dogtag-pki' and result.triggers LIKE '%389-ds-base%';
> 
> I find your querying of the SQLite database pretty interesting. Is there
> any documentation about the structure of the database and queries that
> might be useful?

Not really, but there's only 3 tables and not many fields.

Main trouble is downloading the database (it's huge, and of course
changes every few hours).  Would be nicer if we had a REST interface in
front of it to code our scripts against...

Bryce



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

Re: +1 maint - phpunit 9 bootstrap proposal

[Bryce Harrington]

On Tue, Jan 12, 2021 at 05:08:26PM -0800, Bryce Harrington wrote:
> On Tue, Jan 12, 2021 at 04:24:39PM -0800, Steve Langasek wrote:
> > On Mon, Jan 11, 2021 at 08:48:15PM -0800, Bryce Harrington wrote:
> > > phpunit has been stuck in a 8.5 -> 9.5 transition, which blocks other
> > > things.  I'd like to propose we back out 9.5 and bootstrap to 9.0, and
> > > *then* to 9.5.

Hi Steve,

I worked a bit Friday retriggering the remaining packages, which
got these to pass:

  php-guzzlehttp-psr7, phpdox, php-amqplib, php-laravel-lumen-framework,
  phpcpd

Over the weekend it looks like there was a re-trigger of the whole php
stack (or at least the phpunit-using portion of it), for phpunit 9.5.1-1
I guess.  This added a few more packages with issues, but they just
needed retriggers.

Today I reviewed the remainder, and note below what looks like needs
done to resolve them.

composer (2.0.8-2):
  - Errors:
+ Failed asserting that 'Undefined index: file' matches PCRE pattern
  "/(File format not recognized|Unrecognized archive format)/i".
+ Failed asserting that 'Undefined index: file' contains "is not a zip
  archive".
+ Undefined index: file
  - "Undefined index" suggests the test is trying to read an array
element that doesn't exist.  All three tests appear to be expecting
an error message that isn't present in an array.
  - Not finding any indication of these errors reported upstream or in
Debian.
  - autopkgtest passes locally for me.
  - I'm not sure what is wrong here...

√ php-arthurhoaro-web-thumbnailer (2.0.3+dfsg-1):
  - Passed with phpunit 9.5.0-5, but is failing now with 9.5.1-1 on
arm64 only
  - Failures are network issues trying to connect to gravatar.com.
Previous failures haven't hit this before, so is unusual.
  - Re-triggered testrun as-is in case it's just a network issue
  - PASSED

√ php-crypt-gpg (1.6.4-1):
  - Passed with phpunit 9.5.0-5, but is failing now with 9.5.1-1 on
arm64 only
  - Failing testcase with error about invalid GPG password.
  - Re-triggering as-is, to rule out flaky test environment
  - PASSED

php-doctrine-dbal (2.12.1-1):
  - The build logs indicate the autopkgtest failed, but the results show
no errors, just warnings.
  - Running autopkgtest locally shows two errors in DBAL's
PortabilityTest.php
+ Debian's 0002-Revert-Update-PHPUnit-to-9.2.patch is altering
  PortabilityTest.php.  With this patch disabled, these tests pass,
  however there's then a different error, permission denied trying
  to chattr on /tmp/doctrine_failed_connection_292.db.  Still, this
  looks like the right path to investigate
  - Also, there is a new 3.0.0-1 in debian experimental

php-http-request2 (2.3.0-1ubuntu2):
  - Reproduced same 25 testsuite failures locally in lxc.
Offhand, I am wondering if these are due to phpunit api changes?
  - Debian is also seeing autopkgtest failures with this package,
although their errors look like phpunit framework issues.
  - There is a new upstream version 2.4.2 (not yet in Debian) with some
php version updates.  Might be worth pulling that version in.

php-league-flysystem (1.1.3-2):
  - Timestamp discrepancy on file in filesystem.  Same issue seen on
all arch's.
  - Debian is seeing same issue in their autopkgtests.
  - Fixed in 1.1.3-3.  This should sync in when it's migrated in Debian.

php-net-ldap2 (2.2.0-3ubuntu3):
  - The test failures here are fixed in 2.2.0-6 from -proposed
  - The ubuntu delta is safe to drop - it's just compatibility fixups
for earlier phpunit problems.
  - I've retriggered with php-net-ldap2 from -proposed

php-twig (2.14.1-1):
  - Fixed in 2.14.1-2:

https://salsa.debian.org/php-team/pear/twig/-/commit/77d0a0f8f6f5b5754c5752f50cbaa55b3ca07fc5
  - I've retriggered with php-twig from -proposed

php-parser (4.10.4-1):
  - Data type discrepancy on armhf
  - The two armhf failures have been seen before (lp: #1878102),
and we've disabled the tests in the past.  Probably easiest path
forward here as well.

Bryce


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

Re: +1 maint - phpunit 9 bootstrap proposal

[Bryce Harrington]

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

Excellent!

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

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

Bryce

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

+1 maint - phpunit 9 bootstrap proposal

[Bryce Harrington]

phpunit has been stuck in a 8.5 -> 9.5 transition, which blocks other
things.  I'd like to propose we back out 9.5 and bootstrap to 9.0, and
*then* to 9.5.


In looking at the phpunit builds on update_excuses, phpunit 9.5 fails to
build due to three of its dependencies, which themselves are failing to
build because they in turn have phpunit 9.x as build dependencies.
E.g.:

  phpunit unsatisfiable Build-Depends(-Arch) on amd64: php-codecoverage (>= 9)

  php-codecoverage 9.2.5+dfsg-2 shows "Missing build dependencies: phpunit (>= 
9)"

(Near as I can tell, the packages depend on phpunit only for
running the testsuite in debian/rules' override_dh_auto_test.  The
packages don't appear to actually depend on any code from phpunit.)

Debian did not jump straight from 8.5 to 9.5, but rather went through
the intermediate versions in Experimental.  It looks like phpunit 9.0.0
might be new enough to satisfy various built requirements, without
having too intensive build requirements itself.

RAOF suggested one option might be to do similarly - remove phpunit from
-proposed, stage the intermediary pieces in a PPA, and then
source+binary copy them into the archive.  I've staged the pieces, with
their testsuites disabled, here:

  https://launchpad.net/~bryce/+archive/ubuntu/phpunit-bootstrap/+packages

Once that phpunit is happily in the archive, I believe the remainder of
the phpunit stack should be able to be rebuilt, and then phpunit 9.5
could be re-introduced and hopefully complete the phpunit transition.

Neither RAOF or I have worked on phpunit previously, and we're not
certain that this is the proper approach, so would appreciate a thumb's
up or course correction from Vorlon, Xnox, etc., before we actually do
it.  Is this a sensible path?

Bryce

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

[Bryce Harrington]

This was my week's rotation on +1 maintenance.  There are several
transitions in process, it doesn't look like they're conflicting with
each other so much as just taxing the runners (particularly on armhf and
ppc64el).



### Stats ###

Monday: 1398 update excuse records found
Tuesday:1262 update excuse records found
Wednesday:  1114 update excuse records found
Thursday:   1068 update excuse records found
Friday: 1018 update excuse records found



### Ruby ###

Lucas mentioned that he fixed rubygems in debian and now the ruby stack
could be retriggered.  I did so, with triggers for the proposed versions
of rubygems, ruby-defaults, icu, and libxml.  Unfortunately, that seems
not to be sufficient.  The logs for the various ruby packages show
errors about not being able to find specific gems or the rubygems
package in general.

As an experiment, I tried a no-change rebuild of ruby-bootsnap, but it
FTBFS on all arch's.  I verified it is building with the new rubygems
and gem2deb packages.

Checking with Lucas, he said, "I would go through the dependencies chain
and check if they were built with gem2deb 1.4.  Maybe something is
missing it."


### PHP ###

* php7.4 was blocking apparmor (and later openssl) due to unsatisfied
  dependencies on i386.  I retriggered with icu, openssl, and a dozen
  other packages which seems to have resolved it (some tests still in
  progress though).

* php8.0 was in the archive, due to autosync from Debian.  We aren't
  planning for PHP 8.0 this cycle so we've removed it for 21.04 and
  blocked it from syncing.

* php-horde-ansel:  We removed php-horde* in focal, but this seems to be
  a remnant that popped up via autosync.  Filed LP: #1907705 to have it
  removed.

* php-phar-io-manifest / php-phar-io-version: Just needed triggered
  together, along with phpunit.

* php-token-stream: Also needed retriggered against php-phar-io* and
  phpunit

* phpunit: Also needed retriggered against php-phar-io* and phpunit, and
  symfony

While the above retriggers worked, there were failures still on i386,
although not sure that will cause problems migrating.  If they do, we
may want to look closer at supportability of php on i386 more generally.



### R-Bioc-* ###

There's a bunch of r-bioc-* packages in update-excuses.  I did a heavy
amount of retriggering, which seems to have resolved _some_ issues, but
most of the packages are still blocked until r-bioc-biocgenerics
migrates, and r-bioc-biocgenerics is blocking on six packages:

  - r-bioc-genomeinfodb
  - r-bioc-annotationhub
  - r-bioc-delayedarray
  - r-bioc-delayedmatrixstats
  - r-bioc-dropletutils
  - r-bioc-shortread

r-bioc-genomeinfodb is failing because it's trying to access the web
during its unit tests (ftp.ncbi.nlm.nih.gov port 21 specifically).  It
may need to be reconfigured to not do that, or else have its test(s)
skipped (i.e. maybe add hint force-badtest?)

r-bioc-annotationhub complains about an invalid cache for
sqlite, and asks to run with localHub=False.  This sounds like it might
also be a "can't access the web" situation (see
https://support.bioconductor.org/p/127555/).

r-bioc-delayedarray and r-bioc-delayedmatrixstats show warnings and
errors about invalid data types.  Might be ordinary test failures but
googling reveals nothing on them.  I kind of wonder if these too are
needing data or packages from the web and just lack code to handle that
error.

r-bioc-dropletutils (arm64) looks more like a platform data type
discrepancy.  "Objects equal but not identical".  Googling turned up
https://github.com/r-lib/testthat/issues/920 that if used might give
more debuggable information here.

r-bioc-shortread (amd64) complains of an undefined superclass.  Googling
showed a hint that this may need a newer Biobase, so maybe retriggering
this against hirsute-propose's r-bioc-biobase/2.50.0-1 would resolve
it.  If not, maybe there is a patch in r-bioc-biobase master to cherrypick.


### crmsh / pacemaker ###

Retriggered together plus with lxml and some py deps in -proposed, and
they seem happy now.



### Package Rebuilds ###

These FTBFS resolved by just a rebuild:

  - limnoria
  - python-casacore
  - mousetweaks
  - pqiv
  - perl6-zef
  - herbstluftwm
  - node-jsonld
  - puppetlabs-ring-middleware-clojure
  - netplan.io
  - sahara
  - python-sqlalchemy-utils
  - placement
  - intel-media-driver-non-free 20.4.2+ds1-1


### Retriggers ###

These all passed with just a simple retriggering:

  - aptdaemon (amd64)
  - arrayfire (armhf)
  - asterisk (ppc64el)
  - augur (amd64)
  - bambam (arm64)
  - deal.ii (ppc64el)
  - dgit (armhf)
  - fmtlib (arm64)
  - golang-github-containerd-cgroups (ppc64el)
  - golang-github-dchest-uniuri (s390x)
  - golang-github-emersion-go-imap (arm64)
  - golang-github-farsightsec-go-nmsg (armhf)
  - golang-github-fluffle-goirc (armhf)
  - golang-golang-x-text (amd64)
  - golang-golang-x-net (arm64)
  - golang-honnef-go-tools (amd64)
  - golang-logrus (armhf)
  - golang-testify 

+1 maintenance report

[Bryce Harrington]

### golang-* ###

Since there's a lot of golang-* packages I made that my main focus for
the week, and made some progress.

* golang-github-grpc-ecosystem-grpc-gateway
  - One test case was broken because it uses deprecated code and
unstable API.  Easiest to just skip the test.
  - The other test case breakage was causing a 'panic'.  I found an
upstream fix for that, but this enabled more tests to run and more
test failures.
  - I filed bug LP: #1897179 with my patches if anyone wants to carry it
forward from here.  There might be existing fixes upstream for the
remaining test failures.
  - However time might be better invested merging and testing a newer
upstream release (1.5.x maybe?), and/or the unreleased v2 branch.

* These just needed re-triggered against current archive:
  - golang-github-willf-bitset: Passed migration
  - golang-github-armon-go-metrics: Passed migration
  - golang-github-marten-seemann-qpack: Passed migration

* golang-golang-x-exp:  I think this might need this patch:
  https://github.com/golang/exp/commit/7c80518d1cc79ffde9e571fe4fd281f321d36200

* These are blocked on i386 because of dependency on other packages not
  installable on i386:
  - golang-github-fernet-fernet-go
  - golang-github-rakyll-statik

There's a dozen more golang packages waiting on each other or stuck for
other reasons.


### heat / python-oslo ###

There was a cluster of migration issues around heat and the
python-oslo.* packages.  These are now mostly all resolved.

* I cleared a lot of these with some customized re-triggers:
  - python-troveclient: Passed migration
  - python-cinderclient: Passed migration
  - python-oslo.cache: Passed migration
  - python-oslo.config: Passed migration
  - python-oslo.context: Passed migration
  - python3-oslo.serialization: Passed migration
  - python-osprofiler: Passed migration

The last two were failing due to an expired (25 sec) timeout starting up
the heat daemon.  Since they passed on re-trigger I'm guessing it was
just a random timing issue.  However, I'm also assuming these will occur
off and on in the future.

While investigating, I also noticed an error in the timeout handling
that was preventing the error log from getting displayed in the test
results.  I uploaded a fix, and sent an MP:

  https://code.launchpad.net/~bryce/ubuntu/+source/heat/+git/heat/+merge/391390

The build won't finish before my EOW and won't know if the oslo/heat
package troubles will persist or resolve, so next +1 maintenance person
my need to pick it up from here.  But hopefully the error log fix will
ensure there's some better details for diagnosis.


### pygalmesh ###

I opened an update-excuse bug (LP: #1897338) on this, with a link to the
upstream bug report that Michael Hudston-Doyle filed when he looked at
this a couple weeks ago.  Probably needs someone on s390x to do some gdb
work to figure out what the failure is.


### osmo-sgsn ###

After updating to newer gcc, this is failing on a warning being treated
as an error, for code that it thinks may have a null pointer deref.  The
fix for this is to check the return from gprs_subscr_get_or_create() for
NULL and then... maybe warn & bail?  That implies all users of
gprs_subscr_get_or_create_by_mmctx() will need to test for NULL too.  I
see that the issue is still relevant to upstream's current codebase, so
a next action might be to report it to them.

Note we're several versions behind upstream here.  I don't think
updating to a newer version would solve this bug, but from the upstream
git changelog there's lots of fixes.  Might make more sense to try
merging a newer version from upstream before investing too much time
fixing CI issues.


### ruby-joiner ###

After retriggering with a more complete set of dependencies, this
passed, however it still is blocked from migrating due to rails.


### ruby-http-parser ###

Has some sort of dependency issue on s390x with ruby-http.  It's been
stuck in proposed-migration with this issue since April.  I couldn't
make headway on it, but I think a good next-action might be to open a
bug report where we can start accumulating analysis.


### securefs ###

This is hitting an error with a too-long filename on amd64 in a getattr
operation, which triggers some exceptions.  This failure has been going
on for a few releases.

* I found a couple similar-sounding issues upstream but I don't think
  they're the same as this:
  - https://github.com/netheril96/securefs/issues/82
  - https://github.com/netheril96/securefs/issues/84


### lintian-brush ###

Michael had said, "lintian-brush tests fail on s390x but it seems very
likely the problem is really in "ruamel.yaml.clib", a Python C extension
library which does not have (afaics) any tests (!)."

There aren't any relevant bugs or changes in upstream for either
lintian-brush or ruamel.yaml.clib.  The issue doesn't reproduce on amd64
unfortunately.

Next action for this would be to try to reproduce on s390x.  The test
case is 

Re: nodejs in groovy-proposed? (Re: +1 maintenance report)

[Bryce Harrington]

On Tue, Aug 11, 2020 at 01:02:27PM -0700, Steve Langasek wrote:
> On Tue, Aug 11, 2020 at 09:55:16AM -0700, Bryce Harrington wrote:
> 
> > Could someone give a status update on the icu and json-c transitions?
> > I see they've been progressing daily, but curious since server team has
> > a few packages blocked from migrating.
> 
> The big problem I see right now is nodejs, which seems to have made a
> complete mess of the autopkgtests of its revdeps.  I'd be interested to know
> if anyone is working on this and sees indications that it's tractable, or if
> we should just revert nodejs for now.

I worked on it quite a bit during my +1 maintenance shift a couple weeks
ago.  It has indeed been a huge mess, but it has definitely gotten a lot
better.  Looks to me like there's just three problems remaining for
nodejs itself:

a.  The main remaining issue is that for three of the packages there is a
bug on pcc64el with SHA1 encryption[1], which osomon has been working
on, and found to be due to a compiler optimization error.  He forwarded
it upstream[2] and yesterday upstream provided a patch to test[3].  So
this looks like it's on a path to be solved soon.

b.  Another three packages appear to be hitting timeouts on autopkgtests,
for arm64 only.  Their test histories look like they mostly fail with
scattered random passes.  Maybe a flaky test?  Maybe re-running it a few
times will resolve them?

c.  node-clean-css is the only other failure.  It occurs only on armhf
and only for a single test case.  It doesn't print any details about
what the test case was or how it failed.

In addition to nodejs itself, many node-* packages need rebuilt or
retriggered.  I did a bunch of these on my shift but we're getting
additional ones syncing from Debian.

So, nodejs feels reasonably close, and moving from nodejs 10 to 12 would
be a big improvement for users.

Bryce

1: https://bugs.launchpad.net/ubuntu/+source/node-sha.js/+bug/1887144
2: https://bugs.launchpad.net/ubuntu/+source/node-sha.js/+bug/1887144
3: https://chromium-review.googlesource.com/c/v8/v8/+/2349468

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

Re: +1 maintenance report

[Bryce Harrington]

On Tue, Aug 04, 2020 at 09:53:26PM +1200, Michael Hudson-Doyle wrote:
> Hi all,
> 
> I noticed golang-gopkg-square-go-jose.v2 times out on armhf, filed
> https://github.com/square/go-jose/issues/326.
> 
> Then I looked at the icu transition.
> 
> 0ad fails to build due to gcc-10, I found the fix for this upstream and
> backported it.
> 
> I retried some ucto builds which appeared to have run before a build
> dependency had been built (maybe fallout from the build farm outage). And
> retried "frog" builds when these completed.

> doxygen autopkgtests are failing because the json-c in proposed has moved
> its Doxyfile.
> 
> doxygen's tests fail with the json-c in proposed: it builds the
> documentation for json-c in an autopkgtest but json-c has moved it's
> Doxyfile into a different directory. Easy to fix once json-c has migrated.
> 
> Cheers,
> mwh

Could someone give a status update on the icu and json-c transitions?
I see they've been progressing daily, but curious since server team has
a few packages blocked from migrating.

Thanks,
Bryce

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

[Bryce Harrington]

Here's some of the things I worked on for my +1 maintenance this week.

* Packages where only a single arch failed, I retriggered test runs.
  Many of these required additional triggers to include icu, gcc-10, etc.
  - sleekxmpp
  - jinja2
  - lua-luv
  - libhttp-dav-perl
  - node-jquery
  - gegl
  - bluez-qt
  - Bunch more, lost track...

* Went through packages listing 'missing builds' and re-triggered
  ones where the logs showed connection errors or other irregularities
  that might be build system errors.  Quite a few of these passed.

* Rebuilt / retested all packages with a riscv failure more than 30 days
  old.  It's relatively new, figured things change fast.  Over half of
  these passed.

* php-horde-*: Most of this stack has been blocked from being synced,
  but there were four more trying to sync.  These four are added now.
  (If any other php-horde-* packages show up, please add them as well.)

* openclipart: Debian is on libreoffice 7.x but we're on 6.x;
  openclipart was trying to depend on a new binary package from 7.x.  I
  restored that back to the 6.x-era dependency, and this migrated.

* nodejs: There was a syntax warning in an awk statement that was
  causing the autopkgtest's lint check to fail.  I fixed the warning;
  hopefully it will pass now.

* node-*: There were numerous autopkgtest regressions that were fixed by
  re-triggering against nodejs, icu, pegjs and various combinations of other
  dependencies.
  - node-chokidar
  - node-formidable
  - node-json-buffer
  - node-kew
  - node-clean-css
  - node-oauth-sign
  - node-opencv

### Still Needing Attention ###

Some notes for remaining work:

* node-node-sass:  Hits a TypeError, still needs investigated.

* node-sha.js, node-create-hash, node-crypto-browserfy:
  - See LP: #1887144

* node-xterm:  I think this needs updated to 4.x (see deb #964170).
  Debian (and Ubuntu) are on 3.8.  There seems to be some type conflict
  between Window and DOMWindow; might be due to API changes in nodejs?

* python-hypothesis: It errors on unreliable test timings.  The package
  seems to have a history of this.  I retried a couple times, but maybe
  the test should be skipped as flaky?

* gubbins: This is being built on arch: All, but depends on iqtree which
  is built only for a few arch's, so gubbins fails on other arch's.  I
  tried building iqtree with arch: All but no such luck.  Not sure what
  to do here...


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

Adjustment to df's output of squashfs mount points

[Bryce Harrington]

Happy Friday,

Just wanted to announce the change to df's output has landed in groovy's
coreutils today.

df now omits devtmpfs and squashfs filesystems, by making gnulib treat
them as 'dummy' filesystems.  This should make df's output a bit more
"crisp" for snap aficionados by excluding display of /snap/* (and /dev).

$ df -h | wc -l
42
$ sudo apt-get update
$ sudo apt-get install coreutils
$ df -h | wc -l
12

https://launchpad.net/ubuntu/+source/coreutils/8.30-3ubuntu3

This work is result of discussions with upstream.  They suggested the
approach used in this patch, so while it's not landed in their master
branch yet, this should be close to what they'll be carrying.


Some additional technical details below...

On Mon, Jun 01, 2020 at 09:12:47AM -0700, Bryce Harrington wrote:
> On Mon, Jun 01, 2020 at 09:30:58AM +0100, Iain Lane wrote:
> > On Thu, May 28, 2020 at 09:38:47PM -0700, 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.
> > 
> > We had this problem on the desktop a while ago, and we worked with the
> > snapd team to solve it by introducing an extra option on the mounts
> > which snapd creates, called "x-gdu.hide". Parts of the GNOME desktop
> > respect this, and so user interfaces are not cluttered up with snap
> > mounts.
> > 
> >   
> > https://github.com/snapcore/snapd/blob/31b6deca70ddabbc86ab2793ddf16e500ae66fde/osutil/squashfs/fstype.go#L67
> > 
> > This feels to me to be a cleaner approach than saying that *all*
> > squashfs filesystems should be hidden by default - instead, the software
> > which creates the mounts is able to communicate this fact and if you've
> > created your own mounts then you carry on seeing them as normal.
> 
> Thanks, that's a very good tip, I'll mention this to upstream.

I didn't get much discussion from upstream about use of "x-gdu.hide",
so I did some analysis myself.  This property can be accessed via
libmount, however coreutils/gnulib explicitly does not use libmount as a
dependency since it has heavy dependencies.  I'd be keen to know of
alternate ways to access this tag, because it does seem like a very
useful refinement.
 
> > There's still the question of creating an interface to hide based on
> > mount options and how to set the default. (Personally I agree with Seth
> > that the systemd style is a nice way to do it, if upstream are up for
> > that.) But this warrants consideration, I think.
> 
> It sounds like upstream is preferring to avoid config files and env
> vars, and would prefer to filter squashfs as a dummy fs (if you look at
> `df -a` output you can see there are others already being filtered.)  So
> given that I think they'll be interested in hearing about "x-gdu.hide"
> since that will more precisely target the issue we're trying to solve.

The response from upstream was to not use a config file or env var, to
avoid any security concerns, and just treat these as dummy filesystems.

Initially, they'd also considered excluding tmpfs, however there are
concerns that this would hide intentional tmpfs systems created by
users.  I suspect for Ubuntu we ought to exclude tmpfs anyway, but have
left them as-is for now.  (Perhaps something like "x-*.hide" could allow
distinguishing these.)

Bryce


> Thanks,
> Bryce
> 
> -- 
> 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: +1 maintenance June 2nd-5th

[Bryce Harrington]

On Fri, Jun 05, 2020 at 09:09:49PM +0200, Christian Ehrhardt wrote:
> On Fri, Jun 5, 2020 at 8:29 PM Bryce Harrington <
> bryce.harring...@canonical.com> wrote:
> 
> > On Fri, Jun 05, 2020 at 08:11:40AM +0200, Christian Ehrhardt wrote:
> > >  php-horde
> > >
> > > Next was a look at php-horde-* which is not only split into many packages
> > > but also has plenty of autopkgtests due to that.
> > > 10/10 tests that I checked were blocked at the same issue: "E: Package
> > > 'php-horde-test' has no installation candidate"
> > > If there is another issue, then I need this to resolve to be able to see
> > it
> > > :-)
> > >
> > > It turned out to be rather easy: php-horde-test isn't in groovy-release -
> > > not even an older version.
> > > Due to that the tests fail to find anything.
> > >
> > > 104 source packages and counting :-). The reason for all that was that
> > the
> > > status was a mixed feeling before [6] and removed from focal.
> > > It was removed from Debian as well [7] and the current flurry of
> > > builds is caused by re-uploads to bring it back.
> > > Some bits are still hanging in Debian's new queue like the core
> > "php-horde
> > > 5.2.21+debian1-1" itself.
> > >
> > > We should give it a chance now, but if it looks as bad with proper test
> > > triggers it likely should be removed until this has resolved to a proper
> > > state in Debian (gladly the package was adopted, so this will become
> > better
> > > over time).
> > >
> > > For now we can't go on, this will need to wait until php-horde passes the
> > > new queue and is in groovy-proposed.
> > > Then we want to run something like the following to properly restart the
> > > tests.
> > >
> > >   $ wget
> > >
> > https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html
> > >   $ for p in $(grep -Hrn '>php-horde-.* (- to php-horde-/php-horde-/' | sed -e
> > > 's/<\/a>.*//' ); do retry-autopkgtest-regressions --series groovy
> > --blocks
> > > "${p}"; done | sed -e
> > >
> > 's/$/=php-horde-test%2F2.6.3%2Bdebian0-5=php-horde%2F5.2.21%2Bdebian1-1/'
> > >
> > > ---
> > >
> > >  php-horde
> > >
> > > Still waiting in Debian new queue, due to that still nothing to do.
> >
> > php-horde was dropped in focal, and should be for groovy as well, and
> > blacklisted:
> >
> >   https://bugs.launchpad.net/ubuntu/+source/php-horde/+bug/1880776
> >
> > php-horde-* wraps a vast number of other system packages, so whenever
> > there are any changes in plumbing, invariably some chunk of php-horde
> > ends up broken.  We don't see a high enough usage of php-horde to
> > warrant the effort maintaining it has been taking.
> >
> 
> 
> Hi Bryce,
> thanks for the background.
> I remember and even read the old removal bug when looking at the case this
> week.
> I thought we could give it a chance if it is better now, but I'm fine to
> remove it if that is still the right thing to do.
> So you are saying we should re-remove and more actively block further
> syncing then?
> I can do so next week, just please confirm to me that this is the path to
> go on this.

Yes, that's what I recommend - re-remove it and actively block it from
being sync'd back in.

It's been a frequent visitor to update-excuses, and given that it's not
widely used, it's consuming engineering attention that'd be better
focused on more pressing matters.

Bryce


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

Re: +1 maintenance June 2nd-5th

[Bryce Harrington]

On Fri, Jun 05, 2020 at 08:11:40AM +0200, Christian Ehrhardt wrote:
>  php-horde
> 
> Next was a look at php-horde-* which is not only split into many packages
> but also has plenty of autopkgtests due to that.
> 10/10 tests that I checked were blocked at the same issue: "E: Package
> 'php-horde-test' has no installation candidate"
> If there is another issue, then I need this to resolve to be able to see it
> :-)
> 
> It turned out to be rather easy: php-horde-test isn't in groovy-release -
> not even an older version.
> Due to that the tests fail to find anything.
> 
> 104 source packages and counting :-). The reason for all that was that the
> status was a mixed feeling before [6] and removed from focal.
> It was removed from Debian as well [7] and the current flurry of
> builds is caused by re-uploads to bring it back.
> Some bits are still hanging in Debian's new queue like the core "php-horde
> 5.2.21+debian1-1" itself.
> 
> We should give it a chance now, but if it looks as bad with proper test
> triggers it likely should be removed until this has resolved to a proper
> state in Debian (gladly the package was adopted, so this will become better
> over time).
> 
> For now we can't go on, this will need to wait until php-horde passes the
> new queue and is in groovy-proposed.
> Then we want to run something like the following to properly restart the
> tests.
> 
>   $ wget
> https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html
>   $ for p in $(grep -Hrn '>php-horde-.* (- to php-horde-/php-horde-/' | sed -e
> 's/<\/a>.*//' ); do retry-autopkgtest-regressions --series groovy --blocks
> "${p}"; done | sed -e
> 's/$/=php-horde-test%2F2.6.3%2Bdebian0-5=php-horde%2F5.2.21%2Bdebian1-1/'
> 
> ---
> 
>  php-horde
> 
> Still waiting in Debian new queue, due to that still nothing to do.

php-horde was dropped in focal, and should be for groovy as well, and
blacklisted:

  https://bugs.launchpad.net/ubuntu/+source/php-horde/+bug/1880776

php-horde-* wraps a vast number of other system packages, so whenever
there are any changes in plumbing, invariably some chunk of php-horde
ends up broken.  We don't see a high enough usage of php-horde to
warrant the effort maintaining it has been taking.

Bryce

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

[Bryce Harrington]

On Mon, Jun 01, 2020 at 09:30:58AM +0100, Iain Lane wrote:
> On Thu, May 28, 2020 at 09:38:47PM -0700, 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.
> 
> We had this problem on the desktop a while ago, and we worked with the
> snapd team to solve it by introducing an extra option on the mounts
> which snapd creates, called "x-gdu.hide". Parts of the GNOME desktop
> respect this, and so user interfaces are not cluttered up with snap
> mounts.
> 
>   
> https://github.com/snapcore/snapd/blob/31b6deca70ddabbc86ab2793ddf16e500ae66fde/osutil/squashfs/fstype.go#L67
> 
> This feels to me to be a cleaner approach than saying that *all*
> squashfs filesystems should be hidden by default - instead, the software
> which creates the mounts is able to communicate this fact and if you've
> created your own mounts then you carry on seeing them as normal.

Thanks, that's a very good tip, I'll mention this to upstream.

> There's still the question of creating an interface to hide based on
> mount options and how to set the default. (Personally I agree with Seth
> that the systemd style is a nice way to do it, if upstream are up for
> that.) But this warrants consideration, I think.

It sounds like upstream is preferring to avoid config files and env
vars, and would prefer to filter squashfs as a dummy fs (if you look at
`df -a` output you can see there are others already being filtered.)  So
given that I think they'll be interested in hearing about "x-gdu.hide"
since that will more precisely target the issue we're trying to solve.

Thanks,
Bryce

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

[Bryce Harrington]

On Fri, May 29, 2020 at 10:54:40PM +, Seth Arnold wrote:
> On Thu, May 28, 2020 at 09:38:47PM -0700, Bryce Harrington wrote:
> > For Ubuntu, DF_EXCLUDE_FSTYPES could be set in the global profile (under
> > /etc/profile.d/ perhaps?)  This would make it straightforward to add
> 
> Many thanks for working on this, df output has been annoying me for quite
> some time (but I dislike shell aliases even more).
> 
> Properly threading an environment variable into a given process is
> surprisingly difficult. /etc/profile.d/ is read by bash, and other
> shells that choose to use these startup files. /etc/environment is
> used by any PAM service that has pam_environment configured and
> systemd-environment-d-generator(8) for systemd user manager instances.
> 
> These may not cover all instances where users would like it to. And,
> ironically, even though it doesn't cover everything, it would be in the
> memory of many processes that may never call df. It's not like it's a
> huge amount of memory, but it is something.
> 
> Different tools like sudo, su, systemd-nspawn, lxc exec, etc may
> further complicate getting an environment variable through from where a
> human is interacting with the system to where df is executing.
> 
> So, I'd like to propose using the typical systemd-style configuration file
> approach instead:
> 
> Package defaults in:
> /lib/something/coreutils/df.conf or
> /usr/lib/something/coreutils/df.conf
> 
> Sysadmin configuration in:
> /etc/something/coreutils/df.conf
> 
> User configuration in:
> XDG_SOMETHING_CONFIG/coreutils/df.conf
> or
> /run/uid/something/coreutils/df.conf
> 
> Yes, it's exhausting to implement the functionality for all this compared
> to the simplicity of a getenv() or secure_getenv(), but filesystem access
> is more predictable than environment variables from parents to children
> and will likely work closer to expectations across chroot, schroot, lxd,
> etc uses.
> 
> If we ever want to change the package defaults, then any local admin
> choices already made could continue to be respected.
> 
> Thanks

Thanks for the feedback Seth.

I haven't seen other examples of config file use elsewhere in coreutils,
which was one reason I went with an env var for this POC.

I'll bring your points forward when I present to upstream, and if they
also like the conf file approach better, I can reimplement it that way.
Is there another GNU package (in C) that implements a systemd-style
config file approach that you'd recommend to use for reference?

Bryce


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

[Bryce Harrington]

On Fri, May 29, 2020 at 10:31:56AM -0400, Sergio Durigan Junior wrote:
> On Friday, May 29 2020, Bryce Harrington wrote:
> > I've drafted a POC implementation for df here:
> >
> >   
> > https://github.com/bryceharrington/coreutils/commit/cc372d778b44abcf81af42743a5174685f9bb4db
> 
> Hey Bryce,
> 
> Overall I like the idea of using an environment variable to control this
> behaviour, but I feel compelled to raise the point of discoverability.
> 
> If the distro ships a file under /etc/profile.d/ which silently sets
> this variable for all users, and if the user is not aware of that, it
> may take her some non-trivial effort to figure out why her tmpfs mount
> is being listed by df.
> 
> I'm sure you must have thought of that, but if you go forward with the
> environment variable idea, extra care will need to be taken when writing
> the documentation for it.  Perhaps (and that's a big "perhaps"; I
> haven't thought much about it) it's even worth mentioning somehow that
> DF_EXCLUDE_FSTYPES is being used in the output of df,

It's a good point.  My plan is to mention it in --help, and also add an
ENVIRONMENT section to the df man page, since at least to me that'd be
the second and third places I'd look (the first being google
obviously...)  I notice that df has a couple other environment variables
(POSIXLY_CORRECT and DF_BLOCK_SIZE) mentioned in --help but not the man
page, which could go in as well.

This is probably too low-level to be worth including in the Groovy
release notes, but I can propose a sentence or two just for some extra
visibility.

> or having a new
> "--full-output" option (or some such) that would ignore the variable and
> print everything.

There is a 'df --all' option that sounds like it should suit that need.
Thanks for raising this idea -- in testing it I notice the new code
isn't honoring it.  I'll add a check to skip the env var if -a,--all is
specified.

> I kind of like the idea of a configuration file, but I agree that an
> environment variable is more flexible.  Also, I don't think the creation
> of a configuration file would be justified for just this single option.

Yeah, those were my thoughts as well.  df itself doesn't currently use a
config file, but I wonder if coreutils itself has something.

> Let me know when you submit the patch upstream; I'm interested in
> following the discussions :-).

Sure thing,
Bryce

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

[Bryce Harrington]

On Fri, May 29, 2020 at 11:15:27AM -0300, Rafael David Tinoco wrote:
> On 29/05/2020 11:03, Robie Basak wrote:
> > +1 for Bryce's approach.
> >
> > On Fri, May 29, 2020 at 10:56:34AM -0300, Rafael David Tinoco wrote:
> >> Perhaps this environment variable should be set by snapd package ?
> > I think this could be surprising - because we would be hiding all
> > squashfs filesystems from df, not just snapd ones. I think it would be
> > cleaner to consider that users don't generally want to see squashfs
> > stuff in df output by default anyway, and so hide it Ubuntu-wide.
> >
> > I'm less sure about tmpfs. I can think of occasions where I have wanted
> > to see tmpfs usage (since it can run out, and has run out on me before).
> > But that's perhaps too much of a specialist case, and so I think it's
> > also OK to hide tmpfs by default from df on Ubuntu.
> I'm wondering if having an optarg to disconsider the environment
> variable would be appropriate. And sorry if that was already considered
> Bryce, I haven't looked into your code.

I didn't include a cli arg, but that effect can be achieved by:

$ DF_EXCLUDE_FSTYPES= df

I did make sure the env var plays well with -t, so if you *just* want to
see tmpfs and squashfs filesystems, for instance, then this would do it:

$ df -t tmpfs -t squashfs

(Note that if you've aliased df to 'df -x tmpfs' this will break if you
try to also -t tmpfs; those options are mutually exclusive, and df will
error.)

You can also get df to display everything, including normally hidden
filesystems via:

$ df -a

For my desktop this shows 79 entries, including cgroup and nsfs stuff
(that apparently snap uses) which aren't shown by default.  The -T flag
is handy to use with -a to help figure out what's what.

$ df -a -T

Thanks for the feedback,
Bryce


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

Adjusting what fstypes df displays

[Bryce Harrington]

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?

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:

https://bugs.launchpad.net/charm-nagios/+bug/1827159

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

Re: PHP 7.4 in Focal

[Bryce Harrington]

On Fri, Mar 27, 2020 at 08:32:54AM +, Mark Shuttleworth wrote:
> On 26/03/2020 18:47, Bryce Harrington wrote:
> > The in-archive transition from PHP 7.3 to PHP 7.4 is complete.  I expect
> > PHP 7.3 will be removed from Focal soon.
> >
> > PHP 7.4 is a new feature update, bringing typed properties, arrow
> > functions, weak references, and unpacking inside arrays among other
> > things.  For more information on the new features and improvements, see
> > the PHP 7.4 Release Announcement[0].
> >
> 
> Just want to say thank-you to everyone who is contributing to 20.04 LTS
> with such grace under pressure. Also, a shout-out to the ways open
> source is enabling rapid response in communities and between volunteers
> supporting health and medical professionals globally.
> 

Thanks, and you're right - it's humbling and inspiring to see the
consistency of execution everyone in the company is showing right now.
20.04 is going to be an amazing release.

It was prescient to establish Canonical as a remote oriented company.
In this time of so much change, many companies are needing the same
capability right now, and it's wonderful to be part of a company that is
able to provide that expertise, and in this way help the world.

Thank you Mark, for leading us in this time of trouble, and ensuring we
have such a great place to work.

Bryce

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

PHP 7.4 in Focal

[Bryce Harrington]

The in-archive transition from PHP 7.3 to PHP 7.4 is complete.  I expect
PHP 7.3 will be removed from Focal soon.

PHP 7.4 is a new feature update, bringing typed properties, arrow
functions, weak references, and unpacking inside arrays among other
things.  For more information on the new features and improvements, see
the PHP 7.4 Release Announcement[0].

Deprecated features include:

  - Nested ternary operations must explicitly use parentheses to dictate
the order of the operations. Previously, when used without
parentheses, the left-associativity would not result in the expected
behaviour in most cases.

  - The array and string offset access syntax using curly braces is
deprecated. Use $var[$idx] instead of $var{$idx}.

  - The (real) cast is deprecated, use (float) instead. 

  - The is_real() function is also deprecated, use is_float() instead.

  - Unbinding $this of a non-static closure that uses $this is deprecated.

  - Using parent inside a class without a parent is deprecated.

  - The allow_url_include ini directive is deprecated.

  - Passing invalid characters to base_convert(), bindec(), octdec() and
hexdec() will now generate a deprecation notice.

  - Using array_key_exists() on objects is deprecated.

  - The following functions are deprecated:
+ get_magic_quotes_gpc()
+ get_magic_quotes_runtime()
+ hebrevc()
+ convert_cyr_string()
+ money_format()
+ ezmlm_hash()
+ restore_include_path()

For more details about deprecated functionality, and suggested
replacements, see the PHP 7.4 Deprecated Features page[1].

Migration guides to 7.4 from 7.3[2] or earlier versions of PHP are also
available in the PHP Manual.

Users coming from Ubuntu 18.04 will be moving from 7.2 to 7.4, so should
also refer to the Migration guides to 7.3 from 7.2[3]

Note as well that phpunit has been undergoing a transition from 7.5.6 to
8.5.2, which changes behavior for functionality used in some test cases.

Bryce

0: https://www.php.net/releases/7_4_0.php
1: https://www.php.net/manual/en/migration74.deprecated.php
2: https://www.php.net/manual/en/migration74.php
3: https://www.php.net/manual/en/migration73.php

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

Re: Upcoming PHP 7.4 transition

[Bryce Harrington]

On Fri, Feb 14, 2020 at 10:30:31AM -0800, Bryce Harrington wrote:
> On Fri, Feb 14, 2020 at 09:52:34AM +0100, Julian Andres Klode wrote:
> > On Thu, Feb 13, 2020 at 05:33:21PM -0800, Bryce Harrington wrote:
> > > Hi devs,
> > > 
> > > For focal the server team will be transitioning PHP to 7.4 over the
> > > coming weeks.
> > > 
> > > Since version 7.0, upstream PHP has adopted a regular release cadence,
> > > with one release per year. Each release is supported for 2 years, plus a
> > > third year of security critical fixes.[1] Changes from 7.3 to 7.4 are
> > > modest, but the extra year of upstream support is a tangible benefit for
> > > the Ubuntu LTS.
> > > 
> > > The language binary, php7.4, is already sync'd to universe in focal.
> > > Remaining parts of the stack are in process by Debian, but are expected
> > > to enter experimental/universe soon.  Initial build testing shows the
> > > changes that have been queued in Debian's git package repos have
> > > addressed most build issues, and will simply need synced/merged.
> > 
> > It's stuck in proposed due to failing autopkgtests of reverse
> > dependencies, and it also depends on the icu transition. Hopefully
> > icu is done soon, I guess I'd wait for this first before entangling
> > another transition into it.
> 
> Thanks for the head's up, I'll keep an eye on when it migrates.
> 
> > I have added a transition tracker for php7.4.
> 
> Great, thanks.

Btw, if you want to update the linked ticket for that tracker, the lp
bug report I'm using for tracking this is
https://bugs.launchpad.net/ubuntu/+source/php-defaults/+bug/1855020/

Bryce

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

Re: Upcoming PHP 7.4 transition

[Bryce Harrington]

On Fri, Feb 14, 2020 at 09:52:34AM +0100, Julian Andres Klode wrote:
> On Thu, Feb 13, 2020 at 05:33:21PM -0800, Bryce Harrington wrote:
> > Hi devs,
> > 
> > For focal the server team will be transitioning PHP to 7.4 over the
> > coming weeks.
> > 
> > Since version 7.0, upstream PHP has adopted a regular release cadence,
> > with one release per year. Each release is supported for 2 years, plus a
> > third year of security critical fixes.[1] Changes from 7.3 to 7.4 are
> > modest, but the extra year of upstream support is a tangible benefit for
> > the Ubuntu LTS.
> > 
> > The language binary, php7.4, is already sync'd to universe in focal.
> > Remaining parts of the stack are in process by Debian, but are expected
> > to enter experimental/universe soon.  Initial build testing shows the
> > changes that have been queued in Debian's git package repos have
> > addressed most build issues, and will simply need synced/merged.
> 
> It's stuck in proposed due to failing autopkgtests of reverse
> dependencies, and it also depends on the icu transition. Hopefully
> icu is done soon, I guess I'd wait for this first before entangling
> another transition into it.

Thanks for the head's up, I'll keep an eye on when it migrates.

> I have added a transition tracker for php7.4.

Great, thanks.

Bryce


> -- 
> debian developer - deb.li/jak | jak-linux.org - free software dev
> ubuntu core developer  i speak de, en

> -BEGIN PGP SIGNATURE-
> 
> iQIzBAABCgAdFiEET7WIqEwt3nmnTHeHb6RY3R2wP3EFAl5GX88ACgkQb6RY3R2w
> P3HiWQ//TF9iY6EHEIX4RpUCZaBrpqQe1XW5u+JXH19UeTDlKfvsv4Mf/nS6msLl
> lrnSUPda84gTNnwilKi6pdeVrUnL2PegBJioZtHIamXJXUsaD1SqjkQ1lXqt1gXG
> af3GqLdE8CfFfVRVGUCT0XwGX7mntPOGKMx3uc9Xcy4id4pp12GAZHGpZHCRSvsR
> ZT1BaoBkGLKdLkhbo5zYI4UvIDEZsOqIKnZAmAs9/ysSNlySB65iFdrCvxcCKqYr
> euDtvZ/jjAlHdl/9t9QN/KhOEKAhyfm5QocLs0+Z04eFrMT7w8LoIujG/vMkfNT4
> GVkVYqeTmU1AyYCZ+F/zoXUNA0hRPZXLCek5P1DM4m/9hsRCe9irKmsqoPmb7AwK
> GziLlw/Uekkv74vwYs2AqicB+tkWLLMKORhyrP+40u8OhEHgRRIimZ9QrY51Hzwl
> vPcSQDuGdFpVkvIqK6GRFSbBjLMoo+L6d7U0YayC25nLL7iuC3OiucFf25h3J+6i
> rhiqN+djzvKdTQF3LjfVsnvR5daW4C7ME7a/HRN3IdVphTqqYLBAdLM3PDsbFb+G
> XYev32LBt8vauDWWkyel/nFD2w2FW1NafA5n3eTvq/ouSQqWA/KL7NHowpF7fMt8
> J86V1xt2vUU2J0PPWxXhHM75Txu25paLOgqb1So/lKxlOTywfW0=
> =e+p9
> -END PGP SIGNATURE-


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

Upcoming PHP 7.4 transition

[Bryce Harrington]

Hi devs,

For focal the server team will be transitioning PHP to 7.4 over the
coming weeks.

Since version 7.0, upstream PHP has adopted a regular release cadence,
with one release per year. Each release is supported for 2 years, plus a
third year of security critical fixes.[1] Changes from 7.3 to 7.4 are
modest, but the extra year of upstream support is a tangible benefit for
the Ubuntu LTS.

The language binary, php7.4, is already sync'd to universe in focal.
Remaining parts of the stack are in process by Debian, but are expected
to enter experimental/universe soon.  Initial build testing shows the
changes that have been queued in Debian's git package repos have
addressed most build issues, and will simply need synced/merged.

Let me know if there are questions/concerns.  Otherwise we will plan to
initiate the transition within the next week or so.

Bryce

1: https://www.php.net/supported-versions.php


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

Re: Reconsidering Ubuntu bug-filing redirection

[Bryce Harrington]

On Mon, Oct 14, 2019 at 12:13:30PM +0100, Colin Watson wrote:
> About ten years ago [1] [2], Launchpad was changed so that, if people
> try to file a bug on Ubuntu directly via the web, then they're instead
> redirected to https://help.ubuntu.com/community/ReportingBugs which
> explains how to file a bug using the appropriate tools.  Some way down,
> this explains how to file bugs manually and bypass this redirection.
> 
> At the time, this change was described as an experiment.  I think it's
> worth having a look at this and seeing if we can tweak it to reduce some
> sources of frustration.
> 
> I think we could consider other approaches in the Launchpad UI to give
> people a nudge towards good local bug-reporting tools while being
> slightly less user-hostile to people who know what they're doing about
> bugs in general but not about Ubuntu's processes.  I have two specific
> independent ideas that I'd like to submit for consideration:
> 
>  * Rearrange the UX for reporting bugs on Ubuntu as a non-member of
>~ubuntu-bugcontrol so that it presents the reference to ReportingBugs
>and the advice to use ubuntu-bug in a way that's hard to ignore but
>that can still be skipped.

Back in 2010 there was some discussion on this issue, and Deryck Hodge
had a proposal to make the UX follow a "Your bug is X% complete" style,
maybe conceptually similar to this suggestion, which was captured as a
"Bugs Q" story:

https://dev.launchpad.net/Bugs/BugQ%26A

Fairly rough concept there, but apparently was included for the LP 4.0
roadmap (https://dev.launchpad.net/VersionFourDotO/Stories).

Bryce

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

Re: reflecting on first UDS session on rolling releases

[Bryce Harrington]

On Wed, Mar 06, 2013 at 02:19:52PM +, Matthew Paul Thomas wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 Michael Hall wrote on 06/03/13 00:41:
  
  On 03/05/2013 06:49 PM, Allison Randal wrote:
  
  There were a few things that concerned me in today's session on 
  cadence of rolling releases:
  
  http://summit.ubuntu.com/uds-1303/meeting/21683/community-1303-rolling-release/
 
 
  
 But, the biggest was at the very end when System76 said that two
  years is too long between releases for their customers, but that
  they were willing to at least *try* the new rolling releases. The
  reply was that the rolling releases weren't expected to be stable
  enough to deliver to customers. This surprised me, since
  stability is exactly the purpose of rolling releases.
 
 This was the argument System76's Carl Richell gave against two-yearly
 releases: I don't think Windows or OS X or Chrome OS are going to
 release in such a long time. And I'd also look at 11.04, for instance.
 If we installed 11.04 on our computers, and used it for a week, is
 that how we would want Ubuntu represented commercially? Because that
 would be the result of a two-year release cycle.
 http://www.youtube.com/watch?v=4FN_S9PoMC8#t=1m24s
 
 I don't understand the first part of that argument. Windows 7 and 8
 were, actually, both released two years after the previous version. OS
 X had 18-to-24-month releases for over a decade, switching to yearly
 releases only with 10.7 and 10.8. And Chrome OS has little UI or APIs
 of its own, so (I assume) it has less difficulty in keeping stable
 in any sense of the word.

He means not just the core OS but also the application ecosystem.  In
Windows the OS release is just the core OS, and then users manually
install newer versions of whatever applications they want.

(I would argue that any software project that has their act together
will have .debs for the LTS downloadable from their web site or a PPA,
or even via -backports, so in practice this isn't that different.
However, I believe that was the distinction he was drawing.)
 
Bryce

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

X.org 1.14 and RR / 13.04 (un-)plans

[Bryce Harrington]

Xserver 1.14 was released upstream today.  We are maintaining this new X
stack in a PPA for anyone interested in testing on it:

  https://launchpad.net/~canonical-x/+archive/x-staging

We've decided to hold off on putting this into raring for now.  But we
probably will let the mesa 9.1 update through.


We've been testing the rc candidates of xserver 1.14 up 'til now, and
have found it to be generally pretty solid.  However, it does introduce
an ABI change which necessitates updates of proprietary drivers, and
pointer barriers have changed implementation, which has required changes
to Unity.  For the proprietary drivers, -nvidia now has a compatible
release we can provide, but we're still awaiting updates for -fglrx and
-tegra.  For Unity, we include the fix in the PPA above, but it's not in
the general archive yet.

For these reasons, and in the general interest of avoiding disrupting
folks working on phone/tablet, we're going to hold off on uploading
xserver to the archive for a month or two.  We may end up skipping
1.14.0 entirely and wait for 1.14.1, but we'll see.

Mesa 9.1, on the other hand, doesn't impact things quite so bad, and
brings in EGL improvements that may help phone and mir, as well as a
slew of fixes that we think/hope will solve some of the GPU lockups
people are currently experiencing.  We want to do a bit more
review/testing but we'll likely upload this in the next week or two.
There is no transition needed for this, and it won't cause any
disruption to users (other than maybe the odd minor regression or so).

I don't know if we're officially doing a 13.04 Ubuntu release or not,
but if we do that means we would stick with the current 1.13.x Xserver
series for that, but update to mesa 9.1.  It sounds like 1.13 will
continue being actively supported upstream, so this seems like a sound
option.  Since we ship 1.13.x in both quantal and the 12.04 update
stack, it would make SRUs slightly simpler as well.

I'm hopeful this will enable us to make the current X stacks that much
more stable for everyone.  We're also starting to balance our time
between X and Mir, so if this gives us any extra time then we can
contribute help towards Mir development.

Meanwhile, we're also looking into ways we can improve our deployment of
driver updates for -nvidia and -fglrx to stable Ubuntu releases.  Our
new process for rolling out updates has been working out well for users,
except that it's just too slow.  We're looking into how we can remove
bottlenecks so the updates get out to users faster, and then see if we
can scale up the volume of updates we can do.  This is geared to help
game vendors that want users to have access to the latest drivers, for
example.


Finally, if you do install the x-staging PPA linked above to run the
newer xserver, please feel free to file bug reports normally, and we'll
follow up on the issues.

Bryce

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

Re: taking Unity to the next level

[Bryce Harrington]

On Mon, Mar 04, 2013 at 01:39:36PM -0500, Scott Kitterman wrote:
 On Monday, March 04, 2013 05:46:54 PM Oliver Ries wrote:
  Hi,
  
  I wanted to give you a quick heads up regarding Unity in preparation of
  this weeks UDS.
  
  The traction that Ubuntu Touch is creating is great and the team is
  happy with where this is leading us. However, in order to implement the
  vision of converged devices, some changes to our Display Stack are
  necessary.
  
  After thorough research, looking at existing options and weighing in
  costs  benefits we have decided to roll our own Display Server, Mir
  (rf. http://wiki.ubuntu.com/MirSpec).
  
  None of the existing solutions would allow us to implement our vision
  without taking major compromises which would come at the cost of user
  experience and quality. We will be running sessions at UDS to discuss
  questions and take feedback.
  
  Also, driven by Ubuntu Touch we are starting to move Unity over to a
  Qt/QML based implementation, embracing Qt as a community backed
  technology for our offerings. We are looking at tackling the transition
  from the Nux based implementation to a Qt/QML based implementation
  component by component and are striving to do that in a transparent way
  for the user. This topic is also up for discussion at UDS and we are
  providing a spec at http://wiki.ubuntu.com/UnityNextSpec.
  
  I am providing more context about these topics at
  http://www.olli-ries.com/mir-unity-qml-unity-apis-unity .
  
  Please feel free to reach out to us during UDS and later on to discuss
  any questions.
 
 Does that mean that after next  April, the X stack and Wayland will no longer 
 be maintained by Canonical, so that flavors that are using a standard display 
 stack are on their own?

Wayland is not maintained by Canonical currently.  We do package it, as
it's required by mesa and some other projects, and that'll likely
continue as is.  Ideally we just sync it from Debian.

The X.org stack itself will probably be around for a good long while,
since legacy apps will need it for their rootless X sessions, and for
cases where Mir doesn't work right.  Our level of maintenance efforts
there will probably taper off over time in favor of Mir, though, maybe
to the point we're just syncing from Debian.  So yes for flavors staying
on X.org bases may need to be more involved in tending to their
foundation, but you'll likely always have the Debian base to build from
which I expect should be solid for as long as X11 remains relevant.

Bryce

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

Re: taking Unity to the next level

[Bryce Harrington]

On Mon, Mar 04, 2013 at 03:35:21PM -0500, Scott Kitterman wrote:
 On Monday, March 04, 2013 11:45:57 AM Bryce Harrington wrote:
  On Mon, Mar 04, 2013 at 01:39:36PM -0500, Scott Kitterman wrote:
   On Monday, March 04, 2013 05:46:54 PM Oliver Ries wrote:
 citizens in the long run.  Also, one of the advantages that being part of 
 Ubuntu brings to other flavors like Kubuntu is the support of new hardware 
 due 
 to Canonical's hardware enablement work.  Sync'ing from Debian loses us that.

Not really.  For display hardware, most of the enablement work is kernel
level stuff.  A lot of that is either backported from upstream, or else
is usually taken upstream eventually, so even if you switch to being a
Debian derivative you'd probably still benefit in the long run.

Bryce

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

Re: Let's Discuss Interim Releases (and a Rolling Release)

[Bryce Harrington]

On Thu, Feb 28, 2013 at 10:59:36AM -0600, Mario Limonciello wrote:
 Thanks Rick.  I applaud this proposal.
 
 This definitely helps to reaffirm the decision that we made with Mythbuntu
 to move to LTS only for our releases.  We have had an incredibly positive
 response within our sub-community with the decision.
 
 I look forward to hearing more about how this will affect the point
 releases for LTS though.  Currently LTS point releases are bringing in HW
 backports from the previous 6 month release.  Will they keep a similar
 schedule and pick up the current development release snapshot?

Yes, that would be a good discussion to have at this point.

The reason we do the HW backports is to ensure the LTS remains relevant
on the latest hardware.  If anything, it seems to me that this is going
to be twice as important as before, since we're shifting to rely even
more heavily on the longevity of the LTS.

That said, we may need to rethink the processes for how these are done.
I'd like to hope we could stay reasonably close to the original plan,
with some tweaks to account for our move to RR, at least through to the
14.04 LTS, but putting together the HW backports involves a lot of
people, so it would make sense to have a discussion on this topic next
week.

Bryce

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

Patch Pilot - Feb 28, 2013

[Bryce Harrington]

Removed from sponsors queue (WIP/unsubbed) due to issues needing resolved:
* 
https://code.launchpad.net/~danilo/ubuntu/raring/command-not-found/python2-package/+merge/149494
* 
https://code.launchpad.net/~logan/ubuntu/raring/piuparts/0.49ubuntu1/+merge/149918
* 
https://code.launchpad.net/~israeldahl/ubuntu/raring/lmms/lmms_0.4.13_raring/+merge/150566
* https://bugs.launchpad.net/ubuntu/+source/rp-pppoe/+bug/705880

Removed from sponsors queue due to already being done:
* https://bugs.launchpad.net/ubuntu/+bug/1126433
* https://bugs.launchpad.net/ubuntu/+source/twpsk/+bug/1134242
* https://bugs.launchpad.net/ubuntu/+source/twclock/+bug/1134240

Upload sponsored:
* https://bugs.launchpad.net/ubuntu/+source/libx11/+bug/1129389
* https://bugs.launchpad.net/ubuntu/+source/sqsh/+bug/1134233

32 at start, 23 at end

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

Patch Pilot for Jan 31, 2013

[Bryce Harrington]

Removed from queue since needs fixing:
 * 
https://code.launchpad.net/~qrilka/ubuntu/precise/libvirt/libvirt-fix-1092826/+merge/141163
 * 
https://code.launchpad.net/~roger.light/ubuntu/quantal/mosquitto/fix-972389/+merge/141467
 * 
https://code.launchpad.net/~serialorder/ubuntu/precise/coolkey/fixmOldCACAssertError/+merge/14
 * 
https://code.launchpad.net/~bkerensa/ubuntu/quantal/xorg-server/quantal-proposed-1104209/+merge/144824
 * https://bugs.launchpad.net/ubuntu/+source/libqglviewer/+bug/1096852
 * 
https://bugs.launchpad.net/ubuntu/+source/fusioninventory-for-glpi/+bug/844868
 * https://bugs.launchpad.net/ubuntu/+source/curl/+bug/108
 * 
https://code.launchpad.net/~psusi/ubuntu/quantal/gparted/drop-swraid/+merge/143168
 * https://bugs.launchpad.net/ubuntu/+source/gnome-settings-daemon/+bug/1065979

Closed as disapproved:
 * 
https://code.launchpad.net/~surfacepatterns/ubuntu/quantal/rtmidi/add-alsa-support/+merge/141471
 * 
https://code.launchpad.net/~xnox/ubuntu/raring/ubuntuone-client/fix-apport/+merge/145758

Branch merged and uploaded:
 * 
https://code.launchpad.net/~arges/ubuntu/precise/iptables/fix-lp982961/+merge/145941
 * 
https://code.launchpad.net/~arges/ubuntu/quantal/iptables/fix-lp982961/+merge/145942

Might be done, but asked for clarification:
 * lp:~arges/ubuntu/oneiric/whois/fix_lp943502
 

Started with 55 items, 48 at end.

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

Re: Screen orientation and backlight sensing for the Nexus 7

[Bryce Harrington]

On Fri, Jan 18, 2013 at 12:36:00PM +0100, Oliver Grawert wrote:
  However, to prevent adding yet another daemon with non-negligible memory 
  footprint (~1.8M), I think behavior and various thresholds should be 
  configurable in the Control Center GUI and the functionality added to one 
  or several of the existing daemons written in C.
  AFAIK there are no generic kernel and userland APIs for such sensors, 
  save for device specific sysfs knobs so this may be a good opportunity to 
  think about how to expose such hardware features in a device independent 
  manner in the future.
  
  Thoughts?
 
 while i think that ambient light detection and rotation should be
 separated and implemented as gnome-settings-daemon modules and that we
 should additionally have something event driven from the kernel side
 instead of polling, i also think that this is quite a huge
 implementation task and feature freeze isn't so far out anymore ...

Yes, getting things accepted into g-s-d upstream might be too time
consuming to make it by FF.  I'm betting this is not something we'd want
to carry permanently as a distro patch, so we'd want to get it upstream
at some point.

 i think we should go with the standalone daemon for the moment, add some
 cmdline/conffile ways for configuration (feature on/off at least) and
 work out proper blueprints for 13.10. that way we have the function in
 place asap and can collect and fix bugs for it in 13.04, this will make
 sure that we have the underlying bits fully in place for 13.10 and can
 concentrate on the split into modules and UI elements...
 
 the size is indeed a bit concerning and it would be better to just have
 it in plain C unless the go binaries can be made smaller

Would bash or python be ok?  I'm guessing this isn't performance
critical, and it looks like everything in nexus.go could be done in
either of those languages.

Btw, I've put the xrotate script into the xdiagnose package, so we can
drop it from the nexus7 image.  Work on generalizing it for other
devices is ongoing, and I'd be open to keeping it either in bash or
rewriting it into python.

Bryce




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

Re: Minutes from the Ubuntu Kernel Team meeting, 2013-01-15

[Bryce Harrington]

On Tue, Jan 15, 2013 at 12:10:37PM -0500, Joseph Salisbury wrote:
 === Status: Raring Development Kernel  ===
  We have rebased the Raring kernel to the latest v3.8-rc3 upstream
  kernel and uploaded last week.  Please test and let us know your
  results.

A few people have come to us about new GPU lockups they're seeing.  
See bug 1099394 for instance.

Bryce

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

Re: Intel SNA in Raring

[Bryce Harrington]

On Fri, Jan 04, 2013 at 08:09:49PM +0100, Gökçen Eraslan wrote:
 Hello,
 
 Today, I have tried a Raring daily build and realized that UXA is still
 being used as the default acceleration method for
 xserver-xorg-video-intel (dh_auto_configure -- --enable-sna --enable-uxa
 --with-default-accel=uxa).
 
 Why isn't SNA preferred in alpha Raring? Isn't the alpha period best
 time to test and fix SNA bugs?

SNA has been under very active development the past couple years.  We've
been monitoring (and testing) this development, and providing it as an
opt-in option for users who wish to use it.  We evaluated enabling it
last cycle but were not certain about its stability across a wide
breadth of card models.

We likely will try again this cycle.  We are planning on an X.org stack
update rather late in the cycle, and if we include SNA we believe it
will be most stable with that stack; thus the lack of attention we've
given it right now - any testing we do now would have to be redone with
the newer code anyway.

If you want to help, one thing you can do right now is to install the
xorg-edgers PPA, enable SNA, and report any SNA-specific bugs you find
to upstream.

Thanks,
Bryce


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

Re: Minutes from the Developer Membership Board meeting of the 1st of November (at UDS)

[Bryce Harrington]

On Sun, Nov 18, 2012 at 07:55:33PM -0500, Stéphane Graber wrote:
 A new Xorg packageset was created:
 http://people.canonical.com/~stgraber/package_sets/raring/xorg and
 Maarten was added to it as an uploader.

The list of packages ubuntu-x tends will generally vary over time.  We
track the packages we tend via the package subscriptions of the ubuntu-x
team.  Will someone be periodically comparing that list with the package
set, and updating the set when there are discrepencies?

Bryce


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

Re: [ubuntu-x] xorg package set update for lts

[Bryce Harrington]

On Mon, Nov 19, 2012 at 02:09:27PM +0100, Maarten Lankhorst wrote:
 Op 12-11-12 11:50, Maarten Lankhorst schreef:
  Hey,
 
  Could the xorg package set be updated to include the following packages, 
  for the lts point release?
 
  libdrm-lts-quantal
  mesa-lts-quantal
  xorg-server-lts-quantal
  xorg-lts-quantal
 add wayland-lts-quantal to the list too.
  
 
  Lets get more into details now, since I think most technical issues have 
  been worked out now, so
  I think this can be uploaded soon after verifying it works locally.
 
  Needs to be updated in precise, for building:
   apt, for switching stacks https://launchpad.net/bugs/1062503
   x11proto-gl, from quantal for xserver
   x11proto-dri2, from quantal for xserver
   x11proto-randr, from quantal for xserver
   wayland, from quantal for mesa 9.
 Looks like wayland decided on breaking abi for their 0.99 release, so it's 
 going into the rename bin instead.
 
 Makes my life easier though, renaming is slightly more work but less chance 
 of breaking stable.

Sounds good.
 
 Now how do I get the paperwork in place for getting the x11proto and apt 
 updates to precise?
 It's blocking the upload to precise-proposed right now.

Answered on IRC, but basically sounds like both cases can be handled as
regular SRUs.  Find an SRU admin to work with and they can give guidance
on specifics that they'll need.

Offhand, both sound like viable changes to SRU, so hopefully it'll go
smoothly.  If you run into problems or if it drags on to  1 week, let
me know.

Bryce

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

Patch Pilot Report: 2012 Nov 16

[Bryce Harrington]

I focused on several of the X.org items in the queue.  Some were a bit
involved and took most of the time.  There were 92 items at the start of
my day.

https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1069031
 * Patch looks fine.  Merged into git, uploaded to raring
 * SRU'd to quantal

https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1041063
 * Cherrypick of upstream patch.
 * SRU'd to quantal
 * SRU'd to precise

https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-nouveau/+bug/1010794
 * Uploaded server fix for raring
 * SRU'd to quantal

https://code.launchpad.net/~bkerensa/ubuntu/raring/kazam/new-upstream/+merge/134426
 * Set to Work In Progress since needs additional changes

https://bugs.launchpad.net/ubuntu/+source/pmud/+bug/1077853
 * Fails to build; unsubbed sponsors

https://bugs.launchpad.net/ubuntu/+source/picard-tools/+bug/1078012
 * Fails to build; unsubbed sponsors

https://bugs.launchpad.net/ubuntu/+source/fglrx-installer-updates/+bug/1048142
 * Was already uploaded, but lacked SRU details so filled that in
 * Unsubbed sponsors since this this really belongs to the SRU team

86 items were left at the end of day.

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

Re: [ubuntu-x] New nvidia experimental driver packages coming soon for 12.04

[Bryce Harrington]

Thanks for letting us know Michael.

On Tue, Oct 16, 2012 at 08:16:55PM +0200, Michael Wisheu wrote:
 Hi Bryce,
 
 Sorry for the delay from my side. It is a busy week... I have one little
 update for you though: According to NVIDIA the issue I've mentioned should
 be fixed in 304.60 which will be released this Friday.
 
 Best,
 
 Michael
 
 Sent from phone... Please excuse typos.
 On Oct 12, 2012 6:46 PM, Bryce Harrington br...@canonical.com wrote:
 
  On Fri, Oct 12, 2012 at 05:18:33PM +0200, Michael Wisheu wrote:
   Hi Bryce,
  
   Unfortunately 1060346 is an internal bug tracking ID of NVIDIA and I also
   have no access to their bug tracker.
   In addition to that I can't use easily 'ubuntu-bug xorg' as apport is
   disabled on our company computers.
   I also don't know if it would be so helpful if I would submit that report
   as we build our own NVIDIA packages (based on X updates packages).
 
  This is good info, can you paste it into a bug report?  If you can't use
  ubuntu-bug, you can file it manually at
 
 
  https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-updates/+filebug
 
  It's helpful if you can file the bug report, because then we can contact
  you for information or to let you know when it's fixed.
 
  Bryce
 
   Thus I try to give as much details here:
  
   $ cat /proc/driver/nvidia/version
   NVRM version: NVIDIA UNIX x86_64 Kernel Module  304.51  Tue Sep 18
  17:16:56
   PDT 2012
   GCC version:  gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5)
  
   $ dpkg -l | grep nvidia
   ii  nvidia-common1:0.2.44.2
Find obsolete NVIDIA drivers
   ii  nvidia-current
   304.51-0ubuntu1~precise~xup1~gg3NVIDIA binary Xorg driver, kernel
   module and VDPAU library
   ii  nvidia-settings
304.51-0ubuntu1~precise~xup1~gg3Tool of configuring the NVIDIA
   graphics driver
   ii  nvidia-updater   1.19
Postpone NVIDIA package updates until startup
  
   $ xrandr
   Screen 0: minimum 8 x 8, current 3120 x 1920, maximum 8192 x 8192
   DVI-I-0 disconnected (normal left inverted right x axis y axis)
   DVI-I-1 connected 1920x1200+0+0 (normal left inverted right x axis y
  axis)
   518mm x 324mm
  1920x1200  60.0*+   59.9
  1600x1200  60.0
  1280x1024  75.0 60.0
  1152x864   75.0
  1024x768   75.0 60.0
  800x60075.0 60.3
  640x48075.0 59.9
   DP-0 disconnected (normal left inverted right x axis y axis)
   DP-1 connected 1200x1920+1920+0 left (normal left inverted right x axis y
   axis) 518mm x 324mm
  1920x1200  60.0*+   59.9
  1920x1080  60.0 59.9 50.0 24.0 30.0 30.0
   25.0
  1600x1200  60.0
  1280x1024  75.0 60.0
  1280x720   60.0 59.9 50.0
  1152x864   75.0
  1024x768   75.0 60.0
  800x60075.0 60.3
  720x57650.0 25.0
  720x48059.9 30.0
  640x48075.0 59.9 59.9
  
   Steps to reproduce the issue:
   1) Configure one monitor in portrait orientation
   2) xset dpms force standby
   3) Press a key or move the mouse so that the monitors leave standby
   4) Xorg crash
  
   I've also attached my Xorg.0.log.old after a crash.
   Please note that we were able reproduce this behavior on all release
   drivers between 304.43 and 304.51. This might be an issue in earlier
  3xx.xx
   drivers too.
   I hope this helps already a bit... If you need more details please let me
   know.
  
   Best,
  
   Michael
  
   PS: Wish you a nice weekend...
  
  
   On Fri, Oct 12, 2012 at 11:41 AM, Bryce Harrington br...@canonical.com
  wrote:
  
On Fri, Oct 12, 2012 at 11:14:30AM +0200, Michael Wisheu wrote:
 Hi Byrce,

 Thanks for the great explanation and I agree that it makes sense this
way.
 Please note that we've seen another bug with 304.43 and later (but
  might
 affect also earlier 304.x driver versions) on Precise that cause X
  server
 crashes under certain circumstances.
 The circumstances are:
 * Multi-monitor setup
 * At least one screen is in portrait orientation
 * X server crashes once monitors should leave standby
 * Disabling DPMS prevents the X server crashes

 NVIDIA has confirmed this issue last week and they are working on a
  fix.
 They are tracking the issue under number 1060346. There is no
  Launchpad
bug
 for this issue.
   
Thanks for letting me know about this Michael.
   
Do you have a URL for viewing the issue number 1060346, or is that an
internal bug tracker number?  If the latter, is there a forum or
  mailing
list post from NVIDIA referencing that, which we could refer to?
   
Having a Launchpad bug report to follow this would be helpful.  The
  most
useful way to file this bug would be to reproduce

Re: [ubuntu-x] New nvidia experimental driver packages coming soon for 12.04

[Bryce Harrington]

On Fri, Oct 12, 2012 at 10:18:07AM +0200, Michael Wisheu wrote:
 Hi Bryce,
 
 How about updating it to 304.51? This is mainly a bugfix release and I
 would recommend it over 304.43.
 http://www.nvidia.com/object/linux-display-amd64-304.51-driver

We actually have looked at that, but we found there's a bug[1] with
304.51 and Unity when the launcher is set to auto-hide (it never
reveals).  This was found by testers of the development release, and we
reverted nvidia-current back to 304.43 as a result.

This is a particular problem for quantal because Unity is enabling
autohide by default, so the bug affects people by default and thus is
quite severe.  For precise, Unity does not auto hide by default, so that
makes it less severe; however precise is also an LTS so stability is
all the more important and known regressions in even non-default
functionality are still worth close scrutiny.

For quantal, we'll be shipping 304.43 as the nvidia-current version.
It's quite stable and received a huge amount of testing, so I think it's
a safe choice.

In quantal, we are including 304.51 as the nvidia-current-updates
version.  It does include some worthwhile bug fixes; still, this is a
bit risky: If precise users have -updates enabled and then upgrade to
quantal, then unity will break for them.  Yet at least there are paths
to work around the bug (by going back to nvidia-current).

I've notified NVIDIA about this bug, and they've confirmed it and are
working on a fix.  So we'll have it out in quantal's
nvidia-current-updates once it becomes available and passes testing.

For precise, it probably makes sense to just skip inclusion of 304.51
for nvidia-current-updates, and wait for the fix.  SRU policy applies
here, and that tends to strongly avoid updating things if there are
known regressions such as we have in this case.

But, many precise users probably don't use Unity's autohide feature and
would like 304.51 to fix other bugs, and don't want to wait for the next
update.  We are shipping it in the x-updates PPA[2], and would encourage
these users to install from there.

Bryce

1:  https://bugs.launchpad.net/unity/+bug/1057000
2:  https://launchpad.net/~ubuntu-x-swat/+archive/x-updates


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

Re: [ubuntu-x] New nvidia experimental driver packages coming soon for 12.04

[Bryce Harrington]

On Fri, Oct 12, 2012 at 11:14:30AM +0200, Michael Wisheu wrote:
 Hi Byrce,
 
 Thanks for the great explanation and I agree that it makes sense this way.
 Please note that we've seen another bug with 304.43 and later (but might
 affect also earlier 304.x driver versions) on Precise that cause X server
 crashes under certain circumstances.
 The circumstances are:
 * Multi-monitor setup
 * At least one screen is in portrait orientation
 * X server crashes once monitors should leave standby
 * Disabling DPMS prevents the X server crashes
 
 NVIDIA has confirmed this issue last week and they are working on a fix.
 They are tracking the issue under number 1060346. There is no Launchpad bug
 for this issue.

Thanks for letting me know about this Michael.

Do you have a URL for viewing the issue number 1060346, or is that an
internal bug tracker number?  If the latter, is there a forum or mailing
list post from NVIDIA referencing that, which we could refer to?

Having a Launchpad bug report to follow this would be helpful.  The most
useful way to file this bug would be to reproduce the crash, and then on
the crashed system file the bug via 'ubuntu-bug xorg', which will
collect all the log and config files we need.  Then also reference any
and all background material (steps to reproduce, external bug #'s, forum
discussions, etc.)  Elaborating on any/all testing activity you've done
can also be invaluable.

Bryce



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

Re: [ubuntu-x] New nvidia experimental driver packages coming soon for 12.04

[Bryce Harrington]

On Fri, Oct 12, 2012 at 05:18:33PM +0200, Michael Wisheu wrote:
 Hi Bryce,
 
 Unfortunately 1060346 is an internal bug tracking ID of NVIDIA and I also
 have no access to their bug tracker.
 In addition to that I can't use easily 'ubuntu-bug xorg' as apport is
 disabled on our company computers.
 I also don't know if it would be so helpful if I would submit that report
 as we build our own NVIDIA packages (based on X updates packages).

This is good info, can you paste it into a bug report?  If you can't use
ubuntu-bug, you can file it manually at 

https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-updates/+filebug

It's helpful if you can file the bug report, because then we can contact
you for information or to let you know when it's fixed.

Bryce
 
 Thus I try to give as much details here:
 
 $ cat /proc/driver/nvidia/version
 NVRM version: NVIDIA UNIX x86_64 Kernel Module  304.51  Tue Sep 18 17:16:56
 PDT 2012
 GCC version:  gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5)
 
 $ dpkg -l | grep nvidia
 ii  nvidia-common1:0.2.44.2
  Find obsolete NVIDIA drivers
 ii  nvidia-current
 304.51-0ubuntu1~precise~xup1~gg3NVIDIA binary Xorg driver, kernel
 module and VDPAU library
 ii  nvidia-settings
  304.51-0ubuntu1~precise~xup1~gg3Tool of configuring the NVIDIA
 graphics driver
 ii  nvidia-updater   1.19
  Postpone NVIDIA package updates until startup
 
 $ xrandr
 Screen 0: minimum 8 x 8, current 3120 x 1920, maximum 8192 x 8192
 DVI-I-0 disconnected (normal left inverted right x axis y axis)
 DVI-I-1 connected 1920x1200+0+0 (normal left inverted right x axis y axis)
 518mm x 324mm
1920x1200  60.0*+   59.9
1600x1200  60.0
1280x1024  75.0 60.0
1152x864   75.0
1024x768   75.0 60.0
800x60075.0 60.3
640x48075.0 59.9
 DP-0 disconnected (normal left inverted right x axis y axis)
 DP-1 connected 1200x1920+1920+0 left (normal left inverted right x axis y
 axis) 518mm x 324mm
1920x1200  60.0*+   59.9
1920x1080  60.0 59.9 50.0 24.0 30.0 30.0
 25.0
1600x1200  60.0
1280x1024  75.0 60.0
1280x720   60.0 59.9 50.0
1152x864   75.0
1024x768   75.0 60.0
800x60075.0 60.3
720x57650.0 25.0
720x48059.9 30.0
640x48075.0 59.9 59.9
 
 Steps to reproduce the issue:
 1) Configure one monitor in portrait orientation
 2) xset dpms force standby
 3) Press a key or move the mouse so that the monitors leave standby
 4) Xorg crash
 
 I've also attached my Xorg.0.log.old after a crash.
 Please note that we were able reproduce this behavior on all release
 drivers between 304.43 and 304.51. This might be an issue in earlier 3xx.xx
 drivers too.
 I hope this helps already a bit... If you need more details please let me
 know.
 
 Best,
 
 Michael
 
 PS: Wish you a nice weekend...
 
 
 On Fri, Oct 12, 2012 at 11:41 AM, Bryce Harrington br...@canonical.comwrote:
 
  On Fri, Oct 12, 2012 at 11:14:30AM +0200, Michael Wisheu wrote:
   Hi Byrce,
  
   Thanks for the great explanation and I agree that it makes sense this
  way.
   Please note that we've seen another bug with 304.43 and later (but might
   affect also earlier 304.x driver versions) on Precise that cause X server
   crashes under certain circumstances.
   The circumstances are:
   * Multi-monitor setup
   * At least one screen is in portrait orientation
   * X server crashes once monitors should leave standby
   * Disabling DPMS prevents the X server crashes
  
   NVIDIA has confirmed this issue last week and they are working on a fix.
   They are tracking the issue under number 1060346. There is no Launchpad
  bug
   for this issue.
 
  Thanks for letting me know about this Michael.
 
  Do you have a URL for viewing the issue number 1060346, or is that an
  internal bug tracker number?  If the latter, is there a forum or mailing
  list post from NVIDIA referencing that, which we could refer to?
 
  Having a Launchpad bug report to follow this would be helpful.  The most
  useful way to file this bug would be to reproduce the crash, and then on
  the crashed system file the bug via 'ubuntu-bug xorg', which will
  collect all the log and config files we need.  Then also reference any
  and all background material (steps to reproduce, external bug #'s, forum
  discussions, etc.)  Elaborating on any/all testing activity you've done
  can also be invaluable.
 
  Bryce
 
 
 


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


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

New nvidia experimental driver packages coming soon for 12.04

[Bryce Harrington]

We are introducing new 'experimental' driver packages for NVIDIA, which
will be available via the Additional Hardware Drivers setup tool for
12.04 user (and 12.10 too).  These packages will provide NVIDIA's beta
drivers, which are required for certain commercial games.

There is an nvidia-experimental-304 package which isn't really a beta
driver, just what we've been using for testing.  The first real beta
package will be nvidia-experimental-310; it should be coming some time
later this month.

For Intel, there will be a PPA upgrade available for 12.04 gamers.

For more details, see my blog:
  http://www.bryceharrington.org/wordpress/?p=91

Bryce

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