[00:48] <mwhudson> vorlon: https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#mozjs78 talks about a missing binary on i386 but the new package does not build there, do you need to remove the old binaries?
[00:49] <mwhudson> i'm not sure why it didn't build on i386 though
[00:50] <sarnold> maybe steam folks didn't use it?
[00:51] <mwhudson> here's where i completely forget where the list of packages that build on i386 lives again
[00:51] <sarnold> aye,I was hoping I had it written down somewhere..
[00:52] <sarnold> https://wiki.ubuntu.com/i386 suggests it's a seed
[01:43] <mwhudson> ah yes https://git.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/+git/i386
[01:50] <mwhudson> still don't really undertstand why one version of mozjs78 built on i386 and one didn't
[01:51] <vorlon> the previous version might've been used by something a while ago and no longer is but I haven't done a cleanup of no-longer-needed i386 binaries in a bit
[01:54] <vorlon> ummm this just removed mozjs91 binaries but not mozjs78
[01:54] <vorlon> oh, possibly processing main first, then universe
[01:54] <vorlon> nope
[01:54] <vorlon> hm
[01:54] <vorlon> so mozjs78 IS in the whitelist
[01:56] <vorlon> oh, no, I was working from a stale copy of the whitelist, cough
[02:02] <vorlon> ok, removed now
[02:03] <vorlon> mwhudson: are you looking at ncbi-vdb?
[02:03] <mwhudson> vorlon: no, i was looking at osmo-pcu
[02:03] <mwhudson> vorlon: is that a request? :)
[02:04] <vorlon> ahhh good luck
[02:04] <mwhudson> uh oh
[02:04] <vorlon> nah just wondering, since you're clearly on NBS and I have too many terminals open here paused for looking at ncbi-vdb
[02:05] <vorlon> for osmo-pcu, it looked to me like the person who synced this transition post-FF has regressed BE and should get to keep the pieces :P
[02:05] <vorlon> for ncbi-vdb, my next step was going to be to try to reproduce in Debian
[02:05] <vorlon> since there's no sign of this particular failure on ci.debian.net
[02:15] <mwhudson> what on earth, this is some kind of c++ initializer ordering problem
[02:22] <vorlon> which one?
[02:25] <mwhudson> omso-pcu
[02:25] <mwhudson>         /* e must make sure to initialize logging before the BTS static
[02:25] <mwhudson>          * constructors are executed below, as those call libosmocore APIs that
[02:25] <mwhudson>          * require logging already to be initialized. */
[02:25] <mwhudson>         __attribute__((constructor)) static void early_init(void)
[02:25] <mwhudson> somehow this isn't happening
[02:25] <vorlon> funfun
[02:26] <mwhudson> or the authors are making assumptions about ordering that are not always valid
[02:29] <jamesh> sounds like a job for .preinit_array
[02:29] <mwhudson> jamesh: do you know how this stuff works? it's c++ static initialization vs __attribute__((constructor))
[02:33] <jamesh> iirc, C++ constructors are called via the array of function pointers in the .init_array section
[02:33] <jamesh> .preinit_array is called before that
[02:34] <mwhudson> huh you can pass a priority to the constructor attribute too
[02:35] <jamesh> we used .preinit_array in snapd's snap-update-ns to do some work before Go's init functions
[02:37] <mwhudson> "However, at present, the order in which constructors for C++ objects with static storage duration and functions decorated with attribute constructor are invoked is unspecified."
[02:38] <mwhudson> lalala
[02:38] <jamesh> right. But .preinit_array will be called before anything in .init_array
[02:38] <mwhudson> jamesh: right
[02:38] <mwhudson> also hilariously upstream's git repository seems to have gone away?
[02:39] <mwhudson> also time for childcare duties
[02:40] <jamesh> I think the only way to guarantee ordering of C++ static initialised objects is to have their constructors reference the other.
[02:44] <jamesh> e.g. the stdlib iostreams plunking an __ioinit object in every object that includes <iostream>
[03:47] <mwhudson> jamesh: it's not c++ static initializer vs c++ static initializer tho
[03:47] <mwhudson> https://github.com/osmocom/osmo-pcu/blob/master/src/bts.cpp#L60
[03:47] <mwhudson> OH MY GOD
[03:48] <mwhudson> " Once we support GCC4.7 and up we can change the code below."
[03:49] <mwhudson> ah https://osmocom.org/projects/osmopcu/repository/osmopcu/revisions/0a369e560cef5967bdf47a7ee9b36bf98b418cc8/diff/src/bts.cpp
[03:49] <jamesh> could be worse. It could have been gcc 2.96
[03:49] <mwhudson> egcs even
[03:50] <jamesh> at least egcs releases were real releases. There is no upstream gcc 2.96
[03:52] <mwhudson> ah
[03:53] <mwhudson> i had forgotten that drama
[07:48] <schopin> I'm getting a GPG BADSIG error on the jammy InRelease files when trying to update my jammy systems (daily driver but also my schroots), is this a known issue? (tried several mirrors, same problem)
[08:45] <juliank> schopin: Works for me Get:2 http://archive.ubuntu.com/ubuntu jammy InRelease [270 kB]
[08:46] <juliank> schopin: Same if it jumps to french mirror Hit:2 http://fr.archive.ubuntu.com/ubuntu jammy InRelease
[08:46] <juliank> I get: E: Failed to fetch http://ddebs.ubuntu.com/dists/jammy/universe/binary-amd64/Packages.xz  File has unexpected size (4865008 != 4857464). Mirror sync in progress? [IP: 185.125.188.12 80]
[08:47] <juliank> Either ddeb-retriever crashed or that will fix itself any minute now :)
[08:47] <juliank> Fixed itself :)
[10:43] <GunnarHj> sil2100: Can you check if the language pack generation for jammy is broken again. I would have expected some sign of a delta build based on yesterday's source.
[10:44] <sil2100> GunnarHj: I discussed some of that with seb on -release - it seems to work as if you take a look at the queue, you'll see a lot of langpacks arriving:
[10:44] <sil2100> https://launchpad.net/ubuntu/jammy/+queue?queue_state=1&queue_text=
[10:45] <sil2100> Patience! I will accept those once they all arrive at the queue
[10:45] <GunnarHj> sil2100: Ah, great. Forgot about the queue.
[10:46] <sil2100> I switched the delta langpacks crontab on yesterday so I was sure we'd get something today eventually
[10:46] <sil2100> (and if not, I'd take a look later)
[10:46] <GunnarHj> Ack.
[10:46] <Kolusion> A retard has banned me from the #ubuntu channel for no apparent reason.
[10:59] <Kolusion> No wonder desktop users don't want to use Ubuntu even if its for free. With social retards involved, no ones interested.
[11:00] <schopin> Kolusion: regardless of the reason why you were banned on #ubuntu, please note that the Ubuntu CoC applies on all Ubuntu channels, including here.
[11:01] <Kolusion> How many people out of the 194 people in this room do you think have actually read them?
[11:02] <mwhudson> vorlon: ncbi-vdb is crazy, it seems throwing an exception is triggering an abort in the unwind code
[11:05] <mwhudson> i guess it could be some kind of memory corruption
[11:13] <Kolusion> I see I am still banned.
[11:13] <Kolusion> There must be more retard developers that I thought.
[11:13] <Kolusion> No wonder Windows 11 marketshare overtook all of Linux in its 25 years.
[11:13] <Kolusion> On day 1
[11:14] <mwhudson> oh it's lto probably
[11:16] <schopin> mwhudson: it seems "it's lto probably" is often the answer when weird memory/stack corruption is involved...
[11:17] <mwhudson> schopin: yeah i don't think it's memory corruption this time (valgrind has no complaints)
[11:17] <mwhudson> very similar to this, fwiw https://jira.mariadb.org/browse/MDEV-25633
[11:23] <seb128> Kolusion, so you are trying to repeat by acting in an offensive manner here now until you eventually get kicked out for it and use it as a reason to go rant on another channel how idiots kicked you out from the channel?
[11:24] <Kolusion> seb128: No one is acting in an offensive manner. I am simply stating a fact. People don't like Ubuntu people half the time it doesn't work and when people ask for help they usually encounter social retards.
[11:24] <Kolusion> seb128: Like my experience.
[11:24] <Kolusion> seb128: Resisting my opinion is not going to help Canonical.
[11:25] <seb128> Kolusion, you are on the wrong place to share experience, that's a developer channel, we talk about technical problems not social ones
[11:25] <seb128> Kolusion, also calling people retards isn't going to help you
[11:25] <Kolusion> seb128: Ubuntu is a social project- developers and social interaction go hand-in-hand.
[11:25] <Kolusion> seb128: I will call out an apple as an apple.
[11:27] <Kolusion> I have to go now. Ubuntu is a broken piece of trash and now I need to find a solution in Windows 10.
[11:27] <seb128> have a nice day
[11:27] <xnox> why did none of my /ignore /mute commands worked?
[11:28] <xnox> how does one use IRC to ignore messages from certain people? (i use wechat)
[11:30] <seb128> xnox, that should work afaik...
[11:31] <seb128> xnox, or maybe /ignore add <username>
[12:50] <Kolusion> How come no one writes drivers for Ubuntu?
[13:17] <ahasenack> what type of drivers?
[14:11] <jdstrand> amurray, mardy: hey, fyi https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1967884 for something to watch out for
[14:14] <tjaalton> juliank: hi, I'm unable to use 'sbuild --extra-package=...' for sid builds if I have packages built on jammy there, it complains about "'foo.deb' uses unknown compression for member 'control.tar.zst', giving up". is debian missing something?
[14:14] <juliank> tjaalton: Debian does not support zstd compressed deb packages
[14:15] <juliank> tjaalton: The dpkg maintainer did not accept the zstd patches, opted instead for multi-threaded xz decompression to make things faster
[14:15] <tjaalton> juliank: okay
[14:16] <tjaalton> found the thread
[14:17] <tjaalton> but we carry them?
[14:21] <schopin> Yes.
[14:21] <tjaalton> can I default to some other compression for locally built packages?
[14:32]  * ahasenack would also like to know that
[14:34] <tjaalton> dh_builddeb could pass parameters to dpkg-deb, but haven't found an environment value or something to control that
[14:36] <juliank> I don't think there's a way to override this
[14:46] <tjaalton> alright
[15:20] <vorlon> mwhudson: whee the ncbi-vdb blocker is also an LTO-related misbuild of sra-sdk
[18:48] <vorlon> https://people.canonical.com/~ubuntu-archive/nbs.html one knot left... who wants to work on D libraries
[19:20] <seb128> does anyone remember why there is a 'skip' button on the ubiquity side screen?
[19:20] <seb128> and what it is supposed to do?
[19:22] <seb128> trying to git blame the vcs it was added in 2006 and the description mentioned cancelling progress bar, the code is setting a debconf_progress_cancellable to false/true but it's not clear to me how that is ending up to do anything?
[19:22] <seb128> cjwatson, ^ you wrote that code back then, it has been ages ago but maybe you remember some details?
[19:22] <seb128> I'm wondering if we should just remove that button
[19:41] <vorlon> seb128: speaking of, now that jxrlib has been bootstrapped, can you please add it directly to the seed so that it can be dropped from the code? lp:~ubuntu-core-dev/ubuntu-seeds/+git/i386
[19:42] <vorlon> seb128: ECHAN
[19:53] <cjwatson> seb128: goodness, uh, I probably can't remember any more than you can get by tracing through the code for yourself TBH
[19:53] <cjwatson> seb128: I guess it was meant to interact with the debconf cancel capability somehow
[19:54] <cjwatson> Or whatever it's called.  debconf-apt-progress might be worth poring over
[20:04] <seb128> cjwatson, well, trying to follow the code makes me believe it's not doing anything anymore, git blame makes me end up on refactoring commits, I guess I could try to check out older revisions and read what the code was doing back then. Thanks for the reply!
[20:04] <seb128> I will also check debconf-apt-progress
[20:36] <mwhudson> vorlon: yeah and a highly weird one at that
[20:38] <vorlon> ddstreet, rbasak: so uh I don't see anywhere in this TB thread that the actual text (or link thereto) of the proposed charter has been included, can someone who knows actually forward it to the list?
[20:58] <ddstreet> vorlon lol, sorry, it's funny that you are the first one to have noticed that :) i'll follow up on the ML and update the agenda too, and for reference here it's https://wiki.ubuntu.com/UbuntuBackports/Charter
[20:59] <ddstreet> vorlon also i've suggested to the backports team to drop our attempt at getting ratification and just proceed with approving it using our own approval, and move on with real work
[20:59] <ddstreet> but if the TB would like to ratify it, please feel free
[22:57] <mwhudson> tumbleweed: any idea why gnuradio is sad?
[22:58] <mwhudson> how do langpack builds fail
[23:39] <mwhudson> arrrgh glibc/focal/riscv64 failed _different_ math tests in my last retry
[23:44] <amurray> jdstrand: thanks for the heads up - now that I go looking I see I am seeing this too