[00:13] <twb> I'm interested in the packaging history of dnsmasq in ubuntu, in EOLd releases.  Is there something like git.debian.org or snaspshot.debian.org that'll let me look at the debian/ for dnsmasq?  There's no X-VCS- header, so I guess I need each .diff.gz...
[00:15] <sarnold> twb: I thin kyou'd want to grab the .debian.tar.gz from each of the linked packages https://launchpad.net/ubuntu/+source/dnsmasq/+publishinghistory
[00:15] <twb> Thanks
[00:15] <sarnold> twb: there may be a scriptable solution around pull-lp-source but i'm less sure about that
[00:15] <twb> I was checking old-releases.u.c and packages.u.c, I didn't think to try launchpad (herp derp)
[00:16] <sarnold> (and that's liable to pull down all the .orig tarballs too, even thought you may not need them here)
[00:16] <twb> I can probably ad-hoc script enough for my needs :-)
[00:17] <sarnold> fun party trick, launchpad may also be the easiest way to answer the question for debian, too: https://launchpad.net/debian/+source/dnsmasq/+publishinghistory
[00:17] <twb> Yeah for most stuff I can cheat and git clone git://git.debian.org/collab-maint/foo, or svn equivalent.
[00:18] <twb> Although I guess not for really old releases
[00:20] <kirkland> barry: okay, I'm still outta luck
[00:21] <twb> Argh, curl auto-ungzipped the .diff.gz so now the checksums don't match in dpkg-source -x
[00:22] <twb> Commenting "compressed" out in ~/.curlrc fixes that (and breaks some other sites)
[00:29] <xnox> twb, http://old-releases.ubuntu.com/
[00:29] <twb> xnox: I think that's only the install media
[00:29] <xnox> twb, it has the full archieves.
[00:29] <xnox> twb, wee ubuntu subdir.
[00:30] <twb> Oh, OK.  I suck at reading, then :/
[00:30] <xnox> twb, note that intermediate builds maybe garbagge collected. so typically the "final" released version is available in $adjective suite, and then latest per pocket e.g. $adjective-security.
[00:30] <xnox> (including in launchpad)
[00:31] <xnox> twb, you might get lucky with a bzr branch too.
[00:31] <xnox> twb, http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/wily/dnsmasq/wily/changes
[00:31] <xnox> appears to go back to 2005
[00:32] <sarnold> is the bzr branch exhaustive? or does it only reflect when people used the UDD thing?
[00:33] <mdeslaur> it's supposed to auto-import packages, but it doesn't work properly
[00:40] <xnox> sarnold, it's off for xenial, and hit and miss in history, there are a bunch of unimportable stuff/revisions. but when it was started it was comprehensive. it went back and imported as much as possible.
[00:40] <xnox> omg https://www.youtube.com/watch?v=GUlk1ssXJYk&feature=iv&src_vid=C2THq4UG_Eg&annotation_id=annotation_3271641833 is amazing
[00:41] <sarnold> I wonder if this includes the suse guys dancing along..
[00:58] <doko> kirkland, instead of disabling the tests, please can you just set a correct PYTHONPATH so that the tests find the just built module?
[01:03] <kirkland> doko: hmm, a hint as to what that PYTHONPATH should be?
[01:04] <doko> kirkland, I didn't look. will do tomorrow, it's 2am here. but in general just ask, others like barry or me might be able to help
[01:05] <kirkland> doko: okay, thanks, I'd love some help with this;  I've been struggling with it for a while now
[01:05] <doko> just saw the series of uploads
[01:05] <kirkland> doko: I asked barry earlier today
[01:05] <kirkland> doko: :-)  thanks for noticing and pinging me here
[01:05] <kirkland> doko: i did see where barry's advice in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=803310 was to disable the tests
[07:05] <pitti> Good morning
[07:11] <pitti> $1$.*+
[07:12] <infinity> Guest54153: That's an awfully short password.
[07:12] <Guest54153> it's not -- it's weechat's prompt for a password :)
[07:12] <Unit193> infinity: You're not identified either, fwiw.
[07:13] <infinity> Unit193: MAYBE I'M BEING A REBEL.
[07:13]  * infinity goes to fix it.
[07:13] <Unit193> infinity: THEN WE SUPPORT YOUR DECISION!
[07:13] <infinity> Unit193: ;)
[07:14] <Unit193> (Yes there is something wrong in my head, I know.)
[07:14] <pitti> yay glibc and all those server reboots :)
[07:15] <infinity> I'm so undecided on the media's reporting of nasty vulns over the last few years.
[07:15] <infinity> On the one hand, I guess the press is helpful for getting people to actually act on it and upgrade.
[07:15] <infinity> On the other hand, it's all rather alarmist and annoying.
[07:15] <infinity> THE WORLD IS ENDING, UNPLUG ALL YOUR COMPUTERS AND BUY A GUN.
[07:19] <ScottK> Wouldn't I need a computer to do that because it's not safe to leave my basement?
[07:19] <infinity> ScottK: Buy a gun, THEN turn off your computer?
[07:19] <ScottK> Fair enough.
[07:20] <Unit193> What if I already have a gun?  Buy a handgun too?
[07:20] <infinity> Unit193: You can never have too many on hand to defend against the machines.
[07:20] <infinity> Unit193: Start by shooting your own computers, just in case.
[07:21] <Unit193> Will do!
[07:22]  * pitti suggests an EMP gun instead
[07:26] <ScottK> The machines are probably their own Faraday cage, so as long as they are on the ground, not sure that'll do it.
[07:57] <dholbach> good morning
[08:34] <Mirv> slangase`: if you have time, the python package rename went through Debian NEW queue so debdiff would be ok to upload to Ubuntu https://launchpadlibrarian.net/240160130/debdiff_4.0.1-2ubuntu1_4.0.1-3ubuntu1.txt
[08:49] <infinity> Mirv: Steve's on paternity leave for a month, sponsored it for you.
[08:49] <Mirv> infinity: oh! great, to both of the mentioned things!
[09:33] <ginggs> any archive-admins able to look at removal of python-support please? LP: #1535318 only 3 packages remain that directly depend on python-support
[09:46] <Laney> @pilot in
[10:10] <doko> LocutusOfBorg, dholbach: please follow-up on https://bugs.launchpad.net/ubuntu/+source/fonts-android/+bug/1536547  this is stuck in -proposed
[10:11] <dholbach> LocutusOfBorg, if you need sponsoring for a solution, let me know: ^
[10:11] <doko> see http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt or look at the rdepends of the removed packages
[10:12] <zhangchao> seb128, about new package request: https://bugs.launchpad.net/ubuntukylin/+bug/1536886,according to your proposal, the issues have been solved. Can you help upload this new package to archive ?
[10:12] <doko> seb128, did the last e-d-s upload trigger a transition?
[10:12] <LocutusOfBorg> doko, dholbach I asked on mail list and all affected maintainers, nobody seems to care
[10:13] <LocutusOfBorg> https://lists.ubuntu.com/archives/ubuntu-devel/2016-February/039159.html
[10:13] <LocutusOfBorg> e.g.
[10:13] <LocutusOfBorg> I don't want to make untested changes, so I would appreciate some help, at least from teams
[10:14] <seb128> doko, no
[10:14] <dholbach> LocutusOfBorg, can you send a followup mail to the list again?
[10:14] <seb128> doko, it's a bugfix update, no packaging change
[10:14] <LocutusOfBorg> sure dholbach
[10:14] <seb128> zhangchao, I can try to but I'm quite busy this week, maybe Laney can help since he's patch piloting?
[10:14] <seb128> doko, why?
[10:14] <doko> seb128, ahh, no, libopenobex ...
[10:15] <dholbach> LocutusOfBorg, awesome - thanks
[10:15] <seb128> doko, k
[10:15] <LocutusOfBorg> dholbach, actually reverse-recommends shouldn't be a big issue, maybe we can use the new noto font, and live happy
[10:15] <LocutusOfBorg> assuming they didn't hardcode some font name (grep is needed)
[10:16] <LocutusOfBorg> for reverse-depends debian packages should be fixed
[10:17] <seb128> LocutusOfBorg, doko, dholbach, https://code.launchpad.net/~happyaron/ubuntu-seeds/lp-1468027/+merge/282265
[10:17] <seb128> we got noto MIRed and changed the seed
[10:17] <seb128> so that's the preferred solution
[10:17] <zhangchao> Laney,about new package request: https://bugs.launchpad.net/ubuntukylin/+bug/1536886 . Can you help upload this new package to archive ?
[10:17] <seb128> (sorry I don't have full context, just read https://lists.ubuntu.com/archives/ubuntu-devel/2016-February/039159.html again and the 2 options=
[10:18] <LocutusOfBorg> seb128, <3
[10:18] <Laney> ...
[10:18] <Laney> this will take most of the patch pilot shift
[10:18] <seb128> Laney, I did review it in my previous shift and had just nitpicks, it should be easy
[10:18] <seb128> Laney, I already pre-reviewed for NEW as well so if you upload I can NEW
[10:19] <seb128> well, that's assuming that you are not pickier than me on packaging for the upload :p
[10:19] <Laney> ok, but I don't like it, patch piloting is meant to help the community and this is a Canonical commitment which is bypassing the rest of the things in the queue now
[10:20] <seb128> Laney, well, it's in the queue and community but feel free to not do it it's fine
[10:20] <seb128> I'm going to have a look later or tomorrow if you don't get to it
[10:21] <Laney> vila: bzr is stuck in -proposed because of bzr-upload and loggerhead
[10:21] <Laney> seb128: it's okay I will do, just thinking that normal work sponsorship should be done out of patch pilot time
[10:22] <Laney> vila: they both seem to have << 2.7.0 dependencies
[10:22] <vila> Laney: ungh, where do you see that ? /o\
[10:23] <Laney> vila: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html shows that it is a Valid Candidate but it didn't migrate yet
[10:23] <seb128> Laney, I'm unsure to see the distinction you are making, it's a new package from a contributor who is going through sponsoring and sponsoring contributor work is what we do in patch pilot shifts?
[10:23] <Laney> so look on http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html and see it there
[10:23] <zhangchao> seb128, Laney, Thank you so much for your help :)
[10:24] <LocutusOfBorg> does anybody have some sort of guide for understanding update_output in a human way?
[10:24] <LocutusOfBorg> trying: fonts-android
[10:24] <LocutusOfBorg> skipped: fonts-android (6 <- 56)
[10:24] <LocutusOfBorg>     got: 250+0: a-138:a-18:a-17:i-16:p-19:p-19:s-23
[10:25] <LocutusOfBorg> I don't remember exactly what does it mean
[10:25] <LocutusOfBorg> britney britney, y u no verbose?
[10:25] <doko> LocutusOfBorg, just look apt-cache rdepends <removed packages>
[10:26] <LocutusOfBorg> mmm recommends aren't important?
[10:26] <vila> Laney: hmm, can't find loggerhead or bzr-upload in http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html, bzr-upload is a bit of a mess but I know what is going on and have a wip for that (though it doesn't show up in excuses), but loggerhead I can't see.
[10:26] <doko> apt-cache rdepends fonts-droid fonts-roboto
[10:27] <doko> seb128, what do I have to do with the merge?
[10:27] <Laney> seb128: I suppose I mean that I don't sponsor things for the general community super often, but there is some kind of work arrangement to do things for Kylin so it's easier to do this at any time? Not sure
[10:28] <seb128> doko, that I don't know
[10:28] <Laney> vila: look in update_output.txt - it says that your new bzr package makes the existing bzr-upload and loggerhead ones uninstallable
[10:29] <Laney> vila and LocutusOfBorg: https://wiki.ubuntu.com/ProposedMigration
[10:29] <seb128> Laney, right, I guess you can see it like that, I just see it as contributor work in the queue ... anyway I didn't want to start a big discussion and distract you from doing actual patch piloting, enjoy your shift! ;-)
[10:29] <Laney> kylin-greeter looks forked from unity-greeter so I guess the packaging is probably close to okay ;-)
[10:30] <LocutusOfBorg> Laney, thanks, I was reading that one :)
[10:31] <vila> Laney: ha right ;-) Thanks for the subtitles ;-D
[10:32] <Laney> vila: same is happening here https://release.debian.org/migration/testing.pl?package=bzr :-)
[10:36] <vila> Laney: I'm in touch with jelmer for the debian side, bzr-pipeline and bzrtools already have the same patches as ubuntu, waiting for upload
[10:41] <vila> Laney: bzr-upload has two issues, one already fixed (bzr deps), the other in the work (0 tests are run :-), I'll fix later via debian, and for the former here is https://bugs.launchpad.net/ubuntu/+source/bzr-upload/+bug/1546470
[10:44] <Laney> vila: thx
[10:59] <Laney> seb128: zhangchao: I uploaded that, thx for the work
[11:00] <vila> Laney: and https://bugs.launchpad.net/ubuntu/+source/loggerhead/+bug/1546482 should be good (I'll followup with debian)
[11:11] <seb128> Laney, thanks
[11:24] <rbasak> rharper: strongswan git imports pushed. Please check they're OK. {old,new}/{debian,ubuntu} I'm not pushing to lpusd because those tags will change per-merge, and we don't (presumably) want to publish tags that change. I intended those really just for local use (and to push to your own repo for review if you want).
[11:46] <Laney> vila: I saw, I will get it soon
[11:50] <highvoltage> 3/win 30
[12:04] <flexiondotorg> Laney, Any chance you'll be able to look at libwnck merge? LP: #1546066
[12:18] <Laney> flexiondotorg: I did it already
[12:18] <Laney> should be in t'NEW queue
[12:19] <flexiondotorg> Laney, Thany you very much. That's great :-)
[12:19] <Laney> yeehaw
[12:36] <Laney> rbasak: don't suppose you know about all these php-* sponsoring requests do you? :)
[12:36] <Laney> also, hi!
[12:39] <rbasak> Laney: o/
[12:39] <rbasak> Laney: nacc is taking care of them, with slangasek and infinity
[12:39] <Laney> rbasak: ok - they look a bit daunting on the list
[12:39] <rbasak> I am sort of sponsoring nacc, but for the PHP transition I thought it be best that an AA handled it directly.
[12:39] <rbasak> (since there are bootstrapping coordinations needed)
[12:40] <rbasak> And to my knowledge, I haven't been asked to sponsor anything yet.
[12:41] <rbasak> I'm not sure if nacc intended them to actually be in the sponsorship queue to be sponsored by a patch pilot, or if he subscribed ~ubuntu-sponsors because the process said he should.
[12:43] <Laney> 'k, I'll wait for a reply and then we can deal with it
[12:44] <Laney> unsubscribe + tag is one option
[12:57] <Laney> rharper: hey, I see you subscribed the sponsors to bug #1539634 - what action are you looking for there?
[13:33] <cyphermox> good morning!
[13:44] <caribou> when a packages is overrided by an SRU, is there a place where we can find the package with previous versions ?
[13:45] <ogra_> on launchpad
[13:45] <teward> i was about to say that too heh
[13:45] <ogra_> :)
[13:45] <Laney> @pilout out
[13:45] <udevbot> Error: "pilout" is not a valid command.
[13:45] <Laney> @pilot out
[13:45] <caribou> ogra_: ah, true. thanks!
[13:45] <Laney> hmm
[13:50] <rbasak> caribou: pull-lp-source takes an optional second version string parameter, too.
[13:50] <caribou> rbasak: yeah, but I'm after the binary package
[13:50] <rbasak> caribou: (and rmadison will tell you the release pocket version; LP can also give you every previously published version in a particular pocket)
[13:50] <rbasak> Ah
[13:50] <Son_Goku> rbasak: is there a chance there’s something wrong with libpam-systemd in trusty?
[13:50] <caribou> rbasak: lp is the solution I was after
[13:51] <Son_Goku> I can’t seem to build anything in a chroot that brings in that package as a dependency
[13:51] <Son_Goku> either directly or indirectly
[13:51] <rbasak> Son_Goku: there could well be. Trusty doesn't use systemd, so it presumably didn't get looked after back then.
[13:51] <caribou> we need the previous version that was in trusty-updates to confiirm that cyphermox recent upload fixes a problem in multipath-tools-boot
[13:52] <rbasak> caribou: I see. That makes sense. I don't know of an easier way other than manually hitting the Launchpad UI and dpkg directly.
[13:52] <Son_Goku> rbasak: polkit-1 drags in libpam-systemd, which broke my debootstrap chroot for building libvirt packages (testing patches to libvirt for upstreaming)
[13:52] <rbasak> (I'm sure that can be automated but I'm not aware of any tooling)
[13:52] <caribou> rbasak: that's good enough
[13:53] <Son_Goku> it also apparently breaks the OBS’ ability to even build packages the drag in polkit-1 as a dependency: https://build.opensuse.org/build/home:Pharaoh_Atem:u1404_libvirt/xUbuntu_14.04/x86_64/libvirt/_log
[13:53] <Son_Goku> that one is building an Ubuntu VM to do builds, and that fails too
[13:53] <cyphermox> caribou: yeah, lp
[13:55] <cyphermox> caribou: could be easy to adapt this to pick the right version too : http://paste.ubuntu.com/15100153/
[13:55] <caribou> cyphermox: funny my colleague couldn't figure out why his test system was no longer reproducing the bug
[13:55] <cyphermox> I suppose that's goodish news
[13:55] <rbasak> Son_Goku: I'm not sure, sorry. But if upstreaming, it might be easier to use Wily or Xenial. Trusty is pretty old now.
[13:55] <rbasak> You'd effectively be backporting latest libvirt to Trusty otherwise, and that is non-trivial.
[13:56] <Son_Goku> yeah, I know
[13:56] <Son_Goku> my company wants us to do it because they want new libvirt on our fleet of 14.04 servers
[13:57] <Son_Goku> and I can build it from source by hand on a regular Ubuntu system
[13:57] <Son_Goku> but I can’t do any clean builds at all :(
[13:57] <caribou> I'm looking for a Debian Dev with a few spare cycles to create a project for me on alioth.debian.org/collab-maint. Anyone able to volunteer ?
[13:57] <rbasak> Son_Goku: looks like Canonical already provide libvirt backports through UCA, though that's for use with Ubuntu's Openstack only (other uses unsupported).
[13:58] <rbasak> You could base your work off that perhaps.
[13:58] <rbasak> 1.3 not backported yet it seems.
[13:59] <rbasak> Whatever you do, please publish it.
[13:59] <rbasak> jamespage and/or coreycb might be interested in your work too if you end up backporting libvirt 1.3 to Trusty.
[14:01] <caribou> cyphermox: FYI, going back to multipath-tools 7.7 does reproduce the problem so you last upload does fix the problem \o/
[14:01] <Son_Goku> rbasak: sure, I just wish the chroots worked :(
[14:02] <Son_Goku> I’ll poke and prod at it a bit more
[14:03] <Son_Goku> rbasak: apparently, I’m not the only one bitten: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1325142
[14:21] <xnox> doko, should libdfp cpu target be bumped from power7 -> power8? or not yet?
[14:23] <jtaylor> is there anything in a 14.04 -> 16.04 upgrade that could cause a kernel panic?
[14:23] <nneul> Is there a set time in the release schedule at which point it would be safe to rely on apt-get upgrade getting you to the same state as a fresh install of the release? In particular, at what point will that apply for alphas/betas/etc. of 16.04?
[14:25] <xnox> nneul, it's always the case... since the devel release got split into devel and devel-proposed.
[14:25] <xnox> nneul, and well full-upgrade/dist-upgrade.
[14:25] <xnox> sans bugs/errors that is.
[14:25] <nneul> oh? I thought that there were still points during the early alphas where changes to the install infrastructure could result in the final install being different?
[14:26] <nneul> Asked another way - I'm wanting to get some devel/test boxes up and running/deployed, but would rather not have to reinstall them again later.
[14:26] <xnox> nneul, ..... support for xenial is at #ubuntu+1 channel
[14:27] <nneul> thank you, will ask there!
[14:29] <doko> xnox, sure, we don't need 7 anymore
[14:29] <xnox> doko, ack will bump. updating to new upstream release for s390x here.
[14:42] <spm_draget> I am testing Xenial right now. If I got this right, feature-freeze was 14th, correct? Installed the daily image from the 12th and upgraded today. Libvirt is not responding anymore. 'virsh list' does not return anymore. Not sure if this is related, but I see 'kernel: audit: type=1400 audit(1455716426.684:23): apparmor="DENIED" operation="open" profile="/usr/lib/libvirt/virt-a * Documentation:  https://help.ubuntu.com/mm="virt-aa-
[14:42] <spm_draget> helper" requested_mask="r" denied_mask="r" fsuid=0 ouid=0 ' in dmesg
[14:42] <spm_draget> Any ideas how I should debug this?
[14:42] <spm_draget> * Xenail Server
[14:47] <LocutusOfBorg> jtaylor, which trusty kernel?
[14:48] <LocutusOfBorg> if you try linux-lts-wily the bump is from 4.2 to 4.4
[14:48] <LocutusOfBorg> otherwise 3.13 to 4.4 or so
[14:48] <LocutusOfBorg> quite huge
[14:49] <coreycb> arges, we have a few uploads in trusty/wily queues that could use a review if you or another sru team member could take a look when you get a chance
[14:50] <rharper> Laney: I wanted to see about getting the libnl and the related network-manager SRU going;  I've done just about as much verification that I can; I should go ahead and mark them verification done; but I did want to check about phasing;   I've updated network-manager to include a breaks which should force dpkg to install the network-manager update before installing the libnl package;  but interested to know if there is
[14:50] <rharper> anything else to do before marking verification-done and getting both of those into updates
[14:51] <Laney> rharper: Nope, not if you're happy that they should go in - seems sensible to me
[14:56] <rharper> Laney: excellent; thanks for the help
[14:56] <jtaylor> LocutusOfBorg: 4.2
[14:56] <jtaylor> I'm not clear how an upgrade could cause a panic
[14:56] <jtaylor> does e.g. lvm change something in the disklayout during upgrade?
[14:56] <jtaylor> maybe some changes in the network could cause it?
[14:56] <jtaylor> the trace incldues vfs_write so network is probably not the cause
[15:14] <arges> coreycb: sure
[15:14] <coreycb> arges, thanks
[15:16] <caribou> Q: When applying a debdiff on a source package that deletes a  patch, should a "quilt pop -a" be done beforehand ?
[15:17] <caribou> deletes a QUILT patch btw
[15:17] <arges> caribou: you mean debian/patched/blah.patch
[15:17] <arges> patches
[15:17] <caribou> arges: yes
[15:18] <caribou> arges: what I see is that if I don't quilt pop -a in my source, debuild -S complains that the pristine file has been touched
[15:18] <caribou> arges: which is coherent since quilt push -a has applied the patch that is removed in the debdiff
[15:18] <arges> caribou: that could make sense if you delete the patch, when quilt pop -a is done it doesn't know about unapplying that patch anymore perhaps
[15:19] <caribou> arges: actually sponsor-patch does it
[15:19] <arges> caribou: another approach would be to extract the original sources and copy the debian directory in : ) but I think 'quilt pop -a' would be cleaner
[15:20] <caribou> it pull-lp-source {package}, get the debdiff & applies it then bulk out since the patch has been applied to the source & then removed
[15:35] <rbasak> caribou: things tend to be cleaner if debdiffs are always generated with all quilt patches popped and no .pc directory.
[15:35] <rbasak> IMHO
[15:36] <rbasak> bzr UDD doesn't do this, and ties itself up in knots as a result (again, IMHO)
[15:36] <caribou> rbasak: yeah, I was first puzzled at .pc appearing in debdiffs
[15:37] <caribou> rbasak: in that case, there is no other way than to pop out the patches in order to delete one
[15:38] <caribou> rbasak: to build the debdiff. It is applying the debdiff afterward that causes  problem if the target source package still has the patches applied
[15:40] <rharper> rbasak: I have an existing merge.xx branch locally, I'm creating a new 'merge' branch based on debian/sid; I need to git rebase -i <stuff from my merge.xx branch> onto this new merge branch;  but I've not figured out the right syntax
[15:40] <rbasak> git branch merge merge.xx  # to create the new one that you'll rebase, assuming it doesn't exist already
[15:40] <rbasak> git rebase --onto debian/sid old merge
[15:41] <rbasak> Where "old" is your old new/debian commit hash. You can find this by looking at "git log merge" to see what commit it's based on (the previous Debian import) if the tags aren't clear.
[15:42] <rbasak> (and to check, "git log old..merge" should show you only your Ubuntu delta)
[15:42] <rharper> rbasak: ok, that makes sense; I was setting my merge branch to debian/sid and then merge had conflicts;
[15:42] <rbasak> The general form is "git rebase --onto <new place you're replaying onto> <a> <b>" where "git log <a>..<b>" is the set of commits you're replaying.
[15:43] <rbasak> (and <b> is the branch tip you're moving; it'll move, so branch <b> off first if you want to keep the old <b>)
[15:44] <rbasak> (also note that old should be the last commit you _don't_ want to reply, not the first one you do)
[15:44] <rharper> ah, the a..b helps; what set of commits to apply to the onto branch
[15:44] <rbasak> Right
[15:45] <rharper> rbasak: yes;  in particular for me 'old' is the import/5.3.5-1
[15:45] <rbasak> Right
[15:45] <rharper> cool!
[15:45] <rharper> \o/
[15:45] <rharper> sweet
[15:45] <rbasak> Just wanted to check that you wouldn't accidentally drop the first commit in your Ubuntu delta, that makes it clear you won't :)
[15:45] <rharper> yep
[15:45]  * rbasak goes afk for a bit
[15:46] <rharper> rbasak: thanks again!
[15:46] <barry> pitti: planet-venus is holding up html5lib because it's Regression on armhf, but Always failed on all the other plats.  looks like we got unlucky (wink) in that planet-venus passed once on armhf and now we're forever blocked on it.  can/should we just pretend armhf is Always failed and let this one through?
[16:01] <arges> coreycb: does the latest neutron/trusty upload also include the fixes for bug 1318721?
[16:02] <coreycb> arges, yes it does, and the latest upload should fix up the dep8 issues that the prior upload was hitting
[16:02] <arges> coreycb: ok
[16:03]  * arges loves seeing random 'sleep 5' lines thrown into bash script
[16:04] <coreycb> arges, it's pretty isn't it?
[16:05] <arges> coreycb: i guess the worst case is your run this on a really overloaded/slow system and the sleep isn't long enough
[16:06] <arges> probably should loop and check for pid a finite amount of times
[16:06] <coreycb> arges, right.  it's not a pretty fix but we've done it before.  agreed that would be better.
[16:06] <arges> coreycb: ack, yea i guess you'll be cleaning up any messes this causes
[16:07] <coreycb> arges, good point
[16:08] <arges> My View
[16:10] <rharper> nacc: thanks for the help; along with rbasak;  I've pushed a merge branch into my repo; now looking to do a launchpad MP,  what do I put in for the target repo and target ref path ?
[16:14] <nacc> rharper: target repo should the be the usd path for where you got the debian/sid commits from
[16:14] <nacc> rharper: and target ref should be ubuntu/devel
[16:19] <rharper> nacc: thanks!
[16:22] <jdstrand> sbeattie: hey, is it just me or is this denial weird looking: audit: type=1400 audit(1455703199.526:434): apparmor="DENIED" operation="create" profile="/usr/sbin/ntpd" pid=15139 comm="ntpd" family="unspec" sock_type="dgram" protocol=0
[16:25] <tyhicks> jdstrand: AF_UNSPEC is a valid socket family for some syscalls
[16:25] <tyhicks> jdstrand: I didn't think it was valid for socket(), though. Is that the syscall that is triggering the denial?
[16:26] <jdstrand> I don't know. I was looking at https://bugs.launchpad.net/ubuntu/+source/ntp/+bug/1546455
[16:27] <jdstrand> it's a new denial with yesterday's upload
[16:28] <sbeattie> hunh, weird.
[16:28] <tyhicks> jdstrand: was the family="unspec" the part that looked odd to you?
[16:31] <jdstrand> yeah
[16:32] <jdstrand> looking at the diff, I see code that using AF_UNSPEC
[16:32] <tyhicks> jdstrand: have a link handy to the diff?
[16:32] <jdstrand> http://launchpadlibrarian.net/237992992/ntp_1%3A4.2.6.p5+dfsg-3ubuntu9_1%3A4.2.8p4+dfsg-3ubuntu1.diff.gz
[16:33] <jdstrand> line 316878
[16:33] <jdstrand> it sets the family to that, the socktype to dgram and the protocol to udp
[16:34] <robert_ancell> sarnold, thanks for revieweing bug 1475021 - regarding the zalloc fix, you haven't filed that anywhere right? I should do that?
[16:36] <jdstrand> so I guess we can add 'network dgram udp, network stream tcp,' (I saw AF_UNSPEC later in the diff)
[16:36] <jdstrand> (with tcp)
[16:39] <jdstrand> oh those aren't valid
[16:39] <tyhicks> udp == dgram and tcp == stream
[16:39] <jdstrand> sure
[16:40] <jdstrand> this is what I am thinking it should be changed to:
[16:40] <jdstrand>   # ntp uses AF_INET, AF_INET6 and AF_UNSPEC
[16:40] <jdstrand>   network dgram,
[16:40] <jdstrand>   network stream,
[16:40] <jdstrand> it was:
[16:40] <jdstrand>   network inet dgram,
[16:40] <jdstrand>   network inet6 dgram,
[16:40] <jdstrand>   network inet stream,
[16:40] <jdstrand>   network inet6 stream,
[16:40] <tyhicks> I think that should be fine
[16:40]  * jdstrand nods
[16:40] <jdstrand> tyhicks: thanks!
[16:43] <pitti> barry: that is already the case, see "Should wait for planet-venus 0~git9de2109-3ubuntu1 test, but forced by pitti"
[16:43] <jdstrand> huh
[16:43] <pitti> barry: see http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt search for "trying: html5lib"
[16:43] <jdstrand> those rules aren't working
[16:45] <barry> pitti: i don't really understand that output, but also, i uploaded a planet-venus that should at least pass its dep-8 (albeit perhaps bogusly but i think it's a mostly unmaintained package anyway)
[16:45] <jdstrand> hrmm
[16:45] <barry> pitti: but also, i trust you :)
[16:45] <tyhicks> jdstrand: they aren't compiling or the kernel is still denying ntpd?
[16:45] <jdstrand> tyhicks: we have a problem
[16:45] <jdstrand> the kernel is still denying
[16:45] <pitti> barry: it means that the new html5lib version makes that list of packages uninstallable: dh-virtualenv, python-pip-whl, python-tox, python-virtualenv, python3-venv, python3-virtualenv, python3.5-venv, tox, virtualenv, virtualenvwrapper
[16:45] <barry> pitti: i also merged the ubuntu delta so i can just syncpackage it
[16:45] <jdstrand>   network udp,
[16:45] <jdstrand>   network tcp,
[16:45] <jdstrand>   network dgram,
[16:45] <jdstrand>   network stream,
[16:45] <jdstrand>   network inet,
[16:46] <jdstrand>   network inet6,
[16:46] <jdstrand>   network,
[16:46] <jdstrand> tyhicks: none of those work ^
[16:46] <tyhicks> jdstrand: so the kernel isn't properly handling AF_UNSPEC?
[16:46] <jdstrand> seems like it
[16:46] <tyhicks> :/
[16:46] <pitti> barry: seem's it's caught in that -whl transition?
[16:47] <pitti> barry: and http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#python-pip does not promote because it breaks virtualenv
[16:47] <tyhicks> jdstrand: I'll give it a look after I finish sorting something else out
[16:47] <pitti> barry: and http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#python-virtualenv breaks tox
[16:47] <pitti> barry: I'll try to run all those tests from -proposed, but I already did that some days ago
[16:48] <barry> pitti: yes.  tox 2.3.1-2 should fix python-virtualenv, which should let them all pass
[16:48] <jdstrand> tyhicks: all you have to do is apt-get install ntp on an up to date xenial system. you need 1:4.2.8p4+dfsg-3ubuntu1
[16:49] <pitti> barry: ah, that landed 3 hours ago, so time for some retries indeed
[16:49] <barry> pitti: yep.  will you poke at them?
[16:49] <jdstrand> tyhicks: I'm going to upload with the new rules and add an apparmor task. does that sound reasonable?
[16:49] <pitti> barry: yes
[16:49] <barry> pitti: awesome, thanks!
[16:49] <tyhicks> jdstrand: thanks - I'll see if I can spot the kernel issue
[16:49] <tyhicks> jdstrand: yes
[16:50] <barry> pitti: i'll keep an eye on things too, but if something gets caught up, do ping me
[16:52] <pitti> barry: eek, we just got Qt'ed again, so that'll take a while, sorry (see http://autopkgtest.ubuntu.com/running.shtml)
[16:52] <barry> pitti: that's okay, it's lunch time here :)
[16:56] <ogra_> woah !
[16:56] <ogra_> ogra@anubis:~/datengrab/generic-initrd$ dput ppa:ogra/ppa initramfs-tools-ubuntu-core_0.7.17_source.changes
[16:56] <ogra_> ...
[16:56] <ogra_> RuntimeError: Failed to read %zi bytes from /dev/urandom
[16:56] <ogra_> ogra@anubis:~/datengrab/generic-initrd$
[16:57] <ogra_> (this is trusty)
[16:57] <pitti> barry: ah, I see you already queued retries; I also queued some with using all of -proposed (as they don't seem to have versioned deps)
[16:57] <barry> pitti: +1
[17:25] <pitti> barry: ah, stuff is green on s390x again, so the other arches should go green too (once they ever catch up..)
[17:26] <pitti> I'm still not sure what http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#python-setuptools is supposed to mean
[17:28] <mterry> pitti, are there logs for the generation of touch langpacks?  I wanna see if I can tell where the pam inclusion went wrong
[17:30] <mterry> @pilot in
[17:32] <pitti> mterry: yes, http://macquarie.canonical.com/~langpack/logs/xenial-touch.log -- indeed no trace of them
[17:33] <pitti> mterry: can you please check if http://launchpadlibrarian.net/240166862/ubuntu-rtm-15.04-translations.tar.gz actually contains "pam"? (sorry, about to have a meeting)
[17:33] <mterry> pitti, sure
[17:33] <pitti> mterry: curiously there is a locale named "pam" too :)
[17:35] <mterry> pitti, no it doesn't seem to be in that tarball.  The actual gettext domain is Linux-PAM, didn't see it in expected places (like es or fr)
[17:36] <mterry> Wonder where the 'pam' locale is
[17:38] <rbasak> nacc: http://reqorts.qa.ubuntu.com/reports/sponsoring/index.html
[17:41] <swt2c> Hello all.  A package I maintain in Debian failed to build in Xenial due to a broken dependency.  That dependency has been fixed, so I was wondering if there is some way to request the autobuilder try to build it again (besides bumping the package revision)?
[17:41] <pitti> mterry: oh, I just saw http://bazaar.launchpad.net/~ubuntu-langpack/langpack-o-matic/main/view/head:/cron.daily.rtm
[17:41] <pitti> mterry: it seems it actually merges together the distro and the RTM "overlay" tarballs, so Linux-PAM ought to come from that
[17:42] <pitti> mterry: (sorry, not very familiar with that, this is sil2100's domain)
[17:42] <sil2100> uh oh
[17:42]  * sil2100 hides
[17:42] <mterry> sil2100, :)
[17:42] <kickinz1> rbasak, did you get any chances to review amavisd-new? Can you prepare ubuntu-server-dev git for me to rebase moin and urgrabber merges?
[17:42] <mterry> sil2100, I'm trying to get pam's translations (domain Linux-PAM) in touch
[17:42] <pitti> mterry: but the log actually has lots of "Copying cs/Linux-PAM into package ../xenial/sources-touch/language-pack-touch-cs
[17:42] <pitti> sil2100: nevermind
[17:43] <pitti> mterry: so they ought to be there?
[17:43] <pitti> mterry: I grepped for "pam" thus I didn't see the all-caps name
[17:43] <mterry> pitti, right, I see it too
[17:44] <ogra_> heh
[17:44] <ogra_> ogra@anubis:~$ apt-cache search realpath
[17:44] <ogra_> realpath - Gibt den kanonisierten absoluten Pfadnamen zurück
[17:44] <ogra_> sometimes there are words you shouldnt translate ...
[17:44] <pitti> mterry: sorry, wrong log -- so the *xenial* touch packages have it
[17:44] <mterry> hm
[17:44]  * ogra_ never heard "kanonisiert"
[17:44] <pitti> mterry: but what you are looking at is http://macquarie.canonical.com/~langpack/logs/15.04-touch.log
[17:44] <pitti> mterry: that's from the cron.daily.rtm cronjob
[17:45] <mterry> pitti, uh oh...  did I not update the 15.04 map in that MP?
[17:45] <pitti> mterry: ooh! your latest commit into langpack-o-matic (r552) did only add it to pkglist-touch-{vivid,xenial}
[17:45] <pitti> mterry: but not the 15.04 map
[17:45] <pitti> voilà :)
[17:45] <mterry> pitti, duh
[17:46] <pitti> mterry: it's still a bit unclear how these can be auto-generated
[17:46] <rbasak> kickinz1: sorry otp
[17:46] <pitti> sil2100: ah btw, thanks for explaining the -meta issue for RTM
[17:46] <mterry> pitti, ok I can propose a new branch for that
[17:46] <pitti> mterry: but with that ^ it means we don't actually have a seed branch which we can check out
[17:46] <sil2100> pitti: no worries, it's a bit confusing, we know - not the cleanest approach but works
[17:46] <mterry> pitti, but I'd have to do it manually
[17:46] <pitti> mterry: so I guess we can sync this up with xenial once, or make it identical to xenial if that's the right thing to do, or maintain it manually just like the -meta package in the overlay PPA?
[17:47] <sil2100> (at least worked so far)
[17:47] <mterry> pitti, what's that about seeds?
[17:47] <pitti> mterry: so TL;DR: to unblock this, let's just add it to these map files manually for now
[17:47] <rbasak> nacc: https://bugs.launchpad.net/~nacc/+reportedbugs
[17:47] <pitti> mterry: nevermind, I just commit it, it's trivial
[17:47] <mterry> pitti, heh ok
[17:48] <mterry> pitti, is it possible to remake langpacks?  I want to make sure that we actually end up using the translations correctly too, once they're in place
[17:48] <pitti> mterry: done and rolled out, so without further ado next Tuesday's cronjob will pick that up
[17:48] <pitti> mterry: with a bit of fiddling, as they will normally get the same version number
[17:49] <pitti> mterry: I'll make a note (I need to run off for some hours), I'll do the surgery later tonight
[17:49] <mterry> pitti, ah maybe not important.  I can test manually by putting some mo files in place
[17:49] <pitti> mterry: it's not that difficult, just more than running a cronjob and doing it with only half of my attentino
[17:50]  * pitti -> out for some hours
[17:56]  * doko looks at eight running unity8 builds on s390x ... great platform for unity
[17:56] <ogra_> does it support gestures ?
[18:13] <sarnold> robert_ancell: please do, I mailed the upstream author about the g_malloc_n() issue (and the other minor things), but that's it
[19:11] <damascene> guys, how can a package ask for exception of feature freeze?
[19:12] <rbasak> damascene: https://wiki.ubuntu.com/FreezeExceptionProcess
[19:12] <teward> heh i was about to link that
[19:12] <damascene> thank you both ☺
[19:12] <rbasak> teward: oh you had a question for me.
[19:12] <rbasak> Sorry. I'll look back at that now.
[19:13] <teward> rbasak: no super super rush, but i'd ideally like to get 1.9.11 in before FF so I don't have to go through the exception process, heh.  But yeah, it's really just figuring out which is the lesser of two options to fix a fail-to-build :P
[19:37] <jderose> pitti: i believe i was just hit by lp:1252121 for the first time... it consistently happens on hardware with Killer E2400 Ethernet controllers (Ethernet is disconnected after resume, wont reconnect even if you unplug/re-plug the cable)
[19:38] <jderose> pitti: one horrible, hacky work-around i've found that works is to use a /etc/pm/sleep.d/ script to restart network-manager upon resume. any ideas?
[21:17] <hallyn> pitti: pam-auth-update: Local modifications to /etc/pam.d/common-*, not updating.
[21:18] <hallyn> (updating systemd)
[21:18] <hallyn> oh, nm
[21:18] <hallyn> i misread :)
[21:18] <hallyn> uh, what is "inheritable capabilities management" pam module?
[21:19] <hallyn> huh
[21:22] <hallyn> anyway, pitti, if you're actually around (i assume you're sleeping), some hints about systemd-machined would be very much appreciated.  (comment #33 in bug 1529079)
[21:26] <barry> pitti: i messed up the upload of tox 2.3.1-2.  just uploaded 2.3.1-3 so once that winds through the system i think we'll be okay
[22:26] <mterry> @pilot out
[23:32] <superm1> robert_ancell: i uploaded the fix that sarnold recommended that was blocking the gcab MIR, mterry promoted gcab to main and then I uploaded all the stuff to undo disabling firmware on appstream-glib
[23:33] <robert_ancell> superm1, I saw that, thanks!
[23:33] <superm1> sure thing
[23:33] <superm1> so i guess the only stuff blocking firmware still on gnome-software is fwupd and fwupdate need updated security reviews
[23:33] <robert_ancell> yes
[23:34] <robert_ancell> Then we should re-enable in GNOME Software I guess.
[23:35] <infinity> superm1: Is anyone testing mythbuntu for 14.04.4?
[23:35] <superm1> tgm4883: ^
[23:35] <superm1> he's closer in the loop on that right now
[23:35] <infinity> superm1: At this point, *anyone* would do, just to boot/install/reboot smoketest.  The time for deep testing is passed anyway. :P
[23:36] <superm1> he had some folks lined up that did testing the last go around, but i'm not sure where they are now
[23:37] <superm1> robert_ancell: will fwupd end up a recommends of gnome-software or will it be seeded in ubuntu-desktop meta?  i noticed in debian it's only suggests
[23:38] <robert_ancell> superm1, I think it will be a recommends / or seeded. It seems like it will be a popular feature. I'm not driving the adoption though.
[23:39] <superm1> well so far only my company has published any real firmware that can be used by it, but i'm hoping it does get popular and used widely :)
[23:40] <robert_ancell> superm1, now I'm regretting my switch to Toshiba :)
[23:42] <xnox> doko, forced synced golang-pty to get us to the same as the newer debian upstream release. if it lacks architecture supports, i'll resurect patches.
[23:42] <tgm4883> superm1: I'll do one when I get home. Leaving work now
[23:45] <xnox> doko, actually ppc types are missing =(