[00:35] <rbasak> xnox: you know I've been working on the mongodb FTBFS right?
[00:35] <rbasak> xnox: my fix is ready. I've put up an MP for peer review.
[00:35] <xnox> rbasak, url?
[00:36] <xnox> rbasak, you mean https://jira.mongodb.org/browse/SERVER-33395 right?
[00:36] <rbasak> Yes.
[00:36] <rbasak> xnox: 1758116
[00:36] <rbasak> xnox: bug 1758116
[00:36] <ubottu> bug 1758116 in mongodb (Ubuntu) "mongodb ppc64el FTBFS on 1:3.4.7-1ubuntu3" [Undecided,In progress] https://launchpad.net/bugs/1758116
[00:36] <rbasak> xnox: bug 1758118
[00:36] <ubottu> bug 1758118 in mongodb (Ubuntu) "src/mongo/db/fts/unicode is not optimised on ppc64el" [Medium,Triaged] https://launchpad.net/bugs/1758118
[00:37] <xnox> "I've put up an MP for peer review" -> url?
[00:37] <rbasak> xnox: https://code.launchpad.net/~racb/ubuntu/+source/mongodb/+git/mongodb/+merge/341934
[00:37] <mdeslaur> slangasek: fyi, I am against the xchat-gnome removal
[00:37] <xnox> mdeslaur, have you used hexchat at all?
[00:37] <rbasak> xnox: frankly I'm pretty pissed off at the level that you're interfering with this, given that you washed your hands of it already.
[00:37] <mdeslaur> xnox: yes, but it's gtk2.0, which we are trying to deprecate
[00:37] <rbasak> xnox: I have it under control.
[00:37] <xnox> mdeslaur, true
[00:38] <rbasak> xnox: please stop.
[00:38] <mdeslaur> in fact, AFAIK, jbicha is the one trying hard to deprecate gtk2.0, so I'm a bit puzzled by his bug
[00:39] <mdeslaur> It would be nice to have at least _one_ irc client that works natively in wayland
[00:39] <rbasak> xnox: and if you have comments to make, please discuss them with me first. It's frustrating to find that you're doing things without talking to me about it given that you know I'm on it.
[00:39] <xnox> rbasak, you have been following the discussions on #juju, right?
[00:40] <xnox> rbasak, you are the one told me to talk with balloons and figure things out, which is what i have been doing.... like you said....
[00:40] <xnox> rbasak, you are the one who told me to talk with balloons and figure things out, which is what i have been doing.... like you said....
[00:40] <xnox> also re:altivec, we do have a channel to talk about power issues direct with IBM.
[00:41] <xnox> so instead of regressing performance, or applying an unknown fix, it would be better to escalate it to IBM via our PMs.
[00:41] <rbasak> xnox: I said that *if* you want to do things differently, then you can take responsibility for the whole thing. I'm not aware that you did that.
[00:41] <rbasak> xnox: and if you want to do that, please speak to dpb first.
[00:42] <rbasak> xnox: connecting to IBM about it is part of the plan. That's why I have filed a separate bug.
[00:42] <xnox> cool
[00:42] <rbasak> xnox: but in the meantime I want to land the FTBFS fix to unblock Juju.
[00:43] <rbasak> If/when a fix arrives upstream (quite possibly with IBM's help), then we can upload that - in an SRU if needed.
[00:44] <xnox> rbasak, i still stand by the fact that your facilitation of enabling juju team to use src:mongodb with js engine enabled, is irresponsible from security stand point of view.
[00:45] <xnox> rbasak, and no, that's not what they ultimately want. but they don't have time nor headcount to have what they really want.
[00:45] <rbasak> And I stand by the fact that it is outside of your remit and my remit to speak for the security of Juju upstream, as Juju is not packaged in Bionic.
[00:45] <xnox> i'm just being a responsive community member
[00:46] <rbasak> You're being a community member demanding that others do work.
[00:46] <rbasak> You're not in a position to do that.
[00:46] <xnox> i made no such demands.
[00:46] <rbasak> Sure, we can improve tons of things.
[00:46] <rbasak> This is not an improvement that we've commited to make and support. We've chosen a middle ground instead.
[00:47] <xnox> i did file requests for certain things to be looked at. and they haven't because of ENOTIME, but there are a lot of bugs, which we are valid, and we do acknoweldge by either fixing them or, wont-fixing them.
[00:48] <rbasak> No, you're filing bugs that actively block my work, eg. with block-proposed, without even telling me about it, let alone consulting me.
[00:48] <rbasak> That is out of order.
[00:48] <mdeslaur> xnox, slangasek: I've filed bug 1758210 to remove hexchat from Ubuntu
[00:48] <ubottu> bug 1758210 in hexchat (Ubuntu) "Please remove hexchat from Ubuntu" [Undecided,New] https://launchpad.net/bugs/1758210
[00:48] <xnox> mdeslaur, nice =)
[00:49] <jbicha> lol
[00:49] <Unit193> What? :P
[00:50] <xnox> rbasak, filing a public bug is trivial; so is marking it wontfix with the a comment; or leaving the bug open, but removing the tag.
[00:50] <xnox> rbasak, i'm using the collaboration tools as they were meant to.
[00:50] <rbasak> And pinging me about it is trivial too, but you didn't seem to find the time to do that.
[00:50] <Unit193> Perhaps 'demote' is a better word?
[00:51] <rbasak> Instead you're demanding that we do this differently while also blocking me from making progress while also not committing any time to actually do it.
[00:51] <rbasak> Anyway, I've said my piece. Now: will you leave me alone please, so I can get on and land this without further interference?
[00:52] <xnox> rbasak, you are missjudging me a lot.
[00:52] <jbicha> mdeslaur: of course we're not actually removing gtk2 from universe for 18.04 LTS 🙄
[00:52] <Unit193> Yeah, that'd be insane.
[00:53] <xnox> rbasak, if I were not working, in my free time, for the past few days, on making a minimal supportable juju-mongodb3.4 build with js engines off, i would not have hit the same FTBFS on the test-suite stage of the build to discover and comment on the upstream jira.
[00:54] <xnox> rbasak, i would not have been uploading wiredtiger to enable it to be build on arm64, s390x, ppc64le
[00:54] <xnox> rbasak, i would not have uploaded it to support verbose messaging
[00:54] <jbicha> mdeslaur: Firefox and Chromium aren't native Wayland yet either…
[00:54] <xnox> (and check that we have both newer wiredtiger in the distro, still compatible with mongodb)
[00:54] <rbasak> xnox: why have you not been coordinating this work with me, dpb, or ~ubuntu-server in genreal?
[00:54] <mdeslaur> jbicha: perhaps we should leave gtk2 in main
[00:54] <xnox> rbasak, i would not be making a build that uses system wiredtigered.
[00:54] <mdeslaur> would be nice to get gtk2 compatible with wayland
[00:55] <xnox> rbasak, dude - you said you have no time, to make the standalone minimal build; and that you are doing core packages split (because it makes sense anyway) and that is it. And you said take it with juju, and discuss if minimal build is something they would ahve liked..... as i did..... in #juju chanel.... with talking to balloons.
[00:56] <xnox> rbasak, i'm confused, why you are backtracking on what we disussed now.
[00:56] <rbasak> xnox: no, I'm not.
[00:56] <rbasak> xnox: I didn't think it needed to be said that I expect you to coordinate with everyone involved, including me.
[00:56] <rbasak> You *knew* that I was continuing down this path.
[00:57] <xnox> rbasak, correct, which is the core split. but you did say you want to do this, irrespective of what juju does.
[00:57] <xnox> or uses.
[00:57] <rbasak> No, I said it was _for_ Juju, but acceptable generally for the package.
[00:57] <rbasak> I intended to maintain the core split delta only for Juju.
[00:58] <xnox> i thought you said you chatted with debian about it, and they are ok to take it too, etc... and they ~ubuntu-server did that for all other dbs
[00:58] <xnox> that's what i understood
[00:58] <xnox> sorry. and that juju would be one of the users of core bins - just like they noticed that core split was done everywhere else already
[00:59] <rbasak> Who is going to maintain this juju-mongodb3.4 that you intend to upload in your spare time?
[00:59] <xnox> rbasak, anyway, irrespective of this, i think even 3.4 series are crap, due to lack of openssl1.1 support. thus i'm planning to tackle v3.6, if i find enough time for that.
[01:00] <xnox> rbasak, support on the stable series is easy.
[01:00] <xnox> rbasak, it's supporting it across multiple LTS is hard.
[01:00] <rbasak> Who is going to maintain this juju-mongodb3.4 that you intend to upload in your spare time?
[01:01] <xnox> rbasak, i did talk to them - so what is the support story, beyond bionic and non-out-of-the-archive mongo? and turns out, they have none (or at least baloons was not aware of any). And they do have lack of manpower to be able to maintain juju-mongodbX.Y either in the distro, or outside of distro.
[01:01] <xnox> one option
[01:01] <xnox> is for them to move to upstream builds
[01:01] <rbasak> I am aware. Please answer my question.
[01:01] <xnox> because upstream does provide mongodb builds fro arm64 s390x amd64 ppc64el
[01:02] <xnox> but htat upstream build is "enterprise"
[01:03] <xnox> rbasak, supporting source package of 3.4 in bionic, for lifetime of bionic, is easy, even if by me. It is no harder than support boost.
[01:03] <xnox> rbasak, supporting source package of 3.4 in bionic, for lifetime of bionic, is easy, even if by me. It is no harder than supporting boost.
[01:03] <xnox> rbasak, but not supporting 3.4 build in e.g. 18.10, or beyond.
[01:03] <rbasak> Just you? And you don't consider that irresponsible?
[01:03] <xnox> ideally i want juju-mongodb3.6 in bionic with openssl1.1
[01:04] <xnox> because i think 3.4 series may die soon.
[01:04] <rbasak> What if you're not around? Hit by a bus? You think it's OK to leave your baggage behind in the archive without having consulted any appropriate other Ubuntu developers about it?
[01:04] <rbasak> ...while also having Juju rely on it?
[01:05] <xnox> rbasak, dude. you do know that mwhudson was the one-man person doing juju-mongodb & mongodb all this time.
[01:06] <rbasak> You are missing my point.
[01:06] <rbasak> It's not about how difficult it is.
[01:06] <jbicha> mdeslaur: have you tried Polari?
[01:06] <rbasak> It's about imposing your will on others without consulting with them first.
[01:06] <rbasak> That is irresponsible and antisocial.
[01:06] <xnox> rbasak, and e.g. me getting hit by the bus, will get boost unmaintained in debian & ubuntu, as far as i can tell. already =)
[01:06] <rbasak> You don't get to make that decision alone.
[01:06] <xnox> rbasak, and boost has a bit more users.
[01:07] <xnox> rbasak, i can say the same about you.
[01:07] <jbicha> xnox: rbasak: please don't get hit by a bus
[01:07] <xnox> rbasak, this is a waste of my time, let me go back to coding and building things.
[01:07] <rbasak> No, you can't.
[01:07] <xnox> jbicha, hahahhaha. thanks.
[01:07] <rbasak> I am doing what I'm doing after extensive consultation with a whole load of people.
[01:07] <rbasak> And my actions are backed by ~canonical-server which includes a bunch of Ubuntu core devs.
[01:08] <xnox> good
[01:09] <rbasak> xnox: no, you don't get to ignore the conversation.
[01:10] <rbasak> xnox: you chose to get involved, now you get to take responsibility and work with me to find an agreement on how to continue from here.
[01:10] <xnox> my code is not ready for code review yet
[01:10] <rbasak> What are your intentions now?
[01:12] <xnox> unchanged since yesterday; work on providing a test ppa with juju-mongodb3.4 & juju-mongo-tools3.4; latest upstream point release; js-engine off; no /bin/mongo client shipped; and asking upstream (juju) to review if that is suitable/desirable/better for them. mentioning the build changes, and caveats.
[01:14] <xnox> also i have two patches to send to upstream mongo, to fix their build infra.
[01:14] <xnox> there are mistakes in scons linking scripts for smaller builds
[01:16] <rbasak> Thank you for stating that.
[01:17] <rbasak> From my POV, if you do that and upstream uses that instead of the Bionic mongodb package, then I'd like to back as much of the delta out of Ubuntu universe as I can, as we would have no motivation to maintain it.
[01:18] <rbasak> The FTBFS fixes would have to remain of course, but that can be synced in time I guess.
[01:19] <rbasak> The core split change I'd want to back out unless Debian upload that before we release Bionic. Because otherwise, if Debian decides not to take it, then we'd have to hold a transitional delta until the next LTS.
[01:19] <xnox> rbasak, that would be reasonable. to me the biggest driving factor is to avoid legitimising use of src:mongodb and given any impression that Canonical supports it. Given the nack from security team in keeping it support due to js engine. Having mongodb in main has come up before (with juju and wihtout juju as context) and foundations/security did a lot of analysis on making mongodb supportable for generic users - and it really isn't.
[01:19] <xnox> "and give any"
[01:20] <rbasak> I think I'm justified in being pissed off about this - not because you're doing work in your spare time, but because you've done this without coordination and this is causing me to waste my time.
[01:20] <xnox> FTBFS fixes only -> yeah, we need that regardless
[01:21] <rbasak> "avoid legitimising use of src:mongodb and given any impression that Canonical supports it" -> you should be talking to your manager about this.
[01:21] <xnox> rbasak, i'm pissed off that instead of continuing conversation with me about fixing up juju-mongodb3.2, since the issue was raised early in bionic cycle, the upstream pivoted to stop talking to foundations/mwhudson and instead pivoted to talking to you/ubuntu-server.
[01:21] <rbasak> If that's your rationale, then I still think your inteference is out of order.
[01:22] <rbasak> It's outside the remit of your Ubuntu hat, and not within the remit of your Canonical hat.
[01:22] <xnox> rbasak, because have they said "well then, will have to switch to using src:mongodb instead" things would have been escalated much earlier, and juju-mongodb3.[46] could have been done much earlier.
[01:23] <xnox> rbasak, but, i get pissed off, and let things go. clearly the code they need, in the form they need, does not exist, and needs work. Because mongo has a lot of deps, and is quite fragile/sensitive - any time one touches it, something new pops up to fix. If mongo was easy to build, none of this would have been an issue; and it would have been vendorized by juju a long time ago, like the rest of their godeps.
[01:25] <xnox> "out of order" -> as soon as I discovered it.
[01:25] <xnox> rbasak, also note the https://bugs.launchpad.net/ubuntu/+source/juju-mongodb3.2/+bug/1730706 and the comment from 1st of December
[01:25] <ubottu> Launchpad bug 1730706 in juju-mongodb3.2 (Ubuntu Bionic) "RM FTBFS with new scons, new g++, new C++ standards" [Critical,Confirmed]
[01:25] <xnox> rbasak, that is my context for my involvement. so chronologically, i think the core-split comes after that bug was filed, no?
[01:26] <xnox> clearly there were multiple conversations, in parallel, with certain people involved, but not all.
[01:27] <rbasak> I don't see how that contradicts anything I've said.
[01:28] <rbasak> Yes, the core split proposal came after. I wasn't aware of that bug specifically, but was aware of the general gist.
[01:28] <xnox> "We will seek to ship juju-mongo3.6"
[01:28] <rbasak> That's exactly why, in my understanding, we ended up doing the core split in src:mongodb
[01:28] <xnox> hence, i wrote FTBFS juju-mongo3.2 issues; knowning that 3.6 will land sometime.
[01:28] <xnox> it's quite a change in plan of record; to pivot to a mongo-core split, don't you think?
[01:29] <rbasak> It follows from the conversation on that bug. I only see people declaring that effort was not being committed there.
[01:29] <xnox> rather than saying "please halp, we are late, we have no juju-mongo3.6, can anybody help, please" -> ok then, says xnox.
[01:30] <xnox> rbasak, well, i'm sorry that i trust people when they say they gonna do something or what the plan is.
[01:30] <rbasak> All of that is fine. Taking it upon yourself without coordinating with anyone else is what I have a problem with.
[01:32]  * xnox "hence, i wrote _off_ FTBFS ..." (i suck at grammar, and i better correct myself, before rbasak goes quoting irc logs in emails to the widely followed mailing lists by all the job recruitors ;-) )
[01:33] <rbasak> ?
[01:33] <xnox> rbasak, btw, i think it is not nice quoting irc logs in public mailing lists ;-) the style and tone of irc conversations, is different to emails, mailing lists, and email requests/petitions for policy clarifications.
[01:33] <xnox> rbasak, you could have paraphrased, and summarise irc conversation re:autopkgtest-only-sru
[01:34] <xnox> at least my writting style is different on irc vs mailing lists
[01:34] <rbasak> The IRC logs are public.
[01:34] <xnox> sure, but the audience is different. and when people open and read irc logs, they do it differently, then when they are reading an email.
[01:35] <rbasak> Would you prefer I linked to the IRC logs instead?
[01:35] <xnox> yes
[01:35] <rbasak> I don't see how that would be different.
[01:35] <xnox> because it would force you to summarise what you are linking to.
[01:35] <rbasak> I'm just saving the trouble of someone clicking. I did state that it is an IRC discussion!
[01:35] <rbasak> I did summarise.
[01:35] <rbasak> "Dimitri uploaded a dep8 fix for dovecot in bug 1757265"
[01:35] <ubottu> bug 1757265 in dovecot (Ubuntu Artful) "Ubuntu in the welcome string confuses autopkgtest" [Undecided,Fix committed] https://launchpad.net/bugs/1757265
[01:36] <rbasak> That was (genuinely) my summary.
[01:36] <rbasak> I didn't feel that anything further was needed, because the details aren't relevant to the general question.
[01:36] <xnox> i just think it was rude, to quote irc conversation, even if it was on the public irc channel, in a mailing list email / policy discussion email thread.
[01:36] <xnox> that is all.
[01:37] <rbasak> OK. Sorry. Data point accepted. I'm quite surprised you think that though. If consensus is that it's rude, I'll stop doing it.
[01:38] <xnox> rbasak, i've asked opinions, a few people agreed that i'm not weird, and that it is a bit rude to "quote irc in an email, without consent / asking"
[01:39] <xnox> as a general rule of thumb.
[01:39] <rbasak> I'm in the habit of doing it.
[01:39] <rbasak> For example, if I ping someone asking about a bug, I'll paste the conversation into the bug.
[01:39] <xnox> we typically go very explitic, like "startmeeting" bot command when we are logged, and published minutes to e.g. websites / wikis / mailinglists
[01:40] <rbasak> How else should I record the conversation in a way that's useful to the bug?
[01:40] <rbasak> Are you saying I need to summarise and link every time?
[01:40] <xnox> i'd say copy&paste irc responses form somebody, that purely contain technical details, description of behaviour, code explanations are fine.
[01:40] <rbasak> I genuinely don't see how that's different. I understand that IRC has a different conversational context, but I have always assumed that context switch is obvious to any reader who sees that it's obviously an IRC paste.
[01:40] <xnox> as the person at the time, are in "code comment like writing mode"
[01:42] <xnox> rbasak, for example, our conversation today, i expect not, to be send to juju-devel; or ubuntu-release; or canonical-tech; etc.
[01:42] <rbasak> I didn't think that quoting you from a public, logged channel is something you'd find rude in the slightest. Sorry.
[01:42] <xnox> appologies accepted.
[01:43] <rbasak> I think to be consistent I can only really follow accepted norms on this though, rather than remember to do something special for different people as that would be unrealistic.
[01:43] <rbasak> I'll ask around to try to match my understanding to what people expect.
[01:43] <xnox> cool
[01:44] <sarnold> xnox: fwiw I'd rather see raw IRC in an email than a summary. Summaries can be misleading, even when made carefully and with no ill intentions.
[01:45] <xnox> rbasak, if you want a bit of british humor google for "Tea Consent" youtube video
[01:45] <rbasak> I'm aware of that video :)
[01:45] <xnox> sarnold, sure, i would email security@ubuntu.com full logs of everything i can. because that's a more private venue, who I expect to sanitize things.
[01:46] <xnox> sarnold, we do sanitize bugs before changing them form private -> public.
[01:46] <sarnold> aye
[01:46]  * rbasak is pretty sure that sarnold is a real person rather than just security@ubuntu.com :)
[01:46]  * xnox TIL
[03:50] <slangasek> mdeslaur: xchat-gnome> I have no dog in this, if you want to maintain it you can reupload it and I'll let it back in same as it was removed
[03:50] <slangasek> I just don't know why anyone wants any of these gui irc clients ;p
[03:51] <slangasek> mdeslaur: as for hexchat, given that this is a package synced from Debian rather than an Ubuntu-only package, my threshold for removal is slightly higher
[03:59] <tsimonq2> irssi ftw :P
=== ochosi_ is now known as ochosi
[09:57] <dupondje> xnox: https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=2d1fad641b950520bec1a87c450d0e3b1439e262 => by chance this can be cherry-picked into nm?
[10:31] <_hc> good morning!  hope the bionic freeze is going smoothly.  I'm part of the Debian Android Tools team.  The past two LTS releases, we've synced up right about now, so I'm checking in to see what's needed
[10:31] <_hc> we've being doing testing on bionic and things are looking good
[10:31] <_hc> there are three sync requests for the final bug fixes
[10:34] <_hc> we were not able to get a update of the full SDK complete in time for bionic, so it'll still be on 7.0.0.  but I believe that still has ~3 years of security support from GOogle
[10:35] <_hc> at the very least, that version of adb works with all current Android releases
[10:35] <rbasak> _hc: bug fix sync requests should be fine. Do you have a link to the requests please?
[10:36] <_hc> https://bugs.launchpad.net/bugs/1758192
[10:36] <rbasak> Has anyone in particular dealt with these for you before?
[10:36] <ubottu> Launchpad bug 1758192 in android-sdk-meta (Ubuntu) "Sync android-sdk-meta 25.0.0+8 (universe) from Debian unstable (main)" [Undecided,New]
[10:36] <_hc> https://bugs.launchpad.net/bugs/1758196
[10:36] <ubottu> Launchpad bug 1758196 in fdroidserver (Ubuntu) " Sync fdroidserver 1.0.3-1 (universe) from Debian unstable (main) " [Undecided,New]
[10:36] <_hc> https://bugs.launchpad.net/bugs/1758199
[10:36] <ubottu> Launchpad bug 1758199 in androguard (Ubuntu) " Sync androguard 3.1.0rc2-1 (universe) from Debian testing (main) " [Undecided,New]
[10:37] <_hc> yes, I'm looking it up in the log, one sec
[10:37] <_hc> cjwatson is one person
[10:38] <rbasak> _hc: https://tracker.debian.org/pkg/android%2Dsdk%2Dmeta took me to https://salsa.debian.org/android-tools-team/android-sdk-meta which 404s. Is the link incorrect?
[10:38] <_hc> no, its mid-migration, I can do that now if its needed
[10:39] <rbasak> _hc: no need to fix the link. Just tell me where I can find the VCS to browse pleaes :)
[10:39] <rbasak> (well do fix the link of course, but no need to block on that right now)
[10:40] <_hc> still on alioth https://anonscm.debian.org/git/android-tools/android-sdk-meta.git
[10:40] <rbasak> These all look fine to sync in principle. I'd just like to browse the actual changes to make sure they aren't doing anything unexpected/inappropriate for freeze
[10:40] <_hc> FYI, Debian will be shutting down alioth soon, and all repos should be migrated to salsa.debian.org
[10:41] <_hc> so if you haven't seen that already, expect to see it a lot from here on out :)
[10:41] <cjwatson> I was just doing it because I was around and paying attention, rather than because I have a special interest, so no need to block on me.
[10:41] <rbasak> cjwatson: OK thanks
[10:41] <rbasak> _hc: yeah I'm aware thanks :)
[10:41] <cjwatson> (I think possibly at one point there was a complicated bootstrap to do.)
[10:41] <_hc> correct, not this time
[10:42] <rbasak> _hc: alioth is missing the push of +8 that you're asking for a sync for I think?
[10:42] <_hc> arg, sorry
[10:43] <_hc> rbasak: pushed
[10:44] <rbasak> Thanks, looking
[10:45] <_hc> and https://salsa.debian.org/android-tools-team/android-sdk-meta is up now
[10:48] <rbasak> Syncing android-sdk-meta. Looking at fdroidserver next.
[10:52] <_hc> fdroidserver requires the third sync request: androguard
[10:59] <rbasak> OK, thanks
[10:59] <rbasak> _hc: doesn't https://salsa.debian.org/debian/fdroidserver/commit/c20834080e5b82b8d7a5ea5eef8aaa71e8416d33 _add_ dependencies?
[11:00] <rbasak> For example, doesn't it cause android-sdk-common to be installed when it wasn't before?
[11:00] <_hc> it removes android-platform-tools-base, which has a lot of deps, while adding more specific ones
[11:00] <_hc> that android-platform-tools-base would install
[11:01] <_hc> oops, android-platform-tools-base might not install those two
[11:02] <_hc> android-sdk-common and android-sdk-platform-tools-common have no other deps
[11:02] <_hc> android-platform-tools-base installs libandroid-ddms-java, which installs a few more things
[11:03] <rbasak> It feels like a bigger change to me, and https://tracker.debian.org/pkg/fdroidserver has warnings about installability problems in testing.
[11:03] <rbasak> (androguard I know about, but not the others)
[11:04] <rbasak> Separately, I've just noticed that androguard has a major version bump. Are all changes there suitable for feature freeze?
[11:04] <_hc> yeah, we got it into unstable in time for the bionic freeze, but not testing
[11:05] <_hc> we specifically were working on androguard, fdroidserver, and all the android packages to get them into Debian in time for the bionic freeze
[11:05] <_hc> but I guess I overlooked that LTS imports from testing not unstable
[11:05] <rbasak> It may still be reasonable to update Ubuntu with this, but if the changes are over the feature freeze line, I'm not allowed without consultation with the release team.
[11:05] <_hc> sorry
[11:05] <rbasak> brb
[11:06] <_hc> are ppc64el, mips, s390x even supported arches on Ubuntu? sorry for the mess there, I was just focused on Ubuntu, so thinking arm*/amd64/i386
[11:11] <rbasak> ppc64el and s390x are supported on Ubuntu.
[11:11] <_hc> ok, fixing now
[11:11] <rbasak> We sync from Debian unstable but pretty much the same installability checks Debian does to migrate to testing.
[11:11] <rbasak> Except we don't have minimum aging periods.
[11:11] <rbasak> So in general, if Debian can't migrate to testing, we might well not be able to do so either.
[11:12] <_hc> good to know
[11:12] <rbasak> So a testing migration blocking issue in Debian is something to look at before sync to consider whether it will also block proposed migration in Ubuntu.
[11:13] <_hc> ironically aapt/zipalign aren't hard deps, I just assumed they would always be there
[11:13] <_hc> I've been doing most of my Ubuntu testing with a PPA, never seen other arches there.
[11:14] <rbasak> You should be able to enable ppc64el and s390x on your PPA settings page
[11:16] <rbasak> _hc: where can I find the upstream changelog/commits for androguard please? I don't see a link on the tracker.
[11:17] <_hc> ah, interesting,, I'll try that now
[11:17] <_hc> it'll be a large change:  https://github.com/androguard/androguard
[11:17] <_hc> is that what you mean?
[11:17] <_hc> or a specific file?
[11:19] <rbasak> THat's fine, thanks.
[11:19] <rbasak> I'm interested in "git log old_tag..new_tag" basically
[11:19] <rbasak> Since that's the change you want to land in Ubuntu.
[11:20] <_hc> it'll be large.
[11:21] <_hc> we worked with upstream on androguard 3.1.0 to get it in bionic...
[11:21] <_hc> sorry I didn't catch that sooner
[11:22] <rbasak> OK. Based on https://github.com/androguard/androguard/releases/tag/v3.1.0 the set of changes is too large, IMHO, to be suitable for upload to Bionic after feature freeze without an exception from the release team.
[11:22] <rbasak> I guess that blocks the sync of fdroidserver too then?
[11:22] <rbasak> If you think it's still appropriate to land in Bionic, please follow https://wiki.ubuntu.com/FreezeExceptionProcess and get a +1 from a release team member.
[11:22] <_hc> yeah, but if androguard won't make it into bionic, I can change the fdroidserver deps accordingly
[11:23] <_hc> it'll work without androguard, but works better with
[11:23] <rbasak> Basically edit the bug, explain what you're doing, why you want it, why it's appropriate to break the freeze, etc, and subscribe ~ubuntu-release.
[11:23] <rbasak> Then we can ask a release team member to look at it.
[11:23] <_hc> thanks!
[11:27] <rbasak> _hc: you're welcome. Thank you for looking after this in Bionic. I hope it's clear what you can do to make progress. If not, feel free to ping me.
[11:27] <_hc> I think so
[11:46] <jbicha> rbasak: did you see https://tracker.debian.org/news/942400/accepted-mongodb-13414-1-source-amd64-all-into-unstable-unstable/ just landed in Debian?
[11:51] <rbasak> jbicha: yes, thanks.
[11:51] <rbasak> It's in NEW because of my core split patch that Debian accepted.
[11:53] <jbicha> it's out of new now so maybe we can just sync it later today?
[11:54] <rbasak> I'm concerned that it will FTBFS.
[11:54] <rbasak> It doesn't have https://code.launchpad.net/~racb/ubuntu/+source/mongodb/+git/mongodb/+merge/341934 AFAICT for example.
[11:55] <rbasak> So please don't just sync it without checking it builds and works first.
[11:55] <jbicha> I guess it does: https://buildd.debian.org/status/package.php?p=mongodb
[11:55] <rbasak> (and to be clear, please check with me again before actually pushing the button to sync)
[11:55] <rbasak> On Debian, sure.
[11:56] <rbasak> The current ppc64el FTBFS in Ubuntu appears to be toolchain dependent.
[11:56] <rbasak> I'm not saying it won't work.
[11:56] <rbasak> I just don't want to add to the mess by syncing without checking.
[11:56] <jbicha> no, I mean, it fails to build on ppc64el in Debian too
[11:56] <rbasak> Oh
[11:56] <jbicha> so if y'all could forward that to Debian… :)
[11:57] <rbasak> I'm currently blocked on my manager figuring out what he wants me to do next, so I'm holding uploading the MP on that.
[11:57] <rbasak> But yeah, I'll forward my MP to Debian as part of resolving all of this.
[13:20] <dupondje> https://bugs.launchpad.net/network-manager/+bug/1758331 => would be a nice-to-backport :)
[13:20] <ubottu> Launchpad bug 1758331 in network-manager (Ubuntu) "IPv6 Route to OpenVPN Server is not created" [Undecided,New]
[13:20] <ahasenack> Laney: hi, 'morning. I got another gvfs build with two patches from upstream to add extra logging. I think these are committed even (https://bugzilla.gnome.org/show_bug.cgi?id=794487)
[13:20] <ubottu> Gnome bug 794487 in general "gvfs-test: Increase timeout to 10s" [Normal,New]
[13:29] <ahasenack> hi, archive admin question: https://pastebin.ubuntu.com/p/vnKrkqNczH/
[13:29] <ahasenack> would you reject this NEW package on the basis of the nvml_dbg directory under /usr/lib/$arch?
[13:30] <ahasenack> upstream says:
[13:30] <ahasenack> "Files under nvml_dbg are builds with debugging symbols, logging, asserts and expensive checks that we normally don't want users to run with.
[13:30] <ahasenack> "
[13:30] <ahasenack> the files there also trigger "W: libpmempool-dev: package-has-unnecessary-activation-of-ldconfig-trigger"
[13:31] <ahasenack> dupondje: oh, do you think that's related to https://launchpad.net/bugs/1756032 ?
[13:31] <ubottu> Launchpad bug 1756032 in openvpn (Ubuntu) "No VPN connectivity when accessing tunnel endpoint over IPv6" [Medium,Triaged]
[13:40] <dupondje> ahasenack: i'm quite sure :)
[13:41] <dupondje> I did have the same issue, build nm with the patch, and it works fine now
[13:41] <ahasenack> dupondje: I might be able to get someone to test it, besides myself. I was also hit by that
[13:42] <dupondje> I can send you the .deb's :)
[13:42] <dupondje> or just build it yourself ofc
[13:43] <ahasenack> you could attach a branch to that bug report
[13:44] <dupondje> didn't create a branch :) just build a deb on my own syste,
[13:44] <ahasenack> I'll create a branch and a ppa
[13:44] <jbicha> ahasenack: I ignore https://lintian.debian.org/tags/package-has-unnecessary-activation-of-ldconfig-trigger.html
[13:45] <jbicha> ahasenack: that lintian warning shows up too often and it's not clear that there's anything that should be done for it
[13:45] <ahasenack> jbicha: I think ldconfig being activated could be a bug even, since that subdirectory is not in the ld search path
[13:46] <rbasak> jbicha: I'm more bothered about the shipping of weird extra binary libraries in a -dev package. The lintian warning is just a symptom.
[13:47] <ahasenack> yeah, it pointed me at that, let's consider these two issues
[13:50] <jbicha> dupondje: looks like we just need to update NM from 1.10.4 to 1.10.6 for that issue
[13:52] <dupondje> jbicha: could be an option indeed, its included in 1.10.6
[13:53] <dupondje> somebody got to do it :)
[13:54] <dupondje> its in debian already at least
[13:57] <dupondje> I just want to have it on somebody's radar :) hehe
[13:59] <ahasenack> I know a few people hit by that bug
[13:59] <ahasenack> I can prep/tst packages with the patch, but not a new upstream, that I will leave to somebody else to justify
[13:59] <ahasenack> I'm not that familiar with n-m
[14:09] <jbicha> ahasenack: oh if you want to test, I can put it in a temp PPA for you then :)
[14:09] <ahasenack> https://launchpad.net/~ahasenack/+archive/ubuntu/nm-ipv6-openvpn-1758331/+packages is building with the patch
[14:10] <jbicha> I think we should update to 1.10.6 for bionic anyway so that was my plan eventually
[14:11] <ahasenack> I'm fine with that, I just don't know n-m enough to file a FFe
[14:12] <jbicha> I don't consider this as needing a FFe (new bugfix release in the stable series)
[14:14] <ahasenack> I admittedly didn't go over the changelog
=== xnox_2 is now known as somethingrather
=== jbicha_ is now known as jbicha
[15:56] <mapreri> mdeslaur: btw, I'm quite annoyed by your wording in lp #1758210 that I read as "the UX is suboptimal in gnome shell, so it's trash let's remove it".
[15:56] <ubottu> Launchpad bug 1758210 in hexchat (Ubuntu) "Please remove hexchat from Ubuntu" [Undecided,Won't fix] https://launchpad.net/bugs/1758210
[15:57] <Laney> ahasenack: sorry, I missed your message, do you still need those tests queueing?
[15:59] <mdeslaur> mapreri: huh? I didn't write that
[15:59] <mapreri> oh, that was xnox
[16:00] <mapreri> mdeslaur: sorry, I meshed the messages from you and xnox.
[16:02] <mdeslaur> my intention by filing that bug was to push for someone to port it to gtk3, so that it can be properly confined, etc.
[16:03] <jbicha> mdeslaur: could you reword the bug description and title then?
[16:03] <mapreri> mdeslaur: with "Please remove hexchat from Ubuntu" as a title and subscribing the release team?
[16:03] <mapreri> and then slangasek already subscribed the archive admins…
[16:05] <mdeslaur> yes, at some point in the future I suspect it will be inevitable
[16:07] <mapreri> right, but that's not now… and starting with a title like that and already subscribing AA it's *very* rushed.
[16:47] <slangasek> mapreri, mdeslaur: he had subscribed the release team but it's an AA call, so I changed the subscription
[16:48] <mapreri> slangasek: could you please drop the AA subscription for now?
[16:49] <ahasenack> Laney: yes please, I can't to it myself. No upload privs
[16:49] <Laney> ahasenack: ok, running
[16:49] <ahasenack> thx
[16:50] <slangasek> mapreri: I don't think that's the appropriate action here.  There is a discussion in the bug log, which shows there's not a consensus for this action; I don't think unsubscribing ubuntu-archive is relevant
[16:50] <slangasek> if you were counting on unsubscribing ubuntu-archive to keep an AA from acting on the bug, well, someone could just re-subscribe ubuntu-archive later
[16:50] <mapreri> slangasek: ok (as long as no action is taken)
[16:51] <mapreri> probably I'm a bit concerned due to how RM bugs tend to be acted upon in Debian :)
=== alan_g is now known as alan_g|EOW
[18:18] <rbasak> mapreri: IMHO, it should just be made clear that there's an objection using a bug comment. Whether or not the AAs are subscribed, it's their decision on any action they want to take, so all that anyone else can do is to make sure they're informed and leave them to decide.
[18:19] <rbasak> (and the only path if you object is the tech board)
[18:19] <rbasak> (and the only path if you object _to their decision_ is the tech board)
[18:29] <ahasenack> Laney: hi, do you have the results of those gvfs test runs somewhere?
[18:43] <xnox> mdeslaur, mapreri - yes, i like hexchat, it worked awesome with unity / messenging menu; it doesn't with shell.
[18:43] <xnox> mapreri, polari does things better; so something is broken w.r.t. how hexchat sends notifications to gnome-shell.
[18:43] <xnox> mapreri, i've tried polari, maybe it is just the themeing, but it really is not usable.
[18:44] <xnox> eplisized topic, with full topic only in an tooltip, is not good, given that one cannot click the URLs in a tooltip
[18:44] <xnox> and lack of the server buffer is also quite constricting.
[18:51] <coreycb> bdmurray: we have a regression in neutron in a recent fix. i'm working through the packages atm to revert the change. would you be free in a bit to review? https://bugs.launchpad.net/cloud-archive/mitaka/+bug/1758411
[18:51] <ubottu> Launchpad bug 1758411 in neutron (Ubuntu Bionic) "[SRU] Revert fix for bug 1752838 regression" [Critical,Triaged]
[18:52] <bdmurray> coreycb: I'm going to take a break soon but will be back in about an hour
[18:53] <coreycb> bdmurray: that's fine, thanks
[19:26] <coreycb> bdmurray: ok they are ready for review in the xenial and artful unapproved queues
[20:22] <smoser> wonder if someone could review my package
[20:22] <smoser>  https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1758420
[20:22] <ubottu> Launchpad bug 1758420 in cloud-init (Ubuntu) "separate grub-legacy-ec2 from cloud-init" [Undecided,New]
[21:55] <Laney> ahasenack: same place, https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic-ahasenack-gvfs-test-fixes-1713098/?format=plain
[21:58] <Laney> ahasenack: e.g. https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic-ahasenack-gvfs-test-fixes-1713098/bionic/ppc64el/g/gvfs/20180323_165317_e7060@/log.gz "ftp: blocking job: 0x1a21e512210" is the output of the new g_debug