[01:05] <tsimonq2> @pilot in
=== udevbot_ changed the topic of #ubuntu-devel to: Archive: Feature Freeze (Cosmic Cuttlefish) | 18.04 released | Devel of Ubuntu (not support) | Build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of Trusty-Bionic | If you can't send messages here, authenticate to nickserv first | Patch Pilots: tsimonq2
[01:05] <tsimonq2> This is more of an experiment for now, but I'm following what cyphermox set out in his email: https://lists.ubuntu.com/archives/ubuntu-devel/2018-September/040501.html
[01:06] <tsimonq2> Maybe the bot can eventually be updated to distinguish +1 vanguards vs Patch Pilots but I'll also be looking at the sponsorship queue.
[01:08] <tsimonq2> Ah, I see not much SRU processing lately but it's understandable given the state of the development cycle...
[01:08] <sarnold> woah a patch pilot
[01:08] <sarnold> this takes me back :)
[01:09] <tsimonq2> Yeah, hehe
[01:21] <tsimonq2> sarnold: If you're around, how's this apparmor profile look? bug 1788102
[01:21] <ubottu> bug 1788102 in ntpsec (Ubuntu) "ntpsec's ntpd fails to write ntp.drift file because of apparmor" [Undecided,Confirmed] https://launchpad.net/bugs/1788102
[01:21] <tsimonq2> I don't personally know enough about apparmor so your opinion on it either way would be welcome.
[01:21] <sarnold> tsimonq2: lgtm, richard's usually on the ball
[01:22] <tsimonq2> Cool.
[01:25] <tsimonq2> sarnold: Uploaded to the queue, thanks!
[01:25] <sarnold> tsimonq2: woot, thanks :)
=== giraffe is now known as Guest86558
[02:05] <tsimonq2> @pilot out
=== udevbot_ changed the topic of #ubuntu-devel to: Archive: Feature Freeze (Cosmic Cuttlefish) | 18.04 released | Devel of Ubuntu (not support) | Build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of Trusty-Bionic | If you can't send messages here, authenticate to nickserv first | Patch Pilots:
[02:05] <tsimonq2> https://lists.ubuntu.com/archives/ubuntu-release/2018-October/004611.html
=== zhongjun2_ is now known as zhongjun2
[04:15] <cyphermox> tsimonq2: I did ask how we could update the bot code to distinguish (or replace, since patch pilot is largely a dead thing)
[04:15] <tsimonq2> cyphermox: I don't even know where the code is for it. :/
=== lan3y is now known as Laney
=== _hc is now known as M_hc_[m]
=== M_hc_[m] is now known as M_hc[m]
[12:18] <coreycb> doko: i know python3.7 will be the default in the next ubuntu release, but out of curiosity will it also have python3.6 available?
[12:21] <xnox> coreycb, no, the plan is python3.7 only
[12:21] <xnox> coreycb, for 19.04 that is.
[12:22] <coreycb> xnox: ok thanks, and yes 19.04 is what I was curious about
[12:22] <coreycb> xnox: just formulating an email upstream
[12:22] <xnox> coreycb, does that have some implications? as in, why are you asking? =)
[12:24] <coreycb> xnox: well i'm going to try to enable py37 tests upstream. there might be some push back because not not all tests are passing yet from recent py36 enablement.
[12:25] <coreycb> xnox: looks fairly trivial to enable, but a decent amount of busy work across many projects. getting fixes may be another story. hopefully i can convince them it needs to be enabled and get community focus on fixes soon.
=== cpaelzer_ is now known as cpaelzer
[12:51] <rbasak> juliank: thank you for the version regression report. I wonder if we could perhaps add this to the pending sru report? Or should it be separate?
[12:52] <juliank> rbasak: I don't think it's something to consider in the SRU reporting. It also applies to security updates, and for those, there sometimes are valid reasons to temporarily have the new release in a stable release first
[12:54] <juliank> but not sure
[12:55] <xnox> well, a new archive report to be run and published on ~ubuntu-archive
[12:55] <rbasak> I just wondered about when someone will look.
[12:56] <xnox> juliank, you do know ubuntu-archive-tools repository?
[12:56] <rbasak> If left to the AAs then I suppose they have their own separate reports to check for all the other wrong things too
[12:56] <juliank> xnox: yes
[12:56] <xnox> add it there =)
[12:56] <juliank> I think optimally it should also query security thing and check if any CVEs are fixed in older releases, but not in newer.
[12:57] <juliank> xnox: I will soon
[12:57] <juliank> rbasak: I'm not sure if there's anything actionable for the SRU team except for not releasing an SRU until it has a higher version number in later releases
[12:58] <rbasak> juliank: it might be useful to block releasing to updates (from proposed).
[12:58] <juliank> Maybe britney could check that automatically
[12:58] <rbasak> I know I've accepted from the queue into proposed before with the caveat of "not in updates until fixed in <future>"
[12:59] <rbasak> There is talk of having britney do the release to updates, for all the extra britney checking too.
[12:59] <xnox> it's not actually something we'd want to block on.
[13:00] <xnox> it is legit for something to be good in one release, and stuck in proposed in another, as long as we sort it out eventually.
[13:00] <xnox> a separate report for now, would be good enough.
[13:00] <rbasak> xnox: I'm talking about something different - when the fix isn't in a future release (not even proposed), but the SRU is uploaded to a previous release.
[13:01] <juliank> the problem if the versioning in an SRU is wrong though, and it's in proposed, is that you can't go back to an older version number AFAIUI
[13:01] <xnox> rbasak, which is nothing to do with this report.... cause it acts on what's accepted, not what's proposed.
[13:01] <juliank> i.e. I upload -ubuntu0.1 to bionic, then -ubuntu0.16.04.1 to xenial
[13:02] <juliank> I'd have to upload -ubuntu0.0.16.04.1 to xenial to fix the mess I created
[13:02] <rbasak> Oh, I see.
[13:02] <juliank> xnox: It does show you if the new release has a proposed one though
[13:02] <juliank> i.e. those would be greyed out a bit
[13:02] <juliank> in html
[13:02] <xnox> but like it doesn't look at the queue
[13:03] <juliank> yeah
[13:05] <tsimonq2> rbasak: Britney doing the release to updates> Oooh, I'm curious about that. Autopkgtests and all? Or just a seven day aging period plus bug tags being in order? Is there discussion about this somewhere that I could read up on? :)
[13:07] <rbasak> tsimonq2: AFAIK, it's just something people have mentioned should happen. I don't know that anyone's working on it, and so I don't believe there are any other details.
[13:08] <xnox> tsimonq2, it is running, and does report adt regressions, but i don't think we actually use "unblock" to release sru
[13:08] <tsimonq2> That would be cool.
[13:16] <rbasak> Hmm. On the lines of something being in development -proposed, I have a case where something is in development unapproved but with an SRU ready to go.
[13:17] <rbasak> I presume that's OK as well, but it'd be nice to see it in cosmic-proposed since then it's "guaranteed" to land.
[13:17] <rbasak> I wonder if block-proposed and an accept is appropriate?
[13:18] <rbasak> Or easier if a release team member could review systemd unapproved in Cosmic please?
[13:31] <rbasak> xnox: do you have a git tree or similar for systemd anywhere? Trying to match up pieces of your delta with the changelog.
[13:31] <rbasak> xnox: on that point, given you don't mention the patch names in the changelog, it'd be nice if you used Bug-Ubuntu dep3 headers to help match things up.
[13:36] <xnox> rbasak, no, we don't use dep3 headers, we use git-buildpackage quilt to manage them
[13:36] <xnox> the git is at
[13:37] <xnox> rbasak, https://code.launchpad.net/~ubuntu-core-dev/+git/systemd
[13:37] <xnox> and it is indeed broken by change by commit, and changelog is git-dch managed too
[13:37] <rbasak> xnox: thanks! Just as I've finished breaking down your upload manually :-/
[13:38] <rbasak> I'm not sure that's a reason to not have dep3 headers though
[13:38] <xnox> (the no-dep3 thing kind of comes from debian.... cause their patchset is large, and then we add things ontop and interweb upstream cherrypicks)
[13:38] <rbasak> You can add dep3 to patches that you add though, surely?
[13:39] <xnox> rbasak, well there are topics, so upstream cherrypicks are first, then debian topic debian-specific-patches and then debian topic UBUNTU- prefix is ubuntu-specific stuff
[13:39] <rbasak> eg. debian/patches/core-move-enforcement-of-the-start-limit-into-per-unit-type-code-again.patch has one, just with no Bug-Ubuntu.
[13:39] <xnox> but gbp pq import/export doesn't process those
[13:39] <xnox> and they don't end up in the changelog
[13:39] <xnox> LP: # -> do
[13:40] <xnox> cause gbp pq, tries to ensure that patches are `git am`ble & `git format-patch`able & dpkg `quilt-applicable`
[13:40] <xnox> rbasak, if gbp pq gains dep3 support, that would be nice.
[13:40] <rbasak> Yes but AIUI none of that prevents you from adding Bug-Ubuntu dep3 headers
[13:41] <rbasak> Put it in the commit message and it'll end up in the quilt patch, no?
[13:41] <xnox> i'd still have to put in LP: #, as well
[13:41] <rbasak> Yes you would.
[13:41] <rbasak> As you would when adding dep3 headers and not using git.
[13:41] <xnox> have you heard of DRY?! =)
[13:41] <rbasak> All I'm saying is it makes it difficult to review.
[13:41] <xnox> LP: # urls are clickable on all ubuntu terminals
[13:42] <rbasak> dep3 solves the problem, allowing reviewers to match things up.
[13:42] <xnox> do you not use gnome-terminal?
[13:42] <rbasak> An LP reference in the changelog doesn't tell me what the corresponding quilt patch is.
[13:42] <xnox> i'm not sure how dep3 helps here
[13:42] <rbasak> Some people put the quilt patch name in the changelog entries. You do not, which is fine, but then I'd like dep3 to help me match things up.
[13:42] <xnox> yeah cause that is only visible in the git repo
[13:43] <rbasak> Which I didn't have before, and Vcs-Git doesn't point to it.
[13:43] <rbasak> In any case, AIUI, uploads are expected to follow convention and stand on their own without VCS.
[13:43] <xnox> sure
[13:44] <sforshee> LocutusOfBorg: it turns out that the upstream vboxvideo does not have dependencies on vboxguest like I thought, so we can just disable it
[13:44] <sforshee> I've sent patches to start using the dkms drivers again - https://lists.ubuntu.com/archives/kernel-team/2018-October/095882.html
[13:44] <sforshee> Odd_Bloke: ^
[13:45] <xnox> cause like our ./debian/git-cherry-pick script which we use for cherrypicking things from upstream, and injecting it in the right place in the quilt stacks doesn't autogenerate stanzas either
[13:45] <xnox> as we use plain `git cherry-pick` there
[13:45]  * xnox ponders if that can grow "better" referencing integration
[13:45] <rbasak> I don't think it's OK to blame your tooling. As we established, it's trivial for you to add dep3 in your commit messages like everyone else does.
[13:46] <rbasak> (AFAIK, everyone else using dep3 currently writes them by hand)
[13:48] <xnox> rbasak, the only patch with dep3 i see, was actually contributed to the upload and was not done by me. and doesn't actually follow systemd packaging conventions.
[13:49] <xnox> but i tend to take contributions as is, if they apply correctly and work correctly, cause i value their contibutions to systemd packaging.
[13:49] <xnox> thus dep3 header in that one patch is exception, in systemd, rather than the norm.
[13:52] <rbasak> xnox: my request still stands. Please use dep3 headers when uploading SRUs, since it makes reviewing easier.
[13:56] <LocutusOfBorg> sforshee, did you take vboxvideo from which package?
[13:56] <LocutusOfBorg> I added a kernel 4.18 patch in 5.2.18
[13:59] <xnox> https://git.launchpad.net/~ubuntu-core-dev/+git/systemd/commit/?id=6a8b3e99b74704b66a5f9422a828f58f532ac3af https://git.launchpad.net/~ubuntu-core-dev/+git/systemd/commit/?id=cc8f39042c5b47bc853b7450f3fe80467dd5897c https://git.launchpad.net/~ubuntu-core-dev/+git/systemd/commit/?id=fd832930ef280c9a4a9dda2440d5a46a6fdb6232
[14:01] <Odd_Bloke> sforshee: \o/
[14:02] <Odd_Bloke> sforshee: When might I expect to see that land?
[14:05] <sforshee> LocutusOfBorg: using the upstream vboxvideo still, as in bionic
[14:06] <sforshee> Odd_Bloke: can't say for sure, but we'll have to upload it very soon to be in the release
[14:07] <sforshee> LocutusOfBorg: I updated the drivers from 5.2.18-dfsg-2 in those patches
[14:11] <LocutusOfBorg> ack
[14:15] <Odd_Bloke> sforshee: Cool, thanks!
[14:56] <rbasak> xnox: the AutomountResult enum in src/core/automount.h doesn't form part of any ABI does it?
[14:56] <rbasak> (or API even)
[14:57] <rbasak> xnox: same question with {busname,mount,path,service,socket,swap,timer,unit} - it's all the same pattern.
[14:58] <xnox> rbasak, internally they are enums/states et.al. externally they are all encoded/decoded/shown as a single string.
[14:59] <rbasak> OK, thanks. As long as the numbers are internal :)
[14:59] <xnox> rbasak, as per their abi stability guides, they are free to remove/add/change those strings. but it is guaranteed to remain a string.
[14:59] <rbasak> Thanks. Handy for you to know the answer without me having to dig :)
[14:59] <xnox> the abi is like `is-failed` which knows which strings are "bad" and which ones are "good"
[14:59] <xnox> for every unit type.
[15:00] <xnox> it's meant to be informational
[15:09] <cyphermox> tsimonq2: thanks for looking at slideshow :)
[15:10] <tsimonq2> cyphermox: No problem. :)
[15:40] <dgadomski> mwhudson: hi, could you please also release the fix for bug #1749289 to xenial?
[15:40] <ubottu> bug 1749289 in ubiquity (Ubuntu Xenial) "Installer stops after pressing Cancel on Select a language screen during OEM install" [Undecided,Confirmed] https://launchpad.net/bugs/1749289
=== slangasek is now known as vorlon
=== vorlon is now known as slangasek
=== slangasek is now known as vorlon
[15:50] <ogra> vorlon, identity crisis ?
[15:50] <vorlon> stuck settings in the client that I'm trying to shake loose
[15:55] <rbasak> Would it be acceptable in Ubuntu for a package to dynamically add an extra binary package not listed in debian/control through debian/rules? The reason is that I want to keep in sync with Debian but build an extra split out binary package to stay in universe.
[15:55] <rbasak> (in Debian this wouldn't happen so I don't think there's an issue there)
[15:56] <tsimonq2> Why is it not possible to list it in debian/control?
[15:56] <rbasak> Because it wouldn't be appropriate to build the binary package on Debian.
[15:56] <sarnold> wouldn't taht just turn into a delta in debian/rules?
[15:56] <rbasak> Yes it would.
[15:57] <rbasak> But we do that already in other places, using dpkg-vendor
[15:57] <tsimonq2> Ohh, I catch your drift.
[15:57] <rbasak> Means that Debian and Ubuntu build from the same source, which is convenient. Saves doing merges etc.
[15:57] <tsimonq2> That personally sounds doable but I guess I'd defer to an archive admin. :)
[15:58] <sarnold> I dislike it, but not enough to be annoying about it. :)
[15:58] <tsimonq2> ^
[15:58] <rbasak> ISTR someone saying that Debian disallowed this. But it might be OK for Ubuntu. The only reason to do this is caused by Ubuntu's main/universe distinction.
[15:59] <rbasak> I think the alternatives is for sarnold to +1 our MIR from a security perspective, or to keep doing package merges forever.
[15:59] <sarnold> heh, which one? :)
[15:59] <rbasak> bug 1781529
[15:59] <ubottu> bug 1781529 in mecab (Ubuntu) "[MIR] mecab" [High,New] https://launchpad.net/bugs/1781529
[15:59] <tsimonq2> As someone once said, "Policy is your friend. Trust the Policy. Love the Policy. Obey the Policy." so I guess I'd be curious to say if Policy has a specific rule around it. :)
[15:59] <sarnold> aha, dunno if I can get there today or not. I didn't sleep well last night :/
[15:59] <rbasak> I'll finish writing my reply. My question was prompted in writing a reply :)
[15:59] <sarnold> haha :)
[16:00] <tsimonq2> rbasak: Oh, I just recalled that dbgsym packages aren't mentioned in d/control.
[16:01] <tsimonq2> So while they're "special" packages, it should mean that it's permissible under policy.
[16:01] <rbasak> Reply written in the bug.
[16:01] <rbasak> vorlon or infinity: ^ please could you tell me if this is acceptable? See bug 1781529 comment 7.
[16:01] <ubottu> bug 1781529 in mecab (Ubuntu) "[MIR] mecab" [High,New] https://launchpad.net/bugs/1781529
[16:02] <tsimonq2> infinity: ^ (since, if I recall correctly, he only gets pings if the message starts with his name.)
[16:03] <sarnold> rbasak: very nice reply, thanks :)
[16:06] <rbasak> sarnold: thanks. Over to you I guess? If you want to nack the MIR on security grounds, that's fine - we'll find some way, and if we can't, we'll either continue merging or continue without mecab support.
[16:40] <vorlon> rbasak: binary packages produced by a source package are expected to be listed in the debian/control shipped in the source package
[16:41] <rbasak> vorlon: "expected", or "must"? I'm aware of the expectedness; that's why I'm asking :)
[16:41] <vorlon> rbasak: must
[16:41] <rbasak> OK, thanks
[16:42] <vorlon> it's bad to have packages listed in debian/control that you never build, but that's less bad than building packages you don't list in debian/control; the latter breaks cross-references in the indices
[16:43] <rbasak> I could list it in debian/control and then never build it, but then I'd be foisting that on Debian, which seems inappropriate.
[16:48] <xnox> vorlon, nvidia-* packages currently shadow each other ;-)
[16:49] <vorlon> xnox: yes; which is permitted for the same reason it's permitted for gccs, you shouldn't have to reupload the old package in order for a new package to take over its binaries
=== dannf` is now known as dannf
[17:25] <vorlon> mdeslaur: why did woff2 have a no-change rebuild in bionic-security? should we copy it forward to cosmic? (cf juliank's post)
[17:27] <juliank> vorlon: he did upload 1.0.2-1build1 to cosmic a few hours or so ago
[17:27] <vorlon> ah, well then
[17:27] <vorlon> still wondering what the no-change rebuild was for :)
[17:28] <juliank> Yeah, it would have been useful to have "for ..." in the changelog
[17:30] <sarnold> iirc it was so that we could do a security update on webkit2gtk https://launchpad.net/ubuntu/+source/webkit2gtk/+changelog
[17:34] <jbicha> vorlon: we moved woff2 to main
[17:34] <vorlon> ah
[17:35] <vorlon> moving to main does not require a rebuild, only a pocket copy
[17:35] <jbicha> ok, good to know. We don't do it very often :)
[17:36] <mdeslaur> vorlon: if you only do a pocket copy, you break ubuntu-support-status
[17:36] <vorlon> oh?
[17:36] <vorlon> ok
[17:36] <mdeslaur> since the installed package on people's systems still comes from universe
[17:37] <jbicha> vorlon: if you have time, brotli binaries need to be moved to main in xenial too LP: #1795077
[17:37] <ubottu> Launchpad bug 1795077 in brotli (Ubuntu Xenial) "Backport brotli 1.0.3 to Ubuntu 16.04 LTS" [Medium,Fix committed] https://launchpad.net/bugs/1795077
[17:37] <jbicha> and woff2 (SRU wasn't accepted yet) LP: #1795094
[17:37] <ubottu> Launchpad bug 1795094 in woff2 (Ubuntu Xenial) "Backport woff2 to Ubuntu 16.04 LTS" [Medium,In progress] https://launchpad.net/bugs/1795094
[17:38] <sarnold> jbicha: do we really? I thought webkit2gtk added new toolchain dependencies that meant we can't support it in trusty any longer?
[17:38] <jbicha> sarnold: we never announced that webkit2gtk/xenial was unsupported so maybe…
[17:41] <jbicha> latest webkit requires gcc6 and no one's volunteered to backport that to xenial yet
[17:42] <jbicha> https://trac.webkit.org/wiki/WebKitGTK/GCCRequirement
[17:43] <mdeslaur> it's a bit more complicated than that...we can't just backport gcc6
[17:43] <mdeslaur> the stdlibc++ library on xenial is provided by gcc5
[17:44] <jbicha> I admit I don't know what that library means
[17:50] <rbasak> coreycb: would you prefer me to wait for neutron in bug 1795424 before reviewing? Or are you happy with releasing bits at a time?
[17:50] <ubottu> bug 1795424 in nova (Ubuntu Bionic) "[SRU] queens stable releases" [High,Fix committed] https://launchpad.net/bugs/1795424
[17:51] <rbasak> coreycb: or, given they all get tested together, maybe it's better to wait in the general case?
[17:52] <coreycb> rbasak: thanks for taking a look. i'd really like to include neutron as it has some critical bug fixes.
[17:53] <coreycb> rbasak: it's all regression tested, i think we can mark the remaining neutron bug as verification-done since it passed regression testing.
[17:53] <rbasak> coreycb: there's still two more days left to age for neutron
[17:55] <coreycb> rbasak: ah, right. well i think you can hold off and we can get those all released together fri or mon.
[17:55] <rbasak> OK, thanks.
[17:55] <coreycb> rbasak: thanks
[17:55] <rbasak> coreycb: it'll be Mon. We generally don't release on Fridays.
[17:55] <coreycb> rbasak: ok makes sense
[17:56] <rbasak> juliank: I appreciate the impact statement in bug 1796081 :)
[17:56] <ubottu> bug 1796081 in dpkg (Ubuntu Bionic) "dpkg frontend locking" [Undecided,In progress] https://launchpad.net/bugs/1796081
=== vorlon is now known as slangasek
=== slangasek is now known as vorlon
[18:03] <vorlon> jbicha: brotli overrides done
[18:04] <jbicha> thanks
[20:51] <mwhudson> dgadomski: oh i didn't realize it affected xenial too
[20:51] <mwhudson> dgadomski: is it in git for xenial yet?
[21:18] <xnox> libtool: compile:  mpicxx -DHAVE_CONFIG_H -I. -I../.. -Wdate-time -D_FORTIFY_SOURCE=2 -I/usr/include -I../.. -g -O2 -DNDEBUG -DZDOT_RETURN -c _hrr_c0_66.cc -o _hrr_c0_66.o
[21:18] <xnox> virtual memory exhausted: Cannot allocate memory
[21:18] <xnox> but builds fine in debian.... compiler bug? PIE or some such making it explode?
[21:19] <xnox> mwhudson, vorlon, doko - any suggestions on where to go from here?
[21:19] <mwhudson> !?
[21:19] <mwhudson> xnox: package, architecture, etc?
[21:19] <xnox> bagel, all arches
[21:19] <xnox> cosmic
[21:20] <xnox> did --no-parallel build in xnox/nonvirt ppa and also fails on all arches
[21:20] <mwhudson> huh
[21:20] <vorlon> yeah, virtual memory exhausted would seem to imply you're out of address space rather than out of physical memory
[21:21] <mwhudson> sounds compiler bug-like to me
[21:21] <vorlon> and the compiler in question is... mpicxx?
[21:21] <mwhudson> what is mpicxx? mpi as in the multi process thing?
[21:21] <mwhudson> yes, seems so
[21:21] <xnox> yeah, openmpi implementation c++ compiler....
[21:22] <mwhudson> xnox: tried locally?
[21:24] <mwhudson> it's a different version of libmpich-dev, 3.3~b2-6  vs 3.3~b2-7build1
[21:24] <xnox> mwhudson, well can't remember now. rerunning build in unstable chroot; then will rerun build in our chroot; then will see if libmpich-dev makes a difference.
[21:25] <mwhudson> changes between the versions are trival so it would only be if mpicxx built with gcc-8 is broken or some such fun
=== vorlon is now known as slangasek
=== slangasek is now known as vorlon