Re: Symbols files for C++ libraries for Ubuntu main
On Thu, Jun 15, 2023 at 04:07:54PM +1000, Christopher James Halse Rogers wrote: > abi-compliance-checker and abigail. None of those experiments have ended up > sticking, though, for reasons which I'm not fully aware of. Alan Griffiths > and Michał Sawicz did most of that investigation; I'll see if they can help > shed light on problems we encountered. > > If we *can* get (one of) the ABI checking tools working they'll be more > valuable than a symbols file anyway, as they actually check that ABI didn't > change rather than just that the symbol strings in the DSO match. I'm not actually close enough to package updates to see how exactly these different tools report symbols problems. I've tried reading the Debian Wiki page, the KDE symbols page, etc, but without having these problems myself, first-hand, it's hard for me to come to terms with the issues. How do the default symbols files "failures" appear when building packages? Are the results "actionable"? Or is the usual outcome to pave over the old file and use a new file? What's the ratio of false positives to true positives? I keep hearing that the KDE symbols handling is vastly better; is there a reason why it's not the default? There's more to ABI compatibility than keeping the types of parameters and return values lined up. Do any of the ABI tracking tools provide help looking into the types, or the functions, etc? Thanks 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
+1 maintenance report
This week I did my +1 maintenance shift. As usual, I got a bit sidetracked on Monday due to other pressing matters. I like to start from the bottom of update -excuses and choose some of the more challenging FTBFSes. Here's my report: Investigations == * wtforms -alchemy - https://bugs.launchpad.net/ubuntu/+source/wtforms -alchemy/+bug/2013156 - Rebuilt the package. - Build succeeded. - This should unblock wtforms -json. * maxima - Triggered rebuild on ppc64el to see if it works this time. - No luck. Decided to move to another package. * git -annex - https://bugs.launchpad.net/ubuntu/+source/git -annex/+bug/2019992 - Fixed the FTBFS by removing -Wl, -Bsymbolic -functions from LDFLAGS. Debian accepted the patch as well, which is good. - ... Unfortunately this did not solve all the problems. It seems like there's some LTO issue going on. Investigating. - ... Indeed, disabling LTO seems to fix the FTBFS on ppc64el. Still not sure what's going on with the riscv64 build. - ... A bit more investigation and I found that we apparently have to enable certain Build -Deps for riscv64 as well. Submitted a new bug to Debian. - Still not sure what causes the crash on armhf. I tried obtaining a machine to test the build, but after half a day waiting on an internal MAAS to reserve me a machine, it failed. I gave up. - I will sync the package again when Debian accepts my second round of changes. Let's check if the new upstream version will have any impact on the armhf bug. * golang -github -pion -transport * golang -github -pion -datachannel * golang -github -pion -dtls.v2 * golang -github -pion -ice.v2 * golang -github -pion -interceptor * golang -github -pion -mdns * golang -github -pion -rtcp * golang -github -pion -sctp * golang -github -pion -srtp.v2 * golang -github -pion -stun * golang -github -pion -turn.v2 * golang -github -pion -udp * golang -github -pion -webrtc.v3 - Made them all migrate by using the correct incantation when retriggering the tests. * rust -sequoia -net - Depends on rust -sequoia -openpgp >= 1.13, which is packaged in Debian experimental, so I sync'ed it. - Unfortunately, rust -sequoia -openpgp depends on a newer version of rust -base64. There is an update ready to be uploaded on salsa, which leads me to believe that we should be able to untangle this soon. * bind -dyndb -ldap - This will need a rebuild when we merge bind9 from Debian. I left a comment in the merge bug. * netatalk - dep8 test fails due to wrong regexp. - There's a fix on salsa, but it hasn't been uploaded to Debian yet. I believe we should see an upload soon now that bookworm is out. - https://bugs.launchpad.net/ubuntu/+source/netatalk/+bug/2023728 - My initial intention was to leave the package as is instead of introducing unnecessary delta, but given that I've been called out before when I did that, I went ahead and uploaded a fixed package to Ubuntu. * simde - dep8 failing on ppc64el. - I noticed that the Debian maintainer uploaded a new version to unstable today (2023 -06 -13). I hasn't been picked up by LP yet, so I'll give it some time and see if that fixes the problem. - ... Unfortunately the new upload did not fix the failure. * emacs -corfu - Depends on elpa -compat >= 29.1.4.0, but Debian and Ubuntu carry 29.1.3.0. - I uploaded compat -el 29.1.4.0 to Debian, it should help resolve this situation. * fwupd - Retriggered the amd64 dep8 test; passed. * libvcflib - FTBFSing on s390x. - Filed https://bugs.launchpad.net/ubuntu/+source/libvcflib/+bug/2024021 and the upstream equivalent https://github.com/vcflib/vcflib/issues/386 * libgnatcoll -db - Retriggered build for ppc64el, which passed. * mac -fdisk - The package only builds on architectures that aren't support by Ubuntu. - Filed https://bugs.launchpad.net/ubuntu/+source/mac -fdisk/+bug/2024062 asking for its removal. * libssh - dep8 test fails on ppc64el/s390x. - Passes on debci. - I tried reproducing it using a ppc64el canonistack box, but the test always passes there, too. - Filed https://bugs.launchpad.net/ubuntu/+source/libssh/+bug/2024064 to document what I did. It seems to be something specific to our autopkgtest infra, so I stopped the investigation. * intercal - Retriggered amd64 build. Passed. * taglib - i386 build has been stuck for a while due to a missing dependency (utfcpp). - I checked and utfcpp seems to be the only missing piece to build taglib on i386. Everything else is already built for the architecture, and utfcpp itself only Build -Depends on packages already available for i386, too. - Pinged vorlon and ask if there's any interest in adding utfcppp to i386's whitelist in order to unblock taglib. - ... all done:
Open Source MSDOS Game Decomp Suggestion for Repo
Hi I originally posted this on the Ubuntu forums and was then directed here. I was looking through the games list and I noticed there is a game that could be added. There is an open source decomp for the MSDOS game Raptor Call of the Shadows that I think would be great for the Repo. The decomp has the original MSDOS Programmer's approval as well. https://github.com/skynettx/raptor Video of it running on Linux https://www.youtube.com/watch?v=r8aMxADjlJM -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: SRU bug subscription for sponsors
Hi, On Thu, Jun 15, 2023 at 6:50 AM Sebastien Bacher wrote: > > Le 14/06/2023 à 22:32, Robie Basak a écrit : > > > > If sponsors aren't prepared to do this, I question whether what they are > > doing is actually useful. The harm is that they are leaving > > non-uploaders in the cold, and review teams are spending unnecessary > > effort that could be diverted to doing the reviews that only they can > > do. > > The issue is not really 'to be prepared to do this'. I do agree with you Good ;) > that the sponsors should be engaged in the process, especially when > sponsoring work from someone who isn't familiar with all the details of It's not just familiarity. Sometimes the person just doesn't have enough privileges to take an action, like nominate a series, or retry autopkgtests. Specially retry autopkgtests. > the system. It is especially true for SRU uploads which often need > follow-ups to deal with the issues you mentioned. Subscribing to the > corresponding launchpad bug makes sense in that context and that's > something I would recommend doing. I agree. > > Where I disagree is that it should be forced on us this way, without > even letting us the change to have a public discussion here before > having the change in action. Well, the discussion is happening now. > A few concerns I have > > 1. I've noticed that people (even in our teams at Canonical) don't keep > up with bug emails and some end up just ignoring anything coming from > launchpad. The issue isn't new and isn't due to the new bot, but the bot > is adding to the problem. gmail is super bad at filtering email, agreed. What other way would we have to follow the progress of an upload that was sponsored? Who is in the best position to do that? > 2. You argue that we should expect that the people asking for sponsoring > aren't familiar with the processes or they wouldn't ask for sponsoring > such they need guidance and involvement from their sponsors. While > that's true for a class of contributors it's often not the case. I'm > regularly sponsoring work for people in my team who are perfectly able > to follow up on their changes and know the process, it just happens that > sometime they need to upload a fix outside of the packagesets they have > access to Or retry an autopkgtest with triggers or special options. Besides the question of ACLs, where most sponsored people wouldn't even be able to do it, there is a tricky learning curve to deal with autopkgtest and migration issues. So much that it's a standard recurring question when someone applies for core dev privileges. > > 3. You say "sponsors will follow through on uploads until they land", > could the script be made to be smart enough to unsubscribe the sponsor Maybe, but once a bug is "fix released" (since the fix landed), there normally aren't many follow-ups to it. If there are, then it might have introduced a regression, in which case you would definitely want to know about it, or it's another type of comment and you can easily unsubscribe from the bug then. > at that point? Launchpad bugs are often noisy (users sometime comment on > unrelated closed issues which seem similar to what they face, they ask > for guidance on how to install an SRU updates, ...) which adds to > problem 1. Yes I can go to unsubscribe manually if I'm bothered enough > but that's just one more annoyance and manual action needed which > contributes to the 'it's easier to just filter launchpad emails in a > folder and ignore those'. Imagine the annoyance of the SRU team when they find a bug that was supposedly verified, tags flipped, but the package didn't even build (it's an FTBFS) :) Somebody must have gotten an email about it. Could that email be one of those that are being ignored? Or when somebody asks why the sru hasn't landed yet, and it has current autopkgtest failures that the sponsored person cannot do anything about other than ask for help somewhere, perhaps in the bug. Would that be lost too in some folder? I do believe sponsoring is more than pressing a button and forgetting about it. And I wonder how it's working in the new patch pilot program, if uploads are being followed through, or being forgotten after dput (my shift will be in a few days). -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
