[00:18] pitti: i thought that was solved -> clicks declare x-tests:autopilot_dir= key in their manifest. [00:18] pitti: that means they are ported. [00:18] 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] 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] xnox: anyway, is the meeting tomorrow ok for you? [00:18] pitti: all click's tests are just in bzr. [00:18] pitti: yeah, i'll be there. [00:19] xnox: perfect, thank you [00:19] pitti: and i should update my phablet-tools patch before that meeting. [00:19] probably best to discuss that with everyone in the hangout [00:19] pitti: is sergiusens on the call as well? [00:21] xnox: not ATM, but I'm happy to invite him [00:21] pitti: please do. [00:25] 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] 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] slangasek: and there is another sprint in progress across the pond, which may have new things.... [00:27] 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] xnox: ok, thank you [00:29] slangasek: I gave a summary to https://code.launchpad.net/~barry/autopilot/reexec/+merge/203765 [00:30] 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] 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] um [00:30] why does re-exec not work? [00:31] because it's only done on import, not if there's a failed test [00:31] importing py3 autopilot will always work, but you might get test failures on non-py3 compatible tests [00:31] if you run tests from bzr you don't have separate install locations for py2 and py3 autopilot test modules [00:33] pitti: so xnox and barry did have a plan to address this [00:33] which xnox has agreed to write down where we can all discuss it, instead of rediscussing everything from scratch every other week :) [00:34] pitti: re-exec trick works, if one uses phablet-test-run with my proposed branch to phablet-test-run. [00:34] well yes, that's the bit which we don't understand yet, and I haven't seen a place which explains this [00:34] 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] pitti: right i'll write exactly that up. [00:35] xnox: barry said that there are tests which don't use that [00:35] if that's obsolete, then it makes the whole thing much simpler [00:36] 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] slangasek: ah [00:37] 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] since we should be using ptr for everything, and should be using python3 for everything [00:37] pitti: and we will _only_ support python3 with autopilot. [00:37] so it doesn't hurt to bundle the two [00:37] ack [00:38] 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] 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] 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] xnox: click manifest or the deb depends .*python3* ? [00:39] 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] 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] xnox: yes; I mean, we need a corresponding metadata check for .deb packages, like dialer-app-autopilot [00:40] 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] but that's just Depends:.*python3* IMHO [00:40] pitti: for debs it's different. [00:41] 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] xnox: ah right, those would trigger the import error for py3 [00:41] pitti: exactly =) [00:42] 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] 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] that's the most straightforward and explicit way [00:42] 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] 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] pitti: re-exec hack is best imho, as that will push python3 modules off the image quicker. [00:43] how so? [00:43] pitti: and requires less reuploads. [00:43] p-t-r could just explicitly call ap-py3 or ap-py2 [00:44] because it knows which py version the test wants [00:44] pitti: it's the same script.... autogenerated entry point. [00:44] 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] no, it should have a python3 hashbang [00:45] 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] and it does [00:46] xnox: yes, that's why I said I'm okay with the reexec hack, if people object to the autopilot3 name [00:46] 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] we'd need to divert /usr/bin/autopilot in python3-autopilot [00:46] with re-exec hack, it's just transparent. [00:46] and drop the autogenerated entry point and replace it wit ha simple shell script [00:46] pitti: well, that's why we merged the two into a single package ;-) no need to divert things. [00:46] but that's not too complicated [00:47] and I'm certainly willing to do that [00:47] pitti: please no shell... [00:47] xnox: no, no, no, no [00:47] merging the two into one will forever commit us to supporting ap-py2 [00:47] I want to drop python-autopilot after all tests get ported [00:47] and ported packaged tests will change their dep to python3-autopilot [00:48] 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] so we can simply measure which tests got ported, and we never break packages which still need python-autopilot [00:48] pitti: we don't break any tests with my plan and have 3 transition steps instead of 5. [00:48] *shrug*, if we want to assume that at no point we break anything existing that's what we have to do [00:48] we need to upload the packages anyway to fix the tests [00:49] pitti: as long as people use phablet-test-run to execute the tests (be it deb, or click) [00:49] 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] 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] that would be a tiny short-term benefit for long-term trouble [00:51] 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] 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] 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] 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] pitti: and ideally like ship them in /usr/share/autopilot/ anyway =))))) [00:52] pitti: what do you think of the pyflakes package btw? [00:52] err, no, autopilot is not an app [00:52] or not only [00:52] it's mainly a python API [00:52] pitti: i really did not want the world to do: Depends: pyflakes, pyflakes3, just because they started to support python3. [00:53] xnox: "pyflakes3" makes no sense indeed, as that's just a program [00:53] python3-pyflakes would be required if applications would do "import pyflakes" [00:53] 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] err, no [00:53] pitti: i have at least 3 reverse-dependencies that import public pyflakes modules and do further or less processing. [00:54] pitti: and i don't see how I violate any of the python policy. [00:54] xnox: oh, you mean pyflakes, not ap [00:54] xnox: if pyflakes has a public python module API, then you need a python3-pyflakes [00:54] pitti: the only bit that i probably violate is python modules team naming scheme. [00:54] pitti: i don't /need/ it, i just need to have it. [00:55] 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] 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] but this is not the case with ap [00:55] it has a public user-facing python API [00:55] it's not pointless [00:56] 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] 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] xnox: no, you misunderstand that [00:56] pitti: how does one write something that import autopilot and does something useful which is not a test script? [00:56] xnox: all ap tests do "import autopilot" [00:56] pitti: yes, but it's not "python -m my_test_module" it's "autopilot my_test_script" [00:57] ap also has that /usr/bin/autopilot test runner (which is a CLI), but it has a public API [00:57] pitti: at no time those tests that do "import autopilot" can do anything useful by themself. [00:57] without the one and only /usr/bin/autopilot test runner. [00:57] sure [00:57] but we don't know whether the tests are py2 or py3 [00:57] pitti: autopilot broke it's api and moved to 1.4 without renaming =) [00:57] and we don't control them all [00:58] pitti: which it should have done, if I go by your "it's public api" ditto like cherrypy2 / cherrypy3 [00:58] it's the exact same reason why we have python3-apt, python3-pycurl, and what not [00:58] pitti: and at the moment we do control all autopilot tests out there. [00:58] xnox: err, no, we don't [00:58] pitti: python3-apt / pycurl is different. [00:59] 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] pitti: then how did we broke and removed 1.3 api, if we don't control all fo them?! [00:59] e. g. we use it in the ubiquity tests [00:59] which just live in a branch somewhere [00:59] pitti: and we control ubiquity tests, it's in lp:ubiquity. [00:59] xnox: I never said that I thought that was a good idea [01:00] xnox: no, not these; I mean the ubiquity autopilot tests [01:00] but anyway [01:00] pitti: ubiquity autopilot tests are long merged into lp:ubiquity and jenkins is running them off lp:ubiquity... [01:00] I consider python-ap to be like python-apt or python-pycurl etc. [01:01] xnox: ok, fine; it was just an example [01:01] but there is a reason why we have separeate python3-* binaries in the archive, and that applies to ap as well [01:01] and I see absolutely no reason why we should cause this long-term trouble [01:01] we just flip the dependencies if we port a test, that takes like 2 seconds [01:02] 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] and then we can clearly see what stuff is still using py2 by checking the rdepdns of python-autopilot [01:02] how is it a historical mistake? [01:02] python3 is a different programming language than python 2 [01:02] for debs we inspect content, for clicks look at manifest. it's clear. [01:03] if deb is depends on python-autopilot -> not ported, depends on autopilot ported. [01:03] clicks no autopilot_dir key -> not ported, with autopilot_dir key -> ported. [01:04] pitti: under your naming scheme how or when are you going to drop "autopilot-py3" and just make it "autopilot" (shebang python3) [01:04] ? [01:04] seriously, that policy was made to provide a safe solution which works [01:04] 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] xnox: I thought we wanted to do that right now, with your reexec trick? [01:04] pitti: yes. hence python3-ap is pointless with reexec. [01:04] (and keep autopilot3 as a compat symlink) [01:05] well, python-autopilot keeps /u/b/a as we have it today [01:05] pitti: so you want policy compliant binary package names with re-exec hack? [01:05] python3-autopilot diverts that and replaces it with a python3 hashbang [01:05] (e.g. python3-autopilot owns /u/b/a which does re-exec if it needs to) [01:05] the reexec trick will then run it as py2 if import with py3 fails [01:06] it's ugly and non-explicit in my taste, but it works and I'm ok with that [01:06] pitti: divert -> ok. [01:06] pitti: do diverts work ahead of other package installation?! (thinking about it, they must) [01:06] xnox: yes, they do [01:07] (e.g. install python3-autopilot first, and maybe later python-autopilot) [01:07] pitti: ok. [01:07] xnox: i. e. you can install py3-ap, it installs the diversion [01:07] cool. [01:07] and then you install py-ap, dpkg will install its /u/b/ap into the diverted location [01:07] pitti: ok then packaging will be sane and easy + divert. [01:07] same the other way round [01:07] + reexec [01:10] xnox: yes, it would in both cases be the same autogenerated script, just with diversion instead of rename to autopilot3 [01:10] we then need the reexec trick [01:10] pitti: exellent. [01:11] but we have the code for that in barry's branch === io is now known as IdleOne [01:17] correct. [02:18] 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] RAOF, your in ~archive-admin but not an archive admin suitable for that right? [02:23] robert_ancell: Correct. I only NEW packages which are X-SRUish (so, things like the nvidia-drivers-34234234245234134-updates et al) [02:23] RAOF, know any archive admins who are awake by any chance? [03:17] E: base-files: file-in-etc-not-marked-as-conffile etc/legal [03:17] grr, we really ought to force that package to use debhelper [03:19] slangasek: Santiago is still allergic? [03:19] apparently? [03:20] I don't get why he is so against it, but hey, it's his battle. [03:21] 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] Yeah, I had to clean that up with os-release ages ago. [03:21] slangasek: Perhaps we need the build to fail in that case. Or we could just accidently switch to debhelper [03:21] Luckily caught it before it was a big issue. [03:22] infinity: yeah, apparently we've gone since karmic without anyone ever reading the lintian output on the binary packages on base-files? [03:22] slangasek: Seems plausible. [03:22] I only noticed it with os-release, cause that's a file that actually changes on upgrade. [03:22] * slangasek nods [03:24] 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] Except that dinner made me too fat to think. [03:25] infinity: and regression-testing it in ubuntu-emulator too, right? [03:25] 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] slangasek: Are there destructions somewhere on how to do that? [03:26] infinity: https://wiki.ubuntu.com/Touch/Emulator [03:27] 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] "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] Sliiiick. [03:28] yeah, qemu+stupidjobcontroltricks [03:29] Sounds like someone just needs to use saner console redirection defaults. [03:29] mm? [03:29] But anyhow... Let's see if I can make this all go after I get a PPA build running. [03:29] ok === freeflying is now known as freeflying_away === mwhudson is now known as zz_mwhudson [03:37] 1 new private symbol, 0 new public symbols. Looks sane. [03:38] oh for the love of makefiles [03:38] Also, why am I hungry? I think my brain is broken. [03:38] Sitting here unable to move, and thinking "yeah, I could really go for a snack." [03:39] yes, base-files, perfectly reasonable that I should have to also remember to manually install debian/postrm [03:39] You're adding a postrm? [03:39] yes, dpkg-maintscript-helper === freeflying_away is now known as freeflying [03:39] To do the conffile migration? [03:39] to do a conffile removal [03:40] rm_if_matches_md5sum [03:40] See: http://launchpadlibrarian.net/120844030/base-files_6.5ubuntu6.3_6.5ubuntu6.4.diff.gz [03:40] slangasek: I'm a fan of sticking with the way the package already handles this case. [03:41] yes, and I prefer full policy compliance. :) [03:42] 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] it's just the one because it's an Ubuntu-specific file being removed [03:42] so post-trusty the delta can drop out again [03:42] Kay. Still would make sense to me to just use the same method, s'all. [03:43] Smaller delta, more obviously readable in context, no new maintainer scripts, etc. [03:43] except that method is buggy, and I have no intention of fixing the bugs in it by hand [03:43] in fact, fixing the bugs in it requires adding a postrm anyway [03:43] True. [03:44] 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] 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] 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] pitti: How do we completely flush an arch from ddebs so we can re-retrieve it? === semiosis_ is now known as semiosis === jono is now known as Guest99797 [05:24] http://VisitsToMoney.com/index.php?refId=386970 === semiosis_ is now known as semiosis [06:47] good morning [06:50] @pilot in === udevbot changed the topic of #ubuntu-devel to: Trusty Tahr Alpha 2 released! | Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> saucy | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: dholbach [06:57] dholbach, Could you look at some merges for xubuntu please? [06:58] https://code.launchpad.net/~noskcaj/ubuntu/trusty/xfce4-panel/4.11/+merge/206601 is probably the highest priority [07:00] Noskcaj, yes [07:00] thanks [07:23] slangasek, bug 1280109 [07:23] bug 1280109 in skype (Ubuntu) "Please, upgrade skype package to version 4.2.0.13" [Undecided,Confirmed] https://launchpad.net/bugs/1280109 === tvoss|food is now known as tvoss [07:57] dholbach, What's the text conflict? I didn't have that issue [07:58] Noskcaj, http://paste.ubuntu.com/6964186/ [07:59] Could you try just resolving it locally? I think just take the new version, since it's an upstream change [08:02] Noskcaj: wait [08:03] those are our default settings, please don't mess with those [08:03] ok, could you check the changes then [08:03] link? [08:03] or is it only the conflict that was pastebinned? [08:04] ochosi, that's only the conflict [08:04] Noskcaj, to me it looks like the updated debian/patches/shimmer-layouts patch might have caused a bit of headache [08:05] yes, i think we should get rid of that debian patch, just haven't had the time to deal with that :/ [08:05] ochosi, It's in debian, but i'm one of the maintainers there if you need a change [08:06] ochosi, Noskcaj: can you work together to agree on something? [08:06] 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] I'll leave it to you [08:06] ok [08:06] sponsor indicator now please? [08:06] 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] 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] 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] dholbach, Oh yeah, forgot that [08:07] i meant: i'll work with upstream to get these patches in so that you can get rid of the patch [08:07] ochosi, Noskcaj: can you update the MP once you resolved the issue and agreed on a way forward? [08:08] yep [08:08] thanks guys [08:08] thank you dholbach! [08:09] 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] 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] 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] infinity, yeah, we're doing that too, but that one takes longer to land [08:28] LSMSGCV: You just sent an email to [08:28] https://code.launchpad.net/~robert-ancell/unity/ubuntu-session/+merge/207346 [08:28] wrong paste buffer there [08:29] 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] robert_ancell: Alright, so you intend to drop that dep as soon as unity is pulling it in, I guess? [08:30] robert_ancell: That works. [08:30] yeah [09:02] 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] Launchpad bug 1282154 in xubuntu-default-settings (Ubuntu) "update default settings for trusty" [Undecided,New] [09:02] dholbach: the problem is that currently the devs who can merge to those branches are a bit MIA [09:03] so we cannot merge anything to xubuntu-default-settings ourselves [09:04] and the ppl whose review is still pending are those who could merge [09:04] ochosi: you could merge into one branch yourself and ask for that to be sponsored [09:04] shrug, daily CD build failed again on checkbox depends things [09:04] 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] *taken [09:05] 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] i'll try to take care of it asap and update that bugreport then [09:05] thanks ochosi [09:05] no problem, should i ping you again after the merges dholbach ? [09:05] ochosi, thanks - that'll make review a lot easier [09:06] yep, sounds good [09:06] thanks dholbach [09:08] seb128: component-mismatches [09:09] Laney, yeah, 2 days in a row [09:10] you have the power! [09:10] right, looking at it [09:32] 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] 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] ochosi, did you test build it and see if the settings all work as expected? [09:44] I'll take a look in a sec [09:44] for the merge-requests that i originally did, yes [09:45] i'm not really a packager, so i can't judge the changes of rev464 tbh [09:46] hum [09:46] anyone else from the Xubuntu crowd in here? [09:46] rev463 was tested, but not by me :/ [09:46] i think Noskcaj had to take off, but bluesabre might be around in an hour or two [09:47] 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] I don't have a xubuntu installation around to test it [09:48] test packages are up at http://people.canonical.com/~dholbach/tmp/xubuntu/ [09:48] thanks, that's very kind of you! [09:48] i'll test myself (i'm on trusty) and ask our testers too [09:49] and wow, that was quick :) [09:49] rock on [09:56] pitti: *nudge* [09:56] ochosi, it looks like all the changes were merged into the branch successfully - let me know how the testing goes [09:57] infinity, he's in Oakland, so probably not going to be online before a few hours [09:58] seb128: Ahh. And here I was, waiting up for him. ;) [10:01] dholbach: quick question, why would the greeter.conf file from rev462 end up as "lightdm-gtk-greeter.conf.dpkg-dist"? [10:02] (i installed your package) [10:06] 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] 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] you can diff the two files to see which differences there actually were [10:08] i used software center and i don't see any logs there [10:08] check /var/log/apt [10:10] yeah, nothing in the history or term.log [10:10] somehow ubuntu-software-center didn't write/keep any logs it seems [10:11] the .conf file is what was there before, the .dpkg-dist file has the changes done in rev462 [10:11] 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] yes, you could try that [10:12] and see what the other testers say as well [10:12] Laney, python3-plainbox | 0.4-4 | trusty | all [10:12] Laney, can you retry the iso build? [10:12] yup, thanks [10:13] dholbach: will do, thanks. so far i've tested the changes from rev 459, 460, 461 from your package (they all work) [10:13] Laney, thanks [10:14] 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] 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] thanks [10:14] seb128: yeah, not live - they're copied out after the build is done [10:14] to http://people.canonical.com/~ubuntu-archive/livefs-build-logs/trusty/ubuntu/latest/ and emailed [10:15] ok, thanks [10:18] 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] and yeah, will leave you to do other things until i've got more tester-feedback. thanks again! :) [10:22] 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] Sweetshark, when do you plan your next lo upload? [10:37] doko_: libreoffice/libreoffice-l10n today if possible for there are urgent upstream fixes in that release. [10:37] ok, thanks. just wan to have it built with python3.4 as the default [10:37] doko_: FWIW I saw your nlpsolver ping, will try to look into it still this week (together with other stuff in that package) === doko_ is now known as doko [10:47] @pilot out === udevbot changed the topic of #ubuntu-devel to: Trusty Tahr Alpha 2 released! | Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> saucy | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: [10:48] seb128: the build worked [10:48] Laney, \o/ [10:50] Laney, the results are not copied yet though? [10:50] I think that happens once per hour [10:50] ok [10:50] seems http://cdimage.ubuntu.com/daily-live/current/trusty-desktop-amd64+mac.manifest is updated [10:51] good, gnome-control-center dropped from the default install, I was after that for some days [10:51] there was a recommends left in gnome-bluetooth that I fixed tuesday, seems that did it [10:51] cool [10:51] got to get gsd out now [10:51] yeah, I'm looking at that [10:53] might just be totem-plugins [10:53] seems to be [10:53] * seb128 fixes that [10:53] let me [10:53] oh, ok! [10:53] ok [10:53] who? :P [10:54] Laney, if you want to do it, please do [10:54] I've enough landings I want to push through to keep busy [10:54] ok [10:54] thanks [10:56] 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? [10:56] Launchpad bug 1264547 in totem (Ubuntu) "Apport Hooks Need Update gstreamer0.10 -> gstreamer1.0" [Undecided,New] [11:01] okay [11:01] thanks [11:01] infinity, still around? [11:02] is it fine to copy from https://launchpad.net/~canonical-libreoffice-builds/+archive/archive-staging to the trusty archive including binaries? [11:02] or should we do a source copy instead? [11:02] Sweetshark, ^ [11:05] seb128: I have no idea how that PPA is configured, but probably not fine, no. [11:05] infinity, https://answers.launchpad.net/launchpad/+question/243446 if that helps [11:06] infinity, it's supposed to be security updates friendly, so it should be archive friendly as well? [11:06] wgrant, ^? [11:07] 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] seb128, infinity: That PPA is a nonvirt and all archs, and no weird deps, so I don't really see a problem. [11:08] 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] infinity: Yes, that's just the nonvirt flag. [11:08] (totally insane, but true) [11:09] 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] (So confusing) [11:09] Yup [11:09] The build ddebs flag puts them in the .changes [11:09]