Extended call for Ubuntu Technical Board candidates

2022-11-23 Thread Merlijn Sebrechts
We are still looking for candidates to join the Ubuntu Technical Board!

The call remains open until *November 27th*, 2022, at 23:59 UTC. This is a
bit longer than initially anticipated.

Are you interested or do you know of someone who you want to see in this
role? Please submit the nomination.
What is the Ubuntu Technical Board?

The Ubuntu Technical Board is responsible for the technical direction of
Ubuntu. It makes decisions on package selection, packaging policy,
installation systems and processes, kernel, X server, display management,
library versions, and dependencies. The board works with relevant teams to
establish a consensus on the right path to take, especially where diverse
elements of Ubuntu cannot find consensus on shared components. The current
Technical Board is expiring at the end of the year, and the Community
Council would like to confirm a new Technical Board, consisting of five
people, who will serve for two years. The eligibility requirements are:
Who is eligible?

Everyone who meets the following criteria:

   - Be an Ubuntu Core Developer
   - Be available during typical meeting hours [see
https://wiki.ubuntu.com/TechnicalBoardAgenda
   ]
   - Have insight into the Ubuntu Development process, architecture, and
   technical culture

How do you nominate yourself or someone else?

Send the Community Council an email (community-council AT lists.ubuntu.com).
With your nomination. Note that you can nominate yourself too!
How does the election work?

The call remains open until November 27th, 2022, at 23:59 UTC. After that,
the Community Council will review the submissions, submit them to Mark
Shuttleworth for shortlisting, and proceed with a vote by the Ubuntu
Development team.
-- 
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 (2011-11-16 - ~2011-11-22)

2022-11-23 Thread Andreas Hasenack
Hi,

this +1 maintenance shift was a bit less useful due to external
interrupts and holidays, and of course large test queues, but I tried
to make the most of it.

Since the dep8 queue is clogged, I started by focusing on NBSs, and
lastly FTBFs since the builders are fast:

# gnuradio stack and libuhd transition
Lots of no-change rebuilds here:
gnuradio
soapyuhd
gnss-sdr
gr-osmosdr
gr-radar
gr-air-modes
gqrx-sdr
gr-fosphor
gr-gsm
gr-satellites
gr-funcube
gr-rds
gr-limesdr
gr-iqbal
gr-hpsdr

This are all mostly just waiting for gnuradio to finish testing.
gnss-sdr I'm unsure. It had some failures, but after a trigger the
result became "neutral". Since the excuses page still shows the red
failure (hasn't picked up the new result?), I'm unsure if "neutral"
will be good enough for migration, we will have to wait.


# librcutils0d transition to librcutils1d
ros-image-common
ros-urdf
ros2-rosidl (FTBFS on armhf, see LP: #1996897). Upstream is asking for
help on this one
ros-class-loader
ros-ros-comm


And lastly I fixed a git FTBFS on s390x
https://bugs.launchpad.net/ubuntu/+source/git/+bug/1997475 which was
blocking ubuntu-advantage-tools, docker.io, and perhaps others. What
took a lot of time here was to get a s390x VM to try to reproduce the
problem, as canonistack is in bad shape again (at least for s390x).
Thanks Christian for lending me a mainframe for a few hours ;)

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