[04:08] <hareendra> hello there
[04:09] <hareendra> any one wo has developed some pannel item (like network manager) to unity
[04:09] <hareendra> ?
[10:37] <jml> OK. Wow.
[10:38] <jml> Having to sneak into a flatmate's room to get internet is not how I like to start the day.
[10:39] <noodles775> ouch
[10:46] <mvo> jml: weeh, that sounds not right :/
[10:47] <jml> the router is in their bedroom.
[10:47] <jml> should probably see if we can move it
[10:49]  * mvo nods
[10:58] <jo-erlend> I would like to run tests on every save in gedit. So, when I save the file database.py, then it should run trial test_database.py. How do I do that?
[10:58] <jml> jo-erlend: I guess there are two things there
[10:59] <jml> one is detecting the save and doing something
[10:59] <jml> the other is doing the right thing
[10:59] <jml> If you put an emacs-style variable in database.py like this:
[10:59] <jml> # -*- test-case-name: foo.tests.test_database -*-
[11:00] <jml> then 'trial --test-module=foo.database'
[11:00] <jml> will run test_database
[11:00] <jml> as for doing something on save, umm, that I don't know.
[11:01] <jml> I mean, you'd probably have to write a program. But it seems like the sort of program that someone must have already written.
[11:01] <noodles775> ooh, I remember chatting with james_w about something similar a few years ago (like growl)... and, in typical james_w fashion, he came back the next day with a prototype:
[11:01] <noodles775> https://code.launchpad.net/~james-w/+junk/test_watcher
[11:01] <jo-erlend> I would like to display a notification bubble on save showing whether the tests pass or not.
[11:02] <noodles775> ... and here's the mock-demo I did that started our conversation: http://www.youtube.com/watch?v=bvUDYmllVrM
[11:03] <jo-erlend> Actually, if all tests pass, it should display that bubble and run bzr qcommit.
[11:03] <jml> noodles775: cool.
[11:04] <jml> noodles775: I was thinking of a more generic "have files in this dir changed" watcher
[11:04] <jml> noodles775: but that'll do :)
[11:07]  * noodles775 used to use rspactor years ago, looks like it's turned into https://github.com/guard/guard now.
[11:11] <jo-erlend> noodles775, that looked very similar to what I want.
[12:21] <jml> noodles775: apparently there's plans to have upstart use inotify to watch directories and trigger jobs.
[12:21] <noodles775> Nice
[12:26] <jo-erlend> jml, you mean watch all directories?
[12:26] <jml> jo-erlend: I meant specific directories, but to be honest I don't know the details.
[12:27] <jml> jo-erlend: this is just stuff I picked up from ev from his work on the crash db
[12:28] <xruud> I'm going to develop a program on a ubuntu device (prefer it to be headless). The program looks exactly like a photoframe and shows images from the internet. There is no user interaction and the program updates itself. Which develop environment and language would best suit these needs?
[12:35] <xruud> don't answer all at once please :)
[12:36] <xruud> fyi, I'm going to try Quickly and MonoDevelop
[12:54] <jml> \o/
[13:05] <jo-erlend> xruud, Quickly is a very good choice. :)
[13:32] <dpm> xruud, let us know how it goes! We recommend quickly (i.e. python and the other tools/technologies it puts together). You can learn how to get started here: http://developer.ubuntu.com/get-started/
[13:32] <dpm> Other interesting resources:
[13:33] <dpm> http://developer.ubuntu.com/resources/tools/quickly/
[13:33] <dpm> http://developer.ubuntu.com/resources/tutorials/all/diy-media-player-with-pygtk/
[13:58] <jml> oh, apparently distribute and pip are supposed to replace setuptools and easy_install
[13:59] <jml> except that distribute recommends using easy_install in all its documentation
[13:59]  * jml goes to buy some real eggs from the supermarket
[14:45] <noodles775> jml: how do I add a requirement in a setup.py based on a bzr branch? (i just tried adding a bzr+http dependency_link in the setup.py but it's an unknown url type.
[14:45] <jml> noodles775: I'm working on that now. Turns out I might have misinformed you earlier based on a doc that misinformed me.
[14:46] <noodles775> Ah, k. I'll upload a tarball instead :/. Thanks!
[14:58] <xruud> dpm: I'm trying Quickly first. Curious how it will turn out!
[14:59] <jml> noodles775: yeah, using the requirements file seems to be it
[14:59] <jml> noodles775: can you remind me why setup.py is preferred for non-test dependencies?
[15:00] <noodles775> jml: I assume so that the package can be installed via the setup.py?
[15:00] <noodles775> (at least, that's what I've been using it for)
[15:01] <jml> Hmm. I guess that matters if you want to use it as a dependency in another pip/virtualenv/distribute/setuptools/easy_install project
[15:01] <noodles775> yeah. I think it was ricardok who started that, and pointed out that there's no reason for them not to be valid python packages (ie. installable themselves)
[15:01]  * noodles775 likes it.
[15:02] <noodles775> Interestingly, I just started using it to deploy an app in a juju charm.
[15:02] <jml> I can imagine it's nice when it works, and when you aren't developing dependencies in collaboration or using experimental dependencies
[15:09] <dpm> ruudt, awesome, let us know how it goes, and feel free to ask any questions!
[15:12] <jml> I'm getting pretty sick of compiling bzr though.
[15:42] <jml> OK. Now when it's running a binary backend script that script cannot import from devportalbinary
[15:42] <jml> despite devportalbinary being installed in the virtualenv and the script using '#!/usr/bin/env python'
[15:44] <noodles775> jml: but if the script is being run from a cron, it's not going to know about your virtualenv is it? /me isn't sure of your setup.
[15:45] <jml> noodles775: it's not being run from cron
[15:45] <jml> noodles775: the tests, running in a virtualenv, are running some code that runs an executable script which happens to be a Python script
[15:47] <noodles775> How is it running the script? popen or something else? (and if it's within the context of a django app, can you use a custom django management command? (easier to test - maybe)
[15:47] <noodles775> https://docs.djangoproject.com/en/1.3/howto/custom-management-commands/
[15:49] <jml> ah hah
[15:49] <jml> it's using system python
[15:49] <jml> it's using system python
[15:49] <jml> (oops)
[15:50] <jml> noodles775: pkgme itself is launching the script, so we can't use django magic there
[15:50] <jml> now, why is it using system Python?
[15:50] <noodles775> how are you running your script from your test?
[15:51] <jml> Ah hah
[15:51] <noodles775> achuni: with the ssoclient, what's the equivalent of a the lazr.restfulclient authenticated API?
[15:51] <jml> noodles775: pkgme uses subprocess.Popen, and the test uses pkgme.
[15:52] <jml> the issue is that 'fab test' is wrong
[15:52] <noodles775> jml: cool
[15:52] <achuni> noodles775: the lazr.restfulclient authenticated api as in api.authentications.authenticate()?
[15:52] <jml> 'virtualenv/bin/python django_project/manage.py test djpkgme' != 'django_project/manage.py test djpkgme' under the virtualenv
[15:53] <noodles775> achuni: no, as in ServiceRoot(BasicHttpAuthorizer(username, password), service_root_url)
[15:54] <noodles775> jml: why not? does your manage also have the '#!/usr/bin/env python' ?
[15:54] <noodles775> oh, I guess it does, or you'd see lots of failures...
[15:54] <jml> yes, it does.
[15:54] <achuni> noodles775: that would be SingleSignOnAPI(BasicAuthorizer(username, password), service_root_url)
[15:54] <achuni> noodles775: and BasicAuthorizer is from piston_mini_client.auth
[15:55] <noodles775> achuni: ah... sweet. I love piston_mini_client.
[15:55] <achuni> noodles775: eh, and the args go in the other order
[15:55] <noodles775> achuni: yeah, I'll use kwargs anyway.
[15:55] <achuni> good idea :)
[15:56] <jml> noodles775: I'm trying to figure out why not.
[15:57] <noodles775> achuni: do you mind if I keep nutting away at this charm if you'll be at the USC call? Or do you prefer me to join too?
[16:00]  * noodles775 joins to be on time anyway :)
[16:01] <achuni> noodles775: don't worry, there shouldn't be anything pressing on the call
[16:02]  * noodles775 is already there now.
[16:07] <james_w> noodles775, what's the charm you are working on?
[16:08] <jml> noodles775: fwiw, the difference is that sourcing 'activate' sets PATH. Just running the python in the virtualenv does not.
[16:10] <james_w> yay virtualenv
[16:10] <jml> yeah
[16:10] <jml> I've lost a lot of time to it & its cousins
[16:13] <noodles775> james_w: apache-django-wsgi - a general charm for deploying any django app.
[16:13] <jml> and yay, cdiff doesn't work in virtualenv because bzr is a dependency
[16:13] <james_w> noodles775, cool, I'd love to take a look
[16:14] <noodles775> james_w: yeah, I'll email/post once it's working. Right now I'm trying to remove lazr.restfulclient dependencies from apps.ubuntu.com - the demo app I'm using :/
[16:17] <noodles775> jml: isn't your issue that your 'manage.py test djpkgme' is running within the virtualenv, but when you're calling popen, the resulting process isn't? (/me guesses it's inheriting the env, which doesn't include any special PATH, as you said)?
[16:18] <noodles775> (and that would make sense, IMO)
[16:24] <noodles775> (hrm, other way around, `virtualenv/bin/python manage.py test` is spawning a process which knows nothing about the virtualenv as PATH isn't set)
[16:26] <jml> noodles775: no, that's not the issue
[16:26] <noodles775> ah, k.
[16:26] <jml> noodles775: what does "within the virtualenv" mean?
[16:27] <jml> it means a certain configuration of environment variables, of which PATH is one
[16:27] <jml> which is *not* set just by running virtualenv/bin/python
[16:27] <noodles775> jml: That was meant to say "isn't your issue that you 'virtualenv/bin/python manage.py test djpkgme' is running within the virtualenv", in which I meant, running with the virtualenv's python.
[16:28]  * noodles775 doesn't see why it would need to set it - *unless* you were spawning python processes?
[16:28] <jml> so if whatever module is passed to virtualenv/bin/python launches a script that uses '/usr/bin/env python', it's going to get python from the default path
[16:28] <jml> not whatever path would be set by sourcing virtualenv/bin/activate
[16:29] <jml> noodles775: yes, I said I was spawning Python processes didn't I?
[16:29] <noodles775> yep, I was just trying to figure out what other use cases would require it, but you just ansswered that :)
[16:31] <noodles775> So what's the result? If your process will spawn other python processes, make sure the path is set? Yuk. I guess we've never had that issue as our scripts are all django management commands, which we test without needing to spawn a process.
[16:32] <jml> noodles775: umm... actually, I think the net result is that fab should be within the virtualenv if you want to use fab properly.
[16:32] <james_w> again this seems to come down to the issue that all these tools (virtualenv, eggs, pkg_resources) seem to have been built with an assumption that the whole world is Python
[16:32] <jml> yes
[16:36] <noodles775> james_w: I don't really understand what you mean - aiui, virtualenv is only trying to solve a python issue (replicating development environments - python packages - on various OSs?)
[16:37] <noodles775> Ah... do you mean like when you try to include PIP in your virtualenv, it tries to compile and fails (or similar). ie. python packages that are wrappers around C++ libraries?
[16:37] <james_w> noodles775, yes, but it works best when you have no other code in your project
[16:37] <james_w> in this case we want to run scripts in any language that the backend developer wants
[16:37] <james_w> if we just supported Python we could use entry points or something
[16:37] <noodles775> But you're not using a virtualenv for your actual deploy? (are you?)
[16:38] <james_w> no, we're not
[16:38] <james_w> but we have a choice between declaring not to work in virtualenv (or as an egg etc.), or making this work
[16:41] <noodles775> And what's not working with virtualenv? (jml's issue above makes sense, and is easily solved I think?). Or on the other hand, do you need to be using a virtualenv at all, or is it just because the dpkgme was setup that way?
[16:42] <jml> noodles775: there's a hacky way of solving my issue, which is guessing the PATH that virtualenv/bin/activate sets and running 'PATH=$that_guess fab test' (or running fab inside the virtualenv and having to deal with broken/less functional bzr)
[16:43] <james_w> noodles775, there's this which is an extension of something jml was fighting last week, which is that it's really hard to find the paths where python puts data files when dealing with eggs/virtualenv/etc.
[16:44] <noodles775> jml: yuk, yes I didn't realise it was that messy.
[16:45] <noodles775> jml: is it not just adding virtualenv/lib/python-2.x/site-packages ?
[16:46] <jml> noodles775: umm, no. it's at least inserting virtualenv/bin to the top of PATH
[16:46]  * noodles775 was thinking of PYTHONPATH, sorry.
[16:47] <jml> noodles775: so, it's easy to make a good guess, but if virtualenv changes its behaviour then it'll break again.
[16:48] <jml> i.e. it's an abstraction violation to have to manually specify PATH
[16:49] <noodles775> Sure - I'm just trying to understand why we've never hit this issue, atm I think it's as above, that we've only ever used django commands for our scripts, which we can test within teh same process.
[16:51] <noodles775> also, afaik, we never use or depend on activate.
[16:53] <noodles775> jml: perhaps a better way would be to pass the current python interpretter to Popen in your test? (ie. the subprocess always runs with the same python environment as the tests themselves)?
[16:53] <noodles775> interpreter, even.
[16:54] <jml> noodles775: if I could rely on all pkgme backends being written in Python, that would work
[16:55] <noodles775> jml: isn't this issue only (1) relavent to test in your dev env which is using a virtualenv, and (2) relevant to backends written in Python?
[16:55] <jml> noodles775: the test isn't directly running the subprocess, it's calling something that calls pkgme, which invokes the backend
[16:55] <noodles775> Ah, I see :(
[16:56] <noodles775> Hrm, so why is the backend even dependent on the virtualenv? (sorry if I'm going around in circles). Shouldn't it be independent of your development environment?
[16:58] <jml> how could it not be? this one is written in Python
[16:58] <jml> it needs to import its own Python modules to work
[16:59] <dpm> ok everyone, calling it a day today, see you tomorrow!
[17:00] <jml> where's it going to get them from? Can't get them from the system, because we're in a virtualenv. So it has to be specified as a dependency of djpkgme and it has to get its modules from within the virtualenv
[17:02] <noodles775> I didn't realise a backend importing its own python modules would be a problem. I'd thought the backend might not need to import djpkgme stuff, but I guess it does.
[17:03] <noodles775> hrm, no, it shoudn't should it? (ie. non-python ones won't be obviously)
[17:04] <jml> it doesn't need to import djpkgme
[17:04] <jml> this backend (lp:pkgme-binary) has got a fair chunk of code written in Python
[17:04] <james_w> jml, I'm on mumble when you want to chat
[17:04] <jml> that's how it works
[17:04] <jml> I could have written it in Go
[17:04] <noodles775> heh
[17:06] <noodles775> I'm sure I don't know enough about the setup, I'm just not understanding why the backend - if it's a separate independent process - needs to be in the virtualenv, rather than being a self-contained python package. It'd probably be obvious if I looked at the code instead of asking annoying questions.
[17:06] <noodles775> Anyway, dinner time here. Night people.
[17:06] <jml> g'night.
[17:45] <james_w> jml, https://github.com/wmorgan/heliotrope
[19:10] <Guest13163> how can i determine if a package is installed on ubuntu programmatically (c++)? is there a website that explain this?
[21:09] <ruudt> Developing with quickly presents a problem; searching in google for anything like "create fullscreen app quickly" gets misinterpreted. How do you do find answers?
[21:47] <JanC> ruudt: the default quickly templates use PyGtk = Python + Gtk+, so use PyGtk or maybe Gtk for searching
[21:48] <ruudt> JanC: Thanks. I still need to figure out if I need quickly. I will be running it on a headless ubuntu installation. But the program has no user interface but shows images
[21:49] <JanC> headless?
[21:49] <JanC> how will you show images then?
[21:49] <ruudt> can't I
[21:49] <ruudt> It actually is a minimal install
[21:49] <JanC> what do you mean by "headless"?
[21:50] <ruudt> no gui
[21:50] <JanC> ah, most people mean "no display" by "headless", hence my confusion...  ;)
[21:51] <JanC> ruudt: and by "no GUI", do you mean "no X" or "no desktop environment"?
[21:52] <ruudt> no, I had to install 835 packages to get xubuntu-desktop :P
[21:53] <ruudt> So I'd say it is safe to say there is no desktop environment
[21:53] <ruudt> The difference between x or desktop env I do not know (yet)
[21:55] <JanC> X is basically the system that puts everything graphical on the screen on linux desktops
[21:55] <ruudt> I am quite new and might be ignorant of many parts still. Though I try hard to learn everything
[21:56] <ruudt> The minimal install starts and displays tux while doing so. Would that imply X?
[21:56] <JanC> and a desktop environment is a collection of programs (e.g panels, window managers, etc.) that give you a useable desktop experience
[21:56] <JanC> nu, that's just using the "framebuffer"
[21:57] <ruudt> JanC, I see. I would like the machine to have a minimum of packages installed. It needs wifi and the ability to display images fullscreen
[21:57] <ruudt> Should I use quickly?
[21:58] <ruudt> The tutorials seem fixed on making gui programs
[21:58] <JanC> you can display images in this simple framebuffer, but there is not much support for making it easy in that (and generally there is no support for 3D or other GPU acceleration in that framebuffer)
[21:58] <ruudt> I don't need that
[21:58] <ruudt> I need to display images downloaded from the internet. Nothing more or less
[21:59] <ruudt> Alike a picture frame
[22:00] <JanC> ruudt: I'm pretty sure there are already applications to do that, and you could use a simple script to link them, are you sure that's no solution for your problem?
[22:00] <JanC> I mean, applications that show images and applications that can download images
[22:01] <ruudt> JanC: that would be fine for my purposes. You suggest I'd find them first. Is there any tactic I should use to find them?
[22:02] <ruudt> (Google using specific terms)
[22:07] <JanC> to be honest I have alsmost no framebuffer experience, but certainly "framebuffer" is one thing to search for  ;)
[22:10] <ruudt> actually really simple suggestion. I found some things on frambuffer. But will discover what I found tomorrow. Sure hope this will be easier then I think it will be. Thanks
[22:10] <JanC> one other thing you could do is install an X server (either the default Xorg or an alternative one) and use a simple, single maximized PyGtk app on top of that (you could even use Quickly to create it then, which might help packaging, if that's needed)
[22:10] <ruudt> Can I install X on any linux installation if it was not included?
[22:11] <ruudt> Because I'm somewhat limited in Linux options :P
[22:12] <JanC> I don't know any well-known desktop linux distro that doesn't have packages for one or more X servers (and certainly not without Xorg)
[22:12] <JanC> of course an embeded distro like Android is different
[22:13] <ruudt> Ok, I'll be fine on that part then
[22:14] <JanC> http://directfb.org/ might be useful too
[22:14] <ruudt> Indeed. thanks!
[22:14] <JanC> if you don't want to use Xorg
[22:15] <ruudt> I'm going to sleep now. I'm almost hitting the keyboard with my head ;)
[22:15] <ruudt> But be sure I'll try your suggestions tomorrow