[07:58] <mkukri> adrien dobey: saw the discussion ubuntu-release, will be checking if the library breakage is because of that flag
[08:15] <adrien> thanks! :)
[08:41] <mkukri> reproduced the valgrind errors with `-fstack-clash-protection` on a hello program linked against a shared library
[08:41] <mkukri> question is, is it actual breakage or is valgrind broken?
[09:06] <mkukri> https://bugzilla.redhat.com/show_bug.cgi?id=1522678
[09:06] -ubottu:#ubuntu-devel- bugzilla.redhat.com bug 1522678 in Fedora "gcc: probes below the stack pointer on armhfp" [Unspecified, Closed: Cantfix]
[09:07] <mkukri> that pretty much explains it, there are issues with this flag on armhf
[09:08] <adrien> there are also opinions on some debian mailing posts or bugs that it's only surfacing existing issues
[09:09] <mkukri> perhaps, the gnutls segfault is that.
[09:09] <adrien> one way or the other we probably don't have a short-term solution besides disabling that flag and rebuilding affected packages (or maybe all of armhf that was build since that flag got enabled in armhf, which is fortunately more recent that on other arches!)
[09:09] <mkukri> but it's also incompatible with valgrind, so we would need to disable all valgrind based autopkgtests on armhf at least
[09:12] <mkukri> yeah *if* we disable it, rebuilding everything on armhf since it was enabled would probably be good for preventing random bug reports
[09:12] <adrien> I don't know if there are existing plans for such situations; I'm going to prepare a patch to disable this in dpkg-dev and then we can at least do no-change rebuilds for the few packages that we have seen affected at the moment
[09:45] <cpaelzer> doko: hi, I'm reading in https://wiki.ubuntu.com/ToolChain/LTO "... except for riscv64, aiming to not slowing down the riscv64 builds further."
[09:45] <cpaelzer> doko: if I now have a build that "needs LTO" it is ok if I switch it on for one particular build right?
[09:45] <cpaelzer> as that would not make all, but just this one longer
[09:45] <doko> sure, that works
[09:46] <cpaelzer> thanks
[10:02] <juliank> Oh I forgot to
[10:02] <juliank> @pilot in
=== ChanServ changed the topic of #ubuntu-devel to: Archive: open | Devel of Ubuntu (not support) | Build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of Focal-Mantic | Patch Pilots: juliank
[10:02] <juliank> calendar controls me
[10:02] <juliank> :D
[11:09] <nteodosio> Shouldn't the /bin/clang{,++} symlink be installed by every version-specific clang package version?
[11:10] <nteodosio> It seems that at the moment only clang package installs it, not clang-15 for instance.
[11:13] <doko> no. use CC= CXX= for using the compilers, or use the versioned bin directory
[11:16] <nteodosio> doko, same for the whole of llvm? llvm-ar-15 instead of llvm-ar etc.
[11:16] <nteodosio> Is there a reasoning behind not installing the symlinks?
[11:18] <doko> PATH=/usr/lib/llvm-NN/bin:$PATH clang ...
[11:18] <doko> is there a reason not to use that?
[11:25] <nteodosio> doko, none, that is a good solution, thanks. I was just wondering about "why not creating the symlinks". Is it because there would confuse Apt when installing different versioned packages?
[11:32] <doko> we are not using alternatives, because different compiler versions can have ABI skews
[12:05] <adrien> mkukri: do you feel like testing some stuff? :)   https://launchpad.net/~adrien-n/+archive/ubuntu/noble-no-fstack-clash-protection
[12:06] <adrien> versions don't have ~ppaX appended; it's not meant for usage outside of test containers :)
[12:08] <mkukri> is everything built and published? do i just install gnutls from the ppa and that's that?
[12:09] <adrien> yeah, everything built and published so you can just use the PPA in your test env and try to reproduce the issue
[12:09] <adrien> errr, no, it's not published yet for gnutls
[12:10] <adrien> did I misunderstand something about ppa-dev-tools?
[12:11] <adrien> but well, you can grab https://launchpad.net/~adrien-n/+archive/ubuntu/noble-no-fstack-clash-protection/+build/27016456/+files/libgnutls30_3.8.1-4ubuntu4_armhf.deb directly
[12:12] <mkukri> okay that's good enough. could you maybe also upload the latest libarchive to that ppa too?
[12:12] <mkukri> (and ideally libxml2 too)
[12:12] <adrien> sure, let me have a look, but as you know it's going to be a while before the files are ready and published
[12:14] <mkukri> yeah yeah, ill test gnutls just now, just want to confirm that the cflag also fixes those two
[12:14] <mkukri> but im sure it will
[12:24] <mkukri> adrien: tested your gnutls deb, it seems to fix the issue
[12:24] <adrien>  \o/
[12:44] <ahasenack> starting my sru shift
[12:50] <adrien> ahasenack: openssl! :D
[12:50] <adrien> ahasenack: https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/2033422
[12:50] -ubottu:#ubuntu-devel- Launchpad bug 2033422 in openssl (Ubuntu Jammy) "openssl: backport to jammy 'clear method store / query cache confusion'" [Medium, In Progress]
[12:50] <adrien> good morning :)
[12:50]  * ahasenack takes note
[12:52] <adrien> as I mentioned earlier, it needs to be handled fairly quickly because otherwise it could easily linger until january, at which point there will certainly be another openssl security update (there's one almost every two months...) which would collid with this
[12:52] <ahasenack> oh, who hasn't been overruled by a security update before, raise their hand :)
[12:53] <adrien> I haven't yet :P
[12:53] <ahasenack> lucky you
[12:53] <adrien> actually, I have
[12:53] <adrien> for this very SRU a month ago
[13:05] <adrien> mkukri: you can fetch the packages directly from https://launchpad.net/~adrien-n/+archive/ubuntu/noble-no-fstack-clash-protection/+packages (still not published but direct links available)
[13:15] <mkukri> any brave souls here who want to test zlib on s390x and/or power? https://code.launchpad.net/~mkukri/ubuntu/+source/zlib/+git/zlib/+merge/456176
[13:15] <mkukri> adrien, will test
[13:21] <mkukri> libarchive and libxml are both fixed by the cflag removal
[13:25] <adrien> woo \o/
[13:25] <adrien> thanks for testing :)
[13:44] <adrien> doko: what should we do for -fstack-clash-protection? wait more? and if so, until when? merge my dpkg changes? I've opened an MR in order to record that discussion if wanted: https://code.launchpad.net/~adrien-n/ubuntu/+source/dpkg/+git/dpkg/+merge/456181
[14:44] <doko> adrien: I brang that up to Debian today, please let's postpone this until Monday
[14:48] <tjaalton> ahasenack: I've updated the ivsc/ipu6 test case a bit to use the mantic kernel instead, and added a comment
[14:50] <adrien> doko: ok, I've updated the MR and marked it as WIP (also, I didn't want to rush it or whatever: I merely wanted to save the diff somewhere, write down my thoughts and share so that I could remove that thing from my mind :) )
[14:51] <mkukri> im marking my related proposed migration as blocked until we decide a way forward. at least it is not a mystery anymore
[14:55] <ahasenack> tjaalton: awesome
[15:24] <mkukri> if there is any patch pilot around when dpkg 1.22.1ubuntu3 hits proposed, can you please upload the 3 no-op rebuilds ive left in # ubuntu-release?
=== rkratky__ is now known as rkratky
[16:54] <ahasenack> tjaalton: is it ok to move this step, which is curently the first one, to just before installing the userspace gstreamer and v4l packages? "  $ sudo add-apt-repository ppa:oem-solutions-group/intel-ipu6
[16:54] <ahasenack> "
[16:54] <ahasenack> I'd like to be sure that gstreamer and that v4l package are the only ones being installed from that ppa
[16:59] <juliank> @pilot out
=== ChanServ changed the topic of #ubuntu-devel to: Archive: open | Devel of Ubuntu (not support) | Build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of Focal-Mantic | Patch Pilots: N/A
[17:03] <tjaalton> ahasenack: sure
[17:03] <ahasenack> I added a comment with that question
[17:03] <ahasenack> and a suggested test case
[17:05] <tjaalton> yes, done now
[17:41] <liushuyu> Hi ubuntu-devel, I would like to ask why https://launchpad.net/ubuntu/+source/cargo/0.67.1+ds0ubuntu0.libgit2-0ubuntu0.20.04.2/+build/26388590 failed without a log?
[17:41] <liushuyu> Is it because the package has been superseded in version?
[17:42] <bdrung> liushuyu, that happens sometimes. the reason for the missing build log in unknown to far AFAIK. Should I retry the build to get some logs?
[17:43] <liushuyu> bdrung: Yes, you can retry and see.
[17:43] <bdrung> liushuyu, pressed the button.
[17:44] <liushuyu> bdrung: seem to have failed the moment you pressed the button
[17:44] <bdrung> liushuyu, yes, that kind of failure is new to me.
[17:45] <vorlon> missing build logs means that buildd-manager lost contact with the instance and couldn't retrieve the logs.  But having it fail immediately is unusual; you should check with launchpad folks about this
[17:47] <liushuyu> vorlon: Will do