[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 :)