[00:00] <tzero> OHH bzr is like git and the bzr bd is just some convenience thing so you have to type bzr more?
[00:01] <infinity> "so you have to type bzr more"... I like that.
[00:01] <tzero> `bzr status` = ... unknown: the missing files -.- hahaha
[00:01] <infinity> That belongs in the docs.
[00:02] <infinity> tzero: bzr is a revision control system, yes, and "bzr bd" is essentially just shorthand for "bzr export $location && cd $location && dpkg-buildpackage"
[00:03] <tzero> oh man, totally burned. That makes more sense now. Thanks a zillion, I was just cruising through the guide and didn't realize it
=== Guest69465 is now known as mfisch
=== mfisch is now known as Guest67039
[02:24] <psusi> can anyone tell me where the ubuntu mesa sources are?  the bzr repo on lp is out of date and the Vcs-Git: header points to the debian repo
=== henrix_ is now known as henrix
[03:38] <lamont> who do we know who knows gtk, dbus, and network interfaces to some degre?
[03:38] <lamont> https://bugs.launchpad.net/ubuntu/+source/sflphone/+bug/1377963 annoys me
[03:38] <ubottu> Launchpad bug 1377963 in sflphone (Ubuntu) "sflphone choses the wrong IP for a SIP connection" [Undecided,New]
[04:19] <pitti> Good morning
[04:33] <pitti> Mirv, tvoss: https://ci-train.ubuntu.com/job/ubuntu-landing-001-2-publish/lastSuccessfulBuild/artifact/packaging_changes_trust-store_1.1.0+14.10.20141007.4-0ubuntu1.diff
[04:34] <pitti> tvoss: ordinarily *.mo files must *not* go into libraries, as the files would conflict on the next soname bump
[04:34] <tvoss> pitti, ah, where do I put them?
[04:34] <pitti> tzero: so this is only they should normally go into some arch: all -common package, or perhaps trusty-store-bin or so
[04:34] <tvoss> -bin?
[04:34] <pitti> tvoss: this only works because we strip translations for main packages and for X-Ubuntu-Use-Langpack: yes pacakges
[04:35] <Mirv> pitti: shouldn't the same probably be for usr/share/core/trust/mir?
[04:35] <pitti> so this landing only works if this is true
[04:35] <Mirv> they are already there in the lib* packages, but sounds wrong
[04:35] <pitti> Mirv: location-service works fine
[04:35] <tvoss> pitti, I will move the translations to the -bin package
[04:36] <pitti> Mirv: correct; any file in a libfooN package must be versioned (in dir or file name)
[04:36] <pitti> otherwise different sonames aren't co-installable
[04:36] <tvoss> pitti, Mirv I can fix that, too
[04:36] <Mirv> tvoss: yeah, /usr/share/core/trust/mir/prompt_main.qml can't be there. thanks.
[04:37] <pitti> Mirv, tvoss: anyway, landing that now would be ok provided that you add a X-Ubuntu-Use-Langpack: yes marker to debian/control's Source:
[04:37] <pitti> as otherwise the translations won't be stripped and go to langpacks, but the package would ship them by itself
[04:40] <tvoss> okay, preparing breakfast real quick, on it after that
[04:41] <pitti> tvoss: and please while you are at it, can you add the "use langpack" marker?
[04:41] <tvoss> pitti, sure
=== tvoss is now known as tvoss|afk
[04:41] <pitti> unless the sources are in main
[04:59] <Mirv> pitti: they are in main
[05:00] <pitti> Mirv: aah, ok (and good!)
[05:00] <pitti> Mirv: right, that explains why they get stripped
[05:00] <Mirv> I was surprised too, they sounded like "probably not MIR:d" :)
[05:00] <pitti> yeah
=== tvoss|afk is now known as tvoss
[05:06] <tvoss> pitti, Mirv pushed the marker for location-service
[05:07] <pitti> tvoss: wb
[05:07] <tvoss> pitti, Mirv will tackle trust-store after breakfast
[05:07] <pitti> tvoss: no worries, sorry about the marker
[05:07] <tvoss> pitti, all good
[05:07] <pitti> tvoss: you don't need it, the packages are in main (quite surprisingly)
[05:07] <tvoss> pitti, Mirv the silo needs manual ack'ing, so no one can accidently land as is
[05:07] <pitti> tvoss: all main packages use langpacks by default
[05:07] <tvoss> pitti, oh :)
[05:07] <Mirv> tvoss: I also marked the silo back to "not tested"
[05:07] <tvoss> Mirv, great, thank you
[05:07] <pitti> tvoss: I'm not quite sure whether that was actually MIRed, or just wrongly NEWed
[05:08] <tvoss> pitti, nope, on purpose, both are in main
[05:08] <tvoss> including MIRs
[05:08] <pitti> nice
=== tvoss is now known as tvoss|test
=== tvoss|test is now known as tvoss
[08:07] <tvoss> Mirv, pitti https://code.launchpad.net/~thomas-voss/trust-store/fix-1354092 has got the changes to .install files
[08:07] <tvoss> Mirv, pitti would appreciate a quick review
[08:23] <Mirv> it would help of course if tvoss would stay online :)
[08:34] <pitti> heh, he's got a tendency to drop off, yeah ;)
[08:34] <pitti> looking (was in a HO)
[08:35] <pitti> Mirv: the X-Ubuntu-Use-Langpack: yes should be dropped again, and I don't quite understand the install.$arch symlinkery, but this LGTM
[08:36] <pitti> /summon tvoss
[08:36]  * Mirv HO now
[08:36] <Mirv> pitti: so LGTM without changes and Langpack: yes to be removed for next release?
[08:36] <seb128> pitti, why does the X-Ubuntu-Use-Langpack use needs to be dropped?
[08:37] <pitti> seb128: well, not *need*, but it's not necessary
[08:37] <pitti> seb128: I falsely assumed that these packages were in universe, like so many others
[08:37] <seb128> oh, that's in main
[08:37] <seb128> yeah, me too, just looked at it
[08:37] <pitti> one package to get it right! :-)
[08:37] <Mirv> "we've a relatively recent touch package that is in main o_O"
[08:38] <pitti> ok, I need to run for some errands, back in ~ 45 mins
[08:38] <pitti> Mirv: if tvoss comes back, would you mind relaying the above to him?
[08:38] <Mirv> let's wait for tvoss to be back, anyhow
[08:38] <Mirv> sure
[08:38] <seb128> technically the update doesn't need to be rejected on that
[08:38] <pitti> cheers
[08:38] <seb128> could be fixed in the next landing
[08:38] <pitti> seb128: no, it doesn't
[08:38] <pitti> seb128: but it's already not yet proposed, so it might just as well get cleaned up while he's at it
[08:39] <seb128> right
[09:02] <pitti> tvoss: wb
[09:02] <tvoss> pitti, hey there
[09:02] <pitti> tvoss: the X-Ubuntu-Use-Langpack: yes should be dropped again, and I don't quite understand the install.$arch symlinkery, but this LGTM
[09:03] <tvoss> pitti, ack, will remove the marker again
[09:03] <pitti> tvoss: sorry about the confusion
[09:03] <tvoss> pitti, no worries, all good
[09:05] <tvoss> pitti, pushed both location-service and trust-store
[09:05] <tvoss> pitti, could you approve both MPs once you are happy?
[09:07] <pitti> tvoss: ack'ed https://code.launchpad.net/~thomas-voss/trust-store/fix-1354092/+merge/235299
[09:11] <pitti> tvoss: what's the other MP?
[09:13] <tvoss> pitti, https://code.launchpad.net/~thomas-voss/location-service/fix-1354092/+merge/235225
[09:15] <pitti> tvoss: erledigt
[09:15] <tvoss> pitti, \o/
[09:16] <tvoss> pitti, Mirv kicked silo rebuild
[09:18] <Mirv> tvoss: thanks! and good that you asked for the approvals since that means we'll be able to ack the packaging changes even though it's in main.
=== Sweetsha1k is now known as Sweetshark
=== doko_ is now known as doko
[10:07] <sil2100> @pilot in
=== udevbot changed the topic of #ubuntu-devel to: Archive: Feature Freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> trusty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: sil2100
[10:08] <cjwatson> YokoZar: I see infinity fixed wine1.6 for you; I fixed it a bit harder so that nobody should have to manually bump that version again.
=== ming is now known as Guest82927
=== MacSlow is now known as MacSlow|lunch
[11:32] <doko> Sweetshark, any update on https://bugs.launchpad.net/ubuntu/+source/libixion/+bug/1349859 ?
[11:32] <ubottu> Ubuntu bug 1349859 in libixion (Ubuntu) "[MIR] libixion (b-d of liborcus)" [Undecided,Incomplete]
[11:41] <doko> Laney, pitti: you signed paramiko, now in dep-wait
[11:42] <doko> jamespage, swift ftbfs
[11:42] <pitti> doko: oh argh, sorry about that; so we either need to sync python-alabaster (FFE) or just remove the new paramiko from -proposed (also fine, it's not that important)
[11:42] <pitti> doko, Laney ^ and as paramiko is in main, I tend to the latter, given where we are in the release cycle; ok?
[11:43] <doko> well, it's a sphinx theme, I have no problem with that. just write a MIR then
[11:43] <pitti> can do that too (we'll need it in V anyway)
[11:45] <doko> synced
[11:45] <jamespage> doko, hmm
[11:45] <pitti> doko: thanks, will review package and write MIR shortly
[11:46] <jamespage> doko, OK looking - I did not see that locally
[11:51] <sil2100> @pilot out
=== udevbot changed the topic of #ubuntu-devel to: Archive: Feature Freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> trusty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
[11:51]  * sil2100 lunch o/
[12:13] <doko> barry, could you take care of the python-eventlet ftbfs? you seem to be involved upstream already, see https://github.com/eventlet/eventlet/issues/135
[12:20] <Sweetshark> doko: whops, that slipped by under the radar in post-conference-mail-avalanche -- will look into it,
[12:22] <doko> Sweetshark, thanks, and please have a look at the two dict-* ftbfs at http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20140914-utopic.html
[12:23] <Sweetshark> doko: willdo
=== _salem is now known as salem_
[12:32] <doko> apw, could you have a look at the arm64 crash ftbfs http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20140914-utopic.html ?
[12:33] <apw> doko, hmmm that is needs building ... so there is no log
[12:34] <rbasak> doko: while you're looking at ftbfs from the test rebuild, I was planning on tackling some of the server ones this week.
[12:34] <rbasak> doko: is there anything you're working on from that list right now?
[12:34] <doko> apw, ahh, I just gave it back
[12:34] <apw> doko, ack, i'll wait on it exploding again
[12:34] <doko> rbasak, no, just pinging people
[12:35] <rbasak> I need some help with the libecap one. It's a mismatched symbols file. I have a fix, but how do I verify that it's safe?
[12:35] <rbasak> Marking some more symbols optional fixes it: http://paste.ubuntu.com/8520625/
[12:35] <rbasak> Is it safe just on the basis that the source hasn't changed?
[12:39] <doko> I've never seen issues removing the destructor symbols
[12:40] <doko> great packaging, two year old source ....
[12:40] <rbasak> How do I know what type of symbols they are?
[12:41] <rbasak> (I understand that C++ mangles the names; I don't know how to match them up to their prototypes)
[12:41] <rbasak> So I have no idea what _ZN7libecap7MessageD0Ev might mean for example.
[12:43] <mlankhorst> run it through c++filt
[12:43] <mlankhorst> ~$ echo _ZN7libecap7MessageD0Ev | c++filt
[12:43] <mlankhorst> libecap::Message::~Message()
[12:43] <rbasak> Oooh
[12:43] <doko> $ c++filt _ZTVNSt3tr121_Sp_counted_base_implIPN7libecap7adapter7ServiceENS_11_Sp_deleterIS3_EELN9__gnu_cxx12_Lock_policyE2EEE
[12:43] <doko> vtable for std::tr1::_Sp_counted_base_impl<libecap::adapter::Service*, std::tr1::_Sp_deleter<libecap::adapter::Service>, (__gnu_cxx::_Lock_policy)2>
[12:43] <rbasak> I didn't know about that
[12:44] <sergiusens> cjwatson: is there any wiki talking about switching your sources list to devel?
[12:51] <cjwatson> sergiusens: no, haven't advertised it much because there are still a few problems I haven't had a chance to fix up
[12:52] <sergiusens> cjwatson: right, that was my followup question, advertising :-) thanks
[12:53] <rbasak> doko: sorry, I'm still not comfortable with this. I don't really follow the bigger picture of how to determine that these symbols really aren't needed.
[12:53] <cjwatson> I have regrettably forgotten the details, would have to try it again for a while to remember them ...
[12:53] <rbasak> The package includes all the headers, which makes it awkward.
[12:54] <rbasak> doko: if you're happy with my diff, then I guess I can upload that.
[12:54] <rbasak> Or else, I don't really see the point of having the symbols file in the first place if we just change it to accomodate when needed.
=== dosaboy_ is now known as dosaboy
[13:02] <barry> doko: yeah.  unfortunately, i'm not sure what the upstream fix really is.  it's probably not simple.  if i have time
=== MacSlow|lunch is now known as MacSlow
[13:20] <doko> rbasak, agreed for c++ symbols files, but c symbol files should be fine
[13:20] <doko> go ahead with the upload
[13:20] <doko> my libabigail upload is still stuck in NEW
[13:22] <rbasak> doko: OK - you mean an upload to drop this c++ symbols file entirely, or just to mark the disappearing symbols as optional as in my diff?
[13:23] <doko> well, optional shouldn't hurt from my point of view
[13:23] <rbasak> OK
[13:23] <pitti> doko: I reviewed the alabaster source package and filed bug 1378830 FYI
[13:23] <ubottu> bug 1378830 in alabaster (Ubuntu) "[MIR] alabaster" [Undecided,New] https://launchpad.net/bugs/1378830
[13:23] <rbasak> Thanks
[13:24] <doko> pitti, looking
[13:28] <doko> pitti, promoted
[13:29] <pitti> doko: danke
[13:30]  * pitti accepts the gazillion langpacks in unapproved
[13:33] <Laney> doko: not the version I synced
[13:33] <smoser> slangasek, i just posted some debug info at bug 1377005.  looks like 'startpar' is at least involved.
[13:33] <ubottu> bug 1377005 in cloud-init "Breaks machine without IPv4: "Route info failed"" [Undecided,New] https://launchpad.net/bugs/1377005
[13:33] <smoser> so your comments woudl be appreciated.
[13:34] <smoser> hm.. but reading what startpar is, maybe thats not that helpkful. maybe you see other info in that ubg
[13:34] <smoser> bug
[14:19] <geser> smoser: hmm, could you check if a "pre-up sleep 5" in your inet6 stance makes a difference (without a ipv4 stance)
[14:20] <geser> if it's really a race condition
[14:20] <smoser> geser, thats a good suggestion. will try.
[14:30] <smoser> geser, does'nt seem to make a difference. still failed. when the ipv4 stanza was below the ipv6, but ipv6 had 'sleep 5'
[14:31] <geser> hmm
[15:03] <doko> barry: http://launchpadlibrarian.net/186832595/python-eventlet_0.13.0-1ubuntu2_0.13.0-1ubuntu3.diff.gz
[15:03] <pitti> smoser: hey, how are you?
[15:04] <pitti> smoser: what's the recommended way to enable restricted/multiverse with cloud-init? do I need to parse the existing sources.list to make some guesswork what the primary mirror is, or can I use some $mirror variable/macro in "apt_sources:"?
[15:04] <pitti> smoser: i. e. I need to refer to the default of "apt_mirror" in apt_sources
[15:14] <barry> doko: ah, just skip the tests.  okay cool, i'll apply
[15:15] <barry> (or did you already?)
[15:21] <doko> barry, no, just the one patch, fixed the sslwrap
[15:22] <barry> doko: ack. i'll forward that upstream.  thanks
[15:31] <smoser> pitti, you shoudl be able to use a boothook to write/edit/re-write /etc/cloud/templates/sources.list.ubuntu.tmpl
[15:32] <smoser> and if you l ook at that file, it should be obvious to you.
[15:32] <doko> rbasak, can't we just sync blas?
[15:34] <rbasak> doko: the previous revision seemed to have some more major changes to me.
[15:34] <rbasak> doko: we could sync it if the release team is happy with that.
[15:34] <doko> ok, I'll take it as it is
[15:34] <rbasak> OK thanks
=== nik90 is now known as nik90|AFK
[15:59] <doko> Saviq, Mirv: qtdeclarative-opensource-src, any reason why this is still built using gcc-4.8? what kind of symbol changes were this?
[16:01] <Saviq> doko, IIRC building it with 4.9 resulted in ABI breakage, which is tricky with apps in the store
[16:02] <Saviq> but don't quote me on that...
[16:02] <Saviq> tsdgeos, do you remember ↑?
[16:02] <doko> Saviq, how do you want to cope with that in the future?
[16:02] <doko> because we won't keep 4.8 forever
[16:03] <Saviq> doko, yeah of course, I'm not sure what the plan on that is... the problem is that we try to maintain backwards compatibility, which in this case would mean keeping multiple binaries
[16:04] <Saviq> or we'd have to break backwards comp
[16:04] <Saviq> but I'm totally out of the loop on those things, cjwatson can you comment on that ↑?
[16:05] <doko> well, then I don't understand why you didn't start freshly with 4.9. but maybe this is too late now
[16:05] <tsdgeos> Saviq: i think you or someone mentioned some c++11 thing
[16:05] <tsdgeos> which is probably not used in qt
[16:05] <pitti> smoser: cheers
[16:05] <Saviq> doko, yeah, we were well past that, and of course didn't foresee such an issue
[16:12] <Mirv> Saviq: doko: we already landed 4.9 qtdeclarative to rtm (just today) and didn't encounter any problems, so I expect any future ubuntu release to drop that 4.8 usage too
[16:12] <cjwatson> Saviq: I don't know about that
[16:13] <Saviq> Mirv, ok then, I must've remembered wrong
[16:13] <doko> Mirv, hmm, but why not to utopic then?
[16:13] <Mirv> doko: it's a new feature that landed
[16:14] <doko> Mirv, maybe I misunderstand, but what is the new feature?
[16:14] <Mirv> doko: precompiling qml magic
[16:14] <Mirv> from ricmm
[16:14] <doko> Mirv, but this is not in the Ubutu package, correct?
[16:14] <Mirv> doko: yes
[16:15] <Mirv> so certainly ubuntu package could diverge and now build without that feature but also dropping the 4.8 usage
[16:15] <doko> Mirv, so no reason not to switch to 4.9 for the utopic release
[16:15] <Mirv> doko: no particular reason, it would just need a round of building and symbol updates
[16:15] <doko> Mirv, would you have time for that this week?
[16:16] <Mirv> doko: possibly yes. I'll add a landing line for that so I don't forget. and the diverged packages need to be tracked a bit, plus I've a third packaging branch for 5.3.2 (for v-series)...
[16:16] <doko> cool, thanks
[16:18] <doko> Mirv, ohh, and please see http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20140914-utopic.html  the qt* ftbfs. can you address this for utopic too, or somebody else?
[16:22] <infinity> Mirv: Erm, aren't RTM changes meant to be in utopic before (or in parallel to) the RTM landings?
[16:22] <infinity> Mirv: If qtdeclarative has moved to 4.9 in RTM, I sure hope this is also heading to utopic yesterday. :P
[16:24] <Mirv> infinity: not really, many landings are currently made rtm first. plus this can't land as is to utopic, and the gcc 4.9 switch was made as a sidetrack of the actual landing.
=== stokachu is now known as stokachu__
[16:24] <Mirv> at some point I assume landings to rtm will continue while ubuntu sides waits for v-series to open
[16:25] <infinity> Mirv: Okay, let me rephrase.  It was a matter of policy that things that were meant to happen in both happen in both at the same time, or the distro first.  Why are we breaking that policy?
[16:25] <infinity> Mirv: RTM-specific hacks are a different story, but this doesn't fall into that.
[16:25] <seb128> because utopic is more frozen than rtm
[16:25] <seb128> and rtm work can't stop on that
[16:25] <infinity> seb128: BS. It could be sitting in the queue.
[16:25] <seb128> we need to open v-serie and land there
[16:26] <seb128> sit and never been accepted
[16:26] <seb128> what's the point?
[16:27] <Mirv> infinity: in general, to get rtm bugs fixed faster it's now often the other way around, landing utopic (queue) secondarily. in this specific case, I wasn't sure if a change like this is wanted to utopic or not, but apparently the answer is yes
[16:27] <infinity> seb128: The queue has 5 items, only one of which is older than 7 hours, 3 are an hour old.  So, while I get the point you're trying to make, it's not actually valid.
[16:27] <seb128> I was not speaking about delays in the queue review
[16:27] <Mirv> and rtm first so that QA can start their work as early as possible
[16:27] <cjwatson> it doesn't strictly have to be actually in utopic; it just has to be queued somehow somewhere in such a way that it will definitely not get lost
[16:27] <seb128> but about features that are not ok for utopic
[16:28] <seb128> those should go in v
[16:28] <seb128> but that's not open for uploads yet
[16:28] <cjwatson> (in a way that's a bit better than "honestly yes I promise")
[16:28] <seb128> or is it?
[16:28] <cjwatson> seb128: not possible at present
[16:28] <seb128> k, but does it make sense to upload features that are not ok for utopic to utopic queue?
[16:28] <cjwatson> (also the singular of series is series)
[16:28] <seb128> those are just going to be rejected since they shouldn't go in that serie
[16:28] <infinity> cjwatson: Yeah, I'm fine with that too, of course, but I'm assuming this "it's only in RTM" thing usually means "only in RTM, and might get lost if people forget to merge back".
[16:29] <infinity> seb128: No, if it's obviously not okay for U, it shouldn't be uploaded to U, as Colin says, but a distro branch where it's committed and won't get lost should also definitely happen.
[16:29] <seb128> right
[16:29] <seb128> nobody said that didn't happen
[16:29] <seb128> and it's different from "need to get in utopic first"
[16:30] <infinity> Anyhow, this 4.9 change is a bit of a unique snowflake, as we've been pushing for that to be completed throughout the whole cycle.
[16:30] <infinity> If it can get done, it should get done, so we don't have to deal with the potential pain between U and V being incompatible somehow.
[16:32] <Mirv> I'll get that in the queue in the morning
[16:33] <infinity> Mirv: <3
=== stokachu__ is now known as stokachu
[16:35] <smoser> barry, you just want to fix bug 1295833 for me ?
[16:35] <ubottu> bug 1295833 in bzr-fastimport (Ubuntu) "Import error in exporter.py - fastimport.helpers" [High,Triaged] https://launchpad.net/bugs/1295833
[16:35] <smoser> it looks like someone just has to do it. per the last comment there.
[16:43] <barry> smoser: i'll take a look
=== nik90|AFK is now known as nik90
[16:54] <slangasek> smoser: sorry, I can't tell in your logs on bug #1377005 what the differences are between good and bad wrt networking
[16:54] <ubottu> bug 1377005 in cloud-init "Breaks machine without IPv4: "Route info failed"" [Undecided,New] https://launchpad.net/bugs/1377005
[16:55] <slangasek> smoser: and nothing startpar-related jumps out at me
[17:04] <doko> seb128, Laney: please could you have a look at the glibmm2.4 ftbfs, see http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20140914-utopic.html
[17:05] <seb128> doko, k
[17:06] <seb128> Laney, we should probably update that to 2.42 to match glib, wdyt?
[17:07] <Laney> I guess
[17:07] <doko> who is the proper person to ask for the unity-* ftbfs?
[17:07] <seb128> doko, depending of the package
[17:08] <doko> same for ido
[17:08] <seb128> the lens/scope probably thostr's team
[17:08] <seb128> the webapp one, dbarth
[17:08] <seb128> ido, bregma
[17:08] <seb128> or ted
[17:08] <Laney> https://code.launchpad.net/~laney/unity-lens-music/notify-notification/+merge/235434
[17:09] <doko> seb128, which ones of ido, unity-lens-music, unity-scope-manpages, unity-webapps-qml do you want to look at?
[17:09] <doko> bregma, ^^^
[17:10] <seb128> Laney, let me ack/do a landing for that one
[17:10] <Laney> k, cool
=== Guest67039 is now known as mfisch
[17:10] <Laney> I forgot about it to be honest, but seems that nobody is watching those merge proposals
=== mfisch is now known as Guest72593
[17:11] <smoser> slangasek, i cna't tell either.
[17:11] <smoser> you have any thoughts on where to go ? i collected /var/log/upstart/* also, and
[17:12] <smoser>  http://paste.ubuntu.com/8522008/
[17:12] <smoser> ie, no hints there either.
[17:12] <seb128> Laney, yeah, music lens didn't move for like a year, I guess that's deprecated/not maintained
[17:12] <Laney> desktop eh
[17:13] <seb128> it's also that the people who worked on those components left (e.g mhr3)
[17:15] <doko> barry, could you have a look at https://launchpadlibrarian.net/184782940/buildlog_ubuntu-utopic-i386.dirspec_13.10-0ubuntu2_FAILEDTOBUILD.txt.gz ?
=== roadmr is now known as roadmr_afk
[17:21] <slangasek> smoser: ok, but you said "startpar is involved", and I wasn't sure what you meant by that... startpar is always running at boot, but I don't see anything going wrong with it
[17:23] <smoser> slangasek, right. the one thing that was different in the  logs
[17:23] <smoser> was the location of startpar
[17:23] <slangasek> ok
[17:23] <smoser> which i think was actually related to the location of mounted proc
[17:23] <smoser> not sure though
[17:26] <slangasek> smoser: so do you have a /var/log/upstart/network-interface-$iface.log?
[17:26] <smoser> nothign there.
[17:26] <smoser> which means it didn't have output
[17:26] <slangasek> yes
[17:26] <smoser> so i know its probably red-herring
[17:26] <smoser> but
[17:27] <smoser> these 3 things happen before 'EXT4-fs (vda1): re-mounted. Opts: (null)' in bad case , and after in good case
[17:27] <smoser> init: startpar-bridge (mounted-proc--stopped) state changed from post-stop to waiting^M
[17:27] <smoser> init: Handling stopping event^M
[17:27] <smoser> init: startpar-bridge (mounted-dev--stopped) state changed from stopping to killed^
[17:28] <smoser> although i'm not certain order between event and message written to /dev/console is guarnateed (ie, if upstarts writing to /dev/console is intermixed with kernels in a determinable order)
[17:29] <slangasek> yes, it's not guaranteed, and I don't see anything there that looks suspicious
[17:32] <smoser> any wild guesses or thoughts are appreciated.
[17:42] <slangasek> smoser: so in the failure case, what does /run/network/ifstate show after boot, and what's the output of 'sudo initctl list | grep network-interface'?
[18:17] <doko> pitti, postgresql-9.4 autopkg test failure, blocks python3.4
[19:06] <ScottK> mitya57: Why is it too late on sphinx-issuetracker?
=== roadmr_afk is now known as roadmr
[19:30] <kenvandine> doko, did you mean to drop  Multi-Arch: allowed in gdb?
[19:32] <cjwatson> (^- I investigated, it's not mentioned in the changelog and might be a merge accident)
[19:32] <kenvandine> doko, ubuntu-system-settings has a build dep on gdb:any, so we have a FTBFS
[19:51] <YokoZar> cjwatson: Thanks for the fix to britney :)
[19:52] <smoser> slangasek,
[19:52] <smoser> $ cat /run/network/ifstate
[19:52] <smoser> eth0=eth0
[19:52] <smoser> lo=lo
[19:52] <slangasek> smoser: and eth0 is your test ipv6-only interface?
[19:52] <smoser> http://paste.ubuntu.com/8522838/
[19:53] <smoser> right.
=== Guest72593 is now known as mfisch
[19:53] <smoser> if youre interesetd in re-creating
[19:53] <smoser> i just pushed instructions to https://code.launchpad.net/~smoser/+junk/lp-1377005
=== mfisch is now known as Guest6813
[19:53] <slangasek> curious/annoying
[19:53] <smoser> recreates with just downloading an image, modifying it a bit
[19:53] <smoser> and running in kvm (even with user networking)
[19:54] <slangasek> not going to have time to try to reproduce it right now
[19:54] <smoser> yeah, well if you ahve time (and i'd much appreciate it, or anyone else),
[19:54] <smoser> http://bazaar.launchpad.net/~smoser/+junk/lp-1377005/view/head:/README
[19:54] <smoser> is honestly how much effort it takes.
=== Guest6813 is now known as mfisch
[20:00] <cjwatson> YokoZar: np
[20:31] <cjwatson> Which Ubuntu flavours still use consolekit (if any)?
[20:32] <cjwatson> Trying to work out whether the proper fix to bug 1334916 is to actually put effort and thought into it, or drop the patch ... I suspect the latter is the right answer eventually but maybe not yet
[20:32] <ubottu> bug 1334916 in openssh (Ubuntu) "sshd-ConsoleKit integration patch causes abrupt termination of multichannel sessions" [Undecided,New] https://launchpad.net/bugs/1334916
[20:34] <Unit193> mate-power-manager and lxsession-logout (Mate Ubuntu, Lubuntu) dep on it.
[20:43] <cjwatson> Unit193: Right, I was trying to work out the extent to which the dependencies were real/interesting - the point of the consolekit patch is so that you can interact with things like policykit over ssh, but if it's just a few things that realistically you would only ever manipulate from a logged-in desktop, then that's less concerning
[20:43] <infinity> cjwatson: From the package names, it sure sounds like it's the latter.
[20:43] <smoser> slangasek, well, heres some more info. http://paste.ubuntu.com/8523098/ <-- output of 'ifup --verbose' in both cases with attached commentary.
[20:44] <Unit193> Alright, pardon me.
[20:45] <cjwatson> Unit193: no, don't apologise, I wasn't very clear and it's useful information ...
[20:46] <cjwatson> I guess maybe I should be trying to figure out whether policykit might ever care
[20:46] <slangasek> smoser: um?  '$ sudo ifup --verbose
[20:46] <slangasek> ifup: Use --help for help
[20:46] <slangasek> '
[20:46] <slangasek> smoser: oh, ifup --verbose --allow-auto, ok
[20:47] <smoser> well. yeah.
[20:47] <smoser>  's,ifup --allow auto,ifup --verbose --allow auto,'
[20:49] <smoser> well, there goes my ethtool theory. i 'chmod -x /sbin/ethtool' without it makign a difference.
[20:49] <infinity> smoser: Those logs are identical...
[20:49] <smoser> well, order is important.
[20:49] <infinity> smoser: cut and paste fail, or were they really identical?
[20:50] <smoser> oh shoot.
[20:50] <smoser> yeah.
[20:50] <smoser> fail.
[20:51] <smoser> re-attaching corrected
[20:51] <geser> and I was wondering why I didn't see any difference between GOOD and BAD
[20:51] <smoser> reload
[20:51] <smoser> and ihave to go now.
[20:51] <infinity> geser: I thought I was maybe just failing to parse, so fed them both to diff, which lies less often than my eyes.
[20:51] <smoser> later.
[20:51] <infinity> smoser: "reload"?  It's a pastebin.
[20:51] <smoser> oh.
[20:51] <smoser> see bug
[20:52] <smoser> https://bugs.launchpad.net/cloud-init/+bug/1377005
[20:52] <ubottu> Ubuntu bug 1377005 in cloud-init "Breaks machine without IPv4: "Route info failed"" [Undecided,New]
[20:52] <smoser> sorry for confusion
[20:52] <smoser> i have to run
[20:52] <infinity> Ahh.
[20:52] <infinity> Toodles.
[20:53] <cjwatson> pitti: BTW thank you for all your effort making adt-virt-qemu etc. work well.  This is so much less unfun than uploading-and-praying, or hoping that the schroot runner is a good enough approximation.
[21:51] <slangasek> smoser: so the ordering should only matter if something happens during the ipv4 bring-up that undoes the ipv6 bring-up.  But what about the case where there's *only* ipv6?
=== salem_ is now known as _salem
[23:53] <smoser> slangasek, i can get that. but i think that something in the ipv4 bringup is just providing time in some way preparing system for ipv6 to come up.  ie, if the 'modprobe net-pf-10' not blocking. anyway, yeah, i can get that though.
[23:54] <smoser> but actually, the "just ipv6" is not going to be differen tthan ipv6 then ipv4 in that its busted. and clearly wasn't ready at ipv6 bringup time.
[23:57] <smoser> so, yeah, i dont think ipv4 "un-does" ipv6, i think it provides something (possibly just time) to make system ready for ipv6.