[15:59] <AnhVoMSFT> @Odd_Bloke @blackboxsw_ @rharper any rough ETA on when the next SRU of cloud-init will be?
[16:09] <Odd_Bloke> AnhVoMSFT: Within the next couple of weeks: once https://github.com/canonical/cloud-init/pull/528 is landed, and once https://github.com/canonical/cloud-init/pull/514 has been approved (that's a packaging change, so it won't "land" per se), we'll be starting to look at it.
[17:41] <Odd_Bloke> FYI for fokls who aren't already aware: I will be on vacation for a couple of weeks starting at the end of this week.
[17:42] <Odd_Bloke> ("fokls" <-- I am evidently in need of a vacation ;)
[18:33] <AnhVoMSFT> Thanks @Odd_Bloke
[19:38] <rharper> eandersson: hey , I saw your reponse on the openstack timeout issue;
[19:39] <rharper> eandersson: I was hoping to see a cloud-init log (or if you know) whether the timeout is seen during cloud-init-local.service where it's bringing up the ephemeral dhcp client, or if it's seen much later ...  and if you're using latest cloud-iinit on ubuntu or something else?  I'd really like to rule out that it's not the classless static route issue
[19:42] <eandersson> rharper http://paste.openstack.org/show/Udy604fiNCxNqP9pTV7D/
[19:43] <eandersson> So I have seen a couple examples of this and we can reproduce it pretty easily.
[19:43] <meena> rharper: what is, "the classless static route issue"?
[19:44] <eandersson> This is on CentOS. I haven't tried it on Ubuntu.
[19:44] <eandersson> But the underlying issue is basically either network or something not quite fast enough on the OpenStack side.
[19:45] <eandersson> When creating a ton of VMs (e.g. 200+ VMs at the same time)
[19:45] <eandersson> When I tested by allowing it to retry at least a few times it would never fail.
[19:45] <rharper> https://bugs.launchpad.net/cloud-init/+bug/1821102
[19:45] <rharper> meena: ^
[19:46] <rharper> it's sense been fixed
[19:46] <rharper> eandersson: thanks, lemme look
[19:46] <rharper> scale testing sounds like dhcp response times are slow; so it's likely unrelated to the bug I mentioned;
[19:47] <eandersson> My motivation is really that if something like the EC2 (Amazon) data source has a retry, it is very reasonable that the OpenStack should be allowed to retry at least a couple of times.
[19:48] <eandersson> But it's easy to just override the default cloud-init pages so it's not a hill I would die on. :D
[19:48] <eandersson> *settings
[19:48] <rharper> right, i'm still trying to see if we're failing to bring up networking correctly, or if it's the IMDS itself that's failing;  the snippet is hard to see the whole contenxt
[19:49] <Odd_Bloke> A big difference (until recently, of course) is that EC2 only had Intel hardware, so we would always be able to determine that we were on EC2 reliably (and maybe we still can in their ARM, I don't recall).
[19:49] <eandersson> Yea - I unfortunately don't have the full logs at the moment.
[19:49] <Odd_Bloke> So EC2 can configure a timeout because that timeout should only affect EC2 instances.
[19:50] <eandersson> But this issue is for sure that either the network (e.g. vxlan) or dhcp / network namespace / security group isn't ready.
[19:50] <rharper> eandersson: it does look like this is during early boot and the ephemeral dhcp; I see the ip commands which tear down what we brought up
[19:51] <rharper> eandersson: if possible, it would be great to see an Ubuntu log where I know we've got the classless static routes issue fixed;
[19:51] <eandersson> How would that bug be presented?
[19:51] <eandersson> Reading
[19:52] <rharper> so,  looking at the logs for the bug I posted
[19:52] <rharper> they look almost exactly like yours
[19:53] <rharper> http://paste.openstack.org/show/796830/
[19:53] <eandersson> It's for sure not the same issue because we don't have an additional route for 169
[19:54] <eandersson> and the metadata proxy is local on the hypervisor
[20:00] <rharper> ok; if it's not the bug and it's a slow metadata service; and 50 seconds isn't enough (10 second timeout * 5 retries); we're left with bumping a default for openstack which makes the remaining network datasources to wait longer;
[20:00] <eandersson> Yea - I mean an alternative would just to be add some documentation tbh.
[20:00] <rharper> Odd_Bloke: one area we didn't continue the discussion on was whether we should sort the datasource_list by total wait time (timeout * retries)
[20:01] <rharper> configdrive is still an option for openstack;
[20:03] <eandersson> I have never seen it fail more than once btw.
[20:04] <eandersson> I probably could make it fail more, but would need to create a lot of VMs :D
[20:04] <rharper> well, it already retries 5 times; with 10 second timeouts before retry
[20:04] <eandersson> It does not
[20:04] <rharper> well, then I want to see that log
[20:04] <rharper> what you posted showed exactly one; the default for openstack is 10 second timeout and 5 retries
[20:04] <eandersson> > Giving up on OpenStack md from ['http://<IP_ADDRESS>/openstack'] after 0 seconds
[20:04] <eandersson> The TCP timeout is indeed 10s
[20:04] <eandersson> Which is why it "waits for 10s"
[20:05] <eandersson> That code path does not adher to the retries
[20:07] <rharper> eandersson: I don't understand; https://github.com/canonical/cloud-init/blob/master/cloudinit/sources/__init__.py#L172  this is the default config for all datasources, unless the subclass overrides;
[20:07] <rharper> DataSourceOpenstack.py does not have an override (expect in your PR);
[20:08] <rharper> so, I see no reason why OS would *not* retry the expected 5 times;   unless we're not getting 404; and there's some url_helper path that's skipping the retry ...
[20:08] <rharper> hence needing the logs
[20:09] <eandersson> It's because the code path uses wait_for_url
[20:09] <eandersson> https://github.com/canonical/cloud-init/blob/411dbbebd328163bcb1c676cc711f3e5ed805375/cloudinit/sources/DataSourceOpenStack.py#L82
[20:09] <eandersson> It does not even pass on the retries
[20:10] <eandersson> It basically only uses the max_wait_seconds to determine how long it will retry for
[20:10] <eandersson> In this case it's -1 (no retries) so it never retries
[20:10] <johnsonshi> Odd_Bloke: Thanks for your always reviewing my PRs Odd_Bloke! I believe my PR (https://github.com/canonical/cloud-init/pull/468/) is finally ready.
[20:10] <eandersson> It does however use the tcp timeout. So it may look like it tries for "10 s"
[20:10] <blackboxsw_> Odd_Bloke: you mentioned a couple of prs that needed review, I just +1'd https://github.com/canonical/cloud-init/pull/531 were there 2 others that needed eyes?
[20:11] <eandersson> https://github.com/canonical/cloud-init/blob/master/cloudinit/url_helper.py#L344 wait_for_url is defined here
[20:13] <rharper> yeah; I see the try once with -1 ; which is the default;
[20:25] <eandersson> Yea - that code path is just so unforgiving
[20:26] <rharper> so, CloudStack, Ec2, Exoscale, MAAS, and Openstack (ignoring ovf since it's local ds mostly); all have max_wait set to something other than default;
[20:26] <eandersson> And there are so many things that happens at the same time when spawning a new VM.
[20:26] <Odd_Bloke> blackboxsw_: Ryan beat you to them. :)
[20:26] <Odd_Bloke> (Thanks for the review!)
[20:26] <blackboxsw_> that's the spirit !
[20:26] <rharper> only OpenStack and MAAS, I think support multi-arch
[20:26] <Odd_Bloke> Obviously more thanks to rharper for doing multiple reviews. ^_^
[20:27] <rharper> Odd_Bloke: sure
[20:27] <rharper> man, Xenial is the killer here (and maybe other OS which use cloud-init but don't use ds-identify)
[20:28] <Odd_Bloke> johnsonshi: My pleasure!  I'm taking another look through the code to confirm that I'm happy with it, but note that I would like you to revert your removal of the type annotations before it lands.
[20:28] <rharper> it will walk each DS at network time; so putting a large max_wait means pain for anything coming after it
[20:31] <AnhVoMSFT> @Odd_Bloke - regarding typehints, what is your recommendations regarding other distros like RHEL/CentOS/SUSE, who have many enterprise customers that continue using it for at least another 3-5 years? There are features that we should be delivering them irrespective of the python version. Do you recommend we send another PR to stable-19.4 with the exact change except dropping the typehints
[20:31] <AnhVoMSFT> in that PR?
[20:31] <johnsonshi> Odd_Bloke: Thanks for the note about the type hints. Any recommendations for the pre-existing RHEL and CentOS image maintainers out there? Those images will still be supported for a few more years.
[20:32] <AnhVoMSFT> oops, didn't realize johnsonshi was on IRC just now and asking same question :-)
[20:36] <Odd_Bloke> I don't have any particular recommendations, no: it really depends on how they handle backporting cloud-init changes (and, for that matter, how their distro/company handles backporting Python 3-only projects to their Python 2-only releases more generally).  Or, expressed another way: I would expect them to know better than any recommendation I could give. :)
[20:37] <Odd_Bloke> I think using `stable-19.4` would be appropriate, but note that the type annotations are not the only way in which cloud-init code cannot run on Python 2 any longer, so just removing them may not be sufficient.
[20:37] <Odd_Bloke> Of course, it's only worth using `stable-19.4` if the maintainers of the existing images will use it, so you'd need to coordinate that with them.
[20:39] <AnhVoMSFT> is typehints going to be a requirement for all new methods going into cloud-init?
[20:39] <rharper> Odd_Bloke: so I think the best test of the cost of changing openstack max_wait to something other than -1 would be ec2 xenial boots; which at this time still are not ds-identify strict; so it will walk all of the ds in the list;  we could look at the current boot time now;  make the change to openstack per eandersson PR and retest  boot to see the impact
[20:40] <Odd_Bloke> AnhVoMSFT: Not a requirement, but I would expect they will become used more generally as people adapt to being able to use them.
[20:40] <Odd_Bloke> And I would like to discuss the timeline for dropping 3.4 support at the summit, after which point we would be able to use the `typing` module; I would expect an uptick in their use then, too.
[20:41] <Odd_Bloke> (We can only annotate simple cases without `typing`, which obviously reduces the number of annotations across the codebase.)
[20:41] <AnhVoMSFT> Given that this PR brings more clarity due to the refactoring and additional telemetry ( we previously did not capture the call to extract goal state ), I think the typehints isn't the major enhancement and dropping it doesn't really make the code worse (the code is being made better by the refactoring, it's not being made worse because the typehints weren't there to start with)
[20:42] <AnhVoMSFT> by extract goal state I mean extracting the certificates.xml - duh
[20:43] <Odd_Bloke> To be clear, I didn't say that the PR made our codebase worse, I said that type annotations make our codebase better.
[20:44] <Odd_Bloke> I'd be happy to accept the type annotations in a follow-up PR, if that would give you an easier-to-backport commit?
[20:44] <johnsonshi> Odd_Bloke AnhVoMSFT: Thanks to both of you for clarifying. :) What should the next steps be for my PR?
[20:46] <johnsonshi> AnhVoMSFT Odd_Bloke: Ok I'll be going with that suggestion and have that in a follow up PR instead. Thanks folks.
[20:46] <AnhVoMSFT> I think we should address the typehints in a follow-up PR, perhaps adding typehints to all the methods in DataSourceAzure, that'll be cleaner and provide better static analysis during testing too
[20:47] <Odd_Bloke> AnhVoMSFT: We won't be able to add them to all the methods until we have `typing` access, but I agree that typing as many as we can currently would be great!
[20:50] <AnhVoMSFT> Thanks @Odd_Bloke - I think one topic for the cloud-summit this time should be on how distro maintainers (mostly looking at RHEL, SUSE, Oracle Linux) plan on packaging cloud-init to support their python 2.7 and python 3.4 customers
[20:50] <Odd_Bloke> johnsonshi: AnhVoMSFT: Landed! :)
[20:51] <johnsonshi> Odd_Bloke: Woooo! :) I think that was the first substantial PR I made in the cloud-init codebase. Thanks for reviewing! :)
[20:53] <Odd_Bloke> johnsonshi: Thank you for your work, and congratulations! :)
[20:54] <Odd_Bloke> AnhVoMSFT: Agreed, that would be a good topic to include.
[20:56] <Odd_Bloke> rick_h: AnhVoMSFT has suggested including a summit topic on how distro maintainers who still have to maintain packages for Python 2.7 systems (and, once we drop 3.4 support, 3.4 systems) can collaborate.  We wouldn't have any skin in that game as Ubuntu (xenial is on 3.5), but I think it would be a really valuable topic for us to facilitate as cloud-init upstream.
[20:56] <AnhVoMSFT> johnsonshi I'm looking forward to the follow-up PR. I think there are quite a few important things to follow up
[21:02] <rick_h> Odd_Bloke:  AnhVoMSFT that makes sense. I'll add it to the topic list. I think this is another place that having the discourse category for cloud-init might be of use. I don't have permission to set it up but working on getting it enabled.
[21:04] <robjo> What determines the Data source dependencies?
[21:05] <robjo> Seeing some flakiness in Azure
[21:05] <Odd_Bloke> robjo: "dependencies" in what sense?
[21:05] <robjo> Looking for data source in: ['Azure', 'None'], via packages ['', 'cloudinit.sources'] that matches dependencies ['FILESYSTEM', 'NETWORK']
[21:06] <robjo> IN this case the Azure data source does not get loaded, i.e. I end up with Searching for network data source in: ['DataSourceNone']
[21:06] <robjo> but when I get: "Looking for data source in: ['Azure', 'None'], via packages ['', 'cloudinit.sources'] that matches dependencies ['FILESYSTEM']
[21:07] <robjo> then the Azure data source gets loaded and the instance gets provisioned
[21:07] <robjo> there is no message in the importer, thus I don't know if we are trying to load the Azure data source and it fails and gets discarded, that would then point to Azure
[21:07] <rharper> robjo: in sources/DataSourcesAzure.py   at the bottom, there should be 'datasources = []'
[21:08] <rharper> robjo: Azure has been local (DEP_FILESYSTEM) for some time
[21:08] <rharper> it uses the EphemeralDHCP to bring up networking to fetch the network config from IMDS; so it wants to only run at local time;
[21:09] <rharper> well, not an empty array, but that's where it's defined;
[21:10] <robjo> It has "datasources = [
[21:10] <robjo>     (DataSourceAzure, (sources.DEP_FILESYSTEM, )),
[21:10] <robjo> ]
[21:10] <robjo> "
[21:10] <robjo> so that looks OK
[21:10] <rharper> yrd
[21:10] <rharper> yes
[21:11] <rharper> that's what's in master
[21:11] <robjo> still running 19.4 but that's there already
[21:12] <robjo> so where does the "NETWORK" part come from and why do I end up with None being loaded instead of Azure?
[21:13] <robjo> None has both dependency on "sources.DEP_FILESYSTEM, sources.DEP_NETWORK"
[21:14] <rharper> so stages.py:init runs a fetch() which calls the datasource fetch code, this looks for <site-pages>/cloudinit/sources/*.py;  for each of those files, it checks for the datasource attribute; and extracts the array and sees if there is a datasource class name DataSourceXXX, that has deps that match;
[21:14] <rharper> robjo: it sounds like something went wrong at cloud-init-local.service time;  such that when cloud-init.service runs (which runs with mode=dsnet NETWORK deps) that it's still looking for a datasource
[21:15] <rharper> there isn't a NETWORK Azure datasource, it only runs at local time
[21:15] <robjo> so the Azure data source gets discarded because of no network dependency
[21:15] <robjo> fair enough, but how do I get there in the first place?
[21:16] <rharper> the question in the log is why wasn't Azure found at local time
[21:17] <rharper> if you make it to cloud-init.service (stage 2) on Azure without finding the datasource then it's all going downhill from there
[21:18] <rharper> Azure its found via several checks, azure_chassis in DMI data, or if it has an azure seed dir or a specific ovf-env.xml file;
[21:19] <eandersson> Thanks rharper. Let me know how it goes. I have alternative ideas if the impact is too large.
[21:21] <rharper> eandersson: ok, I'll append the suggested test to the PR;
[21:23] <robjo> OK, yes, 'local' never runs, the log file starts with: "Cloud-init v. 19.4 running 'init' ...."
[21:25] <rharper> that's do it
[21:25] <rharper> *that'll do it*
[21:26] <robjo> Interesting that this is not consistent and region dependent and storage class dependent....
[21:27] <rharper> that sounds quite odd
[21:27] <rharper> maybe then a race
[21:27] <rharper> so sometimes if there's a systemd unit race, systemd will evict a unit
[21:27] <rharper> can you check in the logs for 'cycle' I think is what systemd emits
[21:29] <robjo> systemd expects a live system, AFAIK, given that the system with the condition never boots I can only extract information by attaching the system disk from the failed system
[21:31] <rharper> should be in syslog or messages; or if your image writes persistent journal, then you can offline journalctl --directory /path/to/journal  to dump
[21:38] <robjo> thanks, time to go dig, messages file is empty so there are obviously other issues and journald is setup to forward to rsyslog
[22:03] <AnhVoMSFT> I felt like I ran into this problem before, with init running but not init-local
[22:04] <AnhVoMSFT> which distro is this?
[22:08] <rharper> AnhVoMSFT: likely suse related


[16:19] <jamescarr> hey guys, another upstart question
[16:20] <jamescarr> is there a way to ensure something executes on startup when EVERYTHING ELSE has started?
[16:20] <jamescarr> I have a service that needs to start when at least two other services have started
[16:32] <jodh> jamescarr: "start on (started service-a and started service-b)". There is no "everything else" - jobs start and stop for the lifetime of the system boot.
[16:33] <jamescarr> jodh: yeah I think what you said is what I need
[16:33] <jamescarr> basically, I need this script to run once docker is running and networking has been configured ;)
[16:33] <jamescarr> the problem was it was running before networking was configured or docker was running
[16:34] <jamescarr> so sometimes it worked sometimes it didnt
[16:34] <jodh> jamescarr: take a look at upstart-events(7) or http://upstart.ubuntu.com/cookbook/#ubuntu-well-known-events-ubuntu-specific as there are generally events for most stages of the boot.
[16:49] <SpamapS> jamescarr: I'd do 'start on runlevel [2345]' and then in pre-start do 'exec start wait-for-state WAITER=myjob WAIT_FOR=docker'
[16:50] <SpamapS> jodh: btw any movement on state awareness for upstart?
[16:51] <jamescarr> SpamapS: didn't know about that pre-start thing
[16:51] <jamescarr> thanks!
[16:52] <SpamapS> jamescarr: it is less than obvious, but it solves the problem in a more robust way (it will force docker to start if it is not yet starting)
[16:52] <jamescarr> yeah I like that
[16:55] <jodh> SpamapS: not recently I'm afraid. Still something we're considering as mentioned in the LinuxCon talk.


[00:58] <bob2> 'clone' was deprecated?
[01:29] <lifeless> yes, it isn't what git means by clone, nor hg, so it was confusing (it was deprecated -ages- ago)
[01:30] <bob2> hm, in the sense that it "clones" a branch not a repo like hg/git?
[01:30] <lifeless> right
[01:30] <bob2> fairynuff
[01:31] <lifeless> possibly it ca come back with colocated setups
[05:38] <infinet> how to resume an interrupted "bzr branch lp:xxxxx " command?
[05:39] <bob2> afaik you're boned unless you run it in a shared-repo
[05:39] <AuroraBorealis> why are you boned? try just running the command again
[05:40] <AuroraBorealis> they say that bzr is failure resiliant
[05:40] <bob2> pretty sure it won't use the already downloaded data
[05:40] <AuroraBorealis> well a branch operation is pretty easy to just start over anyway so if it doesn't then it doesn't matter :>
[05:40] <infinet> it says "bzr: ERROR: Target directory "calibre" already exists.", so seems like have to delete data already download and start over
[05:40] <bob2> as above
[05:41] <bob2> AuroraBorealis, not if it is a large branch
[05:41] <AuroraBorealis> bzr's dev branch takes less then 5 minutes =
[05:41] <AuroraBorealis> you might have to delete the .bzr directory
[05:42] <infinet> the calibre appears quite large, I end up over 100M of unfinished data when last interrupted
[05:42] <infinet> what a waste
[05:42] <bob2> pretty sure as above
[05:42] <AuroraBorealis> try
[05:42] <AuroraBorealis> bzr branch --use-existing-dir
[05:43] <infinet>  --use-existing-dir make no difference, it is what bzr explorer did by the way
[05:44] <AuroraBorealis> i would just try again, then.
[05:45] <infinet> thanks
[05:45] <AuroraBorealis> i think operations that change stuff (like history) are safe, but i guess branch isn't since you don't really lose any data if it gets interrupted.
[05:46] <infinet> true, it is the first time to fetch the branch, so nothing lost
[05:47] <bob2> still immensely tedious though
[05:47] <AuroraBorealis> i agree. i dont know why it wouldn't resume if its just downloading revisions
[05:48] <infinet> more carbon emission, perhaps
[05:48] <AuroraBorealis> perhaps its just on the ever growing todo list.
[07:19] <poolie> hi vila?
[07:36] <vila> hi all !
[07:36] <vila> hey poolie
[07:36] <poolie> hi there
[07:48] <poolie> vila, tangentially, what did we end up with as preferred config option naming
[07:49] <poolie> jelmer is adding 'bzr.transform.orphan_policy' but i thought we were going to drop the 'bzr.'
[07:49] <vila> he didn't add it, just migrated it
[07:49] <vila> yes, we settled on dropping the leading 'bzr.' but this option predates that decision
[07:49] <poolie> k
[07:50] <poolie> true
[09:02] <mgz> morning all!
[09:05] <poolie> hi mgz, and good night
[09:08] <mgz> night poolie :)
[10:08] <apw> anyone else seeing a large delay (leading to compiz greying out) in bzr vis after the progress bars are done filling and before showing the first commit
[10:17] <mgz> try profiling it and seeing what the call that blocks is.
[10:18] <apw> mgz, any hints as to how to profile it, is there something pythony in my toolbox
[10:23] <mgz> you can run it via a bzr command line thing right?
[10:24] <mgz> so `bzr --lsprof-file bzr_viz_prof.txt viz ...`
[10:24] <mgz> and close the window as soon as it's done loading.
[10:24] <mgz> I've used that for bzr explorer/qbzr issues
[11:29] <AfC> apw: yeah, I've seen that delay lately. It's pretty awful.
[11:30] <jelmer> I think it was introduced with our migration to gtk3, haven't had time to investigate either though :-/
[11:33] <mgz> it's worth a bug at any rate.
[11:33] <mgz> jelmer: how was the weekend's snow?
[11:35] <jelmer> mgz: terrible :)
[11:35] <mgz> did the trains go in the end?
[11:35] <jelmer> had long delays on Friday and Sunday, but got back home safely
[12:20] <LarstiQ_> can I turn 'pypy' into an official tag?
[12:23] <mgz> LarstiQ: if you can, do so.
[12:24] <LarstiQ> mgz: done
[12:27] <mgz> LarstiQ: for bug 926869 it's as poolie says, I'd have added features.RefCountingGC or something to the tests were there an obvious way of detecting that
[12:28] <mgz> there's no sensible way of implementing detection of test cases living too long without depending on gc implementation details
[12:29] <mgz> and though some of the pypy gc options will benefit from testcases that die promptly, there's no way short of running a collection after each case to actually do that, and that will have other downsides
[12:30] <mgz> it should perhaps have been more clearly documented as such, but I wasn't particularly thinking that any other python implementations were close to working
[12:31]  * LarstiQ nods
[12:31] <LarstiQ> mgz: now that an entire testsuite run completes, I'm not too worried about the memory consumption
[12:31] <LarstiQ> so for my part skipping would be fine
[12:31] <mgz> for bug 927581 win32 has a similar but worse problem, pypy only uses the bytestring version
[12:32] <mgz> so really I think they need to make listdir less broken with non-ascii data, but the way we use it doesn't help.
[12:32]  * LarstiQ nods
[12:32] <mgz> I couldn't find an upstream pypy bug, it may be worth filing one and linking it.
[12:33] <LarstiQ> mgz: I can do that
[12:33] <LarstiQ> mgz: do you have a link for the win32 version?
[12:33] <mgz> I thought I'd posted a bug, but now can't find it, so maybe I just noticed the issue but didn't file

[12:35] <wgz> note we create a file that we then can't remove with a standard library function in cleanup
[12:39] <tsdgeos> hi guys
[12:39] <tsdgeos> i obviously messed up something in a merge
[12:40] <tsdgeos> and ended up with https://code.launchpad.net/~aacid/unity-2d/unity-2d-shell_rtl/+merge/90455
[12:40] <tsdgeos> where i have "added file 'tests/launcher/autohide_show_tests_common.rb'" and "removed file 'tests/launcher/autohide_show_tests_common.rb'"
[12:40] <tsdgeos> instead of just the differences in that file
[12:40] <tsdgeos> is there a way i can fix that?
[12:42] <LarstiQ> tsdgeos: try `bzr status --show-ids` on that change
[12:42] <LarstiQ> tsdgeos: it sounds like two files with different file-ids
[12:42] <tsdgeos> i mean probably
[12:42] <tsdgeos> the file was already there
[12:42] <tsdgeos> and then the merge brought a file named the same
[12:43] <tsdgeos> so that's basically where i messed up i guess
[12:43] <tsdgeos> just wondering if it can be repaired
[12:43] <LarstiQ> tsdgeos: well, you could backtrack to where the extra copy got introduced
[12:44] <tsdgeos> LarstiQ: otoh it's weird, because if you go to http://bazaar.launchpad.net/~aacid/unity-2d/unity-2d-shell_rtl/revision/969 that is the merge commit
[12:44] <LarstiQ> tsdgeos: but if that has already been merged into the project history, might not be worth it to disrupt that
[12:44] <tsdgeos> it looks acceptable
[12:44] <tsdgeos> when you unfold "tests/launcher/autohide_show_tests_common.rb "
[12:45] <tsdgeos> it looks like only the changes there, not a whole replace/rewrite of the file
[12:45] <LarstiQ> tsdgeos: right, so that's the wrong place
[12:46] <tsdgeos> well, that's the place i merged the two branches that had the same file, before that all was fine
[12:48] <tsdgeos> anyway, not important
[12:48] <tsdgeos> thanks!
[12:48] <LarstiQ> tsdgeos: you're merging into lp:~unity-2d-team/unity-2d/unity-2d-shell
[12:48] <LarstiQ> tsdgeos: so could be that there the change happened
[12:48] <LarstiQ> tsdgeos: (or maybe there is a bug in the merge proposal preview)
[12:48] <tsdgeos> maybe
[12:48]  * LarstiQ branches and checks
[12:49] <tsdgeos> this is my first merge with files coming from everywhere
[12:49] <tsdgeos> so probably did something wrong somewhere
[12:55] <LarstiQ> tsdgeos: so ` bzr log -p tests/launcher/autohide_show_tests_common.rb` in your branch shows it getting added in r957
[12:57] <LarstiQ> tsdgeos: and ` bzr st --show-ids -r ancestor:../unity-2d-shell` tells you the fileid of the removed versions
[13:00] <LarstiQ> tsdgeos: hmm, I don't quite get it
[13:01] <LarstiQ> tsdgeos: `bzr missing --line ../unity-2d-shell` and then `bzr log -v -r 935..-1` show you didn't remove or rename them
[13:02] <mgz> I think both sides of the merge added the file, so there was a path conflict rather than a content conflict, and he took his copy?
[13:03] <LarstiQ> mgz: that sounds plausible
[13:03] <mgz> so then, merging that into trunk replaces the existing file
[13:03]  * LarstiQ nods
[13:03] <mgz> the right thing to do is redo that merge, keep trunk's file, add in any changes needed, which should then merge back to trunk cleanly
[13:05] <LarstiQ> tsdgeos: what mgz said.  Trunk added autohide_show_tests_-20120131103636-9609yigoypwit8fi-1 in r953, you added autohide_show_tests_-20120130172001-gjk3mfvvx7hksg75-1
[13:41] <pippijn> hi all
[13:41] <pippijn> I'm having some issues committing
[13:41] <pippijn> http://xinutec.org/~pippijn/files/txt/ca85c58612e67f7eb1b5581a6478aa2c.txt
[13:48] <jelmer> hi pippijn
[13:48]  * mgz wants to make a joke about this being the wrong place for relationship advice
[13:48] <jelmer> vila: ^
[13:50] <mgz> pippijn: did that not also print out the version and plugin version info?
[13:50] <pippijn> hmm
[13:50] <pippijn> I did bzr merge, got an error, did bzr commit again, got a different error
[13:50] <pippijn> one that does not read Traceback
[13:51] <pippijn> there we go, it's suddenly fixed
[13:51] <jelmer> pippijn: this seems odd, the error suggests you have files from different versions of bzr installed
[13:51] <tsdgeos> LarstiQ: mgz: how would i do that? bzr uncommit + push again? will that overwrite the old history?
[13:51] <pippijn> it's working now
[13:51] <pippijn> magically
[13:54] <jelmer> pippijn: do you have a dist-upgrade / yum upgrade job going on in the background, or something like that?
[13:54] <pippijn> jelmer: no
[13:54] <mgz> tsdgeos: either uncommit, or to be safer branch the rev just before to a new directory and try again
[13:55] <jelmer> pippijn: it sounds like there's something really funky going on with the files in /usr/lib/python2.7/dist-packages/bzrlib
[13:55] <mgz> tsdgeos: then, after doing the merge, committing, and maybe testing against a local copy of trunk to see the merge back works as expected, you can push --overwrite to fix your branch and mp
[14:04] <tsdgeos> mgz: nice that worked :-)
[14:04] <tsdgeos> tx
[14:05] <mgz> cool.
[15:09] <vila> jelmer: what ? mgz's joke ?
[15:10] <jelmer> vila: sorry, unping
[15:10] <jelmer> vila: it was about the config hooks issue pippijn was running into
[15:12] <vila> jelmer: oh, ok, just seen the traceback, quite weird indeed, I don't remember changing hook signatures there... I agree with your feeling about some weird update
[15:13] <mgz> eheh, the ping was amusingly timed.
[20:35] <cabbey> anyone familar with oddball errors out of bzr rebase around?
[20:35] <cabbey> trying to rebase my branch and it's given me a "conflict" on a directory and file that are new in my branch
[20:36] <cabbey> can't seem to convince bzr resolve to clear the bogus conflict messages
[20:41] <jelmer> hi cabbey
[20:41] <cabbey> howdy jelmer
[20:41] <jelmer> cabbey: you should be able to run 'bzr resolved' and then 'bzr rebase-continue'
[20:42] <cabbey> heh, if anyone is familiar with this code, I suspect you would be. :)
[20:42] <cabbey> so right after I posted that, a co-worker suggested explictly resolve'ing by name... that worked when bzr resolved wouldn't
[20:43] <jelmer> cabbey: bzr resolved can only automatically resolve text conflicts, not shape conflicts
[20:43] <jelmer> there is also 'bzr resolved --all' which makes it consider all conflicts as resolved
[20:43] <cabbey> mmm... --all woulda saved me some copy/paste
[21:09] <cabbey> hey jelmer, I'm starting to think what I'm doing is not a good use of rebase. Got a moment to confirm/reject that?
[21:10] <cabbey> we've got 3 branches: trunk -> feature A -> feature B
[21:10] <cabbey> feature A landed to trunk last week, now I'm trying to rebase my branch for B to trunk, since A is deadended
[21:12] <cabbey> rebase is dragging me through lots of nasty manual conflict merges that make no sense to go through again... I had already dealt with all of them as I pulled A into B
[21:13] <cabbey> (A and B were in parrallel development since last september... I've probably done 1000 hand merges during that time)
[21:19] <cabbey> oh god. I just looked at some of the supposed merge results it handled without flagging as conflicts. :(
[21:23] <jelmer> RE
[21:24] <jelmer> cabbey: I would do a reverse merge of the changes from A in B
[21:24] <jelmer> cabbey: rebase will try to create all commits again on top of trunk, one by one - so it's probably not what you want, indeed
[21:25] <cabbey> sadly it seems to be doing a very bad job of re-creating them :(
[21:27] <jelmer> cabbey: it's just applying the changes again
[21:27] <jelmer> cabbey: you might have more luck trying to rebase on the revision from trunk before feature A was started
[21:28] <cabbey> that's not what I'm seeing in these .BASE, .THIS and .OTHER files
[21:28] <jelmer> cabbey: it's basically just doing "bzr diff -c" for each revision and then calling "patch -p0" for that revision on top of trunk
[21:29] <poolie> hi jelmer, wgz
[21:29] <jelmer> hi poolie
[21:30] <jelmer> are you feeling better?
[21:32] <poolie> yes thanks
[21:32] <poolie> how are things with you?
[21:32] <cabbey> jelmer: it should be replaying the commits from my branch, right?
[21:32] <poolie> i'm going to try to get through the queue today
[21:33] <poolie> and maybe then look in to debugging some precise bugs
[21:33] <jelmer> poolie: I had fun at FOSDEM :)
[21:34] <Riddell> jelmer: you never came by my stall!
[21:34] <poolie> hi riddell, how are you?
[21:34] <Riddell> poolie: recovering
[21:35] <Riddell> enjoyed fosdem, had to limit my intake of belgian beer of course
[21:35] <jelmer> Riddell: well, you missed the Ubuntu dinner >-)
[21:36] <jelmer> Riddell: I did spot you at some point during the weekend, but you were in conversation with somebody
[21:36] <Riddell> that's because I had about 25 KDE cats to herd to the dinner I organised
[21:36] <jelmer> ah, heh :)
[21:36] <Riddell> I might be concussed but I still can organise better than most free software types
[21:38] <jelmer> cabbey: did you merge trunk during the feature development at all?
[21:38] <jelmer> Riddell: :)
[21:38] <cabbey> yes. via A
[21:38] <cabbey> A pulled trunk in, B pulled A in
[21:39] <jelmer> cabbey: replaying the changes from B on top of trunk means that older B revisions won't have all the changes from trunk merged in yet
[21:39] <cabbey> well, pulled or merged... mostly merged there in the latter days as things diverged :)
[21:40] <jelmer> basically, rebasing anything that has merges of the branch onto which you're rebasing in it somewhere is going to cause massive conflicts
[21:41] <cabbey> right, so rebase-abort here I come. :(
[21:47] <lifeless> poolie: hiya
[21:48] <lifeless> poolie: LP would like to be able to import bzr plugins from eggs (in our buildout environment) - are you aware of an existing bug for having bzr find plugins via setuptools voodoo ? I don't want to file a dupe, I vaguely recall such a bug, but flacoste couldn't find it when he looked
[21:49] <poolie> hm
[21:49] <poolie> as in, it doesn't automatically find them?
[21:49] <poolie> or, you can't even load them by hand?
[21:50] <poolie> this seems to get into namespace package ickiness
[21:50] <poolie> but
[21:50] <poolie> i don't recall a bug for it and i don't object
[21:50] <poolie> the only bzr tasks i have been objecting to are the ones where the bug is not yet actionable in bzr
[21:51] <lifeless> sure; I wasn't referencing or impeded by that :)
[21:53] <lifeless> poolie: as in the load_plugins call needs to call some setuptools api to ask it to iterate the available bzrlib.plugins.* eggs; that would get the package path setup fo r'import bzrlib.plugins.foo' at the same time; I think its fairly shallow (but possible expensive to call so may need an option to turn it on)
[21:53] <jelmer> cabbey: I would recommend doing a reverse merge of the changes between A and trunk
[21:54] <poolie> +1
[21:54] <jelmer> cabbey: rebase is just conceptually problematic in this regard
[21:54] <lifeless> bug 78520 is tangentially related (in that you can't install plugins into an egg distribution, so if plugins are desired, this is a pre-cursor to fixing that existing bug report)
[21:54] <cabbey> jelmer: yeah, I'm starting down that route in copy of my branch right now
[21:59] <lifeless> poolie: I've filed https://bugs.launchpad.net/bzr/+bug/927920 about this
[22:23] <poolie> thanks lifeless
[22:36] <lifeless> poolie: de nada :)
[22:50] <milki> hm
[22:50] <milki> bug 0
[22:50] <milki> :o
[22:50] <milki> bug 1
[22:50] <milki> lol
[23:35] <wgz> a little bazaar before bed


[07:35] <tuxmaniac> hey guys! If I download the latest <IP_ADDRESS> from kernel.org and compile and install it on Ubuntu Dapper I know it will work
[07:35] <tuxmaniac> but we will miss out on the Ubuntu patches right?
[07:35] <tuxmaniac> So what will be the end effect if one installs a latest vanilla kernel on Dapper?
[07:39] <crimsun> tuxmaniac: "know it will work"?
[07:39] <crimsun> tuxmaniac: as in you've tested it, and the udev<->kernel interaction works identically?
[07:40] <tuxmaniac> no
[07:40] <tuxmaniac> crimsun: There are some problems?
[07:40] <tuxmaniac> there are some problems!
[07:41] <tuxmaniac> But is there no way to install the latest kernel from kernel.org
[07:41] <tuxmaniac> I did install 2.6.16 on Brezy and it pretty much worked fine except for my synaptic touchpad scroll feature
[07:41] <crimsun> you can, but there's no guarantee everything will work. The udev<->kernel interaction I mentioned is just one issue.
[07:42] <tuxmaniac> hmmm.. so the latest on Ubuntu Dapper is 2.6.15-23 but the topic says -22 !?
[07:45] <tuxmaniac> crimsun: I want to ask one more standard question. am very much interested in working with the kernel team. How do I start? Submit patches to bugs or how?
[07:50] <crimsun> that's an excellent way.
[07:56] <crimsun> well yes, there are rather gigantic differences
[05:19] <fabbione> BenC: ping?
[05:19] <BenC> fabbione: pong
[05:19] <fabbione> hey BenC
[05:19] <fabbione> BenC: -23- is no go on my PB
[05:19] <fabbione> as soon as X starts the machine is totally frozen
[05:19] <fabbione> hard
[05:20] <BenC> running it on mine
[05:20] <fabbione> -22- works fine
[05:20] <fabbione> i just dist-upgraded 10 minutes ago or so
[05:20] <BenC> Linux grayson 2.6.15-23-powerpc #1 Thu May 18 09:56:00 EDT 2006 ppc GNU/Linux
[05:20] <fabbione> yeah
[05:20] <fabbione> i do believe you :)
[05:20] <BenC> I'm running the one I built before upload
[05:20] <BenC> I'll reboot to the archive one in a second
[05:20] <fabbione> can you try the one that has been built in the archive?
[05:20] <fabbione> thanks
[05:22] <BenC> btw, 2.6.17-1 is building on everything except hppa and ia64 now
[05:24] <fabbione> cool
[05:24] <BenC> it boots on my G4, but on my ultra3k it is causing a openboot panic
[05:24] <BenC> sends it into a POST loop
[05:25] <fabbione> interesting
[05:25] <tuxmaniac> fabbione: -23 runs fine on mine too.. Just installed today! :)
[05:26] <fabbione> tuxmaniac: what model is your?
[05:26] <tuxmaniac> sorry fabbione Dint see.. ou guys are talking abt ppc.. Mine is x86 :D
[05:29] <fabbione> BenC: i am going to calibrate the THX on the mythtv box
[05:29] <fabbione> i will pass by later to check on -23-
[06:18] <jbailey> BenC: Which gcc are you using for the edgy kernels?
[06:18] <BenC> whatever /usr/bin/gcc is
[06:29] <tuxmaniac> BenC: I did a custom install of 2.6.16-ck11
[06:30] <tuxmaniac> BenC: While booting the EVMS is generaing a device maper error! What could it be.. Should I disable EVMS or something?
[06:30] <BenC> not sure
[06:32] <fabbione> re
[06:32] <fabbione> BenC: does it boot for you?
[06:38] <bluefoxicy> gah
[06:46] <bluefoxicy> there, booting with stack_random_bits=99 mmap_random_bits=99 on v3 (rebuilding with v4 after this to test that..)
[06:46] <bluefoxicy> Stack randomisation test (SEGMEXEC)      : No randomisation
[06:46] <bluefoxicy> yay i broked it :)
[06:50] <bluefoxicy> wow
[06:50] <bluefoxicy> that's really freaky.
[06:50] <bluefoxicy> 2 files not to patch because they're simply not there, and the code is new.


[13:29] <elena09> hi
[14:05] <eraldo> Greetings!
[14:05] <eraldo> I want to buy a laptop for working outside (garden, etc)
[14:06] <eraldo> any (personal) hints / recommendations?
[22:33] <elena09> hi
[22:33] <elena09> hello?


[10:09] <imran_khakoo> I'm seeing "E: Unable to locate package juju-mongodb3.2" when I bootstrap a new 18.04 controller. Any news on when this package will be available?
[11:02] <parlos> Good Morning!
[15:11] <magicaltrout2> hello folks
[15:11] <magicaltrout2> amulet
[15:11] <magicaltrout2> its asking me for juju-deployer
[15:11] <magicaltrout2> what faux pas am I making?
[15:18] <magicaltrout2> rick_h_: any clue?
[15:18] <magicaltrout2> are you supposed to use juju-deployer with juju 2.x & amulet?
[15:19] <rick_h_> magicaltrout2: otp, but I think that amulet never lost the deployer dep so it's working as expected?
[15:20] <magicaltrout2> well deployer wants paths that don't exist in juju 2.0 like .juju/environments.yaml etc
[15:38] <cmars> hi, does CDK & ceph work with azure storage? i'm trying to deploy ceph and attach storage, but it never seems to detect the block devices
[15:42] <kwmonroe> magicaltrout: yeah, amulet will use juju-deployer.  get it with pip3 install juju-deployer.
[15:42] <kwmonroe> magicaltrout: when you want to run it with juju 2.x, make sure you pass the -e <controller>:<model
[15:43] <rmcd> list
[15:45] <kwmonroe> magicaltrout: if you're just running amulet tests directly, it should be smart enough to use the current model.  but if you're calling juju-deployer in your own script, make sure you stick in the -e.
[15:51] <magicaltrout> hmm thanks kwmonroe i'll give it another prod later
[17:18] <hml> zeestrat: ping
[18:07] <zeestrat> hml: pong
[18:08] <hml> zeestrat: hi - question on your email , what cloud are you bootstrapping?
[18:11] <zeestrat> hml: Localhost/lxd. Can't remember if I checked MAAS.
[18:13] <hml> zeestrat: 2.4-beta1 is almost out the door, so i’m not sure anything can be added.  i’d recommend emailing the juju mail list for discussion and geting more spotlight on it.
[18:14] <zeestrat> hml: Sounds good. Thanks for taking a look :)
[18:14] <hml> zeestrat: i’ve also been playing the lxc profiles
[18:14] <hml> see if i can get constraints working for you that way
[18:15] <hml> but that limits individual memory constraints to a single model
[18:15] <hml> not optimal
[18:15] <zeestrat> hml: Yeah, the problem is multiple different mem constraints in the same model. The workaround we have works so don't stress.
[18:16] <hml> :-)
[18:17] <zeestrat> hml: Thanks again. Have a nice weekend!
[18:17] <hml> zeestrat: you too!
[18:27] <ananke> was wondering if somebody could help me out figuring out general architecture question regarding juju and maas (very green on those subjects). say I have a dozen servers under maas management, and I want to use juju for various app deployments. I've bootstrapped juju onto maas, and it took on an entire physical node
[18:31] <ananke> now if I deploy any application stack with juju, each 'application' uses an entire physical node, which is a bit of an overkill of course. So my question is, what are some typical ways of combining maas+juju with virtualization, and would I be using juju to deploy them, or maas?
[18:32] <ananke> maas seems to have an option to manage kvm virtualization, but juju store doesn't have anything for that. there are container solutions, but maybe I'm overlooking something obvious
[18:35] <zeestrat> ananke: No, it's a bit of pain atm. Regarding the bootstrapped juju controller, folks usually create some kvm vm's on a dedicated machine or even on the MAAS controllers themselves and add them to MAAS so you have more machines to pick from. Then when you bootstrap juju, you can select those kvm vm's with a constraint or MAAS tag. Check out https://docs.maas.io/2.3/en/nodes-add#kvm-guest-nodes
[18:36] <zeestrat> ananke: I believe using kvm vm's got even easier with MAAS if you use their pod/composable hw setup: https://docs.maas.io/2.3/en/nodes-comp-hw
[18:37] <ananke> zeestrat: thank you. I may have to revisit the white board and figure out if maas+juju are still worth exploring. I was hoping maas+juju would help manage that middle layer
[18:38] <zeestrat> ananke: Regarding deploying applications with juju, you can use the same kvm trick as with the bootstrapped juju controller but what most folk use and would be most appropriate is LXD containers. They are well supported and make it easy to deploy multiple applications on the same host.
[18:41] <ananke> zeestrat: thanks, that makes sense. I haven't spent much time with lxd, but it's certainly something we'd be willing to learn
[18:41] <zeestrat> No worries. At work, we dedicate 2 boxes for a bit of redundancy (can do on 1) for MAAS controllers and juju controllers with kvm. For the rest we use LXD.
[18:42] <ananke> wonder if maas+openstack+juju combinations are common. seems there are guides on how to deploy openstack on maas, but not sure if those three can be glued together
[18:43] <ananke> zeestrat: that's what I was planning on doing too, have a couple controllers per rack. I have two racks of equipment in two discrete facilities, dedicated mostly for testing various things. maas & juju seemed like a good fit, and they appear to be well polished
[18:43] <zeestrat> ananke: That's exactly what we do. MAAS manages the hardware and juju deploys openstack on the hardware from MAAS.
[18:45] <ananke> zeestrat: and then does juju communicate with openstack for deploying apps, or how is that done? I wonder if there are any blueprints for that setup
[18:46] <zeestrat> ananke: Are you thinking of deploying openstack or deploying apps on top of openstack? Juju will do both, just good to know what you're looking for :)
[18:47] <ananke> zeestrat: frankly, either or, whatever makes more sense. being able to deploy apps on top of openstack would be ideal
[18:48] <hml> ananke: you can use juju to deploy openstack on your maas hardware, then turn around and have juju use the openstack to deploy applications.
[18:49] <ananke> I'm coming from the traditional HPC clustering world, which has a very different approach to many things. we would like to create an on-prem cloud solution, first to serve our IT needs, second to potentially have a self-service cloud for our researchers
[18:49] <zeestrat> ananke: I'd check out the openstack deployment guide if you're looking to deploy: https://docs.openstack.org/charm-deployment-guide/latest/. For more general info about the openstack juju charms (the recipes/playbooks used by juju) see: https://docs.openstack.org/charm-guide/latest/. For deploying apps on top of openstack see: https://jujucharms.com/docs/stable/help-openstack
[18:49] <ananke> zeestrat: thanks, I was looking at the first document already earlier today, I'll check out the other one too. just trying to get my head wrapped around how all of this could function
[18:49] <ananke> hml: ahh, that makes sense
[18:50] <hml> for juju maas, openstack, lxd, aws, gce, azure are all clouds… you can bootstrap with them then deploy
[18:52] <ananke> I should redo the juju setup then, and have it use lxd on the maas controller, instead of an entire physical node
[18:52] <hml> you can deploy units to lxd containers on machines already deployed
[18:52] <hml> instead of new machines for each unit
[18:53] <hml> check out the —to directive
[18:53] <ananke> hml: right, that makes sense. however, I'm not familiar with lxd at all, and was hoping there was an existing solution with either maas or juju to manage lxd on those machines
[18:54] <hml> ananke: you can try ‘juju add-unit <application> —to lxd:0’
[18:54] <hml> that would add a unit of something to a new lxd container on machine 0
[18:56] <hml> there are many permutations of specifying where a new unit will go… check out juju help add-unit
[18:56] <ananke> while I fumble through documentation, what's the relation of '0' in juju to maas? I imagine I would be able to query available systems from juju
[18:57] <ananke> forgive the naive questions, I just started with juju this morning
[18:57] <hml> not a problem  :-)
[18:57] <hml> 0 is what juju defines as machine 0
[18:57] <hml> if you run juju status 0
[18:57] <hml> you can find which machine/isntance in your maas config is being used
[18:58] <zeestrat> ananke: Just note that if you want to bootstrap juju on a MAAS controller, then your best bet is kvm as MAAS doesn't support lxd containers.
[18:58] <ananke> zeestrat: thanks
[18:59] <hml> zeestrat: you can still use lxd on a machine already deployed though yes?  just not use lxd as a maas machine?
[18:59] <zeestrat> hml: Yes, just not as a MAAS machine which you need for bootstrapping juju.
[19:00] <hml> lxd can be confusing, since we can use as a cloud, or to add containers to juju machines
[19:00] <hml> used in multiple ways
[19:00] <ananke> hmm, juju status 0 reveals nothing different than juju status <any number here>. https://paste.ofcode.org/yPdkLET3NNfTKjJwaHvRPq
[19:00] <hml> :-)
[19:00] <zeestrat> It's a bit confusing (it sure confused me in the start).
[19:00] <hml> ananke: oops.. sorry  - you have to deploy a charm first… :-)
[19:01] <hml> juju deploy ubuntu —to lxd
[19:01] <hml> will deploy a maas machine - then install ubuntu  charm on an lxd container on top of the machine
[19:01] <ananke> ERROR unrecognized args: ["lxd"]
[19:02] <hml> weird… dash dash to?
[19:02] <ananke> hmm. this is maas 2.3.0 with whatever latest stable juju was
[19:02] <hml> my irc client is autocorrecting on me
[19:02] <ananke> hml: ahh, some weird encoding took place. I retyped that, seems to be running now
[19:03] <bdx> kwmonroe: happy friday
[19:03] <ananke> looks like maas booted a system, and is installing ubuntu. yay
[19:03] <kwmonroe> bdx: o/
[19:04] <bdx> experiencing some issues with hadoop on openstack
[19:04] <bdx> juju status | http://paste.ubuntu.com/p/DNdJprKXHH/
[19:04] <bdx> kwmonroe: got a bug coming your way
[19:05] <bdx> have you seen this before https://paste.ubuntu.com/p/TMCVJJb4jv/
[19:05] <bdx> ?
[19:05] <ananke> hml: thank you so much, this is helping me figure out how I can approach this stack
[19:05] <bdx> when I look in /var/log/hadoop-hdfs/hadoop-hdfs-namenode-juju-6e95f5-hadoop-test-5.out
[19:05] <hml> :-)
[19:06] <bdx> https://paste.ubuntu.com/p/JvbskWgKSd/
[19:06] <bdx> cat /var/log/hadoop-hdfs/hadoop-hdfs-namenode-juju-6e95f5-hadoop-test-5.out ^
[19:07] <bdx> kwmonroe: is this telling me that xenial-cloud-img has different/more restrictive ulimit defaults that stop hdfs from starting?
[19:09] <kwmonroe> bdx: i don't think so.. the .out is terrible.  see if there's more info in the .log (should be in the same dir)
[19:09] <kwmonroe> bdx: if i had to guess, your NN can't resolve it's own address.  i know that is particularly painful in openstack envs
[19:10] <kwmonroe> i mean, trying to deploy hadoop in openstack envs..
[19:10] <bdx> Oh I bet
[19:10] <kwmonroe> which is https://github.com/juju-solutions/jujubigdata/issues/62
[19:10] <kwmonroe> which is ... still not fixed :/
[19:10] <bdx> cat /var/log/hadoop-hdfs/hadoop-hdfs-namenode-juju-6e95f5-hadoop-test-5.log | http://paste.ubuntu.com/p/FWgwPc2Yxr/
[19:10] <bdx> totally
[19:10] <bdx> I wonder if I can hook up the designate bits and make my way
[19:11] <bdx> ill be looking into this
[19:11] <bdx> guess I wont be filing any bugs for you:)
[19:11] <kwmonroe> oh there's plenty filed already.  dont you fret.
[19:11] <bdx> Caused by: java.net.UnknownHostException: juju-6e95f5-hadoop-test-5: Name or service not known
[19:11] <bdx> boom
[19:12] <bdx> ok
[20:28] <bdx> kwmonroe: its all about https://jujucharms.com/neutron-api/#charm-config-enable-ml2-dns
[20:28] <bdx> they made it simpel for the internal resolution
[20:28] <bdx> real nice
[20:28] <bdx> designate looks like it s for external dns
[20:29] <bdx> kwmonroe: I was able to get around it with that config
[20:37] <kwmonroe> whoa - super cool bdx!  i kept hoping it would fix itself (or at least get easier).  turns out waiting pays off!
[20:58] <bdx> +!
[20:58] <bdx> +1 same


[05:14] <infinity> mjg59: Hrm.  on-demand requency scaling seems to have broken in the latest kernel for my Pentium-M... In the middle of a nasty compile, sysfs still claims my current frequence is 800MHz (instead of 2GHz), and the compile does seem slow, so I don't think it's being misreported.
[05:15] <mjg59> infinity: Can you force it higher manually?
[05:15] <infinity> How?
[05:15] <mjg59> Echo stuff into sysfs
[05:16] <mjg59> I can't remember which file off-hand, I'm afraid
[05:16] <infinity> (base)root@cthulhu:/sys/devices/system/cpu/cpu0/cpufreq # echo 2000000 > scaling_setspeed
[05:16] <infinity> (base)root@cthulhu:/sys/devices/system/cpu/cpu0/cpufreq # cat scaling_cur_freq
[05:16] <infinity> 800000
[05:16] <mjg59> Interesting
[05:16] <mjg59> What does /proc/cpuinfo say?
[05:17] <infinity> 1995.800 MHz, 3994.36 bogomips.
[05:17] <infinity> But it was lying in the last kernel revision too.
[05:17] <mjg59> Which seems to suggest it's working
[05:17] <mjg59> Oh
[05:17] <mjg59> Hm
[05:17] <mjg59> I've no idea which one to trust here
[05:17] <infinity> (ie: cpuinfo always said I was at full speed, despite the speed going up and down, according to sysfs)
[05:17] <mjg59> But something's plainly broken
[05:19] <infinity> Oh well.  I'll have to bug you about it later.  Bedtime now.
[05:19] <mjg59> Night
[05:44] <zul> heylo
[08:13] <zul> BenC: more crack for you..
[11:22] <ds> BenC: you around?
[11:24] <ds> BenC: I'm willing to do some hacking/testing for #20622 if you have suggestions


[06:03] <Avis_bot> ASHER\Work: Welcome to #ubuntu-il! Feel free to ask questions. Note that it may take at least around half an hour until you get a response. Enjoy!
[06:03] <Avis_bot> ASHER\Work: ברוכים הבאים ל #ubuntu-il! הרגישו חופשי לשאול שאלות. שימו לב שעלולה לקחת לפחות כחצי שעה לקבלת מענה. תהנו!
[08:37] <Avis_bot> matanya: Welcome to #ubuntu-il! Feel free to ask questions. Note that it may take at least around half an hour until you get a response. Enjoy!
[08:37] <Avis_bot> matanya: ברוכים הבאים ל #ubuntu-il! הרגישו חופשי לשאול שאלות. שימו לב שעלולה לקחת לפחות כחצי שעה לקבלת מענה. תהנו!
[20:06] <Avis_bot> philipballew: Welcome to #ubuntu-il! Feel free to ask questions. Note that it may take at least around half an hour until you get a response. Enjoy!
[20:06] <Avis_bot> philipballew: ברוכים הבאים ל #ubuntu-il! הרגישו חופשי לשאול שאלות. שימו לב שעלולה לקחת לפחות כחצי שעה לקבלת מענה. תהנו!
[20:06] <philipballew> Hello Ubuntu people!
[20:07] <philipballew> Wanted to drop a Ubuntu project here I think you might all might be able to help with: http://philipballew.wordpress.com/2013/04/03/showcase-the-diversity-of-the-ubuntu-community/
[20:21] <lousygarua> philipballew, what is is about?
[20:23] <philipballew> lousygarua, I am asking for other Ubuntu users and comunity members to send me post cards showing where they are to highlight the many ubuntu users we have in all parts of the world.Then write something about Ubuntu on it.  Bonus points if the post card  or what is written on it is not in English
[20:25] <lousygarua> philipballew, sounds cool :) I'll post your request in our forums and mailing list.
[20:26] <philipballew> lousygarua, I'll then take all the post cards, and wither make a giant poster with them, or take them with me to all Ubuntu events I go to to showcase the great Ubuntu community we have.
[20:26] <philipballew> lousygarua, thank you also. If you would like to send one as well, I will not stop you.
[20:26] <philipballew> lousygarua, so do you run the loco here or something?
[20:29] <lousygarua> philipballew, I will do my best to send a postcard.
[20:29] <lousygarua> philipballew, yes, I'm the current point-of-contact for the Israeli Team
[20:30] <philipballew> lousygarua, good. Nice to meet you, and thank you for helping out Ubuntu. Hope we can get to know each other further as well.
[20:31] <lousygarua> philipballew, sure :) you can always see how to reach me under http://wiki.ubuntu.com/AmirEldor if i'm not on IRC
[20:32] <philipballew> lousygarua, nice! I am at http://wiki.ubuntu.com/philipballew and on twitter at @philipballew.
[20:32] <philipballew> I have never been to your part of the world. It sounds like a great place.
[20:32] <philipballew> :)
[20:33] <lousygarua> philipballew, you are invited to visit. It's not a warzone as shown on the media.
[20:34] <lousygarua> Also, there is a new initiative with someone from our community where he wants to invite guest speakers from the world to Israel to say something about Ubuntu and FOSS.
[20:34] <lousygarua> It also involves a site-seeing tour to all guest speakers
[20:34] <lousygarua> I'll invite you :)
[20:34] <philipballew> lousygarua, I will take you up on that once I find a thousand dollars! I am actually a good speaker. I Have spoken at conferences and everything.
[20:35] <philipballew> A pane ticket to anywhere in the middle east is gonna run about 1000
[20:35] <lousygarua> philipballew, I think it costs even more than that, but maybe we'll find a big sponsor to fund these stuff.
[20:35] <lousygarua> But I'm too optimistic :)
[20:36] <philipballew> lousygarua, Yes, if you can sponsor me to come out, let me know. I am going to be free all Summer and can always take a week off school to come out.
[20:36] <philipballew> If sponsored I can usually leave within a days notice.
[20:37] <lousygarua> philipballew, I will let you know.
[20:37] <lousygarua> What are you studying? I study sound production/enginerring, still unsure how to call it
[20:37] <lousygarua> engineering*
[20:39] <lousygarua> philipballew, whoops, noticed a little type on your launchpad page, "Ubuntu Forms" instead of "Forums". https://launchpad.net/~philipballew
[20:39] <lousygarua> typo*
[20:39] <lousygarua> haha :)
[20:40] <philipballew> lousygarua, Feel free to come to California anytime. I currently study Communications in college. I see that error now. Thanks. I am much better speaking than typing!
[20:40] <philipballew> Is sound stuff fun?
[20:42] <philipballew> to come to Israel is really easy for Americans unlike me going to any other country in that part of the world.
[20:43] <lousygarua> The sound stuff is great :) both from a musician and a sound techncian point of view.
[20:43] <lousygarua> Israel is the "little devil" and America is the "big devil", that's what they say in the muslim world :)
[20:44] <philipballew> That sounds pretty cool. so how old are you?
[20:44] <lousygarua> so the big devil can visit the little one anytime :)
[20:44] <lousygarua> I'm 25
[20:44] <lousygarua> philipballew, how old are you?
[20:44] <philipballew> lousygarua, people there in those countries always seem to be mad. People need to just be happy. I am 21!
[20:45] <philipballew> I have a friend who lives just outside (somewhat not outside) Israel, in Gaza and says that Tel Aviv is a really cool place.
[20:46] <lousygarua> philipballew, I believe Gaza, or Beirut, or any big city around is pretty cool. It's too bad the extremists on both sides control our lives here.
[20:47] <lousygarua> *sigh* politics and religion
[20:47] <lousygarua> Why can't we all Ubuntu ;)
[20:47] <philipballew> lousygarua, I understand. Thats why I think Ubuntu philosophy is even more important than free software. Ubuntu means free in Congo as well.
[20:49] <lousygarua> philipballew, I think the world is heading in an Ubuntu-ish direction, in a philosophical way as you said it.
[20:49] <lousygarua> But again, I'm too optimistic :)
[20:50] <lousygarua> I'm usually more pessimistic than this. Something is weird today.
[20:50] <philipballew> lousygarua, I pray so myself. I am a optimistic person as well. Way to hopeful for the good.
[20:50] <philipballew> lousygarua, maybe its the food or something.
[20:50] <lousygarua> philipballew, too much mars bars
[20:50] <philipballew> lousygarua, I love mars bars!
[20:51] <lousygarua> philipballew, yeah they are great! but i only got the mini-sized ones :q
[20:51] <philipballew> lousygarua, maybe it's time you go to the store!
[20:52] <lousygarua> philipballew, me and my flatmate just did. but sadly I didn't buy real food :(
[20:52] <lousygarua> should go to the marketplace tomorrow
[20:52] <lousygarua> tomorrow's morning
[20:53] <philipballew> I usually go once a week or so myself. So where in Israel do you live?
[20:54] <lousygarua> Currently in Tel Aviv, but I come from a small city near Haifa.
[20:54] <philipballew> I see. I live in a place called San Diego. It is 20 miles north of Mexico, and 100 miles south of LA.
[20:56] <lousygarua> I've never been to Barcelona, I have no idea why I've thought of this.
[20:56] <lousygarua> I know San Diego
[20:56] <lousygarua> Never visited your continent though... would like to do so
[20:57] <lousygarua> and would definitely do so one day
[20:57] <philipballew> lousygarua, the same goes for you there. I would love to make a trip to your part of the world.
[20:58]  * philipballew does own a passport
[20:58]  * lousygarua owns a Dutch passport, and belives Europeans can get into the US easier than Israelis
[20:58] <lousygarua> believes*
[20:59] <philipballew> lousygarua, so you are a dutch citizen?
[21:00] <philipballew> http://wikitravel.org/en/United_States_of_America
[21:05]  * philipballew will be back online in a little while
[21:44] <avihay> lousygarua: I didn't know you ere the official poc
[21:50] <lousygarua> avihay, who did you think it was then? aviv?
[21:50] <avihay> I assumed the whole thing just died out
[21:51] <lousygarua> avihay, it did, but i woke it up
[21:51] <lousygarua> you should sign up to the mailing list
[21:51] <lousygarua> and visit the site
[21:51] <lousygarua> at least once a week
[21:51] <avihay> also, start bugging me about the bot on Saturday
[22:23] <lousygarua> avihay, ok - bot bugging on saturday?


[19:29] <vish> qense: hi.. could you have a look at the branch linked to Bug 498182 , if it is good we could poke tedg bout it
[19:29] <ubot4`> Launchpad bug 498182 in indicator-session (Ubuntu) (and 3 other projects) "Indicator-application does not support vertical panels (affects: 27) (dups: 4) (heat: 180)" [Medium,Triaged] https://launchpad.net/bugs/498182
[19:30] <qense> vish: I'll take a look!
[19:30] <vish> qense: thanks
[19:32] <hyperair> qense: Bug #556112
[19:32] <ubot4`> Launchpad bug 556112 in couchdb-glib "Create DesktopcouchDocumentClass (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/556112
[19:32] <hyperair> er shit
[19:32] <hyperair> wrong bug
[19:32] <hyperair> qense: Bug #566112
[19:32] <ubot4`> Launchpad bug 566112 in banshee-community-extensions (Ubuntu) "Notify-OSD lags with AppIndicator (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/566112
[19:33] <qense> hyperair: thanks, will look at it
[19:33] <hyperair> qense: i remember an ancient similar bug
[19:33] <hyperair> qense: it was fixed a long time ago in the notificationAreaicon
[19:34] <qense> hyperair: ok, if necessary I'll try to find that bug
[19:34] <qense> vish: Have you tested the diff yourself? I quickly looked over it and it looked alright, but I don't know whether it works.
[19:35] <hyperair> qense: no wait, the problem seems to be different, although the symptoms are the same.
[19:35] <vish> qense: i havent checked if it works though
[19:36] <qense> hyperair: Medium or Low, what would you say?
[19:36] <qense> I'd go for Low
[19:36] <hyperair> qense: i'd put medium.
[19:36] <qense> ok
[19:37] <hyperair> qense: reason being i can't press my media keys repeatedly until i can find a song i want to listen to at the moment.
[19:37] <hyperair> qense: it would help to ask for dbus-monitor output, but i can't remember exactly what the syntax was like
[19:37] <hyperair> the watch expression i mean
[19:37] <qense> hyperair: I'll do it myself.
[19:38] <hyperair> qense: oh you can reproduce it?
[19:38] <qense> hyperair: I quickly tested the issue here and: yes
[19:38] <hyperair> qense: cool, that'll speed things up, thanks.
[19:39] <qense> hyperair: wasn't bug #562345 already solved by your first try to fix dependency issues for Banshee.AppIndicator?
[19:40] <ubot4`> Launchpad bug 562345 in banshee-community-extensions (Ubuntu) "banshee-extension-appindicator should not depend on indicator-applet (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/562345
[19:40] <qense> that is bug #560095
[19:40] <ubot4`> Launchpad bug 560095 in indicator-application (Ubuntu) (and 1 other project) "packaging of libappindicator0-cil is in violation of the Debian CLI Policy, making ${cli:Depends} not work (affects: 6) (dups: 1)" [High,Fix released] https://launchpad.net/bugs/560095
[19:40] <qense> nope, it's not
[19:40] <qense> hyperair: will it be solved by one of your next fixes for libappindicator0-cil?
[19:41] <hyperair> qense: it's fixed, just not built yet.
[19:42] <hyperair> qense: it won't be built until someone gets around to uploading indicator-application's fix
[19:42] <qense> a shame
[19:42] <hyperair> qense: yep.
[19:42] <qense> hyperair: Would you be so kind to mark the bug as a duplicate?
[19:42] <qense> I lost track of the different bug reports regarding this issue.
[19:44] <qense> vish: Mind if I take a look at the patch later? I don't have much time now, really. I want to push a working, not-functional basic interface of Mergimus this evening so I can put that aside.
[19:44] <vish> qense: sure ... ;)
[19:45] <vish> qense: err , rather.. np.. ;p
[19:45] <qense> vish: great!


[00:21] <Ampelbein> robert_ancell: hi there! am I right that you are upstream for glchess in gnome-games?
[00:21] <robert_ancell> Ampelbein, I am
[00:23] <robert_ancell> brb
[00:23] <Ampelbein> robert_ancell: cool, i was looking for a fix for bug 389889. I came up with http://paste.ubuntu.com/201152/ but that only works in python2.6, not 2.5.
[00:32] <robert_ancell> Ampelbein, I suggest pushing that fix upstream and marking the Ubuntu bug as triaged - I'm not sure if we're ready to require Python 2.6 yet
[00:33] <Ampelbein> robert_ancell: http://paste.ubuntu.com/201153/ works also with python2.5, but I do have a question: what error do you want to be displayed?
[00:34] <Ampelbein> robert_ancell: http://paste.ubuntu.com/201156/ the first or the more detailed second?
[00:36] <robert_ancell> Ampelbein: I want the text of the message to be displayed, I think in http://paste.ubuntu.com/201153/ it will display something like "IOError('blah')" which is not what I want
[00:38] <Ampelbein> robert_ancell: ok, so you want http://paste.ubuntu.com/201160/ ?
[00:39] <Ampelbein> robert_ancell: or just the "No such file or directory"?
[00:40] <robert_ancell> Ampelbein, testing...
[00:42] <robert_ancell> Ampelbein: yes, I want that.  I didn't realise that .message doesn't return anything anymore!
[00:42] <Ampelbein> robert_ancell: ok, i'm filing a bug and attach the patch
[00:42] <robert_ancell> Ampelbein: thanks
[05:37] <TheMuso> c
[06:25] <pitti> Good morning
[07:02] <robert_ancell> pitti: Do you know .deb Python packaging well? I'm trying to fix gucharmap, it FTBFS as it installs python modules in /usr/lib/python2.6/site-packages not /usr/lib/python2.6/dist-packages.  Is there a debhelper that will "do the right thing" for me?
[07:02] <robert_ancell> bug 390523
[07:03] <pitti> robert_ancell: does it use distutils?
[07:03] <pitti> robert_ancell: then you need to use --install-layout=deb on the "setup.py install" call
[07:04] <robert_ancell> pitti, unfortunately it doesn't use distutils - it's an autoconf job
[07:04] <pitti> robert_ancell: ok, then this needs to be fixed in debian/*.install
[07:05] <robert_ancell> pitti, but then how do you get it to work building both python 2.5 and 2.6?
[07:11] <pitti> robert_ancell: you probably have to split the python module install line in debian/*.install then
[07:41] <didrocks> good morning
[07:42] <pitti> hey didrocks
[08:14] <robert_ancell> pitti: do you know why gnome-system-monitor is failing to build? It doesn't cant install dependencies it seems
[08:14] <robert_ancell> http://launchpadlibrarian.net/28187740/buildlog_ubuntu-karmic-sparc.gnome-system-monitor_2.27.3-0ubuntu1_FAILEDTOBUILD.txt.gz
[08:15] <pitti> robert_ancell: oh, just sparc?
[08:15] <pitti> robert_ancell: I guess gtk wasn't built (at all/correctly) on sparc
[08:15] <robert_ancell> pitti, no it seems to be all the archs
[08:16] <pitti> robert_ancell: no, all other arches built
[08:16] <pitti> https://edge.launchpad.net/ubuntu/+source/gnome-system-monitor/2.27.3-0ubuntu1
[08:16] <pitti> robert_ancell: https://edge.launchpad.net/ubuntu/+source/gtk+2.0/2.17.2-0ubuntu2
[08:16] <robert_ancell> pitti: sorry, yes.  It sent me email saying the others hadn't built
[08:16] <pitti> robert_ancell: it's needs-build on sparc still
[08:16] <pitti> any/all arch conflict
[08:17] <pitti> don't worry about it
[08:46] <seb128> hello there
[08:48] <didrocks> hey seb128, did you have a nice week-end? :)
[08:48] <seb128> didrocks: too short but good yes, you?
[08:48] <didrocks> seb128: same, even if the "Libre music" festival in Paris was not as good as last year
[08:49] <seb128> libre music = fÃªte de la musique or something else?
[08:49] <didrocks> seb128: something related, but not exactly fÃªte de la musique: http://www.libreacces.org/spip.php?article75
[08:49] <pitti> hey seb128
[08:50] <seb128> ok
[08:50] <seb128> hey pitti
[08:50] <pitti> seb128: FYI, I'm packaging polkit-1 now
[08:50] <pitti> seems that we won't get around it
[08:50] <seb128> cool
[08:50] <seb128> yeah, GNOME is going to depends on it this cycle
[08:50] <pitti> new dk-disks and g-d-u releases depend on it
[08:50] <pitti> eggdbus is in the archive now
[08:51] <pitti> I hope that dk-power will be ported soon, too
[08:51] <pitti> seb128: do you think you can get the new gdm into karmic this week?
[08:51] <seb128> I can try but I doubt it
[08:52] <seb128> I still have no clue how to fix those upgrade issues and rick asked me to have a look to get the new GNOME3 component in before GUADEC
[08:52] <pitti> ah, ok
[08:52] <seb128> I expect the week to be busy
[08:52] <seb128> if somebody has a clue how to fix this "new gdm start after upgrade and autolog your user again"
[08:52] <pitti> now if only compiz would start..
[08:52] <seb128> and "the banner doesn't work until reboot"
[08:53] <pitti> well, it'd be enough for now to make it work at all..
[08:53] <pitti> upgrades, themes, etc. can be fixed later
[08:54] <didrocks> seb128: the new version.py script should now install launchpadlib automatically (thanks pitti for the script \o/ I had to hack it a little because of strange import behavior in python). I saw also that robert changed the package list.
[08:55] <seb128> yeah he dropped me an email
[08:55] <seb128> pitti: ah right it doesn't work for you, I need to try that it was working there but on a jaunty-karmic mixed install
[08:55] <seb128> didrocks: excellent, I will try that
[08:55] <pitti> seb128: just try installing it on a live system
[08:56] <seb128> well I can try on my laptop now I upgraded since
[09:10] <TheMuso> Is anyone working on realtimekit, and is there anything besides a future pulseaudio version that needs it?
[09:10] <seb128> that's the first time I read about this one
[09:10] <seb128> so I'm not and I don't know if anybody else here is working on it
[09:10] <pitti> likewise
[09:11] <TheMuso> ok
[09:11] <TheMuso> Will worry about it if/when its needed.
[09:12] <seb128> TheMuso: do you know why the gedit version you sponsoed is 1ubuntu1?
[09:12] <seb128> debian doesn't have this version they don't track 2.27
[09:13] <TheMuso> seb128: Twas an error that RObert made which I msised. *blushes*
[09:13] <seb128> ok, I was just wondering that's just a detail
[09:15] <seb128> pitti: I will look at the notify-osd update if you didn't yet
[09:16] <pitti> seb128: thanks, I didn't
[09:16] <seb128> good
[09:16] <seb128> MacSlow: looking at your notify-osd update ;-)
[09:16] <pitti> MacSlow: interesting "403 Forbidden" patch :)
[09:21] <seb128> ubuntu-devel-discuss is very noisy recently
[09:21] <Laney> you can say that again
[09:22] <Laney> it actually prompted me to reorganise my mail filters
[09:24] <didrocks> Fspot is a revival of Mono flameware... when will it stop?
[09:26] <Laney> when you apply your killfile :)
[10:01]  * pitti uploads policykit-1 to ubuntu-desktop ppa
[10:01] <chrisccoulson1> perhaps there should be a "mono-flamewar" list that these people should post to instead?
[10:02] <MacSlow> pitti What's missing?
[10:03] <pitti> MacSlow: look at your mail, the attachment 16_use_synchronous_notifications.patch
[10:03] <pitti> <?xml version="1.0" encoding="iso-8859-1"?>
[10:03] <pitti>   <title>403 - Forbidden</title>
[10:03] <pitti> :)
[10:17] <huats> morning everyone
[10:23] <MacSlow> pitti, resend
[10:23] <MacSlow> the "wonder" of evolution
[10:26] <pitti> hah
[10:37] <lool> MacSlow: Do you still need some help with autotools stuff, or did you manage to sort it out?
[10:39] <MacSlow> lool, I defeated it yesterday -> http://macslow.net/?p=316
[10:40] <lool> Cool
[10:40] <MacSlow> lool, the end-result for karmic-users/testers is -> http://macslow.net/clips/correct-throbbing-debug-bar-proximity-fade.ogv
[10:41] <Laney> MacSlow: you should look into pbuilder-dist if you want to manage multiple chroots
[10:41] <MacSlow> Laney, yeah... but not today :)
[10:42] <MacSlow> Laney, I keep that in mind for next time around
[10:42] <Laney> ok
[10:42] <lool> MacSlow: Cool :)
[11:30] <huats> didrocks: seb128 : just for the record, right after lunch I start to work on bugbuddy finally
[11:30] <seb128> ok
[11:30] <seb128> I just finished reading emails from the weekend, users are crazy
[11:31] <cassidy> seb128: tell me about that, I got a day off on Friday and I discovered 198 (upstream) Empathy bug mails this morning...
[11:32] <seb128> yeah, same for me, I had a 3 days weekend
[11:32] <seb128> got over 800 bugmails during the weekend
[11:35] <Zdra> cassidy: and you are not monitoring evolution bugs.... you can be happy!
[11:35] <cassidy> thanks god!
[11:48] <didrocks> huats: open a bug and assign it to you so that we can track it in versions.html
[12:13] <huats> didrocks: I already did it...
[12:14] <didrocks> huats: it's not in http://people.ubuntu.com/~seb128/versions.html
[12:14] <didrocks> did you add the right tag?
[12:15] <huats> didrocks: not tagged yet
[12:15] <huats> that is the pb, but the bug was created
[12:15] <huats> :)
[12:16] <didrocks> great, you can tag it, so :p
[12:16] <huats> hum
[12:16] <huats> actually it was already tagged desktop-upgrade
[12:17] <huats> and it does appear in the list
[12:17] <didrocks> oh, maybe a bug in desktop-upgrade, when did you tag it?
[12:17] <didrocks> (url?)
[12:18] <huats> (saying unasigned while I am assigned to it but it is a detail)
[12:18] <huats> I haven't tagged it !
[12:18] <huats> When I tied to do it, it was already done...
[12:18] <didrocks> can you paste me the url?
[12:18] <huats> https://bugs.edge.launchpad.net/ubuntu/+source/bug-buddy/+bug/390616
[12:18] <didrocks> huats: versions.py finds the bugs by their tags...
[12:19] <Laney> can I drop the gaim conflicts/replaces from pidgin now?
[12:20] <Laney> oh
[12:20] <Laney> nm
[12:23] <didrocks> huats: ok, so, you tagged it recentely and now it's updated (I didn't refreshed the page). Now, I'm wondering why the bug is unassigned. Let's wair for seb128 to push the new version on prod using launchpadlib rather than page parsing to see if it fixes it
[12:23] <didrocks> huats: or you can launch it now by yourself at home to check if the generated page contains your assigned name :)
[12:24] <huats> I can... but it is not a big deal I think
[12:25] <huats> but if it helps you I can launch it to test case
[12:26] <didrocks> huats: yes, please, can you launch it and paste me the result?
[12:35] <seb128> Laney: do you work on the pidgin update?
[12:35] <Laney> seb128: yes
[12:35] <seb128> ok good
[12:35] <Laney> we need to sru that yahoo fix right?
[12:36] <seb128> I guess so
[12:36] <Laney> fun
[12:36] <seb128> why?
[12:36] <pitti> ok, ubuntu-desktop PPA has polkit-1 crack now
[12:36] <seb128> didrocks: how is the local launchpadlib supposed to work?
[12:36] <seb128> pitti: cool
[12:36] <pitti> devicekit-disks is depwaiting on new libsgutils2 which is in karmic NEW
[12:37] <pitti> (*hint* :) )
[12:37] <pitti> trivial binary NEW, but I was the uploader
[12:37] <seb128> pitti: I can have a look ;-)
[12:37] <pitti> seb128: so, with dk-disks, packagekit, g-d-u and other stuff being ported, I guess we have to swallow this
[12:38] <pitti> it's pretty buggy still, but at least devkit-disks --mount /dev/sda3 works now
[12:38] <pitti> (internal drive)
[12:38] <pitti> I didn't package new g-d-u yet
[12:38] <pitti> lunch first ;)
[12:39] <cassidy> seb128: some TP components need to be upgraded: http://people.collabora.co.uk/~cassidy/tp-versions.html  Sync from Sid is automatic, right?
[12:39] <seb128> cassidy: yes
[12:40] <seb128> pitti: sg3-utils newed
[12:40] <pitti> seb128: thanks
[12:41] <seb128> you're welcome
[12:41] <pitti> seb128: let's have the regular archive admins worry about the new polkit/p-gnome stuff, and work in the ppa for now
[12:41] <pitti> seb128: IIRC you were blocked by this for some update
[12:41] <pitti> was it gvfs?
[12:41] <seb128> sounds good
[12:41] <seb128> yes gvfs
[12:41] <pitti> I hacked on gvfs over the weekend as well
[12:41] <seb128> but not hurry to get it updated
[12:41] <pitti> and seriously missed it as well
[12:41] <seb128> yeah I noticed your cdda and gphoto patches
[12:41] <pitti> so I backported my trunk patches
[12:42] <pitti> backports work fine for now, though, so it's not super-urgent
[12:42] <pitti> DIE, hal, DIE! :-)
[12:42] <pitti> and now, DIE, devicekit, DIE! :-)
[12:42] <pitti> (new devkit-disks doesn't use it any more)
[12:42] <seb128> lol
[12:43] <seb128> do they plan to stop rewritting everything one day?
[12:53] <didrocks> seb128: it's supposed to download launchpadlib if it's not present, and then, add it to sys.path, why?
[12:54] <seb128> doesn't work
[12:54] <didrocks> hum? I tested on my host purging launchpadlib :/
[12:54] <didrocks> (and its dependencies)
[12:55] <didrocks> seb128: can you show me any traces?
[12:56] <seb128> how are you supposed to use that tool? run it by hand?
[12:57] <didrocks> seb128: no. versions.py try to use launchpadlib from the distribution, if it doesn't find it, it launches the script to download it and then, bind to it.
[12:57] <didrocks> seb128: so, you don't have to run it by hand, just run versions.py
[12:57] <seb128> let me try that
[12:57] <seb128> WARNING: it seems that python-launchpadlib is not installed system widely nor locally. Try to install it locally.
[12:58] <seb128> dpkg-deb: failed to read archive `python-httplib2*.deb': No such file or directory
[12:58] <seb128> ERROR: can't install launchpadlib locally
[12:58] <didrocks> seb128: which version of the distribution is the prod server?
[12:59] <seb128> dapper
[12:59] <didrocks> urgh, maybe this package is not there, let me check
[13:01] <didrocks> seb128: this package exists from hardy :/
[13:01] <seb128> running things on dapper is no fun really
[13:01] <didrocks> and same for python-simplejson
[13:02] <didrocks> seb128: we only need one file from each package, I can maybe embeeded them and copy if not found. What do you think?
[13:02] <seb128> give it a try ;-)
[13:03] <didrocks> ok, one sec. I must connect on my server to branch the code :)
[13:07] <didrocks> seb128: can you try "dlocate /usr/share/python-support/python-httplib2/httplib2", we never know if it was on another package :)
[13:07] <seb128> didrocks: http://packages.ubuntu.com/ is your friend for that
[13:07] <didrocks> even for files? never used it
[13:07] <didrocks> let me have a look
[13:08] <seb128> "Search the contents of packages"
[13:08] <didrocks> oh, great, never used another thing that "search package directories" :)
[13:08] <seb128> it seems it was not on dapper no
[13:08] <didrocks> hum, ok, let's try with karmic version and cross the fingers :/
[13:16] <seb128> karmic is really a piece of crap to use, need to reboot again it's eating all ram and most of the swap again
[13:31] <chrisccoulson1> seb128 - whats eating all your ram in karmic? i was thinking of upgrading my main desktop this week (well, more of a forced reinstall as my Jaunty install isn't working too well)
[13:31] <seb128> the intel driver
[13:31] <seb128> seems to be a intel965 issue
[13:32] <chrisccoulson1> ah, thats not so bad for me, as i don't have intel hardware
[13:56] <kenvandine> pitti, eww... libgstfarsight depends on  gstreamer0.10-plugins-bad
[13:56] <kenvandine> that is not cool
[13:56] <pitti> kenvandine: right, what I wrote in the MIR bug
[13:56] <pitti> and on other gst plugins as well
[13:57] <kenvandine> yeah
[13:57] <kenvandine> humm
[13:57] <kenvandine> i will investigate
[13:57] <pitti> thanks
[13:57] <pitti> we need to strip -bad either way, and preferably also the other new dependencies (conserve space)
[13:57] <kenvandine> yeah
[13:58] <kenvandine> understand
[13:58] <kenvandine> morning tedg
[14:04] <tedg> Good morning kenvandine.
[14:06] <mpt> mvo, hi, ready for a call?
[14:06] <mvo> mpt: sure
[14:15] <seb128> MacSlow: do you really need those new gboolean in the g-s-d change?
[14:15] <seb128> can't you use the level being being 0 or 100?
[14:15] <MacSlow> no
[14:17] <MacSlow> seb128, I tried numerous things... only this guarantees me the trobbing indication is sent correctly by g-s-d or g-p-m (by -1 or 101)
[14:17] <seb128> weird
[14:17] <seb128> I don't like the change much I've to say
[14:18] <MacSlow> seb128, also I wanted to keep the patch change in one single spot only
[14:18] <seb128> why wouldn't looking for the value being > 99 work?
[14:18] <pitti> seb128: desktop-ppa now has latest g-d-u as well, FYI
[14:19] <seb128> bah
[14:19] <seb128> why does notify-osd require gmcs to build now?
[14:20] <seb128> pitti: ok thanks
[14:20] <SiDi> seb128: its because of the examples in mono, but they'll be optional in the next release
[14:20] <seb128> why do we need those to build notify-osd for karmic?
[14:21] <seb128> no example are installed
[14:21] <MacSlow> seb128, the steps at which brightness/volume are increased are different from time to time (and apparently system to system)
[14:21] <seb128> MacSlow: well the steps are but the 0 and 100 limits should not
[14:22] <MacSlow> seb128, pitti: gcms is only needed if you build notify-osd using --with-examples=mono
[14:22] <MacSlow> seb128, pitti: the package default is not to state --with-examples at all
[14:23] <MacSlow> seb128, pitti: thus it's not part of the build-requirements in the rules
[14:23] <seb128> MacSlow: http://launchpadlibrarian.net/28200152/buildlog_ubuntu-karmic-i386.notify-osd_0.9.14-0ubuntu1_FAILEDTOBUILD.txt.gz
[14:23] <seb128> MacSlow: it failed
[14:23] <MacSlow> seb128, pitti: and _I_ will not change that behaviour... not in notify-osd and not in the packageing... I had enough of this over the weekend
[14:24] <MacSlow> seb128, were did you pull notify-osd from? Trunk?
[14:25] <seb128> MacSlow: the 0.9.14 tarball
[14:25] <MacSlow> fuck!
[14:25] <seb128> we use tarball for distribution builds
[14:25] <MacSlow> I forgot to update that
[14:25] <MacSlow> one "sec"
[14:29] <pitti> seb128: hm, you don't merge trunk into ubuntu any more?
[14:29] <pitti> or is the error in the autoconfiscation? (which we take from orig.tar.gz indeed)
[14:30] <seb128> pitti: I do
[14:30] <seb128> bzr get lp:~ubuntu-desktop/notify-osd/ubuntu
[14:30] <seb128> cd ubuntu
[14:30] <seb128> bzr merge lp:notify-osd
[14:31] <seb128> dch -v new_version
[14:31] <pitti> ok, was just confused
[14:31] <seb128> debcommit -r
[14:31] <seb128> bzr push
[14:31] <seb128> I'm doing things wrongly again?
[14:31] <pitti> seb128: no, that looks fine
[14:31] <seb128> ok *pfffiou* ;-)
[14:31] <pitti> plus bzr bd -S, I take it? (to fetch new orig.tar.gz)
[14:31] <seb128> bzr-buildpackage
[14:31] <seb128> it gets the tarball and build
[14:31] <pitti> seb128: so the error MacSlow is fixing now is just in the orig.tar.gz, like in teh autogenerated Makefile.in, etc.?
[14:31] <pitti> seb128: righto
[14:32] <seb128> pitti: right
[14:32] <pitti> seb128: ok, that explains it then
[14:35] <mpt> mvo, a debconf prompt just grabbed focus, and I've no idea what I chose :-]
[14:36] <mpt> I was typing something when it popped up, and I pressed Space, which triggered one of the buttons
[14:37] <mvo> mpt: *weeeh* focus stealing ftw
[14:37] <mvo> mpt: but seriously, for 2.0 we could work on a more intergrated debconf
[14:38] <mpt> yes indeed
[14:38] <MacSlow> seb128, pitti: https://edge.launchpad.net/notify-osd/+milestone/notify-osd-<IP_ADDRESS>
[14:38] <mvo> mpt: unfortunately its not tirivial to embeded the frontends (and its auto-generated UI, so very hard to make not ugly in the general case)
[14:38] <seb128> MacSlow: thanks
[14:38] <mvo> mpt: hm, but for a start we could set focus-on-map=False
[14:39] <mpt> that would help
[14:40] <mpt> unless/until there's some way to front-load the questions
[14:41] <didrocks> seb128: I think you can bzr pull now. It works with intrepid package (not hardy ones). It took some time to setup a proper jaunty chroot with all depends :/
[14:48] <seb128> didrocks: that works now, good job ;-)
[14:48] <seb128> the page has been updated
[14:49] <didrocks> seb128: great \o/
[14:49] <didrocks> (but dapper is a pain ;))
[14:50] <seb128> dapper is old
[14:57] <seb128> MacSlow: your new notify-osd tarball...
[14:57] <seb128> MacSlow: it built fine, thanks for the tarball update ;-)
[14:58] <MacSlow> seb128, at least this time I came "prepared"
[14:58] <pitti> didrocks, seb128: don't worry about dapper; it's easier to set up the cronjob on another DC host (macaroni or cocoplum) and rsync the result to rookery, than trying to get this stuff running on dapper
[14:58] <MacSlow> not that I don't expect the next release to as gruesome as this one... at least for me
[14:58] <seb128> pitti: too late to say that, didrock managed to fix it ;-)
[14:59] <pitti> wow
[14:59] <pedro_> lool: salut, are you looking at bug 390591 ? just wondering since you were subscribed by the reporter.
[15:00] <lool> pedro_: I just verified that it was committed in the tip VCS
[15:00] <lool> pedro_: It seems we share packaging across Debian and Ubuntu, it's hosted in an Alioth SVN
[15:01] <lool> pedro_: I also confirmed the jaunty task as it seems SRU worthy, but I don't intend to actually prepare it (and didn't milestone it)
[15:02] <pedro_> lool: ah ok, thanks for the info
[15:02] <Laney> I think you two are talking about different bugs
[15:02] <lool> Ah we are indeed
[15:03] <lool> pedro_: Sorry, I touched only one f-spot bug myself; I see which bug you mean now
[15:03] <lool> pedro_: So for this armel crasher, I was subscribed because our ARM partners always subscribe me and then I dispatch  :)
[15:04] <lool> I usually assign or subscribe canonical-mobile for bugs we care about
[15:04] <Laney> I don't think they are PE executables
[15:05] <Laney> maybe it is broken, but that's not the reason I hope...
[15:05] <pedro_> lool: alright, do you want me to assign that to canonical-mobile then? would be good to have someone looking at it
[15:05] <lool> pedro_: I had sub-ed us some minutes ago, but I'll actually assign us
[15:06] <pedro_> lool: nice, thanks
[15:07] <lool> pedro_: Thanks for the heads up
[15:14] <rickspencer3> didrocks: did you see my updates to quickly over the weekend?
[15:15] <pitti> rickspencer3: good morning
[15:15] <rickspencer3> hi pitti
[15:16] <rickspencer3> http://piware.de/tmp/desktopteam-burndown-karmic.png
[15:16] <rickspencer3> nice, except we're above the trend line already
[15:16]  * rickspencer3 takes heartburn pill
[15:16] <rickspencer3> j/k
[15:17] <pitti> rickspencer3: if you start exactly at the top of TODO, that's kind of expected, isn't it?
[15:17] <rickspencer3> I was just kidding
[15:17] <rickspencer3> I didn't really expect any to be resolved over the weekend
[15:19] <didrocks> rickspencer3: yes, I reviewed them this morning. I have some changes to do, but it will only by the end of the week :)
[15:19] <rickspencer3> ok
[15:20] <didrocks> rickspencer3: I changed slightely the spec, integrating my remarks
[15:20] <rickspencer3> did you see how eeejay figured out how to handle deriving from gtk.Window and gtk.Dialog and still use Glade?
[15:21] <didrocks> rickspencer3: I'm unfortunately not a pygtk programmer. Currently learning it, so, I didn't attach yet so much important to this part of code. (but from what I know, we should use gtk.AboutDialog)
[15:21] <rickspencer3> didrocks: ok. trust me, it's very cool
[15:21] <rickspencer3> :)
[15:22] <didrocks> I trust you :)
[15:40] <seb128> pedro_: is that an impression or is the desktop bug activity crazy recently?
[15:41] <pedro_> seb128: it's raising considering the past weeks, i wouldn't say crazy yet but we're getting more bugs yeap
[15:41] <seb128> I think the hundredpapercut thing has been generating lot of noise
[15:42]  * awalton__ concurs.
[15:43] <pedro_> that's true, a good portion of the bug mail on the desktop-bugs is coming from there
[16:01] <Laney> seb128: do you have any ideas on python-gdl besides waiting for upstream?
[16:01] <seb128> build without the option for now or distro patch to build it?
[16:01] <seb128> it's probably easy to update to the abi changes
[16:01] <Laney> maybe, did debian do the same with gdl?
[16:05]  * Laney knows nothing about python-c bindings to fix it
[16:06] <seb128> Laney: no, debian doesn't track 2.27
[16:06] <Laney> it's on 2.25.3 in both
[16:07] <Laney> oh you mean gdl
[16:07] <Laney> nm
[16:08] <Laney> building pidgin now
[16:08] <seb128> cool
[17:29] <seb128> Laney: do you still work on the tomboy upgrade?
[17:29] <Laney> seb128: yes it's at the head of meebey's sponsor queue now
[17:29] <seb128> oh, you are blocking on a debian update to sync?
[17:30] <Laney> yeah
[17:30] <Laney> you can upload it direct if you want though
[17:30] <Laney> just pull it from git
[17:31] <seb128> no that's ok
[17:31] <seb128> I was reviewed the outdated desktop packages and wondering why this one was not moving
[17:31] <Laney> ah
[17:31] <seb128> we tend to no block on debian usually and update and sync later
[17:31] <Laney> i should have put it in the bug
[17:32] <seb128> but I'm being lazy if they update soon
[17:36] <Laney> i pinged meebey about it, maybe he uploads today
[17:36]  * Laney looks at vino
[17:38] <Laney> seb128: is that a debian bug too?
[17:38] <rickspencer3> seb128: pitti: pedro_: anyone else ... I'm writing tutorials for quickly, and will write reference as well
[17:38] <rickspencer3> what should I be using for authoring, and what format should I be releasing help in?
[17:39] <pitti> rickspencer3: I recommend docbook-xml as source format
[17:39] <pitti> rickspencer3: there are nice tools to convert that to manpages, HTML, LaTeX, etc.
[17:40] <pitti> and it's pretty much _the_ FOSS documentation standard nowadays
[17:40] <rickspencer3> pitti: thanks
[17:40] <rickspencer3> any recommendations for an editor?
[17:40] <pitti> like dookbook2html, or gtk-doc-tools
[17:40] <pitti> rickspencer3: oh, a flamewar gauntlet!
[17:40] <rickspencer3> oh
[17:40] <pitti> vim, of course! :-)
[17:41] <rickspencer3> lol
[17:41] <seb128> Laney: what debian bug?
[17:41] <seb128> rickspencer3: what pitti said
[17:41] <Laney> the conffile move
[17:41] <pitti> see, seb128 also recommending vim now :-P
[17:41] <seb128> Laney: they decided that using etc is wrong and started moving things to usr in a distribution specific way
[17:41]  * seb128 slaps pitti
[17:42] <Laney> seb128: and we don't follow this change?
[17:42] <Laney> or if they started cleaning the conffile we would?
[17:42] <seb128> I'm not decided yet, I've been not following it for now
[17:42] <seb128> we are not on sync for most GNOME packages anyway
[17:42] <Laney> ok
[17:42] <seb128> that's extra diff over upstream for no good reason
[17:42]  * Laney likes to strive for sync
[17:45] <seb128> right sync is good but for most of GNOME we package unstable versions and they don't anyway
[17:45] <pitti> rickspencer3: apt-cache search has conglomerate and qemacs, but pretty much any reasonable XML editor should do
[17:46] <pitti> rickspencer3: the other option is to just document it online in moin
[17:46] <rickspencer3> pitti: right
[17:46] <rickspencer3> what I want is to write it in one place, and export it as MOIN, HTML, etc...
[17:47] <pitti> rickspencer3: if you don't actually need moin, just HTML (which makes sense anyway, since you only want to change the source), then docbook2html or gtk-doc-tools are great
[17:48] <dobey> james_w: hey. source package branches should only contain the contents of the tarball, right?
[17:48] <dobey> james_w: plus the debian dir of course
[17:48] <james_w> dobey: as opposed to what?
[17:49] <dobey> james_w: extra cruft that may be in vcs needed to generated a release tarball, that isn't normally in a release tarball
[17:50] <james_w> ah
[17:50] <james_w> yeah, you probably just want what is in the tarball
[17:51] <dobey>  cool. thanks
[18:01] <Laney> pidgin diff is up
[18:10] <pitti> good night everyone
[18:11] <Laney> seeya
[18:39] <rickspencer3> pitti: it looks like "mallard" is the new standard for documentation authoring
[20:13] <dobey> asac: ping
[20:45] <dobey> hrmm
[20:45] <dobey> what's the diff between Build-Depends-Indep and Build-Depends?
[20:50] <Laney> build-depends-indep are packages only needed to build the arch-indep packages
[20:51] <dobey> Laney: so you can build only the Architectrue: all packages, without having to build the other packages for x86 or something?
[20:51] <Laney> right
[20:51] <Laney> via build/binary-indep
[20:52] <dobey> ok
[20:53] <dobey> so basically pointless for any package that only produces Architecture: all package(s)?
[20:53] <Laney> yeah
[20:53] <dobey> fun
[20:57] <kenvandine> dobey, how is the u1 packages coming?
[20:57] <dobey> kenvandine: will be fixed up very soon now
[20:58] <kenvandine> great
[21:51] <chrisccoulson> is there any point in opening papercut tasks for applications that are likely to disappear shortly?
[22:04] <Ampelbein> chrisccoulson: i don't think so. In my opinion, that's a waste of time for the developers.
[22:04] <chrisccoulson> yeah, i agree
[22:04] <chrisccoulson> i was just wondering what other peoples opinions were
[22:05] <chrisccoulson> i marked a bug in gdm-setup as a duplicate of an old gdm bug, but deliberately didn't copy the papercut task across as gdm-setup is gone from the new gdm. then someone told me i forgot to copy the task across :-/
[22:08] <dobey> kenvandine: i uploaded a new ubuntuone-storage-protocol to REVU
[22:08] <dobey> kenvandine: will have new ubuntuone-client very shortly
[22:40] <dobey> kenvandine: new ubuntuone-client is uploaded now too
[23:46] <kenvandine> dobey, woot
[23:59] <chrisccoulson> hi robert_ancell. just looking at this gnome-panel update. i think i drew the short straw;)


[04:14] <swan1> Hello.  I am running mythbuntu 12.04.2, w/mythtv .26 and have configured audio so that it is sent to my tv via HDMI. Unfortunately, if I leave the system idle for a while (>1h) audio no longer works.  If I reboot, it works again.  How do I 1) Turn off the power saving (mis)feature and 2) fix the audio issue?
[04:17] <swan1> I have also disabled screen blanking, so I don't think that is involved.
[05:23] <qwebirc41727> Thanks
[11:17] <scumbum> Hello


[01:28] <Montresor> !info base-files lunar
[01:29] <Montresor> Bots now know of the lunar repo.
[21:56] <guiverc> the topic for ubuntu-next can be updated (lunar lobster; 23.04)