[00:06] <broder> TheMuso: ping? i was looking at python-virtkey for the dh_python2 jam, and slangasek noticed that the there's a lp:python-virtkey branch owned by ~onboard. there are recent commits to it, but it doesn't reflect the last two archive uploads, so we were wondering if you had any idea what's up
[00:14] <slangasek> TheMuso, broder: looking closely at the branch history, it doesn't appear that lp:python-virtkey quite matches what's been uploaded even before the two latest uploads; so I'm going to drop the Vcs-Bzr field since it doesn't appear to be accurate
[00:34] <TheMuso> Sounds reasonable.
[03:45] <aldeka> Hi all!
[03:45] <aldeka> So, I have a dumb question.
[03:46] <aldeka> Roughly how many people contribute to Ubuntu? Hundreds? Thousands?
[03:46] <aldeka> (I guess meaning people who wrote a patch, or who were otherwise significantly active, in the past year)
[03:48] <sladen> aldeka: hard question to answer.  There are many more people who contribute to Ubuntu than write patches!
[03:48] <aldeka> That is true.
[03:49] <sladen> aldeka: it's a bit like the "how long is a piece of string" question
[03:50] <aldeka> Heh.
[03:52] <sladen> aldeka: For example, there are 1350+ people who've have subscribed to and install the PPAs to beta test early versions of the ubuntu Font Family
[03:53] <sladen> aldeka: and taking the time to beta-test fonts is a pretty niche activity
[03:53] <aldeka> Wow.
[03:53] <aldeka> re: # of font-testers
[03:54] <sladen> aldeka: https://launchpad.net/~ubuntu-typeface-interest/+members
[04:25] <NCommander> @pilot off
[04:25] <udevbot> (pilot (in|out)) -- Set yourself an in or out of patch pilot.
[04:25] <NCommander> @pilot out
[07:18] <pitti> Good morning
[07:23] <ion> that
[07:42] <didrocks> good morning
[07:53] <dholbach> good morning
[08:30] <tkamppeter> pitti, hi
[08:30] <pitti> hey tkamppeter
[08:31] <tkamppeter> pitti, it is about bug 801306, a user is only able to use AirPrint when he adds "ServerAlias *" to cupsd.conf. What should we do?
[08:31] <pitti> slangasek: is it ok for you if I upload the multiarch cups in 4 days (when the current version went to testing)? if you need it earlier, I can do an ubuntu specific upload
[08:31] <slangasek> pitti: there's no hurry
[08:32] <pitti> tkamppeter: <hostname.local> is the standard FQDN for zeroconf networks
[08:33] <pitti> tkamppeter: but '*' seems a bit excessive for that -- cups should listen to all local hostnames in /etc/hosts (all names for 127.0.*.*) and for <hostname.local>
[08:33] <pitti> this seems to be a more sensible internal default
[08:57] <pitti> slangasek: for the pam upload, do you want to wait until I have the shadow upload ready with the updated login.defs documentation?
[08:58] <slangasek> pitti: I don't think you need to wait
[08:58] <pitti> I'll fix that today anyway, just want to know whether you are waiting for something else, or want me to upload
[08:59] <tkamppeter> pitti, so we should patch CUPS to add "<hostname>.local" to their internal defaults?
[09:00] <pitti> tkamppeter: I think so, yes
[09:00] <pitti> tkamppeter: I wonder why it doesn't do that already -- after all, the .local stuff is way more popular in the apple world
[09:01] <tkamppeter> pitti, so this can even be a bug in CUPS and not a missing feature.
[09:02] <pitti> tkamppeter: yes, I think so; it's certainly upstreamable
[09:02] <pitti> tkamppeter: well, it might be an omission in our avahi patch
[09:04] <slangasek> pitti: you can upload; otherwise I'll do so after merging the latest Debian upload
[09:05] <pitti> slangasek: ok, then I'll upload it together with shadow, so that we have this in a2
[09:05] <tkamppeter> pitti, the error message originates from scheduler/client.c
[09:05] <pitti> slangasek: I sent an updated patch to the BTS as well (although I guess that's just you with a different hat as well :) )
[09:05] <slangasek> pitti: same hat, just wearing it backwards ;)
[09:06] <pitti> clever!
[09:09] <tkamppeter> pitti, it is a bug in our patch, scheduler/client.c has "#ifdef HAVE_DNSSD" sections, these need also be compiled if Avahi is present.
[09:13] <AnAnt> Daviey: ping (reminding you of swt-gtk)
[09:13] <tkamppeter> pitti, other possible DNS-SD bugs are in cgi-bin/admin.c, scheduler/ipp.c, as these files also contain "#ifdef HAVE_DNSSD" but are not modified by cups-avahi.dpatch.
[09:28] <Daviey> AnAnt: ok, thanks
[09:39] <Daviey> AnAnt: hmm.. the debdiff doesn't seem to cleanly apply?
[09:39] <AnAnt> huh
[09:39] <AnAnt> let me check
[09:42] <Daviey> AnAnt: for example, in the Debian version you are a Uploader: , but not in the debdiff?
[09:42] <Daviey> AnAnt: i can fix it up, but i'm interested what happend?
[09:48] <AnAnt> dunno
[09:49] <AnAnt> Daviey: while I prepare a fixed debdiff, any comments on the dropped change I mentioned ?
[09:52] <AnAnt> Daviey: done
[09:57] <Daviey> AnAnt: it looks good to me, visually
[10:27] <AnAnt> Daviey: ok, please sponsor then :)
[10:56] <tumbleweed> didrocks: we upload ubuntu-dev-tools to Debian where possible
[10:58] <didrocks> tumbleweed: oh sorry, didn't notice that, do you want to sponsor it and then we make a dummy sync?
[10:58] <didrocks> will know for the future : )
[10:59] <tumbleweed> sure, can do. did you upload yet?
[10:59] <didrocks> tumbleweed: I just did, let me check again
[11:02] <didrocks> tumbleweed: should be in the next round, right. If we don't upload ubuntu-dev-tools only for ubuntu, we should really rename the package name :)
[11:03] <tumbleweed> didrocks: heh, we're trying to get most of the non-ubuntu-dev-specific scripts rehomed elsewhere
[11:03] <didrocks> tumbleweed: I've just seen more than 4 weeks of pending changes, hence the upload, if you want, just upload 0.126 in Debian and I'll sync
[11:04] <tumbleweed> I'll see if I can get some of the pending merges landed first
[11:04] <tumbleweed> bdrung: any objection to merging broder's fix-785854 branch?
[11:18] <cjwatson> lamont: should we migrate bug 797555 into RT in order to get some of your work time on it?
[11:19] <ogra> cjwatson, just fyi (and since i have the first images today since the change) manifest files work fine on preinstalled images now
[11:20] <cjwatson> oh good
[11:24] <dholbach> pitti, do you have an idea why community-o-new-ubuntudev-outreach does not show up on status.u.c?
[11:25]  * ogra would like to see his team on status.u.c actually :)
[11:25] <pitti> dholbach: no work items defined -- you need a "work items:" header :)
[11:26] <dholbach> gah, I'm stupid
[11:26] <dholbach> thanks pitti
[11:26] <pitti> dholbach: also, note that the [dholbach] tags are redundant -- you are already the default WI assignee as you are the BP assignee
[11:26] <pitti> they don't hurt, of course, just make typing harder
[11:26]  * pitti hugs dholbach
[11:26] <dholbach> ah ok, good to know
[11:26] <dholbach> thanks pitti!
[11:28] <ogra> pitti, are you maintining access for teams to that ? i would like to see ubuntu-armel on there
[11:31] <pitti> ogra: you mean like http://status.ubuntu.com/ubuntu-oneiric/ubuntu-armel.html ?
[11:32] <pitti> ubuntu-armel has been in the reports for ages, I think
[11:32] <ogra> err
[11:32] <ogra> it hasnt been there a week ago or so
[11:32] <pitti> ogra: but anyway, the config is writable by platform, lp:~wi-tracker-configurators/launchpad-work-items-tracker/ubuntu-config
[11:32] <pitti> hm, perhaps
[11:33] <ogra> oh, its the wi tracker code it uses as backend
[11:33] <ogra> then i'm fine
[11:33] <pitti> ogra: http://people.canonical.com/~platform/workitems/oneiric/ubuntu-armel.html has data since at least May 26 (UDS)
[11:33] <ogra> yeah
[11:33] <pitti> so the config was there before; perhaps status.u.c. didn't because of a recently fixed bug?
[11:33] <ogra> it just wasnt on status.u.c and i didnt know they are the same
[11:33] <pitti> they are separate instances really
[11:34] <pitti> people.u.c. is the old one, but keeps running until status.u.c has been fully announced and the quirks shaken out
[11:34] <ogra> yeah
[11:34] <ogra> ok, then i'm fine, sorry for the noise
[11:35] <pitti> no problem :)
[11:58] <tkamppeter> pitti, the fix for CUPS (new cups-avahi.dpatch) is on its way ...
[12:02] <pitti> tkamppeter: cheers!
[12:16] <lamont> cjwatson: RT gets core-hours time applied to it, launchpad bugs are after-hours things, so yeah, RT will get it more attention, esp since it's written up so more than just me can do it
[12:18] <tkamppeter> pitti, slangasek, current Debian BZR is FTBFSing, it does not pass the built-in regression tests. So I will test my changes on an SRU for Natty and add it to Oneiric as soon as the code stabilizes/the multiarch addition is finished.
[12:22] <Daviey> Laney: around?
[12:22] <Laney> yep
[12:23] <Daviey> Laney: are you able to ack jamespages membership to ~ubuntu-server-dev please?
[12:23] <Daviey> https://launchpad.net/~ubuntu-server-dev
[12:23] <Daviey> (he was in approved in the most recent meeting)
[12:24] <Laney> sure
[12:24] <Daviey> Laney: thanks \o/
[12:25] <Laney> beep boop blop
[12:25] <Laney> there we go
[12:25] <Laney> jamespage: enjoy
[12:26] <jamespage> Laney: thankyou!
[12:26] <Daviey> super!
[12:28] <Laney> lucas: hey, I just got around to crunching the ubuntu -changes archives into a format similar to the one you use for debian-devel-changes... http://master.debian.org/~laney/ubuntu-changes-split/ — would it be easy for you to set up a table in UDD for these?
[12:28] <Laney> I also changed http://master.debian.org/~laney/munge_ddc.py to work with them
[12:29] <Laney> "To: warty-changes@rince.africaninspace.com" heh heh
[12:32] <Daviey> Laney: where did you get the original archives from?
[12:32] <Laney> -changes mboxes on lists.u.c
[12:32] <Daviey> oh interesting.
[12:32] <Daviey> I thought the dead releases were no longer there.
[12:33] <elmo> they're just not advertised, they're still there, we try not to remove stuff unnecessarily
[12:33] <Daviey> elmo: rocking
[12:33] <Laney> just filed an RT ticket to have them rsyncable so that I can be more server friendly
[12:34] <Laney> currently I have to dowload the whole mbox again when there's an upload
[12:34] <Daviey> Laney: you don't want to know how i recently parsed them. :)
[12:34] <Laney> using one of the many great Free mbox parsing libraries?
[12:34]  * Laney coughs
[12:35] <Daviey> no comment
[12:38] <lucas> Laney: quite
[12:38] <lucas> Laney: I'll add it to my TODO, but will try to get to do it this afternoon
[12:38] <Laney> thanks
[12:38] <Laney> I shall set up a daily cron to update them
[12:38] <Laney> it'll have Launchpad-Bugs-Fixed (IIRC) as well as Closes
[12:39] <lucas> ok
[12:53] <tkamppeter> pitti, tested AirPrint fix on Natty and pushed it to Debian BZR repo.
[13:08] <cjwatson> lamont: ah, now that I look, I see that jamespage already did.  RT#46381
[13:08] <lamont> cool
[13:09] <lamont> ISTR a few more that may or may not have migrated yet
[13:09] <lamont> my plate is currently plenty-full until july 7 or so, fwiw
[13:23] <ScottK> lamont: Slightly unconveniently we got our first real "Hey, please make multi-instance work" bug today.
[13:26] <lamont> ScottK: on the bright side, I have a plane ride coming up real soon where I'll be able to make some time to work on that
[13:26] <lamont> may even stuff that in on sunday
[13:26] <ScottK> Nice.
[13:26] <lamont> not just because, well, using it myself
[13:27] <ScottK> lamont: That's handy as I've got a project that's currently on BSD that may move to Ubuntu and it would be very convenient for me not to have to figure it out.
[13:28] <lamont> ScottK: you have my permission to pester me relentlessly on multi-instance
[13:33] <ScottK> Excellent.
[13:38] <zul> @pilot in
[14:16] <pitti> zul: happy flying
[14:16] <zul> pitti: thanks
[14:23] <apw> pitti, had any reports of the burn-down reports being shy some tasks?
[14:24] <apw> pitti, i am seeing only 1 TODO on alpha2 for our ubuntu-delta-review on your tables, but my matrix shows 5 todos in the same combinations
[14:31] <tkamppeter> pitti, I have now uploaded the SRU for Natty for the AirPrint fix (bug #801306).
[14:49] <pitti> tkamppeter: thanks
[14:49] <pitti> apw: hey
[14:49] <apw> pitti, hey
[14:49] <pitti> I didn't have reports, let me look
[14:51] <pitti> hm, indeed
[14:52] <apw> pitti, i presume the db is ok as my report has them in
[14:53] <pitti> it looks like it leaves out the WIs from the people who aren't in ~canonical-kernel-team?
[14:53] <pitti> ah, no
[14:53] <pitti> manjo is in the team
[14:54] <pitti> apw: ooh
[14:54] <james_w> do the workitems have the same description?
[14:54] <pitti> apw: the work items have the same name
[14:54] <pitti> james_w: snap :)
[14:55] <pitti> apw: right, it seems it assigns one and the same WI to different people, and the report identifies them
[14:55] <james_w> they are counted in the burndown, but not shown in the table
[14:55] <pitti> probably the last one wins, or whatever the DB order is
[14:55] <apw> pitti, yes ... but we changed that ages ago to allow it
[14:55] <apw> as its clearly something one might want to do, i specifically remember fixing it
[14:56] <james_w> well it's broken again :-)
[14:56] <james_w> https://bugs.launchpad.net/launchpad-work-items-tracker/+bug/795681
[14:56] <james_w> same cause I think
[14:56] <apw> james yeah sounds likely
[14:57] <pitti> apw: but in this case they are on the same milestone
[14:57] <pitti> so we probably need to include the assignee into the primary key?
[14:58] <james_w> It may be enough to just remove the DISTINCT around description in the queries
[14:58] <pitti> hm, the WI table doesn't even have a PK
[14:58] <james_w> there's nothing that stops you from creating identical workitems, but I'm not sure it's the tracker's job to enforce that
[15:00] <apw> james_w, whats confusing is when we had this same situation in natty ... i went through and took them all out cause it caused exactly this problem
[15:00] <apw> its not obvious why we want to squash them ever
[15:00] <apw> (all out, all the DISTINCTs out)
[15:07] <james_w> apw, http://bazaar.launchpad.net/~work-items-tracker-hackers/launchpad-work-items-tracker/trunk/revision/239
[15:07] <james_w> so I don't think you took them all out
[15:07] <james_w> you fixed it for the graph by the look of it
[15:17] <apw> james_w, very odd we didn't notice till now ... fair enought ... will try and look at it next week
[15:50] <bdrung> didrocks: you uploaded u-d-t to oneiric and that adds work to me.
[15:51] <bdrung> didrocks: we were waiting for distro-info to get accepted in debian
[15:51] <didrocks> bdrung: tumbleweed already mentionned it to me, I never noticed that a package with ubuntu in the name was synced from debian. I added some fixes and seeing no release for more than 4 weeks, I decided to upload. Sorry for that
[15:51] <didrocks> bdrung: tumbleweed told me he would upload on debian and then I'll sync back
[16:43] <slangasek> seb128: components-mismatches picked up a weird build-dependency tree, gtkmm2.4 -> gtkmm-documentation -> gtkmm3.0; do you know whether we should be migrating to gtkmm3.0 for main, or if we need to cut out the dependency?
[16:44] <pitti> it's mainly just gnome-system-monitor and parted which use these
[16:44] <jdstrand> zul: ok, libvirt 0.9.2-4ubuntu1 uploaded. while it build fine on amd64, hallyn's 9023-disable-test-poll.patch was dropped. if builds fail, you might want to grab it from 0.9.1-1ubuntu4, adjusting it for 0.9.2
[16:45] <pitti> slangasek, seb128: cjwatson already started porting gparted to 3.0, and if/when that happens, I think we could just drop g-s-monitor from the default install
[16:45] <tkamppeter> pitti, hi
[16:45] <pitti> hey tkamppeter
[16:45] <slangasek> pitti: +inkscape :)
[16:48] <pitti> slangasek: that's not on the CD, though
[16:48] <pitti> slangasek: at some point it ought to be ported as well, of course, but the pressure is lower there
[16:50] <slangasek> pitti: right, well I was asking about component status, and inkscape is in main at leat
[16:50] <slangasek> least
[16:50] <pitti> from that POV I think it should be in main; it's similar to gtk-3, a new upstream version of the C++ bindings, but new package names as we need for for some time
[16:51] <slangasek> ok
[16:51] <slangasek> does it need an MIR?
[16:51] <pitti> we usually handled new upstream versions with changed names without one
[16:51] <pitti> mterry, didrocks, doko ^ ok with you, or do you want an MIR?
[16:52] <didrocks> sounds that more paperwork isn't needed IMHO
[16:52] <mterry> pitti, yeah, that's fine
[16:52] <pitti> I promote it ithen
[16:52] <hallyn> jdstrand: thanks!
[16:53] <pitti> bah @ typing -- TGIF
[16:53] <didrocks> pitti: becoming a mac addict? ;)
[16:53]  * pitti pats his Android mobille
[16:53] <didrocks> :)
[16:53] <pitti> didrocks: hardly -- after installing my mother's iPod touch I loved android five times more :)
[16:54] <didrocks> pitti: heh, never touched those things. Still happy with my android phone :) but ithen -> izen? maybe a new concept coming? :)
[16:55] <slangasek> pitti: right, but we usually don't give carte blanche to having more than one upstream version in main at the same time - but if you're all happy, that's fine :)
[16:56] <pitti> slangasek: necessary wart, I guess; the bindings themselves are by and large zero maintenance anyway
[16:56] <pitti> it's gtk2 and 3 themselves which double work
[16:57] <slangasek> sure
[17:36] <broder> pitti: re bug 565047, i am still using maverick in a couple of places where i saw hardware support regressions in natty, so i would like to get the fix into both m and n. i can do the verification legwork
[17:39] <Jarvis> hmm, have a curious issue regarding direct access to keyboard events. It seems certain applications want direct access to /dev/input/event* (namely java apps)
[17:39] <Jarvis> i'm wondering whether to bug rep it or not
[17:40] <Jarvis> can anyone think of a reason not to give world read access to /dev/input/event*
[17:40] <broder> because i don't want every unprivileged user to be able to see my keystrokes?
[17:41] <Jarvis> somones suggested possibly dropping it into its own group and giving access to that
[17:41] <Jarvis> i've no clue why java (lwgl it seems inparticular) wants read access like that, but hey
[17:42] <Jarvis> fair point broder
[17:42] <Jarvis> i might try and find out why its directly accessing it in the first place
[17:43] <Jarvis> as it shouldn't be
[18:07] <jaberwokey> Should questions about the C appindicator api be asked here, or in #ubuntu-app-devel?
[18:14] <ScottK> jaberwokey: I would guess the latter or #ayatana.
[18:17] <jaberwokey> k, thanks
[18:22] <seb128> re
[18:23] <seb128> slangasek, pitti: yeah, just promote it
[18:23] <seb128> the goal would be to use gtk3 if we can this cycle
[18:28] <Ampelbein> hi there, has something changed in oneiric regarding --no-copy-dt-needed-entries (--no-add-needed)? 'gcc -Wall -Wl,--no-as-needed,--no-copy-dt-needed-entries test.c -o test -lslang' works (with test.c being http://paste.ubuntu.com/631913/). shouldn't that give an undefined reference error?
[20:10] <doko> infinity: ping
[20:15] <Ampelbein> doko: maybe you can tell if something is changed in oneiric: 'gcc -Wall -Wl,--no-as-needed,--no-copy-dt-needed-entries test.c -o test -lslang' should IMHO give a undefined reference error, test.c is http://paste.ubuntu.com/631913/. Am I thinking wrongly?
[20:29] <infinity> doko: 'sup?
[20:31] <infinity> doko: You know better than the fire off contentless pings. ;)
[20:31] <infinity> doko: s/than the/than to/
[20:31] <pitti> broder: okay then
[20:49] <broder> pitti: thanks
[22:07] <ScottK> infinity: Apparently not.
[23:07] <mannic> hi
[23:07] <mannic> there is someone who can help me on building the last unity trunk in 11.04?