On Tue, Mar 8, 2022 at 5:23 PM Frank Ch. Eigler <[email protected]> wrote: > > Hi - > > Thanks for reaching out! > > > The systemtap package is one that is particularly vulnerable to > > changes in the kernel, and the older versions in stable releases > > frequently see breakage with kernel updates or even when using a HWE > > kernel, as you know. > > Right. > > > I don't personally use systemtap very often, but in talking to > > coworkers my understanding is the 'latest' systemtap version can > > almost always handle 'any' kernel that was previously released (i.e. > > backwards compatible with kernels), > > That is correct. > > > but the systemtap library modules may not be backwards compatible, > > so SRU'ing the latest systemtap might get it working with different > > kernels but might also break user custom modules. Is that accurate? > > I don't think so - the whole system is designed to be aggressively > backward compatible, and even includes runtime modes to disable newer > functions for the benefit of older scripts.
hmm, if that's the case, then it might be even more appropriate to just apply for a 'SRU exception' where the 'latest' version would get pushed back to stable releases on a regular basis. That would be certainly better than using backports, as users would get the newer working version by default. For reference, the sru exception process: https://wiki.ubuntu.com/StableReleaseUpdates#Documentation_for_Special_Cases > > > > If so, maybe systemtap would be a good candidate for adding to the > > -backports pocket; since it's an opt-in pocket, users would have an > > option of getting the latest working systemtap on stable releases. > > Sorry, I'm not sure what the implications of this would be. If the > effect is to make it easy to frequently update from upstream releases, > that'd be great. So the options are essentially: 1) the default process, of patching old versions one-bug-at-a-time 2) the SRU exception process, of pulling the entire 'latest' version back into older releases 3) the backports process, of pulling the entire 'latest' version into a special opt-in pocket of older releases Backports aren't intended to actually fix bugs, but I had thought it might be appropriate for systemtap; however, if the latest systemtap versions really are backwards-compatible, the SRU exception process would be the most appropriate way to get the stable releases updated. > > > > This isn't a pre-approved notice, so if you think it's a good idea > > (meaning you would be the one preparing and uploading the backports), > > we (the backports team) can have a bit more discussion to make sure we > > agree it's appropriate. [...] > > I'm not sure I'm personally in a position to undertake ubuntu > packaging, but perhaps someone from our team or the community at large > can make it happen. We can ask around if you need us to. Certainly understandable, Ubuntu/Debian packaging isn't always the simplest ;-) I cc'ed Emanuele Rocca, as the Debian maintainer, possibly would you be interested helping maintain systemtap for stable Ubuntu releases? I can also check with my team. > > (By the way, any idea whether y'all might put up a ubuntu debuginfod > server, like debian (via sergiodj), fedora, and others have? It makes > systemtap and other debugging type tools much easier to use.) Yes, I'd be quite interested as well in when sergiodj might be getting to that for Ubuntu ;-P Last I heard from him, he was going to try to get some time carved out for it. It would be very useful for my team as well so it's possible I/we might work on it too at some point. Thanks! > > > - FChE > -- ubuntu-backports mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-backports
