[09:19] <fheimes> ginggs I think the decision for removing c-closc2 s390x binaries for now is totally fair; just fyi meanwhile I asked IBM s390x people to have a look at the c-closc2 issues ...
[10:43] <Guest95> Hi,ubuntu experts
[10:43] <Guest95> We want to add a library to control our device on ubuntu, as far as I know, I need to build my own source code and make it as a package.But I do not know how to do it.
[10:43] <Guest95> I saw a lot of materials online that described how to download ubuntu existing ubuntu package, customize it and then submit the patch, but how can I create a fresh new our own ubuntu package(library)?
[10:43] <Guest95> Thanks in advance.
[11:58] <rbasak> tsimonq2: SRU processing for bug 2040011 is blocked waiting on SRU paperwork. Did you miss the bug comments?
[11:58] -ubottu:#ubuntu-devel- Bug 2040011 in vim (Ubuntu Mantic) "[SRU] Ensure supported codenames are accurate" [Wishlist, Incomplete] https://launchpad.net/bugs/2040011
[11:59] <ginggs> fheimes: ack, thanks!
[13:55] <Skia> to help in the Python transition, is anyone willing to sponsor the patch I uploaded on this bug https://bugs.launchpad.net/ubuntu/+source/crmsh/+bug/2052018 ? Thanks :-)
[13:55] -ubottu:#ubuntu-devel- Launchpad bug 2052018 in crmsh (Ubuntu) "crmsh fails its autopkg tests with Python 3.12" [Undecided, New]
[14:28] <rbasak> sagemath is missing from Noble (removed from Debian testing). I think this will affect a fairly large number of Ubuntu users if we release like that. Volunteers to fix it wanted!
[14:29] <rbasak> sudip: ^ interested? :)
[14:45] <ahasenack> is there a wiki page or discourse post about the FORTIFY_SOURCE=3 change in our build flags? I seem to remember there was something
[14:46] <ahasenack> found it, via https://bugs.launchpad.net/ubuntu/+source/gcc-13/+bug/2012440
[14:46] -ubottu:#ubuntu-devel- Launchpad bug 2012440 in gcc-13 (Ubuntu) "Please add -D_FORTIFY_SOURCE=3 to default build flags" [High, Fix Released]
[14:53] <tsimonq2> rbasak: bug 2040011> I'm aware. There are some non-public elements that have me close to giving up on that, I haven't made my decision yet.
[14:53] -ubottu:#ubuntu-devel- Bug 2040011 in vim (Ubuntu Mantic) "[SRU] Ensure supported codenames are accurate" [Wishlist, Incomplete] https://launchpad.net/bugs/2040011
[15:02] <rbasak> tsimonq2: OK, thanks. Is it OK if I reject from the queue for now, and you can re-uploaded if you take it up again? Otherwise someone from the SRU team has to re-examine the bug on every shift to see if it has been addressed (if they have capacity). It seems like the effort being spent on that is now exceeding the very marginal benefit of the "bug" being fixed.
[15:03] <tsimonq2> rbasak: That is alright with me, thanks for the clarification.
[15:04] <UnivrslSuprBox> adrien: anything you need from me wrt faketime?
[15:06] <rbasak> Done - thanks!
[15:12] <dbungert> ogayot: I'll sponsor LP: #2053016, that will also fix an issue I was chasing for juypter-python
[15:12] -ubottu:#ubuntu-devel- Launchpad bug 2053016 in python-requests-unixsocket (Ubuntu) "console-conf errors on Ubuntu Core 24: HTTPConnection.request() got an unexpected keyword argument 'chunked'" [Undecided, In Progress] https://launchpad.net/bugs/2053016
[15:12] <ogayot> dbungert: excellent, thanks!
[15:17] <adrien> UnivrslSuprBox: I haven't had time to look at it yet unfortunately; not having "native" 32-bit machines doesn't help :D
[15:17] <adrien> I was hampered by an issue with openssl which I just finished pinpointing and reporting so I'll have some time hopefully
[15:35] <UnivrslSuprBox> adrien: the issue replicates perfectly in an i386 chroot on an amd64 host, so luckily no need to drag out a pentium 4
[15:39] <sudip> rbasak: but why is sagemath missing from Noble. Debian unstable still has it. I thought sync will sync from Unstable
[15:41] <rbasak> sudip: https://launchpad.net/ubuntu/+source/sagemath/+publishinghistory
[15:41] <rbasak> Open up the second entry that says "Deleted"
[15:41] <rbasak> > Debian #1055732, ftbfs, removed in testing, remove rdeps brial and sagemath
[15:41] -ubottu:#ubuntu-devel- Debian bug 1055732 in src:fpylll "fpylll ftbfs with Python 3.12" [Serious, Fixed] https://bugs.debian.org/1055732
[15:43] <sudip> rbasak: and to reintroduce that means fixing it in Debian or is that ok to do for Ubuntu only? sorry for the newbie question, this is the first Ubuntu release cycle I am going ti witness
[15:43] <sudip> s/ti/to/
[15:45] <rbasak> sudip: either is acceptable, depending on how appropriate a given fix would be for Debian, how long it'd take to land there, etc. But introducing an Ubuntu delta means maintaining it, and so we should give some thought to that. It's not uncommon for us to put something in a delta to fix it in Ubuntu for now, and put something upstream somewhere so in the long term the fix filters down to Debian and
[15:45] <rbasak> we can sync later.
[15:47]  * sudip will try but cant promise, building sagemath was not a pleasant experience for my laptop
[15:48] <rbasak> Thank you!
[16:59] <ahasenack> waveform: hi, arm64 question: is __NR_signalfd not defined there, just __NR_signalfd4? I'm chasing down a build failure on arm64 and looks like it's because __NR_signalfd is not defined
[17:04] <waveform> ahasenack, I don't know off the top of my head but a quick grep of the headers on my development pi (arm64) is only showing __NR_signalfd4 defined
[18:23] <ahasenack> waveform: yeah
[18:23] <ahasenack> waveform: this https://github.com/fujita/tgt/blob/master/usr/util.h#L106
[18:23] <ahasenack> started to break, I'm not sure since when, but right now in noble it's breaking
[18:24] <ahasenack> that #if is not true (the two conditions), and it goes to #else which basically destroys the signalfd_siginfo struct
[18:24] <ahasenack> defintes it as empty
[18:24] <ahasenack> I'm trying to check how this built before, and when "before" is
[18:25] <ahasenack> """
[18:25] <ahasenack>        There  are two underlying Linux system calls: signalfd() and the more recent signalfd4().  The former system call does not implement a flags argument.  The latter
[18:25] <ahasenack>        system call implements the flags values described above.  Starting with glibc 2.9, the signalfd() wrapper function will use signalfd4() where it is available.
[18:25] <ahasenack> """
[18:26] <ahasenack> what tgt is doing seems wrong, but maybe they worked around an old bug that no longer matters
[18:28] <ahasenack> ugh, that workaround is from 2009
[21:47] <kajiya> I am once again ^^asking for your financial support^^ for sponsorship :D I've got merge proposals into `ubuntu/+source/google-compute-engine-oslogin` that need reviewing/sponsoring if anyone has time. The bug's here for reference: https://bugs.launchpad.net/ubuntu/+source/google-compute-engine-oslogin/+bug/2052438 (noble has already landed, this is an SRU). Cheers!
[21:47] -ubottu:#ubuntu-devel- Launchpad bug 2052438 in google-compute-engine-oslogin (Ubuntu Mantic) "Update d/control file with a dependency on google-guest-agent" [Undecided, New]
[21:48] <kajiya> Ugh the markdown didn't work in that message - my joke is ruined!
[22:36] <arraybolt3> kajiya: :P The way it would usually be done in IRC would be something like:
[22:36] <arraybolt3> I am once again asking for your financial support^U^U^U^U for sponsorship :D ...
[22:37] <arraybolt3> but I got the joke :)