Friday 17 May 2024

New Kernel Uploaders

Today, the Kernel Uploaders Team[1] had an ad-hoc IRC meeting with the
following people in attendence:

Team Members:
Andrei Gherzan (~agherzan)
Andy Whitcroft (~apw)
Bartlomiej Zolnierkiewicz (~bzolnier)
Emil Renner Berthing (~esmil)
Jacob Martin (~jacobmartin)
John Cabaj (~john-cabaj)
Juerg Haefliger (~juergh)
Kleber Sacilotto de Souza (~kleber-souza)
Magali Lemes do Sacramento (~magalilemes)
Manuel Diewald (~diewald)
Marcelo Cerri (~mhcerri)
Phil Cox (~philcox)
Roxana Nicolescu (~roxanan)
Stefan Bader (~smb)
Thibault Ferrante (~thibf)
Tim Gardner (~timg-tpi)

Applicants:
Agathe Porte (~gagath)
Bethany Jamison (~bjamison)
Kevin Becker (~kevinbecker)
Kuba Pawlak (~kuba-t-pawlak)
Noah Wager (~nwager)
Portia Stephens (~portias)

Observers:
Jose Ogando Justo (~joseogando)
Mehmet Basaran (~mehmetbasaran)

[1] https://launchpad.net/~ubuntu-kernel-uploaders

We reviewed the application[2] by Portia Stephens (~portias)[3] for
Kernel Upload Rights. After representations by the applicant and
their sponsors a vote was held as below:

Andy Whitcroft +1
Emil Renner Berthing +1
Jacob Martin +1
John Cabaj +1
Kleber Sacilotto de Souza +1
Magali Lemes do Sacramento +1
Manuel Diewald +1
Marcelo Cerri +1
Phil Cox +1
Roxana Nicolescu +1
Stefan Bader +1
Tim Gardner +1

The application was unanimously approved; congratulations to Portia
Stephens.

[2] https://wiki.ubuntu.com/portias/KernelUploadRightsApplication
[3] https://launchpad.net/~portias

We reviewed the application[4] by Kuba Pawlak (~kuba-t-pawlak)[5] for
Kernel Upload Rights. After representations by the applicant and
their sponsors a vote was held as below:

Andy Whitcroft +1
Bartlomiej Zolnierkiewicz +1
Emil Renner Berthing +1
Jacob Martin +1
John Cabaj +1
Kleber Sacilotto de Souza +1
Magali Lemes do Sacramento +1
Manuel Diewald +1
Marcelo Cerri +1
Phil Cox +1
Roxana Nicolescu +1
Stefan Bader +1
Tim Gardner +1

The application was unanimously approved; congratulations to Kuba
Pawlak.

[4] https://wiki.ubuntu.com/kuba-t-pawlak/KernelUploadRightsApplication
[5] https://launchpad.net/~kuba-t-pawlak

We reviewed the application[6] by Kevin Becker (~kevinbecker)[7] for
Kernel Upload Rights. After representations by the applicant and
their sponsors a vote was held as below:

Andrei Gherzan +1
Andy Whitcroft +1
Bartlomiej Zolnierkiewicz +1
Jacob Martin +1
John Cabaj +1
Juerg Haefliger +1
Kleber Sacilotto de Souza +1
Magali Lemes do Sacramento +1
Manuel Diewald +1
Marcelo Cerri +1
Phil Cox +1
Roxana Nicolescu +1
Stefan Bader +1
Tim Gardner +1

The application was unanimously approved; congratulations to Kevin
Becker.

[6] https://wiki.ubuntu.com/kevinbecker/KernelUploadRightsApplication
[7] https://launchpad.net/~kevinbecker

We reviewed the application[8] by Agathe Porte (~gagath)[9] for Kernel
Upload Rights. After representations by the applicant and their
sponsors a vote was held as below:

Andrei Gherzan +1
Andy Whitcroft +1
Emil Renner Berthing +1
Jacob Martin +1
John Cabaj +1
Juerg Haefliger +1
Kleber Sacilotto de Souza +1
Magali Lemes do Sacramento +1
Manuel Diewald +1
Marcelo Cerri +1
Phil Cox +1
Roxana Nicolescu +1
Stefan Bader +1
Thibault Ferrante +1
Tim Gardner +1

The application was unanimously approved; congratulations to Agathe
Porte.

[8] https://wiki.ubuntu.com/gagath/KernelUploadRightsApplication
[9] https://launchpad.net/~gagath

We reviewed the application[10] by Bethany Jamison (~bjamison)[11] for
Kernel Upload Rights. After representations by the applicant and
their sponsors a vote was held as below:

Andrei Gherzan +1
Andy Whitcroft +1
Bartlomiej Zolnierkiewicz +1
Emil Renner Berthing +1
Jacob Martin +1
John Cabaj +1
Kleber Sacilotto de Souza +1
Magali Lemes do Sacramento +1
Manuel Diewald +1
Marcelo Cerri +1
Phil Cox +1
Roxana Nicolescu +1
Stefan Bader +1
Thibault Ferrante +1
Tim Gardner +1

The application was unanimously approved; congratulations to Bethany
Jamison.

[10] https://wiki.ubuntu.com/BethanyJamison/KernelUploadRightsApplication
[11] https://launchpad.net/~bjamison

We reviewed the application[12] by Noah Wager (~nwager)[13] for Kernel
Upload Rights. After representations by the applicant and their
sponsors a vote was held as below:

Andrei Gherzan +1
Andy Whitcroft +1
Bartlomiej Zolnierkiewicz +1
Jacob Martin +1
John Cabaj +1
Kleber Sacilotto de Souza +1
Magali Lemes do Sacramento +1
Manuel Diewald +1
Marcelo Cerri +1
Phil Cox +1
Roxana Nicolescu +1
Stefan Bader +1
Tim Gardner +1

The application was unanimously approved; congratulations to Noah
Wager.

[12] https://wiki.ubuntu.com/nwager/KernelUploadRightsApplication
[13] https://launchpad.net/~nwager

Congratulations to all of the successful applicants. Enjoy your new
rights. Andy Whitcroft (~apw) was tasked with adding them to the
~ubuntu-kernel-uploaders team and announcing these results.

-apw (on behalf of the ~ubuntu-kernel-uploaders team)

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

Thursday 16 May 2024

ubuntu-dev-tools and `ubuntu-build`

Hi folks,

As part of the time_t transition, I've found it useful to improve
commandline tooling around retrying/rescoring package builds.

I previously had my own local launchpadlib scripts that I used for this; but
I've recently learned that ubuntu-dev-tools ships an 'ubuntu-build' script
for this and has done since 2009(!)

When I learned about it I checked it out, and decided it wasn't really fit
for purpose. I've spent some time enhancing its set of options, and these
improvements are now available in version 0.201ubuntu2 in noble.

My question to this list is: was anyone using this script, and if so, are
you attached to the non-"batch" mode? If not, I would like to make the
"batch" mode the mode, dropping the requirement for the --batch argument.

--
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/
slangasek@ubuntu.com vorlon@debian.org

Monday 13 May 2024

RE: pastebinit default target on Ubuntu

For awareness, with my Debian Maintainer hat on and also my upstream pastebinit contributor hat on:

Today version 1.7.0 of pastebinit was tagged in GitHub. It includes many improvements since 1.6.2 and includes the dpaste.org addition.

Note that while I think there's specific overrides for Ubuntu and Debian, the 'default' of pastebinit upstream is now bpa.st.

We can relatively quickly add code logic *in* pastebinit that changes the default for Ubuntu to bpaste.org or such.

1.7.0-1 was uploaded to Debian today but can be rapidly updated if needed to add Ubuntu logic. Or we can distropatch that in with a merge or such.

Thomas

-----Original Message-----
From: ubuntu-devel <ubuntu-devel-bounces@lists.ubuntu.com> On Behalf Of Marco Trevisan
Sent: Thursday, April 25, 2024 07:28
To: Timo Aaltonen <tjaalton@ubuntu.com>
Cc: Sergio Durigan Junior <sergiodj@ubuntu.com>; Robie Basak <robie.basak@ubuntu.com>; ubuntu-devel@lists.ubuntu.com
Subject: Re: pastebinit default target on Ubuntu

Hey,

On apr 16 2024, at 8:23 am, Timo Aaltonen <tjaalton@ubuntu.com> wrote:
> Sergio Durigan Junior kirjoitti 15.4.2024 klo 20.51:
>> dpaste.com also runs a proprietary backend, so I'm -1 on using it.
>> There's dpaste.org, which is FLOSS and doesn't seem to load any ads.
>
> dpaste.org seems like a fine alternative, so +1 here too

Oh, I totally agree with this, and supporting dpaste.org was easy enough:
- https://github.com/pastebinit/pastebinit/pull/5

(for those who wants to use it already, just add that config to ~/.pastebin.d and adjust ~/.pastebinit.xml accordingly).

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

Thursday 9 May 2024

Re: Make proposed available by default? [was: Setting NotAutomatic for hirsute+1-proposed]

On 5/3/24 22:08, Seth Arnold wrote:
But, I also expect very few of our users would use -proposed. What  percentage do you expect? I'm guessing less than 1%.    Instead of configuring proposed by default, I suggest that we should  make this work:    $ sudo add-apt-repository proposed  Unable to handle repository shortcut 'proposed'  

Let's also not lose sight of the fact that if proposed had been enabled by default with the current LTS release, the xz exposure and impact would have been a lot broader than it was, and also a lot harder to clean up and retract from. 

As it was, the customer I support mirrored -proposed into their internal aptly during the Feb 28-March 30 window when the  exploited versions of xz packages were resident in noble-proposed, and some of their machines had it deployed as part of internal automation. They had to go through a manual exercise to delete the pocket from their mirror and specifically the xz-utils packages for a daily span of 30 days of mirroring and resilver all of their aptly package lists to redact that and remove their own potential for exposure.

Let's err on the side of being a bit more cautious here, so we don't leave ourselves open to another possible 'adventure' that could sneak through unnoticed, before our users/customers are impacted. -proposed explicitly disabled by default has a purpose and requires being manually enabled, and once we flip that position, we may lose the value that explicit testing of packages in -proposed provides.

--   David A. Desrosiers  Principal Support Engineer (PSE/DSE), Canonical US   <david.desrosiers@canonical.com>

Wednesday 8 May 2024

Re: Can we collaborate with Debian better?

Steve Langasek <steve.langasek@ubuntu.com> writes:

> You do not have to be "the Ubuntu maintainer" to close bugs in launchpad,
> you only have to create a launchpad account. (Some bug states, such as
> 'Triaged' and 'Opinion', are restricted; but 'Fix Released' is not.)

Thank you! I just closed that bug, and will close the other relevant
ones in a bit.

I don't have much more to contribute to the rest of this. Thanks again
for the detailed replies.

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

Oracular Oriole is now open for development

We're pleased to announce that Oracular Oriole is now open for development.
auto-sync has been enabled and will run soon. As usual, we expect a large
influx of builds and autopkgtests in this initial period, which will cause
delays. Please help fixing any breakage that occurs.

The release schedule can be found at

https://discourse.ubuntu.com/t/oracular-oriole-release-schedule/36460

Please see the release schedule page for information about any major changes
and for all milestone dates.

Please check your uploads in a oracular chroot. See [1] or [2] for details on
how to set up such a development chroot.

You can subscribe to the oracular-changes mailing list [3] to receive the
changelog entry of package uploads to the archive for oracular.

[1] https://wiki.ubuntu.com/SimpleSbuild
[2] https://wiki.ubuntu.com/DebootstrapChroot
[3] https://lists.ubuntu.com/mailman/listinfo/oracular-changes


On behalf of the Ubuntu Release Team,
Utkarsh Gupta

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

Tuesday 7 May 2024

Re: Can we collaborate with Debian better?

On Mon, May 06, 2024 at 12:00:28PM -0700, Dima Kogan wrote:
> Thanks for the replies, everybody. This was helpful.

> First off, let me ask about the bug tracker divergence. There are a
> number of bugs in Ubuntu launchpad, describing issues that have long
> been fixed in Debian. For instance:

> https://bugs.launchpad.net/ubuntu/+source/vlfeat/+bug/1313166

> I'm not the Ubuntu maintainer, so I can't close these bugs.

You do not have to be "the Ubuntu maintainer" to close bugs in launchpad,
you only have to create a launchpad account. (Some bug states, such as
'Triaged' and 'Opinion', are restricted; but 'Fix Released' is not.)

> Are yall saying that it's the responsibility of the Ubuntu maintainers to
> close these, and they just haven't gotten around to it yet?

I think "responsibility" is a bit strong. We have processes by which the
Ubuntu community, not only limited to developers, can contribute to triaging
bugs:

https://wiki.ubuntu.com/BugSquad/GettingInvolved

But the primary purpose of the bug tracker, and bug triage, is not to have a
perfect representation of the bug status of packages. The primary purpose
is to use this as input to improve the quality of packages for our users.

If a bug is filed against a package that's in universe, and which is synced
from Debian (both of these things are true for vlfeat), it is very unlikely
that a developer is going to look at and act on that bug report. This
unfortunately means it may be a waste of time for a user to have filed that
bug report at all. But we don't have a way to communicate to users that
some bugs should probably be filed upstream (where "upstream" may mean
Debian) instead.

> For such packages (few rdeps, nothing Ubuntu-specific; tons of these!), we
> don't want tighter integration between the two bug trackers?

I think by "tighter integration" you are implying automation of bug status
changes, and for that the answer is no. Even in cases where we know a
corresponding bug in the Debian BTS and have linked to it for the launchpad
bug for the Ubuntu package, there are various ways in which trying to make
the Ubuntu bug state match the Debian bug state can go wrong. The bugfix
may not have landed into Ubuntu because of a freeze; or may have been synced
to Ubuntu, but had an Ubuntu-specific build or test failure preventing it
from migrating to the release pocket (and therefore the bug is not actually
fixed from a user perspective); there may be Ubuntu-specific aspects to the
bug that mean the fix in Debian is not applicable to Ubuntu. So automation
here is going to have an unacceptable false-positive rate.

The automation we DO have, and have had for many years, is that where a
Debian maintainer knows a change they're making in the package fixes a bug
reported in Ubuntu, they can close that bug in the changelog just as they
can close a Debian bug using the LP: ##### syntax.

> > "Removed from disk on 2024-04-18.
> > Removal requested on 2024-04-17.
> > Deleted on 2024-04-17 by Matthias Klose
> > Debian #1069220, ftbfs, no rdeps"

> > https://launchpad.net/ubuntu/+source/mrcal/+publishinghistory

> > In this case, the bug pointed to is in fact one that Matthias himself
> > filed, so he was documenting the build failure for the Debian
> > maintainer prior to removing the package.

> I guess he did that, but I never saw any of it.

Yes, there is no way to subscribe in Ubuntu to package removals.

If a bug had been filed in Ubuntu about it, you could subscribe to bug
notifications for the package (in fact, if you claim your @debian.org email
address in Launchpad, you will be autosubscribed to bugs for packages you
maintain). But that didn't apply here.

> > mrbuild 1.10-1, which would have fixed this build failure, was published to
> > Debian unstable on 2024-04-05. However, Debian Import Freeze happened on
> > 2024-02-29

> As noted above, mrbuild 1.9-2, published on Mar 26 fixed this problem
> (and 1.9-1, published on Mar 21 would probably have fixed it too). These
> both made the deadline.

Which deadline? As I said above, Debian Import Freeze was Feb 29, a month
before.

> > So although you did reply right away with an explanation of how to fix
> > the build failure, it's understandable that Matthias did not
> > prioritize bringing this package back into the noble release pocket
> > and syncing the new mrbuild necessary to get it to build in the week
> > before release, when many other things were in flight.

> Yeah. The timing of the xz disclosure was really unfortunate. It sounds
> like the extra work should have pushed back the Ubuntu release. Even if
> the communication was clear here, the time crunch made it impossible to
> actually fix the problem.

I don't think the removal of mrcal from Ubuntu supports the conclusion that
the release should be delayed. I appreciate that you care about your work
being used by users of Ubuntu and care about its inclusion, and *in general*
there are things we could do to improve Debian maintainers' ability to track
whether a package is at risk of removal (e.g. perhaps we should be
automatically surfacing build failures of a package as bugs in launchpad, so
that a package bug subscription would be enough to result in a
notification). But it is always the case that we may do late removals of
packages in a development series, when necessary to address certain classes
of problems (most likely: uninstallability of binary packages) and don't
currently have a plausible way to generate notifications to Debian
maintainers for these cases.

> > I do not want to commit our archive admins to a policy that we MUST
> > notify Debian maintainers before their packages are removed from
> > Ubuntu.

> I think that would be a very good policy, actually.

You *personally* think that there should be such a policy. Many other
Debian maintainers would be very angry to receive such notifications. And
we currently don't have any mechanism for such notifications that would not
impose an additional burden on the archive admins, which I'm not willing to
accept.

--
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/
slangasek@ubuntu.com vorlon@debian.org