Re: Sending LTO delta to Debian
On 06.05.22 08:53, Steve Langasek wrote: Hi Andreas, On Thu, May 05, 2022 at 05:33:37PM -0300, Andreas Hasenack wrote: Hi, this came up again in a review, and I wanted to ask a broader audience. How to we send LTO[1] related delta to Debian, given that Debian isn't using LTO (yet)? Case in point was the ust package[2], which has this bit[3] part of the delta (just showing the first hunk): @@ -1,5 +1,5 @@ liblttng-ust-python-agent.so.1 liblttng-ust-python-agent1 #MINVER# * Build-Depends-Package: liblttng-ust-dev - __start_lttng_ust_tracepoints_ptrs@Base 2.13.0 - __stop_lttng_ust_tracepoints_ptrs@Base 2.13.0 + (optional=lto)__start_lttng_ust_tracepoints_ptrs@Base 2.13.0 + (optional=lto)__stop_lttng_ust_tracepoints_ptrs@Base 2.13.0 Is this upstreamable to Debian as is? I know this depends most of the time on the maintainer, but in general what would be our arguments? Does it change the behavior of package building when lto is not used? In a non-lto case, would the disappearance of those symbols be caught? When talking about upstreaming of changes to .symbols files, I prefer to argue it from a higher level: the two purposes of .symbols files are 1) to avoid user-affecting bugginess due to undetected ABI breakage, and 2) to ensure library dependencies are as relaxed as possible to give the best cross-release binary compatibility and minimize constraints on release upgrades. While in our case it's LTO that has resulted in these particular symbols disappearing, it's obvious from the names that these symbols are not intended to be part of the public ABI of this library - the fact that these symbols are exported is an accident, not something happening by design. So marking these symbols "optional" makes the packaging more correct in terms of describing the library's ABI, and more portable with respect to a variety of compiler options that may change the exposure of internal symbols. Thus it's a low-priority bug for Debian, but the change is intrinsically correct - not something Ubuntu-specific. symbols files are broken by design. however that design error was accepted into dpkg and issues mitigating that by either using the google or redhat solutions are ignored. so please be pragmatic about this and try to work around it. so yes, an issue for Debian to address these issues is appropriate. Matthias -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Log-rotation doesn't work for catalina.out in src:tomcat9 as intended
On Fri, May 06, 2022 at 01:20:30AM +0530, Utkarsh Gupta wrote: > a) This is Ubuntu-specific because of the changes introduced in > src:rsyslog over a decade ago, which basically doesn't let it run as > root, which is where I think the problem(s) started to originate. > However, I am kinda stumped that it took more than 13 years to get to > this bug. :) > > b) Markus (an implicit co-maintainer of tomcat* in Debian) said that > the approach to fix the same, whilst being Ubuntu-specific, doesn't > make sense to him. So since I am not very well-versed with > src:tomcat*, I am confused about what we should do here then. > > What do y'all think? I think I am convinced that if a) is true, then > this will indeed be a delta which we'll have to maintain forever (or > at least until we re-sync rsyslog :)). What do you think should be the > correct path? If there's someone who has more experience with the > package, can they take a look? AIUI, it's a deliberate decision for Ubuntu to ship rsyslog by default and that it is configured to not run as root as a delta against Debian. So I expect the default position to be that we should try to maintain that, unless there's some reason it no longer makes sense. Therefore, I think what we need to do is fix the tomcat* packaging to correctly work with that. Hopefully we can find a way that makes sense regardless of whether rsyslog runs as root or not. Then this should be acceptable to Debian too, and we wouldn't need a delta in the tomcat* packaging. Maybe this isn't possible, but as far as I can tell, this hasn't been ruled out. All I saw in the Debian bug was the Debian maintainer declining one specific proposed solution. But maybe a general solution acceptable to both configurations of rsyslog can be found? This is where I'd look next. HTH, Robie 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 was on +1 this week. Here are my notes. # cyrus-common - LP: #1971469 # cyrus-common had test failures around usage of EVP_PKEY_base_id. The usage of this function seems to have changed somewhat, and cyrus-common was not using it in a method consistent with the v3 OpenSSL manpage for EVP_PKEY_base_id. That manpage suggests instead using EVP_PKEY_is_a for checking key types in this scenario, which seems to work well. Status: Forwarded upstream, merged to Debian (Thanks Yadd) and autosynced. Jammy Status: the affected code was introduced as part of 3.5, and the version of cyrus-common in Jammy is 3.4.3. I see no reason to believe that a SRU would be needed. # osmo-mgw - LP: #1971620 # osmo-mgw turned out to have different behavior if you had systemd installed in the build environment, and by default schroot does not. If systemd is present, it causes an unexpected file to appear in the list of files to install, then dh_missing complains. Status: Fix proposed to Debian and also listed at above LP. # gyoto vs lorene - LP: #1971735 # gyoto had a LTO version conflict with a .a file found in liblorene-dev. The symptom of that is: lto1: fatal error: bytecode stream in file ‘/path/to/foo.a’ generated with LTO version 11.2 instead of the expected 11.3 By rebuilding liblorene-dev, I could use that for a working gyoto build. However, this suggests a category problem with .a files. See below. Status: Uploaded (Thanks Graham) # LTO vs .a files # Existing .a files in packages built with LTO could trigger the above problem. I wrote some tooling to go looking for such things. https://github.com/dbungert/lto-rebuild-detect Getting the LTO version was harder than expected - lto-dump doesn't expose it yet, so doing so requires a patched lto-dump or manual parsing of the info. (no thanks!) That said, it was still possible to detect this problem. for each deb containing a .a file for each .a file run lto-dump from the correct version of gcc look for a errors 'generated with LTO version X instead of ...' It's not enough to just check the lto-dump return code, since it can fail for other reasons - for example, lto-dump will fail on object files in .a files in golang-golang-x-tools-dev, but the error is probably not LTO: lto-dump-11: error: /tmp/tmp38g9q35d/archive-2/_go_.o: file not recognized Based on this script, for AMD64 only looking at -dev packages, I found a few candidates of packages I expect need a rebuild: libbenchmark-dev libbluetooth-dev libdpdk-dev libhts-dev liblorene-dev libngtcp2-crypto-gnutls-dev libunwind-dev libunwind-setjmp0-dev libwmf-dev libwvstreams-dev slurm-wlm-basic-plugins-dev (What's the best way to request sponsorship of a small batch of rebuilds?) # retest items # I didn't spend too much time trying to do retests - the queues have been awful this week - but did request a few: * cif-api * yaz # other things # * armci-mpi - I was able to verify the test failures but didn't get too far with it. ppc64el and s390x failures look different. s390x looks like an endianness problem maybe. * android-platform-system-core - problem with debug flags? Looks like this: https://sourceware.org/bugzilla/show_bug.cgi?id=24756 -Dan -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Proposal: move byobu (and run-one) to universe
I'm on the fence on this one. On one hand, if it's not really being cared for upstream, then you're right in asking about whether demotion is appropriate. On the other hand, it does Just Work, and I've been pointing inexperienced admins to it for years as a console-sharing leave-things-running solution for the command line. It's nice not to have to explain screen/tmux operation when on defaults, and this convenience only really works if it's installed by default. Note that it's currently documented in the server guide (https://ubuntu.com/server/docs/tools-byobu) and a deprecation (from Ubuntu Server main/defaults) needs addressing there too. Robie 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
