[00:18] <xnox> pitti: i thought that was solved -> clicks declare x-tests:autopilot_dir= key in their manifest.
[00:18] <xnox> pitti: that means they are ported.
[00:18] <xnox> pitti: deb based tests, will ship modules in either python3 or python2.7 path (and thus import/re-exec test works for them)
[00:18] <pitti> xnox: right, but I was told that for some cases/apps the tests would just be in bzr, and that there was no packaging for those
[00:18] <pitti> xnox: anyway, is the meeting tomorrow ok for you?
[00:18] <xnox> pitti: all click's tests are just in bzr.
[00:18] <xnox> pitti: yeah, i'll be there.
[00:19] <pitti> xnox: perfect, thank you
[00:19] <xnox> pitti: and i should update my phablet-tools patch before that meeting.
[00:19] <pitti> probably best to discuss that with everyone in the hangout
[00:19] <xnox> pitti: is sergiusens on the call as well?
[00:21] <pitti> xnox: not ATM, but I'm happy to invite him
[00:21] <xnox> pitti: please do.
[00:25] <slangasek> xnox, pitti: so I know this was discussed at the core sprint, but I have yet to see a write-up of what was decided there.
[00:26] <slangasek> I gather that xnox and barry have a clear idea of what's required, but it hasn't been written up / shared, which should be remedied ASAP
[00:26] <xnox> slangasek: and there is another sprint in progress across the pond, which may have new things....
[00:27] <xnox> slangasek: i'll write something up early tomorrow such that we all should be on a similar page and with all steps clear (and their current status)
[00:27] <slangasek> xnox: ok, thank you
[00:29] <pitti> slangasek: I gave a summary to https://code.launchpad.net/~barry/autopilot/reexec/+merge/203765
[00:30] <pitti> slangasek: nothing decided really, we just discussed it and found that we agree on some things, but need xnox and barry for others
[00:30] <pitti> slangasek: we just ruled out some possible proposals (such as this reexec trick or merging py2/3 modules into python-autopilot) as they wouldn't work
[00:30] <slangasek> um
[00:30] <slangasek> why does re-exec not work?
[00:31] <pitti> because it's only done on import, not if there's a failed test
[00:31] <pitti> importing py3 autopilot will always work, but you might get test failures on non-py3 compatible tests
[00:31] <pitti> if you run tests from bzr you don't have separate install locations for py2 and py3 autopilot test modules
[00:33] <slangasek> pitti: so xnox and barry did have a plan to address this
[00:33] <slangasek> which xnox has agreed to write down where we can all discuss it, instead of rediscussing everything from scratch every other week :)
[00:34] <xnox> pitti: re-exec trick works, if one uses phablet-test-run with my proposed branch to phablet-test-run.
[00:34] <pitti> well yes, that's the bit which we don't understand yet, and I haven't seen a place which explains this
[00:34] <xnox> pitti: indeed executing directly in the bzr checkout has a corner case, but everyone must use phablet-test-run, as during transition period we will not support anything else.
[00:35] <xnox> pitti: right i'll write exactly that up.
[00:35] <pitti> xnox: barry said that there are tests which don't use that
[00:35] <pitti> if that's obsolete, then it makes the whole thing much simpler
[00:36] <slangasek> pitti: IIRC the plan was to force use of phablet-test-run as a precondition for py3 tests, and let non-ptr callers continue to use python2
[00:37] <pitti> slangasek: ah
[00:37] <xnox> pitti: and the point of re-exec trick was that it live for a very short period of time: between the upload and until last pre-installed click ports to python3, at the point python2 from autopilot will be purged.
[00:37] <slangasek> since we should be using ptr for everything, and should be using python3 for everything
[00:37] <xnox> pitti: and we will _only_ support python3 with autopilot.
[00:37] <slangasek> so it doesn't hurt to bundle the two
[00:37] <pitti> ack
[00:38] <pitti> so thomi and I were open to either reexec or checking a flag in the deb/click source in /usr/bin/autopkgtest to then run python[3] -m autopkgtest.run
[00:38] <pitti> but thomi said we don't always have a click/deb source so we can't use a flag in the packaging, but it needs to be in the sourc
[00:38] <xnox> pitti: the current proposal we had is that - phablet-test-run looks into click manifest (as it does now anyway) to fetch the bzr branch of the tests.
[00:39] <pitti> xnox: click manifest or the deb depends .*python3* ?
[00:39] <xnox> pitti: no, click manifest is either current (naked -> means python2) or has "autopilot_dir" key with the path to tests inside the branch.
[00:39] <pitti> the only thing which I'm absolutely and firmly against is to put the python3 autopilot modules into python-autopilot together with the py2 modules
[00:40] <pitti> xnox: yes; I mean, we need a corresponding metadata check for .deb packages, like dialer-app-autopilot
[00:40] <xnox> pitti: apart from based on the flags in click manifest, phablet-test-run will fetch python2 or python3 tests into different paths. Then for python3 and python2 a different pythonpath is set and re-exec does the magic.
[00:40] <pitti> but that's just Depends:.*python3* IMHO
[00:40] <xnox> pitti: for debs it's different.
[00:41] <xnox> pitti: as debs tests already encode which python version they are for inside the deb, so we similarly extract them into python2 or python3 pythonpath by phablet-test-run.
[00:41] <pitti> xnox: ah right, those would trigger the import error for py3
[00:41] <xnox> pitti: exactly =)
[00:42] <xnox> pitti: pitti: there is no need for two /usr/bin/autopilot binaries as during _transition_ period we can force a given python version with: /usr/bin/python2 /usr/bin/autopilot
[00:42] <pitti> xnox: so if we can assume p-t-r and that it can always tell whether the test runs py2 or py3, the p-t-r could just call /usr/bin/autopilot or /usr/bin/autopilot-py3
[00:42] <pitti> that's the most straightforward and explicit way
[00:42] <xnox> pitti: also, i don't understand the fetish about using a different binary package, cause that just forces people to do pointless uploads to depend one or the other package name.
[00:42] <pitti> if you really prefer the re-exec hack, that would do as well, and while I don't particularly like it I don't veto it
[00:43] <xnox> pitti: re-exec hack is best imho, as that will push python3 modules off the image quicker.
[00:43] <pitti> how so?
[00:43] <xnox> pitti: and requires less reuploads.
[00:43] <pitti> p-t-r could just explicitly call ap-py3 or ap-py2
[00:44] <pitti> because it knows which py version the test wants
[00:44] <xnox> pitti: it's the same script.... autogenerated entry point.
[00:44] <xnox> pitti: it's a relly like "dash" vs "bash" autopilot entry point is the same, and we want python3 to be the default and will drop python2.
[00:44] <pitti> no, it should have a python3 hashbang
[00:45] <xnox> pitti: and with re-exec it does, and is called "/usr/bin/autopilot" and really do not want to end up with "/usr/bin/autopilot-py3" forever.
[00:45] <pitti> and it does
[00:46] <pitti> xnox: yes, that's why I said I'm okay with the reexec hack, if people object to the autopilot3 name
[00:46] <xnox> pitti: the python2 and python3 versions of the script are the same, thus "/usr/bin/python2 /usr/bin/autopilot" is equivalent to the current python2 autopilot.
[00:46] <pitti> we'd need to divert /usr/bin/autopilot in python3-autopilot
[00:46] <xnox> with re-exec hack, it's just transparent.
[00:46] <pitti> and drop the autogenerated entry point and replace it wit ha simple shell script
[00:46] <xnox> pitti: well, that's why we merged the two into a single package ;-) no need to divert things.
[00:46] <pitti> but that's not too complicated
[00:47] <pitti> and I'm certainly willing to do that
[00:47] <xnox> pitti: please no shell...
[00:47] <pitti> xnox: no, no, no, no
[00:47] <pitti> merging the two into one will forever commit us to supporting ap-py2
[00:47] <pitti> I want to drop python-autopilot after all tests get ported
[00:47] <pitti> and ported packaged tests will change their dep to python3-autopilot
[00:48] <xnox> pitti: i don't want to (a) encode /usr/bin/python3 (b) encode Depends: python3-autopilot (c) upload all of that (d) drop python2 autopilot (e) rencode s/autopilot-3/autopilot (f) reencode Depends:autopilot
[00:48] <pitti> so we can simply measure which tests got ported, and we never break packages which still need python-autopilot
[00:48] <xnox> pitti: we don't break any tests with my plan and have 3 transition steps instead of 5.
[00:48] <pitti> *shrug*, if we want to assume that at no point we break anything existing that's what we have to do
[00:48] <pitti> we need to upload the packages anyway to fix the tests
[00:49] <xnox> pitti: as long as people use phablet-test-run to execute the tests (be it deb, or click)
[00:49] <xnox> pitti: even longer route is to make all tests bilingual, not break anything at any point, and then drop python2 in any order....
[00:49] <pitti> I'm not willing to break upgrades, the python policy, and reverse dependencies just because we are too lazy to properly switch dependency for ported packages
[00:50] <pitti> that would be a tiny short-term benefit for long-term trouble
[00:51] <pitti> xnox: I think your reexec trick is fine, given the new assumptions; but it doesn't require this blatant "merge py2/3 modules into one binary" hack
[00:51] <xnox> pitti: what upgrades? also i don't see how python policy is violated at all.... and i don't see how we are doing anything lazy here.
[00:51] <pitti> xnox: because at some point you'd drop the py2 modules from python-autopilot, and you have no way of knowing which rdepends of python-autopilot still expect py2, and which only py3
[00:51] <xnox> pitti: sure you can have modules in any package. but imho autopilot is an app, and should have it's module in the same binary package.
[00:51] <xnox> pitti: and ideally like ship them in /usr/share/autopilot/ anyway =)))))
[00:52] <xnox> pitti: what do you think of the pyflakes package btw?
[00:52] <pitti> err, no, autopilot is not an app
[00:52] <pitti> or not only
[00:52] <pitti> it's mainly a python API
[00:52] <xnox> pitti: i really did not want the world to do: Depends: pyflakes, pyflakes3, just because they started to support python3.
[00:53] <pitti> xnox: "pyflakes3" makes no sense indeed, as that's just a program
[00:53] <pitti> python3-pyflakes would be required if applications would do "import pyflakes"
[00:53] <xnox> pitti: it's only executable under autopilot binary controlled environment and it's users are private plugins. It's no different from e.g. bzr and bzr plugins.
[00:53] <pitti> err, no
[00:53] <xnox> pitti: i have at least 3 reverse-dependencies that import public pyflakes modules and do further or less processing.
[00:54] <xnox> pitti: and i don't see how I violate any of the python policy.
[00:54] <pitti> xnox: oh, you mean pyflakes, not ap
[00:54] <pitti> xnox: if pyflakes has a public python module API, then you need a python3-pyflakes
[00:54] <xnox> pitti: the only bit that i probably violate is python modules team naming scheme.
[00:54] <xnox> pitti: i don't /need/ it, i just need to have it.
[00:55] <pitti> xnox: the difference of pyflakes to ap is that pyflakes is only a CLI program and that the fact that it is written in python is an internal implementation detail
[00:55] <xnox> pitti: i mean if ubuntu ever decides to drop python2 from main into universe, a split is welcome. Otherwise it's been absolutely pointless, especially for all the bilingual moudles.
[00:55] <pitti> but this is not the case with ap
[00:55] <pitti> it has a public user-facing python API
[00:55] <pitti> it's not pointless
[00:56] <xnox> pitti: it doesn't. the only way to use autopilot modules is by executing them through /usr/bin/autopilot and have that eventually setup environment and import your modules.
[00:56] <pitti> you can't just randomly break reverse dependencies which expect python-ap to ship what it says on the tin: the python2 ap module
[00:56] <pitti> xnox: no, you misunderstand that
[00:56] <xnox> pitti: how does one write something that import autopilot and does something useful which is not a test script?
[00:56] <pitti> xnox: all ap tests do "import autopilot"
[00:56] <xnox> pitti: yes, but it's not "python -m my_test_module" it's "autopilot my_test_script"
[00:57] <pitti> ap also has that /usr/bin/autopilot test runner (which is a CLI), but it has a public API
[00:57] <xnox> pitti: at no time those tests that do "import autopilot" can do anything useful by themself.
[00:57] <xnox> without the one and only /usr/bin/autopilot test runner.
[00:57] <pitti> sure
[00:57] <pitti> but we don't know whether the tests are py2 or py3
[00:57] <xnox> pitti: autopilot broke it's api and moved to 1.4 without renaming =)
[00:57] <pitti> and we don't control them all
[00:58] <xnox> pitti: which it should have done, if I go by your "it's public api" ditto like cherrypy2 / cherrypy3
[00:58] <pitti> it's the exact same reason why we have python3-apt, python3-pycurl, and what not
[00:58] <xnox> pitti: and at the moment we do control all autopilot tests out there.
[00:58] <pitti> xnox: err, no, we don't
[00:58] <xnox> pitti: python3-apt / pycurl is different.
[00:59] <pitti> we've shipped autopilot for a long time as ubuntu package, we don't know how people use it aside from our packaged tests
[00:59] <xnox> pitti: then how did we broke and removed 1.3 api, if we don't control all fo them?!
[00:59] <pitti> e. g. we use it in the ubiquity tests
[00:59] <pitti> which just live in a branch somewhere
[00:59] <xnox> pitti: and we control ubiquity tests, it's in lp:ubiquity.
[00:59] <pitti> xnox: I never said that I thought that was a good idea
[01:00] <pitti> xnox: no, not these; I mean the ubiquity autopilot tests
[01:00] <pitti> but anyway
[01:00] <xnox> pitti: ubiquity autopilot tests are long merged into lp:ubiquity and jenkins is running them off lp:ubiquity...
[01:00] <pitti> I consider python-ap to be like python-apt or python-pycurl etc.
[01:01] <pitti> xnox: ok, fine; it was just an example
[01:01] <pitti> but there is a reason why we have separeate python3-* binaries in the archive, and that applies to ap as well
[01:01] <pitti> and I see absolutely no reason why we should cause this long-term trouble
[01:01] <pitti> we just flip the dependencies if we port a test, that takes like 2 seconds
[01:02] <xnox> pitti: i agree there is a reason, i don't see a reason for ap though given that i thought the plan is to drop python2-ap and keeping "python3" in the name (or any abbriviation of thereoff) is a historical mistake =)
[01:02] <pitti> and then we can clearly see what stuff is still using py2 by checking the rdepdns of python-autopilot
[01:02] <pitti> how is it a historical mistake?
[01:02] <pitti> python3 is a different programming language than python 2
[01:02] <xnox> for debs we inspect content, for clicks look at manifest. it's clear.
[01:03] <xnox> if deb is depends on python-autopilot -> not ported, depends on autopilot ported.
[01:03] <xnox> clicks no autopilot_dir key -> not ported, with autopilot_dir key -> ported.
[01:04] <xnox> pitti: under your naming scheme how or when are you going to drop "autopilot-py3" and just make it "autopilot" (shebang python3)
[01:04] <xnox> ?
[01:04] <pitti> seriously, that policy was made to provide a safe solution which works
[01:04] <pitti> I don't see how it helps to arguing about it for hours and spending lots of time to check that we didn't break everything when we can just effing change depends: to python3-ap for ported tests in 2 seconds and know that it's right
[01:04] <pitti> xnox: I thought we wanted to do that right now, with your reexec trick?
[01:04] <xnox> pitti: yes. hence python3-ap is pointless with reexec.
[01:04] <pitti> (and keep autopilot3 as a compat symlink)
[01:05] <pitti> well, python-autopilot keeps /u/b/a as we have it today
[01:05] <xnox> pitti: so you want policy compliant binary package names with re-exec hack?
[01:05] <pitti> python3-autopilot diverts that and replaces it with a python3 hashbang
[01:05] <xnox> (e.g. python3-autopilot owns /u/b/a which does re-exec if it needs to)
[01:05] <pitti> the reexec trick will then run it as py2 if import with py3 fails
[01:06] <pitti> it's ugly and non-explicit in my taste, but it works and I'm ok with that
[01:06] <xnox> pitti: divert -> ok.
[01:06] <xnox> pitti: do diverts work ahead of other package installation?! (thinking about it, they must)
[01:06] <pitti> xnox: yes, they do
[01:07] <xnox> (e.g. install python3-autopilot first, and maybe later python-autopilot)
[01:07] <xnox> pitti: ok.
[01:07] <pitti> xnox: i. e. you can install py3-ap, it installs the diversion
[01:07] <xnox> cool.
[01:07] <pitti> and then you install py-ap, dpkg will install its /u/b/ap into the diverted location
[01:07] <xnox> pitti: ok then packaging will be sane and easy + divert.
[01:07] <pitti> same the other way round
[01:07] <xnox> + reexec
[01:10] <pitti> xnox: yes, it would in both cases be the same autogenerated script, just with diversion instead of rename to autopilot3
[01:10] <pitti> we then need the reexec trick
[01:10] <xnox> pitti: exellent.
[01:11] <pitti> but we have the code for that in barry's branch
[01:17] <xnox> correct.
[02:18] <robert_ancell> cjwatson, slangasek or others, can you get https://launchpad.net/ubuntu/+source/gnome-session/3.9.90-0ubuntu8/+build/5618671 out of the NEW queue? We need to split the old gnome-session binary into gnome-session and ubuntu-session. Also, will that automatically be in main?
[02:22] <robert_ancell> RAOF, your in ~archive-admin but not an archive admin suitable for that right?
[02:23] <RAOF> robert_ancell: Correct. I only NEW packages which are X-SRUish (so, things like the nvidia-drivers-34234234245234134-updates et al)
[02:23] <robert_ancell> RAOF, know any archive admins who are awake by any chance?
[03:17] <slangasek> E: base-files: file-in-etc-not-marked-as-conffile etc/legal
[03:17] <slangasek> grr, we really ought to force that package to use debhelper
[03:19] <StevenK> slangasek: Santiago is still allergic?
[03:19] <slangasek> apparently?
[03:20] <StevenK> I don't get why he is so against it, but hey, it's his battle.
[03:21] <slangasek> well, and then people keep modifying the package in Ubuntu and adding new files under /etc, not realizing there's an additional manual step
[03:21] <infinity> Yeah, I had to clean that up with os-release ages ago.
[03:21] <StevenK> slangasek: Perhaps we need the build to fail in that case. Or we could just accidently switch to debhelper
[03:21] <infinity> Luckily caught it before it was a big issue.
[03:22] <slangasek> infinity: yeah, apparently we've gone since karmic without anyone ever reading the lintian output on the binary packages on base-files?
[03:22] <infinity> slangasek: Seems plausible.
[03:22] <infinity> I only noticed it with os-release, cause that's a file that actually changes on upgrade.
[03:22]  * slangasek nods
[03:24] <infinity> Hey, shiny, eglibc 2.19 passed the testsuite on amd64 and ppc64el.  Should probably slam it at a PPA to check the other arches, and then slide it in right before FF. :P
[03:25] <infinity> Except that dinner made me too fat to think.
[03:25] <slangasek> infinity: and regression-testing it in ubuntu-emulator too, right?
[03:25] <infinity> I think my stomach is actually putting pressure on my brain somehow.
[03:25]  * slangasek gives infinity a spinal tap to release the pressure
[03:25] <infinity> slangasek: Are there destructions somewhere on how to do that?
[03:26] <slangasek> infinity: https://wiki.ubuntu.com/Touch/Emulator
[03:27] <slangasek> not sure if we should be worrying about an autopilot run, or if smoke testing is sufficient... you probably have a better feel for the 2.18->2.19 delta than I do, to answer that
[03:27] <infinity> "The terminal will start an Ubuntu console by default, which can be used as any virtual console. Just be aware that hiiting Control + C will stop the emulator."
[03:27] <infinity> Sliiiick.
[03:28] <slangasek> yeah, qemu+stupidjobcontroltricks
[03:29] <infinity> Sounds like someone just needs to use saner console redirection defaults.
[03:29] <slangasek> mm?
[03:29] <infinity> But anyhow... Let's see if I can make this all go after I get a PPA build running.
[03:29] <slangasek> ok
[03:37] <infinity> 1 new private symbol, 0 new public symbols.  Looks sane.
[03:38] <slangasek> oh for the love of makefiles
[03:38] <infinity> Also, why am I hungry?  I think my brain is broken.
[03:38] <infinity> Sitting here unable to move, and thinking "yeah, I could really go for a snack."
[03:39] <slangasek> yes, base-files, perfectly reasonable that I should have to also remember to manually install debian/postrm
[03:39] <infinity> You're adding a postrm?
[03:39] <slangasek> yes, dpkg-maintscript-helper
[03:39] <infinity> To do the conffile migration?
[03:39] <slangasek> to do a conffile removal
[03:40] <infinity> rm_if_matches_md5sum
[03:40] <infinity> See: http://launchpadlibrarian.net/120844030/base-files_6.5ubuntu6.3_6.5ubuntu6.4.diff.gz
[03:40] <infinity> slangasek: I'm a fan of sticking with the way the package already handles this case.
[03:41] <slangasek> yes, and I prefer full policy compliance. :)
[03:42] <infinity> Mixed methods just seem icky.  I'm all for submitting a patch to Debian to change all of those bits to maintscript-helper, but just one seems odd.
[03:42] <slangasek> it's just the one because it's an Ubuntu-specific file being removed
[03:42] <slangasek> so post-trusty the delta can drop out again
[03:42] <infinity> Kay.  Still would make sense to me to just use the same method, s'all.
[03:43] <infinity> Smaller delta, more obviously readable in context, no new maintainer scripts, etc.
[03:43] <slangasek> except that method is buggy, and I have no intention of fixing the bugs in it by hand
[03:43] <slangasek> in fact, fixing the bugs in it requires adding a postrm anyway
[03:43] <infinity> True.
[03:44] <infinity> Though, this is only true for the rollback case, I'm not sure how much I'd care (I obviously didn't when I did os-release, but whatever)
[03:44] <infinity> I suspect you have bigger issues if your system is so broken that base-files fails to upgrade and needs to abort/unwind.
[04:16] <hallyn> pitti: stgraber: rbasak: rharper:  I'm sure there are problems left with it, but I opened https://code.launchpad.net/~serge-hallyn/auto-upgrade-testing/uvtool/+merge/207350  (managed to do a full adt run with it)
[04:30] <infinity> pitti: How do we completely flush an arch from ddebs so we can re-retrieve it?
[05:24] <inahandizha> http://VisitsToMoney.com/index.php?refId=386970
[06:47] <dholbach> good morning
[06:50] <dholbach> @pilot in
[06:57] <Noskcaj> dholbach, Could you look at some merges for xubuntu please?
[06:58] <Noskcaj> https://code.launchpad.net/~noskcaj/ubuntu/trusty/xfce4-panel/4.11/+merge/206601 is probably the highest priority
[07:00] <dholbach> Noskcaj, yes
[07:00] <Noskcaj> thanks
[07:23] <Noskcaj> slangasek, bug 1280109
[07:57] <Noskcaj> dholbach, What's the text conflict? I didn't have that issue
[07:58] <dholbach> Noskcaj, http://paste.ubuntu.com/6964186/
[07:59] <Noskcaj> Could you try just resolving it locally? I think just take the new version, since it's an upstream change
[08:02] <ochosi> Noskcaj: wait
[08:03] <ochosi> those are our default settings, please don't mess with those
[08:03] <Noskcaj> ok, could you check the changes then
[08:03] <ochosi> link?
[08:03] <ochosi> or is it only the conflict that was pastebinned?
[08:04] <dholbach> ochosi, that's only the conflict
[08:04] <dholbach> Noskcaj, to me it looks like the updated debian/patches/shimmer-layouts patch might have caused a bit of headache
[08:05] <ochosi> yes, i think we should get rid of that debian patch, just haven't had the time to deal with that :/
[08:05] <Noskcaj> ochosi, It's in debian, but i'm one of the maintainers there if you need a change
[08:06] <dholbach> ochosi, Noskcaj: can you work together to agree on something?
[08:06] <ochosi> dholbach: so, the "PLUGIN_AUTOSAVE: 1" can go in as an upstream change, it's a plugin that automatically saves tags every 15mins, so we want that
[08:06] <dholbach> I'll leave it to you
[08:06] <Noskcaj> ok
[08:06] <Noskcaj> sponsor indicator now please?
[08:06] <dholbach> I'm not an expert - if you agree on what to put in there, test it and tell me it's good to go, I'm happy to sponsor it
[08:07] <dholbach> Noskcaj, one after the other - when I tried to build it 5m ago the panel build-dep wasn't in the archive yet
[08:07] <ochosi> yeah, but simply dropping the debian-patch will potentially result in a lot of work, i didn't mean we should do that now
[08:07] <Noskcaj> dholbach, Oh yeah, forgot that
[08:07] <ochosi> i meant: i'll work with upstream to get these patches in so that you can get rid of the patch
[08:07] <dholbach> ochosi, Noskcaj: can you update the MP once you resolved the issue and agreed on a way forward?
[08:08] <Noskcaj> yep
[08:08] <dholbach> thanks guys
[08:08] <ochosi> thank you dholbach!
[08:09] <ochosi> dholbach: btw, Laney advised me to also try bugreports/MR like the xubuntu-default-settings one, i'm not very experienced in this though, so just let me know if i messed up
[08:11] <robert_ancell> slangasek, hey, gnome-session depended on ubuntu-session in case people didn't have ubuntu-desktop installed. These people will potentially have no session installed after upgrading to the new gnome-session binary. So, you can be on "sudo apt-get install ubuntu-desktop" reminding for them :)
[08:28] <infinity> robert_ancell: Wouldn't it make more sense to have something like unity pull it in, if it's specific to ubuntu-desktop and not needed for GNOME?
[08:28] <robert_ancell> infinity, yeah, we're doing that too, but that one takes longer to land
[08:28] <robert_ancell> LSMSGCV: You just sent an email to
[08:28] <robert_ancell> https://code.launchpad.net/~robert-ancell/unity/ubuntu-session/+merge/207346
[08:28] <robert_ancell> wrong paste buffer there
[08:29] <robert_ancell> infinity, so we'll just have a day or two where things could go wrong. I sent an email to ubuntu-devel to give people a heads up
[08:30] <infinity> robert_ancell: Alright, so you intend to drop that dep as soon as unity is pulling it in, I guess?
[08:30] <infinity> robert_ancell: That works.
[08:30] <robert_ancell> yeah
[09:02] <dholbach> Noskcaj, ochosi: I'm not quite sure I understand https://bugs.launchpad.net/ubuntu/+source/xubuntu-default-settings/+bug/1282154 - there are a lot of branches for the same package - some of the MPs are approved, some are not - what exactly requires uploading? can you make sure all those branches are merged somewhere and you just propose one thing to be sponsored?
[09:02] <ochosi> dholbach: the problem is that currently the devs who can merge to those branches are a bit MIA
[09:03] <ochosi> so we cannot merge anything to xubuntu-default-settings ourselves
[09:04] <ochosi> and the ppl whose review is still pending are those who could merge
[09:04] <Laney> ochosi: you could merge into one branch yourself and ask for that to be sponsored
[09:04] <seb128> shrug, daily CD build failed again on checkbox depends things
[09:04] <Noskcaj> The other solution is i get my upload rights (and as a result get the push rights), but that's take 50 days now
[09:05] <Noskcaj> *taken
[09:05] <ochosi> Laney: sure, that's no problem, it has just evolved that way as separate MRs and i thought it should be kept that way
[09:05] <ochosi> i'll try to take care of it asap and update that bugreport then
[09:05] <dholbach> thanks ochosi
[09:05] <ochosi> no problem, should i ping you again after the merges dholbach ?
[09:05] <dholbach> ochosi, thanks - that'll make review a lot easier
[09:06] <dholbach> yep, sounds good
[09:06] <ochosi> thanks dholbach
[09:08] <Laney> seb128: component-mismatches
[09:09] <seb128> Laney, yeah, 2 days in a row
[09:10] <Laney> you have the power!
[09:10] <seb128> right, looking at it
[09:32] <seb128> Laney, I promoted python3-plainbox, how do we get CD builds retried once the promotion is published?
[09:32]  * Laney can do that
[09:43] <ochosi> dholbach: ok, i've merged the different ones into a single merge-request, is it ok like this? https://code.launchpad.net/~ochosi/xubuntu-default-settings/trusty-updates/+merge/207376
[09:44] <dholbach> ochosi, did you test build it and see if the settings all work as expected?
[09:44] <dholbach> I'll take a look in a sec
[09:44] <ochosi> for the merge-requests that i originally did, yes
[09:45] <ochosi> i'm not really a packager, so i can't judge the changes of rev464 tbh
[09:46] <dholbach> hum
[09:46] <dholbach> anyone else from the Xubuntu crowd in here?
[09:46] <ochosi> rev463 was tested, but not by me :/
[09:46] <ochosi> i think Noskcaj had to take off, but bluesabre might be around in an hour or two
[09:47] <dholbach> I'll review it as good as I can and put up test packages somewhere - could you ask a few xubuntu folks who are on trusty if they can test them?
[09:47] <dholbach> I don't have a xubuntu installation around to test it
[09:48] <dholbach> test packages are up at http://people.canonical.com/~dholbach/tmp/xubuntu/
[09:48] <ochosi> thanks, that's very kind of you!
[09:48] <ochosi> i'll test myself (i'm on trusty) and ask our testers too
[09:49] <ochosi> and wow, that was quick :)
[09:49] <dholbach> rock on
[09:56] <infinity> pitti: *nudge*
[09:56] <dholbach> ochosi, it looks like all the changes were merged into the branch successfully - let me know how the testing goes
[09:57] <seb128> infinity, he's in Oakland, so probably not going to be online before a few hours
[09:58] <infinity> seb128: Ahh.  And here I was, waiting up for him. ;)
[10:01] <ochosi> dholbach: quick question, why would the greeter.conf file from rev462 end up as "lightdm-gtk-greeter.conf.dpkg-dist"?
[10:02] <ochosi> (i installed your package)
[10:06] <dholbach> ochosi, do you still have the installation log? did you do local modifications to ./etc/xdg/xdg-xubuntu/lightdm/lightdm-gtk-greeter.conf?
[10:07] <dholbach> the package just ships /etc/xdg/xdg-xubuntu/lightdm/lightdm-gtk-greeter.conf but depending on what your local configuration looked like (local changes), it might be moved to dpkg-dist
[10:07] <dholbach> you can diff the two files to see which differences there actually were
[10:08] <ochosi> i used software center and i don't see any logs there
[10:08] <dholbach> check /var/log/apt
[10:10] <ochosi> yeah, nothing in the history or term.log
[10:10] <ochosi> somehow ubuntu-software-center didn't write/keep any logs it seems
[10:11] <ochosi> the .conf file is what was there before, the .dpkg-dist file has the changes done in rev462
[10:11] <ochosi> i can downgrade the package, remove the dpkg-dist file and try to install with dpkg again if you think that'd help
[10:12] <dholbach> yes, you could try that
[10:12] <dholbach> and see what the other testers say as well
[10:12] <seb128> Laney,  python3-plainbox | 0.4-4 | trusty | all
[10:12] <seb128> Laney, can you retry the iso build?
[10:12] <Laney> yup, thanks
[10:13] <ochosi> dholbach: will do, thanks. so far i've tested the changes from rev 459, 460, 461 from your package (they all work)
[10:13] <seb128> Laney, thanks
[10:14] <seb128> Laney, can I see the build logs live somewhere or is that just "wait on an error email or an iso to be published"?
[10:14] <dholbach> ochosi, I'll do a few other things now, but let me know when you and others concluded your testing and I'll go and upload (and update the branch)
[10:14] <dholbach> thanks
[10:14] <Laney> seb128: yeah, not live - they're copied out after the build is done
[10:14] <Laney> to http://people.canonical.com/~ubuntu-archive/livefs-build-logs/trusty/ubuntu/latest/ and emailed
[10:15] <seb128> ok, thanks
[10:18] <ochosi> dholbach: just fyi, seems like software-center generated the dpkg-dist file. synaptic asks you what to do (keep old version or replace with pkg-maintainer-version) and "dpkg -i" just overwrites the old config. so rev 462 is actually ok...
[10:19] <ochosi> and yeah, will leave you to do other things until i've got more tester-feedback. thanks again! :)
[10:22] <rbasak> Almost done with this mini-php transition. Just three packages left, but need some help here please. Can someone sponsor a no change rebuild for graphviz and redland-bindings for me? And I think ffmpeg-php needs to go - it FTBFS already for porting reasons (seems non-trivial, and already removed from jessie), and is blocking the transition.
[10:31] <doko_> Sweetshark, when do you plan your next lo upload?
[10:37] <Sweetshark> doko_: libreoffice/libreoffice-l10n today if possible for there are urgent upstream fixes in that release.
[10:37] <doko_> ok, thanks. just wan to have it built with python3.4 as the default
[10:37] <Sweetshark> doko_: FWIW I saw your nlpsolver ping, will try to look into it still this week (together with other stuff in that package)
[10:47] <dholbach> @pilot out
[10:48] <Laney> seb128: the build worked
[10:48] <seb128> Laney, \o/
[10:50] <seb128> Laney, the results are not copied yet though?
[10:50] <Laney> I think that happens once per hour
[10:50] <seb128> ok
[10:50] <seb128> seems http://cdimage.ubuntu.com/daily-live/current/trusty-desktop-amd64+mac.manifest is updated
[10:51] <seb128> good, gnome-control-center dropped from the default install, I was after that for some days
[10:51] <seb128> there was a recommends left in gnome-bluetooth that I fixed tuesday, seems that did it
[10:51] <Laney> cool
[10:51] <Laney> got to get gsd out now
[10:51] <seb128> yeah, I'm looking at that
[10:53] <Laney> might just be totem-plugins
[10:53] <seb128> seems to be
[10:53]  * seb128 fixes that
[10:53] <Laney> let me
[10:53] <Laney> oh, ok!
[10:53] <seb128> ok
[10:53] <Laney> who? :P
[10:54] <seb128> Laney, if you want to do it, please do
[10:54] <seb128> I've enough landings I want to push through to keep busy
[10:54] <Laney> ok
[10:54] <seb128> thanks
[10:56] <seb128> Laney, if you are not done yet, can you look at the patch on https://bugs.launchpad.net/ubuntu/+source/totem/+bug/1264547 while you are at it?
[11:01] <Laney> okay
[11:01] <seb128> thanks
[11:01] <seb128> infinity, still around?
[11:02] <seb128> is it fine to copy from https://launchpad.net/~canonical-libreoffice-builds/+archive/archive-staging to the trusty archive including binaries?
[11:02] <seb128> or should we do a source copy instead?
[11:02] <seb128> Sweetshark, ^
[11:05] <infinity> seb128: I have no idea how that PPA is configured, but probably not fine, no.
[11:05] <seb128> infinity, https://answers.launchpad.net/launchpad/+question/243446 if that helps
[11:06] <seb128> infinity, it's supposed to be security updates friendly, so it should be archive friendly as well?
[11:06] <seb128> wgrant, ^?
[11:07] <infinity> seb128: Ahh, well, if it's "security-friendly", that would also mean that post-release pockets are turned off, which is devel-release hostile. :)
[11:07] <wgrant> seb128, infinity: That PPA is a nonvirt and all archs, and no weird deps, so I don't really see a problem.
[11:08] <infinity> wgrant: Does it also have all the right toggles on/off for a copyable archive with ddebs published to apache, etc? (see the kernel or security PPAs as examples)
[11:08] <wgrant> infinity: Yes, that's just the nonvirt flag.
[11:08] <wgrant> (totally insane, but true)
[11:09] <infinity> wgrant: Right, I always forget and have to look at the ckt one.  So, build ddebs and publish ddebs both need to be off.  And then it builds ddebs. :P
[11:09] <infinity> (So confusing)
[11:09] <wgrant> Yup
[11:09] <wgrant> The build ddebs flag puts them in the .changes
[11:09] <wgrant> The publish ddebs flag additionally puts them in main/debug
[11:10] <wgrant> With neither they'll just end up in Apache
[11:10] <wgrant> (ew)
[11:10] <infinity> To be security-friendly, it should also be set to build only against -security, of course.
[11:10] <infinity> Which I still maintain is devel-hostile.
[11:10] <wgrant> devel-hostile if there's a transition in -proposed, indeed.
[11:10] <infinity> There are always transitions in proposed. :P
[11:14] <infinity> seb128: Meh, just copy out the source.  If there's a transition it'll hang up on, I'd rather it get hung up and dealt with properly.  Unless there's some urgent reason we need it built right this instant.
[11:16] <infinity> PPAs are cheap.  If we want to have one for libreoffice-devel and one for libreoffice-security, we should just do that.
[11:16] <infinity> s/devel/proposed/
[11:16] <infinity> Since it would also be fine for staging non-security SRUs.
[11:16] <Sweetshark> infinity, seb128: This build is not urgent. Im essentially smoketesting this workflow, so that we _dont_ have these discussions _when_ its urgent.
[11:17] <infinity> Sweetshark: Right, so I'd recommend a second PPA, so we're doing things "right".
[11:17] <seb128> infinity, ok, I'm fine with source copy, I was just trying to spare some buildds cycles
[11:17] <infinity> Sweetshark: a libreoffice-proposed that builds against all pockets for devel releases and SRUs, and a libreoffice-security that's used to stage security releases.
[11:18] <infinity> And sane component mapping, but I assume wgrant did that last time he set this up.
[11:18] <Laney> seb128: do you remember what this recommends is for?
[11:18] <wgrant> infinity: I can't actual twiddle that bit on others' PPAs, but the owner can.
[11:18] <infinity> Of course, with libreoffice constantly adding/removing language packages, this will run into the same skips-binary-new-and-lands-in-universe bug that kernels have. :(
[11:19] <seb128> Laney, the g-s-d one?
[11:19] <infinity> wgrant: Oh, I assumed commercial admins saw all those twiddles.  You're not actually all-powerful? :)
[11:19] <Laney> yeah
[11:19] <Sweetshark> infinity: understood (with the two ppas).
[11:20] <wgrant> infinity: No, it's deliberately restricted to making changes that normal users shouldn't be able to make
[11:21] <wgrant> infinity: (and also it lets you opt into seeing just about anything, but that's for debugging/support without invoking IS...)
[11:21] <infinity> Sweetshark: You'll also need to set up the +edit-dependencies page for each.  One to use "security" and one to use "proposed", and then also set the "Ubuntu components" section to "Use the same components used for each source in the Ubuntu primary archive".
[11:21] <wgrant> But write operations are pretty much restricted to heavily privileged bits.
[11:21] <seb128> Laney, hum, not really, I guess it has to do with multimedia keys, eg https://bugzilla.gnome.org/show_bug.cgi?id=509438
[11:22] <Sweetshark> infinity: right
[11:23] <seb128> Laney,
[11:23] <seb128> src/plugins/media-player-keys/totem-media-player-keys.c:			       "org.gnome.SettingsDaemon",
[11:24] <Laney> but with G_DBUS_PROXY_FLAGS_DO_NOT_AUTO_START
[11:25] <seb128> Laney, right, well it has integration with g-s-d so it recommends it I guess
[11:25] <seb128> you can do that u-s-d | g-s-d
[11:25] <seb128> or drop it
[11:25] <seb128> I don't think it's very useful
[11:25] <Laney> I think I will drop it
[11:25] <Laney> ta
[11:25] <seb128> yw
[11:25] <seb128> that makes sense
[11:26] <seb128> having desktop integration doesn't mean it should recommends/pull in the desktop it integrates with
[11:30] <zequence> Would anyone like to sponsor this upload, please? It's a ubiquity plugin for Ubuntu Studio. Bug: 946591
[12:08] <bluesabre2> dholbach, ochosi: I can verify each of the fixes from http://people.canonical.com/~dholbach/tmp/xubuntu/
[12:08] <bluesabre2> https://code.launchpad.net/~ochosi/xubuntu-default-settings/trusty-updates/+merge/207376
[12:47] <doko> rbasak, I'm looking at http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt  (end of page). Any hint about the failing ones?
[12:47] <codfather> A quick question about SPICE support in 14.04 - is it going to be improved over that which was provided with 12.04?
[12:48] <rbasak> doko: graphviz and redland-bindings presumably just need no change rebuilds - I don't have permission to upload them.
[12:48] <rbasak> doko: ffmpeg-php looks more involved, since it already FTBFS. I think we should drop it from Trusty (it's been dropped from jessie)
[12:49] <rbasak> doko: zeroc-ice I've rebuilt, but it seems to be a build issue that drops the LFS support. I haven't looked into it in detail yet.
[12:49] <doko> rbasak, but why the rebuild at all? the php-api didn't check
[12:49] <doko> rbasak, yes, removing the ruby1.8 zeroc binary
[12:50] <rbasak> doko: on i386, php5-common used to provide phpapi-20121212. Now it provides phpapi-20121212-lfs instead.
[12:50] <doko> ahh, ok. then rebuilding
[12:51] <rbasak> Thanks!
[13:22] <rbasak> doko: zeroc-ice has the phpapi dependency hardcoded, instead of using dh-php5 etc. If I just change the hardcoding, is that likely to break it? LFS-ness should be defined in the header files inside php5-dev, right? Or do I need to make sure that the macro definitions are usied during the build (which I think they aren't)?
[13:23] <doko> rbasak, no clue ... only did fix the python3 issues in this package
[13:25] <rbasak> OK, I'll dig deeper.
[13:58] <dholbach> thanks bluesabre2
[13:59] <dholbach> ochosi, bluesabre2: uploaded
[14:00] <doko> rbasak, demoted ffmpeg-php, zeroc-ice should be the last one
[14:00] <ogra_> oh my ...
[14:00] <ogra_> systemd just swallowed network-manager
[14:03] <doko> jtaylor, are you working on the qhull transition?
[14:17] <ochosi> dholbach: thanks a lot!
[14:18] <dholbach> ochosi, keep up the good work!
[14:18] <ochosi> dholbach: will try to, in fact our seed also has a few merge-requests... :)
[14:18] <dholbach> ochosi, I need to take care of a few other things now - I hope you can find somebody else in here who can help out now
[14:19] <ochosi> dholbach: sure thing, thanks a lot for all you've done!
[14:19] <ochosi> i know it wasn't very convenient sponsoring
[14:19] <dholbach> anytime :)
[14:19] <dholbach> no no, it was all right
[14:20] <ochosi> ok, well thanks anyway :)
[14:28] <shadeslayer> pitti_: ping
[14:29] <shadeslayer> pitti_: thoughts on : https://bugs.launchpad.net/ubuntu/+source/kubuntu-notification-helper/+bug/1282095 : do you think "Proprietary drivers might be required to enable additional features" will work?
[14:38] <mardy> cjwatson: hi! I've got a difficult question about click, please ping me back when you have a minute :-)
[14:40] <hallyn> slangasek: good morning - bug https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=734633 (which i mentioned in london) hasn't yet been addressed :(
[14:40] <hallyn> did you ever hear back from the maintainer?
[14:41] <hallyn> i'd sort of like to have it in trusty...
[14:44] <cjwatson> mardy: ok
[14:53] <cyphermox> ogra_: no, systemd just got some rewritten chunks to do... bridging, or whatever
[14:53] <ogra_> well, matter of time i guess
[14:53] <cyphermox> not in the way that it currently is
[14:54] <xnox> ogra_: are you talking about sytemd-networkd? network-manager maintainer at redhat is pissed off about it =)
[14:54] <cyphermox> it took years to get NM to the semi-working state it is in now
[14:54] <cyphermox> so it will take years to get systemd-network to do half of what NM does
[14:54] <ogra_> xnox, i thought so :)
[14:54] <cyphermox> so it will be years more of this kind of conversation :)
[14:55] <ogra_> xnox, next step ... sniff bash into systemd ;)
[14:55] <ogra_> cyphermox, simply copy-paste job :P
[14:55] <ogra_> *simple
[14:55] <cyphermox> ahah yeah ;)
[14:55] <cyphermox> ogra_: actually my bet is that systemd will either swallow emacs, or emacs swallow systemd
[14:56] <ogra_> that sounds liek we could end up with some kind of moebius ...
[14:56] <ogra_> if both try to swallow each other at the same time
[14:56]  * cyphermox ducks, dons asbestos vest
[14:56] <ogra_> might make the universe vanish or some such
[14:56] <cyphermox> heh
[14:57] <cyphermox> anyway, it's good that systemd does this
[14:57] <cyphermox> some kind of nice competition going on there between systemd, n-m, connman... that might lead to some pretty cool innovation
[14:58] <ogra_> heh, always thinking positive ... you are so canadian sometimes :)
[15:01] <mdeslaur_> ogra_: he's just looking for an excuse to get out of maintaining nm :)
[15:02] <ogra_> hehe
[15:23] <ogra_> pitti_, for the demo images we would like to switch off apport on the phone ... do you think there is any issue with making /etc/default/apport writable by default on the phone image ?
[15:40] <ThiagoCMC> Hello! Guys, I'm using Ubuntu 14.04 on my Desktop and, after the latest "aptitude update/safe-upgrade", Unity doesn't work anymore, only gnome-shell works now... Yes, I know it is devel branch but, I'm just curious...     =P
[15:42] <psusi> #ubuntu+1 is the support channel
[15:42] <jpds> People still use aptitude these days?
[15:45] <ThiagoCMC> jpds, what do you use ?
[15:45] <ThiagoCMC> psusi, tks!
[15:45] <jpds> ThiagoCMC: apt-get.
[15:48] <plugwash> does ubuntu have porterboxes available for packagers to debug their package's build failures on?
[15:48] <plugwash> and if so what is the procedure for getting access to them?
[15:55] <xnox> plugwash: there are no public porterboxes available.
[15:56] <xnox> plugwash: which build failure in particular do you wish to debug?
[15:56] <xnox> plugwash: if you are a dd/dm you can use debian porter boxes which should give you access to a few architectures which are present in ubuntu and are of similar environmnet.
[15:58] <plugwash> I was asking as a result of a discussion in #debian-mentors on oftc relating to the failure of hexchat on ubuntu ppc64el
[15:58] <plugwash> we suspect using dh-autoreconf would fix it but it would be nice to know such things before uploading
[15:59] <pitti_> Good morning
[16:00] <pitti_> ogra_: no, seems fine; one more brick in the wall of broken /etc :)
[16:00] <Logan_> plugwash: I can take a look - I've fixed around 100 ppc64el failures at this point
[16:01] <Logan_> plugwash: yes, we definitely need dh-autoreconf for that - do you want me to test and push a fix?
[16:01]  * sney waves
[16:02] <plugwash> Logan_, sney is the guy you was asking about the hexchat ppc64 failure over in #debian-mentors
[16:02] <Logan_> sney: hey :)
[16:02] <sney> hi
[16:03] <Logan_> so I was just telling plugwash that dh-autoreconf (or a manual libtool file update) is necessary to fix hexchat's FTBFS on ppc64el
[16:03] <Logan_> do you want me to push a fix to Ubuntu?
[16:03] <sney> sure
[16:03] <Logan_> okay one moment
[16:04] <Logan_> well, more like 10 minutes
[16:04] <Logan_> just so I can test and stuff :)
[16:05] <sney> ok, I have to shower anyway
[16:06] <ogra_> pitti_, great, thanks :)
[16:06] <pitti_> ogra_: apport never writes that by itself, so we don't need the /etc/writable/ dance for that
[16:07] <ogra_> pitti_, we need to make the file writable though ... just not the weird hack
[16:07] <pitti_> right
[16:07] <pitti_> ogra_: or, you just change the default in the image build process?
[16:07] <ogra_> pitti_, that would change it for endusers too ....
[16:08] <ogra_> we want to keep apporrt running for users
[16:08] <ogra_> just not for demo images
[16:11] <Logan_> sney, plugwash: uploaded: https://launchpad.net/ubuntu/trusty/+source/hexchat/2.9.6.1-1ubuntu1
[16:12] <Logan_> I'll forward to Debian once we're sure it fixes the FTBFS on ppc64el
[16:14] <pitti_> ogra_: I thought the demo images are different anyway (i. e. different build process)
[16:15] <xnox> Logan_: also hexchat probably needs all of my usability patches =)
[16:15] <Logan_> xnox: oh dear :P
[16:16] <ogra_> pitti_, the same images, with one extra PPA
[16:16] <Logan_> sney, plugwash: it built successfully - forwarding now
[16:16] <ogra_> pitti_, this time we actually managed to get all essential stuff into the main image ... only some demoish extras are in the PPA
[16:16] <pitti_> ogra_: so it seems the easiest would just be to upload apport to that PPA with the default file saying "disabled"?
[16:17] <ogra_> pitti_, hmm
[16:17] <ogra_> sounds like more work
[16:17] <pitti_> ogra_: as you wish, both will work; it's just impossible to ever make a file non-writable again
[16:18] <pitti_> hence uploading apport to the PPA is easier to revert
[16:18] <ogra_> its easy to make a file non writable again
[16:18] <sney> Logan_: groovy, thanks for your attention
[16:18] <ogra_> unless you used the hackish approach ;)
[16:18] <Logan_> sney: no problem, anytime :)
[16:18] <ogra_> normal files just become readonly with a new image
[16:19] <pitti_> ogra_: well, all of that is a complete hack :)
[16:19] <ogra_> nah
[16:19] <ogra_> is *design*
[16:19] <ogra_> *g*
[16:23] <pitti_> xnox: I read https://blueprints.launchpad.net/ubuntu/+spec/core-1311-python3-roadmap and that sounds good, thanks for the write-up
[16:23] <xnox> pitti_: cheers. it leaves out some implementation details.
[16:23] <pitti_> xnox: AFAIU the p-t-r MP that should still work with the simplified ap approach that we discussed yesterday, right?
[16:23] <xnox> pitti_: e.g. it doesn't matter what the binary package names / packaging of autopilot is for example.
[16:23] <pitti_> i. e. only add the reexec thing and divert /u/b/ap instead of renaming it to ap3
[16:24] <xnox> pitti_: correct. Althought, i think i failed to expand "p-t-r MP"
[16:24] <xnox> =))))
[16:24] <pitti_> xnox: https://code.launchpad.net/~xnox/phablet-tools/py2-3/+merge/205608
[16:24] <pitti_> phablet-test-run merge proposal
[16:25] <xnox> pitti_: correct, that one would still work.
[16:26] <ThiagoCMC> jpds, hey man! apt-get installed the correct packages, Unity on 14.04 working again... I'll stop using aptitude...    =)
[16:28] <ogra_> good move
[16:37] <maxiaojun> command-not-found doesn't know about ruby2.0?
[16:42] <xnox> maxiaojun: we didn't refresh command-not-found in ages.
[16:42]  * ogra_ doesnt know about ruby2.0 either 
[16:44] <maxiaojun> http://packages.ubuntu.com/trusty/ruby2.0
[16:48] <maxiaojun> xnox: how are c-n-f data generated?
[16:59] <smb> Just a quick question: is python3.4 known to currently have some Popen issues? Just saw some ignored exceptions during an upgrade,
[17:30] <zequence> Would anyone like to sponsor this new upload, please? It's a fork of edubuntu-live, and should be simple enough to review. Bug: 946591
[17:32]  * highvoltage looks at bug report
[17:34] <highvoltage> zequence: also, good choice on basing on edubuntu-live ;)
[17:34] <zequence> highvoltage: :)
[17:37] <highvoltage> zequence: I'll be happy to sponsor it, anyone else from the ubuntu studio team who could also +1 it?
[17:38] <bdmurray> my system is refusing to accept keyboard input on trusty and I've worked around this before by clicking the input method thing on the lightdm screen and then I can type.  however, I've no cursor either on this system.  Any ideas on how I can log in?
[17:40] <zequence> highvoltage: Perhaps this is enough? It's the blueprint for ubuntustudio-live https://blueprints.launchpad.net/ubuntustudio-live/+spec/ubuntustudio-live-t
[17:41] <seb128> bdmurray, try pressing the power button, it should trigger a session dialog
[17:41] <zequence> highvoltage: The team is kind of small right now, and being the project lead, I feel I can vouch for the thing
[17:41] <seb128> bdmurray, that might unblock it
[17:41] <highvoltage> zequence: ok, uploaded
[17:42] <zequence> Great :)
[17:44] <bdmurray> seb128: it raised the dialog but I can't interact with it
[17:44] <seb128> bdmurray, esc doesn't work?
[17:44] <bdmurray> seb128: no
[17:44] <bdmurray> seb128: I've tried removing usb devices and plugging them back in but that didn't help either
[17:52] <hallyn> rbasak: rharper: the --disk command in uvt-kvm create, what does it take?  a filename?
[17:53] <bdmurray> oh well my keyboard doesn't work in recovery mode so its probably something low-level
[18:07] <jtaylor> doko: re qhull yes
[18:24] <ahasenack> hi guys, I uploaded a package to trusty about an hour ago, and today is feature freeze, I'm just not sure if it means the freeze already started (0:00UTC today, then), or if today is the last day (I have until 23:59UTC)
[18:26] <pitti> barry, xnox: where does it drop the -E option in https://code.launchpad.net/~barry/autopilot/reexec/+merge/203765 ?
[18:26] <pitti> I thought it would need to do that to consider $PYTHONPATH from p-t-r after reexecing to py2
[18:27] <mlankhorst> ahasenack: see topic ;-)
[18:27] <mlankhorst> archive: open
[18:27] <ahasenack> ah, that bit
[18:27] <ahasenack> thanks!
[18:27] <ahasenack> it was uploaded to proposed, so I guess a bot will soon move it to main?
[18:27] <ahasenack> https://launchpad.net/ubuntu/trusty/+queue?queue_state=3&queue_text=landscape-client
[18:30] <barry> pitti: i think xnox was testing something else?  that branch doesn't drop the -E
[18:30] <shadeslayer> pitti: what does the jenkins instance use to run upgrade tests? LXC?
[18:31] <pitti> shadeslayer: LXC for most tests, but there are a couple of _vm tests which use a full qemu
[18:31] <pitti> shadeslayer: we want to minimize the QEMU ones, but we still need some for doing actual reboot tests
[18:31] <xnox> pitti: os.rexec only rexecs with arguments "/usr/bin/autopilot"
[18:31] <xnox> pitti: it does not re-exec with "-E"
[18:31] <shadeslayer> yofel: ^^
[18:31] <shadeslayer> pitti: we're getting these errors on our tests http://paste.ubuntu.com/6966771/
[18:32] <xnox> barry: it does, it's just not obvious =)
[18:32] <pitti> xnox: it looks like it execs "python2 sys.argv", wouldn't that include the -E?
[18:32] <xnox> pitti: no, it would not.
[18:32] <yofel> pitti: note: that ^ error happens on the first run when there's no upgrade container bootstrapped yet
[18:33] <barry> xnox: comments in the code would probably help :)
[18:33] <xnox> pitti: sys.argv only has /usr/bin/autopilot and onwards, not starting from /usr/bin/python3 -E ...
[18:33] <pitti> jibel: does http://paste.ubuntu.com/6966771/ ring a bell?
[18:33] <xnox> barry: # black magic below...
[18:33] <pitti> jibel: (from yofel/shadeslayer above)
[18:33] <xnox> barry: # end black magic?! =)
[18:33] <pitti> xnox: ah, thanks
[18:34] <ahasenack> sorry, network failed
[18:35] <jibel> pitti, shadeslayer I've never seen this before
[18:35] <pitti> yofel: is that a run on your machine, or in jenkins.q.u.c.?
[18:36] <yofel> pitti: currently on mine as we first wanted to test the profiles before mering
[18:36] <pitti> yofel: especially in saucy and earlier, LXC might need some additional tweaks for cgroups/apparmor/etc.
[18:36] <jibel> shadeslayer, can you paste your profile (DistUpgrade.cfg) , I'll try it here
[18:36] <yofel> ah, are those listed somewhere?
[18:37] <yofel> the host is saucy
[18:38] <shadeslayer> jibel: the best would be to branch lp:~kubuntu-dev/auto-upgrade-testing/auto-upgrade-testing :)
[18:42] <jibel> shadeslayer, thanks
[19:02] <ahasenack> hi, do I need to do something to move a package I uploaded to trusty ~1h ago from proposed to main, or does it happen automatically? It used to be automatic, but since today is feature freeze, i'm following closely :)
[19:05] <slangasek> feature freeze is an advisory freeze, it doesn't change anything on the archive side
[19:05] <slangasek> proposed->release pocket should all be automatic - what package?
[19:06] <slangasek> (fwiw, http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html shows the status of package migrations, but it's not the easiest to interpret)
[19:06] <ahasenack> slangasek: https://launchpad.net/ubuntu/trusty/+queue?queue_state=3&queue_text=landscape-client
[19:06] <slangasek> ahasenack: ok, the above page shows that it's waiting for arm64 to catch up
[19:07] <slangasek> but there are no obvious blockers beyond that
[19:07] <ahasenack> slangasek: I see, thanks!
[19:08] <tjaalton> slangasek: we're probably not getting new openldap from alioth git for trusty? ;)
[19:10] <slangasek> tjaalton: man... I haven't even had a chance to look at the openldap git repo yet
[19:10] <tjaalton> hehe
[19:10] <slangasek> tjaalton: I was hoping someone else would pick this up :/
[19:10] <tjaalton> right
[19:10] <tjaalton> the list has been silent, no one seems to care
[19:13] <tarpman> tjaalton: fwiw thanks for working on that... I've been watching and hoping it would make it to trusty, but too busy to contribute
[19:15] <tjaalton> tarpman: yeah I was meant to get this in first and then maybe add a separate library built against libnss.. (for 389ds) but meh
[19:16] <slangasek> tjaalton: so looking at the git repo, there don't seem to be any tags for upstream releases?
[19:17] <tjaalton> slangasek: oh you want those too?
[19:17] <slangasek> is the 'upstream' branch a mirror of the actual upstream?
[19:17] <tjaalton> yes
[19:17] <slangasek> tjaalton: ultimately I want things that work with pristine-tar etc
[19:18] <rharper> hallyn: uvt-kvm --disk should take a size, it's how big to make the qcow2 image for the VM; it uses the release cloud image as a backing file
[19:19] <tjaalton> slangasek: yeah there are several workflows it seems :)
[19:19] <hallyn> rharper: yup, already updated my tree
[19:19] <hallyn> also implemented snapshot.
[19:19] <hallyn> running a new set of tests now
[19:20] <rharper> nice
[19:20] <tjaalton> slangasek: so one is to keep the upstream branch as is but import the tarball only to pristine-tar
[19:21] <tjaalton> I just tend to use uscan
[19:21] <tjaalton> if there are tarballs that can be used
[19:22] <slangasek> tjaalton: right, if the tarball has to be downloaded separately from the package git repo, I consider that a bug
[19:22] <slangasek> and in this case, we have modified tarballs anyway
[19:23] <pitti> thomi, xnox: https://code.launchpad.net/~autopilot/autopilot/py3-for-realz/+merge/207540
[19:23] <pitti> xnox: it's still missing tests, and that breaks one test case, but thomi will look into that
[19:24] <pitti> that's now barry's reexec trick plus the diversion packaging
[19:25] <tjaalton> slangasek: indeed, and there's get-orig-source for the initial tarball build
[19:30] <hallyn> jibel: hi - i've opened mp for https://code.launchpad.net/~serge-hallyn/auto-upgrade-testing/uvtool (and done some updates since then).  auto-upgrade-tester works for me, auto-install-tester is running but going good so far
[19:31] <Ryu_Fitzgerald> I have a queston about ubuntu and I think only someone with a development level knowledge would know this
[19:31] <Ryu_Fitzgerald> When you boot the computer, it writes where /dev/dvd looks.  Where is the file on the operating system that does this?
[19:35] <roadmr> Ryu_Fitzgerald: it's done by a udev rule in /etc/rules.d/70-persistent-cd.rules
[19:36] <sarnold> /etc/udev/rules.d/..
[19:39] <roadmr> sarnold, Ryu_Fitzgerald: right, /etc/udev/rules.d (my bad)
[19:40] <Ryu_Fitzgerald> i see a comment about the file being automatically generated.  Will this file get wiped on boot?
[19:41] <roadmr> Ryu_Fitzgerald: there's a comment about how to add your rules and have them stick over reboots
[19:44] <jtaylor> hm did the latest kernel update break perf?
[19:44] <jtaylor> its saying please install -tools, but it is installed
[19:46] <Ryu_Fitzgerald> i am not seeing any comment about rebooting or booting.  Where did you see it?
[19:49] <Ryu_Fitzgerald> roadmr, i don't see that comment reguaurding how to make the rules stick through reboot
[19:50] <Ryu_Fitzgerald> roadmr?
[19:50] <Ryu_Fitzgerald> speaking of which how did you make you text light up for me
[19:50] <Ryu_Fitzgerald> was it something like this
[19:50] <Ryu_Fitzgerald> roadmr:  or what
[19:52] <Ryu_Fitzgerald> Also i am not familiar wih how  SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:90:f5:ea:f6:ba", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0" format.  Could you please explain it
[19:53] <sarnold> Ryu_Fitzgerald: most irc clients will highlight for the user's nickname
[19:53] <Ryu_Fitzgerald> did this highlight yours,   sarnold,
[19:53] <sarnold> Ryu_Fitzgerald: people sending messages just need to use the nickname and for most people it will magically be awesome :)
[19:53] <sarnold> Ryu_Fitzgerald: yes
[19:53] <sarnold> Ryu_Fitzgerald: most clients also offer something like /lastlog -hilight which makes it easy to see all messages sent to you that are still in the scrollback buffer.
[19:54] <tarpman> Ryu_Fitzgerald: about the directives in the rules file: man 7 udev or http://manpages.ubuntu.com/man7/udev
[20:00] <Ryu_Fitzgerald> am i correct in assuming that once i finish reaeding through this/etc/udev/rules.d/70-persistent-net.rules and figure out how to construct a rule.  I would place the rule here?
[20:00] <roadmr> Ryu_Fitzgerald: my 70-persistent-cd.rules says: "however you are also free to add your own entries provided you add the ENV{GENERATED}=1 flag to your own rules as well." I suggest you google "udev rules" for more information on how they work
[20:00] <roadmr> Ryu_Fitzgerald: right, you should be able to put your stuff there
[20:01] <seb128> hum, arm64 seems to be behind, is there an issue or are we supposed to have only a couple of builders?
[20:08] <hallyn> man this is gonna take forever:  after an hour, i'm at Package dri2-utils: 441 of 7342 (6.006538.2)
[20:09] <sarnold> hallyn: can you change to using e.g. mirror.anl.gov? it seems to be ten to twenty times faster than canonical mirrors for me
[20:11] <jibel> shadeslayer, I reproduce your problem with kubuntu upgrade on trusty, I'll look into it.
[20:11] <hallyn> sarnold: not sure.  i don't think netowrkis the issue though.  i think the install-tester starts a new install for every package install test
[20:12] <sarnold> hallyn: SYN SYN ACK ACK HTTP GET ... oh my god that'll take forever
[20:12] <hallyn> jibel: how long does an auto-install-test run usually take?
[20:13] <Ryu_Fitzgerald> in this statement, what does hdc mean?  KERNEL=="hdc"
[20:13] <hallyn> sarnold: ah no, it doesn't start a new vm each time - it does ssh $name apt-get install package; ssh $name apt-get remove package
[20:13] <hallyn> on some packages i assume that destroy; recover snapshot; start vm would be faster :)
[20:14] <Ryu_Fitzgerald> i also see KERNEL=="hdb"
[20:14] <hallyn> on the bright side every package has passed so far
[20:15] <jibel> hallyn, thanks for the MP, I'll review it. We don't use auto-install-tester, you can just ignore it. If auto-upgrade-tester works with uvtool it's fine
[20:15] <hallyn> awesome
[20:15] <sarnold> hallyn: time for a vacation? :)
[20:15] <hallyn> but yes, auto-install-tester seems to be working so at least i don't appear to have regressed thigns there :)
[20:15] <Ryu_Fitzgerald> i am thinking this is the command i want to write but i don'tknow what hdc means.  KERNEL=="hdc", SYMLINK+="/dev/dvd /dev/sr0"
[20:16] <hallyn> sarnold: as soon as stgraber tags lxc 1.0, i'm quitting computer science
[20:16] <sarnold> hallyn: I hear that.
[20:19] <Ryu_Fitzgerald> or is this what I am looking for?  KERNEL=="sr0", SYMLINK+="dvd"
[20:20] <Ryu_Fitzgerald> does the rule command i just pasted make a linking for /dev/dvd to /dev/sr0?
[20:21] <arges> bdmurray: hi
[20:22] <stgraber> Ryu_Fitzgerald: yes
[20:22] <Ryu_Fitzgerald> thankyou
[20:22] <Ryu_Fitzgerald> i'll try it out, hopeuflly it will work
[20:48] <bdmurray> arges: hey
[20:51] <Ryu_Fitzgerald> thankyou, it works great
[21:02] <slangasek> hallyn: Debian bug #734633> so there's been no response, yes... remind me, was this something we needed in for trusty?
[21:02] <seb128> slangasek, hey
[21:03] <slangasek> seb128: hey there
[21:03] <hallyn> slangasek: yes, without it userspace wont' knwo (from include files) about newer capabilities
[21:03] <seb128> slangasek, do you know if there is any way to get gnome-session "unstalled on upgrade if nothing depends on it"?
[21:03] <seb128> slangasek, I'm discussing with robert_ancell the rename and whether it's going to lead upgrades to get gnome-shell installed at some point or to have gnome-session uninstalled
[21:04] <slangasek> hallyn: ok, so did you want this sponsored into trusty before FF?  (also, why are you not a core-dev?)
[21:05] <slangasek> seb128: probably warrants a hook in update-manager, I guess?
[21:05] <hallyn> slangasek, yes, that'd be great.  I'd really hoped to get it through debian instead, but...
[21:05] <slangasek> seb128: are those changes something that's happening in 14.04, or is that next-cycle stuff?
[21:06] <seb128> slangasek, do you think the hook is enough?
[21:06] <seb128> slangasek, I think robert_ancell mentioned wanting to add the depends next cycle
[21:06] <seb128> robert_ancell, ^
[21:06] <slangasek> seb128: as long as we have things moreor less as-is for
[21:06] <slangasek> seb128: for 14.04, I think an update-manager hook is enough
[21:06] <robert_ancell> yeah, keep as is until post 14.04
[21:06] <seb128> slangasek, k, thanks
[21:07] <slangasek> seb128: does gnome-session show as manually or automatically installed for you?
[21:07] <seb128> robert_ancell, let's go for that then
[21:07] <slangasek> (apt-mark showmanual | grep gnome-session)
[21:08] <seb128> slangasek, let me check on a system where it's still installed :p
[21:10] <seb128> slangasek, it's listed in apt-mark showmanual on a trusty stock install (I think that vm is mostly stock)
[21:10] <slangasek> ok, interesting/annoying
[21:10] <seb128> yeah, what I though...
[21:10] <slangasek> I think that's /etc/apt/apt.conf.d/01autoremove
[21:11] <slangasek> so, update-manager is the only reasonable solution AFAICS; we don't exactly want to make some other package to conflict with gnome-session to force its removal
[21:12] <seb128> slangasek, well, gnome-session is not outdated/deprecated, it's just for GNOME sessions only
[21:12] <seb128> we don't want to remove GNOME on update for those usingit
[21:12] <slangasek> yes, exactly
[21:13] <seb128> I wanted to rename the binaries to gnome-shell-session and ubuntu-session and have gnome-session being a dummy depending on ubuntu-session | gnome-shell-session
[21:13] <seb128> but robert_ancell thinks that's too much/not needed
[21:14] <seb128> well, we can see if the update-manager way works and adapt from feedback during beta time
[21:15] <robert_ancell> seb128, slangasek the safest logic is probably uninstall if don't have gnome-shell / mutter etc installed
[21:15] <robert_ancell> then gnome-session doesn't actually do anything useful
[21:15] <seb128> I don't know if if we the logic for "to things if <installed>"
[21:15] <seb128> to->do
[21:36] <shadeslayer> jibel: note that we have our own modifications to the code, so maybe that's buggy
[21:46] <xnox> i think we might have a consistent / matching bootsplash logo across: netboot, desktop, plymouth for the first time.
[21:46]  * xnox goes to check server images.
[21:50] <ogra_> xnox, now just make the phones work too :)
[23:25] <rbasak> hallyn: disk size, in GB.
[23:26] <hallyn> rbasak: thanks :)  done with that code for now
[23:27] <hallyn> trying to decide whether to update cgroup-bin to use cgmanager, or just package up some scripts to do the useful bits (cgcreate, cgexec, cgfreeze...)
[23:38] <bluesabre2> thanks dholbach!
[23:50] <doko> cyphermox, please could you have a look at http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg (network-manager recommends)