[17:57] <scott-work> ciao quadrispro, you handle the cdbs vs dh flame war rather nicely :)
[17:59] <quadrispro> ehy scott-work, thank you
[17:59] <quadrispro> I don't like this kind of flame at all
[17:59] <scott-work> yeah, i know :(  it's rather counterproductive
[17:59] <scott-work> territorial pissings :(
[18:00] <quadrispro> I fail to see benefits getting from a war CDBSvsDH
[18:01] <scott-work> is jonas an author of CDBS?
[18:01] <quadrispro> scott-work, yes I think
[18:02] <scott-work> i should note that i felt jonas's offer to fix the issue with CDBS seemed quite genuine and gracious (as oppossed to telling someone else to fix it with CDBS)
[18:02] <scott-work> he is quite an asset then to have on the debian multimedia team then :)
[18:04] <quadrispro> it's easy to get an impression like: "oh! he was so kind!"
[18:05] <quadrispro> I really like his job, but a matter of principle doesn't help anyone
[18:05] <quadrispro> scott-work, and he feels this as a question of principle
[18:06] <quadrispro> please take a look at the ML archive
[18:16] <scott-work> i have seen several of his emails, and they do have a certain 'cdbs is the "proper" way to do it' undercurrent to them
[18:53] <quadrispro> I have to leave
[18:53] <quadrispro> ciao scott-work !
[22:44] <falktx> hi guys


[00:58] <mhall119> marcoceppi: is there any way I could get a juju gui showing off the developer.ubuntu.com staging deployment?
[05:23] <stub> marcoceppi, cory_fu : I think fixing imports is a separate issue, and should be done in any case. It makes things cleaner and less magic, and avoids hacks in situations that need it (eg. an @hook('upgrade-charm') wanting to invoke @when handlers directly). Python3 spent a lot of effort getting it working in the odd situations it didn't work in Py2, because occasionally you do need it and not having it is a pain in the bum.
[05:27] <stub> marcoceppi, cory_fu : If the convention is to put APIs and callable or shared non-handlers in lib/charms, thats fine. I had things in reactive because I wasn't aware of the convention, and it felt quite nice having it in the same package.  It was handlers and methods and helpers called by handlers, and some of those methods also designed to be called by handlers in other layers.
[05:29] <stub> (you call things directly rather than set state when you want a particular invocation order, have things invoked inside a context manager, interleave calling handlers with other code...)
[09:59] <jamespage> apuimedo, hey - I will get to your MP's today - just need to sortout an issue in our QA cloud with liberty
[09:59] <apuimedo> very well jamespage ;-)
[11:01] <stub> Has anyone wired up a Juju charm integration test suite to travis-ci ?
[11:06] <marcoceppi> stub: we did for a few layers irrc
[11:06] <marcoceppi> but not the integration stuff
[11:06] <marcoceppi> (like amulet)
[11:19] <stub> lxc test runner needs a kick - failing to bootstrap due to port in use
[12:00] <smartbit> Where can I find the recording of the first day at cfgmgmtcamp 2016, that includes Mark Shuttleworth's talk? I found it a couple of days ago, but lost it :-/
[12:12] <marcoceppi> smartbit: I'm not sure we've published it yet? I'll see if I can find them
[12:13] <marcoceppi> smartbit: we typically publish them here: https://www.youtube.com/jujucharms/videos but none have been uploaded yet
[12:14] <marcoceppi> smartbit: I'll ping James who was doing the recordings
[12:20] <smartbit> marcoceppi: Found it through http://eventifier.com/event/cfgmgmtcamp/videos : https://www.youtube.com/watch?v=sp_Re8Mx9xk&t=4095
[12:21] <smartbit> Recordings of day 2 & 3 juju charner summit 2016: https://www.youtube.com/playlist?list=PLzSGDpUWtiotngRgVqpa8jeCBQ2CCjzfo
[12:24] <marcoceppi> \o/
[12:53] <icey> can I `juju add-machine` with an existing machine, in essence bring the manual provider stuff to a regular deployment?
[12:55] <rick_h__> icey: I've not tried it, but I *think* so?
[12:55] <icey> well then rick_h__ I'll let you know how it works :)
[12:56] <icey> I need a very much not standard machine for a demo tomorrow so wanted to build the /machine/ by hand and then let juju have at it
[12:56] <marcoceppi> icey: yes you can
[12:56] <icey> glad to have it confirmed marcoceppi
[12:57] <marcoceppi> juju machine add ssh:user@address
[12:57] <marcoceppi> icey: ^^
[14:09] <jamespage> apuimedo, neutron-api and charm-helpers fixes landed thankyou!
[14:10] <apuimedo> I just got the email
[14:10] <apuimedo> thank you ;-)
[14:10] <apuimedo> I made some improvements to midonet-api today
[14:10] <apuimedo> to prevent races when running in HA
[14:10] <apuimedo> if you want an ha liberty bundle yaml let me know
[14:11] <stub> marcoceppi: Just looking at the apt layer, I have an install_queued method that may be called directly that is also a handler called automatically. So if I split it, there is going to be some silly duplication.
[14:21] <jamespage> apuimedo, bundles good
[14:21] <jamespage> yes please
[14:21] <apuimedo> very well
[14:21] <jamespage> apuimedo, hows the polish on lint, unit and amulet tests going?
[14:22] <apuimedo> lint should be fixed. unit tests are almost there
[14:22] <apuimedo> amulet tests I basically have to remove the old ones
[14:22] <apuimedo> the new one I added that can also install the enterprise edition, should be good
[14:33] <stub> Yeah, lib/charms/apt.py ends up ok but reactive/apt.py is a bag of dead chickens and the bootstrap/setup method.
 Hi,I will be developing IBM-IM as layer and I explored to make use of basic layer which is present in the "interfaces.juju.solution". and I am not sure about which interface that i can use it for IM from "interfaces.juju.solution",...? or do we need to develop IM interface seperately?? Can you please guide me on this?
[15:00] <mbruzek> shruthima: Hello again!  From the information you gave me yesterday the IBM IM layer would be a charm layer not an interface layer (which is like a relation).  So your layers.yaml would import from the layer:basic.
[15:02] <mbruzek> That will give you a starting point and you can create a charm layer in a repository such as Github or Launchapd.
[15:03] <mbruzek> at this point you shouldn't need to worry about interfaces.juju.solutions, you can make a layer off-line on your own machine. Then when you run "charm build" it will go to interfaces.juju.solutions to pull the basic layer just once
[15:06] <cory_fu> stub: While I enjoy your colorful metaphor, I'm not sure I understand why you're unhappy with the resulting reactive/apt.py?  Do you have it committed, perchance, that I might take a look?
 oh ok thank you.
[15:07] <cory_fu> A branch, perchance?  :)
[15:08] <mbruzek> shruthima: Other people on the team know about layers and reactive, you can ask technical questions about layers and reactive here and others should be able to respond.
[15:09] <mbruzek> here == #juju
[15:09] <shruthima> okie :)
[15:12] <jacekn> hello. I'm having problems understanding juju storage documentation: https://jujucharms.com/docs/1.25/storage I am looking for list of possible values for "type" parameter. I can see "type: block" in an exmaple but it's not documented anywyere
[15:12] <jacekn> also "type: filesystem" seems undocumented
[15:13] <jacekn> will something like this work at all? https://pastebin.canonical.com/149486/
[15:58] <stub> cory_fu: https://git.launchpad.net/layer-apt/tree/?h=apipackage
[15:59] <stub> cory_fu: Its not terrible, but it seems worse than what I started with.
[16:08] <stokachu> marcoceppi: \p/
[16:08] <stokachu> :(
[16:21] <jacekn> hello. I have not heard anything regarding this bug I filed 2 weeks ago: https://bugs.launchpad.net/charms/+bug/1538573 can somebody tell me if it's on charmers's radar?
[16:21] <mup> Bug #1538573: New collectd subordinate charm <Juju Charms Collection:New> <https://launchpad.net/bugs/1538573>
[18:41] <cory_fu> stub: Do you really think that users will need to manually call install_queued or ensure_package_status instead of just relying on the state system to invoke them?
[18:42] <cory_fu> marcoceppi: https://github.com/juju-solutions/layer-basic/pull/33  Thoughts?
[18:43] <marcoceppi> cory_fu: weeeee LGTM
[18:43] <cory_fu> It's untested, though.  ;)
[18:43] <cory_fu> (Testing it now)
[19:38] <jcastro> https://www.youtube.com/user/TheSmartbit
[19:38] <jcastro> does anyone know who this is so I can credit them in the summary?
[20:01] <marcoceppi> jcastro: it's probably smartbit
[20:20] <jcastro> yeah I was looking for a real name
[20:50] <stub> cory_fu: Sometimes. A simple linear @hook('install') might be preferable to half a dozen state handlers. I was also calling install_queued from inside a context manager at one point.
[20:51] <cory_fu> stub: If that's the case, might it not be cleaner to just use the existing tools in charmhelpers?
[20:52] <stub> cory_fu: I think the API is tidier in what I have, and if people like it, this would be where this bit of charmhelpers migrates too
[20:52] <stub> So I would like to support both calling styles. There doesn't seem to be any reason to not support it.
[20:53] <cory_fu> Fair enough
[20:53] <cory_fu> btw, you could avoid doing explicit aliasing if you just import those functions directly
[20:53] <stub> Which is certainly an argument in favour of sticking things in lib/charms
[20:53] <stub> Oh, duh.
[20:56] <cory_fu> I see what you mean, though, about the reactive file just ending up a place to add decorators to existing functions.  I'm not sure that I consider that a bad thing, though.
[20:56] <stub> I can argue it both ways
[20:57] <stub> I don't think these 'library' layers are typical.
[20:58] <stub> I'll go with the split unless people have other use cases for putting an API in reactive.
[20:58] <stub> But I still think it is worth doing the imports better ;)
[21:00] <stub> Given the PEPs Python3 has implemented to get absolute and relative imports working in all other cases, it will be surprising and seem broken whenever people discover it doesn't work in built charms.
[21:03] <cory_fu> Yeah, I don't disagree
[21:04] <stub> When you say 'just a place to add decorators to existing functions' I have flash backs to Zope3 and ZCML ;) At least we don't need to use XML to decorate them :)
[22:21] <wesleymason> Are there any good examples of a reactive charm using the nrpe interface? I can't seem to get the bloody thing to work.
[22:34] <marcoceppi> wesleymason: not that I'm aware of - what are you having problems with?
[22:35] <bolthole> question about juju and lxc. https://jujucharms.com/docs/1.24/troubleshooting-local-lxc doesnt mentoin how to view the actual lxc containers juju uses. doing "lxc list" doesnt show anything?
[22:38] <marcoceppi> bolthole: is this lxc local provider or lxc in a deployed environment?
[22:39] <marcoceppi> bolthole: also, if you're not using 1.24 of juju, I recommend going to the /stable/ version of the docs
[22:40] <bolthole> juju with local environment
[22:40] <bolthole> setup with juju bootstrap, etc.
[22:41] <bolthole> as far as version of docs.. I go to what google pulls up. So you guys may have some tweaking to do for google search optimization ;->
[22:42] <marcoceppi> bolthole: we've been trying to kill juju from crawling our versioned docs, so far that has been fruitless :\
[22:42] <marcoceppi> bolthole: does `lxc-ls` work instead?
[22:42] <bolthole> anyways, content is identical.
[22:42] <marcoceppi> bolthole: sure, but just a point in general
[22:43] <bolthole> lxc-ls shows nothing. (and isnt it just an alias for lxc list?)
[22:44] <marcoceppi> bolthole: `lxc list` and lxc-* are two different versions of lxc. one, lxc list, is the new LXD frontend, and the other is traditional lxc
[22:44] <marcoceppi> bolthole: do you have services deployed?
[22:44] <marcoceppi> does `lxc-ls -a` show anything?
[22:45] <marcoceppi> err `lxc-ls --fancy`
[22:45] <bolthole> nope
[22:49] <wesleymason> marcoceppi: effectively, deploy my charm, deploy nrpe, add-relation, I have a handler with a @when('local-monitors.available'), and it never fires.
[22:49] <wesleymason> Same for nrpe-external-master if I used that instead
[22:52] <marcoceppi> bolthole: what does you juju status output look like?
[22:52] <marcoceppi> wesleymason: weird, that's not the intended design
[22:52]  * marcoceppi checks interface
[22:53] <marcoceppi> wesleymason: do you mean nrpe-external-master?
[22:54] <wesleymason> marcoceppi: well using either, local-monitors for nrpe
[22:55] <marcoceppi> wesleymason: we don't have a local-monitors interface in the interface listing
[22:55] <marcoceppi> haha
[22:55] <marcoceppi> I can't read
[22:55] <marcoceppi> wesleymason: what does your metadata.yaml look like?
[22:56] <bolthole> rebuilding it right now, so cant answer :-/  but if someone with workig juju local wants to post THEIR ouptput, that would be great :)  meanwhile, I am going to be afk for a while
[22:57] <marcoceppi> bolthole: I've been running the alpha1 for a while and am using the new lxd provider - so much more awesome :)
[22:58] <wesleymason> marcoceppi: https://github.com/1stvamp/juju-errbot/blob/master/metadata.yaml
[22:58] <marcoceppi> wesleymason: that's the problem
[22:59] <marcoceppi> wesleymason: you don't require local-monitors, you provide it. The interface library is a bit incomplete - it only has one side of the protocol implemented, the more common side, which is providing local-monitors
[22:59] <marcoceppi> https://github.com/cmars/local-monitors-interface
[22:59] <wesleymason> marcoceppi: aaaaaah nuts, yes, I see it now
[22:59] <wesleymason> marcoceppi: been staring at that metadata for ages, blind
[23:00] <marcoceppi> wesleymason: it's all good. we should consider adding a check at build time that "you provide X interface but interface library does not have provides.py"
[23:01] <wesleymason> marcoceppi: good idea, I should also check my glasses prescription 😉
[23:07] <marcoceppi> wesleymason: https://github.com/juju/charm-tools/issues/105
[23:08] <wesleymason> marcoceppi: 👍
[23:08] <wesleymason> marcoceppi: also interface working fine now 😀
[23:08] <marcoceppi> \o/
[23:09] <wesleymason> Quite close to a fully working errbot charm now
[23:10] <smartbit> jcastro: Bart Smith >smartbit :-)
[23:10] <wesleymason> marcoceppi: out of interest, what's the generally accepted way to package/ship a charm built from a layer? Are people just checking into separate repos/branches, or shipping built tarballs somewhere etc?
[23:22] <marcoceppi> wesleymason: people are starting to use the charm command to upload/publish them into the store
[23:22] <marcoceppi> wesleymason: but that's still a private beta, otherwise, they're putting their layers into VCS they like then the charm artifcat that's built is just uploaded to bzr like charms have been in the past


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


[00:03] <ehammer> can anyone tell me where the network manager is located? ty
[00:10] <valorie> ehammer: located?
[00:10] <valorie> soee: I'll try
[00:10] <valorie> let me read up
[00:30] <ehammer> valorie, no I don't see it
[00:30] <ehammer> sorry for the delay
[00:30] <ehammer> ty
[00:31] <valorie> you mean you don't see the icon?
[00:31] <valorie> you should be able to right-click in the taskbar and add icons, depending on your kubuntu version number
[00:31] <valorie> it is not clear what you are running
[00:57] <koppany> hello
[00:58] <koppany> is anyone here?
[01:01]  * valorie leaves for dinner; hope you get the help you need, ehammer
[02:41] <pablo> lkkkllk
[02:41] <pablo> ñññ
[02:41] <pablo> ññlññ
[02:41] <pablo> {ñ{ñ{
[07:15] <soee> good morning
[08:51] <kubuntu> hi all
[08:52] <rosgani> hi all
[08:58] <lordievader> Good morning.
[08:58] <rosgani> hi
[08:59] <lordievader> Hey rosgani, how are you?
[09:08] <lordievader> rosgani: Please keep conversations in channel. Unasked PM'ing usually is frowned upon.
[09:09] <lordievader> rosgani: I am doing good, though.
[09:10] <lordievader> rosgani: Let's join #kubuntu-offtopic.
[12:32] <BluesKaj> 'Morning folks
[13:29] <mattnpat> Hey.
[13:30] <mattnpat> I don't even use kubuntu, I think I'm using BSD, but have a nice day everyone.
[14:07] <AciD`> what can you do when xorg uses 2.7GB of RAM? Is there a way to force xorg to flush some ram without killing every X apps ?
[14:11] <BluesKaj> AciD`, i guess it depends on how many open apps require xorg
[14:11] <AciD`> BluesKaj > all those I don't want to close :)
[14:12] <AciD`> mainly kwin
[14:12] <BluesKaj> then it looks like you have to lkive with it
[14:12] <BluesKaj> live
[14:13] <AciD`> :(
[14:13] <BluesKaj> any open games etc?
[14:13] <lordievader> Err, Xorg should not hold the ram of its children.
[14:14] <lordievader> I don't have X anywhere in reach to check its memory usage here.
[14:14] <AciD`> xrestop tells me kwin uses 2GB just for himself
[14:14] <BluesKaj> AciD`, what are you using to monitor memory usage?
[14:14] <AciD`> ^
[14:15] <AciD`> (and ctrl+esc usually)
[14:16] <AciD`> BluesKaj > I don't have any open game currently, but I had some yesterday with wine
[14:19] <Captain_Haddock> Xorg is using 23MB memory + 156MB shared memory here.
[14:20] <lordievader> As I figured, so if it uses 2.7Gb something is wrong...
[14:22] <BluesKaj> AciD`, what is the exact number shown in xrestop for kwin?
[14:22] <AciD`> http://paste.ubuntu.com/10173720
[14:24] <AciD`> I missread, it's 2.3GB, not 2.7
[14:24] <lordievader> AciD`: How much does top or ps report?
[14:24] <AciD`> (or perhaps it changed since I restarted kwin 2 times now)
[14:25] <lordievader> I might be reading wrong, but isn't it ~220 mb?
[14:26] <AciD`> http://paste.ubuntu.com/10173782
[14:26] <AciD`> weirdly, xrestop tells me kwin is taking all the xorg memory, but top does not picks up on that
[14:27] <lordievader> AciD`: How much ram in in your system?
[14:27] <AciD`> 16GB
[14:27] <BluesKaj> AciD`, that's not Gb, that's mb from what I can see 213554K=213554000=21mb
[14:29] <AciD`> http://i.imgur.com/e2Dlwil.png
[14:29] <AciD`> 2.314GB ram, 1GB shared for Xorg
[14:30] <BluesKaj> ok
[14:30] <AciD`> since reloading kwin with `kwin --replace` (with or without compositing) did not solve the problem
[14:31] <AciD`> I guess I'll have to reboot :(
[14:31] <AciD`> except if you see another solution
[14:37] <AciD`> after reboot, xorg uses 324MB, 830MB shared
[14:37] <AciD`> far better
[14:38] <Captain_Haddock> AciD`: That still seems high.
[14:38] <AciD`> Captain_Haddock > it's at 175MB when starting (I use a 2560x1440 display btw)
[14:38] <Captain_Haddock> Ah
[14:38] <AciD`> when I launch firefox + freemind + inkscape it jumps up
[14:39] <AciD`> (given those are not kde apps unfortunatly)
[14:39] <AciD`> *qt
[15:31] <lordievader> FWIW: X uses 20Mb here with 33Mb shared.
[15:32] <lordievader> Full-HD resolution.
[16:07] <johnn> after ysterday update kubuntu 14.10 plasma preview 64 is not working.
[16:08] <johnn> systemd error: get error saying sddm userfailed somthing like that....
[16:33] <StellaD> Καλησπερα, υπαρχει καποιος online να με βοηθησει σε εγκατασταση σε netbook παρακαλώ?
[16:36] <lordievader> !ru | StellaD
[16:37] <StellaD> English?
[17:02] <ceibal_> Hoola
[17:12] <jbwiv> guys, I'm running stock ubuntu 14.10, but would like to try plasma5. is the kubuntu-ppa/next the preferred way of doing this?
[17:17] <BluesKaj> jbwiv, yes
[17:17] <jbwiv> BluesKaj: ok, thanks. What's the best way to install without doing a full kubuntu-desktop install? I'd like to install it but maintain my normal ubuntu file associations, default apps, etc
[17:19] <BluesKaj> jbwiv, add the ppa , update /upgrade then dist upgrade https://launchpad.net/~kubuntu-ppa/+archive/ubuntu/next
[17:20] <jbwiv> BluesKaj: ok ,but won't that install the full kubuntu dist? For example, won't it replace lightdm with kdm, etc?
[17:22] <BluesKaj> jbwiv, plasma is still under development so if you're on a production machine on the job etc I would wait til KDE5 is officially released
[17:22] <jbwiv> BluesKaj: ok, fair enough. thank you
[17:22] <jbwiv> I'll give it a shot in a vm
[17:23] <BluesKaj> jbwiv, personally I'm not a big fan so far
[17:23] <jbwiv> BluesKaj: oh really? that's a shame...I held high hopes ;)
[17:24] <jbwiv> the state of the linux desktop is really sad. unity is broken, gnome3 isn't much better, and kde seems to be digressing as well
[17:24] <BluesKaj> I'm testing 15.04 which has plasma 5,2 and KF5 and there are some annoyances, some more serious than others
[17:25] <BluesKaj> jbwiv, yes I'm not liking the the direction that KDE is taking with plsama 5
[17:26] <BluesKaj> 14.10 with plasma 4 is as solid and stable as anything I've used in linux
[17:28] <serpardum> Software Updater comes up every day and says it wants to update. so I say install now, then it complains that some things are unsecure and I'll need to change the settings. But it never says *what* is unsecure or what settings to change. Anyone?
[17:31] <serpardum> "Requires Installation of untruste dpackages This requires isntalling packages from unauthenticed sources". It doesn't say which package or what it's complaining about
[17:31] <serpardum> There is no details or log to look at I can see either
[17:33] <serpardum> any why my calender is in spanish I don't think I'll ever figure out
[17:43] <mr-rich> serpardum: have you added any third party repos?
[17:45] <serpardum> Hmmm. I've isolated it to plex home theatre which doesn't worka nd needs an update anyway
[19:18] <designbybeck_> If my computer goes to sleep or if I lock it and go away for awhile, kwin pegs the CPU at 100% (or higher oddly) and I can't the screen will not let me interact with anything, so I have to go to a TTY and kill kwin, then go back and start it
[19:30] <designbybeck_> This happened with Kubuntu 14.10 and then I did a clean install of 14.04.1 and it still does it
[19:30] <designbybeck_> I have installed the latest NVIDIA driver
[19:30] <designbybeck_> but seemed it was doing it with or without that installed
[21:47] <rberg_> I have been having a issue where plasma freezes for a few min when my laptop wakes up, by freeze I mean the clock doesnt update and clicking on anything in the tray does nothing until it unfreezes then everything I clicked on opens.. does anyone know what can be done about this annoyance?
[21:49] <rberg_> oh and the reason I believe its plasma is because if I attempt to suspend again it will fail and dmesg reports plasma as the reason it was unable to freeze
[22:10] <rberg_> my problem seems to be related to laptop-mode-tools. with that removed I cannot reproduce
[22:13] <ac101> irc://irc.quakenet.org/assaultcube
[22:13] <ac101> server=irc://irc.quakenet.org/assaultcube


[13:03] <thopiekar> hi
[13:04] <thopiekar> is this the right place to ask a question about my driver problem?
[13:06] <matti> thopiekar: Just ask.
[13:06] <thopiekar> I've got a "Genius VideoCam Look" webcam which was working before on jaunty.. I was just waiting for a driver fix because I thought my problem is because of the new kernel.. but until now it isn't fixed.. have you got a solution?
[13:08] <matti> thopiekar: Is there a bug open by any chance?
[13:08] <thopiekar> this website says that I should have a "microdia " webcam.. http://groups.google.com/group/microdia/web/howto-get-information-on-your-webcam
[13:08] <thopiekar> matti: hmm haven't found something on launchpad now..
[13:09] <matti> thopiekar: Try too search for a possible bug and if there isnt one, open it.
[13:09] <matti> I have to go and catch a train to London :(
[13:10] <matti> Perhaps somebody else can help you ;]
[13:10] <matti> thopiekar: Good luck!
[13:10] <thopiekar> ok, matti, see ya :)
[13:10] <matti> ;]
[13:10] <thopiekar> thanks matti
[14:09] <apparle> I am getting this error Initialized empty Git repository in /home/apparle/ubuntu-lucid/.git/ kernel.ubuntu.com[0: <IP_ADDRESS>]: errno=Connection refused fatal: unable to connect a socket (Connection refused)
[14:09] <apparle> on this command
[14:09] <apparle> git clone git://kernel.ubuntu.com/ubuntu/ubuntu-lucid.git
[14:14] <apparle> how to get git working behing proxy
[16:58] <hyperair> hmm recent versions of the kernel have failed with make-kpkg
[16:58] <hyperair> ever since include/linux/utsrelease.h got moved to include/generated/utsrelease.h


[11:24] <jeronimo> My ubuntu server 22.04 live image hangs on my very old rack server(HP G7)
[11:24] <jeronimo> after grub
[11:25] <jeronimo> after I select try or install
[11:43] <jeronimo> GRUB error: can't find command 'grub platform'.
[11:44] <lotuspsychje> maybe related to bug #1905491 jeronimo ?
[11:46] <jeronimo> lotuspsychje: yes, I was about to ttry to convert GPT to MBR.
[11:55] <jeronimo> is there an easy way to do this? I don't have the energy to do some complicated scenario
[12:39] <jeronimo> ok I went back to ubuntu 20.04 because 22.04 did not support my old server
[12:41] <jeronimo> hoping to finally get a ceph cluster working with maas and juju
[22:26] <MaNa2k> lol just guessed my way into this channel
[22:26] <MaNa2k> happy to see it exists
[22:27] <MaNa2k> :P


[22:38] -SwissBot:#xubuntu-devel- ::xfce4-announce:: ANNOUNCE: xfce4-settings 4.15.3 released @ http://xfce.10915.n7.nabble.com/ANNOUNCE-xfce4-settings-4-15-3-released-tp59597.html (by Simon Steinbeiss)
[23:19] <Unit193> !info xfce4-settings experimental
[23:19] <Unit193> xfconf in Debian has gir support. \o/
[23:22] <ochosi> i guess that's good news for the notes plugin
[23:27] <Unit193> Hrm, I thought Sean wanted that for xfce4-screensaver and maybe catfish too?


[10:38] <somerville32> haha
[10:39] <somerville32> I wonder if this was done by an OpenSUSE member
[10:42] (somerville32/#launchpad) I was just going to ask the same question
[10:42] (somerville32/#launchpad) pirast volunteered
[10:42] (somerville32/#launchpad) <g>
[10:49] <somerville32> Are lp admins around? LP is being trolled.
[10:51] <danilos> somerville32: what do you mean?
[10:51] <somerville32> Bug #1 was vandalized
[10:51] <Ubugtu> Malone bug 1 in Ubuntu Dapper "Microsoft has a majority market share" [Critical,Confirmed]  http://launchpad.net/bugs/1
 hey guys, can we get an account on launchpad shut down?
 https://launchpad.net/people/spymac-sucks is messing with the bugtracker
 thanks!
[10:52] <pirast> hi, where can I post suggestions to rosetta (which ml)?
[10:54] <danilos> pirast: rosetta-users
[10:55] <pirast> danilos, thanks.. :-)
[10:58] <danilos> stu1: if you're around, can you help with disabling https://launchpad.net/people/spymac-sucks?
[11:47] <Hobbsee> danilos: thanks for some action
[05:56] <finek> hi
[05:56] <finek> i get an email from You
[05:56] <finek> and i don't know why
[05:58] <finek> ?
[05:59] <LarstiQ> could you be more specific?
[05:59] <yankees26> much more
[05:59] <finek> i don't know how
[06:00] <yankees26> whats in it?
[06:00] <finek> Thank you for registering at Launchpad. To complete your registration,
[06:00] <finek> please follow the instructions here:
[06:01] <LarstiQ> finek: I get all kinds of mail from the launchpad system since I have an account I actively use. What is in your mail?
[06:01] <finek> i don't regiseter
[06:01] <yankees26> then someone used your email address probably
[06:01] <finek> is it spa,m?
[06:01] <yankees26> or you have amnesia and dont remember registering
[06:01] <finek> no
[06:01] <finek> nothing like this
[06:01] <LarstiQ> finek: possibly someone else registered your email, or it is the result from some conversion (from old ubuntu bugzilla, python sf.net tracker, etc)
[06:02] <LarstiQ> finek: I doubt it's spam.
[06:02] <yankees26> its probably what LarstiQ said
[06:02] <yankees26> in the FAQ there is something about not registering an account but having one anyway
[06:03] <finek> strange
[06:03] <yankees26> https://launchpad.net/faq
[06:03] <yankees26> third question
[06:03] <finek> thx
[06:05] <finek> what is launchpad-integration
[06:11] <LarstiQ> finek: iirc, an ubuntu package to make integration with launchpad easier
[06:12] <LarstiQ> finek: ie, when an app on ubuntu crashes, file a bug report directly, or go to the translations, etc
[06:12] <finek> ok
[06:13] <finek> thx
[06:13] <finek> bye
[06:15] <LarstiQ> Next time I should ask if it is an ubuntu user
[06:21] <yankees26> why?
[06:21] <yankees26> LarstiQ: ^
[06:22] <yankees26> o wait i see, never mind
[06:22] <yankees26> and fyi: im not an ubuntu user :P
[06:22] <LarstiQ> yankees26: exactly :)
[06:31] <ryanakca> does someone want to reset the topic?
[06:31] <ryanakca> last it was (from what I see) is: "Developer meeting: Thu 30 Nov, 1200UTC (wiki:MeetingAgenda) |<EMAIL_ADDRESS>(wiki:MailingLists) | Channel logs: http://tinyurl.com/72w39"
[06:35] <LarstiQ> yankees26: update makes sure the working tree is at the same version as the branch. If you are working in a checkout, the consequence is to make it up to date with the master branch.
[06:35] <yankees26> whoa....
[06:35] <LarstiQ> yankees26: whereas a pull gets revisions from the parent branch (and as a side effect updates the working tree, hmm)
[06:36] <yankees26> completely forgot i asked that (yesterday i think)
[06:36] <yankees26> thanks
[06:36] <LarstiQ> so yes, I do read backlog on occassion ;)
[06:36] <yankees26> heh
[06:36] <yankees26> i currently work on the pull/push branch method as opposed to checkout
[06:37] <yankees26> which is better if you are the only dev?
[06:37] <LarstiQ> it's not necessarily along the axis of number of devs :)
[06:37] <yankees26> ok
[06:37] <yankees26> which is better from development point of view?
[06:38] <LarstiQ> For some of my branches I'm the only dev on, I keep a checkout on my laptop/desktop, with the master on my server
[06:38] <LarstiQ> but for things only going on on my laptop, I just branch
[06:38] <yankees26> ah
[06:38] <yankees26> my current setup is i do most of my work from my linux comp and push
[06:38] <LarstiQ> yankees26: if you want to make sure a 'public' branch has the same revisions as what you are working on, using a checkout is a good idea
[06:38] <yankees26> to the launchpad server
[06:39] <yankees26> LarstiQ: the user checksout or i use a checkout?
[06:39] <LarstiQ> yankees26: that is what I used to do. But I've forgotten to push a couple of times, and wouldn't have the most up to date version when I was elsewhere
[06:39] <LarstiQ> yankees26: the developer
[06:40] <yankees26> LarstiQ: ok
[06:40] <yankees26> i think i've switched to a checkout on the mac yesterday
[06:40] <yankees26> now for linux
[06:40] <LarstiQ> it all depends on your workflow
[06:40] <yankees26> i do like that bzr commit also pushs it when you use a checkout
[06:41] <LarstiQ> yankees26: if you are on a slow link however, the network connection for every commit can be a pain
[06:41] <yankees26> im on broadband so i feel safe
[06:41] <yankees26> for that
[06:42] <LarstiQ> you could use commit --local if you weren't :)
[06:42] <yankees26> (even though my god damn ISP doesn't allow servers)
[06:42] <yankees26> ah
[06:43] <yankees26> and now i have a checkout :D
[06:43] <yankees26> (on linux)
[06:59] <YoussefAssad> oh, wait...
[07:00] <LarstiQ> and I'm off, ciao!
[07:00] <yankees26> bye
[08:55] <rawler> am I the only one with terrible response-times from launchpad.net right now? (in the several minutes magnitude)
[08:57] <rawler> probably not since I ended up in a proxy error...
[08:59] <mpt> Gooooooooooooooooooooood morning Launchpadders!
[09:05] <Brushy> Hello
[09:05] <Brushy> Is the server down or something, because I finish my registeration
[09:06] <rawler> seems likely, yes.. :)
[09:06] <Brushy> :/
[09:09] <mpt> It's working for me
[09:09] <rawler> it kicked back in for me as well now.. :)
[09:11] <Brushy> yeah, seems so
[09:17] <Brushy> seems to be down again :/
[09:17] <rawler> yeppers.. :S
[09:17] <rawler> entirely dead this time.. :S
[09:42] <mpt> bother
[09:43] <yankees26> its working for me?
[09:43] <yankees26> (if you mean the website, and ignore that question mark)
[09:43] <mdke> not for everyone, though
[09:45] <mdke> ah, that's better