[00:13] <Laney> python-gdl is uninstallabla
[00:13] <Laney> e*
[00:19] <chrisccoulson> its quiet in here this evening
[00:20]  * robert_ancell watches the tumbleweed float past
[00:20] <chrisccoulson> lol
[00:21] <chrisccoulson> i should probably get some sleep really. i always wake up late for work else
[00:23]  * TheMuso hopes that his local power grid doesn't go down again like it has three times already this morning.
[00:24] <chrisccoulson> TheMuso - that's not good. why is that happening?
[00:25] <TheMuso> chrisccoulson: Because our power grid around here is somewhat flaky, and doesn't have backup power routing.
[00:26] <TheMuso> It doesn't take much for a storm to bring several towns who are on the one grid setup down for 3 hours or more at a time, and similar to this morning, it can simply go down for a minute or so at a time, and come back, or go down for 3 hours plus.
[00:27] <chrisccoulson> i cant remember the last time that happened here. i remember losing power lots when i was growing up, but it rarely seems to happen here now.
[00:27] <TheMuso> Every mini power outage that I experienced this morning saw me hoping the power wan't going to be out for more than five minutes or so./
[00:27] <TheMuso> Things *seem* to be ok now, but you never know with a piece of garbage power grid like whats in this local area.
[00:28]  * TheMuso can't wait to return to Sydney proper, although power grid issues have been occurring their lately as well. :S
[00:29] <chrisccoulson> when are you returning to sydney?
[00:30] <ajmitch> TheMuso: sounds like you like to live on the edge there
[00:30] <TheMuso> ajmitch: Not by choice.
[00:30] <TheMuso> chrisccoulson: Hopefully later this year, I hope to buy an appartment.
[00:31]  * ajmitch can't recall the last time there were power problems here
[00:31] <chrisccoulson> nice(H). i keep getting sent lots of information about career opportunities in australia
[00:31] <chrisccoulson> its very tempting
[00:48] <Ampelbein> robert_ancell: hi! i see you worked on the desktop-versions-script. I changed it to use python-launchpadlib to get the list of bugs and their respective assignee. code at https://code.edge.launchpad.net/~amoog/+junk/versions . should I file a merge request?
[00:49] <robert_ancell> Ampelbein: It's since been worked on by didrocks who added launchpadlib support, have you checked out the latest version?
[00:51] <Ampelbein> robert_ancell: oh, seems he pushed his change after i checked out. will look at his code.
[00:59] <Ampelbein> didrocks: hi. regarding your integration of python-launchpadlib in the desktop-versions script: why do you use regex-matching instead of querying the object directly?
[01:45] <bryce> rickspencer3-afk, I filed bug #389269 about that upstream bug importance issue I mentioned the other day
[01:46] <bryce> rickspencer3-afk, it'd be sweet if you could bump the priority on that
[01:46] <rickspencer3-afk> bryce: ok
[01:46] <rickspencer3-afk> let me talk to Kiko
[01:47] <rickspencer3-afk> I'm wondering if it's supported but requires freedesktop.org to use this launchpad pluggin, which would require them to upgrade their bugzilla
[01:47] <rickspencer3-afk> in which case, I was really hoping to meet up with someone at Guadec from freedesktop, because I have not tracked down the admins to talk to about this
[01:47] <rickspencer3-afk> (emails not answered)
[01:47] <rickspencer3-afk> thanks!
[01:47]  * bryce nods
[01:48] <bryce> I would think they'd be able to snarf the importance the same way they're snarfing status, but who knows
[01:52] <Ampelbein> robert_ancell: hi again. I've made some changes to the py-lp-lib code introduced by didrocks, can you review and possibly apply them? available at https://code.edge.launchpad.net/~amoog/+junk/ubuntu-desktop-versions
[01:52] <robert_ancell> Ampelbein, ok, will look
[01:53] <rickspencer3-afk> robert_ancell: so, if you click on a widget in glade, and then right click inside the inspector treeview, you can choose "edit at top level", in which case it produces a valid UI file that you can use to create a custom widget!
[01:54] <robert_ancell> rickspencer3-afk, cool!
[01:54] <rickspencer3-afk> then you can slurp that widget into a class that derives from frame
[01:54] <robert_ancell> Ampelbein, you have tabs! evil ;)
[01:55] <Ampelbein> robert_ancell: so no tabs? whitespaces all along? and who's gonna buy me a new space-key? ;-)
[01:55] <robert_ancell> haha
[01:55] <robert_ancell> Ampelbein, I didn't say you had to press space, just i done want to see 0x09 in your binary! :)
[01:57] <Ampelbein> robert_ancell: ok then.
[01:59] <robert_ancell> Ampelbein, looks good, the less regexp in the world the better. I've committed with whitespace changes
[02:01] <Ampelbein> robert_ancell: thanks. i'm trying to find out a way to search the bug-subscriptions but no luck yet. Best I can come up with is to iterate through bug_subscription[] and string-compare. but that's much slower than the current way.
[02:05] <robert_ancell> Ampelbein: There is a feature that I want if you're keen to implement it:  I want it to be able to track the popular universe desktop packages and have a toggle to enable/disable these (using javascript or similar). That way this tool can be useful to the community
[02:08]  * TheMuso sighs. All code should be tabbed in, and not white spaced, enough said.
[02:08] <Ampelbein> robert_ancell: i'm unsure if i understand correctly. the generated page should have this toggle? wouldn't it be easier to generate 3 versions of the html? 1) standard packages 2) extra packages 3) all packages
[02:09] <robert_ancell> Ampelbein, we could generate 3, but it would be cooler if it could be toggled without reloading :)
[02:10] <Ampelbein> robert_ancell: i know you would say that.
[02:10] <Ampelbein> *knew
[02:11] <robert_ancell> Ubuntu has to be Web 2.0 compliant!
[02:13] <Ampelbein> robert_ancell: i can try to do this. but not today, it's 03:12AM and i'm too tired... need my 3 hours sleep per day ;-)
[02:14] <robert_ancell> Ampelbein, !! I thought you were in an Eastern timezone!
[02:14] <Ampelbein> robert_ancell: nah, germany. CEST.
[02:15] <robert_ancell> Ampelbein, I'm in Sydney
[02:16] <Ampelbein> robert_ancell: you could the internetz in down under? way cool! *eg*
[02:16] <Ampelbein> *could have
[02:16] <Ampelbein> arghs. *can have. too tired, as i said.
[02:26] <robert_ancell> Ampelbein, still awake?  Do you know how to get the importance of a bug from lplib?
[02:29] <Ampelbein> robert_ancell: short version: you can't. long version: you have to take the importance from the bug_task
[02:36] <Ampelbein> robert_ancell: got my messages? had a disconnect.
[02:37] <robert_ancell> Ampelbein, got it, thanks!  I just modified versions so it now uses the correct bug icon
[04:31] <robert_ancell> TheMuso, how well do you know gstreamer?
[04:33] <TheMuso> robert_ancell: Not that well.
[04:34] <robert_ancell> What I'm trying to work out is should a gst input have a mute?  I think it is obsolete due to the recording toggle
[04:50] <TheMuso> No idea.
[04:50] <TheMuso> The only thing I know about gstreamer is that it allows pipelines to be constructed using various plugins as inputs/outputs.
[05:18] <dobey> robert_ancell: rather it seems odd to me that i have to click a button to tell the system i might want to record from my microphone
[05:19] <dobey> not that clicking the button seems to particularly help, or do anything, or actually stay set to recording
[05:19] <dobey> mute for inputs should mean "don't record from here"
[05:20] <robert_ancell> dobey, I think that mute is for output only and the record toggle is the equivalent for inputs.  You should only need both for a bi-directional track
[05:21] <dobey> robert_ancell: are you pondering UI, or the implementation?
[05:23] <robert_ancell> dobey, fixing bug #578174, the volume control is doing what is thinks gstreamer is telling it to do but it is wrong
[05:23] <robert_ancell> bug 299642
[05:23] <dobey> ah ok
[05:24] <dobey> robert_ancell: i think part of the problem might be a bug in whatever handles the register change for when external headphones/mic are plugged in to the 3.5 mm jack
[05:24] <dobey> on both my fujitsu laptops, plugging in headphones does not mute the internal speaker
[05:25] <robert_ancell> dobey: yes, it appears there are a number of issues here - audio is very hard for users to diagnose
[05:25] <dobey> and on my older one, i can seem to use skype if i plug in an external mic, but i can't get the internal mic to work
[05:25] <dobey> i don't even want to try to describe some of the issues on my newer laptop
[05:26] <dobey> i'm going to chalk it up to "poulsbo makes stuff break" at the moment
[05:27] <TheMuso> dobey: That jack sense stuff is at the ALSA driver layer, i.e alsa doesn't know the correct hda verbs.
[05:28] <dobey> TheMuso: i don't care where it is. i just want it to work. the UI suggest it works. however, it does not. :)
[05:28] <TheMuso> dobey: Yes, I know.
[05:33] <bryce> heya rick
[05:33] <dobey> anyway, so very tired
[05:33] <dobey> must sleep
[05:33] <dobey> later
[05:34] <robert_ancell> bryce: Is rick avoiding you?
[05:34] <bryce> robert_ancell, looks like!
[05:34]  * TheMuso notes that hda hardware + just want it to work do not go hand in hand very well, especially for new hardware.
[05:37]  * TheMuso goes to dig up his USB sound card.
[06:01] <robert_ancell> TheMuso, why are we not using the new gnome-volume-control yet?
[06:01] <TheMuso> robert_ancell: We need to do the switcheroo.
[06:01] <TheMuso> Not hard to do, I need to work with pitti/another archive admin to do that.
[06:01] <robert_ancell> TheMuso, switcheroo?
[06:02] <TheMuso> robert_ancell: Switch the current volume applet around with the pulse applet. Involves uploading a new panel schema with the volume applet removed, and loading the pulse applet on startup.
[06:02] <robert_ancell> TheMuso, is this scheduled for Karmic?  It would be nice to align with upstream
[06:03] <TheMuso> robert_ancell: yes scheduled for karmic, part of the big audio integration drive.
[06:03] <robert_ancell> TheMuso, ah, cool
[06:35] <robert_ancell> bryce, is it ok to push compiz reports with driver problems to xorg?  e.g. bug 340673.  I think you have the process to filter them better than I can do manually
[06:53] <Amaranth> bryce, If we can get the patches that fixed https://bugs.freedesktop.org/show_bug.cgi?id=20704 into xorg and mesa I can do the compiz patch that goes with it
[07:15] <robert_ancell> LOL, the one hundred paper cuts project has 385 bugs and counting...
[07:16] <Amaranth> robert_ancell, Yeah, I think I closed about 20 of them
[07:17] <Amaranth> robert_ancell, too much bug mail
[07:17] <robert_ancell> yes, everyone has a pet bug they want to attach
[07:41] <robert_ancell> see you all next week
[08:08] <didrocks> Ampelbein: Thanks for the patch ;) If you have a good launchpadlib documentation, I can take it, because https://launchpad.net/+apidoc seems a little bit oudated (We can infer that A.<something>_link has a A.<something> corresponding object?)
[08:09] <didrocks> morning everyone o/
[08:24] <MacSlow> Greetings everyone!
[08:47] <didrocks> hey seb128!
[08:48] <seb128> hello didrocks
[08:49] <didrocks> seb128: there are some changes in versions.py script, if you want to try them :)
[08:52] <seb128> lot of changes
[08:52] <seb128> did you duplicate work for the launchpadlib changes?
[08:52] <seb128> you apparently did some of those changes and robert_ancell applied the ones from Ampelbein later
[08:54] <seb128> ok, datacenter version updated, the next run in 15 minutes will use the current version
[08:59] <didrocks> seb128: no, I made them before Ampelbein and then, he changed my regexp to object handler
[09:00] <didrocks> seb128: did you create a credential and upload it to the datacenter?
[09:00] <seb128> didrocks: to be honest he did that before you, only he emailed me about the change and I forwarded to robert_ancell the email
[09:00] <didrocks> seb128: oh :/
[09:01] <seb128> didrocks: no I didn't, is that required?
[09:01] <seb128> trying locally
[09:01] <didrocks> seb128: yes, first time you run the script, you create a credential, and then use it. launchpadlib don't allow anonymous access
[09:02] <seb128> didrocks: where is the token stored?
[09:03] <didrocks> seb128: in lpbinding, the file is called ubuntu-desktop-cred
[09:09] <seb128> doh
[09:09] <seb128> ERROR: it seems that python-launchpadlib is not installed
[09:09] <seb128> the datacenter machines are no fun for that
[09:09] <didrocks> :/
[09:10] <didrocks> hopefully, I tried to import launchpadlib in a try/except statement :)
[09:10] <didrocks> well, can make a request ?
[09:10] <didrocks> or they never change the setup of datacenter machines?
[09:11] <huats> morning everyone
[09:11] <huats> hello seb128 and didrocks
[09:11] <didrocks> salut huats
[09:11] <mvo> dapper ftw
[09:13] <seb128> mvo: indeed
[09:15] <pitti> Good morning
[09:15] <seb128> ok, I did roll back to a version not using launchpadlib for now
[09:15] <seb128> hey pitti
[09:15] <pitti> bryce: thanks for the headsup
[09:15] <didrocks> hello pitti
[09:16] <seb128> so the cron job is running
[09:16] <seb128> I'm official taking a swap day today so I don't plan to spend much time on that
[09:16] <pitti> seb128: enjoy!
[09:16] <seb128> the previous version is working and will do the job for now
[09:16]  * pitti starting late today, was plucking strawberries this morning
[09:16] <pitti> mmmm
[09:16] <seb128> I guess we might have to get a launchpadlib copy or something
[09:16] <seb128> pitti: nice ;-)
[09:16] <pitti> meh, empathy requires weird stuff from universe
[09:16] <pitti> The following packages have unmet dependencies:
[09:17] <pitti>   libgstfarsight0.10-0: Depends: libnice0 (>= 0.0.6) but it is not installable
[09:17] <pitti>                         Depends: gstreamer0.10-plugins-bad (>= 0.10.11) but it is not installable
[09:17] <pitti>                         Depends: gstreamer0.10-nice but it is not installable
[09:17] <pitti> this doesn't seem like something that's easy to resolve
[09:17] <pitti> and thus breaks CD builds
[09:17] <didrocks> seb128: ok. I can maybe add some checks to fallback in this mode if launchpadlib is not setup (but we can't have sponsor list as this is a DOM object loaded after the page is retrieved with urlopen())
[09:18] <pitti> kenvandine: ^
[09:19] <seb128> didrocks: should be easy to install launchpadlib to a local path if there is no extra depends no?
[09:20] <seb128> or use parsing in case where it's not available should do too
[09:21] <didrocks> seb128: https://help.launchpad.net/API/launchpadlib#Installation
[09:21] <pitti> didrocks, seb128: we use a local launchpadlib installation in the apport retracers
[09:21] <didrocks> it's just bzr branch lp:launchpadlib if wadllib is installed
[09:21] <pitti> ubuntu-archive@ronne:~$ ls launchpadlib/
[09:21] <pitti> httplib2  launchpadlib  lazr.uri  oauth  simplejson  wadllib
[09:21] <pitti> you need those
[09:22] <seb128> doh
[09:22] <seb128> seems complicated
[09:22] <seb128> we should maybe just do screen parsing for that
[09:22] <pitti> didrocks: hang on
[09:23] <didrocks> seb128: but screen parsing doesn't allow to get subscribed list and so, your can't retrieve sponsor team if subsscribed. Good reason for slackering on sponsoring, yes :p
[09:24] <pitti> didrocks, seb128: you can take the shell snippet from http://bazaar.launchpad.net/%7Eubuntu-core-dev/ubuntu/karmic/apport/ubuntu/annotate/head%3A/debian/local/setup-apport-retracer#L77 to set up launchpadlib locally
[09:24] <didrocks> (seb128: that's the reason why I decided to implement launchpadlib on it)
[09:26] <pitti> eww, rookery is still dapper; that's going to be hard
[09:26] <didrocks> pitti: seems great ;) And then, we just add to sys.path $HOME/launchpadlib in version.py
[09:26] <pitti> didrocks: PYTHONPATH=$HOME/launchpadlib yourscript...
[09:28] <didrocks> pitti: better than adding it to the script with os.syspath(), indeed :)
[09:28] <didrocks> seb128: motivated, even on Friday? ;)
[09:35] <seb128> didrocks: as said today is a swap day for me not a work day ;-)
[09:35] <seb128> I'm fine applying updates though
[09:37]  * mvo pushes seb128 gently away from work
[09:38] <didrocks> seb128: well. I will work on it this week-end (no ssh from my company and bzr without ssh + lp is hard to test something fixed ;))
[09:40] <seb128> mvo: I'm not really working just chatting on IRC when I pass near the computer ;-)
[09:40] <bryce> Amaranth, #20704 on my todo list to look at tomorrow
[09:41] <seb128> mvo: but right, I should be careful to not start doing work ;-)
[09:42] <didrocks> seb128: you really should take some real rest, though :-)
[09:42] <seb128> didrocks: I've slept enough and I don't plan to be near the computer for the whole day don't worry
[09:43] <didrocks> :-)
[09:43] <mvo> seb128: :)
[09:43] <seb128> it's just early in the morning and I'm getting coffee, checking news, etc
[09:44] <mvo> tea!
[09:44] <mvo> scnr
[09:46] <didrocks> mvo: tea addicts can't win, "Coffee has a majority market share" ;)
[09:47] <mvo> haha
[09:47] <mvo> true
[09:51] <huats> mvo: don't worry another tea addict will rejoign the team (me:))
[09:52]  * hyperair likes both tea and coffee
[09:57] <chrisccoulson> i've just ran out of coffee at work :(
[09:57] <chrisccoulson> and i'm in a meeting until 1pm - it's times like that when coffee is required
[10:02] <hyperair> have someone poke you every 5 minutes =p
[10:02] <chrisccoulson> i would still not wake up ;)
[10:02] <crevette> a slap would do the job?
[10:02] <chrisccoulson> i'm asleep pretty much as soon as the caffeine wears off
[10:03] <chrisccoulson> lol
[10:13] <lool> Hmm I'm trying to debug the yelp crash, but no luck with dbgsym and neither with rebuilding yelp and rarian with noopt nostrip
[10:14] <lool> The backtraces lack debug symbols; albeit I can break on static functions
[10:21] <hyperair> chrisccoulson: sounds like you need to lay off the caffeine for a while =p
[10:21] <hyperair> lool: how about dbg symbols for every library yelp has?
[10:22] <lool> You think that'd help?
[10:22] <lool> I don't see any *sos outside libc in the stack trace currently
[10:24] <hyperair> hmm
[10:24] <hyperair> how very strange
[10:26] <lool> ah valgrind gives me line numbers
[10:26] <lool> Cool, it's exactly the place I suspected when reading the source, but couldn't break on it
[10:32] <lool> wee, fixed
[10:35] <lool> hmpf where's the upstream VCS for rarian?
[10:36] <crevette> freedesktop?
[10:36] <lool> Yeah, but didn't find the git
[10:36] <lool> I think it's still using SVN
[11:42] <Ampelbein> didrocks: hi. I don't have another api-documentation but do <object>.lp_attributes and lp_entries on the object to get it's entities. The apidoc is ... strange.
[11:44] <Ampelbein> didrocks: we can simplify the script later when the bug I mentioned in the script gets fixed. (bug #340935) we can then use source = bugtask.target.name
[11:49] <didrocks> Ampelbein: yes, I saw that. I will have a look, thanks :)
[12:35] <rodrigo_> pitti: who reviews the submissions to REVU?
[12:35] <pitti> rodrigo_: any MOTU can, and some will; we can also do it in the desktop team itself (seb128, asac, me) when getting poked appropriately :)
[12:36] <rodrigo_> pitti: it's my first time, so just want to make sure I did it ok before submitting other stuff, so can you please review, when possible, my json-glib-0.7.2 submission?
[12:37] <pitti> rodrigo_: the first two warnings on http://revu.ubuntuwire.com/p/json-glib are real
[12:38] <pitti> but I'll review it and comment
[12:39] <rodrigo_> ugh, yeah, submitted it for jaunty
[12:39]  * rodrigo_ fixes
[12:39] <pitti> rodrigo_: wait with a new upload, there are more things to address
[12:39] <rodrigo_> yeah
[12:39] <rodrigo_> I'll fix it locally
[12:41] <pitti> rodrigo_: oh, hang on, the package is in Debian already
[12:41] <pitti> rodrigo_: we can just sync this
[12:41] <rodrigo_> ah, is it? 0.7.2?
[12:41] <pitti> 0.6.2
[12:41] <rodrigo_> I need 0.7.2
[12:41] <pitti> but it's easier to sync, and then you supply a package update as a bug report
[12:42] <rodrigo_> ah ok
[12:42] <pitti> since if it's in debian, we want to avoid a large delta, whereas when it's a new package, we want to package it nicely
[12:43] <pitti> revu updated
[12:43] <pitti> rodrigo_: if a package is in Debian, don't use revu please
[12:44] <rodrigo_> ah ok
[12:44] <pitti> rodrigo_: or, for that matter, has already been synced to karmic
[12:44] <pitti> json-glib |    0.6.2-3 | karmic/universe | source
[12:44] <rodrigo_> so what do I need to do for a version upgrade?
[12:46] <tkamppeter> pitti, hi
[12:46] <tkamppeter> I have a HAL problem:
[12:46] <tkamppeter> In Karmic one can access the extra functions of HPLIP-driven MF devices only as root.
[12:48] <tkamppeter> I have already adapted /usr/share/hal/fdi/preprobe/10osvendor/20-hplip-devices.fdi by replacing all occurences of "usb" with "usb_device", to match what is in the "lshal" output.
[12:50] <tkamppeter> Now they all get "info.capabilities = scanner".
[12:51] <pitti> tkamppeter: ah, can you please open a bug against udev about this? We don't use hal for device permissions any more in karmic
[12:52] <pitti> tkamppeter: please plug in printer and do "ubuntu-bug udev", to get the necessary debugging informatino
[12:52] <tkamppeter> pitti, this means that info.capabilities = scanner in lshal is worthless? Obsolete?
[12:52] <pitti> tkamppeter: it's still useful for apps which use hal, but it's not used any more to control /dev permissions
[12:52] <rodrigo_> pitti: I file the bug to ubuntu project in LP?
[12:53] <pitti> rodrigo_: against the json-glib package, yes; with a debdif of current version against your update
[12:53] <tkamppeter> So /usr/share/hal/fdi/preprobe/10osvendor/20-hplip-devices.fdi should not be removed as obsolete?
[12:53] <pitti> rodrigo_: with | filterdiff -x '*/debian/*' preferably, to filter out the upstream changes
[12:53] <rodrigo_> pitti: ok
[12:53] <rodrigo_> pitti: ah, ok, I was wondering if the huge diff I got was ok :)
[12:54] <pitti> tkamppeter: not yet; hal will still stay around as long as some applications aren't ported yet
[12:54] <pitti> rodrigo_: we are just interested in the debian/ changes
[12:54] <tkamppeter> pitti, does it mean that scanning as user is currently not possible in Karmic?
[12:54] <pitti> tkamppeter: it should be possible
[12:54] <pitti> /lib/udev/rules.d/40-libsane.rules
[12:54] <rodrigo_> pitti: debdiff json-glib_0.6.2-3.dsc json-glib_0.7.2.dsc | filterdiff -x '*/debian/*' ?
[12:54] <rodrigo_> pitti: that gives me the same huge diff
[12:55] <pitti> tkamppeter: for scanners supported by libsane it will work through this file
[12:55] <pitti> rodrigo_: sorry, '-i', not '-x'
[12:55] <rodrigo_> pitti: ok
[12:55] <pitti> rodrigo_: -i -> include, -x -> exclude
[12:55] <rodrigo_> right :)
[12:56] <rodrigo_> pitti: hmm, that only includes debian/changelog changes
[12:56] <pitti> Riddell: if you didn't change anything else in the packaging, that sounds about right
[12:56] <pitti> sorry, rodrigo_
[12:57] <pitti> asac: https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-karmic-modemmanagers isn't linked to a spec?
[12:57] <pitti> asac: is that an accident, or is the summary meant to be the entire thing?
[12:58] <pitti> asac: ah, whiteboard confirms that, nevermind
[13:03] <tkamppeter> pitti, /lib/udev/rules.d/40-libsane.rules only turns off USB autosuspend
[13:04] <tkamppeter> Anyone here has a scanner which is not an HP MF device?
[13:04] <pitti> tkamppeter: no, all the ENV{libsane_matched}="yes" rules mark scanners with an "I am a scanner" tag
[13:04] <rodrigo_> pitti: isn't the diff.gz file enough for attaching to the bug?
[13:04] <pitti> tkamppeter: o/ (Canon LiDE 30)
[13:04] <pitti> tkamppeter: and /lib/udev/rules.d/70-acl.rules has a rule to manage ACLs for all "libsane_matched" devices
[13:04] <tkamppeter> pitti, does this not only set the variable libsane_matched to yes for this script?
[13:05] <pitti> rodrigo_: would be as well, but debdiffs are easier to review for a sponsor
[13:05] <pitti> tkamppeter: right, and the followup rule (70-acl.rules) checks this variable
[13:05] <pitti> ENV{libsane_matched}=="yes", ENV{ACL_MANAGE}="1"
[13:06] <rodrigo_> pitti: so do I attach the huge diff then? (without the filterdiff)
[13:06] <tkamppeter> pitti, OK. with this I should have the info to add/modify the UDEV rules which come with the HPLIP package.
[13:06] <pitti> rodrigo_: no, with the filterdiff, please
[13:06] <rodrigo_> pitti: but as I said, filtering it only includes the debian/ changes
[13:06] <pitti> tkamppeter: is that a large list of vendor/product IDs, or are there more general properties one could check?
[13:06] <pitti> rodrigo_: right, that's all we need (well, that, and the URL to the new upstream orig.tar.gz)
[13:07] <tkamppeter> pitti, I will see how HP's already existing rules look like.
[13:07] <rodrigo_> pitti: ah, I include the url in the changelog entry?
[13:07] <pitti> rodrigo_: no, not in the changelog, just to the bug report
[13:07] <rodrigo_> ah ok
[13:07] <pitti> rodrigo_: that is, unless you made inline change to the upstream source (we don't do that, we use debian/patches/foo.patch to do changes, it's easier to maintain)
[13:07] <rodrigo_> pitti: no, I didn't
[13:08] <rodrigo_> pitti: so if I need to add patches, debian/patches then?
[13:08] <rodrigo_> include the patches in debian/patches, I mean
[13:08] <pitti> tkamppeter: ideally, hplip's rules would mark these devices with ENV{hplip_scanner}="1" or perhaps ENV{ID_HPLIP}="1" and then we change 70-acl.rules to manage permissions for them
[13:09] <tkamppeter> pitti, there is /lib/udev/rules.d/40-hplip.rules. I only need to add ENV{libsane_matched}="yes" to each entry.
[13:09] <pitti> rodrigo_: right, and then filterdiff -i '*/debian/*' will include them
[13:09] <rodrigo_> pitti: ok, cool, I think I'm set now :)
[13:09] <pitti> tkamppeter: please don't use libsane, since these aren't handled by libsane (I assume?)
[13:09] <pitti> tkamppeter: I can easily add a rule ENV{ID_HPLIP}=="1", ENV{ACL_MANAGE}="1" to udev (I'm upstream committer)
[13:10] <pitti> tkamppeter: it's better to keep the knowledge which device is which type
[13:10] <pitti> tkamppeter: do you think you can get hplip upstream to have these modified udev rules?
[13:10] <pitti> so that it'll work OOTB everywhere?
[13:10] <tkamppeter> Scanning is handled by libsane, but with the HPLIP driver hpaio, but we marked all devices being a scanner as the changed permissions open up all extra functions for normal users.
[13:11] <pitti> tkamppeter: you can show them https://wiki.ubuntu.com/Halsectomy for some references
[13:11] <pitti> aah
[13:11] <pitti> tkamppeter: hplip ships a sane backend then?
[13:11] <tkamppeter> pitti, yes.
[13:11] <pitti> tkamppeter: (btw, please feel free to add hplip to the Halsectomy page)
[13:12] <pitti> tkamppeter: ok, then you are right, and they should just get ENV{libsane_matched}=="yes"
[13:12] <pitti> tkamppeter: sorry, I wasn't aware of that structure
[13:12] <tkamppeter> pitti, please add ENV{ID_HPLIP}=="1", ENV{ACL_MANAGE}="1", as we do it also for devices which have no scanner, for example to check their ink levels.
[13:13] <pitti> tkamppeter: hm, we don't make printers accessible to users right now
[13:14] <pitti> shouldn't they be just in "lp" and accessible to cups?
[13:15] <rodrigo_> pitti: https://bugs.launchpad.net/ubuntu/+source/json-glib/+bug/389461
[13:15] <rodrigo_> pitti: thanks for your help, hope to not have to ask many more questions anymore :)
[13:15] <pitti> rodrigo_: you're welcome, and please do
[13:16] <pitti> rodrigo_: I'd rather you ask questions than to waste hours trying to figure out processes
[13:16] <rodrigo_> yeah, right
[13:16] <pitti> there's lots of documentation we can refer you to, but it's not always obvious where it is
[13:17] <rodrigo_> yeah, it's a bit hard to find docs (or hard for me :) )
[13:17] <rodrigo_> pitti: so for the new packages I'm working on, dput, right?
[13:17] <pitti> rodrigo_: since this will happen more often, can you please read https://wiki.ubuntu.com/SponsorshipProcess ?
[13:17] <rodrigo_> yeah, sure
[13:17] <pitti> rodrigo_: "dput"?
[13:18] <rodrigo_> pitti: I mean, for new packages, I use the dput revu thing, right?
[13:18] <pitti> rodrigo_: right, if they aren't in ubuntu or debian yet
[13:18] <rodrigo_> ok
[13:18] <pitti> rodrigo_: use "rmadison <packagename>" to check
[13:18] <pitti> this will work independently of which distro release you are using
[13:18] <rodrigo_> ok
[13:19] <pitti> rodrigo_: rmadison is in the "devscripts" package
[13:19] <rodrigo_> yeah, have it installed already
[13:19] <pitti> rodrigo_: try "rmadison json-glib"
[13:20] <rodrigo_> ok
[13:21] <tkamppeter> pitti, for ink-level checks and maintenance with HP's tools the printer must be user-accessible.
[13:26] <pitti> tkamppeter: okay
[13:27] <pitti> tkamppeter: they have been in jaunty with hal?
[13:29] <tkamppeter> pitti, yes. All devices were marked as scanners by HAL, so they got opened for the user logged in to the desktop.
[13:29] <kwwii> erm, is there a "downloads" folder in karmic on a default install?
[13:30] <kwwii> https://bugs.edge.launchpad.net/hundredpapercuts/+bug/388570 seems to say there is
[13:30] <pitti> $ grep DOWNLOAD .config/user-dirs.dirs
[13:30] <pitti> XDG_DOWNLOAD_DIR="$HOME/download"
[13:30] <pitti> kwwii: there should be ^
[13:30] <pitti> it's "Downloads" by default, though, I believe
[13:30] <pitti> (I changed it)
[13:34] <chrisccoulson> i thought XDG_DOWNLOAD_DIR was actually ~/Desktop by default?
[13:35] <chrisccoulson> (sorry if I've missed some conversation)
[13:35] <kwwii> yeah, until now we have just put them on the desktop
[13:35] <chrisccoulson> there may be a residual ~/Downloads folder on some installs due to a previous transmission bug which created that folder on first run rather than using XDG_DOWNLOAD_DIR
[13:35] <chrisccoulson> i wasn't aware that the download folder changed though
[13:36] <kwwii> on my jaunty install it is XDG_DOWNLOAD_DIR="$HOME/Desktop"
[13:36] <chrisccoulson> same here
[13:36] <kwwii> but I haven't installed karmic yet
[13:36] <chrisccoulson> i don't think it changed. like i said, the ~/Downloads folder could be there due to an earlier transmission bug
[13:37] <kwwii> yeah, I think you are right
[13:38] <chrisccoulson> kwwii - bug 338046 has some information about that. it was something i noticed due to a separate transmission bug
[13:38] <kwwii> chrisccoulson: sweet, thanks for that
[13:39] <chrisccoulson> no problem
[13:43] <tkamppeter> pitti, so you will add 'ENV{ID_HPLIP}=="1", ENV{ACL_MANAGE}="1"' to /lib/udev//rules.d/70-acl.rules?
[13:43] <pitti> chrisccoulson: ah, possible; I have ~ as my desktop
[13:47] <pitti> tkamppeter: if you change the rules to set ENV{ID_HPLIP}="1", sure
[13:48] <tkamppeter> pitti, I will do so.
[13:48] <tkamppeter> pitti, can you do this in both Debian and Ubuntu?
[13:49] <pitti> tkamppeter: yes, by committing it straight to udev upstream trunk :)
[13:51] <pitti> tkamppeter: done
[13:51] <tkamppeter> pitti, thanks, when will this arrive in Ubuntu then?
[13:51] <pitti> tkamppeter: in a couple of days, I expect; it's not too urgent, I think
[13:52] <pitti> Keybuk: I suppose you'll do a new udev upload soon; will you merge to trunk head, or to the 143 release?
[13:54] <pitti> I just did another commit to fix the keymap documentation after the recently changed install path
[14:02] <tkamppeter> pitti, thanks, running a testy with hand-edited /lib/udev//rules.d/70-acl.rules and modified HPLIP package.
[14:04] <Keybuk> pitti: need to test first
[14:04] <Keybuk> been tracking a crasher bug in upstart most of the morning, but I think I've figured it out now
[14:04] <pitti> Keybuk: sure, it's not urgent; just asking what you usually do (merge from head or from release tag)
[14:04] <tkamppeter> pitti, it works.
[14:05] <Keybuk> pitti: HEAD usually
[14:06] <Keybuk> Kay likes to sneak in major bug fixes right after the release tag ;)
[14:07] <pitti> Keybuk: hm, seems that lp:udev is severely behind :(
[14:07] <Keybuk> yeah, just updating that now
[14:07] <pitti> oh, it's a manual one?
[14:07] <Keybuk> git imports don't work on Kay's tree atm
[14:07] <pitti> OIC
[14:07] <Keybuk> the LP people expressing an opinion about what people can and can't put in revision control again
[14:07] <Keybuk> "but this can't be valid - it has broken symlinks!"
[14:07] <Keybuk> "no, those are part of the test suite ;)"
[14:09] <pitti> why do they care about what's inside the tree?
[14:10] <Keybuk> well, yes, exactly
[14:10] <Keybuk> but since when did LP manage to not dictate policy to its hosting? :p
[14:10] <pitti> these should be black box imports
[14:10] <Keybuk> (manual import running now btw)
[14:11] <Keybuk> lp:udev up to date
[14:12] <Keybuk> lp:~ubuntu-core-dev/udev/ubuntu up to date with it
[14:12] <Keybuk> will just update changelog and rules and stuff
[14:13] <pitti> yay
[14:13] <pitti> Keybuk: please Conflicts:/Replaces: udev-extras (<= 20090618)
[14:14] <pitti> Keybuk: I just updated the standard seed to not have udev-extras any more
[14:14] <Keybuk> what's in udev-extras now?
[14:14] <pitti> nothing
[14:14] <pitti> it's an empty shell
[14:14] <Keybuk> so why <= ?
[14:14] <Keybuk> let's move to #udev ;)
[14:14] <pitti> well, just in case kay decides to add stuff to it again
[14:14] <pitti> sure
[14:16] <Keybuk> I guess we need to merge in udev-extras b-d
[14:16] <pitti> Keybuk: 20090618 was the day when everything was removed from udev-extras trunk
[14:18] <Keybuk> The configure options have changed because another library needs to be
[14:18] <Keybuk> installed in a different location. Instead of exec_prefix and udev_prefix,
[14:18] <Keybuk> libdir, rootlibdir and libexecdir are used. The Details are explained in
[14:18] <Keybuk> the README file.
[14:19] <Keybuk> ww
[15:01] <dobey> pitti: care to review ubuntuone-storage-protocol and ubuntuone-client in REVU? :)
[15:17] <pitti> dobey: on my TODO list now
[15:17] <pitti> dobey: won't happen today any more, though (at least not from me), I have release team meeting and some other stuff still
[15:18] <pitti> but feel free to poke other people as well :)
[15:18] <dobey> pitti: oh ok.
[15:19] <dobey> james_w: ^^ care to review those? :)
[15:24] <jcastro> dobey: he's travelling
[15:24] <dobey> ah
[15:25] <dobey> right
[15:25] <jcastro> and ken is on vacation
[15:25] <dobey> ken isn't a motu yet though is he?
[15:25] <jcastro> oh no, correct
[15:25] <dobey> and seb is on vacation today as well i think
[15:26] <dobey> everyone i know to ping is on vacation or travelling :P
[15:26] <dobey> or in europe and possibly just not around any longer
[15:30] <pitti>  ok, https://blueprints.edge.launchpad.net/~pitti/+specs?role=approver is once again clear
[15:30] <fta> anyone to have a look at some pango crashes in gwibber?
[15:30] <pitti> if you need me to review any specs today still, please speak up now
[15:30] <pitti> since I'll have release team meeting in half an hour, and then I'm off
[15:30] <fta> bug 389505 and bug 380618
[15:31] <fta> jcastro, ^^ do you see that too?
[15:32] <jcastro> looking
[15:33] <fta> for me, it crashes several times a day, it's barely usable
[15:41] <jcastro> fta: mine doesn't crash in that case
[15:41] <jcastro> but it does crash several times a day
[15:41] <fta> jcastro, do you mean you have a 3rd type of crash?
[15:41] <fta> can you get a traceback?
[15:42] <jcastro> no, but I had apport off on this machien for a while
[15:42] <jcastro> next crash I should get something
[15:42] <fta> ok
[15:48] <pitti> ArneGoetje: can you please draft https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-karmic-translations soon?
[15:58] <ArneGoetje> pitti: there is not much to draft... just file bugs and blueprints for Rosetta, everything else has already been taken care of.
[15:59] <pitti> ArneGoetje: ok, please set the status to obsolete then once that happens
[16:01] <ArneGoetje> pitti: ok
[16:11] <pitti> Keybuk: we probably shouldn't spam #udev with packaging questions
[16:11] <pitti> Keybuk: so WDYT about clean: configure
[16:11] <pitti> configure:
[16:11] <pitti>    autoreconf, gtk-doc, rm autom4te, etc.
[16:11] <pitti> ?
[16:11] <Keybuk> doesn't work
[16:11] <Keybuk> you really need all that madness
[16:12] <pitti> sure, but it's always the same 3 or 4 commands
[16:12] <Keybuk> getting configure isn't the hard part though
[16:12] <Keybuk> it's building a source pcakage
[16:13] <pitti> Keybuk: http://bazaar.launchpad.net/%7Eubuntu-core-dev/udev-extras/ubuntu/annotate/head%3A/debian/README.source has some howto for this
[16:13] <pitti> it should by and large apply to udev as well
[16:13] <Keybuk> pitti: that doesn't work though
[16:13] <Keybuk> see above
[16:13] <pitti> except that we don't have an auto-import to merge from
[16:13] <Keybuk> in order to make the .diff.gz properly, you need the .orig.tar.gz
[16:14] <pitti> sure
[16:14] <Keybuk> if Kay has released it, that's easy
[16:14] <Keybuk> just clean-tree and use my bad dpkg-buildpackage command
[16:14] <pitti> Keybuk: but unlike udev-extras, we can actually download that from upstream :)
[16:14] <Keybuk> when Kay hasn't, it's those 8 commands to make one
[16:14]  * Keybuk tends to make a lot of git head builds ;)
[16:14] <pitti> well, but for a git head build, we'd still make that relative to the latest orig.tar.gz and keep the rest of code changes as inline diffs, no?
[16:15] <pitti> To me, the main blocker here is to have a trunk import
[16:15] <Keybuk> no
[16:15] <Keybuk> doesn't work because of the gtk-doc stuff
[16:15] <pitti> the rest can be nicely done with bzr-buildpackage and some debian/rules helpers
[16:15] <Keybuk> that's what I was just trying
[16:15] <Keybuk> because we out-of-tree build
[16:15] <Keybuk> we have to make the gtk-doc stuff first
[16:16] <Keybuk> you can't use bzr-buildpackage on udev sadly
[16:16] <Keybuk> it freaks out over the test/ directory
[16:16] <Keybuk> (which is the same directory LP freaks out over, and bzr bd freaks out ovre)
[16:16] <pitti> well, I'm in the release meeting and just have half a brain for this here, but I still fail to see the difficulty here
[16:16] <pitti> ah
[16:16] <Keybuk> it's always been annoying
[16:16] <Keybuk> it's just more so now ;)
[16:16] <Keybuk> once there's a 143 tarball, it might be easier
[16:17] <Keybuk> I assume the gtk-doc stuff will work
[16:17] <Keybuk> and update itself
[16:40] <pitti> Riddell: so bug 334052 is actually a dupe of bug 339313 then?
[16:40] <pitti> they looked different to me
[16:40] <Riddell> they're probably different bugs
[16:41] <pitti> right, two different upstream bugs as well
[16:41] <Riddell> but it's all part of the "network manager plasmoid broken all over the place" issue
[16:41] <pitti> okay, so this update doesn't actually address #339313 just yet then, but it's a step closer?
[16:42]  * pitti fixes up the bugs to be in proper SRU shape
[16:43] <pitti> apparently this slipped in without any SRU bug processing at all, hmm
[16:48] <pitti> Riddell: feedbck on 334502 is pretty bad, though :(
[16:50] <Riddell> pitti: that bug isn't relevent, wrong number?
[16:50] <Riddell> oh 334052
[16:50] <pitti> Riddell: bug 334052, sorry (see above)
[16:52] <Riddell> pitti: mm, it's not good, but it's not any worse
[16:53] <pitti> right
[16:53] <pitti> Riddell: I'm not opposed to move this to updates to get the fix for bug 330811, but we should keep it open
[16:54] <pitti> Riddell: so, shall I copy it over now?
[16:55] <Riddell> yes, I agree
[17:00] <pitti> done, bugs updated
[17:02] <Riddell> super, thanks
[17:02] <pitti> Riddell: is there an upstream bug for bug 339313? do they know about it?
[17:04] <Riddell> pitti: don't know, I'll get back to you on that
[17:48] <kwah> hi all
[17:48] <kwah> where gnome gets information about locale ?
[17:48] <kwah> upon session start
[17:49] <pitti> kwah: /etc/default/locale (that's system wide, not just gnome)
[17:50] <kwah> pitti, and if particular user chooses different LANG at the GDM screen?
[17:50] <kwah> it does not influence default system locale then
[17:50] <kwah> what changes?
[17:51] <pitti> right, that's per-user
[17:51] <pitti> kwah: it just sets $LANG, I think
[17:51] <kwah> but it might be stored in between of sessions, hence it should be preserved somewhere
[17:52] <pitti> kwah: ah, I guess that goes into ~/.dmrc then
[17:52] <pitti> but I'm not entirely sure on that
[17:52] <pitti> I think it asks you ("just this session" -> $LANG, "all future sessions" -> .dmrc?)
[17:52] <mclasen> .dmrc is correct
[17:52] <kwah> pitti, thanks, will check it
[17:52] <kwah> pitti, mclasen thanks guys
[18:19] <pitti> have a good weekend everyone!
[19:01] <djsiegel1> rickspencer3: can we add "Paper Cuts Round 1: http://tinyurl.com/mhs2qb" to the topic in here?
[19:02] <rickspencer3> djsiegel1: sure, but I'm not an opp