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/ slanga...@ubuntu.com vor...@debian.org 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: Can we collaborate with Debian better?
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/ slanga...@ubuntu.com vor...@debian.org 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: Can we collaborate with Debian better?
On Sun, May 05, 2024 at 09:53:06PM +0200, Frank Heimes wrote: > There is a little bit more on "removing packages" here: > https://wiki.ubuntu.com/UbuntuDevelopment/PackageArchive#Removing_Packages > So it's actually a 'must' to have a LP bug for getting a package removed. The word "must" does not appear in that text. It simply says that, if you are asking for a package to be removed from Ubuntu, the process to follow is to file a bug in Launchpad. However: On Sun, May 05, 2024 at 03:03:18PM -0700, Erich Eickmeyer wrote: > I recently learned this too, and that's not entirely accurate. Apparently > we treat Debian bugs as though they're our own, so if they're filed in > Debian's bug tracker, then they're fair game. So, if a removal bug is > filed in Debian, it applies to Ubuntu as well and doesn't require a > Launchpad bug. This is broadly correct. More precisely, if there is a release-critical bug (such as a report of FTBFS) filed against the package in Debian that has caused / will cause its removal, archive admins will often consider this adequate documentation of a removal reason. Because wanting bug reports filed for package removals is largely about having something to point to in the removal messages: "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. 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, so well before, meaning this package was not pulled into Ubuntu; and mrcal COULD NOT be shipped in Ubuntu if it couldn't be built, because 2.4.1-1 was built for the wrong version of python, and 2.4.1-1build1 was built with the wrong version of xz-utils present in the host environment. So while python3.12 wasn't the cause of the build failure and this was a misdiagnosis (2.4.1-1build1 was a no-change rebuild *for* python 3.12 and it succeeded), on 2024-04-18 when Matthias removed the package we were 8 days out from release and doing everything necessary to get to the state of a Noble releasable on time without risk of compromise due to xz-utils-tainted binaries. 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. It is also understandable to me that Matthias did not prioritize communicating in the Debian bug that the issue he was reporting would result in the package's removal from the upcoming Ubuntu release. It would have been REASONABLE for Matthias to note this in the bug, but on the other hand 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. However, given the circumstances of the removal for xz-utils: > Related question: is there any way to get my packages included into some > sort of noble "updates", or something like that? As a member of the SRU team my answer is yes, I would consider this. It would require an actual SRU process for mrbuild, since that package has other reverse-build-dependencies in noble (libdogleg, mrgingham, vnlog) which should not be allowed to regress; but provided there is a proper SRU test case to assert this, I think it's a sensible path towards letting mrcal back in the archive for 24.04. -- 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 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: pastebinit default target on Ubuntu
On Tue, Apr 16, 2024 at 05:54:47PM +1200, Michael Hudson-Doyle wrote: > > The current behavior of paste.ubuntu.com, and what I assumed was the > > driver for moving away from this as a default, was that it requires a > > login to VIEW the contents of the pastebin. AFAICS this is not > > justifiable on the basis of preventing abuse with illicit/illegal > > pastes, that's already addressed by requiring login on the submission > > side. > I think the current behaviour is to require login for at least one of > submission or view, so a paste created while logged in can be viewed > anonymously and a paste created anonymously (e.g. by pastebinit, which I > don't think supports logging in?) requires a login to view. Ok, I was unaware of this nuance. That being the case, I don't think "login required" is a sound argument for a default other than paste.ubuntu.com. -- 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 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: pastebinit default target on Ubuntu
On Mon, Apr 15, 2024 at 04:42:37PM -0400, Stéphane Graber wrote: > > And if there are issues with the usability of paste.ubuntu.com, uh, we own > > that service? So let's work with our IS team to make it fit for purpose. > > (I don't know why it currently requires a login to *view* paste contents; > > that seems straightforwardly a bug that we should just get sorted.) > That's because pastebin servers are frequently abused as a way to get > free mass storage. > It's not very practical to require login to post to a pastebin as the > whole point is for a tool like "pastebinit" to work without needing > user configuration as it's commonly used as a debug tool on cloud > instances and other random servers random than a user's personal > system. > With that in mind, a bunch of folks noticed that you could abuse a > service like paste.ubuntu.com by pushing large files (base64 encoded > or the like) and then retrieve them with a very trivial amount of html > parsing (if no raw option is offered directly). > There are obviously alternatives to this, but they tend to require a > bunch more server side logic, basically trying to find the right set > of restrictions to both poster and reader so that legitimate users can > use the service normally while abusers get sufficiently annoyed to > stay away from it. The current behavior of paste.ubuntu.com, and what I assumed was the driver for moving away from this as a default, was that it requires a login to VIEW the contents of the pastebin. AFAICS this is not justifiable on the basis of preventing abuse with illicit/illegal pastes, that's already addressed by requiring login on the submission side. If requiring authentication on the SUBMISSION side is sufficient reason to change the default pastebin, then that of course isn't something we should second-guess; we don't need to be reinvesting anonymous ftp servers. But in that case, I think there should have been a discussion about who the default behavior is for, because for my part it makes the default behavior much worse. -- 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 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: pastebinit default target on Ubuntu
On Mon, Apr 15, 2024 at 04:48:17PM +0100, Robie Basak wrote: > Prior to Noble, the pastebinit command defaulted to paste.ubuntu.com. In > Noble, this has changed to dpaste.com due to an upstream change[1]. > What do Ubuntu developers think the default should be? If it should > remain paste.ubuntu.com, we can ask upstream to change it back, or add a > delta for now. > Reason to keep it dpaste.com: > People have complained that the login requirement makes it unusable for > helping Ubuntu users at large who don't necessarily have an Ubuntu SSO > account. > Reason to keep it paste.ubuntu.com: > I'm not keen on relying on third party services when not necessary, > especially ad-supported ones. I have no reason to distrust the current > operator, but in general, these things tend to go wrong sooner or later. > There was more discussion on IRC[2]. > [1] > https://github.com/pastebinit/pastebinit/commit/5c668fb3ed9b4a103eb22b16e603050a539951e0 > [2] https://irclogs.ubuntu.com/2024/04/15/%23ubuntu-devel.html#t14:17 I was not pleased to see the switch to dpaste.com. I've found that it's pretty unusable on mobile, and I don't like this pointing to a service we don't control. And if there are issues with the usability of paste.ubuntu.com, uh, we own that service? So let's work with our IS team to make it fit for purpose. (I don't know why it currently requires a login to *view* paste contents; that seems straightforwardly a bug that we should just get sorted.) -- 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 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
Noble Numbat (to be 24.04 LTS) Beta Freeze
As of a short while ago, noble has entered the Beta Freeze, with a goal of releasing Beta images sometime late Thursday. *From now until the Beta is released, please only upload updates for packages on any release images if you /need/ to get them into the Beta itself.* Please hold off with everything else until after we release on Thursday. The queue freeze will last from now until the final release next month, which means that all seeded packages will now need a spot-check and review in the queue from a release team member before they are let into the archive. As with the previous releases, we have a bot in place that will accept uploads that are unseeded and don't affect images. Don't take this as an open invitation to break Feature Freeze on those components, this is just to reduce the burden on the release team, so we only review the uploads that need very serious consideration. If you find the bot is blocking an upload that you think should have been auto-accepted, let us know and we'll sort it out. We will be spinning a set of Beta candidates in the next 12 hours or so. We then encourage people to start testing ASAP for their favourite flavour(s) as they come off the line. Happy bug-hunting from now until the final release, and please do help out and test images, etc, where you can and let us know what's broken in your environment(s). As a reminder, the Beta images will appear on the ISO Tracker here: http://iso.qa.ubuntu.com/qatracker/milestones/452/builds On behalf of the Ubuntu Release Team, -- Steve Langasek signature.asc Description: PGP signature -- ubuntu-devel-announce mailing list ubuntu-devel-announce@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-announce
Re: help needed -- fixing hard-coded dependencies on shared library packages
Thanks for pointing developers at this. Note that this does not conflict with prior advice that we should aggressively remove armhf binary packages from the release pocket in order to let the transition through: while dependencies on the old package name will only make the packages *uninstallable* on armhf, having packages on other archs with dependencies on the old package name is also not good for the release because it makes apt's job harder in trying to calculate an upgrade to noble. Since it's about the same amount of effort to just fix these as it is to remove them on armhf, we should just fix them. On Sat, Mar 23, 2024 at 07:05:19PM +0100, Matthias Klose wrote: > Hi, > > according to > https://magenta.jak-linux.org/ubuntu-archive/distcheck/noble.armhf/global-ben.rebuild-for.txt > > we still have a lot of hard-coded dependencies on shared library packages. > > These fixes just take some minutes, not only replacing a shared library name > with another hard-coded name. So when you're bored, can't sleep, or > whatever, please fix some packages! > > To check: > > - For architecture dependent package, check removing the >libfoo1 dependency, test build with nocheck, and look >if the dependency is still there. In this case, just >drop the hard-coded dependency. > > - for other packages, please follow the schema at > > http://launchpadlibrarian.net/720834264/python-fusepy_3.0.1-4build1_3.0.1-4ubuntu1.diff.gz > >- Derive the library name from the -dev package, > add a b-d on the -dev package if necessary, > replace the hard coded library in the control file > with a macro, and pass that macro in dh_gencontrol. > > Please join #ubuntu-devel and mention which package you are working on. > Also check the changes mailing list, if the package is already fixed. > https://lists.ubuntu.com/archives/noble-changes/2024-March/date.html > scrolling to the end > > Please don't forget to forward patches to the Debian bug tracker. > > Thanks, Matthias > > -- > 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 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
armhf and the 24.04 LTS release
If you have been involved in Ubuntu development in Noble for the past month, you are almost certainly aware of the ongoing time_t transition, to ensure that software we ship for the armhf architecture in Ubuntu 24.04 LTS is capable of handling timestamps beyond the year 2038. You will be aware of this because this has been a significantly disruptive transition, blocking most other fixes from being able to reach the release pocket in Noble for some time now. Originally targeted to land in Debian and Ubuntu in early January, this transition has effectively landed 2 months late, arriving in Ubuntu right before feature freeze. This has put us in a bit of a time crunch to get this work done in time to ensure that the upcoming Beta release in a little over 2 weeks includes images that accurately reflect what the team plans to ship in 24.04 LTS. Getting all of the affected packages built and in a position to transition into the release pocket from noble-proposed in less than 2 weeks represents a huge amount of work, especially with long dependency chains affecting some of these packages. However, with the decision to not ship a 32-bit kernel for Raspberry Pi in 24.04 LTS, it is important to recognize that, while it is important that any software we DO ship on armhf is appropriately future-proof, this is NOT the same thing as saying that we have to ship for armhf all the software that we have previously built. In order to appropriately prioritize the needs of the Beta (including for our community flavors), effective immediately, the Release Team is enacting a policy that armhf binaries for all leaf packages in universe, if they are blocking the transition of any time_t library and ESPECIALLY if they are blocking the transition of a library that’s present on a release image, should be summarily removed from the release pocket in order to let the transition move forward. If you are trying to get any library to migrate and you see that it is blocked by an armhf-specific issue, please contact an Archive Admin (e.g. highlighting ubuntu-archive on #ubuntu-release on IRC) providing the name of the source package whose binaries should be removed, and a reference to what it’s blocking on <https://ubuntu-archive-team.ubuntu.com/proposed-migration/update_excuses.html>, and we can remove these packages to move the release forward. This does not mean the package in question will not be shipped on armhf in 24.04. It is still possible for the binaries to be built afterwards, and included in the release. It is simply prioritizing the needs of the 24.04 release cycle over armhf coverage of any particular binary packages. For folks working on +1 maintenance, here are some further hints. * Packages containing libraries that need to migrate for time_t will generally have an NMU version number in -proposed (with or without an Ubuntu-specific version number after) and at the moment, are 18 days or newer (uploads having started on February 28). Please focus on these packages. * Packages listed as 'missing build on armhf' certainly warrant investigation (for fixing or removal). * Packages involved in the transition which have autopkgtest failures listed on architectures OTHER THAN armhf definitely require investigation. * Libraries which are part of this transition that say “Will attempt migration”, but are more than a day or so old, may require no-change rebuilds of their reverse-dependencies using https://lists.ubuntu.com/archives/ubuntu-devel/2022-April/041994.html or a similar script. On behalf of the Release Team, -- Steve Langasek signature.asc Description: PGP signature -- ubuntu-devel-announce mailing list ubuntu-devel-announce@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-announce
Re: early +1 maintenance: jupyter-notebook FTBFS, jupyter-client update ahead of debian
Hi Andreas, On Mon, Feb 19, 2024 at 05:05:00PM -0300, Andreas Hasenack wrote: > I started working on my +1 maintenance shift with the goal of > trailblazing the python 3.12 migration. A few packages sorted already, > but jupyter-notebook has me stumped, and I thought I would share this > now instead of at the end of the shift. > src:jupyter-notebook[1] is FTBFS[2] due to a test failure in > noble-proposed with src:jupyter-client[3] >= 8. I filed a bug[2] with > my findings. > Upstream and other projects I could find all seem to have settled on > pinning jupyter-client to a version < 8. And indeed, if we build > jupyter-notebook with jupyter-client from noble > release (version 7.4.9-2, same as in debian), then it succeeds. > I don't know why jupyter-client was updated to 8.6.0[4] ahead of > debian. So far, I have exhausted my troubleshooting on this issue. I > suppose we could remove src:jupyter-client 8.6.0-0ubuntu1 from > noble-proposed, as that could help with the python3 migration. Given the uploader and the timing, I suspect this was done to get jupyter-client itself to be sorted for the python3.12 transition. Can you verify that the previous version of the package in Ubuntu builds in noble? See also https://bugs.debian.org/1059658 -- 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 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: git-ubuntu MP workflows in Launchpad
On Fri, Feb 16, 2024 at 03:33:26PM +, Robie Basak wrote: > Bryce mentioned the difficulty of removing the slot. Unfortunately > there's no UI for this, but I did confirm today that it can be done by > API. I wrote a quick script so that we can do it easily if needed: > https://git.launchpad.net/~ubuntu-server/+git/ubuntu-helpers/tree/rbasak/clear-review-slot.py Please submit this to ubuntu-dev-tools :-) Thanks, -- 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 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: +1 maintenance report
Hi Sergio, On Fri, Jan 26, 2024 at 06:31:39PM -0500, Sergio Durigan Junior wrote: > * r-bioc-savr > - There's an RM bug against the package on Debian. I didn't touch the > FTBFS. However, Debian package removal requests take an indeterminate amount of time to be acted on by the ftp team, and in the meantime this leaves the package in update_excuses for other folks to lose time on. In cases such as these, please either: - talk directly to an archive admin in realtime to have the package removed from -proposed (a pointer to a Debian removal bug is sufficient rationale for a removal), or - file a bug tagged update-excuse that documents the situation, pointing to the Debian bug and subscribing ubuntu-archive to it so it can be handled asynchronously. Shameless plug: https://code.launchpad.net/~vorlon/ubuntu-dev-tools/+git/ubuntu-dev-tools/+merge/444677 gets you halfway there on the bug filing ;) In this case, it appears that in the meantime Debian has decided to fix the package rather than removing it, so no further action is required now by the Archive Team. > * repowerd > - Investigated a bit. I can build the package locally but it fails to > build on LP due to dh_missing complaining. Are you using up-to-date debhelper on noble? There have been recent changes in debhelper's handling of systemd units, precisely for the /lib vs /usr/lib question. Thanks, -- 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 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: libgcrypt20 delta now dropped
On Tue, Jan 16, 2024 at 12:38:51PM +0100, Julian Andres Klode wrote: > Just to point out I synced libgcrypt20 from Debian now, which > drops the delta that enables FIPS mode that we had in past relases > where libgcrypt20 was not FIPS-enabled. > > This was preceeded by a long internal discussion and we've come > to the conclusion this patch is no longer needed. > > Notably, if you really enable FIPS, nothing changes: You get a > certified libgcrypt20 from a PPA anyway. > If you enable FIPS flag in the kernel without using the FIPS PPA, > for example, by running in a container on a FIPS host, you > libgcrypt20 will now operate in FIPS mode, which may cause > behavioral changes. Sorry, was this a typo and you meant to say "not operate" rather than "now operate"? If the delta we were carrying was to enable FIPS mode, and we are dropping the patch, it would seem to have the opposite effect to what you've written. -- 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 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: Is there a good solution for this: release-upgrade with dependency moved to universe
On Fri, Jan 12, 2024 at 11:05:24AM -0500, Nick Rosbrook wrote: > Hi, > > I guess something in do-release-upgrade could be run to, when encountering > > such a situation, automatically select bin:samba-vfs-modules-extra for the > > upgrade as well? Is it worth it? Is there a precedence for something like > > this? And how would this be done in a more generic/general case, if at all? > We have the concept of "quirks"[1] in ubuntu-release-upgrader which > allows us to handle special cases like this. For example, a cycle or > two ago when flatpak was removed from flavor seeds, we added some code > to not auto-remove flatpak if it appeared the user was actively using > it. So yes, if nothing else we could add a quirk to make sure > samba-vfs-modules-extra is installed upgrades if samba-vfs-modules is > currently installed. I want to weigh in here to say that I think we should NOT do this by default. In my view, every difference between "Install Ubuntu release X; upgrade to Ubuntu release X+1" and "Install Ubuntu release X+1" is a bug. These bugs vary in severity, and we'll probably never zero out the list of such bugs. But we should not knowingly *introduce* such bugs through quirking. This should also apply to "Install Ubuntu release X; apt install Y; upgrade to Ubuntu release X+1", when not modifying any configuration files along the way (though the severity of such a bug should also understandably be lower). If it's possible to detect that the system in question is *using* glusterfs, and add a quirk at runtime to install samba-vfs-modules-extra, then I think this sort of change is ok. Otherwise, I think the right answer here is: behavior changes on upgrade between releases, and the release upgrade is the time for the user to discover this is the case and deal with it (as part of a maintenance window). Otherwise, you're really just shifting the pain. Ubuntu X went EOL, I have to reinstall, I install Ubuntu X+1 which is what I had installed before, why are things behaving differently?! -- 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 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: NBS kernel removals: round three
On Tue, Dec 19, 2023 at 08:20:04AM -0800, Steve Langasek wrote:
> On Sun, Dec 10, 2023 at 05:22:37PM -0800, Steve Langasek wrote:
> > Removing obsolete NBS kernels from trusty as described in June [1] went
> > without any problems being reported.
> > I am therefore planning to proceed with the same cleanup now of NBS kernels
> > from xenial-{updates,security} older than 4.4.0-210.242.
> > As pointed out when preparing the trusty removals, we want to retain those
> > kernels that were used in the debian-installer builds for the final point
> > release of xenial. For debian-installer 20101020ubuntu451.29 in 16.04.7,
> > this was 4.4.0-186 and 4.15.0-112; for debian-installer 20101020ubuntu451.28
> > in 16.04.6, this was 4.4.0-142 and 4.15.0-45; both need to be retained
> > because 16.04.7 was an update only for UEFI architectures (amd64 and arm64).
> > I am planning to start removing the other NBS kernels from xenial this
> > coming Friday, December 15.
> This didn't happen quite on schedule, but has been running since the 17th
> (local time).
And the removals completed sometime over the holidays. I haven't heard any
complaints so far. Happy New Year :)
--
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
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: NBS kernel removals: round three
On Sun, Dec 10, 2023 at 05:22:37PM -0800, Steve Langasek wrote:
> Removing obsolete NBS kernels from trusty as described in June [1] went
> without any problems being reported.
> I am therefore planning to proceed with the same cleanup now of NBS kernels
> from xenial-{updates,security} older than 4.4.0-210.242.
> As pointed out when preparing the trusty removals, we want to retain those
> kernels that were used in the debian-installer builds for the final point
> release of xenial. For debian-installer 20101020ubuntu451.29 in 16.04.7,
> this was 4.4.0-186 and 4.15.0-112; for debian-installer 20101020ubuntu451.28
> in 16.04.6, this was 4.4.0-142 and 4.15.0-45; both need to be retained
> because 16.04.7 was an update only for UEFI architectures (amd64 and arm64).
> I am planning to start removing the other NBS kernels from xenial this
> coming Friday, December 15.
This didn't happen quite on schedule, but has been running since the 17th
(local time).
--
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
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
NBS kernel removals: round three
Removing obsolete NBS kernels from trusty as described in June [1] went
without any problems being reported.
I am therefore planning to proceed with the same cleanup now of NBS kernels
from xenial-{updates,security} older than 4.4.0-210.242.
As pointed out when preparing the trusty removals, we want to retain those
kernels that were used in the debian-installer builds for the final point
release of xenial. For debian-installer 20101020ubuntu451.29 in 16.04.7,
this was 4.4.0-186 and 4.15.0-112; for debian-installer 20101020ubuntu451.28
in 16.04.6, this was 4.4.0-142 and 4.15.0-45; both need to be retained
because 16.04.7 was an update only for UEFI architectures (amd64 and arm64).
I am planning to start removing the other NBS kernels from xenial this
coming Friday, December 15.
Thanks,
--
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
[1] https://lists.ubuntu.com/archives/ubuntu-devel/2023-June/042589.html
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: Running Britney locally against a PPA, how to keep Britney from thinking my PPA package is in main?
On Thu, Dec 07, 2023 at 06:20:58PM -0600, Aaron Rainbolt wrote: > So... if I'm understanding correctly, it's sufficiently safe for me to > request the signon package to be synced from Debian into Ubuntu? Yes, this is the normal and default process. > If so, I'll file a sync request bug report, then watch for fallout once > the package lands in -proposed. If it breaks things, I can work on fixing > them, and if it *really* breaks things, we can revert to the original > version via a +really upload, I believe. I just wanted to have everything > go as smoothly as possible. We typically wouldn't even do a +really upload, but instead just remove the broken version from -proposed. -- 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 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: Running Britney locally against a PPA, how to keep Britney from thinking my PPA package is in main?
On Thu, Dec 07, 2023 at 03:11:31AM -0600, Aaron Rainbolt wrote: > For this reason, I need to have every reverse dependency autopkgtested > against the new signond packages in a PPA, lest I severely clog up the > archive. You really, REALLY don't. Pre-upload autopkgtesting in a ppa is, with few exceptions, a waste of resources. The tests are going to get re-run anyway in the actual archive, and unless it's a library with an ABI transition (== binary package rename) and a VERY LARGE list of reverse-dependencies, there's no reason to double-run the tests on the off chance that you need to fix some tests before the package can land. The signon source package has three runtime library packages with less than a dozen reverse-dependencies between them, AND the signond source package in Debian doesn't introduce any ABI changes. From a proposed-migration perspective, this is all unnecessary busywork. > I've decided to take the most painful but accurate way > possible to get a list of packages that need autopkgtested, and that is to > set up a local Britney instance following the instructions at > https://wiki.ubuntu.com/ProposedMigration/LocalSetup. While it may be the most painful way, it does nothing for you with respect to accuracy unless your package is in the very short list of packages that have customizations to their autopkgtest trigger handling in the britney source code (britney2/policies/autopkgtest.py:tests_for_source() ). You're not uploading gcc or a kernel, so that's not relevant here. If I *did* need a list of packages to trigger tests for, I would: - run `reverse-depends src:signon` - map those to source packages - merge with the output from `reverse-depends src:signon -a source` (which would include any packages that declare a testsuite dependency - in this case, none) I would definitely not spend time hacking on britney for this. > * Create a new component named "universe" in my PPA and upload to it. That > seems like it would be a relatively clean and easy solution, but I have > absolutely no clue how I would go about doing this, and suspect it's not > even possible. It is not possible. -- 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 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: Merge ubuntu-motu@lists into ubuntu-devel-discuss@lists?
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? -- 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 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: [ubuntu-studio-devel] "Support Plan" request challenge (WAS: Ubuntu Studio LTS Re-Qualification)
On Fri, Nov 24, 2023 at 12:20:53AM -0600, Aaron Rainbolt wrote: > SRUs in packages used by flavors (including flavor-specific packages) are > also common. Speaking as a member of the SRU Team as well, I don't actually see evidence of this. There has been a run of SRUs right at the time of the mantic release, related to release upgrades; and there was also a recent Lubuntu SRU to lunar to fix *notifications* for release upgrades; but I can't think of any other examples in the past few years. This might be because it happened that all of them were processed by other members of the SRU Team, but that's statistically unlikely. From my perspective, SRUs of core packages in main are much more common. Can you point to something I've missed showing that flavor package SRUs are happening? (I think this is very relevant to the question of LTS qualification, because demonstrating a track record of active maintenance of the stable release of a flavor goes a long way to establishing that the flavor team is delivering something that meets users' needs for an LTS.) -- 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 signature.asc Description: PGP signature -- ubuntu-studio-devel mailing list ubuntu-studio-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel
Re: [ubuntu-studio-devel] "Support Plan" request challenge (WAS: Ubuntu Studio LTS Re-Qualification)
On Thu, Nov 23, 2023 at 02:10:54PM -0800, Erich Eickmeyer wrote: > Hi Lukasz, > I'm a bit taken-aback by the "support plan" request as for 20.04 LTS and > 22.04 LTS this was never requested, and so as far as I know we would have to > start from scratch. Since I'm basically on the technical side for two > flavors now, I have to wear both those hats and come up with that policy for > both. Unfortunately, this wording for "support plan" is too vague and needs > to be more specific. Guidelines for Tech Board to designate flavor image as LTS * Flavor's support plan presented to Tech Board and approved; support plan should indicate period of time if beyond 18months (3yrs or 5yr), key contacts, and setting expectations as to level of support. https://wiki.ubuntu.com/RecognizedFlavors?action=recall=5 This has been documented since 2011 as the standard to which flavors are expected to be held. If previously the Technical Board has been lax in requiring this, that is not binding on the TB now. The flavor communities for official Ubuntu flavors ARE expected to support the flavors to their users for the lifetime of the release. Rhetorically speaking, you should not be expecting to throw a release over the wall as a one-time artifact image and wash your hands of it. This is all the more important for an LTS release, because LTS *means* "long-term support". If a flavor wants to have an LTS designation (and participate in point releases), they need to be accountable to the larger Ubuntu community that this actually means something. If we get this wrong for a non-LTS release, the consequences are fairly minor. The user who installs a non-LTS image of a flavor is only promised support for 9 months; they are not promised that the flavor will be supported at all as part of the next 6-monthly release. The flavor could sunset in that time and there be no metapackage they can even upgrade to. And if the flavor community fails to support their flavor for the full 9-month period, the impact on the rest of Ubuntu developers to pick up the slack is also likely to be minor. But if a flavor is an LTS release, meaning there is a public promise that it is supported for 3 or 5 years, then it needs to be clear to users what "supported" means for that flavor, and we need to be confident that the flavor community is actually in a position to deliver on that promise. With 10 distinct recognized community flavors, this is not something to be left to chance. > This just creates extra work for *volunteers* that are otherwise working > jobs (e.g. myself as a stay-at-home father/tutor for my son, my wife as a > full-time early childhood administrator). All currently recognized flavors are welcome to participate in the 24.04 release as non-LTS flavors, with no additional requirement to document a support plan. If a flavor finds it overly onerous to *document* their LTS plans, I think it's self-evident that they also should not be *calling* themselves an LTS because they don't actually have capacity to commit to support. > I challenge that this technical requirement crosses the line from > technical requirement into community encroachment, which is why the > Community Council is CC'd on this email. I have confidence that the Community Council will recognize that the LTS label, and the decision about committment of Release Team resources to point releases on behalf of flavors, is within the purview of the Release Team and the Technical Board to decide. > Also, do know that I see no ill-intent here as I do see good reasons for it, > but I feel as though requiring extra work for volunteers when there is no > precedent for something like this in the past seems like a bit of an > overreach and an extremely vague request (support can mean anything from > simple patches to 24/7 technical support which is a no-go). If there was > precedent, then there would already be documentation for each flavor, but I > believe a simple agreement for flavors to a blanket unified "support plan" > would be more appropriate rather than requiring each flavor to come up with > their own which would take more time and possibly definition than flavors > should have to come up with. We're not looking for an original essay here, we're looking for documentation of a credible and sensible plan. If you find it useful to coordinate with other flavors to synchronize your support committments, that's fine. And there is certainly prior art. https://lists.ubuntu.com/archives/technical-board/2016-April/002213.html -- 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 signature.a
Merge ubuntu-motu@lists into ubuntu-devel-discuss@lists?
Hi folks, There is a mailing list, ubuntu-m...@lists.ubuntu.com, that sees very little activity. While MOTU as a concept still exists for those who are approved uploaders to universe but not main (https://launchpad.net/~motu), it's been quite some time that this list is not being used for discussions within that subcommunity of developers. Indeed, I think most MOTU are probably not tracking the list at all, and a look at the message history over the past 6 months shows the only threads started on there are from users asking for help with one universe package or another. It's not clear to me how users are finding this as a contact address, but it's not a good experience for them; the list is infrequently moderated (I have the impression that it's less frequently than ubuntu-devel*), and there are only a handful of developers who answer on the list (myself, Robie, maybe a few others?). I'd therefore like to propose we close this mailing list and forward the address on to ubuntu-devel-disc...@lists.ubuntu.com, which at least has a larger subscriber base and is more likely to result in users getting help with their questions. Opinions? -- 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 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: Fetching source code in Ubuntu: apt source, pull-lp-source, and git-ubuntu
Hi Simon, Thanks for trying to move the experience forward on this. On Wed, Oct 04, 2023 at 02:08:00PM -0500, Simon Quigley wrote: > While this seems great at first, there's quite a few edge cases to consider. > After talking with Julian and Robie on IRC[2], an approach of automatically > adding a "Vcs-Clone" field via Launchpad was brought up. I would like to > further this discussion here, and ask a few specific questions: > - Is there an easy way for determining whether a given source package is > imported via git-ubuntu? The problem is not with having a method that is "easy", but one that is "cheap" (and also, one that works using only the information you already have available locally, i.e. apt indices). The suggestion of autopopulating VCS fields to the source package on the archive side seems like a good one to me, but it's not cheap to do that for all packages as part of a publisher cycle either. What would be the downside of just always telling users in the message where the git-ubuntu repository *should* be? By this point the archive coverage is quite good. The number of misses will be small. The language can account for this, and could even be written in such a way that we encourage a feedback loop to know which missing packages should be prioritized. > - Would it be appropriate to consolidate those messages, only giving the > "Vcs-Clone" field? Strong -1 for defining a new field for this. If we are going to change the Sources file at all, the existing "Vcs-Git" field already has the correct semantics. -- 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 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: dropping various grub targets
Hi Ian,
On Wed, Oct 11, 2023 at 08:30:14PM +0100, Ian Bruntlett wrote:
> Hi Steve,
> I can read ubuntu-devel messages but can't post replies to it...
You can reply but replies will be held until moderated.
I am happy to post this message to ubuntu-devel with your permission, to
keep the thread together.
> On Wed, 11 Oct 2023 at 00:13, Steve Langasek
> wrote:
> > To be clear, it would make a lot of things easier if we did determine we
> > could drop not only BIOS boot support from our images, but also El-Torito
> > ISO boot support treating these images as only for flashing on USB drives.
> > It would remove one significant barrier for us adopting ubuntu-image for
> > the
> > mastering of our installer images. But we should do the work to establish
> > that these things are no longer needed!
> How much work is involved in maintaining BIOS boot support for your images?
> I use various systems that are still BIOS based systems and losing BIOS
> support would be quite disappointing and bad for the environment.
> I *might* be able to help with keeping the BIOS boot support working. What
> exactly does it entail?
> I am mainly a C programmer who can write a bit of C++ who is planning to go
> deeply into C++ over the next couple of years.
>
> Assembly language does not frighten me... much. My degree's project was
> written as a combination of 8086 assembler and 68000 assembler. But that
> was some time ago.
The context here is that our official images are built using a horrible,
terrible, multi-phase pipeline that's implemented in piles of shell script
with 20 years of history and we'd like to jettison the whole thing in favor
of ubuntu-image, which uses a declarative format for describing disk
layouts.
But.
- we have no language yet for describing ISO9660 filesystems as images
- expressing that for both BIOS and UEFI boot is more complicated than just
for UEFI
- the only tool in existence that we know of that can get this right
("right") is xorriso and we would not necessarily want that as an external
dependency (or be able to drive it to DTRT from ubuntu-image declarative
yaml).
Also ubuntu-image is implemented in golang, so I'm afraid C and C++
experience doesn't help substantially here, sorry!
--
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
Re: dropping various grub targets
Hi Julian, On Thu, Oct 05, 2023 at 06:39:53PM +0200, Julian Andres Klode wrote: > some of us would like to drop the following grub targets > as we believe nobody uses them: > * grub-coreboot > * grub-efi-ia32 > * grub-firmware-qemu > * grub-uboot > * grub-xen > Optimally also: > * grub-efi-arm > As in we would like the targets remaining to be: > * grub-efi-amd64 > * grub-efi-arm64 > * grub-ieee1275 [dropping amd64 one, though; just keep ppc64el] > * grub-pc Why is it important to prune support for these targets? There is a lot of stuff in the Ubuntu archive where we have no proof it's being used, but we don't remove it unless it's become a maintenance burden. If you believe nobody uses these targets, then there must not be bug reports about them, so in what sense is it a maintenance burden to continue supporting them given that support for them exists upstream? Is there a proposal also to drop them in Debian? If not, doesn't this divergence itself represent a greater maintenance burden? I think the coreboot stuff remains an interesting target for potential future development and we shouldn't necessarily prune it just because it's currently unused. (grub-efi-ia32, well, I can agree it's probably better to drop. There is sadly hardware that requires it for boot, but we have never signed it for SecureBoot and never will; and we have never supported it in the installer and never will; so having the package in the archive in a sense just gives users false hope. I think this is less an issue now than it used to be, since the affected machines are by now also quite old.) > Please let me know if that makes sense, if I missed anything > (is anyone still using Xen?). I think it's worth ensuring we explicitly hear from the Server Team on this, but my experience is that even though xen is definitively in universe and not a target that we explicitly support, over the past years whenever we have done something that regresses Xen support, we hear about it from users. So my expectation is that Xen is a small but ongoing concern for the community. > We really should revisit the question of BIOS support for 26.04 > or 28.04. Our grub postinst isn't updating BIOS grub for anyone > anymore since boothole because stuff can break for BIOS systems > if you upgrade them so um yeah. BIOS is a risky platform. Well as the uploader of the change for <https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1889556>, my recollection was that this was intended to be a workaround for the immediate breakage with the grub postinst and not that we disable BIOS grub updates long-term. It is certainly programmatically possible to have a much more robust upgrade path for grub-install on a pc-i386 target and make upgrades possible again! And if you're going to consider dropping grub-pc support then part of the conversation needs to be about what sorts of hybrid boot support we choose to have on our installer images, because we know historically that there are machines which support UEFI when booting from internal hard disk but which will only do BIOS boot from external devices (optical media and/or USB stick). Just like 64-bit machines with 32-bit UEFI firmware, any such machines are relics; but it would still be a shame for Ubuntu to drop support for such hardware if it is otherwise still usable. To be clear, it would make a lot of things easier if we did determine we could drop not only BIOS boot support from our images, but also El-Torito ISO boot support treating these images as only for flashing on USB drives. It would remove one significant barrier for us adopting ubuntu-image for the mastering of our installer images. But we should do the work to establish that these things are no longer needed! -- 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 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: Retention period for autopkgtest test logs
On Wed, Sep 27, 2023 at 06:38:06PM -0700, Bryce Harrington wrote: > 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 This was a test plan proposed by the Server Team and accepted by the SRU Team. The SRU Team did not *ask* for pre-acceptance autopkgtests. > Tests run against PPAs are processed at a lower default priority than > the primary archive. There are no priorities on the queues. They are handled in round-robin fashion. So actually, PPA tests, by virtue of being fewer in number, have a higher prioritization than tests in the main archive. > 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? I believe the testing processes described are superfluous in most cases, and anyway it has been a full-time job to keep ahead of the infrastructure issues causing autopkgtests to get backlogged, so wishing for more consistent capacity doesn't really get us anywhere. > 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. Yes; the retention period itself is far less interesting to me than the reasons why, the former is Just some extra data in swift :) -- 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 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: Retention period for autopkgtest test logs
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. 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. -- 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 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: Retention period for autopkgtest test logs
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. The support for running autopkgtests for ppas exists to facilitate Ubuntu development, for things not yet landed in the main archive. It certainly shouldn't be used for long-lived PPAs whose contents are not targeted for inclusion in Ubuntu. -- 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 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: Migrating to deb822 sources on upgrade to Mantic
On Tue, Sep 19, 2023 at 03:25:47PM -0400, Nick Rosbrook wrote:
> > As a part of the effort to use deb822 sources by default in Ubuntu[1],
> > on upgrades to Mantic, ubuntu-release-upgrader will migrate
> > /etc/apt/sources.list to /etc/apt/sources.list.d/ubuntu.sources, and
> > /etc/apt/sources.list.d/foo.list to
> > /etc/apt/sources.list.d/foo.sources. This change has been implemented
> > and is now in mantic.
> The release goal to have deb822 by default in Mantic has been pushed
> back, hence ubuntu-release-upgrader will no longer migrate users to
> deb822.
> The deb822 sources are still usable, and apt will have no problem with
> them. The most notable blocker right now is that the
> software-properties UI cannot handle the deb822 format yet[1]. If you
> have already upgraded to Mantic, and would like to revert to the
> classic sources.list, you should be able to do so with:
> $ cp /etc/apt/sources.list{.distUpgrade,}
> $ rm /etc/apt/sources.list.d/ubuntu.sources
Is this entry in the mantic release notes still accurate?
* add-apt-repository now adds PPAs as deb822 .sources files (Improvements to
PPA management in 23.10)
--
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
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: First Mantic Minotaur test rebuild
On Wed, Sep 13, 2023 at 06:42:11PM -0300, Andreas Hasenack wrote: > > krb5 was a special case because its "internal" symbols used a prefixed name, > > so the glibc implementation was not a drop-in ABI-compatible replacement. > > For the common case, libraries are providing symbols with the literal names > > "strlcat" and "strlcpy"; if the build system detects these names in the > > system libc it will omit them at build time. Unless there's some extremely > > unusual linkage, reverse-dependencies that need this symbol will then just > > pick it up from libc6 instead. > > So if these library packages pick up a versioned Depends: on libc6 (>= 2.38) > > automatically, no further source changes should be needed. And if they > > don't have a versioned Depends: for some reason, it should be sufficient to > > manually add one. > We still need to address the removal of the strl* symbols from each > library package that previously had it in its d/*.symbols packages, > right? Should we settle on marking them as optional? Yes, you would need to update the .symbols files. I would recommend simply dropping them rather than marking them optional, since if they come back again that indicates a DIFFERENT problem. If you need something upstreamable to Debian, then you'll need to mark them optional since Debian unstable is still on glibc 2.37. -- 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 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: First Mantic Minotaur test rebuild
Hi Andreas, On Mon, Sep 11, 2023 at 05:37:05PM -0300, Andreas Hasenack wrote: > Hi, > > On Wed, Sep 6, 2023 at 6:19 AM Graham Inggs wrote: > > > > The first test rebuild of Mantic Minotaur was started on August 30, > > 2023 for all architectures, all components. The rebuild is finished > > for the main component on all architectures except riscv64, and still > > running for universe and multiverse. > > > > Results (please also look at the superseded builds) can be found at: > > > > https://people.canonical.com/~ginggs/ftbfs-report/test-rebuild-20230830-mantic-mantic.html > > Many of these failures are caused by glibc 2.38 now having strlcat and > friends, and this causes a dpkg-gensymbols error like this (example > from src:libqb): > Do we have a pattern to fix these, or a checklist? Mark them as > optional I suppose, but how can we be sure reverse dependencies aren't > relying on these strl* symbols, do we rebuild them all? It may sound > far fetched, but I suppose some application could have been relying on > strlcat from bin:libqb100 (even though it's not declared in > libqb-dev's /usr/include/qb/* anywhere). > > I saw the fix[1] to krb5's build issue, but there the symbol was > internal (but still exposed?). Is that what we need to apply, > including the replacing of #MINVER# in the symbols file to a strict > "equals", which is what I assume changes the shlibs:Depends from a ">= > MINVER" to "= $ver", and thus accounts for the ordering of upgrades? > And still a breaks for the other binary packages produced by the same > source? krb5 was a special case because its "internal" symbols used a prefixed name, so the glibc implementation was not a drop-in ABI-compatible replacement. For the common case, libraries are providing symbols with the literal names "strlcat" and "strlcpy"; if the build system detects these names in the system libc it will omit them at build time. Unless there's some extremely unusual linkage, reverse-dependencies that need this symbol will then just pick it up from libc6 instead. So if these library packages pick up a versioned Depends: on libc6 (>= 2.38) automatically, no further source changes should be needed. And if they don't have a versioned Depends: for some reason, it should be sufficient to manually add one. There had previously been mention on IRC of declaring Breaks: between libc6 and the packages. However, having thought this through just now I believe that's unnecessary, and also doesn't actually adequately solve anything. The versioned Depends: should be sufficient. -- 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 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
+1 maintenance, please look at NBS [Was: +1 maintenance report (Week of 2023-08-21)]
On Thu, Aug 31, 2023 at 02:40:55PM -0300, Athos Ribeiro wrote: > I was on +1 maintenance on the week of 2023-08-21. > I started the week using the Ubuntu archive tooling to re-triggering a few > tests and running the find-proposed-cluster script to find good candidates > to work on. Please keep the NBS report in mind as well: https://ubuntu-archive-team.ubuntu.com/nbs.html There has not been much progress on this list for roughly a month, and there are lots of packages here needing active attention of the kind that would not be blocked by a glibc migration :) Thanks, -- 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 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: +1 maintenance report (14/Aug - 18/Aug)
On Mon, Aug 21, 2023 at 02:28:50PM -0700, Bryce Harrington wrote: > > 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? If it looks like an OOM error only on armhf, retry it and see if it's reproducible. > 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? https://wiki.debian.org/ArchitectureSpecificsMemo is a good overview of architecture differences, which also applies to Ubuntu. It might be a good starting point for someone to create a doc that distills this for just the Ubuntu architectures. -- 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 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: +1 maintenance report (14/Aug - 18/Aug)
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. -- 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 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: Reducing initramfs size and speed up the generation
On Wed, Aug 09, 2023 at 05:30:04PM +, Benjamin Drung wrote: > > The benefits to this are that the firmware and base initrds only need be > > generated once regardless of number of kernels installed. And their > > generation is decoupled from kernel upgrades/installs and each other. > > So the firmware initrd only needs to be regenerated when the firmware > > package is upgraded, and that need not trigger the base initrd to be > > regenerated. Likewise, upgrading cryptsetup (or any other dependency of > > the base initrd) need not cause the firmware initrd to be regenerated. > > This approach could also be used with the early init microcode parts of > > the initrd. > This is an interesting idea. It raises some questions. > The list of firmware files to include in the initramfs is derived from > the kernel modules. Different kernel versions can require different > firmware files. How should that be handled with this approach? While it might be nice to further reduce the space requirements for /boot (especially in the face of ever-growing kernels+firmware), this question is precisely why I don't consider this viable. One of the properties of the current system is that installing new versions of packages that trigger regeneration of the initramfs for the most recent kernel should by default leave the initramfs for other kernels unmodified; this way, in the event of a regression, the last-known-good kernel can still be booted for recovery. If all of the kernels installed would be pointed at a common firmware initramfs that's pulled in by GRUB, then even in the case that the updated firmware package is *supposed* to be compatible with all the kernels on the system, it nevertheless loses this property that we haven't tampered with the last-known-good kernel and makes the system less resilient. We should prioritize resilience of boot recovery over reducing the size of /boot contents. 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 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: +1 maintenance shift (07/AUG - 11/AUG)
Hi Andreas, On Fri, Aug 11, 2023 at 06:40:16PM -0300, Andreas Hasenack wrote: > canonistack isn't an option. Why? Do we need to open RTs? -- 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 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: Flutter Installer and CUPS Frustrations
On Thu, Aug 10, 2023 at 06:58:54PM -0700, eeickme...@ubuntu.com wrote: > Furthermore, the switch to the CUPS snap is also affecting the flavors, > as this was done without any notification via proper channels (any > channel, really) before it was implemented. I understand there was a > discourse post, but I could not find any date as to when the > implementation would occur, so imagine my surprise when all the sudden > every single CUPS package was being removed. > Right now, there's no transition package, so daily .iso images are > simply being built without CUPS or any printing system unless flavors > add the following line to their seeds, and this is only an educated > guess on my part (!!!), so I could be very wrong: > * snap:cups I can't speak to the lack of coordination, but I can say that flavors are NOT meant to be making their own seed changes for this. The transition was done in the desktop-common seed and, in fact, was causing cross-flavor build failures when the seed change originally went through before all of the snaps were available on the required channels. $ grep snap:cups */daily-live/current/*.manifest kubuntu/daily-live/current/mantic-desktop-amd64.manifest:snap:cups stable/ubuntu-23.10 980 lubuntu/daily-live/current/mantic-desktop-amd64.manifest:snap:cups stable/ubuntu-23.10 980 ubuntu-budgie/daily-live/current/mantic-desktop-amd64.manifest:snap:cups stable/ubuntu-23.10 980 ubuntu-unity/daily-live/current/mantic-desktop-amd64.manifest:snap:cups stable/ubuntu-23.10 980 ubuntu/daily-live/current/mantic-desktop-amd64.manifest:snap:cups stable/ubuntu-23.10 980 ubuntu/daily-live/current/mantic-desktop-arm64.manifest:snap:cups stable/ubuntu-23.10 981 ubuntucinnamon/daily-live/current/mantic-desktop-amd64.manifest:snap:cups stable/ubuntu-23.10 980 ubuntukylin/daily-live/current/mantic-desktop-amd64.manifest:snap:cups stable/ubuntu-23.10 980 xubuntu/daily-live/current/mantic-desktop-amd64.manifest:snap:cups stable/ubuntu-23.10 980 $ Evidently there is something different in the way desktop-common is being handled for Edubuntu and Ubuntu Studio, that it's not being seeded there. -- 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 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: Duplicate Requests in autopkgtest-cloud
On Fri, Jul 28, 2023 at 10:01:50AM +0100, Tim Andersson wrote: > Hi Steve, > This is something I missed in the initial implementation, but there's now > an MP for a fix ready to go into master. Right now, however, I've hotfixed > prod so that if you pass `all-proposed`, the duplicate request check is > disabled. I made this quick change to unblock ginggs Excellent, thank you! > On Fri, Jul 28, 2023 at 5:19 AM Steve Langasek > wrote: > > > Hi Tim, > > > > On Thu, Jul 27, 2023 at 11:10:05AM +0100, Tim Andersson wrote: > > > Hi all, > > > > > In the Ubuntu QA team we recently made and deployed a change which now > > > makes it impossible to queue duplicate requests. > > > > > If a request is currently in the queue, or is currently running, and you > > > request the same test, you will be taken to an error page which tells you > > > the test details and whether it is currently queued or currently running. > > > It looks like this: > > > ``` > > > > > > You submitted an invalid request: > > > > > > Test already queued: > > > > > > release: lunar > > > > > > pkg: gzip > > > > > > arch: arm64 > > > > > > triggers: gzip/1.12-1ubuntu1 > > > > > > ``` > > > This is to try and ease the load on autopkgtest-cloud. > > > > > If you experience any bugs or unexpected functionality, please file a bug > > > against `autopkgtest-cloud` and let us know. We expect it to work > > > seamlessly but always expect the unexpected right :) > > > > Does the code also properly distinguish between tests queued with > > proposed=1 > > and those without, so that it's possible to queue both ways in parallel? > > > > Thanks, > > -- > > 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 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: +1 maintenance report
On Fri, Jul 28, 2023 at 05:43:36PM +0100, Robie Basak wrote: > # rust-block-padding > I didn't really make sense of this. How is a build of > rust-block-buffer-0.9 resulting in a binary > librust-block-buffer-0.9+block-padding-dev that has a versioned binary > dependency on librust-block-padding-0.2+default-dev without a build-dep > on something from rust-block-padding? I could dig deeper but I moved on > for now. Rust packaging uses helpers that autogenerate Debian package metadata from the upstream crate metadata. This includes declaring dependencies on various other crates that are used when building against this package (possibly in an optional non-default configuration), that are not necessarily needed at build time (since the binary package is a -dev package that basically contains rust source files, the runtime deps don't necessarily need to be present as build-time deps). So this is a very common pattern for rust packages. -- 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 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: Duplicate Requests in autopkgtest-cloud
Hi Tim, On Thu, Jul 27, 2023 at 11:10:05AM +0100, Tim Andersson wrote: > Hi all, > In the Ubuntu QA team we recently made and deployed a change which now > makes it impossible to queue duplicate requests. > If a request is currently in the queue, or is currently running, and you > request the same test, you will be taken to an error page which tells you > the test details and whether it is currently queued or currently running. > It looks like this: > ``` > > You submitted an invalid request: > > Test already queued: > > release: lunar > > pkg: gzip > > arch: arm64 > > triggers: gzip/1.12-1ubuntu1 > > ``` > This is to try and ease the load on autopkgtest-cloud. > If you experience any bugs or unexpected functionality, please file a bug > against `autopkgtest-cloud` and let us know. We expect it to work > seamlessly but always expect the unexpected right :) Does the code also properly distinguish between tests queued with proposed=1 and those without, so that it's possible to queue both ways in parallel? Thanks, -- 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 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: Reducing initramfs size and speed up the generation
On Tue, Jul 11, 2023 at 01:17:27AM +0200, Benjamin Drung wrote: > If you want to test it yourself, you can find initramfs-tools > 0.142ubuntu7bd2 for mantic in my PPA: > https://launchpad.net/~bdrung/+archive/ubuntu/ppa What blocks this from being uploaded to mantic? AFAICS the behavior should remain unchanged for existing kernel+firmware packages, and it's therefore safe to push more widely. -- 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 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: Reducing initramfs size and speed up the generation
On Fri, Jul 21, 2023 at 07:33:58PM +0100, Dimitri John Ledkov wrote: > If it is a concern that v5.15 jammy kernel may potentially be used > after partial / incomplete upgrade to Mantic, we can opt into using XZ > compressed firmware or I can backport ZSTD firmware support to jammy > GA kernel - it is a trivial patch (given that ZSTD itself is otherwise > available and used by the jammy kernel). The scenario here is that the user has just upgraded to mantic, so they get the new linux firmware and the new kernel; they reboot to mantic, but there is a regression of some kind; they reboot back to the jammy kernel (which is the N-1 kernel on their system) to debug it, and that kernel has regressed support for their hardware because it can no longer load the needed firmware from the root filesystem. This is a realistic enough scenario that I think it is worth backporting the zstd support onto jammy's 5.15 kernel. Thanks, -- 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 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: Reducing initramfs size and speed up the generation
On Tue, Jul 11, 2023 at 01:28:28AM +0200, Benjamin Drung wrote:
> > > Okay. It works now. The not-compressed cpio archive must not be the last
> > > one. So the order is now:
> > >
> > > * AMD/Intel microcode cpio archive (on amd64)
> > > * compressed kernel modules / firmware (not compressed)
> > > * main cpio archive (compressed)
> > >
> > > I'll really stop now. For a first comparison, the firmware files need to
> > > be converted correctly. There are symlinks in /lib/firmware. So running
> > > following was not correct/enough:
> > >
> > > find /lib/firmware -name '*.bin' | while read -r fw; do
> > > sudo zstd -19 -z -o "${fw}.zst" "$fw"
> > > sudo rm "$fw"
> > > done
> > >
> > > If you want to help, hand me a correct conversion script.
> > Some filenames in /lib/firmware contain spaces. There are many more
> > files than .bin ones. A number of the files are readmes.
> > Recent changes in linux-firmware.git add "install-xz" and "install-zstd"
> > targets to make than will do what you want I guess. I haven't checked
> > that this was actually merged; it was discussed at least on 2023-03-01
> > on the mailing-list. It's probably the best path forward in any case.
> > In case it isn't merged, you can have a look at
> > https://lore.kernel.org/linux-firmware/20230301-fixes-and-compression-v2-0-e2b71974e...@gmail.com/T/
> I agree. The conversion script was just for a quick way to test. The
> clean approach would be to patch linux-firmware to produce two
> additional binary packages: linux-firmware-zst and linux-firmware-xz.
We need to find an upgrade path here that doesn't involve having to have
multiple linux-firmware binary packages with different compression types.
Ending up with three copies of the firmware in /lib on disk because of
different dependencies is not an improvement!
I understand the reason for being concerned about keeping uncompressed
firmware available is that not all kernels have support for compressed
firmware. However we should work out a path that lets us switch to
compressed firmware on releases where we know it's supported. What kernel
version introduced support for this?
--
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
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: Drop armhf for ovn package
Hi Frode, On Tue, Jul 11, 2023 at 08:44:58AM +0200, Frode Nordahl wrote: > Hello, > Debian has decided to mark the ovn package as 64-bit only [0] on the > back of [1]. > This is currently preventing proposed migration [2][3] in Mantic and > I'd like to propose we drop armhf for this package starting with > Mantic. Our policy is, broadly, to follow Debian maintainers on decisions of which architectures a package should be supported on. I've removed the binaries now. This isn't something that needs discussion on ubuntu-devel; it's fine to post here but a more lightweight process is to ask on #ubuntu-release on IRC for an archive admin to remove the binaries in such cases. -- 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 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: Reducing initramfs size and speed up the generation
On Sun, Jul 09, 2023 at 04:28:42AM +0200, Heinrich Schuchardt wrote: > > > Benjamin Drung schrieb am Sa., 8. Juli 2023, 02:19: > > > > Hi all, > > > > a year ago we changed the default compression and level for the > > > > initramfs to zstd -1. This fixed the very slow creation times on > > > > development boards (see bug #1958148), but that leads to bigger > > > > initramfs sizes that triggered other bugs (like bug #1842320). > > > > Big initramfs sizes can also fill up small sized /boot partitions easily > > > > (grooming the 850 initramfs-tools bugs revealed several such reports). > > > > Using xz -9 would give very good compression, but it takes very long > > > > (especially on slow development boards) and a lot of memory (good luck > > > > on Raspberry Pis with small memory like Pi Zeros). > > > > I propose following approach to address the drawback: Create cpio > > > > archives (compressed with xz -9) for the kernel modules and firmware > > > > files when building the kernel/firmware Debian package. Then ship those > > > > cpio archives in the package (or in a separate binary package). Then the > > > > CPU load it put on the builders. The cpio archives would contain the > > > > modules for MODULES=most. > > > > mkinitramfs will then look for those cpio archives and uses those in > > > > case they are present. Such a initramfs would look like this: > > > > * AMD/Intel microcode cpio archive (on amd64) > > > > * main cpio archive compressed with zstd -1 > > > > * kernel modules from the Debian package compressed with xz -9 > > > > * firmware files from the Debian package compressed with xz -9 > > > > After working on initramfs-tools as part my day job, my fingers were > > > > itching and I had to create a quick and dirty draft in my free night > > > > time. You can find the result of the last two hours in [1]. This draft > > > > has a mkinitramfs-kernel script that creates a cpio archive containing > > > > the kernel modules and firmware (that needs to be split later on). > > > > The lunar test result on my AMD Ryzen 7 5700G look promising: Building > > > > 6.2.0-24-generic-modules-most.cpio.xz takes around 90 seconds and is > > > > 54.9 MiB in size. Creating the initramfs speeds up from around 8.7 > > > > seconds to 3.5 seconds (saves 60 %). The size reduces from 133.1 MiB to > > > > 80.7 MiB (saves 39.4 %). So the boot needs 52.4 MiB less, but > > > > /lib/modules need 54.9 MiB for the cpio archive. > > > > The drawback is that building the kernel would take longer, the package > > > > takes more space on the archive and mirrors, and downloading them could > > > > take longer on slow connections. > > > > Implementing my proposal would be relative easy for initramfs-tools, but > > > > would mean some work for the kernel team. > > > > What do you think? > Will the user still be able to add further modules and will machine specific > configuration files (e.g. for booting from iSCSI) still be included into the > initrd? I think a robust implementation of this on the initramfs-tools side looks like: - identify all the contents that belong in the initramfs - among those contents, find all zstd-compressed files, if any, and store them in an uncompressed initramfs - put the rest of the contents in a compressed initramfs This would be compatible with kernel packages whether they are changed to ship zstd-compressed modules or not and allow for a smooth transition. -- 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 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: Reducing initramfs size and speed up the generation
Hi Heinrich, On Sat, Jul 08, 2023 at 10:44:58AM +0200, Heinrich Schuchardt wrote: > Hello Benjamin, > some of the Ubuntu supported boards (e.g. LicheeRV) have so little RAM that > a default initrd cannot be decompressed. Some boards may need modules that > are not in initrd by default. Can you clarify where exactly this limitation is? Is this because the system must have room in memory both for the original initramfs image as it is loaded into memory from disk, regardless of compression; plus an uncompressed copy used as the VFS? If that's the case, wouldn't having the kernel modules compressed inside of an uncompressed cpio archive reduce overall memory usage, because the unpacking of the initramfs doesn't uncompress these compressed files? > Benjamin Drung schrieb am Sa., 8. Juli 2023, 02:19: > > > Hi all, > > > > a year ago we changed the default compression and level for the > > initramfs to zstd -1. This fixed the very slow creation times on > > development boards (see bug #1958148), but that leads to bigger > > initramfs sizes that triggered other bugs (like bug #1842320). > > Big initramfs sizes can also fill up small sized /boot partitions easily > > (grooming the 850 initramfs-tools bugs revealed several such reports). > > > > Using xz -9 would give very good compression, but it takes very long > > (especially on slow development boards) and a lot of memory (good luck > > on Raspberry Pis with small memory like Pi Zeros). > > > > I propose following approach to address the drawback: Create cpio > > archives (compressed with xz -9) for the kernel modules and firmware > > files when building the kernel/firmware Debian package. Then ship those > > cpio archives in the package (or in a separate binary package). Then the > > CPU load it put on the builders. The cpio archives would contain the > > modules for MODULES=most. > > > > mkinitramfs will then look for those cpio archives and uses those in > > case they are present. Such a initramfs would look like this: > > > > * AMD/Intel microcode cpio archive (on amd64) > > * main cpio archive compressed with zstd -1 > > * kernel modules from the Debian package compressed with xz -9 > > * firmware files from the Debian package compressed with xz -9 > > > > After working on initramfs-tools as part my day job, my fingers were > > itching and I had to create a quick and dirty draft in my free night > > time. You can find the result of the last two hours in [1]. This draft > > has a mkinitramfs-kernel script that creates a cpio archive containing > > the kernel modules and firmware (that needs to be split later on). > > > > The lunar test result on my AMD Ryzen 7 5700G look promising: Building > > 6.2.0-24-generic-modules-most.cpio.xz takes around 90 seconds and is > > 54.9 MiB in size. Creating the initramfs speeds up from around 8.7 > > seconds to 3.5 seconds (saves 60 %). The size reduces from 133.1 MiB to > > 80.7 MiB (saves 39.4 %). So the boot needs 52.4 MiB less, but > > /lib/modules need 54.9 MiB for the cpio archive. > > > > The drawback is that building the kernel would take longer, the package > > takes more space on the archive and mirrors, and downloading them could > > take longer on slow connections. > > > > Implementing my proposal would be relative easy for initramfs-tools, but > > would mean some work for the kernel team. > > > > What do you think? > > > > [1] > > https://code.launchpad.net/~bdrung/ubuntu/+source/initramfs-tools/+git/initramfs-tools/+ref/ubuntu/prebuilt > > > > -- > > Benjamin Drung > > Debian & Ubuntu Developer -- 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 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: +1 maintenance report
On Fri, Jun 30, 2023 at 03:18:04PM -0400, Nick Rosbrook wrote: > # lua-resty-core (LP 2025072) [needs AA] > This package is uninstallable due to a dependency on > libnginx-mod-http-lua, which is not in the Ubuntu archive due to an > intentional removal (LP: #1986853). > lua-resty-core has no reverse dependencies, so I suggested that the > package be removed from the archive and added to the sync blacklist. Done. > # triton (LP 2025279) [needs sponsor] > This package FTBFS because the package has Build-Depends: > libmlir-14-dev mlir-14-tools llvm-dev, but llvm-dev on mantic gives > llvm-15-dev. This results in CMake not being able to find the correct > MLIRConfig.cmake, because it wants > /usr/lib/llvm-15/lib/mlir/cmake/MLIRConfig.cmake (which would be > shipped by libmlir-15-dev). > I have proposed a PR to fix this in Ubuntu, and forwarded to Debian. Added a question on the PR. > # rdflib-sqlalchemy (LP 2025166) [needs sponsor] > This package FTBFS because it is missing a Build-Depends: > python3-wheel, and also because of an error in dh_auto_test related to > calling pytest. > > I have proposed a PR to fix this in Ubuntu, and forwarded to Debian. Being reviewed by Utkarsh. > # mlpack (LP 2025291) [needs sponsor] > This package FTBFS in Ubuntu and Debian. Upstream changed the way they > install their python bindings during the build (using python3 -m pip > instead of setup.py), so the Debian build needs to be adjusted for > this. > I have proposed a PR to fix this in Ubuntu, and forwarded to Debian. Looks like this has been sponsored. 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 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: git-ubuntu MP workflows in Launchpad
On Thu, Jun 29, 2023 at 10:55:21PM +0100, Robie Basak wrote: > On Thu, Jun 29, 2023 at 02:36:06PM -0700, Steve Langasek wrote: > > I think the least-effort approach is for the handling of MPs for sponsorship > > to match the handling of bugs: ~ubuntu-sponsors is unsubscribed, and it's > > the responsibility of the submitter to re-subscribe them (and patch pilots > > have an obligation to make this clear with a comment). > It's worth noting that the sponsorship queue has a "person who last > commented" column that displays in bold if that person can upload the > package. For a first pass through the queue, one could ignore any row > where that column is bold. This is imperfectly equivalent to ignoring > MPs that are waiting on the contributor to take some action. That seems like it should work. It also looks like there are some bugs here, as http://reqorts.qa.ubuntu.com/reports/sponsoring/general.html currently displays juliank's name in italics instead of bold for lp:~enr0n/ubuntu/+source/triton:fix-lp2025279 which indicates "Ubuntu Developer, who can't upload the package in question" which of course is false? > Could it be used to address the fear of losing MPs, as well as the > desire not to waste every pilot's time on following up on MPs that are > actually waiting on the contributor? If it's not robust enough, what > could we do to help with that? The one case where this is currently suboptimal is if the last comment on the MP is from an Ubuntu dev saying it needs changes, but the submitter has pushed new changes addressing that feedback without leaving a further comment on the MP. An MP in such a state is ready for sponsorship team action, but would have the commenter's name in bold and per the above would be deprioritized. This could be addressed if the "last comment" field also checked whether there were commits newer than the last comment. But I think this is enough to be getting on with, even without that tweak. Thanks, -- 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 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: git-ubuntu MP workflows in Launchpad
On Thu, Jun 29, 2023 at 11:12:43AM -0700, Bryce Harrington wrote: > 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. This is my concern as well. An important part of patch piloting is identifying when a change is not ready for sponsorship, and sending it back to the submitter for revision. When this is done, it's on the submitter to re-submit it for sponsorship. If patch pilots have to track this, we are going to spend a lot of time polling MPs that are not ready for sponsorship. I think the least-effort approach is for the handling of MPs for sponsorship to match the handling of bugs: ~ubuntu-sponsors is unsubscribed, and it's the responsibility of the submitter to re-subscribe them (and patch pilots have an obligation to make this clear with a comment). A more clever approach would be to use a magic zero-member reviewer as Robie proposes, but to filter out any MPs from the sponsorship queue which have a negative review from a sponsor, and no further activity on the MP (either comments or commits) after that point. -- 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 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
+1 maintenance report: the reportening
Wound up not actually being out yesterday, so I got some more work done on +1 maintenance. So here's a second report! * `rust-diesel`: uninstallable on armhf because it depends on packages not built on any 32-bit arch. Added a build-dependency on these packages, so that the uninstallable binaries wouldn't be built; and forwarded to Debian for consideration (either they should add the build-dependency or drop the runtime dependency, either way). [LP: #2024059](https://bugs.launchpad.net/bugs/2024059) However, it appears `rust-diesel` has just started failing to build on all architectures, so I filed [Debian bug #1038138](https://bugs.debian.org/1038138) for that and removed the package from mantic-proposed. * `maxima`: FTBFS on ppc64el, but not in Debian; so tried rebuilding `gcl` with -O3 disabled but it still segfaulted. Dumped some information in [bug #2024061](https://bugs.launchpad.net/bugs/2024061) after trying a few more things, and gave up. * `cgreen`: unsatisfied versioned build-dependency on libbinutils; we had done a no-change rebuild once before but this didn't manage to migrate? So trying again. But also, it regressed in buildability on s390x, so filed [Debian bug #1038145](https://bugs.debian.org/1038145) about this. * `calligra`: build failure wasn't reproducible locally. Retried and it succeeded. * `rust-sequoia-net`: unpick build-dep chain `rust-sequoia-openpgp` -> `rust-nettle` -> `rust-nettle-sys`. Current `rust-sequoia-openpgp` needs the newer `rust-base64` in -proposed, but `rust-sequoia-net` needs the older one. Removed `rust-sequoia-net` from -proposed to let this settle out in Debian. * `python-cogent`: stuck in -proposed because Debian dropped 32-bit arch support and we have armhf binaries left behind; removed the binaries. * `eztrace`: [LP: #2016471](https://bugs.launchpad.net/bugs/2016471) identified that the test was broken because `libomp` was built with `-Bsymbolic-functions` but there was reluctance to disable this option. It's legitimate to build without `-Bsymbolic-functions` when a package in the archive needs to intercept internal library calls. [LP: #230460](https://bugs.launchpad.net/bugs/230460) is a prior example of this from when the hardening flag was introduced. Uploaded `llvm-toolchain-15` with a targeted change to disable `-Bsymbolic-functions` only for libomp, not for all of llvm. But it somehow didn't work. And somehow rebuilding `llvm-toolchain-15` with no relevant changes also [now fails](https://launchpad.net/~vorlon/+archive/ubuntu/ppa/+build/26313388). Giving up. * `opm-simulators`: stuck because the riscv64 build had been cancelled. Retriggered it, and it failed again with no build log. Between this and the changelog, seems like it might be OOMing the builders. Opened [a bug](https://bugs.launchpad.net/bugs/2024246). * Retriggered autopkgtests for packages involved in the `r-base` transition. There are packages not yet ready for the new `r-base`, but this makes clear which ones those are. -- 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 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: git-ubuntu build
Thanks for laying out your vision for the git ubuntu workflow. On Thu, Jun 15, 2023 at 01:57:58AM +0100, Robie Basak wrote: > After MP approval, the next obvious logical step is to upload it - > either yourself if you have permission, or by a sponsor. Currently > git-ubuntu doesn't implement this, so you have to generate a source > package yourself. "prepare-upload" is intentionally low-level to > automate the rich history preservation bit, and to allow for wrappers > like Steve's gu-build and any other custom workflows that established > developers have. As a high level interface I imagine that git-ubuntu > should implement something like "git ubuntu publish"[2] that just does > the right things from a git branch that is ready. > Steve mentioned that he wanted to do things with intermediate steps. I > definitely want this to be possible, but I don't think that the design > of the headline git-ubuntu subcommands should take these use cases into > account except as command line options where those make sense. For > example, "build-source" got replaced with "build -S" and we can keep > this. Where behaviour changes with flags don't make sense, I think we > should instead implement "expert level" subcommands as necessary > instead. I bristle at this being called an "expert" workflow, because it includes steps that I expect every Ubuntu dev to do before uploading to the archive :) That implies additional checkpoints beyond what you've outlined. I think every package (both source and binary) should be checked with lintian before being uploaded, and the uploader should review its output and make a conscious decision to ignore any errors. If building and uploading of a source package is a single operation in git-ubuntu, where does this check happen? There are various ways one can have a git repository that builds binaries successfully, but does not actually correspond to the source package that would be uploaded. E.g., deletions in git of files from the upstream source, which would be ignored by dpkg-source -b; source packages whose debian/rules clean target modifies the source (debian/control being a common one). At what point will the uploader have the opportunity to confirm that the git tree and the source package correspond to one another, and that the source package is what the uploader actually intends to upload? While git-ubuntu is still maturing, some developers might also want to review its output (debdiff? less foo.changes?) before committing. > I'm open to all of these becoming subcommands in the "official" tool. > But I'd like the "headline" subcommands to be focused on what git-based > Ubuntu development _should_ be like, hiding away complexity that can be > automated (eg. not making the user handle source packages when we can > use git instead) rather than still exposing the current arcanity of it > all. I think if we're being realistic, Ubuntu developers not dealing with source packages is years away, and will only be farther if in the meantime we don't provide a first-order git-ubuntu experience that we can confidently recommend to developers for the current setup. Buy-in and adoption of git-ubuntu as a tool is a necessary precondition for us getting away from working with source packages, so in my view we have to approach this incrementally. -- 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 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
breezy behavior wrt lp: [Was Re: git-ubuntu build]
On Wed, Jun 14, 2023 at 03:29:11PM +0200, Paride Legovini wrote: > Steve Langasek wrote on 13/06/2023: > > This is the following in my ~/.gitconfig: > > [url "git+ssh://vor...@git.launchpad.net/"] > > insteadof = lp: > > This configuration is described here: > > https://help.launchpad.net/Code/Git > > We should probably make sure it gets into some Ubuntu documentation and not > > just Launchpad documentation. > The drawback of this config is that with newer versions of Breezy it > gets in the way of Bazaar operations. The relevant change may be [1], in > Ubuntu since Lunar IIRC. > What happens is that Breezy finds the lp: shorthand and resolves it to a > Git URL, then fails if we were actually pointing it to a Bazaar repo. > For example this fails on my Mantic system if I use lp: for Git: > bzr branch lp:~ubuntu-core-dev/meta-release/ubuntu > I now use lpad: as a shorthand for Launchpad Git repos: > [url "ssh://par...@git.launchpad.net/"] > insteadOf = lpad: I had encountered this behavior, but hadn't realized it was on account of my own git config! For my part, I dug through the code and discovered that lp+bzr: (undocumented AFAIK) works to force the use of bzr. Since I do a lot more git checkouts that bzr from Launchpad these days (a trend that is only likely to continue), this is what I'm sticking with, reserving the shorter shortcut for git. -- 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 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: NBS kernel removals: round two
On Thu, Jun 01, 2023 at 12:55:36PM -0700, Steve Langasek wrote:
> Hi folks,
> Well, we found out that removing all NBS kernel packages for stable series
> was not altogether without its problems for users. We have modified the
> removal policy going forward in response to feedback.
> Meanwhile, in preparation for the move of bionic from standard support to
> ESM, the Release Team has noticed that NBS cleanup for ESM releases has so
> far been deferred until the releases go fully EOL.
> At this point, the *newest* kernel image in trusty-security is missing 3
> years of security updates. I believe it's therefore reasonable to require
> that users doing deployments of trusty today should do so using a kernel
> that is *no more than* 3 years out of date, before immediately enabling
> Ubuntu Pro and upgrading to a recent kernel security release.
> Consequently, I will be removing all kernel packages older than linux
> 3.13.0-170.220 from trusty-{updates,security} next week.
> I will leave xenial as-is for the moment, and send further mail before
> making any changes to NBS packages there.
Update: this has been done now.
No reports have reached me of any users adversely affected by the removals
of these old kernel binaries from trusty.
--
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
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
+1 maintenance report
ess. Uploaded hackish fix and forwarded to Debian. * `rust-ahash`: autopkgtests for the new version fail in both Debian and Ubuntu. Bug has already been reported in Debian with no response from the maintainer. Removed from -proposed. * `zulucrypt`: autopkgtests have regressed in Ubuntu; they aren't being run in Debian because they require machine-level isolation. Bug filed in Debian. * `ruby-jekyll-remote-theme`: failing network-dependent tests at build time. Talked with Lucas about how best to fix such things for ruby packages, he says he will take care of it via Debian. * `intelrdfpmath`: Ubuntu's compiler is stricter than Debian's at the moment, and this fails to build because of using sprintf() without bounds checking. Fixed to use snprintf(), you should never use sprintf(). However, -Werror=format-truncation fires even with snprintf(), so disable this error as well. Uploaded and forwarded to Debian. * `ruby-jekyll-github-metadata`: more network-based tests. Disabled in debian/ruby-tests.rake, uploaded, forwarded to Debian. -- 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 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: git-ubuntu build
On Mon, Jun 12, 2023 at 09:37:56PM +0200, Adrien Nader wrote: > > $ git ubuntu > > git: 'ubuntu' is not a git command. See 'git --help'. > > Next I try ` git clone lp:git-ubuntu` and get > > ssh: Could not resolve hostname lp: Temporary failure in name resolution > I think Steve has an SSH config which defines the "lp" host. What you'> This is the following in my ~/.gitconfig: [url "git+ssh://vor...@git.launchpad.net/"] insteadof = lp: This configuration is described here: https://help.launchpad.net/Code/Git We should probably make sure it gets into some Ubuntu documentation and not just Launchpad documentation. > I've quickly tried gu-build and I think it's young but probably has > promises. I tried it on a trivial merge from Debian by (iirc) git ubuntu > clone cdebconf, then git rebase pkg/debian/sid, and finally gu-build. > It feels a bit too automagic, especially because a) it does so many > steps that are typically described and done separately, and b) it pushes > the changes. Together these two elements mean that the command you use > to build and test also pushes the code but I usually like my mistakes to > not be pushed before I review them. Except that... fewer steps to think > about is exactly what's appealing to me with this. I feel this aligns with Bryce's comments about this being more of a 'submission' workflow. It is an important distinction that none of the other 'build' tools I mentioned involve pushing to a public repo. That's otherwise only done by 'bzr push', 'git push', 'dgit push', 'dput'. Would 'git ubuntu push' or 'git ubuntu submit' be a better name for this than 'git ubuntu build'? > I don't know if there exists steps in which the workflow can be split > into and that make sense both for computers which run the automation, > and humans who look at it. I hope such steps exist though. > PS: one improvement for gu-build would be to print to stdout the various > steps it goes through; a full, clean and pretty implementation is > probably fairly difficult but a crude one that is ~60% enough would > probably a matter of minutes. Any objections to this being under a --verbose flag? -- 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 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: git-ubuntu build
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: > > 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. $ 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') ^ $ So, it does *partially* exist, even though running 'git-ubuntu build' returns an error :-) > 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. :-) Yes, Robie and I have talked about this; adding tests was not a blocker for including it in a separate sandbox/ directory but will be for landing it as a git-ubuntu subcommand. I'll be working on adding tests shortly. > 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? 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. > > 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, an
Re: git-ubuntu MPs in the sponsorship queue
On Fri, Jun 09, 2023 at 12:32:38PM +0100, Robie Basak wrote: > On Tue, Jul 05, 2022 at 05:41:04PM +0100, Robie Basak wrote: > > I've arranged for MPs against git-ubuntu repositories to appear in the > > sponsorship queue[1]. > I was using the fact that ~ubuntu-sponsors is requested for review in a > git-ubuntu MP to make it appear in the sponsorship queue. But if > somebody in ~ubuntu-sponsors reviews (let's say with Needs Fixing) then > they "grab" that review slot, and ~ubuntu-sponsors no longer has one. I > think this might cause the entry to disappear from the sponsorship queue > - for example after the contributor has fixed the issue. > Any suggestions on what I should do instead? You don't have to claim the ~ubuntu-sponsors review slot to leave comments on an MP; indeed, unless you explicitly claim it on behalf of the team, it remains there. You can't add yourself as an additional reviewer, but I think that's fine, it should be one or the other - either you're claiming the review on behalf of ubuntu-sponsors and then it should be taken out of the queue and you should be responsible for following through, or you're *not* taking it out of the queue and then you also don't need to be listed as a separate approver. -- 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 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: Symbols files for C++ libraries for Ubuntu main
Hi Seb, On Fri, Jun 09, 2023 at 02:27:02PM +0200, Sebastien Bacher wrote: > I would like to ask if there is any chance the MIR team would reconsider > their position on the topic (at least until the day we have a somewhat > working solution we can use)? > which also included those types of changes > - _Znam@Base 2.0~b2-0ubuntu3 > + _Znaj@Base 2.0~b2-0ubuntu4 > +#MISSING: 2.0~b2-0ubuntu4# _Znam@Base 2.0~b2-0ubuntu3 > I personally don't understand why we have those symbols existing on armhf > which don't exist on amd64. Nor why _Znam@Base is becoming _Znaj@Base nor > how we are supposed to handle such cases Passing them through c++filt may help explain: $ echo _Znam@Base | c++filt operator new[](unsigned long)@Base $ echo _Znaj@Base | c++filt operator new[](unsigned int)@Base $ There are various C++ functions whose signature will change based on the architecture word length. .symbols files support various kinds of globbing etc to be able to express this logically (e.g., you could say '_Zna[mj]@Base' instead of listing two different symbols as optional), but as you've found, it's an onerous, iterative process to identify all the ways C++ symbols vary across architectures and then encode this in a .symbols file. And in this case, the symbol isn't part of the library's public ABI anyway, this is just a function from the base C++ library! > 4. doing those tweaks need to be done manually since it's not only applying > the diff but also adding optional keyword at places, I got one wrong and it > failed to build again > add one more symbol specific to risvc > http://launchpadlibrarian.net/647875197/libcupsfilters_2.0~b2-0ubuntu6_2.0~b2-0ubuntu7.diff.gz Yep. > I understand the motivation for wanting a symbol file but I agree with what > Robie, what's the benefit. In that case we spent a few hours to end up with > a .symbols which as over 150 '(optional)' entries, that doesn't protect us > much better than just not having a .symbols or using -c0 but still has a > high cost. I wouldn't say that it doesn't protect you. It's a pain to set up initially and as you note, you can even have to do further fix-ups as a result of toolchain changes, as the set of template functions and other C++ sugar from outside of the library that gets exported as ELF symbols can change. It DOES have a high cost, but in the end it provides the same level of protection against accidental ABI breakage as it does for C libraries. It would be nice to have better consistent tooling around ABI checking for C++ libraries. I think the KDE team had some tools around automating the generation of symbols files - it does require two passes, first to build on all archs and then to merge the results. But in principle that's better than whack-a-mole. We could also consider using abi-compliance-checker instead of symbols files for C++ libraries. There is a dh-acc debhelper addon, but I've never used it. We are currently using abi-compliance-checker for the ABI analysis of armhf for the move to 64-bit time_t; it's unmaintained upstream, but it does seem to work pretty well - the vast majority of issues we've encountered with it, when trying to run it over the entire Ubuntu archive, have been due to header files that #include headers from packages they don't depend on, or collections of headers that can't all be included together. Both of these are issues of much less significance when it's the maintainer doing the work. It would require the same sort of two-pass setup process as the KDE tools, though, and if it has to be done per-arch (probably), it's more awkward to set up because a-c-c .dump files aren't ascii that you can scrape from the build logs of failed builds - but it might be a more reliable tool over the long term than dpkg-gensymbols for C++ libraries. Downside: symbols files also let you track what version of a package a symbol was added in, which lets packages' versioned dependencies on libraries be no stricter than actually necessary. I don't speak for the MIR team, I have no objection to them relaxing the requirement of .symbols files for C++ libraries in main. Just offering some suggestions on how we can do a better job of automating C++ ABI checks than we're doing today. 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 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
debcheckout -a behavior in Ubuntu?
Hi all,
For those unfamiliar, 'debcheckout' is a tool in devscripts which is meant
to automate the traversal of Vcs-* metadata for Debian packages to let
developers check out the correct VCS repository for a package.
The 'debcheckout -a' option maps the Vcs-* fields to authenticated URLs for
known code hosting services, so that if you have commit access to the
repository, your checkout will be set up such that a push works out of the
box.
This is a useful tool in principle, and historically where packages were
maintained in Ubuntu we have taken care to populate Vcs-* fields in
debian/control to point to the right place.
The problem, from my perspective, is that I can't just trust 'debcheckout
-a' to do the right thing for me as an Ubuntu developer. I always have to
run 'apt-cache showsrc' first to check whether Vcs-* is pointing to a
suitable repo, to know whether I want to run 'debcheckout -a' or 'git-ubuntu
clone'.
I would like to fix this. I believe the desirable properties are:
- if I am running 'debcheckout -a' for a package that I have upload rights
on, I should get a checkout that I can push from, and the next Ubuntu
developer to do 'debcheckout -a' should see my changes, whether or not I
upload them to the archive
- if I do not have upload rights, running 'debcheckout -a' should give me a
checkout that shares commit history with the above, so that I can raise
sensible MPs
With the work on git-ubuntu support for staging branches happening this
cycle, git-ubuntu will soon satisfy this for the majority of packages in the
archive (but not yet). So I think the implementation we want - at the end
of this cycle - would be:
- if there is a Vcs-* field pointing to a repository in Launchpad, use that
- otherwise, call git-ubuntu clone
- if git-ubuntu clone fails (because the package is missing from the
importer), fall back to apt-get source
Now the reason I think this needs discussion before I just run off and
implement it is that I know some teams use ubuntu branches on
salsa.debian.org today for their work. But those repositories would be
unsuitable for the above workflow, because the ubuntu branch on salsa
doesn't know about Launchpad ~ubuntu-dev ACLs.
Do folks who use non-Launchpad repositories as the primary vehicle for their
packaging work mind if 'debcheckout -a' stops pointing at those
repositories? Should we add a new option to debcheckout ('--debian'?
'--upstream'?) to unconditionally follow the fields in debian/control?
Now, another place where the above implementation will give wrong results
today is that there are various Ubuntu-specific Vcs-* fields pointing at
launchpad branches that have effectively been abandoned and have not been
used for any recent uploads (stretching back for years). This is a problem
that can fix itself over time if more people are using debcheckout, as the
wrong metadata gets fixed - ideally, by grafting the repo history into the
git-ubuntu repos and then dropping the stale Vcs-* fields.
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
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
git-ubuntu build
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. 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. Enjoy, -- 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 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: +1 maintenance report
On Sat, Jun 03, 2023 at 10:43:41PM +0800, Shengjing Zhu wrote: > 3. librnd + camv-rnd + pcb-rnd > camv-rnd and pcb-rnd are in dep-wait status, it needs librnd > 4. > It's a small library transition. So I just ask @ginggs to kick off the > transition. > Also ask for revoking the blacklist for sch-rnd since it has stable release > now. https://launchpad.net/bugs/2007172 For the record, the ~ubuntu-archive team receives an unmanageable amount of email (I bitbucket all of mine). So I don't think anyone from the Archive Team saw your follow-up comment on this closed bug - I'm seeing it only because I read the +1 maintenance reports. Better to reopen the bug when commenting, or open a new bug. > 6. libs3 > FTBFS on ppc64el only. Caused by -Werror=stringop-overread. Looks like the > difference is -O3 vs -O2 build flags between Ubuntu and Debian. > Patch attached at https://launchpad.net/bugs/2021564 Followed up on the bug, thanks. > 8. kickpass > FTBFS on amd64 due to LTO. Caused by a pie patch which is added by the > Debian maintainer (Can be safely dropped). > Patch attached at https://launchpad.net/bugs/2021577 and forwarded to > https://salsa.debian.org/debian/kickpass/-/merge_requests/1 Uploaded > 12. beaker > > FTBFS due to tests relying on running redis server. > I don't think we can run a redis server during the build. The package > already ignores tests relying on mongodb server. So it should expand the > ignore list. > > Patch https://launchpad.net/bugs/2022332, forwarded to > https://bugs.debian.org/1037035 Uploaded. 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 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: NBS kernel removals: round two
On Thu, Jun 01, 2023 at 09:34:12PM +0100, Dimitri John Ledkov wrote:
> > Consequently, I will be removing all kernel packages older than linux
> > 3.13.0-170.220 from trusty-{updates,security} next week.
> I believe 3.13.0-165-generic is required to be published, as that's
> the one that is used by
> http://archive.ubuntu.com/ubuntu/dists/trusty-updates/main/installer-amd64/current/images/netboot/mini.iso
> and all the related boot artifacts.
> Also please ensure that 4.4.0-142 remains published too, as that one
> is used by the hwe-mini.iso and related boot artifacts.
> We should realistically continue to support the usage of the last
> installer we built
> https://launchpad.net/ubuntu/+source/debian-installer/20101020ubuntu318.46
> Apart from those two, all others can be cleaned up. Or set the above
> versions as the ceilings for removals of generic & lts-xenial kernels.
Thanks for pointing this out, I naively assumed that we had rebuilt d-i in
trusty against the last kernels published there before moving to ESM.
I've locally implemented a stay of execution for the above kernel package
versions.
--
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
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: +1 maintenance report
On Fri, May 26, 2023 at 09:40:02AM -0700, Simon Chopin wrote: > See https://bugs.launchpad.net/ubuntu/+source/rust-gio/+bug/2020880 > See https://bugs.launchpad.net/ubuntu/+source/rust-graphene-sys/+bug/2020902 Thanks for tagging these update-excuse! -- 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 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: incoming change to task handling in livecd-rootfs in mantic
On Mon, May 22, 2023 at 01:04:51PM +1200, Michael Hudson-Doyle wrote: > Thinking about this a bit more... what is germinate actually for in this > context? :-) > The way packages from a seed end up in an image goes like this at the > moment: > 1. it is listed in the seed > 2. germinate runs and puts the package and all its dependencies into a text > file > 3. live-build reads this text file and uses apt to install the packages > (4. we run mimimize-manual at some point so removing a seeded package and > running autoremove does something useful) > The thing about this is, *apt* obviously knows how to find the dependencies > of a package. Why don't we just shove the packages listed into the seed > straight into the file live-build reads? > (I suppose one answer might be to do with alternatives handling? cf > https://imgflip.com/i/7mmgcz -- does germinate do anything clever to > satisfy alternatives with a minimal number of extra packages or anything > like that?) It does not. Indeed, several of the recent seed changes made while landing this were to fix the fact that germinate from livecd-rootfs (though not when run on the archive) was seeding two conflicting implementations one of which satisfies all the dependencies. (Actually this was a virtual package rather than an alternative, but AFAIK it doesn't do anything clever with alternatives either!) I would expect feeding the list directly to apt rather than using germinate would result in some further changes to the exact packages included, which would then need to be examined to confirm they're what we want, since there are often multiple ways to resolve a seed. There's also the fact that you'd be reimplementing germinate's own parsing of the seeds and resolution of seed dependencies, so I'm not sure it's worth it? (One thing that would be nice, in addition to dropping the time-consuming use of germinate at runtime, would be that today germinate silently ignores listed packages that are unavailable, whereas apt would enforce correctness of the list...) > ((Clearly we need something like germinate to generate the component > mismatches reports. But maybe not at image build time?)) That's already run on ubuntu-archive-toolbox independently of the image builds, so would continue to do so. -- 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 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: +1 maintenance report
On Fri, May 19, 2023 at 05:53:54PM +0200, Benjamin Drung wrote:
> * Follow-up on Lukas Märdian +1 shift: matplotlib 3.6.3-1 was not
> synced. My sync was rejected: "same version already has published
> binaries in the destination archive". I did a fake sync by uploading
> 3.6.3-1fakesync1 with only the version number changed.
For future reference, copy-package from lp:ubuntu-archive-tools lets you
resuscitate source packages with their binaries, in this case by doing:
copy-package -b -s lunar-proposed --to-suite mantic-proposed -e 3.6.3-1 \
matplotlib
--
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
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: incoming change to task handling in livecd-rootfs in mantic
On Fri, May 19, 2023 at 11:38:22AM +0100, Iain Lane wrote:
> On Fri, May 19, 2023 at 09:05:28PM +1200, Michael Hudson-Doyle wrote:
> > After a few rounds of fixups, this change passed all tests and has now
> > migrated to release, so the next round of mantic image builds will be built
> > with it. Let me know if you see anything strange in them!
> Really nice, great work. This has been long overdue, glad it finally got
> sorted out.
> Although the backslash line was one of my favourite lines of code in the
> archive and I'll be sad to see it go. :-)
> I was reminded of
> https://bugs.launchpad.net/ubuntu/+source/livecd-rootfs/+bug/1921862
> When reading this thread. tl;dr is that it's not (was not at the time)
> possible to seed new packages post-release because germinate isn't being
> run for -updates in the publisher so the newly-seeded packages don't get
> Task headers. Would that be any more possible to achieve now? (For
> seeding only: *un*seeding is more gnarly, it involves knowing how to
> have -updates override release.)
The effect of this change is that we're not dependent any longer on the
Task: headers in the archive, so I *think* both addition and removal of
packages from the seeds will now be honored.
However, we're currently invoking germinate with "-d $SUITE" and I think we
need to change this to "-d ${SUITE},${SUITE}-updates" (with an added
${SUITE}-proposed when building with PROPOSED=1) to get germinate to look at
all the right pockets.
--
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
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: NBS removals of old kernels from stable -security and -updates pockets
On Fri, May 12, 2023 at 02:20:39PM +0200, Juerg Haefliger wrote: > > I am therefore intending that, for jammy and later releases, we start to > > prune NBS kernel packages on an ongoing basis, not just at EOL time. > We already have users complaining on IRC about missing kernel packages... What, specifically, are the complaints? > What is the official way/process for getting older packages for example for > crash dump analysis where one might need an older kernel+dbgsym from an > active series? Does the Ubuntu Kernel Team accept crash reports on out-of-date kernels? The general policy for apport is to disallow bug report submissions if the executable or any of the loaded libraries are from out-of-date packages. But it will still be possible to download these older packages from Launchpad: https://launchpad.net/ubuntu/+source/linux/+publishinghistory -- 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 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
NBS removals of old kernels from stable -security and -updates pockets
Hi folks, Kernel updates have an interesting property that, unlike most SRUs, the binary package names change for each update, because the ABI is presumed to change each time. The result of this is that each kernel update causes the binary packages from the previous version to become "NBS" (not built from source). Cleanup of NBS packages from the archive is a manual process involving Archive Admins; they are not automatically removed from the archive. And historically, we did not want to remove NBS kernel packages during a release cycle, because our netboot images relied on modules of matching ABI being available in the archive corresponding to the kernel ABI used in the netboot image - and as we did not control when our users deployed netboot images on their infrastructure, we did not want to arbitrarily break working customer systems, we did not remove NBS kernel packages as we went - only at EOL of a release. However, netboot images that rely on kernel packages of a matching ABI being available in the archive are an artifact of debian-installer, and as of jammy, we no longer ship debian-installer. Therefore, this rationale for retaining the old kernel binary packages in the archive no longer exists. Nearly 50% of all binary packages published in the jammy-updates pocket today are from kernels[1], and this proportion only increases as an LTS ages. I have not done the analysis, but I expect the kernel packages to represent a similar or higher proportion of the *size* of the -updates pocket. Thus, keeping these old binary packages around impacts both the speed of `apt update` for both -updates and -security pockets, and the size of the mirror set for these releases. I am therefore intending that, for jammy and later releases, we start to prune NBS kernel packages on an ongoing basis, not just at EOL time. -- 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 [1] $ grep-dctrl -r -FPackage 'linux.*[0-9]\+\.[0-9]\+\.[0-9]' \ -sPackage /var/lib/apt/lists/*jammy*updates*amd64*Packages | wc -l 6638 $ cat /var/lib/apt/lists/*jammy*updates*amd64*Packages | grep -c ^Package: 14243 $ 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: +1 Maintenance Report
removed now in Ubuntu. > byte-buddy (1.11.4-1 to 1.12.21-1) > This package needs a newer version of `libbyte-buddy-java (>= 1.12.22)` to > be synchronized into Ubuntu. This seems to not be the case as byte-buddy 1.12.21-1 has now migrated? > tinyssh (20190101-1ubuntu1 to 20230101-1) > The directory is world-writable by group or others: /home/ubuntu/.ssh/, > which causes the sanity check to fail. > We probably want to `chmod` the directory before the test. Nothing should be touching the user's home directory as part of a test. It's wrong for /home/ubuntu/.ssh to be writable by anyone but the user, but tinyssh autopkgtests shouldn't be rummaging around in the inherited $HOME - they need to set HOME to a temp directory! Overall, it seems that you looked at a large number of packages in -proposed, but that for most of them you stopped at analysis (which is useful) without preparing and submitting fixes for the issues identified. In the future, please focus more on the latter, as that's what's actually required to resolve the issues - few will read your email on ubuntu-devel in depth, fewer will remember what your analysis was (or be able to find it later). As a result, it's more efficient overall to work deeply on a small number of packages to drive them to completion, than to shallowly touch a large number of packages. Thanks! -- 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 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: +1 maintenance report
On Thu, Apr 06, 2023 at 05:59:46PM -0300, Lucas Kanashiro wrote: > This week is shorter than usual because of the holiday tomorrow, so I am > sending my report today: > ruby-mocha > == > > It is blocked by ruby-bourne for more than 3 months. ruby-bourne does not > support ruby 3.1 and it was removed from Debian testing. Requested its > removal (and ruby-terrapin as a reverse dependency) here: > > https://bugs.launchpad.net/ubuntu/+source/ruby-bourne/+bug/2015231 Removed, thanks. > ruby-moneta > === > > It is blocked by ruby-upr. ruby-upr was removed from Debian because > upstream is dead and it was also blocking ruby-moneta there. I filed > another removal request: > > https://bugs.launchpad.net/ubuntu/+source/ruby-upr/+bug/2015298 Removed > ruby-oauth2 > === > > It is blocked in -proposed because of ruby-github-api test failure. > ruby-github-api was already removed from Debian testing and unstable to > allow ruby-oauth2 migration. I'd say we need to do the same in Ubuntu, so > filed this removal request: > > https://bugs.launchpad.net/ubuntu/+source/ruby-jeweler/+bug/2015305 > > The ruby-oauth2 migration will also allow ruby-omniauth-google-oauth2 > migration. Removed! Thanks, -- 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 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: Question about submitting patches for repositories on Launchpad
On Thu, Mar 30, 2023 at 05:34:10PM +, Alexander Koskovich wrote:
> Steve Langasek wrote:
> > Which branches are you looking to submit to? There are lots of branches
> > that unfortunately we don't have monitoring of. MPs are great, but I
> > wouldn't want you to do work on one only to have it go nowhere because no
> > one is listening.
> I submitted my patch to the 'master' branch since that looked to be active
> development, ubuntu/devel seemed abandoned.
> https://code.launchpad.net/~nexusprism/curtin/+git/curtin/+merge/439880
> I have an MP here, is this the correct way to go about it, or would I need
> to seek sponsorship like you had mentioned?
Conveniently, curtin is a project whose upstream is maintained in Launchpad,
and you've targeted your MP to the correct branch - and there are sensible
default reviewers ("curtin developers" instead of, say "Ubuntu Core
Development Team" who do not receive launchpad email) so everything's on
track for this to be reviewed by the maintainers, there's nothing else you
need to do out of band.
--
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
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: Question about submitting patches for repositories on Launchpad
Hi Alexander, On Thu, Mar 30, 2023 at 03:03:10PM +, Alexander Koskovich wrote: > I'm fairly new to submitting patches for Ubuntu and I wanted to confirm > that I'm doing everything right inline with Ubuntu procedures. > I read that you should fork the original repository in Launchpad, upload > your commit to it, and open a merge request on the original repository. > This is fairly similar to GitHub, but I also read somewhere else that you > should submit the relevant patches through a mailing list? Just wanted > some clarification. Where did you read that patches should be submitted by email? Because that's definitely incorrect. > Also, if there's anything I would need to do on a merge request past just > pushing it to get it reviewed. Which branches are you looking to submit to? There are lots of branches that unfortunately we don't have monitoring of. MPs are great, but I wouldn't want you to do work on one only to have it go nowhere because no one is listening. The official process for getting patches included in Ubuntu is <https://wiki.ubuntu.com/SponsorshipProcess>. The sponsorship queue is sadly also under-managed at this time, so sometimes a ping on IRC (#ubuntu-devel@libera) or email is productive. -- 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 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
+1 maintenance report
nd forward to Debian. * `zulucrypt`: released in Debian because autopkgtests require machine isolation and are therefore skipped. But these tests passed on the previous Ubuntu version and now fail. Low confidence that this isn't a genuine regression, so moving on. * `meta-phosh`: depends on newer `gnome-calls` which is in Debian but hasn't been merged. Leave for next cycle. * `gmenuharness`: the single relevant change in the Debian update was to add a symbol to the symbols file - a C++ template symbol that isn't emitted on most Ubuntu archs. Marked the symbol optional, uploaded, forwarded to Debian. * `firefox-esr-mobile-config`: blacklisted with the rest of firefox debs. * `libsigc++-3.0`: mess of template symbols being listed in symbols file, causing build failures on various archs (specifically, LTO-enabled archs). Patched, submitted to Debian. * `cppad`: binary-indep build fails in Ubuntu and Debian. Removed from -proposed, let the maintainer take care of it. -- 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 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: Lowlatency Kernel is behind in Ubuntu Studio
not the final kernel for the release, so I don't see any reason that being at parity with the generic kernel in the release pocket *right now* would make a material difference to Ubuntu Studio's situation. -- 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 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: [ubuntu-studio-devel] Lowlatency Kernel is behind in Ubuntu Studio
not the final kernel for the release, so I don't see any reason that being at parity with the generic kernel in the release pocket *right now* would make a material difference to Ubuntu Studio's situation. -- 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 signature.asc Description: PGP signature -- ubuntu-studio-devel mailing list ubuntu-studio-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel
Re: Lowlatency Kernel is behind in Ubuntu Studio
On Mon, Mar 13, 2023 at 06:03:00PM +, Dimitri John Ledkov wrote: > > > We pushed 6.1 out, and migrated, on generic only, to migrate lots of > > > packages in proposed, specifically nvidia & everything entangled with > > > it, and thus unblock autopkgtesting of all the userspace packages > > > which were otherwise failing on v5.19. There is no intention to port > > > all flavours to 6.1. > > Again, this is one of the reasons we had do miss testing week among another > it was a mistake to skip testing week. you should have tested ubuntu > studio during the testing week like all the other flavours did. As > there are a lot of changes in lunar, that landed and affect ubuntu > studio. For example, all cloud images which use various cloud kernel > flavours, based on v5.19 did participate. > Can you explain who made the call to skip testing week? as to me, it > seemed, it's a requirement to release a flavour. Is studio going to > skip Lunar release? Testing week is not a release-team-driven activity and flavor engagement in it has no bearing on a flavor's eligibility for inclusion in a stable release. Flavors are required to hit a beta milestone and a release milestone. How they conduct their activities to ensure that these milestones are releasable is for them to decide. -- 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 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: [ubuntu-studio-devel] Lowlatency Kernel is behind in Ubuntu Studio
On Mon, Mar 13, 2023 at 06:03:00PM +, Dimitri John Ledkov wrote: > > > We pushed 6.1 out, and migrated, on generic only, to migrate lots of > > > packages in proposed, specifically nvidia & everything entangled with > > > it, and thus unblock autopkgtesting of all the userspace packages > > > which were otherwise failing on v5.19. There is no intention to port > > > all flavours to 6.1. > > Again, this is one of the reasons we had do miss testing week among another > it was a mistake to skip testing week. you should have tested ubuntu > studio during the testing week like all the other flavours did. As > there are a lot of changes in lunar, that landed and affect ubuntu > studio. For example, all cloud images which use various cloud kernel > flavours, based on v5.19 did participate. > Can you explain who made the call to skip testing week? as to me, it > seemed, it's a requirement to release a flavour. Is studio going to > skip Lunar release? Testing week is not a release-team-driven activity and flavor engagement in it has no bearing on a flavor's eligibility for inclusion in a stable release. Flavors are required to hit a beta milestone and a release milestone. How they conduct their activities to ensure that these milestones are releasable is for them to decide. -- 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 signature.asc Description: PGP signature -- ubuntu-studio-devel mailing list ubuntu-studio-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel
Re: +1 maintenance: 6-10 March 2023
tzdata > Two chrony tests are consistently failing on arm64, armhf, i386 and > ppc64el: 113-leapsecond and 124-tai > I picked the easiest of those arches to try to reproduce it locally > (arm64 it is), but it always works. Works in my pi4, on another bare > metal arm64, on a random arm64 VM someone let me use. I don't know > what's going on. This test suite runs each test multiple times (20), > and tolerates up to 2 failures. But these two tests are failing all > runs in the DEP8 infrastructure, and locally they all pass. > > # openjdk-XX > Tests affected by the ftpmaster.internal slowness. > > # python3.11 > $ python3-dbg-config --cflags --libs > /usr/bin/python3-dbg-config: 117: Syntax error: Unterminated quoted string > I filed https://bugs.launchpad.net/ubuntu/+source/python3.11/+bug/2009967 > with a patch. I would prefer if foundations uploaded this, as the > package is currently a sync, and I don't want to inadvertently start > another python-related massive DEP8 run. > > > 1. https://lists.ubuntu.com/archives/ubuntu-devel/2023-March/042500.html > > -- > 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 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: Fwd: +1 Maintenance report
On Fri, Mar 10, 2023 at 10:38:12PM +1300, Vladimir Petko wrote: > radare2-cutter vs radare2: radare2-cutter was failing to build due to > missing radare2.radare2 was removed due to obsolete dependency, > freebsd-glue. freebsd-glue was removed by Alex Murray and radare2 was > reuploaded. The package is in the upload queue. Once it is uploaded, > we can rebuild the radare2-cutter. Accepted, thanks! > nvda2speechd: package accesses the internet during the build and is > located in a non-free pocket. Raised a removal bug. Removed with prejudice. > nthash vs btllib: deadlock in btllib tests on armhf prevents the > package from building successfully. The deadlock happens because of an > integer overflow in the wait() condition. Documented finding in the > bug As an aside, it appears card has dropped support for using the system nthash package because of its reduced portability. So if we do get this resolved, we may want to let the Debian maintainers know they can revert that change. > node-registry-url vs node-package-json: looks like a generic issue - > nodejs tests use the HTTP agent that does not support proxy[2]. > autopkgtests only allow access through the proxy to external > resources. Probably an infrastructure question, whether package tests > flagged 'needs-internet' should have direct access. They don't get direct access, so the only real question is whether we automatically skip all packages that ask for Internet access, or if we instead manually mark as bad tests those that have requirements our testbeds don't meet. We can have the discussion with Debian about whether to have a more nuanced distinction between a 'needs-internet' restriction and a 'fails-to-honor-proxy' restriction, but that's certain to be longer-term. -- 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 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: Possibility of accepting a network-based installer of Ubuntu as an official flavor?
On Fri, Feb 24, 2023 at 02:20:25PM -0600, Aaron Rainbolt wrote: > This makes good sense to me. The concern I'm noticing here is that Secure > Boot activates a kernel lockdown mode that prohibits kexec. Incorrect. It disables the old kexec syscall which doesn't have an interface for doing signature verification of the payload. It does not disable the use of kexec as a feature. -- 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 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: Possibility of accepting a network-based installer of Ubuntu as an official flavor?
Hi Aaron, Łukasz and Dan have covered the details of the work in progress, so just a couple of notes: On Thu, Feb 23, 2023 at 09:53:16PM -0600, Aaron Rainbolt wrote: > My idea is to either write my own installer or use a customized version of > the existing Debian installer, and package it into a "flavor" of its own, debian-installer is a no-go for future Ubuntu development. It has impact on the maintenance of a large number of core packages, most significantly the kernel, and we have made changes to dpkg in Ubuntu to categorically skip building udebs. mini.iso dropped out of the archive as part of an explicit decision to discontinue support for d-i/udebs. Fortunately, we've identified a path forward for addressing these use cases that doesn't require this. > which would be capable of installing any supported version of any official > flavor of Ubuntu. The "flavor" would be able to be held in a very small ISO > file (preferably CD sized), and it would download and install all of the > packages that make up the Ubuntu system at runtime. I would not consider this a "flavor", any more than the previous mini.iso was a flavor. It's more flavor*less* and thus I don't see it as requiring to go through the community flavor approval process as it's not intended to be a version of Ubuntu, merely an artifact that is used to install Ubuntu. That said, unlike the previous mini.iso, we fully intend that this be a supported and tested image! And crucially, unlike the mini.iso which bypassed all of the installer logic in favor of raw package selection and therefore gave a different - unsupported - install result vs the installer on our full flavor images, this new mini iso will boot the actual flavor installer and so any divergences in the installed system would simply be a bug. 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 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: +1 maintenance report
On Mon, Feb 20, 2023 at 03:51:50PM +0100, Adrien Nader wrote: > Due to the size of the queues, I decided to start with the oldest > issues. Out of interest, how did you identify these "oldest issues"? I happened to spend some time on proposed-migration on Thursday, and all of the packages I worked on are older than the oldest package on your list, AFAICS. (The *youngest* package I worked on was node-object-inspect, which is currently 208 days old.) > # sparse > I'm under the impression that upstream doesn't run their own testsuite > at the moment. > For instance, there is a diagnostic which has been changed in 2019 in > 2094267c7d36d8696897c509558fc63e8a695765 and new testcases have been > added with that diagnostic but older ones have not been updated > accordingly (the one failing because of that change has been created in > 2018 and hasn't been changed since then). > All in all this seemed to much for a +1 shift and I didn't act on the > package. > > # blurhash-python > I tried to reproduce the issue which occured on armhf but I didn't > manage to. There were actually two different issues and that made me > think the issues were unrelated to this package. Due to the size of the > queues, I didn't ask for re-triggers. This package has since migrated. I guess someone did retrigger and it passed. Please don't be shy about retriggering because of the queues; the tests get run eventually... -- 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 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: +1 maintenance report
On Thu, Feb 16, 2023 at 02:35:51PM -0500, Sergio Durigan Junior wrote:
> >> * bcbio & mosdepth & nim-{unicodeplus,regex}
> >> - In -proposed for 95 days.
> >> - bcbio is FTBFSing because it B-D on mosdepth.
> >> - mosdepth is FTBFSing because it B-D on nim-regex.
> >> - nim-regex and its B-D nim-unicodeplus were removed because they B-D
> >> on nim, which (at the time) failed to build with openssl3.
> >> - nim now builds successfully.
> >> - I syncrequest'ed nim-{unicodeplus,regex}.
> >
> > Unfortunately these sync requests from Debian will fail, because
> > - a sync from Debian is a source-only sync
> > - these same versions have already existed in the Ubuntu archive in previous
> > series, so a binary sync is needed
> >
> > I've rejected the packages from the NEW queue and synced the package from
> > jammy with the following commands:
> >
> > $ copy-package --auto-approve -y -b -s jammy --to-suite lunar-proposed \
> > -e 0.17.0+ds-2 nim-regex
> > $ copy-package --auto-approve -y -b -s jammy --to-suite lunar-proposed \
> > -e 0.5.1-2 nim-unicodeplus
> Thanks. While at it, could you please copy nim-docopt from jammy as
> well?
Done.
--
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
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: +1 maintenance report
On Fri, Feb 10, 2023 at 01:58:56PM -0500, Sergio Durigan Junior wrote:
> * gatb-core
> - Debian dropped s390x from the list of supported architectures.
> - Pinged ubuntu-archive and asked them to reflect this decision so
> that britney lets the package migrate.
Missed in backlog while I was unavailable. This package has
reverse-dependencies on s390x so further surgery is needed. Please file a
bug with a complete analysis confirming the revdeps should also be removed.
$ reverse-depends src:gatb-core -a s390x
Reverse-Recommends
* med-bio (for gatb-core)
* med-bio-dev (for libgatbcore-dev)
Reverse-Depends
* bcalm (for libgatbcore3)
* discosnp (for libgatbcore3)
* discosnp (for gatb-core)
* mindthegap(for libgatbcore3)
* minia (for libgatbcore3)
* simka (for libgatbcore3)
$
> * php-laravel-lumen-framework & php-slim
> - In -proposed for 86 and 94 days, respectively.
> - These packages should be removed from Lunar. They have bugs filed
> for that (with ubuntu-archive subscribed), so I marked them as
> Triaged (as suggested by xnox) in the hopes that it helps moving the
> request forward.
FWIW marking it triaged had no effect here, my ubuntu-archive work list is:
https://bugs.launchpad.net/ubuntu/+bugs?field.subscriber=ubuntu-archive=NEW=Confirmed=Triaged=INPROGRESS=FIXCOMMITTED=INCOMPLETE_WITH_RESPONSE=-id
> * bcbio & mosdepth & nim-{unicodeplus,regex}
> - In -proposed for 95 days.
> - bcbio is FTBFSing because it B-D on mosdepth.
> - mosdepth is FTBFSing because it B-D on nim-regex.
> - nim-regex and its B-D nim-unicodeplus were removed because they B-D
> on nim, which (at the time) failed to build with openssl3.
> - nim now builds successfully.
> - I syncrequest'ed nim-{unicodeplus,regex}.
Unfortunately these sync requests from Debian will fail, because
- a sync from Debian is a source-only sync
- these same versions have already existed in the Ubuntu archive in previous
series, so a binary sync is needed
I've rejected the packages from the NEW queue and synced the package from
jammy with the following commands:
$ copy-package --auto-approve -y -b -s jammy --to-suite lunar-proposed \
-e 0.17.0+ds-2 nim-regex
$ copy-package --auto-approve -y -b -s jammy --to-suite lunar-proposed \
-e 0.5.1-2 nim-unicodeplus
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
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 change: rsyslog's apparmor enforced by default
Hi Andreas, On Sat, Feb 11, 2023 at 02:45:17PM -0300, Andreas Hasenack wrote: > Hi, > In the next few days, if all goes according to plan, I'll upload > rsyslogd to lunar with a change[1] to the way its apparmor profile is > applied. > The confinement status won't be changed during upgrades, but fresh > installs will have the apparmor profile enforced by default. Up until > now, it's been disabled. Can you elaborate on this decision not to change the behavior on upgrade? It's expected on upgrade between releases that behavior will change; and to not enforce for upgrading users means a difference in configs between new installs and upgrades that complicates the support matrix over the long term. I am strongly in favor of making the behavior on upgrade conform to the behavior on new installs - even if that means there might be some unpleasant surprises where the package fails to configure because of apparmor being enabled. That seems unlikely to me in any case; even if the user has diverged from the stock rsyslog config, it seems more likely to me that the daemon would still start up but might in some cases fail to log. Again, behavior changes are expected across release upgrades. -- 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 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: shim 15.7 and key rotation woes
On Thu, Jan 19, 2023 at 04:34:49PM +0100, Julian Andres Klode wrote: > Now how do we enforce that we don't update the shim on the ESP when we > don't have kernels trusted by it? One thing is clear: In the > maintainer script we need to check which kernels are signed by our CA > and see if all of them are in the revoked kernels (if you only have > self-signed kernels, or no signed kernels or whatever we don't care > about it in the context of this key revocation). > Option 1: Fail in preinst > This breaks a large apt upgrade in the middle leading to apport errors > and unconfigured packages on the system as apt doesn't complete > unrelated tasks necessarily. > Option 3: Alternatives > We ship both the latest and previous shim in shim-signed, install them > both as alternatives. If trusted kernels are around, the 'latest' > alternative gets priority 100 and the 'previous' gets priority 50; > without trusted kernels the priorities are reversed. > We then add a kernel postinst.d hook that swaps the priorities and > reconfigures shim-signed (installs it to the ESP) when a trusted > kernel is being installed. I am personally not convinced that it was necessary to avoid failing in the preinst. Given that kernels are always published to -security and security updates are by default installed automatically on a frequent cadence, I don't think the incidence of users having failures in the preinst would have been very high, and that even users who encountered the preinst failure would have done so as part of small upgrades within a release, not large upgrades where the preinst failure causes significant problems in recovering. However, you've implemented option 3 and, having reviewed it from an SRU perspective, I can't find fault with the implementation. So we'll move forward with this approach. -- 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 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: Setting NotAutomatic for hirsute+1-proposed
On Thu, Jan 19, 2023 at 01:44:12PM +0100, Gunnar Hjalmarsson wrote: > On 2021-01-21 11:20, Robie Basak wrote: > > https://wiki.ubuntu.com/Testing/EnableProposed will need a rework > > though. We link to that from every SRU bug. > That page was last updated on 2020-06-19, and is obsolete. Would be great i > someone could follow up the change and edit the Testing/EnableProposed page > so it makes sense again. Have you run into problems with the instructions on that page? I skimmed it and aside from mentioning "Selective upgrading from -proposed" which is redundant for newer releases, I don't immediately see anything incorrect there. If you can point out where it's wrong, I'll happily edit it to correct it but I don't have time just now to run through the full instructions there to find out what doesn't work. -- 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 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: Dropping /usr/share/zoneinfo/posix and /usr/share/zoneinfo/right from tzdata
On Mon, Jan 09, 2023 at 07:01:05PM +0100, Benjamin Drung wrote: > Hi everyone, > The tzdata package ships /usr/share/zoneinfo/posix/ (for Coordinated > Universal Time) and /usr/share/zoneinfo/right/ (for International Atomic > Time). The files in /usr/share/zoneinfo/posix/ are identical to their > counterpart in /usr/share/zoneinfo/. The tzdata package converts the > configured posix/* and right/* timezones to their unprefixed variant on > every package upgrade (e.g. it changes "posix/Europe/Berlin" to > "Europe/Berlin"). > Is there anybody actually using /usr/share/zoneinfo/posix or > /usr/share/zoneinfo/right? > Aurelien and I assume that probably nobody is using them. We plan to > drop both directories. If nobody speaks up, I will remove them in the > coming weeks from the Ubuntu tzdata package prior to the feature freeze. > After the Debian 12 "bookworm" release, we will remove it from Debian. In addition to fixing (or at least conflicting with) the bits identified via a code search (thanks, Shengjing!), I want to assert that the upgrade should take care of any references to these obsoleted compat links in /etc/timezone or /etc/localtime. Even if the debconf automation never presented these as options to the user, we shouldn't break the default system timezone on upgrade. You may already have this in your plan, so just making sure! -- 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 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
New +1 maintenance tool: find-proposed-cluster
Happy New Year!
One of my wishes for +1 Maintenance has been to have automated tooling to
answer the question for developers, "what is the next thing in -proposed
that it's a priority for me to work on?"
We're pretty far from this goal, but one small piece of it is to identify
clusters of packages in -proposed that all have to migrate together
("transitions") where relatively small amounts of work make a big difference
for unsticking -proposed.
As this is a very awkward question to answer by reading update_excuses.html,
I've (finally) written a helper tool, find-proposed-cluster, that analyzes
update_excuses.yaml for this, and have committed the tool to
lp:ubuntu-archive-tools.
Examples:
$ find-proposed-cluster
python3-defaults 261
qtbase-opensource-src 80
qt6-base 24
gnat 22
bctoolbox 10
$
$ find-proposed-cluster --limit 20
python3-defaults 261
qtbase-opensource-src 80
qt6-base 24
gnat 22
bctoolbox 10
fenics-dolfinx 8
rust-parking-lot 7
rust-cargo 6
rust-darling 5
rust-git2 5
deal.ii 4
dolfin 4
r-cran-spatstat 4
r-cran-sf 4
rust-html2pango 4
rust-bat 4
qt6-quick3dphysics 3
nvidia-cuda-toolkit 3
starjava-topcat 3
qtcharts-opensource-src 3
$
It's certainly not perfect; although I try to do deduplication, there are
still some duplicates as you can see above (e.g. qt6-quick3dphysics is part
of the qtbase-opensource-src transition). But it's a lot better than trying
to read update_excuses.html directly.
The number after the source package name is the number of additional
source packages identified as part of the cluster. It will never be less
than 3 - if you only have 3 packages in a group that have to migrate
together, it's not significant and it's better to focus on packages in
chronological order instead.
I've been using find-proposed-cluster in anger for about a month now, and
it's given me quicker insight into what's happening in -proposed that needs
attention.
Please kick the tires. Suggestions for improvement welcome.
Enjoy,
--
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
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: lxqt-sudo Ubuntu
On Fri, Dec 30, 2022 at 11:10:41AM +0100, André Verwijs wrote: > lxqt-sudo Ubuntu : > please update debug symbols package to 1.2.0 > Thank you The ddeb-retriever had been stuck since December 6, so ddebs.ubuntu.com was not being updated. I've restarted it, so these symbols should be picked up soon. -- 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 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: OpenLDAP 2.6 transition
On Thu, Dec 15, 2022 at 07:15:21PM -0500, Sergio Durigan Junior wrote: > On Monday, November 21 2022, I wrote: > > On Monday, November 21 2022, Steve Langasek wrote: > > > >> 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. > > > > Ah, no problem. It can wait. > > > >> Hopefully, the autopkgtest backlogs on arm64 and s390x will clear this week > >> and then we'll have a better view on what it takes to finish the above > >> in-progress transitions, and then rebuild anything still linking against > >> libldap-2.5-0. > > > > +1. Thanks, and enjoy your PTO. > Perl and Python have migrated, so I will go ahead with the no-change > uploads tomorrow. FWIW seeing that these hadn't been done yet and openldap had migrated (so all of the reverse-dependencies were on the NBS report), I went ahead and did uploads today of a filtered list of reverse-dependencies, excluding any of those that are currently in -proposed. Uploading those other packages won't cause entanglements between any remaining transitions, but it may slow down the migration of some of them, so I didn't upload them - but if you want to upload them now, there's no fundamental reason you can't. Remaining packages would be: Package gvm-libs already present in lunar-proposed (but not fixed) (Package gvm-libs not built in lunar-proposed) Package lua-apr already present in lunar-proposed (but not fixed) (Package lua-apr not built in lunar-proposed) Package openscap already present in lunar-proposed (but not fixed) Rebuilding openscap Rebuilding postgresql-14 Package sssd already present in lunar-proposed (but not fixed) (Package sssd not built in lunar-proposed) Package uwsgi already present in lunar-proposed (but not fixed) (Package uwsgi not built in lunar-proposed) Package virtuoso-opensource already present in lunar-proposed (but not fixed) (Package virtuoso-opensource not built in lunar-proposed) Package wine already present in lunar-proposed (but not fixed) (Package wine not built in lunar-proposed) Package wine-development already present in lunar-proposed (but not fixed) (Package wine-development not built in lunar-proposed) This also gives you the list of reverse-dependencies that FTBFS. 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 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
Candidate endorsement [Was Re: Extended call for Ubuntu Technical Board candidates]
As a further comment on the TB elections, I want to weigh in and give my support to one candidate in particular. As a sitting Technical Board member, since so much of what the TB deals with relates to what should and should not be allowed in Ubuntu, I have always found it invaluable to have the perspective of our Security Team in TB discussions. With Marc Deslauriers' resignation, we have not had a direct voice of the Security Team on the TB for a while. The work Robie has done in consulting stakeholders regarding a "third-party repository" policy, that he highlights in his own platform for re-election, is absolutely exemplary. Nevertheless, I think this process is easier overall if the Security Team has a direct seat at the table. For this reason, in a field of excellent candidates whose technical qualifications are beyond reproach, I plan to vote Alex Murray first. On Thu, Dec 01, 2022 at 01:47:14PM +1030, Alex Murray wrote: > Hi folks, > > I'm Alex Murray (alexmurray on Launchpad/amurray on IRC) and have been a > part of the Ubuntu community as a long-time user and enthusiast since > back in 2006. In 2018 I was privileged to join Canonical as the Ubuntu > Security Tech Lead and have worked as part of that amazing team ever > since. I have a passion for making Ubuntu as secure *and* usable > out-of-the-box whilst also ensuring Canonical has a great relationship > with our community. > > I started and am still hosting the Ubuntu Security Podcast nearly every > week for the last 4 years as a way to evangelise the awesome work of the > Ubuntu Security team and the various security aspects of Ubuntu. > > I am also involved with security aspects of snapd and as one of the snap > store reviewers to help guide snap publishers to make sure their snaps > can work as smoothly as possible for their users. > > Finally, I've been a core-dev for a year and a half now as well. > > I am really passionate about Ubuntu and helping to ensure that everyone > can benefit from it whilst also being as secure as possible in the > process. > > One final aspect to mention here is that as an Australian, the current > team meeting time of the Tech Board (20:00 in London) is likely to be a > challenge for me for at least for half of the year once DST ends here + > starts in the UK. I realise that part of the criteria for > application/membership of the TB is to be able to make the existing > meeting time. However, I hope that if elected I could work with the > other TB members to try and find something that may work better for all > - whether alternating meeting times or shifting it during DST etc - so > that we can be inclusive for TB members no matter where in the world > they are located. > > Thanks for your consideration, more than happy to answer any questions > anyone may have for me. > > Cheers, > Alex > > > On Tue, 2022-11-29 at 19:07:26 +, Torsten Franz wrote: > > > Hi everyone, > > > > We have received some applications for the new election of the Ubuntu > > Technical Board. A lot of great applications from very good candidates. > > In order to make a good decision in this selection, we would like to > > give the candidates the opportunity to introduce themselves here and to > > say a few words about their application and provide a few links to their > > work. Everyone will also have the opportunity to ask the candidates > > questions. We will start the election on 6 December. All five seats > > (besides Mark) will be filled. > > > > Here is the list of candidates (by alphabetical order of surname): > > > > - Sebastien Bacher > > - Robie Basak > > - Ben Collins > > - Steve Langasek > > - Lukas Märdian > > - Alex Murray > > - Simon Quigley > > - Mathieu Trudel-Lapierre > > - Łukasz Zemczak > > > > If any questions arise, then the Ubuntu Community Council is available > > to help. > > > > On behalf of the Ubuntu Community Council, > > Torsten Franz > > > > > > Am 22.11.2022 22:51 schrieb 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, > >> install
Re: Extended call for Ubuntu Technical Board candidates
Hi, my name is Steve. I've been an Ubuntu Core Dev, an employee of Canonical, and a member of the Ubuntu Release Team since 2007. I have also served on the Technical Board since 2014. My capacity to do TB work has been reduced over the past few years for personal reasons. I remain passionate in my committment to good technical governance of Ubuntu and I am willing to serve, but for this reason I am also happy to see a healthy slate of other strong candidates this cycle, who I would not feel bad about losing my seat to! On Tue, Nov 29, 2022 at 07:07:26PM +, Torsten Franz wrote: > Hi everyone, > > We have received some applications for the new election of the Ubuntu > Technical Board. A lot of great applications from very good candidates. In > order to make a good decision in this selection, we would like to give the > candidates the opportunity to introduce themselves here and to say a few > words about their application and provide a few links to their work. > Everyone will also have the opportunity to ask the candidates questions. We > will start the election on 6 December. All five seats (besides Mark) will be > filled. > > Here is the list of candidates (by alphabetical order of surname): > > - Sebastien Bacher > - Robie Basak > - Ben Collins > - Steve Langasek > - Lukas Märdian > - Alex Murray > - Simon Quigley > - Mathieu Trudel-Lapierre > - Łukasz Zemczak > > If any questions arise, then the Ubuntu Community Council is available to > help. > > On behalf of the Ubuntu Community Council, > Torsten Franz > > > Am 22.11.2022 22:51 schrieb 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 [1]] > > * 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 [2]). 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. > > > > Links: > > -- > > [1] https://wiki.ubuntu.com/TechnicalBoardAgenda > > [2] http://lists.ubuntu.com > > -- > 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 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: +1 maintenance report
On Mon, Dec 05, 2022 at 05:06:30PM -0800, Steve Langasek wrote: > Second, even though the above should already pick up more packages from > -proposed that we need, I've also added --all-proposed, saying to grab all > packages from -proposed. Two reasons for this: FYI, although this is correct in principle, I was reminded today that there's an unfortunate interaction with NotAutomatic, and so despite the fact that I had been passing --all-proposed, the actual test runs were picking up the versions from the release pocket. So the tests have passed and are green, but the test results are actually invalid despite having the correct triggers. There's no good way to unwind these test results from the database so we'll probably have to roll with it for perl and pick up any regressions in the next mass test (glibc?). So it's fairly urgent that we get this fixed in autopkgtest infrastructure sooner rather than later. -- 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 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: +1 maintenance report
; me. This seems to simply be a bug in what autopkgtest.ubuntu.com considers a 'retry', in that it is not propagating the all-proposed=1 option. > In investigating the above, I chose to use lxd since a package > dependency resolution issue should reproduce just fine in a container, > and working with containers is usually much quicker. But when I couldn't > reproduce against ubuntu-daily:lunar, I tried images:ubuntu/lunar/amd64 > for a minimalist base image, but that doesn't exist. I found this > surprising given that images:debian/sid/amd64 does exist. I tried > upgrading up from images:ubuntu/kinetic/amd64, and that worked (and > didn't take long, with it being minimal). It also helped me notice the > libssl3 thing, because openssl happens to be higher in kinetic-updates > at the moment than the lunar release pocket, because it hasn't migrated > from lunar proposed yet. images: is an endpoint maintained by the LXD community and is not the base for the images we use in autopkgtest. That's ubuntu-daily:. Of course, at archive series opening there are bootstrapping questions about providing those images before we've gotten the base packages updated in the devel release pocket that would allow us to generate them. ubuntu-daily:lunar exists now, but for reasons discussed in other threads wrt kinetic-security vs kinetic release pocket used when bootstrapping the autopkgtest images for the new dev series, would not necessarily be a useful base for trying to reproduce some of these more inscrutable autopkgtest failures. -- 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 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: OpenLDAP 2.6 transition
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. -- 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 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: OpenLDAP 2.6 transition
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. Hopefully, the autopkgtest backlogs on arm64 and s390x will clear this week and then we'll have a better view on what it takes to finish the above in-progress transitions, and then rebuild anything still linking against libldap-2.5-0. Thanks, -- 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 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: Setting NotAutomatic for hirsute+1-proposed
Unfortunately this discussion foundered on lack of consensus about whether
to make this change after the fact for stable series; which resulted in both
jammy and kinetic going out without this being set.
I have set the flag now for lunar as it came up in discussion with
Foundations. The question of whether to change this for stable series is
still open (now with some further series that are stable) but can be
discussed separately.
Colin, will this flag be inherited in the future at series opening?
On Thu, Dec 09, 2021 at 04:27:31PM +, Colin Watson wrote:
> On Wed, Feb 03, 2021 at 11:12:57AM +, Iain Lane wrote:
> > I think the Launchpad support is still missing, although we started on
> > this several years ago. That will need to be picked up and finished off:
> >
> > https://bugs.launchpad.net/launchpad/+bug/1016776
> >
> > That bug report talks about doing it pre-release (for devel only) but I
> > think I'm now in favour of doing it always, and the proposed
> > implementation in there would allow that. For devel, the main reason is
> > that I frequently come across users who have misunderstood what proposed
> > is for and manually enabled it themsleves, resulting in various degrees
> > of brokenness on their systems and bug reports that take developers'
> > time to triage and eventually close. These are not (always) people who
> > have updated from a previous release, where we could have had tools
> > disable -proposed for them, but also people who have explicitly turned
> > it on after installing a daily out of an attempt to help test the
> > upcoming release.
> >
> > On the client side, as Robie says, we will at least need to update
> > documentation. I'm also not sure what update-manager will do if there
> > are NotAutomatic updates present. It might need some tweaking to show
> > them differently. This could be checked by looking at something in
> > -backports, which is already present with these flags set.
> >
> > And finally, there's some implication for package builds; both Launchpad
> > buildds and other builders would need to ignore this. Launchpad does
> > this for -backports currently, i.e. -backports builds get Build-Depends
> > from -backports wholesale; hoepfully that means the buildd side isn't
> > too hard because we can reuse that.
>
> This is now ready to use from the Launchpad point of view. There's a
> "proposed_not_automatic" flag on distro series exported over the API; if
> this is set to True, Launchpad writes "NotAutomatic: yes" and
> "ButAutomaticUpgrades: yes" to the Release file. We've also arranged
> for *-proposed to be pinned to 500 in launchpad-buildd, so Launchpad
> builds will ignore this; I can't speak for other build environments.
>
> Thus, from the Launchpad point of view this is ready to use, although
> somebody may want to check the behaviour of things like sbuild and
> pbuilder first.
>
> Somebody in ~techboard would need to make the actual change, if you
> think it's appropriate. For example, the following in "lp-shell
> production devel" would do it for all supported Ubuntu series:
>
> for name in ("bionic", "focal", "hirsute", "impish", "jammy"):
> series = lp.distributions["ubuntu"].getSeries(name_or_version=name)
> series.proposed_not_automatic = True
> series.lp_save()
>
> --
> Colin Watson (he/him) [cjwat...@ubuntu.com]
>
> --
> technical-board mailing list
> technical-bo...@lists.ubuntu.com
> https://lists.ubuntu.com/mailman/listinfo/technical-board
Thanks,
--
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
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: +1 maintenance report
Hi Sergio, On Fri, Oct 21, 2022 at 06:47:09PM -0400, Sergio Durigan Junior wrote: > * cryfs > - FTBFS on ppc64el due to RLIMIT_MEMLOCK being too low. > - After spending some time playing with setrlimit et al, it's clear to > me that the problem cannot be easily fixed in the source code. I > believe we will need to increase RLIMIT_MEMLOCK in the ppc64el > builders. > - Debian isn't affected by this problem. > - There's also an s390x dep8 failure, which is also affecting Debian. > I opened an upstream issue. > - https://bugs.launchpad.net/ubuntu/+source/cryfs/+bug/1993578 Is there any reason not to instead change the package to skip these tests when RLIMIT_MEMLOCK is too low (which seems detectable)? Thanks, -- 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 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
