[03:22] <alkisg> vorlon, mwhudson, hi, do I need to do anything more wrt to the isc-dhcp merge request? https://code.launchpad.net/~alkisg/ubuntu/+source/isc-dhcp/+git/isc-dhcp/+merge/371861
[03:51] <mwhudson> alkisg: oops dropped the ball there sorry
[03:51] <mwhudson> alkisg: will have a look next week
[04:00] <hallyn> there's a guy with an old meizu 5 running ubuntu phone, wants to update it to ubports, but can't get it recognized by adb or fastboot on the computer, and install e.g. the terminal app because the ubuntu phone app store is gone.  What's the right channel for this?
[04:00] <hallyn> i can't get into #ubuntu-phone as it's invite-only :)
[04:39] <RAOF> hallyn: https://t.me/ubports might be sensible.
[04:40] <hallyn> that's where he is :)  but this question is really about the old ubuntu phone, not the new ubport.
[04:40] <hallyn> just looking for someone who knows about any usb unlocking that would need to be done, don't want to pollute this chan with it
[04:42] <RAOF> Ah, right.
[04:42]  * RAOF sees that conversation now.
[05:02] <alkisg> mwhudson: np, ty
[05:41] <Unit193> hallyn: #ubuntu-phone fowards to #ubuntu-touch, which you're already in, so it gives you an 'invite only' message.
[05:50] <hallyn> I see - thx
[06:50] <cpaelzer> ahasenack: it seems your fix for ruby2.3 is blocked in xenial blocks on a dep8 test, but from the test history it seems that glibc/2.23-0ubuntu11 has broken it but was released still
[06:50] <cpaelzer> ahasenack: do you want to debug that or ask for a force badtest, for whatever reason it seems s390x only ?!
[06:51] <cpaelzer> the related upload is https://launchpad.net/ubuntu/+source/ruby2.3/2.3.1-2~ubuntu16.04.13
[06:53] <squishedlunch> Hello, I'm new to Ubuntu and would like to start contributing, I've setup my Launchpad account and  read http://packaging.ubuntu.com, https://wiki.ubuntu.com/MOTU, and https://wiki.ubuntu.com/UbuntuDevelopment but not sure which tickets to pick up on https://wiki.ubuntu.com/One%20Hundred%20Papercuts/Fix/Lists%20of%20bugs, is it possible to get a mentor as a new contributor?
[10:49] <tinoco> morning o/
[10:55] <rbasak> vorlon`: sysbench isn't migrated and is needed for src:mysql-5.7 removal. I see you filed an armhf FTBFS in Debian; Debian then removed the architecture.
[10:56] <rbasak> vorlon`: how would you like to proceed in Ubuntu? If you remove the previous armhf build it will migrate I think, and remain in sync with Debian?
[10:57] <rbasak> It doesn't seem right to me that Debian "resolved" your bug by removing armhf architecture support entirely, but perhaps that needs resolving in Debian. Perhaps another bug "no armhf build" is appropriate.
[10:59] <rbasak> vorlon`: the remaining reverse dependencies all have alternatives available AFAICT. Please could you take a look at removal? I can file a bug if you wish.
[11:00] <cjwatson> Does anyone know what's up with the lintian regressions in http://autopkgtest.ubuntu.com/packages/l/lintian/eoan/amd64 (and other arches)?  I don't see how they can possibly have anything to do with man-db, but they're blocking man-db's migration
[11:01] <cjwatson> "Runner died for ../../autopkgtest_tmp/testsuite/tags/checks/debhelper/debhelper-no-depends: cd ../../autopkgtest_tmp/testsuite/tags/checks/debhelper/debhelper-no-depends; make --trace DEFAULT_DH_COMPAT=9 failed at t/bin/build-test-packages line 375." but no explanation of why
[11:05] <cjwatson> Ah, probably fixed in lintian 2.19.0 by commit f8fc4b5168073a53d0924c71883cbc0b099b6e94
[11:05] <cjwatson> So just need to MIR those two perl modules I suppose
[11:06] <cjwatson> Is anyone sorting that out?
[12:11] <rafaeldtinoco> ocfs2-tools (1.8.5-7build1) disco; urgency=medium
[12:12] <rafaeldtinoco> so, why to use build1 instead of ubuntu1 here
[12:12] <rafaeldtinoco> (it was a rebuild due to soname change in a dependency lib)
[12:12] <rafaeldtinoco> just curious how a SRU would look like regarding to versioning
[12:12] <rafaeldtinoco> in this case
[12:12] <rbasak> rafaeldtinoco: 'ubuntu' in the version string will block autosync
[12:12] <rafaeldtinoco> build1ubuntu1 ? or ubuntu1 only ?
[12:12] <rbasak> So we use build for no change rebuilds
[12:13] <rafaeldtinoco> haaa ok. makes sense tks
[12:13] <rbasak> No need to use it in an SRU
[12:13] <rbasak> Though you might for a no change rebuild to make it clear I suppose
[12:13] <rbasak> I can't think of it ever having come up
[12:13] <rbasak> It's not common at least
[12:14] <rafaeldtinoco> i see.. yep I was curious, first time I see an ubuntu only change with build only in the version
[12:14] <ahasenack> cpaelzer: I can take a look at ruby's sru
[12:43] <ahasenack> rbasak: did you know you are a maas maintainer? :)
[12:43] <ahasenack> rbasak: https://launchpad.net/~maas-maintainers/+members
[12:44] <rbasak> I am :)
[12:45] <rbasak> However I don't think that team is used any more anyway?
[12:46] <ahasenack> well
[12:46] <ahasenack> rbasak: I just came across https://bugs.launchpad.net/ubuntu/+source/django-piston3/+bug/1842043
[12:46] <ahasenack> which will get a git-ubuntu MP shortly
[12:46] <ahasenack> and was wondering who could review it and sponsor
[12:46] <ahasenack> ack will change that debdiff to a g-u branch
[13:09] <ddstreet> Laney in order to test the change from https://code.launchpad.net/~ddstreet/autopkgtest-cloud/+git/autopkgtest-cloud/+merge/371909 can you add a github secret key for me, so i can push tests from my github repo?  I would keep it turned off all the time, except occasionally to verify changes like this, without upstream systemd having to make changes before we can test them
[13:29] <paride> smoser, I dumped what I know about the ZFS bug here: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1779156
[13:30] <paride> I'm hitting that one a lot too :/
[13:41] <rafaeldtinoco> paride: can u trace unshare() in the system until it happens ?
[13:42] <rafaeldtinoco> to get who did it and why ?
[13:46] <paride> rafaeldtinoco, I think that would apply to the "busy namespace mount" case, which I'm not really seeing a lot at the moment
[13:48] <paride> rafaeldtinoco, I think that doesn't apply to point (3) of my comment, which is what I see happening most of the time at the moment
[13:48] <paride> (just added another comment to make it clearer)
[13:55]  * rafaeldtinoco checks point 3
[13:56] <smoser> paride: thanks for that.
[13:56] <smoser> one bit of 'qualitative' info that i have that may be similar to you.
[13:56] <smoser> I almost *always* use --force and delete running containers
[13:56] <smoser> almost never bother to stop containers.  start, do something, destroy.
[13:57] <rbasak> Me too
[14:01] <rafaeldtinoco> paride: having a zfs holds whenever this happens would be great
[14:02] <rafaeldtinoco> (making lxd to output what is holding the dataset)
[14:02] <paride> smoser, yeah stopping and deleting in separate steps almost always works, but most of the time I `delete --force`
[14:02] <rafaeldtinoco> it could either be something upperlevel (like a snapshot being deleted in bg holding the attempt of removal)
[14:04] <paride> rafaeldtinoco, I think stgraber's point is that the kernel shouldn't report it's "done" with deleting stuff (e.g. snapshots) when it's actually not
[14:05] <rafaeldtinoco> paride: well most of those functions in kernel are async and if you want it to be sync you have to explicitly have a flag for it
[14:05] <rafaeldtinoco> (i mean for mounting/umounting)
[14:06] <rafaeldtinoco> anyway, tks for explaining it
[14:06]  * rafaeldtinoco will check zfs snapshot deletion code
[14:07] <paride> I guess it's what LXD is doing. I didn't look at the LXD code any deeper than looking up what "delete --force" does, which is: the same as "stop" and "delete"
[14:08] <paride> rafaeldtinoco, looks like `zfs holds` is only for snapshots, while we want to delete a dataset. And I think this is racey, give that `lxd stop ; lxc delete` works
[14:08] <rafaeldtinoco> gotcha
[14:09] <paride> but `delete --force` does not, and `delete --force` is just the same, but done faster (IIRC)
[14:09] <rafaeldtinoco> gotcha
[14:12] <smoser> paride: you're saying that delete --force is just 'stop, then delete' ?
[14:12] <smoser> i kind of suspected it was, from other experience. but same as you i never looked.
[14:14] <paride> smoser, I did look that one and I'm pretty sure it's just a "stop and then delete"
[14:16] <rafaeldtinoco> i was thinking it was something more like.. a held reference for the filesystem while last sync() is called
[14:16] <rafaeldtinoco> (got this for XFS in the past, thats why)
[14:33] <paride> https://github.com/lxc/lxd/blob/master/lxc/delete.go#L102
[14:34] <paride> here it is: if not (not stopped) and (force) => stop
[14:34] <paride> and then proceed with the deletion
[14:35] <smoser> well, i wonder if a sleep(1) after line 125 would fix it
[14:35] <smoser> "fix"
[15:16] <ahasenack> rbasak: bryce: if one of you have a spare cycle, this should be a simple review, it's one of the 3 remaining packages blocking the migration of lxml
[15:16] <ahasenack> https://code.launchpad.net/~ahasenack/ubuntu/+source/soupsieve/+git/soupsieve/+merge/372071
[15:20] <bryce> ahasenack, I can add this review to my list for today
[15:20] <ahasenack> thanks!
[15:40] <rbasak> bryce, I can grab it now - I'm in between things
[15:40] <rbasak> And make your list shorter
[15:43] <rbasak> Done
[15:46] <bryce> rbasak, ah thanks
[15:53] <rbasak> vorlon: I filed bug 1842097 for you
[16:06] <squishedlunch> Hello, just wanted to ping the channel again to see if there were any mentorship opportunities new contributors could take advantage of? I looked through a couple tickets in Papercut and they lack context for a new person unfortunately
[16:06] <bryce> squishedlunch, what are your interests?
[16:09] <smoser> paride: following your reading pointers brought me http://mywiki.wooledge.org/BashFAQ/105 which has lots of nice examples of why i dont like set -e .
[16:10] <squishedlunch> bryce: packaging, I haven’t seen any groups or teams like cloud or python on the Ubuntu wiki, are there specific areas I can focus on other than packaging and bug fixes in packages?
[16:10] <bryce> smoser, ah interesting.  I also prefer avoiding set -e, now I have a link to point at for why :-)
[16:11] <bryce> squishedlunch, there's a ton going on with cloud and python, I suspect the ubuntu wiki is a bit out of date from that perspective
[16:11] <smoser> bryce: https://hackmd.io/IoVN08RrQV6Hyb6ztY4kwg
[16:11] <smoser> i wrote that a while ago after losing a day or so chasing some of the 'set -e' madness.
[16:11] <bryce> smoser, hah nice
[16:12] <smoser> that is mostly a true story
[16:12] <bryce> will have to read that one too :-)
[16:13] <squishedlunch> bryce: any advice on getting involved with the cloud and python stuff? It’s a bit difficult to just pick up an issue from my perspective
[16:14] <bryce> squishedlunch, packaging, bug fixing in packages, and writing dep8 tests for packages is pretty descriptive of our day to day work on the server team, so if those areas are of interest I can definitely give pointers there
[16:15] <bryce> if you're interested more in python development/coding work on cloud packages, there are several teams working on things
[16:16] <bryce> squishedlunch, my advice would be to do some research into what those Canonical projects are, and what tickles your fancy the most, and then start submitting pull requests / MP's / bug reports; learn what discussion channels those teams use, and frequent them; and identify who are actively working on that project, and ask what's on their todo lists
[16:18] <bryce> squishedlunch, https://canonical.com/projects/ has a good list of what projects are currently under development
[16:19] <bryce> "cloud" is a pretty broad category so you may want to think about what aspects are most interesting for you
[16:21] <bryce> squishedlunch, also fwiw afaik there aren't going to be "formal" mentorship programs ala gsoc, but I believe most of the projects are welcoming to contributors and will give guidance on contributing
[16:21] <squishedlunch>  bryce what the server team is working on sounds great and is more of what I want to learn about and get involved with, is there an up to date wiki page? Or how do you suggest I get started?
[16:25] <bryce> squishedlunch, the server team wiki has a GettingInvolved page here - https://wiki.ubuntu.com/ServerTeam/GettingInvolved
[16:26] <bryce> the page looks kind of dated to me, but would help you narrow down what you're interested in and we can give more up to date advice for what you want to work on once you've decided
[16:27] <bryce> One task area that requires python coding that the server team needs, is writing Dep8 tests.  I don't think that task is listed on that page, but if that sounds interesting I can give more advice there.
[16:28] <bryce> a lot of our cloud packages need Dep8 tests written.  These are generally pretty short scripts, usually in python or bash, that are run as part of the package build to do some package level checks (e.g. does the service initialize and run without error, etc.)
[16:30] <squishedlunch> bryce: okay I will take a look at the wiki and get back to you, what time zone are you in? I’m in PST
[16:30] <bryce> I'm in PST too :-)
[16:30] <bryce> I'm based in Portland
[16:49] <bryce> smoser, wow that set -e issue with compounds in your blog post is esoteric, good to know.  Btw spotted a typo - disabled the error error handling.  An error in your error handling.  ;-)
[17:14] <vorlon> rbasak: why are the mysql-client, mysql-server packages still built from mysql-5.7 source instead of mysql-8.0?
[17:15] <vorlon> rbasak: oh - n/m, somehow there are two versions of mysql-client reported in rmadison
[17:53] <vorlon> cjwatson: ^^ I wonder if there being two different versions of mysql-client and mysql-server in eoan release pocket, one in universe and one in main, might be related to your recent changes
[18:30] <cjwatson> vorlon: That does seem peculiar.  Could you file a bug please?
[18:32] <cjwatson> (It might or might not be - the case of two source packages building the same binary is a bit unusual
[18:32] <cjwatson> )
[18:38] <vorlon> cjwatson: LP: #1842121
[18:38] <cjwatson> vorlon: One reason I'm not totally convinced about it being due to my change is that the copy of 5.7.27-0ubuntu2 into the release pocket appears to have been after the most recent publication of 8.0.16-0ubuntu3, and then both versions would be considered "live" because there are other non-arch-all binaries from the same source that are still live
[18:38] <cjwatson> That would I think have been the case before my changes too
[18:39] <cjwatson> But it'll probably be necessary to set up a matching situation in the test suite in order to tell either way
[18:40] <cjwatson> Anyway it's clearly less bad to have two versions present than none :-)
[18:42] <vorlon> cjwatson: except I believe the "copy" to the release pocket was actually a change I made in response to component-mismatches
[18:43] <vorlon> cjwatson: see https://irclogs.ubuntu.com/2019/08/29/%23ubuntu-devel.html#t21:11
[18:44] <vorlon> the proposed->release copy was 6 days earlier
[18:45] <cjwatson> vorlon: In which case the hypothesis that 5.7.27-0ubuntu2 would have been superseded before I landed my changes can't be supported
[18:45] <cjwatson> vorlon: Because 6 days earlier than that was well before I landed my changes
[18:46] <cjwatson> Indeed I see "Package has 2 live publication(s)" output from the dominator relating to mysql-client from before my most recent deployment
[18:46] <vorlon> oh weird
[18:46] <vorlon> ok
[18:46] <cjwatson> Pretty sure this is a long-standing property of the dominator
[18:46] <cjwatson> See also e.g. libnvidia-common-418
[18:46] <vorlon> yeah, I see now that mysql-8.0 migrated even earlier (22Aug)
[18:47] <cjwatson> Or rdkit-data
[18:47] <vorlon> huh
[18:51] <cjwatson> Though rdkit-data is a bit different - that case is because python-rdkit from the old source package is still hanging around and is NBS
[18:51] <cjwatson> (and not removable because of rdeps)
[18:52] <cjwatson> In general the dominator takes a conservative approach in such cases - I think it assumes that arch-all binaries from a source which has live non-arch-all binaries still hanging around might well be needed to satisfy dependencies or similar, and so keeps them around until there are no live non-arch-all binaries any more
[18:53] <vorlon> ah, that makes sense
[18:53] <vorlon> doesn't make it easier on trying to figure out if it's safe to remove.. but it makes sense :)
[18:54] <cjwatson> I think I would advise not manually removing arch-all binaries in such cases.  In all possible situations there's a better solution available
[18:54] <cjwatson> If multiple source packages that share binaries need to remain live, then all but one of them should stop building the overlapping binary/binaries
[18:55] <cjwatson> While in the NBS-arch-dep-sibling case, the remedy is to chase up NBS
[18:55] <vorlon> cjwatson: sure.  in this case, it just made it cumbersome to figure out based on reverse-depends output whether or not the mysql-5.7 source package was safely removable
[18:56] <vorlon> reverse-depends already has the flaw that it doesn't filter out reverse-dependencies of a binary listed in debian/control that is no longer provided by this source package in the archive
[18:57] <vorlon> having cases where the binary package is actually still provided by the source package in the archive /but not the current version of the binary/ just makes it weirder :)
[18:57] <cjwatson> Perhaps we should have a report for overlapping binaries?
[18:58] <cjwatson> (Also, I've just had the horrible realisation that it's beginning to sound like I actually understand the dominator)
[18:58] <vorlon> if it were strictly a report of overlapping binaries that are currently published, that could be useful
[18:59] <vorlon> I don't want a list of all the source packages that will fail to upload because they try to build binaries that are older than the version from a different source that has taken it over; that list would be noise
[19:00] <cjwatson> Those should be identical if people haven't gone removing binaries by hand without correcting the source packages :P
[19:00] <vorlon> cjwatson: I thought the dominator behavior you described was limited to arch: all though?
[19:00] <vorlon> which would explain why e.g. process-removals of a package that Debian has removed as "obsolete source" doesn't show us removing any binaries
[19:01] <cjwatson> I think it is
[19:05] <cjwatson> FWIW the dominator's current log whinges for eoan{,-proposed} are https://paste.ubuntu.com/p/XrSXtPxK4v/ .  You can probably ignore any cases where the number of items under "Live versions:" is less than the number of live publications reported, as that's likely about to be corrected by domination
[19:05] <cjwatson> So not really a great basis for a report, but gives you a general idea
[22:00] <Unit193> If one were to sync squashfs-tools, eoan wouldn't ship with a git snapshot.