Re: git-ubuntu build
On Fri, Jun 09, 2023 at 09:11:34PM -0700, Steve Langasek wrote: > 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: > > > 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') > > ^ > $ Heh, that list is pretty out of date. build-source is gone, and I think review and lint are as well. There is still a 'build' module with some of the remaining code from the original build command, but you can see from the above commit that the hook for the command was removed. > > 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? That occurred to me too. We had subsumbed 'build-source' to 'build -S' since both commands used basically the same code just passing the -S along to the underlying tools. > 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. Right, the point I was making there is that since the 'prepare-upload' step pushes the branch to Launchpad, I don't want or need to include that in my workflow until the end, after all that is done and I'm ready to do the .changes upload. Then I do one final debuild -S and run prepare-upload, verify it worked and check the .changes file has expected fields, and then I directly dput the .changes. I think of that as more of a submission-style procedure. But, there's more than one way to do this. I'm sure we all have unique workflows for how we prep source packages. Bryce -- 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, and I'll have to look at what you're doing to automate the > -sa arguments, I hadn't figured out a good solution there. > Btw, you may already be doing this but I've found in scripting this > myself that it's worthwhile to
Re: +1 maintenance report
On Fri, Jun 09, 2023 at 06:20:55PM +0100, Danilo Egea Gondolfo wrote: > I had a shorter week with some Netplan distractions but here we go: > > 1. delve > > FTBFS due to the installed bpftool not matching the running kernel version. > I tried to workaround this by calling bpftool directly from > /usr/lib/linux-tools-. > It kinda worked but the build still fails for a different reason. It needs > more work. > See LP: #2021481 > > 2. bpftrace > > FTBFS on armhf. The problem apparently is a gcc bug. > I created a patch with a workaround and asked the upstream project about > the issue. > See: LP: #2023173 > Also submitted to Debian #1037185 > Github discussion > https://github.com/iovisor/bpftrace/pull/2360#discussion_r1223534659 > > 3. cbmc > > FTBFS on all architectures. > The compiler is catching some errors I believe are false positives. > There are some optional variables that it says are MAYBE uninitialized. > I added -Wno-error=maybe-uninitialized to the CXX FLAGS and it fixed > the build on amd64. It's now failing for a different reason on the other > archs. > LP: #2023276 > > 4. pistache > > FTBFS on all architectures except riscv > One of the unit tests tries to resolve an address via DNS and fails > because the builder doesn't have access to the internet I suppose. > It's not failing on Debian's CI. > A patch was submitted to the upstream project > https://github.com/pistacheio/pistache/pull/1134 > LP: #2023274 > > 5. ctffind > > FTBFS on non-x86 architectures > It uses x86 assembly inline. I implemented an alternative code calling > sinf() and cosf() from the libc instead on non-x86 systems. > LP: #2023288 > Debian bug: #1037227 > The patch was accepted by Debian and is already synced to Ubuntu. > > 6. elinks: > > FTBFS on s390x > A tool used during tests, sgml-parser, is crashing. There is a > use-after-free issue > in the code that is not making it crash on other architectures. > One can see it by using valgrind or compiling elinks with address sanitizer. > See: LP: 2023305 > I also reported the problem upstream: > https://github.com/rkd77/elinks/issues/235 > > 7. libopenmpt > > Autopkgtests failing > The test will build a C file that emits some deprecation warnings. > This is causing the test to fail. > LP: #2023406 > It was already reported to Debian: #1037007 I'm publicly mentioning this as it is the second time (today!) I've seen somebody not add a bug watch[1] to a bug which affects both Debian and Ubuntu. Basically, a bug watch will monitor the upstream bug report (status and comments depending on the bug tracker) in the remote tracker and update the bug task's status in Launchpad. This makes it much easier for future travellers to see what is going on with the bug in other bug trackers. [1] https://wiki.ubuntu.com/Bugs/Watches Happy Friday! -- Brian Murray -- 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 MPs in the sponsorship queue
On Fri, Jun 09, 2023 at 12:13:29PM -0700, Steve Langasek wrote: > 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... The problem we had on the server team was "accidentally" claiming it. I believe that if ~ubuntu-sponsors has a review slot, you're a member of ~ubuntu-sponsors and you vote eg. "Needs Fixing", then the ~ubuntu-sponsors slot automatically gets claimed by you. Maybe there's a nuance I'm missing. I'm concerned that the existing workflow will lead to MPs inadvertently disappearing from the queue like this. 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
I had a shorter week with some Netplan distractions but here we go: 1. delve FTBFS due to the installed bpftool not matching the running kernel version. I tried to workaround this by calling bpftool directly from /usr/lib/linux-tools-. It kinda worked but the build still fails for a different reason. It needs more work. See LP: #2021481 2. bpftrace FTBFS on armhf. The problem apparently is a gcc bug. I created a patch with a workaround and asked the upstream project about the issue. See: LP: #2023173 Also submitted to Debian #1037185 Github discussion https://github.com/iovisor/bpftrace/pull/2360#discussion_r1223534659 3. cbmc FTBFS on all architectures. The compiler is catching some errors I believe are false positives. There are some optional variables that it says are MAYBE uninitialized. I added -Wno-error=maybe-uninitialized to the CXX FLAGS and it fixed the build on amd64. It's now failing for a different reason on the other archs. LP: #2023276 4. pistache FTBFS on all architectures except riscv One of the unit tests tries to resolve an address via DNS and fails because the builder doesn't have access to the internet I suppose. It's not failing on Debian's CI. A patch was submitted to the upstream project https://github.com/pistacheio/pistache/pull/1134 LP: #2023274 5. ctffind FTBFS on non-x86 architectures It uses x86 assembly inline. I implemented an alternative code calling sinf() and cosf() from the libc instead on non-x86 systems. LP: #2023288 Debian bug: #1037227 The patch was accepted by Debian and is already synced to Ubuntu. 6. elinks: FTBFS on s390x A tool used during tests, sgml-parser, is crashing. There is a use-after-free issue in the code that is not making it crash on other architectures. One can see it by using valgrind or compiling elinks with address sanitizer. See: LP: 2023305 I also reported the problem upstream: https://github.com/rkd77/elinks/issues/235 7. libopenmpt Autopkgtests failing The test will build a C file that emits some deprecation warnings. This is causing the test to fail. LP: #2023406 It was already reported to Debian: #1037007 Danilo. -- 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
On Fri, 9 Jun 2023 at 20:10, Steve Langasek wrote: > > 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. boost was in a similar position. it is too much work to maintain symbols files for it, update them for new upstream releases, or even just adjust for the new default compiler. the solution there was to just bump the library soname on every upstream change, and often bump package name (sort of soft library abi bump) upon changes to the vendored re-exported libs and/or compiler induced symbol changes. That works really well for c++. It may be redundant for some updates, but it is a foolproof way, with single pass uploads. -- okurrr,
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
Re: Symbols files for C++ libraries for Ubuntu main
Hey there, We had been struggling with a few of those cases recently in desktop and I was going to send an email about the topic then checking the archive I found back that discussion that I had forgotten about. 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)? Here is why. Taking a recent example from desktop and describing the experience on one package where we basically had to go through those steps 1. We added a symbols to libcupsfilters as part of the MIR promotion https://git.launchpad.net/ubuntu/+source/libcupsfilters/commit/debian/libcupsfilters2.symbols?h=applied/ubuntu/devel=c5821fe0 The build failed on armhf because dh_makeshlibs report symbols on armhf which do not existing on amd64 https://launchpadlibrarian.net/647850924/buildlog_ubuntu-lunar-armhf.libcupsfilters_2.0~b2-0ubuntu4_BUILDING.txt.gz 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 2. I tried to help getting that resolved with that upload http://launchpadlibrarian.net/647856580/libcupsfilters_2.0~b2-0ubuntu4_2.0~b2-0ubuntu5.diff.gz Which basically add the symbols showing a new on the armhf as '(optional)' and also listed those that changes as optional in their different variants 3. similar round for riscv64 http://launchpadlibrarian.net/647865001/libcupsfilters_2.0~b2-0ubuntu5_2.0~b2-0ubuntu6.diff.gz 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 5. still failed, I had to add another bunch of symbols from the previous build log http://launchpadlibrarian.net/647896999/libcupsfilters_2.0~b2-0ubuntu7_2.0~b2-0ubuntu8.diff.gz Which finally got us a working build. 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. And from experience it is likely that following the next toolchain update the .symbols will not match anymore and that those of us who will end up having to fix the package build will not understand why and just end up applying the diff proposed by dpkg-gensymbols. Checking on the Debian side, https://wiki.debian.org/UsingSymbolsFiles has a 'C++ libraries' section which start by this statement written in bold style > For C++ libraries it is often better not to ship symbols files. Which means we will often fail at upstreaming such improvements to Debian and will have to increase our delta. And I don't blame them, I'm not even sure how to deal with the 'the symbols change between architectures' out of throwing builds to a ppa to get results and iterate and Debian doesn't have the ppa option... Cheers, Sebastien Bacher Le 22/05/2018 à 18:25, Robie Basak a écrit : On Fri, May 18, 2018 at 08:29:13PM +0200, Matthias Klose wrote: I completely disagree. Replacing a somehow suboptimal check with no check is not an option. On Fri, May 18, 2018 at 08:22:55PM +0100, Dimitri John Ledkov wrote: IMHO symbols files should be mandatory for any new libraries introduced in the archive. And we should assert symbols files for everything in main, and fix all the things. It's 2018, and we really ought to have sensible and strict symbols files. Both of these statements on their own state that we must do this work but don't explain why this is of benefit to Ubuntu. I feel that you need to justify your position rather than just stating it. Can you provide examples of where maintaining this delta has actually helped make Ubuntu better, in the specific case that C++ symbols are being maintained by Ubuntu in a delta that Debian and upstream have declined to adopt or postponed adopting? Without examples, we're not really in a position to assess the trade-off of extra work vs. benefit to Ubuntu. I don't think we should be maintaining delta unless the benefit can be articulated and justified. Separately, I question whether it's in the interest of our project to spend time on maintaining a quality improvement indefinitely if Debian and/or upstream decline to take it, and if that particular improvement is not a high level goal of our project. Thanks, Robie -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at:
Re: git-ubuntu MPs in the sponsorship queue
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? On the Server Team, we use a review slot for ~canonical-server-reporter that nobody is a member of in order to avoid this happening. That way the "marker" remains. But to do this for ~ubuntu-sponsors would mean we have to use a separate team name. Separately, there's a bot[1] that actually adds ~ubuntu-sponsors as a reviewer if there is nobody else, which I think his how most git-ubuntu MPs that need sponsoring are getting to the queue in the first place. Maybe that could subscribe ~ubuntu-sponsors-reporter instead, and I could adjust the sponsorship queue to display both? Robie [1] https://git.launchpad.net/~ubuntu-server/+git/ubuntu-helpers/tree/rbasak/lp_auto_sponsor.py 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
