[00:54] <nacc> rbasak: i pusehd an updated to the tooling, `usd-merge` now exists as a 3-operation tool (tag, reconstruct, commit). Updated https://wiki.ubuntu.com/UbuntuDevelopment/Merging/GitWorkflow heavily
[00:55] <nacc> Still working on it, now will cross-ref with the other wiki page
[01:02] <nacc> barry: --^ you may want to refer to that, i'm working on putting everything i know on there
[01:02] <nacc> cpaelzer: are you ok if i use your graph as an example on the public wiki?
[01:17] <barry> nacc: cool, thanks.  i'm planning on digging intot hat tomorrow
[01:47] <nacc> barry: sure, i'm all ears on feedback, that wiki page is definitely WIP, i'll have more details in our merging process tmrw (but the references to the importer are pretty complete as much as i ahve them :)
[05:52] <cpaelzer> good morning
[07:20] <pitti> Good morning
[09:14] <pitti> nacc: new php-defaults has been stuck in proposed because it makes php-imagick uninstallable apparently; is that on your radar by any chance? (http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#php-defaults)
[09:36] <FourDollars> Hi, does anyone know how to see the debug messages of indicator-bluetooth in Unity desktop environment?
[09:37] <pitti> FourDollars: try .cache/upstart/indicator-bluetooth.log ?
[09:39] <FourDollars> pitti: There is no such file.
[09:39] <pitti> FourDollars: (that's relative to the home dir)
[09:39] <pitti> FourDollars: do you have other indicator-*.log files there?
[09:39] <FourDollars> pitti: Yes, I know.
[09:40] <FourDollars> pitti: Yes, there are other gzip files.
[09:40] <pitti> ah, so maybe check their timestamps, they might just have gotten rotated?
[09:41] <FourDollars> There is no debug messages in those gzip files.
[09:44] <pitti> FourDollars: ah, you probably need to restart the indicator process with G_MESSAGES_DEBUG=all
[09:44] <pitti> and while you are at it, stop the upstart process and start it in a shell
[09:45] <FourDollars> pitti++
[09:45] <FourDollars> G_MESSAGES_DEBUG=all works!
[09:45] <FourDollars> pitti: Thx a lot.
[09:45] <pitti> works? nice
[09:45] <FourDollars> I mean I can see the debug messages now. :D
[09:46] <FourDollars> G_MESSAGES_DEBUG=all is what I need.
[11:21] <jamespage> ok so I've forgotten how todo this:
[11:22] <jamespage> I need to update /etc/default/ceph/ceph -> /etc/default/ceph for upgraders (note the double ceph in the current version)
[11:22] <rbasak> pitti: regarding https://anonscm.debian.org/git/autopkgtest/autopkgtest.git/commit/?id=0122291bfd445ad4afcdb4d59342e4bd009d526b, it is really useful to be able to hack a backend and have adt-run use it instead of the installed one. Will that still be possible if you're assuming path and prefix?
[11:22] <jamespage> is that a mv_conffile /etc/default/ceph/ceph /etc/default/ceph ?
[11:23] <rbasak> jamespage: yes but there might be an issue for directory -> file.
[11:23] <rbasak> Since the maintscript helper expects to be able to leave files around in the same directory as the old conffile location.
[11:23] <jamespage> yeah that's what I thought
[11:23]  * jamespage scratches his head...
[11:24] <rbasak> You might need to manually do what dpkg-maintscript-helper does but manually and tweak for the directory situation.
[11:25] <rbasak> jamespage: another hack is to manually mess with the files it leaves behind in between steps
[11:28] <jamespage> urgh
[11:30] <rbasak> How about: on preinst, run dpkg-maintscript-helper as normal (manually, without debhelper), but then straight after rename /etc/default/ceph to /etc/default/ceph.renamed
[11:30] <rbasak> Then in postinst, call dpkg-maintscript-helper but pretend you're renaming /etc/default/ceph.renamed/ceph to /etc/default/ceph.
[11:31] <rbasak> Not sure about postrm abort-upgrade/abort-install handling. Ideally rename things back and then call dpkg-maintscript-helper with the old case again.
[12:57] <pitti> rbasak: yes, it is; you just have to specify it with a path, i. e. it needs to have a '/' in it
[12:57] <rbasak> pitti: ah good, thanks.
[13:01] <pitti> rbasak: I'm waiting until tomorrow when 3.20.9 goes into testing, then upload 4.0, and when it's available in y and backports I'll write a blog post about the changes, as they are quite large
[13:01] <pitti> (all backwards compatible, though)
[13:02] <rbasak> Sounds good. I'd appreciate xenial-backports if that's the plan.
[13:02] <pitti> rbasak: yes, I regularly backport new releases to t, w, and x
[13:02] <pitti> check rmadison
[13:02] <rbasak> Otherwise I was going to suggest SRUing the adt-buildvm-ubuntu-cloud yakkety URL change and the Python hashing workaround.
[13:03] <rbasak> I was completely unaware of this! Will follow backports from now on. Thank you!
[13:34] <pitti> xnox, infinity, tinoco: 10.100.0.13 has been AWOL since the weekend again, could you please prod it back into existence? thanks!
[13:35] <tinoco> pitti: is this DEVACxx ?
[13:35] <pitti> tinoco: I don't know what that means, but it's the aupkg02 s390x instance
[13:36] <tinoco> ah ok
[13:36] <tinoco> let me check
[13:36] <pitti> tinoco: not sure why aupkg01 is fairly stable and 02 falls over every third day now, do they differ in something significant?
[13:36] <tinoco> pitti: checking that right now
[13:38] <tinoco> pitti: machine looks frozen
[13:38] <tinoco> have u seen anything in kern.log/dmesg ?
[13:38] <tinoco> ops
[13:38] <tinoco> got it
[13:38] <pitti> tinoco: I don't have any serial console or anything, just ssh
[13:38] <tinoco> [430664.069248] INFO: rcu_sched detected stalls on CPUs/tasks:
[13:38] <tinoco> [430664.069253]         (detected by 6, t=41022434 jiffies, g=7602, c=7601, q=66
[13:38] <tinoco> 60)
[13:38] <tinoco> [430664.069265] All QSes seen, last rcu_sched kthread activity 41022434 (4338003
[13:38] <tinoco> 568-4296981134), jiffies_till_next_fqs=1, root ->qsmask 0x0
[13:38] <tinoco> [430664.069290] rcu_sched kthread starved for 41022434 jiffies! g7602 c7601 f0x2
[13:38] <tinoco>  s3 ->state=0x0
[13:38] <tinoco> rcu detected a stall
[13:38] <pitti> tinoco: I think that's what xnox saw the last time too
[13:38] <tinoco> pitti: i could start this guest in another lpar
[13:38] <tinoco> but.. do you mind if we get a dump ?
[13:39] <pitti> tinoco: no, I don't urgently need the machine, we don't have a long queue ATM
[13:39] <pitti> tinoco: so if you want to take this down for some investigation, that's fine
[13:39] <tinoco> pitti: i wanted for you to enable kdump (-c 11,31)
[13:39] <tinoco> and get me a dump on lockups
[13:39] <tinoco> is that ok ?
[13:40] <pitti> tinoco: sure, how does one do that?
[13:40] <tinoco> (i dont have access to the machine and clearly some workload being generated is causing this)
[13:40] <tinoco> pitti: i'll ask xnox to enable kdump on this machine
[13:40] <pitti> tinoco: ack, thanks
[13:41] <tinoco> pitti: tku
[13:41] <tinoco> pitti: for now i'll reboot it
[13:41] <pitti> tinoco: btw, I also have notes how to set up the partitioning, and a script to set up a fresh instance for autopkgtesting, so nothing on this thing is precious in any way
[13:43] <tinoco> pitti: do you know what specific test caused this ? (as a reproducer ?)
[13:43] <pitti> tinoco: no, I don't; I can check the journal what ran last, but it happens pretty often as I said
[13:44] <tinoco> pitti: gotcha, yep.. let me check this.. i might ask you to start the test with kdump enabled for us to get a dump
[13:44] <tinoco> pitti: im leaving for ~1h now.. ill get back to you on this
[13:44] <pitti> tinoco: we can just let it run normally, something will trigger it very soon again, I'm sure :)
[13:44] <pitti> tinoco: ok, thanks; no ssh yet, but as I said not urgent
[13:44] <tinoco> im rebooting it
[13:44] <tinoco> for now
[13:45] <tinoco> pitti: i IPLed dasd 0200 again
[13:45] <tinoco> i hope your OS was in there
[13:45] <xnox> tinoco, pitti - sure enable kdump
[13:45] <pitti> oh, it now says "No route to host", sounds like rebooting
[13:45] <pitti> I'm in
[13:45] <pitti> xnox: apt-get install kdump, and then?
[13:46] <xnox> pitti, check that "crashkernel=196M" is in /etc/zipl.conf it should be
[13:46] <xnox> and well reboot.
[13:46] <tinoco> caribou: ^^ s390 kdump enablement for pitti, could u help ?
[13:46] <tinoco> caribou: i have to leave for about 1h .. bbs
[13:47] <pitti> "Should kexec-tools handle reboots?" -> I suppose "no" for now
[13:47] <xnox> pitti, yes
[13:47] <pitti> "Should kdump-tools be enabled by default?", I suppose "yes"
[13:47] <xnox> otherwise you will not get kdump....
[13:48] <pitti> xnox: installed; now I edit zipl.conf to add this to parameters=?
[13:49] <pitti> done, how to enable this now?
[13:49] <pitti> or is the boot process reading zipl.conf directly?
[13:49] <xnox> $ sudo zipl
[13:50] <cpaelzer> nice, launchpad auto recognizes that a git branch got merged as well
[13:50] <cpaelzer> just curious is that based on a "Merge branch..." statement in a merge commit that is processed on a git push?
[13:50] <cpaelzer> or asked otherwise - what has to be in the right form so that this works (it did for me aparrently)
[13:51] <cpaelzer> rbasak: you remember we discussed that last week - approve does nothing as we expected and the merge got instantly autodetected
[13:51] <cpaelzer> so just the way one wants it :-)
[13:53] <pitti> tinoco, xnox: last test was apparently php-horde-imp, that doesn't sound particularly scary
[13:53] <rbasak> cpaelzer: nice!
[13:53] <rbasak> nacc: I just did a manual "reconstruct" for MySQL, and noticed that we might need special behaviour for new upstream versions imported into Ubuntu.
[13:53] <rbasak> I'm not sure though.,
[13:55] <pitti> xnox: rebooting, crossing fingers :)
[13:57] <pitti> xnox, tinoco: it came back, and crashkernel=196M is in /proc/cmdline; so now let's wait unti it crashes again?
[13:58] <xnox> pitti, ... yeah, and then a dump should be somewhere in /var/ after it next crashes and we reboot it.
[13:58] <xnox> pitti, possibly next time it crashes we need to be on the cmdline to check that.....
[13:58] <xnox> i guess we should have some monitoring for it.
[13:59] <xnox> i wonder if i should just bring up openstack on two lpars for you, and just give you an openstack instead.
[13:59] <xnox> however, that is slightly harder to maintain =/
[14:00] <pitti> xnox: what's the status of getting z into bos02?
[14:00] <pitti> that seems like a more maintainable way foward?
[14:12] <sil2100> pitti: hey! So I seem to be experiencing the LP: #1453738 cryptswap bug as well right now after installing 16.04 cleanly on my new/old machine here
[14:12] <sil2100> pitti: should I attach my details to the same bug or fill in a separate one as you recommended?
[14:13] <sil2100> (since I see people are just using the same bug still for it)
[14:23] <pitti> sil2100: if you are sure it's the same bug, you can attach it there, of course
[14:23] <pitti> I tried to repro it with LVM, no luck so far
[14:23] <pitti> die, swap partitions, die!
[14:23] <pitti> :/
[14:24] <rbasak> pitti: in bug 1588915, the reporter responded that using network-online.target doesn't work either. Please could you take a look?
[14:24] <rbasak> It seems a bit odd. I don't see why the NIC would drop the link.
[14:24] <sil2100> pitti: not sure if that's the same, I didn't do anything special besides just using default installation settings + encrypted home directory
[14:25] <sil2100> pitti: now on each boot I get that stupid prompt, same when installing certain packages
[14:25] <sil2100> pitti: it annoys me greately ;)
[14:25] <pitti> rbasak: yeah, that's weird indeed; can't do much if the link goes down again, I'm afraid
[14:25] <pitti> sil2100: I guess just manually fix up/remove the broken swap partition for now?
[14:28]  * pitti bbl
[14:39] <caribou> xnox: pitti: crashkernel=196M is only needed until the new kdump-tools lands in yakkety
[14:58] <nacc> pitti: it is now, will investigate
[15:00] <shadeslayer> Is it possible to separate the accounts-plugins from the unity packages?
[15:01] <nacc> rbasak: ack, i will look at that today
[15:01] <shadeslayer> at the moment it depends on the gnome-control-center-signon source which depends on further unity packages ( unity-control-center, unity-settings-daemon, etc )
[15:01] <shadeslayer> surely I don't need all of that to use the accounts-plugins?
[15:03] <nacc> cpaelzer: asked last evening my time, but might have been missed -- are you ok if i re-use your ASCII graph from the wiki for the public documentation?
[15:05] <nacc> shadeslayer: what's the package name? 'accounts-plugins' turns up no hits
[15:05] <shadeslayer> https://bazaar.launchpad.net/~online-accounts/account-plugins/trunk/files
[15:05] <nacc> account-plugins
[15:06] <shadeslayer> right :)
[15:06] <cpaelzer> nacc: yes I missed, but you are totally fine to use it
[15:07] <shadeslayer> nacc: it needs libaccount-plugin-1.0-dev which comes from gnome-control-center-signon
[15:08] <shadeslayer> though it seems I can build without libaccount-plugin support
[15:08] <nacc> shadeslayer: but that's a source package, what binary package are you referring to of the ones it builds?
[15:08] <nacc> shadeslayer: or do you mean for building, specifically?
[15:08] <nacc> cpaelzer: np, thanks!
[15:08] <shadeslayer> nacc: I mean for building specifically, it doesn't make sense to me that a package like account-plugins needs unity bits to work
[15:09] <shadeslayer> for eg. KTP uses these plugins, but in order to build them I need to also build unity stuffs now :(
[15:09] <shadeslayer> though I'll probably try to build it without libaccount-plugin support to see what happens
[15:10] <shadeslayer> KTP ( KDE Telepathy )
[15:12] <nacc> ah interesting
[15:13] <nacc> i'm guessing that the build is specified with those deps so that it builds as-is (one or another binary target presumably fails)
[15:13] <nacc> unless you do the configuration step you suggest, which would be a change
[15:13] <nacc> i'm not sure, though
[15:14] <nacc> rbasak: did you import mysql? want me to?
[15:14] <rbasak> nacc: no thanks. I'd like to leave MySQL separate for now, because I also push commits to Debian.
[15:15] <nacc> rbasak: ah ok, let me import locally and reproduce then
[15:15] <shadeslayer> nacc: yeah, i'll probably have to fork the package because I'd rather not rebuild so much stuff :/
[15:15] <shadeslayer> I'll see tomorrow
[15:15] <nacc> shadeslayer: there are notions of build profiles, but i'm not sure it would apply here
[15:15] <shadeslayer> I doubt it
[15:15] <rbasak> nacc: I didn't actually try to use "usd-merge reconstruct" at all BTW. I just did it manually and thought that it might cause it to break. Something to think about, but it wasn't intended to be a bug report and I don't expect you to spend time fixing it right now :)
[15:16] <shadeslayer> ( the entire problem being that I need that package on Debian and Debian does not have any of the unity bits )
[15:18] <nacc> rbasak: ack
[15:20] <nacc> rbasak: to be sure, mysql-5.7 is the src pkg?
[15:21] <rbasak> nacc: yes
[15:21] <rbasak> nacc: I pushed my tree to ~racb if you're interested. This contains the merge I just did manually in ubuntu/wip
[15:21] <nacc> rbasak: thanks, will compare against it
[15:41] <dannf> slangasek: i've pushed some changes to the installation guide that i'd like to SRU back into xenial, so i'd like to do a yakkety upload w/ those first. all the other queued changes are yours - are you good w/ that? and did you have other things you wanted backported to xenial?
[15:42] <slangasek> dannf: hmm I was unaware I had anything queued
[15:42] <dannf> oh - maybe bzr was just out of date - let me check
[15:44] <dannf> slangasek: looks in sync (at least by version) - various changes about dropping "desktop" OS text
[15:45] <slangasek> ah
[15:45] <slangasek> I didn't upload those? ok :)
[15:45] <dannf> slangasek: ok - will push. did you want those SRU'd? if you do, would you mind filing a bug for 'em?
[15:46] <slangasek> dannf: fwiw I think all of those changes are appropriate for SRU; and I think the right way to SRU the installation-guide, being documentation, is a single metabug
[15:46] <dannf> slangasek: ok - cool, that'll make my life easier :) i'll handle that
[15:46] <slangasek> (SRU Test Case: do these words match the words we said they would match? okie-day)
[15:48] <slangasek> infinity, kees, mdeslaur, stgraber: TB meeting in 12
[15:49] <mdeslaur> ack
[15:59] <bdrung_work> pitti, you opinion on https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1233466/comments/26 ?
[16:22] <nacc> rbasak: ah i see what you mean -- also for that package, mysql-5.7 doesn't exist in debian, so our merge process doesn't work anyways (afaict)?
[16:41] <jackdpeterson> Is this the appropriate channel to discuss livecd packaging issues?
[16:41] <jackdpeterson> or, I suppose it would be an issue with the current release(s) of xenial64 and vagrant.
[16:43] <rbasak> nacc: yeah I've been merging from Debian VCS (to which I've been pushing), which ends up being a bit hacky wrt. debian/changelog etc. I will upload to Debian experimental soon but am still working on it.
[16:43] <rbasak> nacc: so I merge from there, which is a little confusing.
[16:44] <rbasak> jackdpeterson: if you're wearing a developer hat then yes, I think this is probably the most appropriate place, unless there's some other channel I don't know about.
[16:45] <jackdpeterson> Well, I'd be happy to attempt a pull request against whatever repository currently exists for performing the packaging for vagrant instances. https://bugs.launchpad.net/ubuntu/+source/livecd-rootfs/+bug/1589721
[16:46] <nacc> rbasak: right, and launchpad doesn't see any publishing hsitory
[16:46] <nacc> rbasak: in theory, one could add a new remote pointing to debian vcs after the import is done
[16:46] <rbasak> jackdpeterson: I'm not sure about the Vagrant side but Odd_Bloke may know.
[16:46] <nacc> rbasak: and it might be able to work then
[16:47] <rbasak> nacc: we do occasionally pull from some VCS somewhere over something in the Debian archive. It is pretty rare though. In this case I'm doing it because I wear both hats, but uploading to Debian is still painful for me (because we're not quite in sync yet but working on it)
[16:47] <nacc> rbasak: won't spend more time on it now, but it's definitely not a use-case we had considered generally
[16:47] <rbasak> nacc: I think it's safe to ignore for now.
[16:48] <Odd_Bloke> jackdpeterson: Can you give basic reproduction instructions for the bug?
[16:48] <nacc> rbasak: and i think most of the tooling is happy to try and use 'commitish' regardless of source
[16:48] <jackdpeterson> Sure thing :-) i'll attach as a comment.
[16:48] <Odd_Bloke> jackdpeterson: (I've marked the one you filed as a duplicate of the one you reference, so put it in there :)
[16:48] <jackdpeterson> Okay, will do.
[16:48] <Odd_Bloke> jackdpeterson: Uh, where "there" == "the older bug". :p
[16:48] <rbasak> nacc: but more generally, there is much more common use case we might need to consider - what happens when Ubuntu pulls in new upstream versions ahead of Ubuntu. Does our merge process work correctly in that case with the new data structure?
[16:49] <jackdpeterson> Yeah, made sense. I just wanted to file one under the right project so it could get appropriate visibility. But i'll add the comments to the older bug report.
[16:50] <nacc> rbasak: i think i can test that with openipmi, will look
[16:51] <jackdpeterson> Odd_Bloke: added comment -- https://bugs.launchpad.net/cloud-images/+bug/1569237/comments/8
[16:52] <Odd_Bloke> jackdpeterson: How long does that error show for?
[16:53] <Odd_Bloke> jackdpeterson: (Because I would expect to see that until the machine is booted and SSH is up)
[16:54] <Odd_Bloke> jackdpeterson: (Also, lets move this to #ubuntu-server; we're more likely to be in front of other Vagrant users there :)
[16:55] <jackdpeterson> One moment, I'm running the same process but on the ubuntu/trusty64 one for compare/contrast. Effectively, performing vagrant ssh -- even after the vagrant up completes requests authenticaiton.
[16:56] <jackdpeterson> compared to trusty64, which simply accepts a ssh username of vagrant and works with the private key autogenerated by vagrant.
[16:56] <jackdpeterson> The ubuntu/xenial64 box, on the other hand fails to authenticate using the vagrant username and the autogenerated private key. This prevents next steps of provisioning using whatever provisioners are used (e.g., puppet or otherwise).
[16:58] <Odd_Bloke> jackdpeterson: So I'm downloading the latest box to test; let's take this over to the #ubuntu-server channel though.
[16:59] <jackdpeterson> Cheers, and switched channels.
[19:33] <GunnarHj> bdmurray: Hi Brian, I got a couple of "increase in crash rate" mails due to the latest language-selector update in xenial:
[19:33] <GunnarHj> https://errors.ubuntu.com/?release=Ubuntu%2016.04&package=language-selector&period=day&version=0.165.3
[19:33] <GunnarHj> However, I don't seem to have access to see the nature of the issue. (Doubt it's really related to the latest change.)
[19:38] <bdmurray> GunnarHj: I agreed its not related to the change. To be able to see crashes at the Error Tracker one must be a member of a specific Launchpad team, which you can join by filling out this form. https://forms.canonical.com/reports/
[19:44] <GunnarHj> bdmurray: Thanks for confirming. Just requested access for l-s. (Is that kind of access package specific?? Assuming that at least core devs have access to everything...)
[19:46] <rbasak> pitti: see bug 1588915 again please.
[19:47] <bdmurray> GunnarHj: just like bug control its not package specific
[19:49] <GunnarHj> bdmurray: Aha, I see. Thanks again.
[21:34] <nacc> rbasak: just sent you a git MR for a very simple merge with our process, using only our helper tools (and git-rebase -i)
[21:35] <nacc> rbasak: i think what we'd do upon 'approval' is the final step would be for the uploader/pusher (presuming the MR submitter not having rights) would need to run `usd-merge commit ubuntu/<series>` to parent the HEAD commit into the right place
[22:36] <nacc> pitti: i think we can sync php-imagick, but let me verify that and i'll submit the request