Re: Responses Needed: Flavor Participation for 24.04 LTS

I can affirm with regards to Lubuntu that we are participating in 24.04 LTS, with a support period of 3 years as typical for Lubuntu.

We are working on getting everything necessary for the Technical Board recertification and will send that soon as well.

Thomas Ward

Lubuntu Team Lead

Lubuntu Council Member

LP: ~teward

---

From: ubuntu-flavors <ubuntu-flavors-bounces@lists.ubuntu.com> on behalf of Simon Quigley <simon@tsimonq2.net>
Sent: Wednesday, November 8, 2023 2:04 PM
To: ubuntu-devel@lists.ubuntu.com <ubuntu-devel@lists.ubuntu.com>; ubuntu-flavors@lists.ubuntu.com <ubuntu-flavors@lists.ubuntu.com>
Subject: Responses Needed: Flavor Participation for 24.04 LTS

 

Hello flavors!

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

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

  * Edubuntu
  * Kubuntu
  * Lubuntu
  * Ubuntu Budgie
  * Ubuntu Cinnamon
  * Ubuntu Kylin
  * Ubuntu MATE
  * Ubuntu Studio
  * Ubuntu Unity
  * Xubuntu

Diversity of opinion within the Ubuntu ecosystem makes us stronger. Flavors play
an important role in making a resilient, inclusive, and technically-sound
Ubuntu, for all of us, inspiring us to do better, and be better. As important
players within the project, we especially value your opinions, and are happy to
address concerns if you run into trouble.

This release, we are making a concerted effort to move off of Ubiquity entirely
and across the board, in time for the LTS. Ubuntu Budgie has paved the way for
flavor participation with the new Ubuntu Desktop Installer, while Lubuntu
continues to innovate and push the limits of what is possible with Calamares.
Whatever route your flavor chooses, it would be an incredibly wise decision to
move off of Ubiquity.

If you have any concerns regarding your participation, or a switch in
installers, please feel free to reach out to me, or anyone from the
~ubuntu-release team.

Thank you!

--
Simon Quigley
simon@tsimonq2.net
tsimonq2 on LiberaChat and OFTC
@tsimonq2:linuxdelta.com on Matrix
5C7A BEA2 0F86 3045 9CC8
C8B5 E27F 2CF8 458C 2FA4

+1 Report

Here is the list packages I have touched during my +1 shift:

• libvpx7 NBS

• Caused by python3-aiortc FTBFS (LP: #2045120)

• that Depends python3-av < 11 but python3-av = 11 is in proposed

• This is also a Debian sid problem, should be fixed there

• simde autopkgtest failure on ppc64el (LP: #2033648)

• Test build of simde_0.8.0~rc1-1~0exp0 from experimental in noble is broken

• Test merge with the HEAD of upstream is also broken (notified)

• This is a reasonably complex code so letting upstream fix it sounds reasonable

• gkrellm2-cpufreq FTBFS, cpufreqd and opa-ff (LP: #1215411)

• These depend on libcpupower-dev, which is provided by the Debian kernel packages

• We only provide the same library versioned per kernel package

• Debian has SONAME that get version bumped on ABI breakage

• @xnox is working on it, no action after discussion

• tiledarray FTBFS (LP: #2007960)

• In Lunar+k and Debian sid (see #1028634 and #1050355)

• Tiledarray possible needs Build-Depend: libblaspp-dev, liblapackpp-dev

• btas in archive is also outdated and not compatible with tiledarray 1.0.0

• Likely needs newer btas packaged from git

• phpmyadmin-sql-parser FTBFS

• Was blocked on phpmyadmin merge

• phpmyadmin merged and has been uploaded now

• pesign 116-6 FTBFS

• Blocked on efivar 38-2 merge

• Upstreamed Ubuntu delta in efivar 38-3, then got sync sponsored

• efivar 38-3 is now in noble, pesign also now migrated

• Other universe merges:

• nix, imath, thin: gotten uploads sponsored

• xserver-xorg-input-synaptics: FTBFS, ubuntu2 in review

• presage: addressing review comments TBD

Mate Kukri

Re: Sponsoring reports moved to sponsoring-reports.ubuntu.com

On Thu, 2023-11-30 at 18:20 -0500, Jeremy Bícha wrote:
> On Thu, Nov 30, 2023 at 6:10 PM Benjamin Drung <bdrung@ubuntu.com> wrote:
> > http://reports.qa.ubuntu.com/reports/sponsoring/ is dead. Long live
> > http://sponsoring-reports.ubuntu.com !
>
> Could you restore the json version? The Ubuntu Desktop team has some
> reports that use it.
>
> https://people.canonical.com/~platform/desktop/versions/ubuntu-desktop.html etc

The JSON reports can be found in
http://sponsoring-reports.ubuntu.com/jsons/ (they used to be stored in
the top-level directory).

--
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: Sponsoring reports moved to sponsoring-reports.ubuntu.com

On Thu, Nov 30, 2023 at 6:10 PM Benjamin Drung <bdrung@ubuntu.com> wrote:
> http://reports.qa.ubuntu.com/reports/sponsoring/ is dead. Long live
> http://sponsoring-reports.ubuntu.com !

Could you restore the json version? The Ubuntu Desktop team has some
reports that use it.

https://people.canonical.com/~platform/desktop/versions/ubuntu-desktop.html etc

Thank you,
Jeremy Bícha

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

Sponsoring reports moved to sponsoring-reports.ubuntu.com

Hi everyone,

http://reports.qa.ubuntu.com/reports/sponsoring/ is dead. Long live
http://sponsoring-reports.ubuntu.com !

This change was caused by the shutdown of the old server. The new server
for sponsoring reports is now under the control of the community
umbrella instead of QA.

The code can be found on https://code.launchpad.net/ubuntu-sponsoring
and deployed via Debian package from a PPA:
https://code.launchpad.net/~ubuntu-sponsors/+archive/ubuntu/sponsoring-report

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

+1 maintenance report - Nov 21st -> Nov 24th 2023

Hello,

I was on my plus-one shift last week. I was off on Monday so it makes it a slightly
shorter report to write.

### libnet-cups-perl (LP: #2044113)

We are ahead of Debian for cupsfilters by one major version. I introduced a patch
to make libnet-cups-perl build properly against libcupsfilters 2.0.
It isn't trivial to make the package compatible with both versions of cups-filters,
so I think we need to maintain the delta in Ubuntu until Debian switches from
cups-filters 1.28 to 2.0.
I also filed a bug report upstream to add support for cups-filters 2.0 in Net-CUPS.
Thanks to Till for sponsoring the upload!

### kitty (LP: #2043080, LP: #2044243)

I merged 0.26.5-5 from Debian unstable and opened a PR in Debian so we can drop our
delta later. As a response, Debian pulled in a new upstream version that has the fix
we need.
Once kitty 0.31 made it to Debian unstable, I requested a sync.
Thank you Simon Quigley for sponsoring both the merge and the sync!

### acedb (LP: #2044385)

acedb was FTBFS in noble. It turned out to be incompatible with glibc 2.38 because
glibc 2.38 makes the strcasestr function available by default. Previously, it made
the function available only when building with _GNU_SOURCE.
acedb defines its own strcasestr function when it thinks the function is not available
(the logic did not cover recent glibc-s). This resulted in multiple definitions with
glibc 2.38.
I added a patch to skip the (re)definition when building with recent glibc-s.
The patch was accepted in Debian before being sponsored in Ubuntu, and the package
auto-synced.

### khmer (LP: #2044383)

In retrospect, I spent /way/ too much time on this package. I think I should have
filed a removal package from the get go since it isn't actively maintained... but
I assumed it was going to be a quick win (and spoiler, it wasn't).

khmer was FTBFS with Python 3.12. The only visible failure at the time was in the
build-time test-suite and looked straightforward to address:

> AttributeError: module 'configparser' has no attribute 'SafeConfigParser'.
> Did you mean: 'RawConfigParser'?

I wrote a fix for this issue, made sure the package would build (well, at least I
thought so...), uploaded a .debdiff, forwarded the patch to Debian and upstream,
and called it done.

Then it turned out that my PPA was not building with -proposed enabled. And as you
know, one (or several) failures can hide behind another. There were actually
dozens other failures, all in the build-time test-suite. The test-suite was failing
on some test-cases and hanging on others (and when it did hang, it hung until
timeout ; therefore not showing any report of the previous errors).

After several iterations. I think I addressed all the remaining issues, submitted
another debdiff and forwarded the changes to Debian and upstream.

This was an interesting experience for sure. I learned that Python 3.12 is /not/
forgiving when a script forgets to close a file that it opened for writing.
This was the root cause of ~90% of the failures in src:khmer when building against
Python 3.12.
* With Python 3.11, there didn't seem to be much of a problem with files that were
open(..., mode="w") without either:
* an explicit call to .close() ; or
* an automatic call to .close() when using context managers (with blocks)
* With Python 3.12, all these files appear truncated. This made the test-suite go
wrong in many obscure ways.

Takeaway: remember to .close() your files (or use a context manager, really!)
especially if you work with Python 3.12.

I still need a sponsor to take my second patch. The diff is hard to read because I've
introduced context managers - which change the indentation of large chunks of code.
Being in a quilt patch does not make it easier either. Maybe the PR upstream is a
better place to start reviewing?

Thank you Simon Quigley for sponsoring the first patch, and looking at some of the
other failures! And sorry about this mess!

### python-ulmo (LP: #2044545)

I merged 0.8.8+dfsg1-1.1, allowing us to drop one piece of our delta (with one left).
I will need a sponsor to upload it :)

### peewee, pgl-ddl-deploy, dataclasses-json

Re-triggered autopkgtest-s blocking migration for these three packages so they would
run against updated dependencies. They both migrated.

### misc

I noticed in proposed-migrations that an unusual number of packages failed to build
because GCC was segfault-ing. I didn't have enough time to investigate.

Thank you,
Olivier

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

Re: Merge ubuntu-motu@lists into ubuntu-devel-discuss@lists?

Hi Steve,

On 11/25/2023 1:38 PM, Steve Langasek wrote:

Having seen no objections to the proposal, I have filed an RT to have the  ubuntu-motu mailing list address redirected to ubuntu-devel-discuss.    On Wed, Oct 18, 2023 at 09:26:29PM -0700, Erich Eickmeyer wrote:  

With my IRC op team hat on: let's be careful about the IRC channels which  are ultimately goverened by the IRC council (i.e. not a Canonical decision  except for what the IRC council has delegated to certain devel teams). While  I would be in favor of closing #ubuntu-motu and forwarding to #ubuntu-devel,  #ubuntu-next is a support channel (not a devel channel) and the volunteer  support in #ubuntu and #ubuntu-next would not be too keen to lose that one.  But, again, that's a discussion to be had with the IRC council.  

  What would be the process for asking #ubuntu-motu to be closed/redirected?

I'm fairly certain a request to ubuntu-irc@lists.u.c would do the trick, and a request in #ubuntu-ops wouldn't hurt either. I'd cite this mailing list thread for the rationale.

I hope that helps! :) Erich -- Erich Eickmeyer Project Leader - Ubuntu Studio Technical Lead - Edubuntu