=== jamesh_ is now known as jamesh
[12:55] <doko> stgraber: never got a reply on my lxd question. now filed https://bugs.launchpad.net/lxd/+bug/1803344
[12:55] <ubottu> Launchpad bug 1803344 in lxd (Ubuntu) "lxd fails it's autopkg tests on arm64 in 18.04 LTS" [Critical,Confirmed]
[14:07] <smoser> xnox: around ?
[14:07] <smoser> https://code.launchpad.net/~smoser/ubuntu/+source/open-iscsi/+git/open-iscsi/+merge/358737
[14:08] <smoser> ii've tried to add a test that verifies that the service is running, but I can't seem to get the test to pass.  even though when i run it and log in and look, iscsid will be running.
[14:11] <smoser> i suspect this is just due to how the udev fired WANTS ends up getting done and that it happens too late for the test to see it done.  the test runs as cloud-init user-data.
[14:11] <smoser> any thoughts on how i could test this in a dep8 test?
[14:13] <xnox> smoser, hey, yes, i am around. and I did see your merge proposal and it did look fine.
[14:15] <xnox> it should be testable.... trivially..... to check
[14:16] <smoser> xnox: well, having cluod-init runcmd with systemctl is-active does not seem to work
[14:16] <smoser> shows inactive
[14:25] <smoser> xnox: ^ thoughts ?
=== chrisccoulson_ is now known as chrisccoulson
[14:39] <rbasak> xnox: unfortuntely the released media has a bunch of bugs :-/
[14:40] <rbasak> (eg. not enabling universe)
[14:40] <rbasak> Right now there is no released media that does the right thing by default.
[14:40] <rbasak> That doesn't need manual intervention to fix.
[14:40] <rbasak> (tbh, I don't understand why that bug wasn't a release blocker)
[15:04] <smoser> xnox: my question is just when can i guarantee that the Wants that was added by the udev rule will have been realized and put into effect
[15:05] <akshayrkapadia> Hey, I want to start contributing to Ubuntu development. Do you guys have any advice on where to start? I've read some of the wiki and checked out Launchpad, but its quite overwhelming.
[15:08] <rbasak> akshayrkapadia: I would start by picking a thing that you want to fix, and focusing on that. It might take a few attempts to find something that is both interesting to you and also easier to fix (to avoid diving in at the deep end).
[15:08] <rbasak> akshayrkapadia: try searching for bugs labelled "bitesize"
[15:08] <akshayrkapadia> Thanks
[15:19] <smoser> akshayrkapadia:  and what things interest you?
[15:19] <smoser> if you have interest in kernel development, then bugs in libreoffice wont be too interesting
[15:26] <akshayrkapadia> I'm interested in android integration with GSConnect and Ubuntu desktop experience as a whole. I'm willing to contribute to any project that.
[15:26] <akshayrkapadia> *any project that is coded in python or java
[15:46] <sladen> akshayrkapadia: best way to begin, is to start with that is there.  Use it until you find a bug/spelling mistake/crash, and then try to work out how to fix/improve it
[16:03] <xnox> smoser, yes, that's an easy question. i don't have the answer to that off-hand.
[16:04] <xnox> smoser, on boot, i expect this to be done after udev coldplug retrigger service runs... and udevadm is settled, and all systemd pending jobs are done.... but it's racy.
[16:06] <xnox> cause it's like polling systemctl list-jobs after a udevadm settle
[16:12] <roaksoax> win 10
[17:12] <infinity> vorlon, doko: Any idea who demoted mozc-utils-gui without actually removing it from ibus-mozc recommends?
[17:12] <vorlon> infinity: me
[17:12] <infinity> vorlon: Seems a bit premature. :P
[17:12] <vorlon> infinity: because qtbase grew a new dep on libvulkan-dev
[17:12] <vorlon> and I'd rather have it in c-m than either have a) busywork MIRs or b) qt reuploads while we're trying to work this transition through
[17:13] <vorlon> and the Desktop Team knows they're supposed to figure out the demotion of mozc-utils-gui <-- seb128
[17:14] <infinity> vorlon: Seems plausible that vulkan will land in main soon anyway, but fair enough.  I guess I'll just not look at c-m for a while. :P
[17:17] <seb128> vorlon, yeah, still in our backlog, thx for the reminder :)
[17:21] <vorlon> seb128: it would be helpful to have that done sooner rather than later now, because the above impact to component-mismatches clutter.  Should I consider just uploading to drop the Recommends?
[17:21] <seb128> vorlon, let me look more tomorrow before we do that
[17:21] <vorlon> seb128: ok, cheers
[17:22] <seb128> np
[17:33] <stgraber> doko: latest result shows a success
[17:43] <doko> stgraber: no, not according to http://autopkgtest.ubuntu.com/packages/l/lxd/bionic/arm64
=== Sven_vB_ is now known as Sven_vB
[18:51] <doko> cpaelzer, rbasak: please subscribe the server team to postgresql-11 (same as for -10)
[18:52] <doko> promoted now
[18:57] <vorlon> Laney: seeing as didrocks referenced you in the git commit, fyi I'm dropping ubuntu-desktop-* on s390x.  They were added without consultation with the folks that own the s390x product after having been explicitly excluded from the package; and I don't agree at all with hacking the seeds to make them installable with a different definition of what constitutes the ubuntu-desktop vs other architectures
[19:06] <cpaelzer> doko, thanks I subscribed myself
[19:06] <cpaelzer> ahasenack: you as well please 11
[19:06] <cpaelzer> ^^
[19:07] <ahasenack> hmm?
[19:07] <cpaelzer> powersj: for subscribing the team that would be you who has the right "powers" to do so :-)
[19:07]  * ahasenack scrolls up
[19:07] <cpaelzer> subscribe to postgres-11
[19:07] <ahasenack> hah
[19:07] <ahasenack> I thought your "11" was meant to be "!!"
[19:07] <cpaelzer> ahasenack: powersj: here https://launchpad.net/ubuntu/+source/postgresql-11
[19:07] <stgraber> doko: are we looking at the same page?
[19:07] <ahasenack> "you as well please !!"
[19:07] <cpaelzer> hehe
[19:07] <stgraber> doko: that URL shows me a pass on 3.0.2-0ubuntu1~18.04.1 on 2018-11-09 14:17:52 UTC
[19:07] <cpaelzer> the 1 is just one key away from my ^
[19:08] <powersj> cpaelzer, thanks for the link
[19:08] <powersj> doko, cpaelzer, ahasenack: ubuntu-server is now subscribed to postgresql-11
[19:08] <cpaelzer> thanks
[19:09] <doko> stgraber: that's a different trigger
[19:10] <stgraber> doko: but the same LXD version so it's either some kind of race because of arm64 being slow (has happened before for TLS code) or an actual regression that happened in bionic-proposed
[19:10] <stgraber> doko: anyway, asked for a re-try, we'll see if that one passes
[19:12] <doko> ta, I didn't see any python related, but I wanted to check, and the history isn't all passing ...
[20:12] <jbicha> I started a conversation about mozc: https://community.ubuntu.com/t/removing-mozc-utils-gui-from-19-04/8717
[20:36] <jbicha> qtwebengine-opensource-src failed to build again :( https://launchpad.net/ubuntu/+source/qtwebengine-opensource-src/5.11.2+dfsg-2build1/+build/15658038
[20:39] <Laney> vorlon: Alright, I'm not bothered about building it there. I'm initerested in the "own the s390x product" claim though - you're saying this is a special architecture and we should consult with people before working on int?
[20:39] <Laney> it*
[20:39] <sarnold> no log file? :/
[20:43] <xnox> Laney, it is special, in a sense of the hardware is rediciously expensive and nobody ever owns them, but only leases them from IBM. It is a server architecture only, as it will never have graphics stack on it. And none of the upstream desktops support it. Thus Ubuntu Desktop product is simply not possible on s390x as it currently stands.
[20:44] <Laney> xnox: I understand arguments along the line of "this isn't an Ubuntu desktop"
[20:44] <Laney> What I want clarification on is "folks that own the s390x product"
[20:44] <xnox> Laney, and in practice it is a sponsored port, as without s390x lease from IBM of the mainframe we will not have it anymore.
[20:44] <Laney> In other words, do I have to get permission from someone to do s390x work?
[20:44] <xnox> Laney, no, you don't need permissions.
[20:45] <xnox> Laney, but we are limited by lease terms as to what we are supposed to use it for. And ubuntu desktop is not it.
[20:45] <Laney> This should probably be communicated to developers and enforced.
[20:46] <Laney> If builds can cause Canonical to violate a lease...
[20:46] <xnox> Laney, it was intentional that ubuntu-desktop was not built on s390x, and my change to ubuntu-meta was reverted, without even a mention in debian/changelog.
[20:46] <xnox> Laney, by someone not knowing why we don't build ubuntu-desktop on s390x, and not bothering to ask either.
[20:46] <xnox> Laney, and it slipped the radar, hence it should be reverted.
[20:48] <xnox> Laney, the contract is vague around those things. the biggest takeaway, is that yes ubuntu-desktop does own the desktop product. but only on arches that you support....
[20:49] <xnox> Laney, and ubuntu-desktop arches is amd64 only.
[20:49] <xnox> (canonical supported)
[20:49] <xnox> there is community support for other arches of ubuntu-desktop (somewhat, under ubuntu project umbrella)
[20:49] <xnox> but there is neither for s390x or ppc64el for ubuntu-desktop.
[20:49] <Laney> Right, well, this is where a mismatch comes in for me I think. Up until nrecently all of the desktop was buildable on s390x, so I don't really see why it's incorrect to have shipped ubuntudesktop there. If there wass some special out of band knowledge required then that really ought to have been
[20:49] <Laney> communicat[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[4~ed t.
[20:50] <Laney> Sorr for al lthe typos, I'm on a train and its' too hard to go fix them all
[20:50] <xnox> bah
[20:50] <xnox> looks like you faceplanted the keyboard there =)
[20:50] <Laney> The interwebs angels left my side for a moment
[20:50] <xnox> Laney, it was communicated at the start of the project 3 years ago, that irrespective what it builds or runs; s390x is ubuntu server and cloud only.
[20:50] <xnox> ditto ppc64el
[20:51] <xnox> Laney, and there is no canonical time to work on desktop/graphical things.
[20:51] <Laney> There is not, that is why we didn't fix mozjs60 when it broke.
[20:51] <Laney> But when things were working for free, sure, we ship things.
[20:51] <xnox> not
[20:52] <xnox> shipping ubuntu-desktop meta was not free, and costed us money. hence the bug of removal is escalated again.
[20:52] <xnox> porting mozc gui from qt to gtk looks interesting though.
[20:52] <Laney> I don't understand that
[20:52] <xnox> it looks small enough.
[20:53] <xnox> Laney, hours of engineering and management time spend both at internal IBM and in Canonical managing the relationship, which could have been spent improving the port for things our users actually want.
[20:53] <Laney> Anyway you're telling me my understanding of the *Ubuntu* archive is wrong apparently
[20:54] <xnox> don't revert intentional changes, without asking the previous upload, when one doesn't understand why it was made?!
[20:54]  * xnox thought that is obvious to all of us.
[20:56] <jbicha> xnox: would you be interested in splitting out ubuntu-desktop-meta to a separate source package?
[20:56] <xnox> Laney, what's your understanding? in terms of .debs we generally build whatever. but the meta-packages are a bit special, as they define what it means /Ubuntu Desktop/ or /Xubuntu/ etc. and they are only built when we can support them, as an official flavour.
[20:56] <xnox> which ubuntu-desktop on s390x was never the case, even when we had all the binaries.
[20:57] <jbicha> it doesn't matter to me whether ubuntu-desktop is available on s390x or not, but I was annoyed at seeing changelog entries like
[20:57] <jbicha> https://launchpad.net/ubuntu/+source/ubuntu-meta/1.397
[20:57] <xnox> jbicha, no, why? it makes no sense to do that. And it doesn't matter which source package it is in.... as it still will not allow us to enable s390x ubuntu-desktop.
[20:57] <jbicha> it was inaccurate because those technically weren't added to desktop [s390x] since that package didn't exist
[20:57] <jbicha> it's a limitation of the ./update script compared to debian/control as I understand it
[20:58] <xnox> jbicha, one second.....
[21:00] <xnox> jbicha, i explicitely remove s390x from desktop; and none of those entries relating to s390x were there.....
[21:00] <xnox> jbicha, until you reverted my change....
[21:01] <xnox> jbicha, they will be gone again, and never appear in changelog anymore, once steve's upload is done.
[21:01] <jbicha> xnox: not true, look closely at https://launchpad.net/ubuntu/+source/ubuntu-meta/1.397
[21:01]  * xnox is finding commits
[21:01] <Laney> I found the diff the added it by the way
[21:01] <jbicha> that will happen if suddenly gjs starts to be buildable again on s390x
[21:01] <Laney> https://launchpadlibrarian.net/345242595/ubuntu-meta_1.406_1.407.diff.gz <- think it was an accident
[21:01] <xnox> jbicha, https://git.launchpad.net/ubuntu/+source/ubuntu-meta/commit/?id=68cb6941bca36314dda3a3d7894b93529e3278a2
[21:01] <xnox> jbicha, is where you reintroduced s390x back for ubuntu-desktop, without consultation
[21:02] <Laney> I still don't know about this built-when-supported argument, that's one I've never heard before
[21:02] <jbicha> yes, the immediate driver was https://launchpad.net/ubuntu/+source/ubuntu-meta/1.406
[21:02] <jbicha> those wrong changelog entries annoy me
[21:02] <Laney> Presumably we should go and proactively remove all the other non-supported architectures then. But I don't see anyone kicking up a fuss so I'm a bit confused.
[21:03] <xnox> jbicha, it was fine in 1.345... archive wise. Let me look at changelogs.
[21:03] <jbicha> I apologize for the 1.407 upload which was wrong
[21:03] <xnox> jbicha, sure, we understand.
[21:03] <xnox> jbicha, if there are spurious changelog entries it is annoying.
[21:03] <jbicha> it was wrong for me to not mention in the changelog what I was doing.
[21:03] <vorlon> Laney: it matters for s390x because we have a contract *specifically* around server enablement, and the lack of any display hardware means that an s390x desktop port is always going to be a bastard stepchild
[21:04] <xnox> jbicha, we totally understand that it was a change, with unintentional consequences
[21:04] <Laney> I just have no knowledge that the architectures a seed-generated metapackage is built for ends up implying a support commitment
[21:04] <vorlon> Laney: people come to us and say "but it's in main"
[21:04] <jbicha> if you can figure out a way to avoid the changelog bug, I'm happy to see ubuntu-desktop go away on s390x
[21:04] <vorlon> Laney: we've been deflecting escalations about supporting Network Manager on z. You're welcome ;)
[21:05] <Laney> vorlon: I presume the contract doesn't include supporting that?
[21:05] <xnox> Laney, the bits in launchpad for archive publishing the supported fields do define lots of things, for various parts and arches.
[21:05] <vorlon> ideally, we would have a way at the germinate level to say desktop is not-for-s390x
[21:05] <vorlon> so that none of the binary packages would be in main at all
[21:06] <jbicha> once you remove ubuntu-desktop/s390x there is an interesting question about whether we should even have ubuntu-desktop for other unofficial desktop arches though…
[21:06] <vorlon> but barring that, at least not having ubuntu-desktop present makes it easier to explain
[21:06] <xnox> Laney, recall that server & desktop had different LTS lengths in the past; and it was also true on per-arches basis too. where we had "official" and "ports" arches.
[21:06] <xnox> Laney, jbicha, vorlon - the most annoying thing is that arch:all packages get the "best" lts supported stanza of all.
[21:07] <xnox> jbicha, now i see what you mean by separate package.
[21:07] <vorlon> jbicha: as I said, there's a hardware aspect here.  For each of the other arches, it's at least possible to run the desktop with GPU acceleration and adequate bandwidth to the display hardware
[21:07] <xnox> vorlon, would ubuntu-meta-desktop source package help?
[21:08] <vorlon> xnox: wouldn't help /me/...
[21:08] <vorlon> xnox: I guess the point would be to have a separate update.cfg that doesn't list s390x?
[21:08] <jbicha> yes
[21:08] <vorlon> I'd prefer fixing ./update to honor debian/control
[21:13] <Laney> why do we bother building / testing most packages if the architecture is not intended to encompass the full archive?
[21:13] <Laney> presumably people see some value in having 'unsupported' software available
[21:13] <Laney> it's probably OK to not have this discussion, not sure it's that useful :P
[21:14] <Laney> I could go read the draft withdrawal ageement instead
[21:17] <vorlon> Laney: sure; as I said, for the general case, it'd be enough to demote these desktop binary packages to universe on s390x if there was a way.  And then I wouldn't care from a contract/relationship/support POV whether the ubuntu-desktop package existed on s390x
[21:17] <vorlon> but I would still think it's wrong to provide it, precisely because it's busywork to have it there
[21:18] <vorlon> if you have to add architecture exclusions to make it installable, it's not really the Ubuntu Desktop experience, so why prefer pretending that it is vs. removing the binary?
[21:23] <Laney> I'm behind that, as I said earlier. I just lose my understanding of the subject when we start mixing building binary packages in Ubuntu and Canonical's support contracts.
[21:24] <Laney> I understood that we were able to distinguish on a more fine grained level than main/universe
[21:24] <Laney> Train's pulling in now, thanks for the discussion :-)
[21:24] <vorlon> :)
[21:58] <infinity> xnox: Wait, wait, wait.  I read some of that backscroll.  Are you really saying "ubuntu-desktop not existing and then existing exposing a bug in ubuntu-release-upgrader was the fault of people making ubuntu-desktop exist"?
[21:58] <infinity> xnox: That bug triggering was not "by design". :P
[21:59] <xnox> infinity, dude it's 10pm here
[21:59] <xnox> infinity, thank you for that message
[22:00] <infinity> My apologies for getting to the discussion late? :P
[22:01] <infinity> I still think the "we define our support based on the existence of metapackages" argument is bunk.  "We're not building the metapackages because the rdeps don't exist" is entirely reasonable and needs no debate.
[22:02] <infinity> But tearing jbicha a new one because re-adding the (at the time) installable ubuntu-desktop exposed a release-upgrader bug that we had to fix is ridiculous.
[22:03] <infinity> It was a bug.  We fixed the bug.  The end.
[22:19] <xnox> infinity, i think you brought up something else entirely, which is not what i was referring to at all.
[22:20] <xnox> infinity, the ubuntu-release-upgrader bug was not at all in my mind, i forgot about that a long time ago - and that was just that, a bug in u-r-u.
[22:24] <infinity> xnox: What were the countless hours/days of engineering time that resulted from ubuntu-desktop existing, then?  I'm genuinely curious.
[22:25] <xnox> infinity, there were half a dozen of private bugs filed by ibm qa; and quite afew meetings/hangouts, and f2f, explaining things.
[22:25] <infinity> xnox: Cause no one seemed to notice at all until the release-upgrader bug, when multiple minds were lost.
[22:26] <infinity> xnox: And again, I'll say that if we're defining our contract with IBM by the existence of a metapackage, something's terribly wrong. :P
[22:26] <xnox> infinity, similar timeline, but as far as i recall the upgrade bug was not actually raised by them.
[22:27] <xnox> infinity, let's not go down the path of what's terrible =)
[22:27] <xnox> see Brexit
[22:27] <infinity> xnox: "We're as bad at contracts as the UK Conservative government" does not instill me with confidence.
[22:28] <xnox> infinity, the question of confidence or no confidence is lingering on the tip of everyone's tongues
[22:28] <xnox> Conservative... and Unionist!
[23:34] <TJ-> I've got to page 340 of the UK withdrawl exit agreement... of over 500 pages... I've come to the conclusion it's designed to put readers to sleep so they never reach the most contentious protocols. It's rather like reading Perl code really
[23:50] <jbicha> I think perl is usually a bit more concise than 500 pages
[23:53] <Unit193> I'd like to take this momennt to link a very important perl script: https://unit193.net/beer.pl
[23:55] <jbicha> see, much more concise!
[23:56] <sarnold> beautiful