[08:00] <ginggs> doko: hi, can gsl be sync'd now? it might need another round of rebuilds
[08:37] <lotuspsychje> hey guys, im still having this bug on 17.10: https://bugs.launchpad.net/ubuntu/+source/hexchat/+bug/1576385
[08:37] <lotuspsychje> just letting you know, have a nice day
[09:11] <doko> ginggs: looks fine
[09:12] <ginggs> doko: ok, thanks
[09:14] <ginggs> gsl sync'd now
[10:17] <doko> xnox, jbicha (not here): gjs ftbfs on s390x, but built before
[10:18] <xnox> doko, i saw messages about dropping gjs binaries on s390x
[10:18] <xnox> doko, <jbicha> no objections to dropping gjs/s390x ? on #ubuntu-desktop
[10:19] <xnox> doko, i do not care about gjs, as that's not in the server stack. All the hip server things use nodejs / chromium js engine bits
[11:14] <LocutusOfBorg> tsimonq2, mitya57 ahasenack qtbase merge to fix qtwebkit?
[11:15] <LocutusOfBorg> I'm doing a qtwebkit-opensource-src 5.9.1+dfsg-4build1 with the fixes except for the qtbase bump, just to see how bad we go
[11:16] <LocutusOfBorg> mitya57, maybe you want to deal with it, since you seems to be the one who fixed qtbase :)
[11:17] <mitya57> LocutusOfBorg, let me look
[11:18] <mitya57> LocutusOfBorg, yes, it needs a dependency on qtbase downgraded. I did not think about Ubuntu when I bumped it in Debian :)
[11:19] <mitya57> And I would rather not merge qtbase at this point of time.
[11:19] <LocutusOfBorg> mitya57, so, upload as ubuntu1 or build1?
[11:19] <mitya57> As it changes debian/control, ubuntu1.
[11:19] <mitya57> Will you do it? I can too.
[11:19] <LocutusOfBorg> doing that already :)
[11:19] <LocutusOfBorg> so I can do something useful there :D
[11:20]  * mitya57 looks why previous version FTBFS on armhf
[11:20] <LocutusOfBorg> mitya57, symbols
[11:20] <LocutusOfBorg> symbols sadness
[11:21] <LocutusOfBorg> btw, queues are empty, so it might even be a good time for a qtbase merge
[11:21] <LocutusOfBorg> this is actually the reason for me asking
[11:21] <LocutusOfBorg> I already have the dput ready to go BTW, I want the "build logs less than 20MB patch"
[11:22] <mitya57> LocutusOfBorg, please wait a couple of minutes before upload
[11:22] <mitya57> LocutusOfBorg, they won't be less than 20MB. They will be less than 500MB :)
[11:22] <LocutusOfBorg> lol
[11:23] <LocutusOfBorg> I'm ready to go, on your ack
[11:27] <mitya57> LocutusOfBorg, can you please include also this? https://paste.ubuntu.com/25362023/ it should fix armhf build
[11:28] <LocutusOfBorg> uploading!
[11:29] <LocutusOfBorg> is this something due to the change of linker?
[11:29] <LocutusOfBorg> additional dup symbols?
[11:30] <mitya57> I don't know why that symbol exists only on some archs. It is not inline.
[11:30] <mitya57> The linker was changed only in Debian, in Ubuntu we are not using gold already.
[11:30] <mitya57> Thank you!
[11:32] <mitya57> And your upload LGTM :)
[11:33] <LocutusOfBorg> thanks!
[11:35] <LocutusOfBorg> mitya57, why it is not inline?
[11:35] <LocutusOfBorg> #if ENABLE(PARALLEL_GC)
[11:35] <LocutusOfBorg> void registerGCThread();
[11:35] <LocutusOfBorg> WTF_EXPORT_PRIVATE bool isMainThreadOrGCThread();
[11:35] <LocutusOfBorg> #elif PLATFORM(MAC)
[11:35] <LocutusOfBorg> WTF_EXPORT_PRIVATE bool isMainThreadOrGCThread();
[11:35] <LocutusOfBorg> #else
[11:35] <LocutusOfBorg> inline bool isMainThreadOrGCThread() { return isMainThread(); }
[11:35] <LocutusOfBorg> #endif
[11:35] <LocutusOfBorg> now, I don't know if it takes that else or not, but it might be
[11:38] <LocutusOfBorg> maybe PARALLEL_GC is not defined on arm?
[11:39] <LocutusOfBorg> anyhow, removing qtwebkit directory, my eyes are bleeding
[11:41] <mitya57> LocutusOfBorg, oh, I was looking at dev branch instead of 5.9.1
[11:42] <mitya57> In any case it is not always inline, only when parallel GC is enabled.
[11:42] <mitya57> So it could be (optional=inline) in the symbols file, but really it is (optional=complicated) :)
[11:43] <LocutusOfBorg> I would say only when parallel GC is NOT enabled
[11:43]  * mitya57 will add the optional tag to Git if the same diff is needed in Debian
[11:43] <mitya57> Right, sorry
[11:43] <LocutusOfBorg> wonderful, no problem, I just started looking at qt stuff, and I feel noob
[11:44] <LocutusOfBorg> btw qtbase in Ubuntu is using ld linker, why aren't we hitting the duplicate symbol files issue?
[11:44] <LocutusOfBorg> I see in qtbase armhf log some --no-use-gold-linker or such
[11:44]  * LocutusOfBorg is sorry if the answer is obvious, this is the first time he tried to understand all that stuff
[11:45] <mitya57> LocutusOfBorg, Ubuntu hit this bug earlier (some releases ago) and applied the fix earlier than Debian.
[11:46] <mitya57> The fix is *not* using gold (gold is default in upstream Qt, so needs to be disabled explicitly).
[11:46] <mitya57> Actually s/some releases ago/one release ago/: https://bugs.launchpad.net/ubuntu/+source/qtbase-opensource-src/+bug/1656431
[11:47] <mitya57> This bug is the same as Debian #852035
[11:53] <LocutusOfBorg> mitya57, mmm we fixed it in qt 5.7.1, but qt5.9 was syncd from debian, so the fix was lost, right?
[11:53] <LocutusOfBorg> well now gold seems disabled everywhere
[11:54] <LocutusOfBorg> (in debian)
[11:55] <mitya57> LocutusOfBorg, qtbase 5.9 was merged, not synced. gold is disabled everywhere in ubuntu too.
[11:55] <mitya57> LocutusOfBorg, if you want I can adjust debian/rules in ubuntu+1 branch so that it does not differ from Debian?
[11:56] <LocutusOfBorg> it would be nice to make it syncable at the end
[11:56] <LocutusOfBorg> I mean all the qt stuff
[11:56] <LocutusOfBorg> tsimonq2, and I are working in that direction
[11:59] <mitya57> I am working in that direction too :) Currently we have only four packages with delta: qtbase, qtdeclarative, qtmultimedia (will be dropped with 5.9.2) and qtwebkit (temporary)
[12:00] <mitya57> In Debian we want to enable OpenGL ES on arm64 with Qt 5.9.2 packaging, which was a large part of Ubuntu delta.
[12:01] <mitya57> The only remaining delta in qtdeclarative is transitional packages, that can be dropped after 18.04.
[12:02] <mitya57> That is a big progress: in 5.7.1 times the qtdeclarative delta was huge
[12:02] <mitya57> Well, I was not quite right, there is also a patch to fix s390x weirdness.
[12:03] <LocutusOfBorg> s390x weirdness due to gcc different optimization levels?
[12:03]  * LocutusOfBorg is not aware of that patch/package
[12:04] <xnox> s390x does not have different optimization levels
[12:04] <mitya57> https://bugreports.qt.io/browse/QTBUG-61579, testcase_array_iteration.patch
[12:04] <LocutusOfBorg> wasn't it built with -O3?
[12:05] <xnox> no, never
[12:05] <xnox> ppc64le only
[12:05] <LocutusOfBorg> ack thanks
[12:06] <LocutusOfBorg> so, the Bl-symbolic foo applies as delta, right
[12:06] <mitya57> The reason for that weirdness is unknown to me, but we have a workaround
[12:06] <LocutusOfBorg> mitya57, did you try an ubuntu-built gcc compiler on a debian s390x porterbox? :)
[12:06] <mitya57> No
[12:06] <xnox> don't do that
[12:06] <LocutusOfBorg> why?
[12:07] <xnox> s390x porterbox is lower minimal CPU arch than what Ubuntu targets
[12:07] <LocutusOfBorg> oh ok
[12:07] <xnox> Ubuntu requires zEC12+
[12:07] <LocutusOfBorg> so maybe the gcc uses more instructions on Ubuntu?
[12:08] <LocutusOfBorg> we might do the other way around, keeping the gcc from Debian and try in Ubuntu
[12:08] <LocutusOfBorg> but ppa don't have s390x, we need silo
[12:08] <LocutusOfBorg> or try to build a gcc without that bl stuff and no-change rebuild qt
[12:09]  * LocutusOfBorg leaves for lunch, cheers
[12:11] <mitya57> xnox, how does Unity 7 need ubuntu-system-settings-online-accounts?
[12:12] <xnox> mitya57, the expectation is that unity7 desktop "works" where "works" means is functionally equivalent. dropping unity-control-centre & online accounts would, imho, mean "not works". but this is out of scope for me to define what it means to "ship unity7 in 17.10". that is responsibility of the ubuntu desktop team.
[12:13] <mitya57> xnox, but ubuntu-system-settings-online-accounts is a Touch / Unity 8 package. It should not affect the desktop UI in any way.
[12:14] <xnox> yes.
[12:15] <xnox> last time i looked it got entangled with unity7 stuff though
[12:15] <xnox> maybe i got it wrong
[12:15] <xnox> but there is work needed to be done to cut the touch bits out of things that are useful on both unity7 and unity8
[12:15] <seb128> xnox, https://wiki.ubuntu.com/Unity/NotDefaultIssues
[12:15] <seb128> xnox, mitya57, not having online account was an accepted regression
[12:16] <seb128> we just can't maintain unity7 working as it was
[12:16] <xnox> seb128, ah! is that authoritative wiki?
[12:17] <seb128> yes
[12:17] <seb128> well
[12:17] <xnox> seb128, but the indicators must work, right? e.g. indicator-sound should drop dependency on url-launcher.
[12:17] <seb128> it's documented the known regression
[12:17] <mitya57> seb128, thanks for the pointer! Can you please comment on bug 1695928 and bug 1711204 that you (the desktop team) are fine with the proposed removals?
[12:17] <xnox> cause url-launcher is unity8/touch stuff - system-settings-app
[12:17] <seb128> we didn't make a call on what level of support we are still supposed to give to unity7
[12:17] <mitya57> I think slangasek wants an input from Canonical desktop team, which you represent :)
[12:17] <seb128> mitya57, yes
[12:17] <mitya57> Thanks!
[12:17] <seb128> yeah, I already commented on that bug
[12:17] <xnox> seb128, and if questions arise, are you the goto?
[12:17] <seb128> saying that the list is fine
[12:18] <seb128> xnox, willcooke or I yes
[12:18] <xnox> seb128, tah. If i spot stuff whilst doing removals and have questions I will ping you two.
[12:18] <mitya57> xnox, url-dispatcher is easy to port away from ubuntu-ui-toolkit. I can take care of it.
[12:19] <xnox> mitya57, that would make total amount of work to do go down. as we'd need not to patch every single indicator-* to drop the build-dep on url-dispatcher.
[12:20] <xnox> and e.g. i'm not compentant to drop u-u-t from url-dispatcher
[12:20] <mitya57> Yes, my plan was to avoid patching all indicators.
[12:20] <mitya57> I also have no idea what it should do, but I can port the UI and test it :)
[12:20] <seb128> I doubt anything use that UI now
[12:21] <seb128> that was touch specific
[12:21] <seb128> so even if it's buggy/missing it shouldn't be an issue
[12:22] <LocutusOfBorg> wonderful! this makes qtbase candidate, right? :D
[12:22] <LocutusOfBorg> so we can look more carefully to what is missing
[13:05] <mitya57> https://code.launchpad.net/~mitya57/url-dispatcher/qtquickcontrols/+merge/329302
[13:13] <xnox> mitya57, i like it! =)
[13:14] <mitya57> Actually I don’t know what is the point of what I have done, as nobody will use it on desktop. But it will allow url-dispatcher to die a bit later :)
[13:20] <xnox> mitya57, >_< i feel you, and on the other hand feature freeze is on thursday hence YOLO
[13:21] <Faux> Freeze? Quick, time to sneak in openssl 1.1 while nobody is looking.
[13:21] <xnox> Faux, haha, no.
[13:21] <xnox> Faux, have you seen the state of openssl 1.1 in debian and the mega flame war thread
[13:21] <xnox> ?
[13:22] <Faux> I haven't, since the one about having to do a release with two versions and e.g. curl being a nightmare.
[13:22] <xnox> ahhhh tl;dr there is more stuff "discussed" now
[13:23] <Faux> There's not really much to discuss, except "when", and "I don't like it wah wah".
[13:25] <xnox> Faux, literarly that's not what is discussed or causing contreversy now.
[13:26] <Faux> Haha. Maybe I should go look. -devel?
[13:27] <Faux> Oh, I saw the TLS1.0/1.1 thing. Interesting experiment, but not a real problem or appropriate to release.
[13:33] <xnox> i beg to differ
[13:33] <xnox> i have no simpathy for using modern client to talk to old servers; or making my server insecure because of end of life client.
[13:33] <xnox> there is only one logical reason why people
[13:33] <xnox> would want to prevent stronger security.
[13:35] <Faux> If TLS 1.1 had been widely supported even five years ago I might agree with you, but the ~3 years it's been relatively commonplace is just not enough for people to catch on.
[13:39] <xnox> Faux, huh?! precise has TLSv1.2 support
[13:41] <Faux> I'm biased this dropping support for things like Android 4.3, the current release until Oct 2013 (less than four years ago), and openjdk-7, which was the most recent Java release until Xenial.
[13:42] <xnox> Faux, i have no sympathy for obsolete clients, Android 4.3 is long dead and out of security support
[13:43] <Faux> I know! I'd love to see it fixed. But I still think the reality is that you have to give terrible people five years, which will be the case by buster's release, but not 17.10.
[14:05] <doko> tjaalton: plesae don't use llvm-5.0 for mesa yet. llvm-5.0 has a hard coded dependency on gcc-6
[14:05] <tjaalton> doko: ok, damn
[14:15] <doko> apw, looking at https://bugs.launchpad.net/ubuntu/+source/binutils/+bug/1702056: do you build the linux package without having proposed enabled?
[14:19] <ginggs> doko: gsl migrated on its own, no rebuilds required
[14:25] <apw> doko, we do not, but that is an old pre transition kernel
[14:25] <doko> apw: ta, so maybe close the issue
[14:26] <apw> when the new kernel and binutils migrated as a set they also orphaned the old kernel perf
[14:26] <apw> I am supprised that is installable though to get that erroe
[14:59] <doko> LocutusOfBorg: do you intend to package the new lsvpd upstream version?
[18:06] <nacc> slashd: ping
[18:16] <slashd> nacc, hi
[18:19] <nacc> slashd: so i was reviewing the logrotate merge -- and i'm a bit confused why so much of the upstream bits were dropped from your fix to LP: #1709670 ? specifically, you dropped the bits that moved the allocateHash call and so they are incorrect now
[18:23] <slashd> nacc, looking
[18:23] <nacc> slashd: thanks, i think i'll end up dropping your changes in the merge, and taking the strict upstream change, but it might be relevant for the SRUs
[18:24] <slashd> nacc, so you'll do artful and me the SRU does that sound good ?
[18:25] <slashd> nacc, thanks for catching this up
[18:26] <nacc> slashd: right, but it looks like you already did both :) and i'm worried the SRUs might be wrong (and the one in artful looks a bit off too) -- so you might need to change the state there, to indicate it needs another update
[18:26] <nacc> slashd: but yeah, i'll make sure the artful version is correct
[18:26] <slashd> nacc, yeah I'll look at the SRU again.
[18:35] <nacc> slashd: thanks, let me know if you want help reviewing the changes -- sorry I didn't catch it earlier
[18:37] <slashd> nacc, glad you did, still don't understand why I miss that.
[18:38] <nacc> slashd: i only caught it because the patch definitely doesn't apply (I didn't expect it to) to the latest from Debian (which isn't fully cuaght up to upstream), but contains a comment about don't return until we allocate the hash, which doesn't happen with the patch applied :)
[18:47] <rosattig> hi guys, I'm trying to install artful and I got this message -> debootstrap warning: http://us.ports.ubuntu.com/ubuntu-ports/dists/artful/main/binary-ppc64el/Packages.gz was corrupt
[18:47] <rosattig> what does it mean?
[18:47] <rosattig> thanks in advance!
[18:47] <nacc> rosattig: for #ubuntu, perhaps?
[18:48] <rosattig> ok, I can post there thanks. But I thought as it was a development release, this channel would seem more appropriate
[18:49] <nacc> rosattig: this is for development of ubuntu
[18:49] <nacc> rosattig: sorry, #ubuntu+1 then, for artful
[18:49] <rosattig> ok nacc, thanks!!
[18:50] <nacc> rosattig: np
[20:41] <LocutusOfBorg> doko, can you please ask the maintainer to update it in Debian too?
[21:06] <slangasek> mitya57: so bug #1695928 is not filed against the packages that you say should be removed. Do you want to correct that? or jbicha?
[21:21] <mwhudson> Laney: that's one special docker bug you have there
[21:24] <mwhudson> waait how the fuck are docker autopkgtests marked as always failing on ppc64el
[21:24] <mwhudson> they were definitely working at some point
[21:25] <mwhudson> slangasek: why did you mark docker badtest?
[21:25] <mwhudson> slangasek: without at least talking to me? :)
[21:26] <mwhudson> biab
[21:27] <slangasek> mwhudson: according to the comment in my hints file, the tests were failing when run against the release pocket alone, so the test had already regressed in release when I set the hint
[21:27] <mwhudson> slangasek: :(
[21:31] <mwhudson> at least it fails on amd64 too so i have some hope of debugging it
[21:32] <mwhudson> i wonder if it's some change in how the lxd images are built
[22:31] <jackpot51> What does MIR mean in an issue title?
[22:31] <nacc> Main Inclusion Request
[22:31] <nacc> jackpot51: ---^
[22:31] <Unit193> Or a bug against the Mir display server, they named two different things by the same name.
[22:31] <nacc> heh
[22:31] <nacc> I assumed MIR referred to the former, and Mir to the latter in bugs, but I suppose that's not always going to be true :)
[22:32] <Faux> Or the Rust intermediate representation!
[22:57] <seb128> bah, I copied the new libreoffice from a ppa but to artful instead of artful-proposed :-/
[23:00] <xnox> seb128, i thought new ubuntu-archive-tools did have a fail-safe net, to prevent archive admins from doing that.
[23:00] <xnox> seb128, demote to proposed? and resurrect the old one?
[23:00] <seb128> xnox, seems not :-/
[23:00] <seb128> how do I do that?
[23:00] <xnox> i'm not an AA, but it is possible.
[23:00] <xnox> slangasek, doko, wgrant, can you help seb128 ?
[23:01] <xnox> seb128, there should be a demotion script available in the ubuntu-archive-tools. and then it's a copy-package from artful to artful with a flag to allow copying deleted packages. make sure to use exact version number.
[23:01] <xnox> something like that, but I do not know for sure.
[23:08] <seb128> xnox, k, tried to do that, I hope I did it right :-)
[23:09] <xnox> seb128, ok, i see new libreoffice in proposed. that looks good.
[23:10] <xnox> I do not see resurrected libreoffice, yet. there are double copy bugs, where if you do it twice it gets lost, thus if it's not there after 2 more publisher runs, you may need to do the ressurect again.
[23:10]  * xnox ponders block-proposed bug until ressurection is done
[23:10] <xnox> ah, 5.3 is in artful-proposed, so it should migrate
[23:11] <xnox> seb128, if you have powers - just hint to skip / ignore tests for old libreoffice to migrate http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#libreoffice
[23:12] <seb128> I don't know how to do that
[23:12] <xnox> hm or not, i am confused, i shall stop talking.
[23:12] <seb128> xnox, demotion failed with a "no binary to copy"
[23:12] <xnox> (it's entangled with poppler, etc)
[23:13] <xnox> seb128, send an email to release, things look ok now, but i'm not sure if they could be improved and like have some libreoffice in artful-release
[23:13] <seb128> well copying back the old version seems to have failed
[23:14] <seb128> or at least I don't see it
[23:14] <seb128> score :-/
[23:14] <xnox> don't do it again, until a publisher run.
[23:14]  * xnox somehow things that lp bug is not fixed yet.
[23:14]  * xnox somehow thinks that lp bug is not fixed yet.
[23:15] <seb128> k
[23:19] <seb128> well, it looks like libreoffice-l10n failed or isn't showing in artful yet
[23:19] <seb128> libreoffice is pending
[23:19] <seb128> I guess I'm just going to call it a day and see how things look like in the morning/try to sort it out if nobody else fixed up for me in between
[23:19] <xnox> yeah, it looks ok now.
[23:20]  * xnox needs to sleep too
[23:20] <Unit193> No, sleep is bad.
[23:55] <nacc> mwhudson: did you send the delta for src:python-pika-pool (from 1ubuntu2) to debian?
[23:55] <mwhudson> nacc: i guess if you're asking you can't see a bug in debian bts and the answer is probably no?\
[23:55] <nacc> coreycb: --^ i guess you did the last upload to debian, presumably the same change as our last is needed there and we can then sync it?
[23:56] <nacc> mwhudson: more to get the conversation rolling ;)
[23:56] <nacc> mwhudson: and <cough>submittodebian<cough> you
[23:56] <mwhudson> yeah looks like that one got missed
[23:56] <nacc> np, i'll send it up
[23:56] <mwhudson> thanks :)


[12:05]  * bittin listening to todays podcast while helping out in the GNOME stand at FOSDEM Online 2022


[03:16] <Fudge> anyone else think that thread on list is getting a bit old
[03:47] <TheMuso> No, debate and discussion is healthy.


[10:50] <KGB-2> gnome-shell-extension-easyscreencast pristine-tar b7e71b5 Samuel Henrique gnome-shell-extension-easyscreencast_1.6.3.orig.tar.gz.delta gnome-shell-extension-easyscreencast_1.6.3.orig.tar.gz.id * pristine-tar data for gnome-shell-extension-easyscreencast_1.6.3.orig.tar.gz * https://deb.li/iilUv
[10:50] <KGB-2> gnome-shell-extension-easyscreencast pipeline Samuel Henrique 380360 * running (extract-source: running; piuparts: created; blhc: created; autopkgtest: created; lintian: created; reprotest: created; test-crossbuild-arm64: created; test-build-all: created; test-build-any: created; build source: created; build i386: created; build: created)
[10:59] <KGB-0> gnome-shell-extension-easyscreencast pipeline Samuel Henrique 380360 * [8 minutes and 26 seconds] failed (piuparts: success; autopkgtest: success; reprotest: failed; test-build-all: success; lintian: success; test-crossbuild-arm64: success; test-build-any: success; blhc: success; build i386: success; build: success; build source: success; extract-source: suc
[10:59] <KGB-0> shell-extensionscess)


[07:46] <pleia2> akgraner: great news re: zareason!
[07:49] <elky> yep, i'm blogging with some clarifications now
[07:50] <elky> whilst simultaneously squeeing at my new boots
[07:50] <elky> so it might take a while
[07:53] <pleia2> hehe
[07:54] <pleia2> I've also still been talking to cathy about shirts, this one local place does them and she said we may even get it down to like $6/shirt
[07:54] <pleia2> and she liked the first design on our tshirt page
[11:28] <valorie> elky, adorable boots!
[15:28] <nigelbabu> czajkowski: had a good oggcamp?
[15:51] <Marttin> this is my place
[15:52] <nigelbabu> elky: hows the participation for the competition?
[15:52] <elky> going good
[15:52] <nigelbabu> nice to hear :)


[07:25] <LinuxNovice> hello, anybody here?
[07:26] <hateball> 68, far as I can see
[07:27] <LinuxNovice> hi..
[07:27] <LinuxNovice> how much space would I require if I need to install an OS in a virtual machine.
[07:30] <hateball> LinuxNovice: by "an OS", do you mean Lubuntu?
[07:30] <LinuxNovice> I am Lubuntu now, if I need to install a Windows OS/
[07:30] <LinuxNovice> ?
[07:31] <LinuxNovice> can we run SAP ERP on Lubuntu?
[07:32] <hateball> ...
[09:44] <dovah> whats the real website lubuntu.me or lubuntu.net?
[12:57] <CrazyDuck> hello, does lubuntu prompt me when there are updates/upgrades available?
[19:52] <n-iCe> Hi guys
[19:52] <n-iCe> is there a minimal installation?
[20:24] <genii> https://help.ubuntu.com/community/Lubuntu/Documentation/MinimalInstall
[22:01] <LiftLeft> I started up compiz, and then my desktop wallpaper disappeared
[22:01] <LiftLeft> then it was blue
[22:02] <LiftLeft> the window borders are pretty ugly also
[22:10] <genii> !info compizconfig-settings-manager


[14:31] <cpaelzer> late just a bit
[14:31] <sarnold> good morning
[14:31] <joalif> o/
[14:31] <didrocks> hey
[14:32] <slyon> heyho o/
[14:33] <cpaelzer> ok getting ready ...
[14:33] <cpaelzer> #startmeeting Weekly Main Inclusion Requests status
[14:33] <meetingology> Meeting started at 14:33:09 UTC.  The chair is cpaelzer.  Information about MeetBot at https://wiki.ubuntu.com/meetingology
[14:33] <meetingology> Available commands: action, commands, idea, info, link, nick
[14:33] <cpaelzer> Ping for MIR meeting - didrocks joalif slyon sarnold cpaelzer jamespage
[14:33] <cpaelzer> most of you are here already, just me being slightly late due to head to head meetings - sorry :-/
[14:33] <cpaelzer> #topic current component mismatches
[14:33] <cpaelzer> Mission: Identify required actions and spread the load among the teams
[14:33] <cpaelzer> #link https://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg
[14:33] <cpaelzer> #link https://people.canonical.com/~ubuntu-archive/component-mismatches.svg
[14:33] <cpaelzer> let us see what this week has new for us
[14:34] <cpaelzer> nothing in non-proposed
[14:34] <cpaelzer> but a lintian explosion in -proposed
[14:34] <slyon> ugh lintian... they're adding new dependencies quicker than we can process them :)
[14:34] <slyon> lintian got a new maintainer upstream and I think there was a big re-organization of the code
[14:34] <sarnold> or.... hooray for more automated checking :) (I hope)
[14:34] <cpaelzer> which is all great, but paingul
[14:34] <cpaelzer> slyon: a question, is there a strong resaon it needs to be in main
[14:34] <slyon> I'll check those new dependencies. and assign them out within foundations, as needed
[14:34] <cpaelzer> slyon: it does not have to be as a build-dependency
[14:35] <didrocks> perlpainful even :p
[14:35] <slyon> cpaelzer: yeah.. we had that discussion during the Frankfurt sprint. But there were some strong opinions about keeping it in main
[14:35] <slyon> I can lookup the details if you want to
[14:35] <cpaelzer> ok, then you said it right -sort out the MIRs on your end and file them
[14:35] <cpaelzer> just wanted to ask to be sure
[14:36] <cpaelzer> the rest are known false positives
[14:36] <cpaelzer> or cases waiting for review
[14:36] <sarnold> openwsman?
[14:36] <cpaelzer> sarnold: that whole maas seed thing is there forver and not changing
[14:37] <cpaelzer> it is aphilospohopy questions, someone decided to declare a seed as maas uses those, but no one stepped up owning and promoting the packages
[14:37] <sarnold> aha. it felt vaguely familiar but I didn't see openwsman in /lastlog. this should do for another few months then.. heh
[14:37] <cpaelzer> it is a very special case of false positives
[14:37] <cpaelzer> TBH all cases that are up are in the security queue
[14:37] <cpaelzer> so you can clear this view a lot sarnold :-P
[14:38] <cpaelzer> #topic New MIRs
[14:38] <cpaelzer> Mission: ensure to assign all incoming reviews for fast processing
[14:38] <cpaelzer> #link https://bugs.launchpad.net/ubuntu/?field.searchtext=&orderby=-date_last_updated&field.status%3Alist=NEW&field.status%3Alist=CONFIRMED&assignee_option=none&field.assignee=&field.subscriber=ubuntu-mir
[14:38] <cpaelzer> none
[14:38] <didrocks> \o/
[14:38] <cpaelzer> really, I thought I have seen one in my inbox this week
[14:38] <cpaelzer> let me see if it shows up in incomplete
[14:38] <cpaelzer> #topic Incomplete bugs / questions
[14:38] <cpaelzer> Mission: Identify required actions and spread the load among the teams
[14:38] <cpaelzer> #link https://bugs.launchpad.net/ubuntu/?field.searchtext=&orderby=-date_last_updated&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&field.subscriber=ubuntu-mir
[14:39] <cpaelzer> a few updates on those
[14:39] <cpaelzer> https://bugs.launchpad.net/ubuntu/+source/ipmitool/+bug/1978144
[14:39] <cpaelzer> was reviewsed by joalif
[14:39] <cpaelzer> looks good a few todos for the team, soon to be handled
[14:39] <cpaelzer> we can assign this to security already IMHO
[14:39] <cpaelzer> as we usually do
[14:39] <joalif> so this needs sec review
[14:40] <cpaelzer> Lena will add the test details while that is hanging in the sec queue
[14:40] <joalif> but I didn't know if i shoudl assign it to them before the todos are done
[14:40] <cpaelzer> yes joalif, I assigned security now
[14:40] <joalif> ah ok
[14:40] <cpaelzer> https://bugs.launchpad.net/ubuntu/+source/libisofs/+bug/1977959
[14:40] <cpaelzer> this goes on between slyon and alexghiti
[14:40] <didrocks> I think slyon kept in sync with his time
[14:40] <didrocks> team*
[14:40] <slyon> actually:
[14:41] <cpaelzer> ?
[14:41] <slyon> this is a question for didrocks:
[14:41] <slyon> about the .symbols file
[14:41] <didrocks> (I agree about the no additional delta if we can’t get it sponsored to debian)
[14:41] <didrocks> if that was your question :p
[14:41] <slyon> I think we do not want to block on this here. as they're using the "-V" parameter
[14:42] <didrocks> yeah, I agree, but can we try to get them in debian still?
[14:42] <slyon> i.e. dh_makeshlibs -V
[14:42] <slyon> Yes, I feel like it should be sent to Debian, but no need to inroduce a Ubuntu delta, right?
[14:42] <cpaelzer> ack
[14:42] <didrocks> right, this is what I just wrote ^
[14:42] <slyon> ok, thanks for clarification
[14:43] <cpaelzer> Then we have https://bugs.launchpad.net/ubuntu/+source/gsasl/+bug/1972866
[14:43] <slyon> I will talk to Alex, he's out currently, though
[14:43] <didrocks> slyon: just to ensure this is done, forwarded, but ack then. I’ll let you finish syncing with your team
[14:43] <didrocks> good :)
[14:43] <cpaelzer> this goes on in discussion - so far mostly about nothing yet testing it AFAICS
[14:43] <cpaelzer> nothing to act for us right now
[14:43] <cpaelzer> #topic MIR related Security Review Queue
[14:43] <slyon> should this be set to "New"+security?
[14:43] <cpaelzer> Mission: Check on progress, do deadlines seem doable?
[14:43] <cpaelzer> #link https://bugs.launchpad.net/~ubuntu-security/+bugs?field.searchtext=%5BMIR%5D&assignee_option=choose&field.assignee=ubuntu-security&field.bug_reporter=&field.bug_commenter=&field.subscriber=ubuntu-mir
[14:43] <cpaelzer> Internal link
[14:44] <cpaelzer> - ensure your teams items are prioritized among each other as you'd expect
[14:44] <cpaelzer> - ensure community requests do not get stomped by teams calling for favors too much
[14:44] <cpaelzer> #link https://warthogs.atlassian.net/jira/software/c/projects/SEC/boards/594
[14:44] <slyon> I think foundations' part is done on gsasl
[14:44] <cpaelzer> yes slyon
[14:44] <slyon> will do cpaelzer
[14:44] <cpaelzer> set
[14:44] <slyon> thx
[14:44] <cpaelzer> I could ask, but I ask the same thing every week sarnold - so I'm not asking this week
[14:44] <cpaelzer> but the list is huge again :-/
[14:45]  * cpaelzer hugs sarnold for review-pain
[14:45] <cpaelzer> Does anyone have other teams inout on the security queue or its handling atm?
[14:45] <cpaelzer> s/inout/input/
[14:46] <cpaelzer> I guess that is a "no by timeout"
[14:46] <sarnold> there was little progress last week due to a security sprint, which was excellent -- and I expect little this week, as most of my colleagues are on vacation this week and much of next week; however, we had good discussions on performing MIRs, the new folks who have taken some are keen, and I'm still feeling happy thoughts :)
[14:46] <cpaelzer> oh great
[14:46] <cpaelzer> so it seems we can hope that this isn't just on your shoulds soon then
[14:46] <sarnold> yes
[14:46] <cpaelzer> great
[14:46] <cpaelzer> #topic Any other business?
[14:47] <sarnold> none here
[14:47] <cpaelzer> I have a heads up on https://bugs.launchpad.net/ubuntu/+source/mdevctl/+bug/1942394
[14:47] <cpaelzer> this ties into the rust rules that we have discussed a while ago
[14:47] <cpaelzer> https://github.com/cpaelzer/ubuntu-mir/pull/3/files
[14:47] <cpaelzer> I will soon have to rebase and re-propose that to land it
[14:47] <cpaelzer> because we have it almost ready in the form that was suggested
[14:47] <cpaelzer> there are things which we need to reconsider
[14:48] <cpaelzer> for example cargo.lock isn't yet done by the dh_cargo tooling, until it exists one can not provide it
[14:48] <cpaelzer> there are fallbacks in our proposed ruling which we will use
[14:48] <cpaelzer> so far just an FYI so you know it comes
[14:48] <cpaelzer> and sadly the wiki has become immutable again
[14:48] <slyon> nice, thanks
[14:48] <cpaelzer> nothing else from my side
[14:49] <slyon> I have once question wrt my last comment on https://bugs.launchpad.net/ubuntu/+source/lerc/+bug/1977551
[14:49] <slyon> do we require the build to fail on .symbols file changes?
[14:49] <cpaelzer> on breaking symbols change IIRC yes
[14:49] <slyon> the MIR rules state that symbols tracking needs to be in place
[14:49] <cpaelzer> not on just adding new symbols
[14:49] <slyon> lerc is tracking symbols, but ignoring the changes during build
[14:49] <slyon> (only to be checked manually)
[14:49] <sarnold> cargo.lock missing from dh_cargo :( -- do we need to ask our rust experts to help push that over the finish line?
[14:50]  * didrocks likes to use level 4 as discussed the other days, but it’s more a personal preference on package I used to maintain directly
[14:50] <cpaelzer> sarnold: (rust) yes, but I'd decouple the MIR rules and any ongoing package from that. Once it exists it shall be used, but until it does we can't require it
[14:50] <didrocks> I think though that yeah, only on removing symbols (even if adding symbols can break in C++)
[14:50] <slyon> didrocks: ACK, thanks for your input on this one! maybe we don't need to be as strict in the generic rules.
[14:51] <slyon> But I'll ask seb to introduce a delta to make the build fail on symbols changes
[14:51] <cpaelzer> slyon: it should fail on removing a symbol - if it does that it is ok IMHO
[14:51] <sarnold> cpaelzer: I'm afraid if we go down that path we'll eventually have a dozen packages in, and no support, and no incentive to get it done..
[14:51] <cpaelzer> sarnold: and if we don't we can't update more and more waiting on the dh_cargo feature to exist
[14:51] <slyon> cpaelzer: I agree on this. So we need to patch lerc, as the maintainers do not want this, due to it being too much work for C++ libraries with lots of generated symbols names
[14:52] <slyon> that might change on toolchain changes
[14:52] <cpaelzer> slyon: I'm really only having a soft opinion here - I do not maintain much C++
[14:52] <cpaelzer> it feels odd to add delta just for that
[14:52] <slyon> hmm
[14:52] <didrocks> if you want to be scared on how you can break the ABI in C++: https://community.kde.org/Policies/Binary_Compatibility_Issues_With_C%2B%2B
[14:53] <didrocks> and you see that removing symbols is not the only way to break it :p
[14:53] <didrocks> (but I think good enough for most of the cases)
[14:53] <cpaelzer> sarnold: (rust) so yes, let us hard-request that from dh-cargo asap - but allow some way to make progress in between
[14:54] <sarnold> cpaelzer: (rust) yes, that can make sense -- but I'm really only comfortable allowing the first if we also have a resourced plan to get to a better dh_cargo situation
[14:54] <slyon> (c++ symbols) IMO it makes sense to rather be on the safe side and check/adopt .symbols after toolchain changes, rather than missing a ABI break
[14:55] <cpaelzer> ack
[14:55] <cpaelzer> that is the way to go then slyon
[14:55] <slyon> thanks. nothing else from my side
[14:56] <cpaelzer> ok, that sounds like a wrap then
[14:56] <sarnold> thanks cpaelzer, all :)
[14:56] <cpaelzer> thank you all
[14:56] <cpaelzer> #endmeeting
[14:56] <meetingology> Meeting ended at 14:56:57 UTC.  Minutes at https://ubottu.com/meetingology/logs/ubuntu-meeting/2022/ubuntu-meeting.2022-06-28-14.33.moin.txt
[14:57] <didrocks> thanks cpaelzer, all!
[14:57] <slyon> thanks all!
[14:57] <joalif> thanks all