[01:14] <lfaraone> I applied for PPU for python-django in December 2015 <https://lists.ubuntu.com/archives/devel-permissions/2015-December/000884.html>, pinged again in <https://lists.ubuntu.com/archives/devel-permissions/2016-February/000900.html> — is there a better place to make that request?
[01:15]  * lfaraone waves at bdmurray , Laney :)
[01:16]  * Unit193 waves back, then notices wasn't being waved at. >_>
[01:16] <sarnold> lfaraone: you may need to wait a bit.. https://launchpad.net/~developer-membership-board/+members
[01:16] <sarnold> (at least I think they're the ones who approve those things)
[01:17] <lfaraone> sarnold: ah, seat shuffle / lame duckedness.
[01:18] <hallyn> Hi - so is there a way to tell launchpad "build lp:package from the current xenial package" ?
[01:19] <sarnold> lfaraone: well, maybe it'll get easier in 22 hours? dunno if quorum could then be satisfied if either infi nity or cyphe rmox alone show up? :)
[01:20] <sarnold> hallyn: does backportpackage(1) do what you want?
[01:21] <hallyn> sarnold: I'm looking for a way to do it without having to upload the whole pkg
[01:21] <hallyn> i.e. save my own bandwidth, since it's all already sitting there :)
[01:22] <sarnold> hallyn: ah :) fire up a canonistack instance perhaps?
[01:24] <hallyn> that's an idea - i don't like moving my keys around, but this could be worth it.
[01:24] <hallyn> But mainly it seemed like this would be one of the two most common cases,
[01:25] <hallyn> so just like github has a 'fork' button, i would think a 'create this from debian unstable' or 'create from xenial' would be a button
[01:25] <hallyn> (debian unstable - actually clone the git tree if listed in control file)
[01:27] <sarnold> hmm, maybe you can do that via launchpad recipes?
[01:34] <hallyn> wgrant: hey, ^ do you know of a way to do that, tell launchpad : just turn the current xenial package into a git tree at lp:libvirt ?
[01:34] <hallyn> sarnold: hm.  that's a thought.  i haven't used those in like 5 yrs, don't recall the details.
[01:35] <hallyn> it's for building source pkgs right?
[01:36] <sarnold> I think you can get binary builds out of it from (nearly?) arbitrary bzr and git trees
[01:36] <wgrant> hallyn: How would one turn a package into an upstream VCS repo?
[01:36] <sarnold> I'm not sure about the "do a git clone for me" aspect of your question to wgrant though.. that sounds like something else :)
[01:36] <wgrant> lp:foo can't be the Ubuntu package of foo.
[01:36] <wgrant> It should be foo.
[01:38] <wgrant> hallyn: Can you explain what you're trying to achieve?
[01:39] <wgrant> "have a lp:libvirt with some contents from somewhere" isn't really an end goal.
[01:39] <hallyn> wgrant: I want to be albe to start stashing (i.e. collaborating) changes for next libvirt release at lp:libvirt
[01:40] <hallyn> so I disagree - I can tweak the branches as I like later on, but I want to populate lp:libvirt with either the xenial pkg source, or the debian git tree contents
[01:41] <hallyn> when you say "lp:foo can't be the Ubuntu package of foo" - is that saying that there are conventions about hte 'master' branch, that it should be upstream?
[01:42] <hallyn> it used to be "bzr branch lp:libvirt" would (modulo importer fragility) give me the devel release package contents
[01:43] <hallyn> i'm looking for a git repo i can use to collaborate with others.  but i guess i'll just do github
[01:44] <wgrant> hallyn: Do you mean lp:ubuntu/libvirt?
[01:44] <wgrant> lp:libvirt and lp:ubuntu/libvirt are very different things.
[01:45] <hallyn> yeah i probably mean lp:ubuntu/libvirt
[01:45] <hallyn> it's been a few years :)
[01:45] <hallyn> right, as an alias for lp:ubuntu/$release/libvirt
[01:46] <wgrant> It is our intent to, given time, have dgit imports set up so trees are maintained automatically like the old days, except working because git rather than bzr.
[01:46] <wgrant> At that point having an import button won't make sense, because it will already be done.
[01:46] <wgrant> And it is unlikely that an import button is significantly cheaper to implement than full automatic imports.
[01:47] <wgrant> To clarify, when you say "libvirt release" and "lp:libvirt" you mean "Ubuntu libvirt package release" and "lp:ubuntu/libvirt" or "lp:ubuntu/+source/libvirt"?
[01:47] <hallyn> yeah, i did
[01:48] <hallyn> so it's better fo rme to wait for that to happen, rather than push stuff there myself now?
[01:48] <wgrant> It will be many months at least. I cannot advise waiting.
[01:48] <hallyn> (that == dget imports)
[01:48] <hallyn> well ,waiting would just mean setting something up on github
[01:49] <infinity> rbasak: Not in the timezone you pinged me in.
[01:49] <wgrant> libvirt's history isn't that huge; I'd suggest you construct the repository as you desire and push it up yourself.
[01:49] <infinity> rbasak: I'm in BKK.
[01:49] <wgrant> Let me know if you need assistance with any of that.
[01:49] <hallyn> wgrant: and i should be able to just git push that?
[01:49] <hallyn> wgrant: is there a url describing any branch name conventions which are expected to be used there?
[01:50] <wgrant> hallyn: Not exactly, but you can push to eg. lp:~hallyn/ubuntu/+source/libvirt, and we can work out what should actually be blessed as lp:ubuntu/+source/libvirt later.
[01:50] <hallyn> (I'm used to git-dpm, which doesn't quite fit I don't think)
[01:50] <wgrant> hallyn: There aren't currently conventions.
[01:50] <wgrant> Conventions will be imposed once we have dgit support for the whole archive.
[01:50] <hallyn> ok, if i'm using ~hallyn then i can mes it up as i please, so no worries
[01:50] <hallyn> thanks
[01:50]  * hallyn goes to try
[01:51] <hallyn> ruh roh error: pack-objects died of signal 13
[01:53] <hallyn> wrong ur
[01:53] <hallyn> l
[01:56] <hallyn> thanks wgrant
[02:05] <hallyn> sunova
[02:06] <hallyn> apparently libvirt just has some files that are too bug and it upsets git push :)
[02:07] <hallyn> git config http.postBuffer 52428800 appears to have helped
[02:08] <hallyn> but not enough
[02:09] <hallyn> yeah one packfile is 364M
=== lamont` is now known as lamont
=== dax is now known as daxcat
[05:57] <Mirv> pitti: the s390x tests seem eternally stalled at https://requests.ci-train.ubuntu.com/static/britney/xenial/landing-050/excuses.html
[05:58] <Mirv> mostly the ubuntu-system-settings-online-account would be needed to pass
[06:14] <danjared> so is there a modern way to determine why a package is held back that doesn't involve aptitude? :)
[06:36] <cpaelzer> good morning
[07:16] <pitti> Mirv: kicked
[07:20] <pitti> stgraber: did you see the "realloc(): invalid next size" errors in lxc/i386?
[07:20] <pitti> (same in lxd)
[07:24] <stgraber> pitti: yep, working on it
[07:26] <dholbach> good morning
[08:02] <stgraber> pitti: and we have a fix, tagging a new upstream release and uploading before going to bed, it's kinda late here.
[08:10] <rbasak> infinity: ah, Linaro Connect?
[08:10] <rbasak> Is now any better?
[08:14] <rbasak> smb: for bug 1547640, I just got a conffile prompt
[08:14] <ubottu> bug 1547640 in squid3 (Ubuntu Xenial) "proxy tries ipv6 and gets 503 when no ipv6 routes" [High,In progress] https://launchpad.net/bugs/1547640
[08:14] <rbasak> /etc/cron.daily/apt:
[08:14] <rbasak> Package 'squid3' has conffile prompt and needs to be upgraded manually
[08:14] <smb> rbasak, hm... sure you mean me
[08:14] <rbasak> Sorry
[08:14] <rbasak> smoser:
[08:14] <rbasak> ^^
[08:16] <smb> lamont, do we have news about mgilbert's work on bind9 and reviving something like the exports lib?
[08:17] <rbasak> smoser: seems unnecessary because the change was in a comment :-/
[08:19] <_ruben> question: is there still a chance that iputils 3:20150815-2 will land in 16.04?
[08:26] <_ruben> ah, found bug #1547702
[08:26] <ubottu> bug 1547702 in iputils (Ubuntu) "iputils-ping does not support IPv6 in ping command" [Undecided,Confirmed] https://launchpad.net/bugs/1547702
[09:03] <flexiondotorg> infinity, seb128 darkxst Hello Pilots - If you get the time today I'd really appreciate it if you could look at some of my sponsoring requests :-)
[09:03] <seb128> *shrug*
[09:03] <seb128> it feels like one of those days I shouldn't have started IRC, I'm online for 5 days and already pinged on 3 channels
[09:04] <seb128> flexiondotorg, I'm going to see what I can when/if I patch pilot today (I might move it to tomorrow)
[09:04] <flexiondotorg> seb128, OK
[09:05] <smb> seb128, "only" 3 ping within 5 days? ;)
[09:05] <seb128> smb, lol, it was meant to be "5 minutes" ;-)
[09:06] <smb> seb128, :) I guessed. But it was too good to let it pass.
[09:06] <seb128> indeed!
[09:11] <darkxst> flexiondotorg, I think I am going to do my shift tomorrow also, not sure I can even upload your packages though
[09:36] <flexiondotorg> darkxst, OK
[10:19] <infinity> rbasak: Yeah.
[10:51] <ari-tczew> morning
[10:51] <ari-tczew> don't we have a Feature Freeze already ?
[10:54] <ari-tczew> since topic says "Archive: open", I'm being confused...
[11:31] <lamont> smb: I'll be following up on that today - mon/tue were kinda special for me. :(
[11:34] <smb> lamont, maybe you could make some update to bug 1551351 to have some plan outlined. I feel a certain unrest rising there. But neither did I want to throw anybody else in front of a bus...
[11:34] <ubottu> bug 1551351 in isc-dhcp (Ubuntu Xenial) "dhclient does not renew leases" [High,Confirmed] https://launchpad.net/bugs/1551351
[11:38] <lamont> smb: sure
[11:39] <smb> lamont, much appreciated, thanks!
[11:40] <lamont> done
=== _salem is now known as salem_
[12:10] <LocutusOfBorg> slow armhf and ppc64el autopkgtests?
[12:10] <xnox> ari-tczew, archive is open, and we are in  feature freeze =)
[12:11] <xnox> ari-tczew, i.e. one can upload bug-fixes and ui changes still.
[12:11] <ari-tczew> xnox: should not we inform about FF in the topic?
=== matsubara_ is now known as matsubara
[12:45] <pitti> stgraber: http://images.linuxcontainers.org/images/ubuntu/xenial/amd64/default/ didn't get a new build for three weeks, what's up with that?
[12:46] <pitti> stgraber: same for i386
=== _ruben_ is now known as _ruben
[12:46] <pitti> same for sid
[13:08] <mterry> seb128, can you help golang-github-mvo5-goconfigparser through NEW?
[13:43] <Mirv> pitti: hmm, any idea why https://requests.ci-train.ubuntu.com/static/britney/xenial/landing-045/excuses.html hasn't been updated since the morning, or will I need to ping robert about that?
[13:43] <Mirv> other silo excuses pages have been updating from what I can see
[13:44] <pitti> Mirv: that'd be Robert indeed
[13:49] <smoser> rbasak, ? not sure what you were saying above.
[13:49] <Mirv> pitti: thanks
[14:02] <caribou> I'm about to upload mstflint4 in Universe for Trusty, and Wily which is the mstflint version that is in Xenial
[14:03] <caribou> should I add a Replaces: to the current Xenial package so it upgrades correctly (sorry first time I do that kind of stuff) ?
[14:20] <infinity> caribou: mstflint in xenial should Conflicts/Replaces mstflint4 at the very least.  If you want a smoother upgrade, you should produce an mtsflint4 transitional package (in Section: oldlibs) that Depends: mstflint, and make mstflint Breaks/Replaces mstflint4 (<< 4.1.0+1.46.gb1cdaf7-1ubuntu1)
[14:21] <infinity> caribou: Option A will upgrade correctly only if the user installs mstflint themselves (or something else pulls it in as a dep), option B will force the upgrade for all users of mstflint4.
[14:22] <caribou> infinity: thanks! would you mind reviewing my changes once everything is ready ?
[14:23] <caribou> infinity: I prefer to go with option B; looks cleaner to me
[14:23] <infinity> caribou: I can review, yeahp.  Just 'debdiff | pastebinit -f diff' and toss me a URL.
[14:24] <caribou> infinity: sure, I'll ping you once I'm done
[14:32] <caribou> infinity: in the meantime, could you spare a minute to look at my changes to make the mstflint4  pkg ? http://paste.ubuntu.com/15334753/
[14:35] <smoser> rbasak, oh. that does stink.
[14:38] <caribou> infinity: better with the -f diff : http://paste.ubuntu.com/15334753/
[14:40] <infinity> caribou: That's the same URL. ;P
[14:40] <caribou> infinity: http://paste.ubuntu.com/15334788/
[14:42] <infinity> caribou: I'm not laughing at the obvious sed screwup. ;)
[14:42] <infinity> caribou: (hint: debian/watch)
[14:43] <infinity> caribou: And the Breaks/Replaces should be Conflicts/Replaces
[14:44] <infinity> caribou: And possibly a Provides too, in case anything depends on mstflint (which nothing in archive does, but maybe something third-party might)
[14:44] <caribou> infinity: the upstream pristine tarball name doesn't change, I don't see the sed screwup but looks like I'm missing the obvious
[14:45] <infinity> caribou: "version="
[14:45] <infinity> caribou: That refers to the format of the watch file, not the package version.
[14:46] <caribou> doh !
[14:46] <caribou> infinity: ok, thanks for the review, I'll fix that up
[15:02] <ilhami> hey guys
[15:02] <ilhami> :D
[15:02] <ilhami> http://www.meizu.com/en/products/pro5ubuntu/summary.html
[15:02] <ilhami> preordered.
[15:07] <pitti> Chipaca: can you please set a proper team email for https://launchpad.net/~ubuntu-push-hackers ?
[15:08] <pitti> Chipaca: all of a sudden all ~ 240 indirect members now get spammed with MPs (and probably bugs too)
[15:11] <ogra_> thats a new form of "spreading the word" :)
[15:17] <seb128> mterry, I can have a look after that meeting
[15:31] <mterry> seb128, sure thanks no rush
=== utlemmin` is now known as utlemming
[16:01] <caribou> infinity: here is the mstflint4 changes according to your suggestions : http://paste.ubuntu.com/15335296/
[16:02] <caribou> infinity: and those are the changes to Xenial's mstflint package : http://paste.ubuntu.com/15335310/
[16:04] <ilhami> GUYS!!!!!
[16:04] <ilhami> share the excitement with me
[16:06] <ogra_> ilhami, the guys in #ubuntu-touch will likely happily share ;)
[16:06] <ilhami> ogra_: I would share it with them if I wasn't banned.
=== daxcat is now known as ezri
[16:26] <seb128> mterry, mvo, golang-github-mvo5-goconfigparser ... shouldn't golang-github-mvo5-goconfigparser-dev C/R/P golang-goconfigparser-dev rather than R/B?
[16:27] <mterry> seb128, R/B is enough for upgrades, right?  P is only needed if we want a nicer upgrade path?  But I think we only have one or so rdepends
[16:28] <seb128> mterry, yeah, well it's a rename the provides can be useful no?
[16:28] <seb128> in practice probably doesn't make a difference
[16:28] <seb128> mterry, mvo, anyway, not a blocked, NEWed
[16:29] <xnox> caribou, hey.
[16:29] <mterry> seb128, thanks!
[16:29] <seb128> yw!
[16:29] <caribou> xnox: howdy!
[16:29] <caribou> xnox: crashkernel on s390 I guess :)
[16:30] <xnox> caribou, does it make sense that "when bootloader is updated" (~= update-grub), the relevant scripts check <kdump is enabled> and inject the appropriate "crashkernel=" cmdline?
[16:30] <xnox> caribou, could you help me with <kdump is enabled> -> how should that be checked?
[16:30] <caribou> xnox: this is historical afaik
[16:31] <xnox> horum, i see that when kexec-tools is installed in injects "crashkernel=384M-:128M" into grub unconditionally.
[16:31] <xnox> so should kexec-tools unconditionally inject that into zipl too?
[16:31] <caribou> <kdump is enabled> relies on kdump-tools being installed which might not be the way to collect dumps on s390
[16:32] <xnox> as far as I understand "historical" way to collect crashdump is to configure your zvm to dump the crashkernel onto separate drive outside of said machine.
[16:32] <xnox> using like zdump stuff.
[16:32] <caribou> xnox: no I meant historical in an ubuntu context
[16:32] <xnox> caribou, why do we use "crashkernel=384M-:128M" instead of "crashkernel=auto"?
[16:33] <caribou> crashkernel=auto is RH specific & relies on some kernel code to evaluate how much "auto" really means
[16:33] <xnox> ack.
[16:34] <caribou> xnox: we have an old discussion with arges that we should look into bringing that into our own kernels
[16:34] <xnox> caribou, why shouldn't i have crashkernel= by default?
[16:34] <nacc> xnox: caribou: they've tried upstreaming it several times, but it's never been accepted, iirc
[16:34] <xnox> does it reduce my available RAM?
[16:34] <caribou> xnox: on Debian, it isn't even setup & is up to the sysadmin to read the doc & add it into /etc/default/grub
[16:35] <caribou> xnox: because it systematically reserves some memory and on small systems (an instances) it is a waste of memory
[16:35] <nacc> xnox: it does, as it reserves some specific memory for storing the crashdump
[16:35] <caribou> xnox: though I've been tossing the idea of making it enabled by default on Ubuntu
[16:35] <nacc> also, i'll say by personal experience, crashkernel=auto has to be constantly adjusted
[16:36] <nacc> and can still be wrong :/
[16:36] <nacc> it just hides the values from the end-user/admin, which tbh is worse
[16:36] <nacc> although the translated upstream equivalent is quite long :)
[16:36] <caribou> the 128M value only came as a problem in Xenial because of the increase in initramfs size.
[16:36] <caribou> I fixed kdump-tools so it now relies on a smaller initrd.img that is stored in /var/lib/kdump
[16:36] <xnox> i wonder if it will work with huge kernel and huge initrd on s390x......
[16:37]  * nacc admittedly speaking from a powerpc perspective
[16:37] <caribou> xnox: I think it is worth a revisit in the ML; maybe we can add statements for bigger memories
[16:39] <xnox> caribou, fyi KDUMP_KERNEL=/var/lib/kdump/vmlinuz does not exist for me.
[16:39] <caribou> 128M on an AWS micro instance is 20% of the memory
[16:40] <caribou> xnox: can you sudo kdump-config show | pastebinit ?
[16:41] <xnox> caribou, https://pastebin.canonical.com/151457/
[16:41] <xnox> caribou, i've just installed makedumpfile on s390x.
[16:42] <xnox> caribou, note we don't have linux-crashdump on s390x.
[16:42] <nacc> caribou: xnox: fwiw, i believe rh only uses kdump if memory >= 2G
[16:42] <nacc> per https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/s2-kdump-configuration-cli.html
[16:42] <caribou> xnox: I need to get my hands on one of these to test it out
[16:45] <smb> xnox, I missed the initial reasoning but why not using zdump?
[16:48] <caribou> smb: I don't think there is any reason *not to* use it, just that the ubuntu kdump tooling is not prepared for that
[16:49] <smb> caribou, ah right, might be a format that crash does not recognized I guess.
[16:50] <xnox> smb, we can use zdump, but doesn't that need the same kernel parameter?
[16:50] <xnox> (also)
[16:50] <xnox> smb, the conversation started with https://bugs.launchpad.net/ubuntu/+source/zipl-installer/+bug/1555159
[16:50] <ubottu> Error: Could not gather data from Launchpad for bug #1555159 (https://launchpad.net/bugs/1555159). The error has been logged
[16:50] <xnox> smb, filed by partner.
[16:51] <smb> xnox, it would not. zdump is basically a bootloader you write to a dedicated dump disk and you then ipl an lpar or zvm with special options that preserve cpu state and memory
[16:52] <smb> xnox, and saying that it unlikely works with zKVM guests
[16:53] <smb> But I do not know that for sure (did not have zKVM back then)
[16:57] <cpaelzer> smb: the KVM combination is virsh dump / crash
[16:58] <caribou> smb: I think that crash speaks s390, I saw some discussion about this on the ML recently
[16:59] <cpaelzer> yes - crash can be used to load dumps, you "just" have to get it out in the right format
[16:59] <smb> cpaelzer, Ah ok.
[16:59] <cpaelzer> I think it was zgetdump -f elf -m /dump/disk
[17:00] <smb> cpaelzer, I was not sure whether zdump would produce something that crash understands. Way back we used lcrash
[17:00] <smb> not sure that is around at all, still
[17:00] <cpaelzer> all normal crash these days
[17:00] <cpaelzer> and depending which path to dump you have different ways to get it to crash
[17:01] <cpaelzer> if you went in KVM virsh dump --memory-only ... you can use crash directly
[17:02] <cpaelzer> if you went zipl -d (creating a dump disk), then you use zgetdump to get it "off" that disk
[17:05] <smb> cpaelzer, So I guess the choice is to either sacrifice a spare disk or spare memory ... and probably kdump might be able to be automatically triggered, while using zdump is rather admin initiated
[17:05] <cpaelzer> yes to first 60% of the statement
[17:06] <cpaelzer> you can configure "boot dump disk on panic" and such
[17:06] <smb> ah ok
[17:06] <smb> Think I did not have that either then... or maybe only forgot
[17:18] <infinity> caribou: +1 on the rename.  The xenial bit is a bit buggy.  The Conflict should be a versioned Breaks (with a conflict, the transitional package can't possibly work), and you have a typo (s/msflint2/msflint4/) in your changelog.
[17:19] <caribou> infinity: thanks. I'll fix that up tomorrow & upload
[17:19] <caribou> or maybe ping you one last time for review
[17:19] <infinity> caribou: Also, as mslfint only exists on 5/7 arches, probably better to make msflint4 match, rather than having it arch:all.  No point bumping up the uninstallable count.
[17:20] <caribou> true
[17:21] <infinity> caribou: Oh, and that << version is wrong, it should be higher than the one in trusty,. :P
[17:21] <infinity> caribou: So, probably (<< xenial-version)
[17:22] <caribou> infinity: fine; I just picked what you told me to
[17:23] <infinity> caribou: It was a copy/paste example (it was also based on my assuming the trusty version would be current-xenial~14.04.1)
[17:31] <seb128> does anyone know where issues about http://changelogs.ubuntu.com/changelogs/binary being missing entries should be reported?
[17:31] <seb128> e.g http://changelogs.ubuntu.com/changelogs/binary/f/firefox/45.0+build2-0ubuntu1
[17:31] <seb128> http://changelogs.ubuntu.com/changelogs/pool/main/f/firefox/firefox_45.0+build2-0ubuntu1/changelog works
[17:31] <seb128> unsure what's the difference
[17:32] <seb128> mvo, ^ maybe you know?
[17:32] <LocutusOfBorg> can anybody please rerun python-numpy python-dtcwt testsuite against 0.10.1+dfsg1-4?
[18:20] <mvo> seb128: this is probably still generated from https://code.launchpad.net/~mvo/+junk/lp-changelogs-crawler
[18:20] <seb128> mvo, k, I emailed ubuntu-devel@
[18:20] <seb128> mvo, the binary url seems to miss updatges
[18:20] <seb128> updates
[18:21] <mvo> seb128: I don't even remember this path, so maybe something changed here
[18:21] <seb128> mvo, well it work most of the time, it seems to miss some though
[18:21] <seb128> mvo, e.g http://changelogs.ubuntu.com/changelogs/binary/f/firefox/45.0+build2-0ubuntu1
[18:21] <seb128> mvo, where http://changelogs.ubuntu.com/changelogs/pool/main/f/firefox/firefox_45.0+build2-0ubuntu1/changelog works
[18:23] <mvo> seb128: the log says "INFO:root:firefox 45.0+build2-0ubuntu1 in PENDING state"
[18:24] <seb128> mvo, that update is 5 days old, so I gess something is stucked/buggy
[18:25] <mvo> seb128: it sounds like it
[18:25] <seb128> :-/
[18:25] <mvo> yes :(
[18:25] <seb128> mvo, sorry, I know you already have too much to do, I was not trying to dump that one on you as well
[18:26] <seb128> do you know if i.s maintains that service?
[18:26] <seb128> or is that a custom u-e job on a machine
[18:27] <mvo> seb128: its running on changelogs.u.c as the changelogs user
[18:27] <mvo> seb128: stgraber was doing fixes to it (2013)
[18:28] <seb128> k
[18:28] <seb128> maybe I can convince him to have a look to that issue ;-)
[18:28] <seb128> mvo, thanks!
[18:28] <mvo> seb128: I think he did the binary symlink logic too
[18:29] <stgraber> I have flushed all of that from memory a long time ago :)
[18:29] <nacc> Pharaoh_Atem: fyi, php fix does let twig pass its tests!
[18:58] <bdmurray> seb128: I may have access changelogs
[18:58] <bdmurray> seb128: to the server
[19:01] <Pharaoh_Atem> nacc: wooo!!!!
[19:01] <Pharaoh_Atem> nacc: so is it upstreamed yet?
[19:02] <nacc> Pharaoh_Atem: nope, just updated the bug
[19:20] <rharper> cyphermox: I've got a multipath-tools merge mostly done;  I'd appreciate a review and any extra testing: ppa:raharper/merges ;
[19:21] <rharper> rbasak: smoser: could one of you git-import multipath-tools into ubuntu-server-dev repo on launchpad ?
[19:23] <cyphermox> rharper: could you add a debdiff to the merge/ffe bug? I'll review it later
[19:23] <rharper> cyphermox: sure! thanks
[19:33] <nacc> rbasak: smoser: same for checksecurity, please
[19:41] <smoser> rharper, will do.
[19:43] <rharper> smoser: thanks!
[19:47] <nacc> jgrimm: fyi, checksecurity realy hasn't received many updates in debian either (only 2 releases since utopic). Merge is easy/done, just need the usd tree updated and i can push it
[19:57] <nacc> actually, i wonder -- checksecurity's merges drop all the recommends to suggests. I assume this is due to main v. universe (not documented). But some of the recommends are in main (at least in xenial). Would it make sense to reduce the delta (even if only marginally) and keep those as recommends?
[19:57] <nacc> or is it better to have a nice clean patch that just moves them all?
[20:15] <smoser> nacc, i would think that if the binary packages are in main, then moving only the ones *not* in main to suggests is better.
[20:15] <smoser> even though its still the same number of lines, the delta is less.
[20:15] <nacc> smoser: agreed, thanks!
[20:15] <nacc> smoser: i think people may have been previously just pulling along hte delta because it was easiest :)
[20:21] <nacc> smoser: let's say the package has a depends on fcron, which was previously dropped to suggests in earlier merges. But fcron is no longer in teh archive at all -- should i just remove it from the control file?
[20:28] <nacc> rbasak: so this brings up an interesting (to me) question -- checksecurity's previous delta seems to be mostly robo-carried. Which is fine, but can be shrunk (and the changelog reasoning isn't always true, e.g. for fcron as just mentioned). How do I document that properly in the changelog? Should I say remaining changes ... (whatever is still there). then Dropped the fcron change. Then a new change for
[20:28] <nacc> dropping fcron altogether?
[20:31] <nacc> that is, should it read like: http://paste.ubuntu.com/15337111/
[20:31] <chiluk> cyphermox:  any chance you can do the sru review for https://bugs.launchpad.net/ubuntu/trusty/+source/coreutils/+bug/1535349
[20:31] <ubottu> Launchpad bug 1535349 in coreutils (Ubuntu Trusty) "`df /dev/sda1` no longer reports information for /dev/sda1" [Medium,In progress]
[20:32] <nacc> or like this
[20:32] <nacc> http://paste.ubuntu.com/15337118/
[20:32] <nacc> rbasak: it seems like the former, since the delta is changing
[20:42] <nacc> actually, this might be the clearest:
[20:42] <nacc> http://paste.ubuntu.com/15337168/
[20:42] <nacc> rbasak: --^
[20:50] <nacc> jgrimm: fyi, looking at the chagnes in checksecurity, i don't think a FFe is needed. They are all bugfixes or non-functional changes to cleanup the control file fields
[20:50] <jgrimm> nacc, excellent
[20:53] <cjwatson> hallyn: if you're around, could you hop into #is on the internal server?  a recent change from you to libvirt seems to have made the arm64 builders go boom
[20:55] <jgrimm> nacc, can you take a look at sg3-utils too? single ubuntu patch to it, so hopefully a quick/easy one to tackle
[20:56] <nacc> jgrimm: sure
[20:57] <nacc> smoser: --^ could you import sg3-utils as well, then
[20:57] <jgrimm> nacc, thanks!
[20:57] <smoser> nacc, sure. doing that for multipath-tools now and will work my way thorugh your list :)
[20:57] <nacc> smoser: thanks!
[21:05] <cjwatson> [6~
[21:23] <smoser> rharper, https://code.launchpad.net/~ubuntu-server-dev/ubuntu/+source/multipath-tools/+git/ is there now.
[21:31] <rharper> smoser: thanks!
=== salem_ is now known as _salem
[21:42] <nacc> cyphermox: looking at merging sg3-utils, had a couple of questions about the delta, if you could help me out
[21:45] <cyphermox> nacc: I'm not sure it's that much worth your time tbh
[21:46] <nacc> cyphermox: ok ... should i look at syncing? it seems like a lot of the delta was for pulling in a version that doesn't exist (and has now been superseded in debian)?
[21:46] <cyphermox> what?
[21:47] <nacc> the chagnelog mentions moving to 1.4.0 from Debian ( which I think was meant to meant 1.40). But that was never released or tagged in Debian's git tree that i can find
[21:47] <nacc> and they are on 1.41 now
[21:48] <cyphermox> sg3 should be fine as it is right now, I think -- all of what is in 1.41-1 is already in 1.40-0ubuntu1
[21:49] <nacc> cyphermox: oh i see
[21:49] <nacc> cyphermox: ok, thanks!
[21:49] <nacc> jgrimm: --^ ?
[21:50] <jgrimm> nacc, cyphermox: cool can we drop the patch and sync?
[21:50] <cyphermox> no
[21:50] <cyphermox> well, doesn't seem like it
[21:54] <cyphermox> scratch that, yes I suppose it can be synced
[21:54] <jgrimm> nice. tx
[21:55] <cyphermox> maybe pick 1.42?
[21:55] <nacc> cyphermox: i think there are post-1.41 chagnes that need to be pulled in still, then, right? for sg3-udeb?
[21:55] <nacc> cyphermox: yeah
[21:56] <jgrimm> nacc, cyphermox: that works.
[21:56] <nacc> jgrimm: 1.41-2 is not released yet, but i think that will mean we can sync
[21:56] <nacc> cyphermox: --^ i assume you meant that, unless there's going to be a 1.42 instead
[21:57] <cyphermox> yes, that's what I meant
[21:57] <nacc> cyphermox: thanks!
[21:57] <nacc> jgrimm: i'll keep my eyes out for it
[21:58] <jgrimm> nacc, tx.
=== ezri is now known as daxcat
[22:06] <nacc> Pharaoh_Atem: why does prepare-fpm-pools.mk in php7.0 have a reference to php5?
[22:06] <Pharaoh_Atem> I'm not sure
[22:06] <Pharaoh_Atem> I didn't write that
[22:06] <nacc> ok :)
[22:06] <nacc> Pharaoh_Atem: maybe worth cleaning up
[22:06] <Pharaoh_Atem> it should probably be changed to actually pick up the correct version :)
[22:07] <Pharaoh_Atem> yeah, I've not been pulling the pkg-php stuff from alioth lately
[22:35] <nacc> slangasek: fyi, upstream php has now taken a fix for the twig testsuite, so we can drop our workaround; should i wait til we've packaged the corresponding release before sending an update to twig to drop that delta?
[22:59] <nacc> slangasek: also, looking at excuses, i think we're in a bit of a loop? php-defaults is waiting on php7.0 which is waiting on php-horde-ansel which failed due to the old version of php-pear which is waiting on php-defaults, as well?
[22:59] <marcoceppi> is it okay to ask a debian packaging question here?
[22:59] <mwhudson> marcoceppi: no, that would be terrible!
[23:00] <mwhudson> marcoceppi: :-)
[23:00] <marcoceppi> mwhudson: okay, I'll go find another room then ;)
[23:00] <rharper> ask away
[23:00] <marcoceppi> I have a python program I'm packaging. One of it's dependencies, as listed in the setup.py is path.py. This is packaged in Xenial as python-path but it keeps trying to install python-path.py how do I tell debian python packaging helper that python-path is what it needs?
[23:00] <rharper> if we don;t like it , we won't answer
[23:00] <mwhudson> marcoceppi: there is #ubuntu-packaging but i'm not sure that's an idea that ever took off (a lot fewer people anyway)
[23:00] <marcoceppi> mwhudson: I'm in it, and I asked there already ;)
[23:00] <mwhudson> marcoceppi: haha
[23:01] <marcoceppi> 340 vs 45 audience though, figured I try my luck here
[23:01] <mwhudson> marcoceppi: #debian-mentors on oftc is fairly repsonsive too
[23:01] <mwhudson> unfortunately i know very little about packaging python
[23:02] <bdmurray> Anybody know where /etc/apt/apt.conf.d/20auto-upgrades comes from?
[23:02] <marcoceppi> mwhudson: thanks, I'll ask there
[23:02] <nacc> bdmurray: unattended-upgrades
[23:03] <bdmurray> nacc: thanks
[23:07] <xnox> bdmurray, installer..... ?!
[23:07] <xnox> one get's to choose what to do during d-i installation....
[23:24] <mwhudson> marcoceppi: you seem to be getting a very debian sort of advice :(
[23:29] <rbasak> nacc: yeah I'd do the former. I think that as long as it's clear what happened, the exact form doesn't matter. To me the former is the clearer of the two.
[23:29] <rbasak> nacc: you can always go more verbose if unsure.
[23:31] <marcoceppi> mwhudson: well it got me my answer, so I'm happy
[23:32] <mwhudson> marcoceppi: cool
[23:32] <marcoceppi> mwhudson: at the end of the day, the package I need is in Xenial, so I'm going to go with that
[23:33] <rbasak> smoser: your imports look good, thanks.
[23:38] <nacc> rbasak: thanks ... i figure that eventually it'll get cleaned up anyways, this one is fairly obvious
[23:39] <rbasak> nacc: sure, and having a git tree available certainly makes it clearer too :)
[23:39] <marcoceppi> mwhudson: "path.py python-path (>= 8.1), python-path (<< 9.0)" was all I needed, go figure
[23:41] <Pharaoh_Atem> I hope one day we have a git mirror of the bzr stuff in lp :/
[23:41] <Pharaoh_Atem> bzr is slooow
[23:41] <nacc> rbasak: right, that's why i think the last one is best for this merge, as it matches the commits idetnically
[23:41] <nacc> and then the future merge will just collapse them
[23:41] <nacc> rbasak: but either way, the git tree makes it obvious
[23:41] <rbasak> nacc: completely agree :)
[23:48] <nacc> slangasek: found the msising imagemagick commit that fixes the test :) https://github.com/ImageMagick/ImageMagick/commit/35a7f566c985215980c8beaa45af6652a89d493c
[23:48] <nacc> slangasek: will send a new debdiff, w/ and update to the php-imagick test
[23:55] <shoutme> pitti: hey, nfs-common (a build-dep of libvirt) won't instal lin a container bc gssd fails to run.