[00:02] <jono> what is the best of getting a list of apps in the archive written in pygtk that use gtkstatusicon?
[00:05] <RAOF> Hm.  I _think_ you'll have to grab the sources of all the packages that depend on python-gtk2 and grep for gtk.StatusIcon.
[00:08] <RAOF> I'd be interested to hear any better solutions, though :)
[00:20] <slangasek> ScottK: yay, removals are my favorite!
[00:21] <johanbr> jono, for packages in debian, you can use http://source.debian.net/source/
[00:21] <jono> thanks johanbr
[00:22] <johanbr> you're welcome :)
[00:31] <tweakt_> should I be able to preseed language, country and keyboard settings?
[00:32] <cjwatson> tweakt_: yes but only using boot parameters
[00:32] <tweakt_> ahh, that explains it
[00:33] <cjwatson> the programs that handle file/url preseeding run after language/country/keyboard have been asked
[00:38] <robert_ancell> jamesh, is there a repository for launchpad-integration? I have a patch for C# support
[00:43] <cjwatson> johanbr: oh my, I hadn't seen that before.  that's fantastic.
[00:44] <johanbr> saw that yesterday on a Fedora mailing list, of all places
[00:44] <cjwatson> this is going to save me a ridiculous amount of bandwidth over time.
[00:44] <johanbr> :)
[00:46] <micahg> robert_ancell: https://edge.launchpad.net/lpx
[00:49] <robert_ancell> micahg, i don't see it there - I'm talking about the package "launchpad-integration" which adds menu items into GTK+ apps help menu
[00:51] <persia> robert_ancell: launchpad-integration is a native package, so lp:ubuntu/lucid/launchpad-integration might be a reasonable thing to branch
[00:51] <persia> robert_ancell: Also, apt-cache show launchpad-integration shows an Original Maintainer who tends to be around, you might also contact that individual.
[00:52] <micahg> robert_ancell: ah, sorry
[00:53]  * micahg missed the -
[00:54] <robert_ancell> persia, yes, as far as I can tell jamesh is the original author and seb128 packaged it.  I'm guessing the answer is no (there is not an official repository) but I can bully him into putting it somewhere oficially. (and getting mvo to link it to lpx - thanks michag)
[00:54] <jamesh> robert_ancell: you should be able to find what you're after here: https://launchpad.net/launchpad-integration
[00:55] <jamesh> I haven't been involved with it much since the first few versions though.
[00:55] <robert_ancell> jamesh, is it stored in version control somewhere?  Could I encourage you to make a lp:launchpad-integration branch :)
[00:55] <robert_ancell> jamesh, ok
[00:55] <jamesh> robert_ancell: lp:~ubuntu-core-dev/launchpad-integration/ubuntu looks like the trunk
[00:56] <jamesh> looks like mvo is the one who'd have permissions to make that branch accessible as lp:launchpad-integration
[00:57] <robert_ancell> jamesh, thanks, that's what I was looking for.  I'll bug mvo to update the LP page
[01:02] <persia> I'm not convinced we want to encourage the practice of enabling lp:foo for native packages where there isn't a distinct upstream.
[01:02] <persia> More likely, it would make sense to integrate that into lp:ubuntu/* and update the tags appropriately.
[01:03] <persia> (unless the content is useful outside the context of the distribution, in which case I question whether it should be a native package).
[01:03] <jamesh> persia: but if people (like robert_ancell) want to make contributions, they'll want to base them on that branch
[01:03] <jamesh> that seems like enough reason to set it as the development focus
[01:04] <persia> (for more thoughts on the matter, read backscroll from about 11 hours ago, talking about ubiq_uity and joc_key
[01:04] <persia> jamesh: Except I think that branch ought to go away for the new model of distributed development.
[01:05] <persia> Because either the software is a separate upstream (in which case it doesn't make sense for ~ubuntu-core-dev to be the trunk branch owner), or it isn't (in which case there's little value to the project external to Ubuntu and that branch only exists as a historical workaround until lp:/ubuntu/* worked)
[01:06] <jamesh> persia: I don't really see what difference it makes though.  If the branch owned by ~ubuntu-core-dev is where the development occurs, then it is the development focus
[01:07] <jamesh> if development occurs elsewhere, then it is not.
[01:07] <jamesh> the development focus might also be the branch where the packaging is managed, but that is separate.
[01:07] <cjwatson> the difference is the same as the difference between a "real" upstream package with independent upstreamish existence, and a native package that exists just for the distribution
[01:07] <persia> Yes, but my argument is that the current branch is a temporary workaround, and it makes sense to fix that rather than setting focus.
[01:08] <persia> The two ways to fix it being 1) set an upstream team and branch or 2) use the DistributedDevelopment branch
[01:08] <cjwatson> which are definitely two different things in distro people's heads - in particular native distro packages aren't particularly expected to be used/usable by other distros
[01:09] <jamesh> if some other distro shows an interest, then it might make sense to separate things out
[01:09] <jamesh> but right now, it seems pretty clear that the ~ubuntu-core-dev branch is the development focus in this specific case
[01:09] <jamesh> that might not always be true, but it is true now.
[01:10] <cjwatson> what persia is I think arguing is that it does not make sense for there to be a project for it at all
[01:10] <persia> Or if there should be a project, the trunk branch should be defined differently and the packaging done differently.
[07:30] <didrocks> good morning
[07:30] <dholbach> good morning
[07:35] <didrocks> superm1: about bug #507121, I've track it down and it's /usr/lib/user-setup/user-setup-apply which screw up custom.conf in both casper and ubiquity phases. So, I'll push a fix today and ping you so that you can remove your workaround
[07:36] <persia> If I want to ask for non-free (unable to modify) data be moved from multiverse to restricted, is that just an MIR, or does it first require a request to the TB?
[10:47] <coz_> hey guys.. out of curiosity...for xplash the frames set are 50  I believe... where do I change that setting?
[10:47] <coz_> also is there a file to change the location of the animated xsplash on the screen?
[10:56] <arand> coz_: afaik, it must be done in the source before compiling, and it's rather untrivial.
[10:56] <coz_> arand,  mm  ok    so  essentially 50 frames   I can deal with that :)
[10:57] <coz_> arand,  thanks
[11:13] <woozy_> coz_: the framerate can be controlled by giving xsplash a parameter on startup, xsplash --help should tell you which one
[11:14] <coz_> woozy_,  ah   that may help quite a bit  thanks :)
[11:22] <dholbach> james_w, kenvandine, sommer, crimsun: can anybody of you please block dav23 from the !ubuntu identi.ca group?
[11:34] <didrocks> cjwatson: if you have any time to sponsor bug #507121 to fix all that session stuff in persistent usb key and after ubiquity install, thanks :)
[11:42] <cjwatson> didrocks: in progress
[11:42] <didrocks> cjwatson: thanks
[11:57] <jussi01> Hey all, are there any ~ubuntu-archive members about atm?
[12:13] <seb128> jussi01, you should ask your question
[12:23] <geser> that reminds me: can an archive admin please check why libxcb in lucid is still 1.4-1 and the both syncs of 1.5 failed in the end? (see bug #492247 and bug #503290)
[12:28] <seb128> geser, looking
[12:28] <seb128> geser, 2010-01-15 12:28:19 ERROR   Exception while processing upload /home/lp_queue/sync-queue/incoming/seb128-20100115-122812 (OOPS-1476FTPMASTER1)
[12:29] <seb128> geser, I'm pinging soyuz guys to know if that's a known bug
[12:47] <cjwatson> didrocks: merged the user-setup one.  For future reference you don't really need ubiquity tasks when it's just a standard rebuild, but I've merged that branch anyway
[12:48] <didrocks> cjwatson: oh, ok. I note it down. Thanks :)
[12:52] <LordMetroid> Alright, I am going to go ahead and break my system
[12:52] <LordMetroid> See you one the other side of alpha2
[12:52] <persia> Could someone press the retry button on https://launchpad.net/ubuntu/+source/metacity/1:2.28.0-2ubuntu2/+build/1430446
[12:53] <cjwatson> persia: done
[12:53] <persia> cjwatson: Thanks.
[14:01] <mdeslaur> slangasek: do you know of anyone who can test a libthai security update?
[14:01] <jdstrand> mdeslaur: actually, ArneGoetje may be able to
[14:01] <mdeslaur> ah! cool, thanks jdstrand
[14:02] <jdstrand> mdeslaur: I'm not sure, but he is our lang guy
[14:03] <mdeslaur> jdstrand: thanks, I'll ask him
[14:03] <mdeslaur> ArneGoetje: ping
[14:03] <persia> Seems odd that we don't have an #ubuntu-th
[14:05] <mdeslaur> persia: we don't? or are you being ironic? :)
[14:06] <persia> mdeslaur: It's not listed as an official channel
[14:06] <persia> But you could ask there, because it's *supposed* to be the Thai channel.
[14:06] <persia> (where official channels are defined at https://help.ubuntu.com/community/InternetRelayChat#Channels , although some might argue that a fairly open wiki is a strange way to define "official")
[14:06] <mdeslaur> persia: oh, ok. thanks.
[14:29] <RainCT> pitti: Hey. Seems like you forgot to push your changes to ubuntu-dev-tools to the branch (and you also skipped the 0.88 release :)).
[14:32] <persia> RainCT: So, based on some discussion about 24 hours ago, there's apparently some procedure that can be done to switch from the current branch to just using lp:ubuntu/${release}/ubuntu-dev-tools .  Do you happen to know who most owns that package?
[14:33] <RainCT> persia: Oh. No, I haven't looked into any of that VCS stuff yet.
[14:35] <apw> pitti, does your new burndown data include the kernel wiki page?
[14:38] <RainCT> persia: It looks like that's handled transparently, though. lp:ubuntu/karmic/ubuntu-dev-tools already exists, and "bzr info" shows lp:~ubuntu-branches/ubuntu/karmic/ubuntu-dev-tools/karmic/
[14:38] <cjwatson> RainCT: that's probably an automatic import rather than the existing branch, though.  I suspect you'll find it isn't nearly so detailed.
[14:39] <cjwatson> RainCT: the procedure for switching the branch references is to file a bug on the 'udd' project.
[14:43] <RainCT> cjwatson: Oh, OK. So it's not ready for mass consumption yet :)
[14:44] <cjwatson> RainCT: I didn't say that?
[14:44] <apw> pitti, does your new burndown data include the kernel wiki page?
[14:44] <cjwatson> RainCT: it's generally fine, but it needs tweaks when people were already using revision control to manage their package
[14:45] <persia> But it has the excellent super-cool feature of automatically dealing with uploads, so we don't have to pester the forgetful uploader to push to the branch.
[14:46] <persia> (or at least that's the impression I have)
[14:46] <RainCT> cjwatson: So you aren't supposed to be able to just pull and push, but need to ask for access to the branch? Or is that just for now (which is what my comment referred to)
[14:46] <persia> RainCT: It's that the real history of the development branch needs to be merged into the import branch.
[14:47] <RainCT> OK. So if I take some other package which was't maintained in bzr before I can push there?
[14:49] <persia> RainCT: https://wiki.ubuntu.com/DistributedDevelopment might be a good primer
[14:50] <RainCT> persia: Yeah, I was trying to avoid reading all that :)
[14:51] <persia> heh :)
[14:51] <persia> But as long as we're managing ubuntu-dev-tools in bzr anyway, it seems reasonable we should use the branches made available in that system.
[14:52] <cjwatson> RainCT: I believe you've misunderstood me somehow.
[14:52] <persia> Then again, I don't know the system well enough to drive that (but I hope I've already completed all my ubuntu-dev-tools changes for lucid)
[14:52] <cjwatson> RainCT: ~ubuntu-branches is magic.  Anyone who can upload the package can edit the branch.
[14:53] <RainCT> cjwatson: So your comment was only about merging in the old history?
[14:53] <cjwatson> RainCT: but, as I said above, if you already have a branch with more detailed history, it would be more appropriate to get the lp:ubuntu/... pointers updated to point to that.
[14:53] <cjwatson> RainCT: my comment was about changing what lp:ubuntu/... points to
[14:53] <RainCT> cjwatson: OK, I see. Thanks for the clarification.
[14:54] <cjwatson> I would not recommend merging the old history into the automatically imported branches in the sense of 'bzr merge' - the result is not likely to be pretty.  It is usually more appropriate to ignore the automatically imported branches if you already have better ones, but it *is* still useful in that case to get lp:ubuntu/... updated.
[14:55] <persia> cjwatson: But if we redirect lp:ubuntu/... will we lose the magic access control and automatic import of uploads?
[14:56] <cjwatson> persia: probably.
[14:56] <cjwatson> I'm not sure about access control.
[14:56] <cjwatson> alternatively you could push --overwrite over the top of the ~ubuntu-branches branch - but ask james_w first, and I'd recommend keeping a copy elsewhere
[14:57] <persia> Hrm.  I think I'll have to learn more about this before promoting it further.
[15:51] <kees> cjwatson: oh, btw, can I help at all with debian bug 562048 ?  it's a workitem for the security team, so I'm hoping you might have time to review it.  Do you want me to s/ReportExtraversion/DebianBanner/ on the proposed patch and resubmit?
[15:52] <cjwatson> kees: more hours in day pls; I'm finishing up a task this week, so ask me at the start of next week?
[15:53] <kees> cjwatson: okay, thanks.  :)
[15:55] <hwilde> hours++
[16:09] <LordMetroid> Breakage of my system complete, I am now in Alpha2, just a restart away(*shudders*)
[16:16] <Incubuss> Can anyone confirm/deny for me that the Interface tab has been removed from Appearance Preferences in gnome?
[16:17] <seb128> Incubuss, it has
[16:19] <Incubuss> any idea why or if the options being reimplemented anywhere else?
[16:19] <seb128> they are gconf keys
[16:20] <seb128> I think they decided that's something useful in the ui
[16:34] <directhex> seb128, so there's now no way to revert the ass-backwards "no icons in menus please" behaviour without gconf-editor?
[16:34] <seb128> no
[16:35] <Incubuss> Ubuntu-tweak makes it possible to get them back but it still took me a good 5 minutes to find the option
[16:46] <Sweb> hi need help with ubuntu
[16:46] <Sweb> any user here?
[16:48] <LordMetroid> Ohh noes, alpha2 can not even start, it totally locks during bootup
[16:48] <LordMetroid> Anyone else have this problem?
[17:52] <slangasek> asac: so, what specs are missing from your report?
[17:53] <slangasek> pitti: could we get some kind of final run of the alpha-2 burndown charts, to verify that all the unfinished workitems have been postponed?
[18:29] <asac> slangasek: so on: http://macaroni.ubuntu.com/~pitti/workitems/canonical-mobile.html
[18:29] <asac> 1st. we have like 30% work item loss over what we had on the old one ..
[18:29] <asac> but i think that was due to the new parser being pickier about the syntax
[18:29] <slangasek> ok
[18:29] <asac> i am going through the itesm now to verify everything is fine
[18:29] <asac> then we have to wait and see if thats good
[18:30] <asac> 2nd. there are specs that dont belong there ;)
[18:30] <asac> desktop-lucid-xorg-halsectomy
[18:30] <asac> foundations-lucid-dropping-sun-java6
[18:30] <asac> 3rd. similarly i suspect that we lost one or two specs ... will check that after doing 1st ;)
[18:30] <slangasek> asac: well, they belong there because the work items are assigne to members of your team
[18:30] <asac> ah ;)
[18:30] <asac> ok
[18:30] <slangasek> that's by design
[18:30] <asac> thats good then
[18:31] <asac> ok. then maybe 3rd is not the case and the loss of items is due to the syntax
[18:31] <asac> lets check how it looks on monday then.
[18:31] <slangasek> ok
[18:32] <asac> and firefox-support spec obviously too ... ok
[18:32] <asac> ;)
[18:32] <slangasek> assign them all to ccheney? :)
[18:33] <asac> i plan to do that next time pitti is about to deliver a all 100% report ... just to nag him :-P
[18:33] <asac> ok enjoy weekend
[18:33] <slangasek> might be more productive if ccheney has more warning that he's responsible for them ;)
[18:33] <slangasek> you too!
[18:49] <Nafallo> kirkland: hey. take a look at bug #505909 when you have a moment.
[18:50] <Nafallo> meh. that wasn't a message. but at least the bot got something to do...
[20:34] <niktaris> hi,  I am remastering the latest version of ubuntu but can't seem to dist-upgrade it. It keeps failing on kernel and rsyslog. Any Ideas ?
[20:36] <niktaris> a yes, by dist-upgrade I mean via chroot
[20:52] <BBHoss> Does anyone remember a bug a while back with tickless kernels? that made the cpu usage go up for things that used timers heavily?
[20:52] <BBHoss> specifically FreeSWITCH
[21:18] <mathiaz> kees: hi - I'm writting a blog post to announce the demotion of nis to universe
[21:18] <mathiaz> kees: what are the main reasons for such a demotion?
[21:18] <mathiaz> jdstrand: insecure? old? unmaintained?
[21:18] <mathiaz> jdstrand: ^^
[21:19] <slangasek> insecure-by-design protocol?
[21:19] <jdstrand> it's both old and a bad design with better alternatives
[21:19] <jdstrand> well, a bad design in the modern age, I guess it was the cat's pajamas back in the day
[21:20] <jdstrand> (always insecure though)
[21:20] <slangasek> I have never known a cat that would wear NIS pajamas
[21:20] <jdstrand> you need an old cat
[21:22] <siretart> slangasek: in combination with kerberos, nis turns out to be pretty useful
[21:22] <slangasek> siretart: no, it's still insecure.
[21:22] <slangasek> unless you mean you've found a kerberos-enabled implementation of NIS itself?  which the one we ship isn't
[21:22] <slangasek> (and then it's pretty much not protocol-compatible)
[21:23] <siretart> no, at my department, we removed password hashes from our nis database and use kerberos for authenticating
[21:23]  * kees agrees with jdstrand and slangasek
[21:24] <slangasek> siretart: that's not secure.  Anyone with access to your network can spoof the maps.
[21:24] <kees> "my uid is 0!"
[21:25] <siretart> slangasek: well, true, we have additional measures in our switches. which we would want even if we would switch to ldap anyway
[21:26] <mathiaz> kees: http://paste.ubuntu.com/357257/ <- does this look ok?
[21:27] <kees> mathiaz: ieee line wrap ;)  reading...
[21:27] <mathiaz> kees: sorry :/
[21:27] <kees> mathiaz: yeah, sounds about right.
[21:27] <mathiaz> kees: great - thanks for the quick review!
[21:28] <kees> np
[21:59] <lamont> I wonder - how long is openclipart supposed to take to build...
[21:59] <lamont> thallium has been working on it for a while
[22:03] <sistpoty> create random set of pixels, check if it looks like a clipart, if not -> begin again :)