=== _salem is now known as salem_
=== salem_ is now known as _salem
[05:58] <cpaelzer> pitti: thanks, successfully verified your fix for bug 1630963 against the autopkgtest git
[05:58] <ubottu> bug 1630963 in autopkgtest (Ubuntu) "issues using user and password in adt-virt-qemu" [Medium,Fix committed] https://launchpad.net/bugs/1630963
[06:31] <pitti> cpaelzer: yay, thanks
[06:32] <pitti> good morning
[06:35] <cpaelzer> good morning pitti
[06:35] <cpaelzer> and good morning everybody else
[06:35]  * cpaelzer feels embarrassed for forgetting his manners by working from home :-/
[06:43] <ginggs> morning pitti! eso-midas has been failing autopkgtests on s390x for a while now, could you do something to let motif migrate please?
[06:45] <pitti> ginggs: hints updated
[06:45] <ginggs> pitti: danke!
[07:25] <ricotz> chrisccoulson, hi
[07:30] <doko> apw: any update on xfsprogs?
[07:31] <ricotz> chrisccoulson, isn't thunderbird 45 effected by https://bugzilla.mozilla.org/show_bug.cgi?id=1251576 too? and please pick up thunderbird 45.4.0
[07:31] <ubottu> Mozilla bug 1251576 in General "GCC6 - TB crashes due to removed null pointer checks for "this"" [Normal,New]
[07:33] <doko> chrisccoulson: and please remove the hardening b-d ...
=== jamespag` is now known as jamespage
[08:44] <apw> doko, oh thanks for the reminder, looking at it now
=== King_InuYasha is now known as Son_Goku
=== LStrange1 is now known as LStranger
=== marcusto_ is now known as marcustomlinson
[09:41] <rbasak> Is there a simple but non-hacky cross-distro way to determine whether to install to /usr/local/lib64 or /usr/local/lib by default? Currently an upstream is testing for the existence of /lib64, but we have that for a ld-linux-x86-64.so.2 symlink, so they install into /usr/local/lib64 which we don't have as a path in ld.so.conf.
[09:43] <rbasak> It's a hand-rolled Makefile build system
[09:44] <sladen> rbasak: have a look what configure/autoconf do
[09:45] <sladen> rbasak: I expect it is just to check the presence of one and use the other if not
[09:49] <rbasak> I can't find the logic in autoconf :-/
[09:50] <rbasak> Clearly it searches there when looking for libraries, but I can't find the bit that decides where to install stuff. Is that usually autoconf?
[09:53] <cjwatson> That's more likely to be automake, if it's detected at all rather than something that you tell it.
[09:53] <cjwatson> Er, I think.
[09:54] <rbasak> I couldn't find a reference in automake, but I have just found something in libtool that looks promising
[09:55] <cjwatson> Maybe I'm wrong there.  lib64 has always been a hideous hack, so I question the assumption that it will be handled well :-)
[09:56] <cjwatson> I believe that RPM passes an appropriate --libdir to configure rather than expecting configure to detect it.
[09:56] <cjwatson> (Source: https://fedoraproject.org/wiki/Packaging:RPMMacros)
[09:56] <cjwatson> s/RPM/the Fedora packaging system/
[09:56] <rbasak> It seems that libtool tries to parse ld.so.conf itself, though I can't get that to work locally. And it'd fail anyway since we use a .d.
[09:57] <rbasak> But I think it'd fall back to not using a lib64, so that'd work for us anyway.
[09:57] <cjwatson> IMO attempts to detect whether to install lib64 are best off being burned.
[09:57] <rbasak> I wonder how things work on RH-based systems when not using RPM.
[09:58] <pitti> cjwatson: do you have an idea how to find out what pulls perl+rename into standard? (http://people.canonical.com/~ubuntu-archive/priority-mismatches.txt) no package in standard depends on either of those, and it's not seeded
[09:58] <pitti> and we really don't want to make perl come back..
[09:58] <cjwatson> pitti: Will look, give me a bit.
[09:58] <pitti> it's also not seeded anywhere
[09:58] <rbasak> cjwatson: I appreciate your response, thanks. Now I'm confident I'm not missing something that everyone knows :-)
[09:58] <cjwatson> rbasak: ICBW of course, my attitude to lib64 has always been one of lofty indifference
[09:58] <rbasak> cjwatson: but the problem is: what do I send upstream to fix this, if they're already expecting to detect lib64? If I remove that, they'll (reasonably) worry about breaking something.
[09:59] <cpaelzer> outside rpm isn't too far from rpm - at least looking at their recommendation "rpm --eval '%{_libdir}'"
[09:59] <cjwatson> Yeah, I don't know :-/
[10:01] <cjwatson> pitti: germinate says (seeded) dnsutils Depends: libbind9-140 Depends: libdns162 Depends: libisc160 Depends: libxml2 Recommends: xml-core Depends: perl Recommends: rename
[10:01] <rbasak> cpaelzer: ah, thanks! So I could concoct something based on that call, and it it fails or doesn't have lib64 in the output, then lib64 isn't in use? That sounds like it might work.
[10:01] <pitti> cjwatson: argh -- cheers
[10:01] <cpaelzer> rbasak: but be aware that on ubuntu that still gives you /usr/lib64
[10:01] <pitti> cjwatson: so looking at germinate is the way to find out
[10:02] <cjwatson> pitti: Yes, priority-mismatches is based on germinate output
[10:02] <rbasak> cpaelzer: you mean if rpm is installed on Ubuntu?
[10:02] <cpaelzer> yes
[10:02] <pitti> cjwatson: ah, I see it in http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.yakkety/standard now; thanks!
[10:03] <rbasak> I wonder if one might consider that a bug in rpm's behavior on Debian/Ubuntu.
[10:03] <rbasak> It'd still be better than what they're doing currently, since they're already assuming lib64 just because /lib64 exists
[10:05] <cpaelzer> rbasak: unfortunately you said non hacky
[10:05] <cpaelzer> rbasak: dirname $(ldd /bin/true | grep libc | awk '{print $3}')
[10:06] <cpaelzer> rbasak: would do on fedora, centos, ubuntu and probably others
[10:06] <cpaelzer> rbasak: but I understand you don't want to suggest such :-)
[10:06] <cpaelzer> rbasak: or maybe you want if it is less broken than the current -e test
[10:06] <rbasak> That does sound like the most non-hacky and reliable suggestion so far, thank you :)
[10:06] <rbasak> Given that it seems that there is no non-hacky solution
[10:07] <cpaelzer> rbasak: put the grep search into the awk to not get called stupid
[10:07] <cpaelzer> I always only realize that later :-)
[10:09] <rbasak> ldd /bin/true|awk '/libc\.so/{print $3}'|grep lib64 >/dev/null 2>&1  # maybe?
[10:09] <rbasak> As I need a test rather than the path.
[10:11] <cpaelzer> rbasak: how about: ldd /bin/true|awk '/libc\.so/{print $3}'|grep -q '^/lib64'
[10:12] <cpaelzer> rbasak: less redirections
[10:12] <rbasak> I didn't think "grep -q" was portable though - for example to BSD?
[10:12] <cpaelzer> rbasak: and some insurance from ...lib64... strings
[10:12] <cpaelzer> rbasak: is that your scope
[10:12] <cpaelzer> rbasak: ok then not -q
[10:12] <cpaelzer> rbasak: but I'd prefer the '^/lib64'
[10:12] <rbasak> And I figured that if lib64 appeared anywhere for libc, then we're in lib64 mode.
=== buxy_bak is now known as buxy
[10:13] <cpaelzer> rbasak: ok for me
[10:14] <rbasak> cjwatson, cpaelzer, sladen: thank you for your help! Now I just have about three other painful but now-offtopic related things to fix :-/
=== hikiko is now known as hikiko|ln
=== hikiko|ln is now known as hikiko
[11:08] <doko> hmm, iptraf doesn't show any interface besides lo in y ...
=== _salem is now known as salem_
=== barry` is now known as barry
=== josepht` is now known as josepht
[13:42] <cpaelzer> I beg a pardon if that it a faux pas by itself, but is there a reasonable way to get root permission in d/rules execution?
[13:42] <cpaelzer> I'd want to use that for a bit weird autotest requirement
[13:45] <cjwatson> cpaelzer: it's not possible in general; use autopkgtests instead for that kind of thing
[13:45] <cpaelzer> cjwatson: thanks
[13:45] <cjwatson> you can do "Restrictions: needs-root" there
[13:45] <cpaelzer> cjwatson: yeah I have that for other tests already
[13:46] <cpaelzer> the charm would ahve been to have that executed on the just built code - I'd like to avoid to build it just again for the adt
[13:47] <cjwatson> yeah ideally you would have a test that you could run on the as-installed code instead
[13:47] <cpaelzer> in that sense I already have it covered in a test run that we use to verify package uploads (with far more tests)
[13:47] <cpaelzer> cjwatson: actually that might be a great idea - for Z* I might tihnk on putting the test program into the -dev package
[13:48] <cpaelzer> cjwatson: is that in general kind of "ok" ?^^
[13:48] <cjwatson> possibly, I don't know your specific situation
[13:48] <cjwatson> you could also consider building only the test program in the autopkgtest
[13:48] <cjwatson> openssh does a sort of partial build of itself in its autopkgtests in order to be able to build the regression tests
[13:49] <rbasak> The link to the spec from http://dep.debian.net/deps/dep8/ appears broken
[13:49] <rbasak> pitti: ^
[13:49] <cjwatson> though possibly shipping them would be better
[13:49] <rbasak> But IIRC there's a test restriction or something similar that specifies that the test needs a "built tree"
[13:49] <cjwatson> right, you certainly *can* do that
[13:49] <cjwatson> but it's better design to avoid it if possible
[13:49] <rbasak> That in theory will mean that no rebuild is required, but in practice we do I think?
[13:49] <cjwatson> especially if the build is slow
=== jgrimm-out is now known as jgrimm
[14:35] <caribou> bdmurray: rbasak: Regarding LP: #1629644, nothing came back from the bug reporter about the potential regression
[14:35] <ubottu> Launchpad bug 1629644 in multipath-tools (Ubuntu) "Trusty: failure to detect device with 0.4.9-3ubuntu7.14" [High,Incomplete] https://launchpad.net/bugs/1629644
[14:36] <caribou> I have another SRU to upload for multipath-tools, should I just disregard this bug & go on with the new SRU ?
[14:37] <rbasak> caribou: I see no others claiming to be affected in that report or any other reports, so I'd go ahead and disregard.
[14:37] <caribou> rbasak: thought so too; thanks!
=== mjeanson_ is now known as mjeanson
[15:06] <pitti> coreycb: what's the justification for the python-pycadf sync?
[15:33] <coreycb> pitti, hi, sorry for the late sync.  it's not critical but the pycadf sync aligns us with the version that upstream has been testing with.  it really just includes a minor typo fix of invalid chars in a config file.
[15:36] <nacc> smoser: re: LP: #1632340, we'll need a source patch like 75336788 added
[15:36] <ubottu> Launchpad bug 1632340 in usd-importer "stacktrace fail import cloud-utils" [High,Confirmed] https://launchpad.net/bugs/1632340
[15:38] <stgraber> pitti: hmm, so could it be that some of that user session work this cycle is causing me to loose all my open windows (as in, all processes die) when some bits of unity crash? it used to be that compiz would crash, respawn and all would be fine, but now it respawns with a clean desktop...
=== masACC is now known as maswan
[15:44] <slangasek> stgraber, mdeslaur, infinity, kees: TB meeting in 16; but I suspect infinity is not actually available to chair this week because release?
[15:45] <jderose> infinity: are you expecting another round of ISO spins now that 4.8.0-22 has landed?
[15:55] <pitti> stgraber: certainly could be that this is missing some tweaks; the intention is that gnome-session.service is the "session leader", i. e. if that crashes everything is gone; but compiz/unity should actually restart by itself and not take everything else down with it
[15:55] <pitti> stgraber: mind filing a bug with the details?
[15:55] <xnox> stgraber, i guess unlike upstart, the cgroup is respawned and everything is scoped into the compiz one, instead of patiently waiting for it to come back.
[15:55] <Laney> pitti: Isn't it that unity7 is in ubuntu-session.target.requires/ ?
[15:56] <Laney> (Not exactly sure what that means with Restart=on-failure though)
[15:56] <pitti> yeah, that could be it -- maybe we need Wants=?
[15:58] <stgraber> pitti: what should I file that bug against? also not sure how much information I can provide. I suspect you can reproduce it by sending SIGSEG to compiz though.
[15:58] <stgraber> obviously, it'd be better if compiz didn't crash, but given that we've failed at making that happen in the past 4 years or so, dealing with it crashing is a good idea :)
[16:00] <pitti> coreycb: you're right, the diff is "fairly harmless"
[16:02] <pitti> stgraber: unity for now (as that ships the file), please assign to me
[16:02] <seb128> stgraber, pitti, I doubt it's systemd session, that was reported before we started that transition
[16:03]  * pitti will have a look later, just grabbing some dinner
[16:03] <stgraber> seb128: oh? still a yakkety regression though right? pretty sure my xenial desktop respawned compiz properly a couple of days ago
[16:03] <seb128> I don't think so
[16:05] <stgraber> maybe a different bug then, I have compiz crashes every week or so and never lost all my windows as a result of it, so something definitely changed
[16:05] <seb128> stgraber, bug #1613297 is the one I know about, unsure if that's what you get
[16:05] <ubottu> bug 1613297 in unity (Ubuntu) "unity --replace crashes/closes some applications (but not all) since 16.04" [High,Triaged] https://launchpad.net/bugs/1613297
[16:12] <stgraber> seb128: I "think" it's unrelated as I explained in https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1632386 just now
[16:12] <ubottu> Launchpad bug 1632386 in unity (Ubuntu) "On yakkety, a unity crash and respawn kills all windows" [Undecided,New]
[16:12] <seb128> stgraber, could well be, I just mentioned it in case that was useful
[16:13] <seb128> stgraber, do you also have a report about the u-p-s taking compiz down issue?
[16:15] <Pharaoh_Atem> I'm getting a weird issue when I attempt to build uw-imap for Ubuntu 14.04
[16:15] <seb128> Trevinho, willcooke, ^ is that known? sounds like an annoying one
[16:15] <stgraber> seb128: I wish I did but for whatever reason, I don't see any crashes in /var/crash/
[16:16] <Pharaoh_Atem> https://paste.fedoraproject.org/448671/62025631/
[16:16] <seb128> stgraber, get a vt with gdb attached to compiz until next one?
[16:16] <Pharaoh_Atem> the thing is, according to the full build log, the dev packages it's talking about are installed: http://kinginuyasha.enanocms.org/downloads/uw-imap-obsbuild.log
[16:17] <willcooke> seb128, not known to me.  But Trevinho is your man
[16:17] <Trevinho> seb128: mhmh... Well it's all due about  the season being dependent on unity 7
[16:17] <stgraber> seb128: yeah, I'll try to remember to keep that going (I unfortunately reboot this machine very frequently for kernel testing)
[16:18] <Pharaoh_Atem> I don't suppose anyone here knows how to fix d-shlib issues?
[16:18] <seb128> Trevinho, but unity segfaulting should lead to a respawn, not to a job stop, no?
[16:26] <nacc> Pharaoh_Atem: possibly it's related to: https://lists.debian.org/debian-user/2003/05/msg00029.html
[16:26] <nacc> Pharaoh_Atem: maybe the versions don't match between what is in the package deps and what is in trusty?
[16:30] <Trevinho> seb128: yes....
[16:33] <Pharaoh_Atem> nacc: that makes no sense, since the package is rebuilt from trusty universe for trusty
[16:34] <Pharaoh_Atem> the uw-imapd package seems to be broken out of the gate on trusty
[16:35] <nacc> Pharaoh_Atem: so you're just doing a rebuild?
[16:35] <Pharaoh_Atem> yes
[16:36] <Pharaoh_Atem> our system doesn't have access to ubuntu universe for trusty, so I did an import to rebuild them
[16:39] <gQuigs> hi there, can someone on the SRU team please review the vlan upload?  (aka, https://launchpad.net/ubuntu/xenial/+queue?queue_state=1)
[16:41] <gQuigs> it's from bug - https://bugs.launchpad.net/debian/+source/vlan/+bug/1224007
[16:41] <ubottu> Launchpad bug 1224007 in vlan (Ubuntu Xenial) "mtu not always set properly on bond/vlan interface" [Medium,In progress]
[16:51] <nacc> Pharaoh_Atem: hrm, a test rebuild in a trusty schroot worked?
[16:51] <Pharaoh_Atem> nacc: that's weird
[16:51] <Pharaoh_Atem> it's not like the package set is any different
[16:51] <nacc> Pharaoh_Atem: did you try doing it in a PPA?
[16:52] <Pharaoh_Atem> no
[16:53] <Pharaoh_Atem> the only difference between my environment and Launchpad's is probably the lack of updates being applied (because it needs to work with 14.04 base)
[16:55] <infinity> jderose: Yes.
[16:56] <jderose> infinity: okay, thanks! you expect a respin today then?
[16:56] <infinity> jderose: Very soon, yes.
[16:56] <powersj> infinity, does that include the server iso?
[16:57] <pitti> across the board, we got a new kernel
[16:57] <pitti> (plus other things which affect all flavors/images)
[16:57] <powersj> pitti, ok thanks!
[16:59]  * infinity just spent the last half hour "debuggin" why his internet was broken until he realized it was his laptop that was acting up.
[16:59] <infinity> I feel smart today.
[17:04] <doko> apw: xfsdump needs the same love as xfsprogs
[17:53] <nacc> smoser: did you see my MR feedback?
[17:56] <smoser> whoops
[17:56] <smoser> didn't change commit after i researchdd
[17:56] <smoser> funny
[17:56] <smoser> will fix
[17:57] <smoser> pushed
[17:58] <smoser> ok, now pushed.
[17:58] <nacc> smoser: thanks
[18:01] <nacc> smoser: merged, with a fixup commit on top, check out master when you can
[18:01] <smoser> so what will uyou do about dpkg parsing ?
[18:01] <smoser> that sucks.
[18:01] <nacc> smoser: not much i can do
[18:01] <smoser> one thing i thought is we could allow for manual
[18:01] <nacc> well, beyond the fixup i documented above
[18:01] <smoser> in event of parse fail, ask user
[18:01] <nacc> that's what hte fixup is, basically
[18:01] <nacc> ah
[18:01] <nacc> that won't work for cron :)
[18:02] <smoser> no it wont, but we expect it to only ever happen for first run
[18:02] <smoser> as new archive tools wont let crap in
[18:02] <nacc> maybe
[18:02] <nacc> we have a fixup method already, though
[18:02] <nacc> i'd rather not add a second
[18:02] <smoser> oh?
[18:02] <nacc> yes, i mentioned it above?
[18:03] <nacc> smoser: re: LP: #1632340, we'll need a source patch like 75336788 added
[18:03] <ubottu> Launchpad bug 1632340 in usd-importer "stacktrace fail import cloud-utils" [High,Confirmed] https://launchpad.net/bugs/1632340
[18:03] <nacc> smoser: we have a facility to patch the 'source' from a published version
[18:03] <nacc> smoser: and provide a range of versions to which that patch applies
[18:03] <nacc> as typically it gets fixed eventually
[18:06] <smoser> nacc, ok. yeah.
[18:06] <nacc> smoser: it's the most generic solution rbasak and i could could come up with :)
[18:07] <nacc> smoser: i need to run a quick errand, but i can look at what's needed for the source patch after that and hopefully get you something imported by EOD
[18:33] <Pharaoh_Atem> nacc: it doesn't seem to work even when OBS is building an Ubuntu VM to do the build: https://build.opensuse.org/package/live_build_log/home:Pharaoh_Atem:u1404_stuff/uw-imap/xUbuntu_14.04/x86_64
[18:33] <Pharaoh_Atem> do you have a build log showing what was installed in the schroot?
[19:08] <chiluk> thanks jderose for reporting back.
[19:08] <jderose> chiluk: np, thanks for the fix!
[19:15] <chiluk> cyphermox can I get some upload lovin on https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1631474
[19:15] <ubottu> Launchpad bug 1631474 in initramfs-tools (Ubuntu) "No networking with initramfs-tools 0.122ubuntu8.3 and ip=dhcp boot option" [Undecided,In progress]
[19:19] <cyphermox> chiluk: that seems very wrong to me
[19:19] <chiluk> ok .. one sec..
[19:19] <slangasek> upload lovin seems wrong to you?
[19:20] <cyphermox> no, that particular upload lovin'
[19:20] <cyphermox> chiluk: it should be fine to do ip=eth0 or ip=BOOTIF
[19:21] <chiluk> correct.
[19:21] <cyphermox> doesn't appear to work for me.
[19:21] <chiluk> I think my fix still works with those.
[19:21] <chiluk> cyphermox: I'll get back to this in 20 minutes or so.. sorry in a meeting.
[19:21] <cyphermox> if you set ip=eth0, DEVICE is unset.
[19:23] <cyphermox> you also don't want to set DEVICE=BOOTIF if you got ip=*:...BOOTIF, as "BOOTIF" is just a placeholder for an actual device name
[19:25] <cyphermox> oh, actually
[19:25] <cyphermox> screw ip=eth0; it's not in that case stanza
[19:25] <cyphermox> but this appears to break for ip=:::::BOOTIF, I think
[19:40] <chiluk> right cyphermox.. that's why I doesn't apply.
[19:40] <chiluk> s/I/it/
[19:40] <chiluk> I'll look at BOOTIF.. although I don't know if that's a valid use case either.
[19:41] <chiluk> really I'd like to completely rewrite the whole configure_networking section at this point.
[19:41] <chiluk> there's a lot of failed use cases.
[19:41] <cyphermox> which?
[19:41] <cyphermox> I will do rewriting later
[19:41] <chiluk> for example :a:b:c:d:device:blah:yada: fails.
[19:42] <chiluk> because it is missed by the ::::*) case statement
[19:42] <chiluk> it should be :.*:.*:.*:.* o something like that.
[19:42] <cyphermox> it's not meant to be caught by that
[19:42] <chiluk> or there should be a separate if in the catchall.
[19:43] <chiluk> also previously ip=::::eth0:dhcp may have been failing since :dhcp wasn't being stripped.
[19:43] <chiluk> I tried to keep the fix as minimal as possible so as not to introduce too much change all at once.
[19:43] <cyphermox> I'm not sure that should be supported
[19:44] <chiluk> I think all things in kernel docs should be supported.
[19:44] <cyphermox> seems to me like all you really need in that case is
[19:44] <cyphermox> if ! echo "${IP}" | grep -q 'BOOTIF\|dhcp$\|any$\|on$'; then
[19:44] <cyphermox> 	DEVICE="${IP#*:*:*:*:*:*}";
[19:44] <cyphermox> fi
[19:45] <chiluk> my kingdom for a bash shell during boot.
[19:45] <chiluk> =~ is your friend..
[19:45] <jderose> chiluk: hehe :)
[19:46] <chiluk> cyphermox.. I was starting to look at the upstream debian project for this.. why is Ubuntu so diverged from debian?
[19:46] <chiluk> long story?
[19:46] <chiluk> ideally all our changes should go in there.. and then trickle back down.
[19:48] <cyphermox> all we need to care about here is this particular switch case, where one does simple dhcp, until we look at everything else in Z and finish ripping out klibc
[19:49] <cyphermox> this divergence is because klibc/ipconfig doesn't do IPv6, and we need something that does
[19:49] <cyphermox> so in that aspect, we don't overly need to care about ::::device:proto, because that does to another switch case which just does ipconfig as it did before
[19:50] <cyphermox> maybe we're missing one :
[19:54] <chiluk> cyphermox this line NEW_DEVICE=${IP#*:*:*:*:*:*}   should be
[19:54] <chiluk> NEW_DEVICE=${IP#*:*:*:*:*:}
[19:54] <cyphermox> no
[19:55] <cyphermox> or why?
[19:55] <chiluk> because it's not regex matching right?
[19:55] <chiluk> I could be wrong on this.
[19:55] <chiluk> I did want to point it out though.
[19:55] <chiluk> I checked both and both seem to function..
[19:56] <chiluk> but # = strip matching from front.
[19:56] <chiluk> the last * matches the device...
[19:57] <chiluk> do you know why both work.
[20:03] <cyphermox> I don't
[20:03] <cyphermox> but we don't need to overthink it if it passes proper testing
[20:04] <chiluk> yeah I think without the * is more correct in that I think the shell is just trying to be smarter than the user since the final * would match all remaining chars
[20:04] <chiluk> just saying.. something I noticed.
[20:04] <cyphermox> wfm
[20:04] <cyphermox> looks like what you're missing is more or less just handling BOOTIF, and dropping the [ ] around your if
[20:05] <cyphermox> chiluk: so something like this: http://paste.ubuntu.com/23309789/
[20:06] <chiluk> ok.
[20:06] <chiluk> so that was another thing..
[20:06] <chiluk> ip=BOOTIF wouldn't hit that case stanza at all.
[20:06] <chiluk> ip=:::::BOOTIF would.
[20:06] <cyphermox> yes
[20:06] <chiluk> but I'm not sure if that's valid... /me rtfm
[20:07] <cyphermox> it most definitely is
[20:07] <cyphermox> and if it wasn't in the doc, then it was supported before and needs to continue working
[20:17] <nacc_> jgrimm: can you or lamont verify LP: #1611923 for x?
[20:17] <ubottu> Launchpad bug 1611923 in python-django (Ubuntu Xenial) "http.request does not support ipv6-formatted ipv4 addresses" [Medium,Fix committed] https://launchpad.net/bugs/1611923
[20:27] <chiluk> yeah cyphermox it's definitely not in the kernel documentation.
[20:27] <chiluk> I'm checking debian docs now.
=== nacc_ is now known as nacc
[21:47] <balloons> micahg, you about?
[21:48] <balloons> mwhudson, in order to upload the mongodb to trusty we'll need signoff from the backporter's team. I suspect micahg can help
[22:00] <mwhudson> balloons: ok
[22:00] <mwhudson> balloons: afaict the package meets all the criteria on https://wiki.ubuntu.com/UbuntuBackports so this shouldn't be too big a deal i hope
[22:01] <balloons> mwhudson, ack. So we should mark the bug confirmed then.. Actually I think they may even just upload it
[22:01] <Unit193> Except the whole not-enough-backporters thing.
[22:01] <balloons> hey Unit193!
[22:01] <Unit193> Howdy
[22:02] <mwhudson> balloons: i guess https://bugs.launchpad.net/trusty-backports/+bug/1583740 doesn't explain how it meets the criteria
[22:02] <ubottu> Launchpad bug 1583740 in trusty-backports "mongo client is missing" [Undecided,New]
[22:02] <mwhudson> balloons: might be better to file a fresh bug?
[22:03] <balloons> mwhudson, did you run the backport tool against it?
[22:03] <mwhudson> balloons: no
[22:03] <balloons> presumably that's how the bug was filed eh?
[22:03] <mwhudson> balloons: eh no, that's the same bug as was used for the SRU
[22:03] <balloons> mwhudson, ahh.. Then I agree. File a new bug with the tool.
[22:03] <mwhudson> balloons: i don't know how the trusty-backports task got added
[22:04] <balloons> me neither ;-)
[22:04] <balloons> unless I did it
[22:04] <mwhudson> balloons: you added it!
[22:04] <balloons> lol, there it is!
[22:04] <mwhudson> balloons: in june :)
[22:04] <balloons> ROFL
[22:04] <mwhudson> balloons: so do you want me to run the requestbackport tool or will you?
[22:05] <balloons> mwhudson, I assume I did which is how it happened, but.. I've no idea at htis point
[22:05] <balloons> mwhudson, please run with it if you can. I really have to EOD
[22:05] <balloons> mwhudson, a new bug, with the tool sounds sanest for everyone
=== zigo is now known as Guest50630
[22:05] <balloons> it's simple to do
[22:05] <mwhudson> balloons: ok
[22:08] <mwhudson> uh why does requestbackport think i want to backport it to xenial as well
[22:09] <mwhudson> heh i haven't actually installed the trusty packages, i guess i should do that :)
[22:10]  * mwhudson afk for 15
=== salem_ is now known as _salem
[23:12] <rbasak> 7/w #maas