User1: User2 i thought that was solved -> clicks declare x-tests:autopilot_dir= key in their manifest.
User1: User2 that means they are ported.
User1: User2 deb based tests, will ship modules in either python3 or python2.7 path (and thus import/re-exec test works for them)
User2: User1 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
User2: User1 anyway, is the meeting tomorrow ok for you?
User1: User2 all click's tests are just in bzr.
User1: User2 yeah, i'll be there.
User2: User1 perfect, thank you
User1: User2 and i should update my phablet-tools patch before that meeting.
User2: probably best to discuss that with everyone in the hangout
User1: User2 is sergiusens on the call as well?
User2: User1 not ATM, but I'm happy to invite him
User1: User2 please do.
User3: xnox, User2 so I know this was discussed at the core sprint, but I have yet to see a write-up of what was decided there.
User3: 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
User1: User3 and there is another sprint in progress across the pond, which may have new things....
User1: User3 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)
User3: User1 ok, thank you
User2: User3 I gave a summary to https://code.launchpad.net/~barry/autopilot/reexec/+merge/203765
User2: User3 nothing decided really, we just discussed it and found that we agree on some things, but need xnox and barry for others
User2: User3 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
User3: um
User3: why does re-exec not work?
User2: because it's only done on import, not if there's a failed test
User2: importing py3 autopilot will always work, but you might get test failures on non-py3 compatible tests
User2: if you run tests from bzr you don't have separate install locations for py2 and py3 autopilot test modules
User3: User2 so xnox and barry did have a plan to address this
User3: which xnox has agreed to write down where we can all discuss it, instead of rediscussing everything from scratch every other week :)
User1: User2 re-exec trick works, if one uses phablet-test-run with my proposed branch to phablet-test-run.
User2: well yes, that's the bit which we don't understand yet, and I haven't seen a place which explains this
User1: User2 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.
User1: User2 right i'll write exactly that up.
User2: User1 barry said that there are tests which don't use that
User2: if that's obsolete, then it makes the whole thing much simpler
User3: User2 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
User2: User3 ah
User1: User2 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.
User3: since we should be using ptr for everything, and should be using python3 for everything
User1: User2 and we will _only_ support python3 with autopilot.
User3: so it doesn't hurt to bundle the two
User2: ack
User2: 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
User2: 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
User1: User2 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.
User2: User1 click manifest or the deb depends .*python3* ?
User1: User2 no, click manifest is either current (naked -> means python2) or has "autopilot_dir" key with the path to tests inside the branch.
User2: 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
User2: User1 yes; I mean, we need a corresponding metadata check for .deb packages, like dialer-app-autopilot
User1: User2 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.
User2: but that's just Depends:.*python3* IMHO
User1: User2 for debs it's different.
User1: User2 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.
User2: User1 ah right, those would trigger the import error for py3
User1: User2 exactly =)
User1: User2 User2 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
User2: User1 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
User2: that's the most straightforward and explicit way
User1: User2 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.
User2: 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
User1: User2 re-exec hack is best imho, as that will push python3 modules off the image quicker.
User2: how so?
User1: User2 and requires less reuploads.
User2: p-t-r could just explicitly call ap-py3 or ap-py2
User2: because it knows which py version the test wants
User1: User2 it's the same script.... autogenerated entry point.
User1: User2 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.
User2: no, it should have a python3 hashbang
User1: User2 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.
User2: and it does
User2: User1 yes, that's why I said I'm okay with the reexec hack, if people object to the autopilot3 name
User1: User2 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.
User2: we'd need to divert /usr/bin/autopilot in python3-autopilot
User1: with re-exec hack, it's just transparent.
User2: and drop the autogenerated entry point and replace it wit ha simple shell script
User1: User2 well, that's why we merged the two into a single package ;-) no need to divert things.
User2: but that's not too complicated
User2: and I'm certainly willing to do that
User1: User2 please no shell...
User2: User1 no, no, no, no
User2: merging the two into one will forever commit us to supporting ap-py2
User2: I want to drop python-autopilot after all tests get ported
User2: and ported packaged tests will change their dep to python3-autopilot
User1: User2 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
User2: so we can simply measure which tests got ported, and we never break packages which still need python-autopilot
User1: User2 we don't break any tests with my plan and have 3 transition steps instead of 5.
User2: *shrug*, if we want to assume that at no point we break anything existing that's what we have to do
User2: we need to upload the packages anyway to fix the tests
User1: User2 as long as people use phablet-test-run to execute the tests (be it deb, or click)
User1: User2 even longer route is to make all tests bilingual, not break anything at any point, and then drop python2 in any order....
User2: 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
User2: that would be a tiny short-term benefit for long-term trouble
User2: User1 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
User1: User2 what upgrades? also i don't see how python policy is jeffrey78@example.org.... and i don't see how we are doing anything lazy here.
User2: User1 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
User1: User2 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.
User1: User2 and ideally like ship them in /usr/share/autopilot/ anyway =)))))
User1: User2 what do you think of the pyflakes package btw?
User2: err, no, autopilot is not an app
User2: or not only
User2: it's mainly a python API
User1: User2 i really did not want the world to do: Depends: pyflakes, pyflakes3, just because they started to support python3.
User2: User1 "pyflakes3" makes no sense indeed, as that's just a program
User2: python3-pyflakes would be required if applications would do "import pyflakes"
User1: User2 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.
User2: err, no
User1: User2 i have at least 3 reverse-dependencies that import public pyflakes modules and do further or less processing.
User1: User2 and i don't see how I violate any of the python policy.
User2: User1 oh, you mean pyflakes, not ap
User2: User1 if pyflakes has a public python module API, then you need a python3-pyflakes
User1: User2 the only bit that i probably violate is python modules team naming scheme.
User1: User2 i don't /need/ it, i just need to have it.
User2: User1 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
User1: User2 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.
User2: but this is not the case with ap
User2: it has a public user-facing python API
User2: it's not pointless
User1: User2 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.
User2: you can't just randomly break reverse dependencies which expect python-ap to ship what it says on the tin: the python2 ap module
User2: User1 no, you misunderstand that
User1: User2 how does one write something that import autopilot and does something useful which is not a test script?
User2: User1 all ap tests do "import autopilot"
User1: User2 yes, but it's not "python -m my_test_module" it's "autopilot my_test_script"
User2: ap also has that /usr/bin/autopilot test runner (which is a CLI), but it has a public API
User1: User2 at no time those tests that do "import autopilot" can do anything useful by themself.
User1: without the one and only /usr/bin/autopilot test runner.
User2: sure
User2: but we don't know whether the tests are py2 or py3
User1: User2 autopilot broke it's api and moved to 1.4 without renaming =)
User2: and we don't control them all
User1: User2 which it should have done, if I go by your "it's public api" ditto like cherrypy2 / cherrypy3
User2: it's the exact same reason why we have python3-apt, python3-pycurl, and what not
User1: User2 and at the moment we do control all autopilot tests out there.
User2: User1 err, no, we don't
User1: User2 python3-apt / pycurl is different.
User2: we've shipped autopilot for a long time as ubuntu package, we don't know how people use it aside from our packaged tests
User1: User2 then how did we broke and removed 1.3 api, if we don't control all fo them?!
User2: e. g. we use it in the ubiquity tests
User2: which just live in a branch somewhere
User1: User2 and we control ubiquity tests, it's in lp:ubiquity.
User2: User1 I never said that I thought that was a good idea
User2: User1 no, not these; I mean the ubiquity autopilot tests
User2: but anyway
User1: User2 ubiquity autopilot tests are long merged into lp:ubiquity and jenkins is running them off lp:ubiquity...
User2: I consider python-ap to be like python-apt or python-pycurl etc.
User2: User1 ok, fine; it was just an example
User2: but there is a reason why we have separeate python3-* binaries in the archive, and that applies to ap as well
User2: and I see absolutely no reason why we should cause this long-term trouble
User2: we just flip the dependencies if we port a test, that takes like 2 seconds
User1: User2 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 =)
User2: and then we can clearly see what stuff is still using py2 by checking the rdepdns of python-autopilot
User2: how is it a historical mistake?
User2: python3 is a different programming language than python 2
User1: for debs we inspect content, for clicks jeffrey78@example.org. it's clear.
User1: if deb is depends on python-autopilot -> not ported, depends on autopilot ported.
User1: clicks no autopilot_dir key -> not ported, with autopilot_dir key -> ported.
User1: User2 under your naming scheme how or when are you going to drop "autopilot-py3" and just make it "autopilot" (shebang python3)
User1: ?
User2: seriously, that policy was made to provide a safe solution which works
User2: 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
User2: User1 I thought we wanted to do that right now, with your reexec trick?
User1: User2 yes. hence python3-ap is pointless with reexec.
User2: (and keep autopilot3 as a compat symlink)
User2: well, python-autopilot keeps /u/b/a as we have it today
User1: User2 so you want policy compliant binary package names with re-exec hack?
User2: python3-autopilot diverts that and replaces it with a python3 hashbang
User1: (e.g. python3-autopilot owns /u/b/a which does re-exec if it needs to)
User2: the reexec trick will then run it as py2 if import with py3 fails
User2: it's ugly and non-explicit in my taste, but it works and I'm ok with that
User1: User2 divert -> ok.
User1: User2 do diverts work ahead of other package installation?! (thinking about it, they must)
User2: User1 yes, they do
User1: (e.g. install python3-autopilot first, and maybe later python-autopilot)
User1: User2 ok.
User2: User1 i. e. you can install py3-ap, it installs the diversion
User1: cool.
User2: and then you install py-ap, dpkg will install its /u/b/ap into the diverted location
User1: User2 ok then packaging will be sane and easy + divert.
User2: same the other way round
User1: + reexec
User2: User1 yes, it would in both cases be the same autogenerated script, just with diversion instead of rename to autopilot3
User2: we then need the reexec trick
User1: User2 exellent.
User2: but we have the code for that in barry's branch
User1: correct.
User4: 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?
User4: RAOF, your in ~archive-admin but not an archive admin suitable for that right?
User5: User4 Correct. I only NEW packages which are X-SRUish (so, things like the nvidia-drivers-34234234245234134-updates et al)
User4: RAOF, know any archive admins who are awake by any chance?
User3: E: base-files: file-in-etc-not-marked-as-conffile etc/legal
User3: grr, we really ought to force that package to use debhelper
User6: User3 Santiago is still allergic?
User3: apparently?
User6: I don't get why he is so against it, but hey, it's his battle.
User3: well, and then people keep modifying the package in Ubuntu and adding new files under /etc, not realizing there's an additional manual step
User7: Yeah, I had to clean that up with os-release ages ago.
User6: User3 Perhaps we need the build to fail in that case. Or we could just accidently switch to debhelper
User7: Luckily caught it before it was a big issue.
User3: User7 yeah, apparently we've gone since karmic without anyone ever reading the lintian output on the binary packages on base-files?
User7: User3 Seems plausible.
User7: I only noticed it with os-release, cause that's a file that actually changes on upgrade.
 * slangasek nods
User7: 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
User7: Except that dinner made me too fat to think.
User3: User7 and regression-testing it in ubuntu-emulator too, right?
User7: I think my stomach is actually putting pressure on my brain somehow.
 * slangasek gives infinity a spinal tap to release the pressure
User7: User3 Are there destructions somewhere on how to do that?
User3: User7 https://wiki.ubuntu.com/Touch/Emulator
User3: 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
User7: "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."
User7: Sliiiick.
User3: yeah, qemu+stupidjobcontroltricks
User7: Sounds like someone just needs to use saner console redirection defaults.
User3: mm?
User7: But anyhow... Let's see if I can make this all go after I get a PPA build running.
User3: ok
User7: 1 new private symbol, 0 new public symbols.  Looks sane.
User3: oh for the love of makefiles
User7: Also, why am I hungry?  I think my brain is broken.
User7: Sitting here unable to move, and thinking "yeah, I could really go for a snack."
User3: yes, base-files, perfectly reasonable that I should have to also remember to manually install debian/postrm
User7: You're adding a postrm?
User3: yes, dpkg-maintscript-helper
User7: To do the conffile migration?
User3: to do a conffile removal
User7: rm_if_matches_md5sum
User7: See: http://launchpadlibrarian.net/120844030/base-files_6.5ubuntu6.3_6.5ubuntu6.4.diff.gz
User7: User3 I'm a fan of sticking with the way the package already handles this case.
User3: yes, and I prefer full policy compliance. :)
User7: 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.
User3: it's just the one because it's an Ubuntu-specific file being removed
User3: so post-trusty the delta can drop out again
User7: Kay.  Still would make sense to me to just use the same method, s'all.
User7: Smaller delta, more obviously readable in context, no new maintainer scripts, etc.
User3: except that method is buggy, and I have no intention of fixing the bugs in it by hand
User3: in fact, fixing the bugs in it requires adding a postrm anyway
User7: True.
User7: 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)
User7: I suspect you have bigger issues if your system is so broken that base-files fails to upgrade and needs to abort/unwind.
User8: User2 User54 User16 User49  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)
User7: User2 How do we completely flush an arch from ddebs so we can re-retrieve it?
User9: http://VisitsToMoney.com/index.php?refId=386970
User10: good morning
User10: @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
User11: dholbach, Could you look at some merges for xubuntu please?
User11: https://code.launchpad.net/~noskcaj/ubuntu/trusty/xfce4-panel/4.11/+merge/206601 is probably the highest priority
User10: Noskcaj, yes
User11: thanks
User11: slangasek, bug 1280109
User12: bug 1280109 in skype (Ubuntu) "Please, upgrade skype package to version 91.69.162.6" [Undecided,Confirmed] https://launchpad.net/bugs/1280109
User11: dholbach, What's the text conflict? I didn't have that issue
User10: Noskcaj, http://paste.ubuntu.com/6964186/
User11: Could you try just resolving it locally? I think just take the new version, since it's an upstream change
User13: User11 wait
User13: those are our default settings, please don't mess with those
User11: ok, could you check the changes then
User13: link?
User13: or is it only the conflict that was pastebinned?
User10: ochosi, that's only the conflict
User10: Noskcaj, to me it looks like the updated debian/patches/shimmer-layouts patch might have caused a bit of headache
User13: yes, i think we should get rid of that debian patch, just haven't had the time to deal with that :/
User11: ochosi, It's in debian, but i'm one of the maintainers there if you need a change
User10: ochosi, User11 can you work together to agree on something?
User13: User10 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
User10: I'll leave it to you
User11: ok
User11: sponsor indicator now please?
User10: 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
User10: Noskcaj, one after the other - when I tried to build it 5m ago the panel build-dep wasn't in the archive yet
User13: yeah, but simply dropping the debian-patch will potentially result in a lot of work, i didn't mean we should do that now
User11: dholbach, Oh yeah, forgot that
User13: i meant: i'll work with upstream to get these patches in so that you can get rid of the patch
User10: ochosi, User11 can you update the MP once you resolved the issue and agreed on a way forward?
User11: yep
User10: thanks guys
User13: thank you dholbach!
User13: User10 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
User4: 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 :)
User7: User4 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?
User4: infinity, yeah, we're doing that too, but that one takes longer to land
User4: LSMSGCV: You just sent an email to
User4: https://code.launchpad.net/~robert-ancell/unity/ubuntu-session/+merge/207346
User4: wrong paste buffer there
User4: 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
User7: User4 Alright, so you intend to drop that dep as soon as unity is pulling it in, I guess?
User7: User4 That works.
User4: yeah
User10: Noskcaj, User13 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?
User12: Launchpad bug 1282154 in xubuntu-default-settings (Ubuntu) "update default settings for trusty" [Undecided,New]
User13: User10 the problem is that currently the devs who can merge to those branches are a bit MIA
User13: so we cannot merge anything to xubuntu-default-settings ourselves
User13: and the ppl whose review is still pending are those who could merge
User14: User13 you could merge into one branch yourself and ask for that to be sponsored
User15: shrug, daily CD build failed again on checkbox depends things
User11: The other solution is i get my upload rights (and as a result get the push rights), but that's take 50 days now
User11: *taken
User13: User14 sure, that's no problem, it has just evolved that way as separate MRs and i thought it should be kept that way
User13: i'll try to take care of it asap and update that bugreport then
User10: thanks ochosi
User13: no problem, should i ping you again after the merges dholbach ?
User10: ochosi, thanks - that'll make review a lot easier
User10: yep, sounds good
User13: thanks dholbach
User14: User15 component-mismatches
User15: Laney, yeah, 2 days in a row
User14: you have the power!
User15: right, looking at it
User15: Laney, I promoted python3-plainbox, how do we get CD builds retried once the promotion is published?
 * Laney can do that
User13: User10 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
User10: ochosi, did you test build it and see if the settings all work as expected?
User10: I'll take a look in a sec
User13: for the merge-requests that i originally did, yes
User13: i'm not really a packager, so i can't judge the changes of rev464 tbh
User10: hum
User10: anyone else from the Xubuntu crowd in here?
User13: rev463 was tested, but not by me :/
User13: i think Noskcaj had to take off, but bluesabre might be around in an hour or two
User10: 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?
User10: I don't have a xubuntu installation around to test it
User10: test packages are up at http://people.canonical.com/~dholbach/tmp/xubuntu/
User13: thanks, that's very kind of you!
User13: i'll test myself (i'm on trusty) and ask our testers too
User13: and wow, that was quick :)
User10: rock on
User7: User2 *nudge*
User10: ochosi, it looks like all the changes were merged into the branch successfully - let me know how the testing goes
User15: infinity, he's in Oakland, so probably not going to be online before a few hours
User7: User15 Ahh.  And here I was, waiting up for him. ;)
User13: User10 quick question, why would the greeter.conf file from rev462 end up as "lightdm-gtk-greeter.conf.dpkg-dist"?
User13: (i installed your package)
User10: ochosi, do you still have the installation log? did you do local modifications to ./etc/xdg/xdg-xubuntu/lightdm/lightdm-gtk-greeter.conf?
User10: 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
User10: you can diff the two files to see which differences there actually were
User13: i used software center and i don't see any logs there
User10: check /var/log/apt
User13: yeah, nothing in the history or term.log
User13: somehow ubuntu-software-center didn't write/keep any logs it seems
User13: the .conf file is what was there before, the .dpkg-dist file has the changes done in rev462
User13: i can downgrade the package, remove the dpkg-dist file and try to install with dpkg again if you think that'd help
User10: yes, you could try that
User10: and see what the other testers say as well
User15: Laney,  python3-plainbox | 0.4-4 | trusty | all
User15: Laney, can you retry the iso build?
User14: yup, thanks
User13: User10 will do, thanks. so far i've tested the changes from rev 459, 460, 461 from your package (they all work)
User15: Laney, thanks
User15: Laney, can I see the build logs live somewhere or is that just "wait on an error email or an iso to be published"?
User10: 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)
User10: thanks
User14: User15 yeah, not live - they're copied out after the build is done
User14: to http://people.canonical.com/~ubuntu-archive/livefs-build-logs/trusty/ubuntu/latest/ and emailed
User15: ok, thanks
User13: User10 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...
User13: and yeah, will leave you to do other things until i've got more tester-feedback. thanks again! :)
User16: 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.
User17: Sweetshark, when do you plan your next lo upload?
User18: User17 libreoffice/libreoffice-l10n today if possible for there are urgent upstream fixes in that release.
User17: ok, thanks. just wan to have it built with python3.4 as the default
User18: User17 FWIW I saw your nlpsolver ping, will try to look into it still this week (together with other stuff in that package)
User10: @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:
User14: User15 the build worked
User15: Laney, \o/
User15: Laney, the results are not copied yet though?
User14: I think that happens once per hour
User15: ok
User15: seems http://cdimage.ubuntu.com/daily-live/current/trusty-desktop-amd64+mac.manifest is updated
User15: good, gnome-control-center dropped from the default install, I was after that for some days
User15: there was a recommends left in gnome-bluetooth that I fixed tuesday, seems that did it
User14: cool
User14: got to get gsd out now
User15: yeah, I'm looking at that
User14: might just be totem-plugins
User15: seems to be
 * seb128 fixes that
User14: let me
User14: oh, ok!
User15: ok
User14: who? :P
User15: Laney, if you want to do it, please do
User15: I've enough landings I want to push through to keep busy
User14: ok
User15: thanks
User15: 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?
User12: Launchpad bug 1264547 in totem (Ubuntu) "Apport Hooks Need Update gstreamer0.10 -> gstreamer1.0" [Undecided,New]
User14: okay
User15: thanks
User15: infinity, still around?
User15: is it fine to copy from https://launchpad.net/~canonical-libreoffice-builds/+archive/archive-staging to the trusty archive including binaries?
User15: or should we do a source copy instead?
User15: Sweetshark, ^
User7: User15 I have no idea how that PPA is configured, but probably not fine, no.
User15: infinity, https://answers.launchpad.net/launchpad/+question/243446 if that helps
User15: infinity, it's supposed to be security updates friendly, so it should be archive friendly as well?
User15: wgrant, ^?
User7: User15 Ahh, well, if it's "security-friendly", that would also mean that post-release pockets are turned off, which is devel-release hostile. :)
User19: seb128, User7 That PPA is a nonvirt and all archs, and no weird deps, so I don't really see a problem.
User7: User19 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)
User19: User7 Yes, that's just the nonvirt flag.
User19: (totally insane, but true)
User7: User19 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
User7: (So confusing)
User19: Yup
User19: The build ddebs flag puts them in the .changes
User19: The publish ddebs flag additionally puts them in main/debug
User19: With neither they'll just end up in Apache
User19: (ew)
User7: To be security-friendly, it should also be set to build only against -security, of course.
User7: Which I still maintain is devel-hostile.
User19: devel-hostile if there's a transition in -proposed, indeed.
User7: There are always transitions in proposed. :P
User7: User15 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.
User7: PPAs are cheap.  If we want to have one for libreoffice-devel and one for libreoffice-security, we should just do that.
User7: s/devel/proposed/
User7: Since it would also be fine for staging non-security SRUs.
User18: infinity, User15 This build is not urgent. Im essentially smoketesting this workflow, so that we _dont_ have these discussions _when_ its urgent.
User7: User18 Right, so I'd recommend a second PPA, so we're doing things "right".
User15: infinity, ok, I'm fine with source copy, I was just trying to spare some buildds cycles
User7: User18 a libreoffice-proposed that builds against all pockets for devel releases and SRUs, and a libreoffice-security that's used to stage security releases.
User7: And sane component mapping, but I assume wgrant did that last time he set this up.
User14: User15 do you remember what this recommends is for?
User19: User7 I can't actual twiddle that bit on others' PPAs, but the owner can.
User7: 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. :(
User15: Laney, the g-s-d one?
User7: User19 Oh, I assumed commercial admins saw all those twiddles.  You're not actually all-powerful? :)
User14: yeah
User18: User7 understood (with the two ppas).
User19: User7 No, it's deliberately restricted to making changes that normal users shouldn't be able to make
User19: User7 (and also it lets you opt into seeing just about anything, but that's for debugging/support without invoking IS...)
User7: User18 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".
User19: But write operations are pretty much restricted to heavily privileged bits.
User15: Laney, hum, not really, I guess it has to do with multimedia keys, eg https://bugzilla.gnome.org/show_bug.cgi?id=509438
User12: Gnome bug 509438 in Plugins "media player keys plugin is causing gnome-settings-daemon to start" [Critical,Resolved: fixed]
User18: User7 right
User15: Laney,
User15: src/plugins/media-player-keys/totem-media-player-keys.c:			       "org.gnome.SettingsDaemon",
User14: but with G_DBUS_PROXY_FLAGS_DO_NOT_AUTO_START
User15: Laney, right, well it has integration with g-s-d so it recommends it I guess
User15: you can do that u-s-d | g-s-d
User15: or drop it
User15: I don't think it's very useful
User14: I think I will drop it
User14: ta
User15: yw
User15: that makes sense
User15: having desktop integration doesn't mean it should recommends/pull in the desktop it integrates with
User20: Would anyone like to sponsor this upload, please? It's a ubiquity plugin for Ubuntu Studio. Bug: 946591
User12: bug 946591 in ubuntustudio-live "Add ubuntustudio-live to trusty repositories" [Undecided,Confirmed] https://launchpad.net/bugs/946591
User21: dholbach, User13 I can verify each of the fixes from http://people.canonical.com/~dholbach/tmp/xubuntu/
User21: https://code.launchpad.net/~ochosi/xubuntu-default-settings/trusty-updates/+merge/207376
User22: 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?
User23: A quick question about SPICE support in 14.04 - is it going to be improved over that which was provided with 12.04?
User16: User22 graphviz and redland-bindings presumably just need no change rebuilds - I don't have permission to upload them.
User16: User22 ffmpeg-php looks more involved, since it already FTBFS. I think we should drop it from Trusty (it's been dropped from jessie)
User16: User22 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.
User22: rbasak, but why the rebuild at all? the php-api didn't check
User22: rbasak, yes, removing the ruby1.8 zeroc binary
User16: User22 on i386, php5-common used to provide phpapi-20121212. Now it provides phpapi-20121212-lfs instead.
User22: ahh, ok. then rebuilding
User16: Thanks!
User16: User22 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)?
User22: rbasak, no clue ... only did fix the python3 issues in this package
User16: OK, I'll dig deeper.
User10: thanks bluesabre2
User10: ochosi, User21 uploaded
User22: rbasak, demoted ffmpeg-php, zeroc-ice should be the last one
User24: oh my ...
User24: systemd just swallowed network-manager
User22: jtaylor, are you working on the qhull transition?
User13: User10 thanks a lot!
User10: ochosi, keep up the good work!
User13: User10 will try to, in fact our seed also has a few merge-requests... :)
User10: 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
User13: User10 sure thing, thanks a lot for all you've done!
User13: i know it wasn't very convenient sponsoring
User10: anytime :)
User10: no no, it was all right
User13: ok, well thanks anyway :)
User25: User34 ping
User25: User34 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?
User12: Launchpad bug 1282095 in kubuntu-notification-helper (Ubuntu) "driverevent makes incorrect assertations" [High,Triaged]
User26: User27 hi! I've got a difficult question about click, please ping me back when you have a minute :-)
User8: User3 good morning - bug https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=734633 (which i mentioned in london) hasn't yet been addressed :(
User12: Debian bug 734633 in libcap2 "Merge upstream 2.24" [Normal,Open]
User8: did you ever hear back from the maintainer?
User8: i'd sort of like to have it in trusty...
User27: User26 ok
User28: User24 no, systemd just got some rewritten chunks to do... bridging, or whatever
User24: well, matter of time i guess
User28: not in the way that it currently is
User1: User24 are you talking about sytemd-networkd? network-manager maintainer at redhat is pissed off about it =)
User28: it took years to get NM to the semi-working state it is in now
User28: so it will take years to get systemd-network to do half of what NM does
User24: xnox, i thought so :)
User28: so it will be years more of this kind of conversation :)
User24: xnox, next step ... sniff bash into systemd ;)
User24: cyphermox, simply copy-paste job :P
User24: *simple
User28: ahah yeah ;)
User28: User24 actually my bet is that systemd will either swallow emacs, or emacs swallow systemd
User24: that sounds liek we could end up with some kind of moebius ...
User24: if both try to swallow each other at the same time
 * cyphermox ducks, dons asbestos vest
User24: might make the universe vanish or some such
User28: heh
User28: anyway, it's good that systemd does this
User28: some kind of nice competition going on there between systemd, n-m, connman... that might lead to some pretty cool innovation
User24: heh, always thinking positive ... you are so canadian sometimes :)
User29: User24 he's just looking for an excuse to get out of maintaining nm :)
User24: hehe
User24: 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 ?
User30: 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
User31: #ubuntu+1 is the support channel
User32: People still use aptitude these days?
User30: jpds, what do you use ?
User30: psusi, tks!
User32: User30 apt-get.
User33: does ubuntu have porterboxes available for packagers to debug their package's build failures on?
User33: and if so what is the procedure for getting access to them?
User1: User33 there are no public porterboxes available.
User1: User33 which build failure in particular do you wish to debug?
User1: User33 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.
User33: I was asking as a result of a discussion in #debian-mentors on oftc relating to the failure of hexchat on ubuntu ppc64el
User33: we suspect using dh-autoreconf would fix it but it would be nice to know such things before uploading
User34: Good morning
User34: User24 no, seems fine; one more brick in the wall of broken /etc :)
User35: User33 I can take a look - I've fixed around 100 ppc64el failures at this point
User35: User33 yes, we definitely need dh-autoreconf for that - do you want me to test and push a fix?
 * sney waves
User33: Logan_, sney is the guy you was asking about the hexchat ppc64 failure over in #debian-mentors
User35: User36 hey :)
User36: hi
User35: so I was just telling plugwash that dh-autoreconf (or a manual libtool file update) is necessary to fix hexchat's FTBFS on ppc64el
User35: do you want me to push a fix to Ubuntu?
User36: sure
User35: okay one moment
User35: well, more like 10 minutes
User35: just so I can test and stuff :)
User36: ok, I have to shower anyway
User24: pitti_, great, thanks :)
User34: User24 apport never writes that by itself, so we don't need the /etc/writable/ dance for that
User24: pitti_, we need to make the file writable though ... just not the weird hack
User34: right
User34: User24 or, you just change the default in the image build process?
User24: pitti_, that would change it for endusers too ....
User24: we want to keep apporrt running for users
User24: just not for demo images
User35: sney, User33 uploaded: https://launchpad.net/ubuntu/trusty/+source/hexchat/91.69.162.6-1ubuntu1
User35: I'll forward to Debian once we're sure it fixes the FTBFS on ppc64el
User34: User24 I thought the demo images are different anyway (i. e. different build process)
User1: User35 also hexchat probably needs all of my usability patches =)
User35: User1 oh dear :P
User24: pitti_, the same images, with one extra PPA
User35: sney, User33 it built successfully - forwarding now
User24: pitti_, this time we actually managed to get all essential stuff into the main image ... only some demoish extras are in the PPA
User34: User24 so it seems the easiest would just be to upload apport to that PPA with the default file saying "disabled"?
User24: pitti_, hmm
User24: sounds like more work
User34: User24 as you wish, both will work; it's just impossible to ever make a file non-writable again
User34: hence uploading apport to the PPA is easier to revert
User24: its easy to make a file non writable again
User36: User35 groovy, thanks for your attention
User24: unless you used the hackish approach ;)
User35: User36 no problem, anytime :)
User24: normal files just become readonly with a new image
User34: User24 well, all of that is a complete hack :)
User24: nah
User24: is *design*
User24: *g*
User34: User1 I read https://blueprints.launchpad.net/ubuntu/+spec/core-1311-python3-roadmap and that sounds good, thanks for the write-up
User1: User34 cheers. it leaves out some implementation details.
User34: User1 AFAIU the p-t-r MP that should still work with the simplified ap approach that we discussed yesterday, right?
User1: User34 e.g. it doesn't matter what the binary package names / packaging of autopilot is for example.
User34: i. e. only add the reexec thing and divert /u/b/ap instead of renaming it to ap3
User1: User34 correct. Althought, i think i failed to expand "p-t-r MP"
User1: =))))
User34: User1 https://code.launchpad.net/~xnox/phablet-tools/py2-3/+merge/205608
User34: phablet-test-run merge proposal
User1: User34 correct, that one would still work.
User30: jpds, hey man! apt-get installed the correct packages, Unity on 14.04 working again... I'll stop using aptitude...    =)
User24: good move
User37: command-not-found doesn't know about ruby2.0?
User1: User37 we didn't refresh command-not-found in ages.
 * ogra_ doesnt know about ruby2.0 either
User37: http://packages.ubuntu.com/trusty/ruby2.0
User37: User1 how are c-n-f data generated?
User38: Just a quick question: is python3.4 known to currently have some Popen issues? Just saw some ignored exceptions during an upgrade,
User20: 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
User12: bug 946591 in ubuntustudio-live "Add ubuntustudio-live to trusty repositories" [Undecided,Confirmed] https://launchpad.net/bugs/946591
 * highvoltage looks at bug report
User39: User20 also, good choice on basing on edubuntu-live ;)
User20: User39 :)
User39: User20 I'll be happy to sponsor it, anyone else from the ubuntu studio team who could also +1 it?
User40: 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?
User20: User39 Perhaps this is enough? It's the blueprint for ubuntustudio-live https://blueprints.launchpad.net/ubuntustudio-live/+spec/ubuntustudio-live-t
User15: bdmurray, try pressing the power button, it should trigger a session dialog
User20: User39 The team is kind of small right now, and being the project lead, I feel I can vouch for the thing
User15: bdmurray, that might unblock it
User39: User20 ok, uploaded
User20: Great :)
User40: User15 it raised the dialog but I can't interact with it
User15: bdmurray, esc doesn't work?
User40: User15 no
User40: User15 I've tried removing usb devices and plugging them back in but that didn't help either
User8: User16 User49 the --disk command in uvt-kvm create, what does it take?  a filename?
User40: oh well my keyboard doesn't work in recovery mode so its probably something low-level
User41: User22 re qhull yes
User42: 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)
User2: barry, User1 where does it drop the -E option in https://code.launchpad.net/~barry/autopilot/reexec/+merge/203765 ?
User2: I thought it would need to do that to consider $PYTHONPATH from p-t-r after reexecing to py2
User43: User42 see topic ;-)
User43: archive: open
User42: ah, that bit
User42: thanks!
User42: it was uploaded to proposed, so I guess a bot will soon move it to main?
User42: https://launchpad.net/ubuntu/trusty/+queue?queue_state=3&queue_text=landscape-client
User44: User2 i think xnox was testing something else?  that branch doesn't drop the -E
User25: User2 what does the jenkins instance use to run upgrade tests? LXC?
User2: User25 LXC for most tests, but there are a couple of _vm tests which use a full qemu
User2: User25 we want to minimize the QEMU ones, but we still need some for doing actual reboot tests
User1: User2 os.rexec only rexecs with arguments "/usr/bin/autopilot"
User1: User2 it does not re-exec with "-E"
User25: User45 ^^
User25: User2 we're getting these errors on our tests http://paste.ubuntu.com/6966771/
User1: User44 it does, it's just not obvious =)
User2: User1 it looks like it execs "python2 sys.argv", wouldn't that include the -E?
User1: User2 no, it would not.
User45: User2 note: that ^ error happens on the first run when there's no upgrade container bootstrapped yet
User44: User1 comments in the code would probably help :)
User1: User2 sys.argv only has /usr/bin/autopilot and onwards, not starting from /usr/bin/python3 -E ...
User2: User46 does http://paste.ubuntu.com/6966771/ ring a bell?
User1: User44 # black magic below...
User2: User46 (from yofel/shadeslayer above)
User1: User44 # end black magic?! =)
User2: User1 ah, thanks
User42: sorry, network failed
User46: pitti, shadeslayer I've never seen this before
User2: User45 is that a run on your machine, or in jenkins.q.u.c.?
User45: User2 currently on mine as we first wanted to test the profiles before mering
User2: User45 especially in saucy and earlier, LXC might need some additional tweaks for cgroups/apparmor/etc.
User46: shadeslayer, can you paste your profile (DistUpgrade.cfg) , I'll try it here
User45: ah, are those listed somewhere?
User45: the host is saucy
User25: User46 the best would be to branch lp:~kubuntu-dev/auto-upgrade-testing/auto-upgrade-testing :)
User46: shadeslayer, thanks
User42: 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 :)
User3: feature freeze is an advisory freeze, it doesn't change anything on the archive side
User3: proposed->release pocket should all be automatic - what package?
User3: (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)
User42: User3 https://launchpad.net/ubuntu/trusty/+queue?queue_state=3&queue_text=landscape-client
User3: User42 ok, the above page shows that it's waiting for arm64 to catch up
User3: but there are no obvious blockers beyond that
User42: User3 I see, thanks!
User47: User3 we're probably not getting new openldap from alioth git for trusty? ;)
User3: User47 man... I haven't even had a chance to look at the openldap git repo yet
User47: hehe
User3: User47 I was hoping someone else would pick this up :/
User47: right
User47: the list has been silent, no one seems to care
User48: User47 fwiw thanks for working on that... I've been watching and hoping it would make it to trusty, but too busy to contribute
User47: User48 yeah I was meant to get this in first and then maybe add a separate library built against libnss.. (for 389ds) but meh
User3: User47 so looking at the git repo, there don't seem to be any tags for upstream releases?
User47: User3 oh you want those too?
User3: is the 'upstream' branch a mirror of the actual upstream?
User47: yes
User3: User47 ultimately I want things that work with pristine-tar etc
User49: User8 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
User47: User3 yeah there are several workflows it seems :)
User8: User49 yup, already updated my tree
User8: also implemented snapshot.
User8: running a new set of tests now
User49: nice
User47: User3 so one is to keep the upstream branch as is but import the tarball only to pristine-tar
User47: I just tend to use uscan
User47: if there are tarballs that can be used
User3: User47 right, if the tarball has to be downloaded separately from the package git repo, I consider that a bug
User3: and in this case, we have modified tarballs anyway
User2: thomi, User1 https://code.launchpad.net/~autopilot/autopilot/py3-for-realz/+merge/207540
User2: User1 it's still missing tests, and that breaks one test case, but thomi will look into that
User2: that's now barry's reexec trick plus the diversion packaging
User47: User3 indeed, and there's get-orig-source for the initial tarball build
User8: User46 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
User50: I have a queston about ubuntu and I think only someone with a development level knowledge would know this
User50: When you boot the computer, it writes where /dev/dvd looks.  Where is the file on the operating system that does this?
User51: User50 it's done by a udev rule in /etc/rules.d/70-persistent-cd.rules
User52: /etc/udev/rules.d/..
User51: sarnold, User50 right, /etc/udev/rules.d (my bad)
User50: i see a comment about the file being automatically generated.  Will this file get wiped on boot?
User51: User50 there's a comment about how to add your rules and have them stick over reboots
User41: hm did the latest kernel update break perf?
User41: its saying please install -tools, but it is installed
User50: i am not seeing any comment about rebooting or booting.  Where did you see it?
User50: roadmr, i don't see that comment reguaurding how to make the rules stick through reboot
User50: roadmr?
User50: speaking of which how did you make you text light up for me
User50: was it something like this
User50: User51  or what
User50: 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
User52: User50 most irc clients will highlight for the user's nickname
User50: did this highlight yours,   sarnold,
User52: User50 people sending messages just need to use the nickname and for most people it will magically be awesome :)
User52: User50 yes
User52: User50 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.
User48: User50 about the directives in the rules file: man 7 udev or http://manpages.ubuntu.com/man7/udev
User50: 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?
User51: User50 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
User51: User50 right, you should be able to put your stuff there
User15: hum, arm64 seems to be behind, is there an issue or are we supposed to have only a couple of builders?
User8: man this is gonna take forever:  after an hour, i'm at Package dri2-utils: 441 of 7342 (6.006538.2)
User52: User8 can you change to using e.g. mirror.anl.gov? it seems to be ten to twenty times faster than canonical mirrors for me
User46: shadeslayer, I reproduce your problem with kubuntu upgrade on trusty, I'll look into it.
User8: User52 not sure.  i don't think netowrkis the issue though.  i think the install-tester starts a new install for every package install test
User52: User8 SYN SYN ACK ACK HTTP GET ... oh my god that'll take forever
User8: User46 how long does an auto-install-test run usually take?
User50: in this statement, what does hdc mean?  KERNEL=="hdc"
User8: User52 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
User8: on some packages i assume that destroy; recover snapshot; start vm would be faster :)
User50: i also see KERNEL=="hdb"
User8: on the bright side every package has passed so far
User46: 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
User8: awesome
User52: User8 time for a vacation? :)
User8: but yes, auto-install-tester seems to be working so at least i don't appear to have regressed thigns there :)
User50: 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"
User8: User52 as soon as stgraber tags lxc 1.0, i'm quitting computer science
User52: User8 I hear that.
User50: or is this what I am looking for?  KERNEL=="sr0", SYMLINK+="dvd"
User50: does the rule command i just pasted make a linking for /dev/dvd to /dev/sr0?
User53: User40 hi
User54: User50 yes
User50: thankyou
User50: i'll try it out, hopeuflly it will work
User40: User53 hey
User50: thankyou, it works great
User3: User8 Debian bug #734633> so there's been no response, yes... remind me, was this something we needed in for trusty?
User15: slangasek, hey
User3: User15 hey there
User8: User3 yes, without it userspace wont' knwo (from include files) about newer capabilities
User15: slangasek, do you know if there is any way to get gnome-session "unstalled on upgrade if nothing depends on it"?
User15: 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
User3: User8 ok, so did you want this sponsored into trusty before FF?  (also, why are you not a core-dev?)
User3: User15 probably warrants a hook in update-manager, I guess?
User8: slangasek, yes, that'd be great.  I'd really hoped to get it through debian instead, but...
User3: User15 are those changes something that's happening in 14.04, or is that next-cycle stuff?
User15: slangasek, do you think the hook is enough?
User15: slangasek, I think robert_ancell mentioned wanting to add the depends next cycle
User15: robert_ancell, ^
User3: User15 as long as we have things moreor less as-is for
User3: User15 for 14.04, I think an update-manager hook is enough
User4: yeah, keep as is until post 14.04
User15: slangasek, k, thanks
User3: User15 does gnome-session show as manually or automatically installed for you?
User15: robert_ancell, let's go for that then
User3: (apt-mark showmanual | grep gnome-session)
User15: slangasek, let me check on a system where it's still installed :p
User15: slangasek, it's listed in apt-mark showmanual on a trusty stock install (I think that vm is mostly stock)
User3: ok, interesting/annoying
User15: yeah, what I though...
User3: I think that's /etc/apt/apt.conf.d/01autoremove
User3: 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
User15: slangasek, well, gnome-session is not outdated/deprecated, it's just for GNOME sessions only
User15: we don't want to remove GNOME on update for those usingit
User3: yes, exactly
User15: 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
User15: but robert_ancell thinks that's too much/not needed
User15: well, we can see if the update-manager way works and adapt from feedback during beta time
User4: seb128, slangasek the safest logic is probably uninstall if don't have gnome-shell / mutter etc installed
User4: then gnome-session doesn't actually do anything useful
User15: I don't know if if we the logic for "to things if <installed>"
User15: to->do
User25: User46 note that we have our own modifications to the code, so maybe that's buggy
User1: i think we might have a consistent / matching bootsplash logo across: netboot, desktop, plymouth for the first time.
 * xnox goes to check server images.
User24: xnox, now just make the phones work too :)
User16: User8 disk size, in GB.
User8: User16 thanks :)  done with that code for now
User8: 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...)
User21: thanks dholbach!
User22: cyphermox, please could you have a look at http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg (network-manager recommends)
ubuntu-devel
Ubuntu IRC