[01:15] <tlp> should hald be running (or even installed) on lucid?
[01:17] <persia> tlp: Depends on what else is installed.  pitivi is one of the packages that seems a current common candidate.
[01:20] <tlp> ah
[01:20] <tlp> that would probably be it, then
[05:05] <zgreg> hi.
[05:05] <zgreg> what's the right way to get a package updated in ubuntu?
[05:06] <zgreg> just file a bug about it in launchpad?
[05:07] <lifeless> doing the update yourself is a much more reliable way to make it happen
[05:07] <zgreg> how so? I'm not maintaining the package for debian or ubuntu.
[05:08] <zgreg> I'm the author of the software though and I'd like to have it integrated into lucid if possible as the new version includes important bugfixes
[05:27] <crimsun> zgreg: https://wiki.ubuntu.com/FreezeExceptionProcess#Exceptions for Universe/Multiverse
[05:43] <zgreg> crimsun: thanks
[06:40] <ebroder> Where does the definition of the Vcs-* debian/control fields come from? I know it's not actually in policy...
[07:07] <AnAnt> Hello, is xsplash still used in lucid ?
[07:08] <AnAnt> or plymouth replaces it too ?
[07:13] <RAOF> Is there a way in an apport hook to attempt to escalate to root privileges?
[07:17] <nigelb> RAOF: I believe there is
[07:18] <RAOF> nigelb: You wouldn't happen to know what it is?
[07:18] <RAOF> :)
[07:18] <nigelb> RAOF: gimme a minute.  after a week of hacking, I have the notes somwhere
[07:20] <nigelb> RAOF: root_command_output(command, input=None, stderr=-2)
[07:21] <nigelb> I suggest using *python -c 'import apport.hookutils; help(apport.hookutils)'* when you want to look for some feature.  Helped me a great deal :)
[07:24] <RAOF> nigelb: That's what I've been doing.
[07:24] <RAOF> I must have missed root_command_output, though.
[07:24] <nigelb> and you missed this?
[07:24] <nigelb> haha
[07:25] <lifeless> nigelb: 'pydoc apport.hookutils'
[07:25] <RAOF> In return, I'll tell you that “pydoc apport.hookutils” will do the same thing.
[07:25] <lifeless> RAOF: tsk, slow :P
[07:25] <nigelb> and I would tell you, it isn't updated on wiki
[07:25] <lifeless> nigelb: what wiki
[07:26] <nigelb> the apport developer how to wiki
[07:26] <nigelb> the one that I close to by-hearted when making the rhythmbox hook
[07:26] <lifeless> ah
[07:26] <lifeless> well, its got awkward advice then :)
[07:28] <DaemonFC> Hello everyone. I have a case to make about the version of libvorbis that is currently shipping in Ubuntu and jono suggested I might bring it here. Who would be the best person to discuss this with?
[07:29] <persia> DaemonFC: Better to just ask your questions: those able to do so will answer if they are around.
[07:32] <DaemonFC> Ahh, I filed a bug about it. The case is that libvorbis as provided by upstream (Xiph.org) has not been meaningfully improved save for some minor bug fixes since 2004. Pretty much all the development work on it takes place in a fine-tuned fork known as AoTuv. It's possible to build Ubuntu packages which replace Xiph.org Vorbis with AoTuv vorbis, but I don't think that's optimal and not something most users would do. I also feel
[07:32] <DaemonFC> that since upstream has waffled about merging this patch set for 6 years that maybe Ubuntu should treat Xiph.org as a dead upstream unless and until they merge. The changes involve 3 packages and can be reverted easily if needs be.
[07:33] <DaemonFC> My bug is here https://bugs.launchpad.net/ubuntu/+source/libvorbis/+bug/529807 and has been marked duplicate of one from 4 years ago here; https://bugs.launchpad.net/ubuntu/+source/libvorbis/+bug/57797
[07:33] <DaemonFC> additionally, there's been a PPA that has been tracking AoTuv for a while; https://launchpad.net/~towolf/+archive/codecs
[07:36] <persia> Hrm.  Are there any high-impact outstanding bugs that would be fixed by such a transition?
[07:37] <DaemonFC> Just an across the board quality improvement, AoTuv also integrated some patches from the Vorbis acceleration project that make it ~10% faster at encoding
[07:38] <DaemonFC> It's not going to fix any horrid deficiencies but it will make quality and speed noticeably better at every level
[07:39] <persia> OK.  We're past FeatureFreeze for our next release, so would need to process a freeze exception, etc.
[07:39] <DaemonFC> is that realistic?
[07:40] <persia> Not unless there's a *really* good reason.
[07:40] <DaemonFC> right now I'm overriding the packaged in Lucid by forcing a "downgrade" to the packages in that Karmic PPA and locking the version
[07:40] <persia> I believe Debian Squeeze is not yet frozen, and would suggest attempting to make the transition there.
[07:41] <persia> The following release of Ubuntu would likely adopt it if accepted there.
[07:41] <DaemonFC> is there a way to put it on the table for Ubuntu 10.10 failing that?
[07:42] <DaemonFC> Debian had the same problem (bug filed there in 2007) and same answer as Ubuntu gave in 2006, "Wait for upstream."
[07:42] <persia> Absolutely.  The fancy way to do it is to write up a spec and get it reviewed at UDS.  The less fancy way is to convince some subset of developers to just do it.
[07:43] <AnAnt> Hello, is xsplash still used in lucid ? or is  plymouth  replacing it too ?
[07:43] <DaemonFC> whatever gets it pushed in :)
[07:43] <persia> DaemonFC: Send a note to the Debian bug asking if the issue could be reconsidered after this time has passed.
[07:43] <AnAnt> or, if the answer isn't here, where can I ask ?
[07:48] <DaemonFC> persia, I just sent an email to that debian bug, it's quite old though so I hope there's someone that sees it :P
[07:50] <pitti> Good morning
[07:50] <pitti> ogra_cmpc: I did; I noticed it wasn't automounted, do you mean that? I'm going to debug that soon
[07:50] <persia> DaemonFC: The age of a bug in Debian has little relevance to whether people see updates.  The response should be more interesting.
[07:51] <pitti> ogra_cmpc: other devices are,mmy first suspicion is due to the ebook reader using the raw partition
[07:54] <DaemonFC> persia, It's a shame that it's out of the question for Lucid simply because it's an LTS and even if Monty does merge, the Vorbis is Lucid will be 9 years without improvement by the time it's out of support
[07:54] <DaemonFC> *in
[07:55] <persia> DaemonFC: I didn't say it's out of the question, simply that it's late for such a change, and would need approval.
[07:55] <persia> Had you asked a month ago, the answer would likely have been quite different.
[07:55] <DaemonFC> well, Lucid is getting libtheora 1.1, and I just think that AoTuv going along with that would have made quite the pairing
[07:56] <DaemonFC> especially with stacked up to commercial solutions
[07:56] <persia> Then apply for an exception
[07:56]  * persia is very much not authoritative on these matters
[07:57] <DaemonFC> where do I ask for an exception?
[07:58] <persia> https://wiki.ubuntu.com/FreezeExceptionProcess
[07:58] <persia> Note that there's still a bit of flux happening due to the merging of motu-release into ubuntu-release, but requests shouldn't just get lost.
[08:01] <DaemonFC> persia, I can see why there are so many PPAs, lol
[08:07] <persia> DaemonFC: Personally speaking, I'd rather more people tried to collaborate to make something that works for everyone than just go off and use third-party repositories (which are often mutually incompatible).  There's a large overhead to wide-scale collaboration, but it tends to be less work overall as there is a smaller merge penalty for each change to whatever one derives from.
[08:07] <persia> That's why I suggested working towards fixing it in Debian: that affects the largest number of people, although it does mean that it probably takes the longest time for the changes to become generally available.
[08:08] <DaemonFC> the merge into Xiph.org's Vorbis is probably taking so long because many companies (including Red Hat) are paying Monty a lot to work on Theora
[08:09] <DaemonFC> maybe now that libtheora 1.1 is out, he'll fix this upstream and Ubuntu will have to take it
[08:09] <DaemonFC> that would be nice
[08:10] <DaemonFC> ahhh, here's jono. jono will approve the freeze exception for me ;) hehehe
[08:10] <jono> DaemonFC, heh, unfortunately I am not allowed to do that :)
[08:10] <DaemonFC> of course you are, I have faith in you :)
[08:11] <persia> It's not a matter of faith.  It's a matter of jono being far too busy with other things to be a release manager.
[08:11] <DaemonFC> I was joking with him
[08:16] <slytherin> Anyone from SRU team around? I wish to discuss new pre-release of gst-plugins-ugly-multiverse0.10
[08:40] <zgreg> slytherin: well, all of the new gstreamer (pre)releases are quite interesting
[08:41] <slytherin> oops. My mistake, I am really looking people from ubuntu-release team to discuss FFE.
[08:41] <ebroder> Any core-devs that could look at bug #497606? It's got an ubuntu-sru ACK and just needs sponsorship
[08:42] <DaemonFC> hey, would anyone happen to know why my Alt+F2 isn't working?
[08:42] <zgreg> everything related to multimedia is still seriously lacking in ubuntu
[08:42] <ebroder> (Also, if somebody would accept the nominations for cupsys+hardy, cups+intrepid, and cups+jaunty, and reject the rest of them, I could milestone everything correctly)
[08:42] <persia> DaemonFC: That class of question is better asked in #ubuntu (or #ubuntu+1 if running a development release)
[08:42] <DaemonFC> k, thanks
[08:43] <persia> ebroder: All the nominations appear accepted to me.  I don't know how to reject once already accepted (perhaps you could set status to "Invalid")
[08:43] <ebroder> persia: Hmm...oh - there we go. Looks like Till is looking at it now
[08:44] <ebroder> When I loaded the page a second ago, only Jaunty was accepted
[09:47] <persia> mvo: regarding bug #82436 : is my comment (#14) correct?  Also, do we still need this package in the presence of software-center?
[09:48] <mvo> persia: thanks, indeed. I fix it in the metadata
[09:49] <persia> mvo: Cool, thanks :)
[10:00] <cjwatson> ooh, openssh upstream completely redid its smartcard handling recently such that we'll be able to compile it in by default after the next upstream release
[10:00]  * cjwatson is glad he's been consistently refusing requests for a new binary package, which he now doesn't have to migrate away from ;-)
[10:03] <RAOF> james_w: Can I bzr import-dsc into the sid packaging branch safely?  I'd like t omenge gjs 0.5-1, but it hasn't yet been imported.
[10:06] <pecisk> Hi people, what are Ubuntu dev thoughts about this? https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2010-February/010730.html Upstream agrees that usb-modeswitch is way to go. So maybe it can still be included in main and by default. Of course feature freeze exception is serious thing, but it would be nice to have working out of box mobile broadband modems.
[10:07] <DaemonFC> ikonia, If you want to be thorough now, I'm right here. :)
[10:07] <ikonia> DaemonFC: there is no ban on you here. So no issue
[10:07] <DaemonFC> functionaries. oh well.
[10:08] <james_w> RAOF: you want 0.5-1?
[10:09] <RAOF> james_w: Yes.  And to know whether or not it's safe to go behind the package importer's back.
[10:09] <RAOF> For future reference.
[10:10] <james_w> RAOF: so yes, you can do it
[10:10] <james_w> you can't push to the sid branch though
[10:10] <james_w> but I think if you push to the Ubuntu branch it will re-use what you have done when it notices that the new upload is available
[10:11] <RAOF> Ok.
[10:11] <james_w> and the reason it hasn't done that yet is that launchpad hasn't imported the Debian version yet
[11:12] <cjwatson> directhex: mono should be sorted now
[11:13] <directhex> cjwatson, thanks, i noticed it was gone from the queue
[11:13] <directhex> the kdebindings folks wanted it for actual reasons, i just wanted a ppa build to work...
[11:14] <ogra> seb128, evo starts to eat 80-90% CPU after a while of running, i cant see a bug open for that
[11:15] <ogra> it goes away after i run evolution --force-shutdown (just closing the UI doesnt help) and returns after it ran for 10-20 min
[11:16] <seb128> ogra: I've seen a bug about that and evo didn't change since karmic
[11:16] <seb128> so it's likely something else impacting on it
[11:16] <ogra> well, probably a lib or something
[11:16] <ogra> i didnt see it before the gtk issues appeared but i'm not sure the two are related
[11:17] <ogra> i saw it though even when i rolled back to the non-broken gtk version during the time gtw was broken
[11:17] <ogra> so i dont really think its gtk itself
[11:18] <ogra> s/gtw/gtk/
[11:19] <ogra> beyond that evo is running fine too ... its just that it massively eats CPU
[11:19] <cjwatson> ArneGoetje: ibus-pinyin-db-open-phrase now depends on pinyin-database, which is in universe.  Somebody needs to either file an MIR for it or remove the dependency; could you take care of one or the other?
[11:20] <cjwatson> ArneGoetje: (I haven't looked at the situation at all, I just know that DVD builds are failing as a result)
[11:21] <seb128> ogra: dunno
[11:52] <mark__> I've created a local package which installs a diversion for /etc/ssh/sshd_config. I'm trying to figure out how to reload sshd config *after* the file is changed. right now it reloads right before (from postinst). Any hints?
[11:57] <cjwatson> probably best to just reload ssh ('/etc/init.d/ssh reload' in <=karmic, 'reload ssh' in lucid)
[11:57] <cjwatson> diverting sshd_config is totally ineffective though
[11:57] <cjwatson> it's not installed by dpkg - it's managed by the openssh-server maintainer scripts
[12:15] <mark__> cjwatson: oh. I see. I'll have to take a close look at how that's being set up. I have a reload call in my postinst now. I was assuming /etc/ssh/sshd_config was a conffile.
[12:41] <maja87_> hello
[12:41] <hyperair> hello
[12:43] <maja87_> i want to be an ubuntu developer. how can ibe?
[12:46] <mark__> cjwatson, so it's not 'owned' by openssh-server but it's still known to apt, cause I get a conffile-like prompt. So how do I go about replacing it?
[12:46] <mark__> says "File on system created by you or by a script"
[12:47] <persia> maja87_: https://wiki.ubuntu.com/MOTU/Contributing is getting increasingly out of date, but provides some ideas of how to help.  Also see https://wiki.ubuntu.com/UbuntuDevelopers
[12:47] <cjwatson> mark__: I have no idea how you managed that
[12:48] <cjwatson> mark__: perhaps something to do with your own diverting package
[12:48] <cjwatson> mark__: the openssh package I maintain does nothing that would cause that ...
[12:48] <cjwatson> indeed it's a long-standing bug that it doesn't, sort of
[12:51] <maja87_> cjwatson the bug is only stand in 9.04 and 9.10
[12:52] <maja87_> if i install the system touchpad works good
[12:52] <cjwatson> maja87_: huh?
[12:52] <cjwatson> maja87_: I wasn't talking to you :)
[12:52] <maja87_> but if i disconnect ac charger nothing wrong
[12:52] <mark__> cjwatson, oh, yeah I had a leftover .dpkg-dist sitting there, my bad
[12:52] <maja87_> ok
[12:52] <maja87_> :)
[12:52] <ogra> pitti, did you notice that some plug events arent catched by udisks ?
[12:53] <ogra> i.e. plugging in a SD card on my laptop or my ebook reader doesnt mount them
[12:55] <pitti> ogra: as I said earlier, I get the effect with raw devices such as my ebook reaer
[12:55] <pitti> ogra: I'll have a look at this
[12:55] <pitti> ogra: if you wish, feel free to "ubuntu-bug storage", for some log comparison and tracking
[12:55] <ogra> pitti, oh, funny, after i used udisks --mount once with that SD it gets automounted now
[12:56] <ogra> oops, sorry, didnt see you replied to my weekend ping
[13:36] <pecisk> anyone have run into problems with nouveau and LiveCD Alpha 3? CD spews lot of reading errors and in the end doesn't work correctly (launching Firefox crashed desktop). CD-RW is allright, I burned it with several other distros and they worked fine.
[13:36] <pecisk> it happened on two computers
[13:40] <persia> pecisk: I'll suggest you ask on #ubuntu+1
[13:56] <apw> we have a number of keyboard quirks in karmic which say "n 2.6.32, a /sys interface is provided to handle setting from userspace." ... so we have the userspace support for these?
[13:57] <smb> (quirks being to generate missing key release events)
[13:59] <didrocks> cjwatson: hey, we need a 5 line bin to create a wallpaper cache for GNOME as ubiquity doesn't use g-s-d for drawing the background in install mode. The bin is called in casper and we agreed with pitti and seb128 that the bin should be there too. The drawback is that it will make casper depends on glib and libgnome-desktop. Just want to check that it's ok with you too before doing the change :)
[14:03] <cjwatson> didrocks: casper itself can't have those dependencies - it can use them if they're available, but it can't actually depend on them.  it's used by more than just Ubuntu images
[14:03] <didrocks> seb128: pitti: idea where we can put it so? ^
[14:04] <didrocks> cjwatson: thanks
[14:04] <cjwatson> didrocks: I think it would be more appropriate to put the binary in ubiquity-frontend-gtk
[14:04] <cjwatson> perhaps?
[14:04] <cjwatson> actually it would be better if we could find some other place - I don't want ubiquity-frontend-gtk to be architecture: any
[14:04] <seb128> didrocks, ok, just upload in gsd
[14:04] <smb> slangasek, pitti, To be specific, do you know whether user-space modifies /sys/devices/platform/i8042/serio0/force_release
[14:04] <seb128> we wasted too much time for that already I think
[14:04] <seb128> I don't like but that's minor, let's do it this way
[14:05] <cjwatson> didrocks: I don't understand why casper is involved here
[14:05] <cjwatson> didrocks: casper isn't responsible for ubiquity's install-only mode?
[14:05] <didrocks> seb128: if you are ok on it. In any case, it's now in debian/….c and build is in debian/rules, so, not an added patch
[14:05] <cjwatson> didrocks: shouldn't it be called in ubiquity-dm or something?
[14:05] <didrocks> cjwatson: casper has an ubiquity-hooks which will call that binary
[14:05] <cjwatson> didrocks: uh, that's after installation ...?
[14:06] <didrocks> cjwatson: right, to push something to the $HOME/.cache/wallpaper
[14:06] <cjwatson> didrocks: why not just put it in ubiquity/scripts/install.py?  putting it in casper's ubiquity-hooks seems an artificial separation, given that it isn't something that casper is otherwise involved in
[14:06] <cjwatson> didrocks: the point of casper's ubiquity-hooks is specifically to reproduce things that are done by casper at live CD boot time, and need to be repeated after installation
[14:07] <cjwatson> it isn't meant to be a grab-bag of post-install scripts
[14:08] <didrocks> cjwatson: there is already some hooks like that like accessibility, etc. ev told me to put the first version there (which works in live mode)
[14:08] <cjwatson> didrocks: accessibility is there because casper does accessibility stuff at boot time
[14:08] <cjwatson> didrocks: I don't think things should go in casper's ubiquity-hooks unless they're also done at boot time in casper
[14:09] <cjwatson> otherwise the result is that we end up with code spread around between casper and ubiquity when it doesn't need to be
[14:09] <cjwatson> you could install a ubiquity-hooks file in gnome-desktop if you want, but it might be better to just have it in ubiquity
[14:09] <didrocks> cjwatson: ok, so, I should convert 35copy_wallpaper_cache to python to some code in install.py?
[14:10] <cjwatson> I think so
[14:11] <didrocks> cjwatson: the script will do "bad thing" that we refused to do on upgrade but on install as it's in a controlled environment, we decided it's ok. Not sure you want that in ubiquity itself I can pastebin it: http://paste.ubuntu.com/386311/
[14:13] <cjwatson> I think that would be OK in ubiquity itself
[14:13] <cjwatson> but I also think it would be OK in a hook in gnome-desktop
[14:13] <cjwatson> up to you really
[14:14] <didrocks> cjwatson: I can try to convert it to ubiquity itself and propose you for a review
[14:14] <cjwatson> you might think that using hooks is in general more elegant; or you might not want to carry the code in gnome-desktop :)
[14:14] <cjwatson> it might be easier all round to use a hook
[14:14] <cjwatson> that way, you only have to change one package, and it's all self-contained
[14:15] <didrocks> cjwatson: I think it'll be more logical to have the call into ubiquity TBH
[14:17] <pitti> smb: yes, that's a new helper in udev, part of the keymaps
[14:17] <pitti> smb: any particular question about that one?
[14:18] <pitti> slangasek: ^ FYI
[14:18] <cjwatson> didrocks: I'm easy either way
[14:18] <smb> pitti, Just wondered whether we have that support (as some kernel drivers have quirks for that as well)
[14:18] <smb> apw, ^
[14:19] <didrocks> cjwatson: thanks, I'll try to have some time to propose you a merge for that later
[14:19] <apw> smb, pitti thanks, so sounds like we don't need the kernel quirks any more, thanks
[14:19] <pitti> apw, smb: udev grew that support in lucid
[14:20] <pitti> apw: beware that we just have two quirks in udev so far; if hte kernel has more, we need to convert them to udev rules instead of just dropping them
[14:20] <apw> pitti, where are they so i can confirm
[14:21] <apw> pitti, and presumably bugs against the quirk package when they are missing?
[14:21] <pitti> apw: /lib/udev/rules.d/95-keyboard-force-release.rules maps machines to tables
[14:21] <pitti> and the tables themselves are in /lib/udev/keymaps/force-release/
[14:21] <pitti> apw: "quirk package" == udev
[14:21] <apw> pitti, thanks
[14:22] <pitti> apw: if you have some, it would be nice if you could assign them to me right away
[14:22] <smb> pitti, apw Likely atm, we just need to make sure we have no dups and future changes go to there instead of a kernel driver
[14:22] <apw> i have three i was just looking at whether they need to come over to lucid, looks like two are already in
[14:22] <pitti> if you do that work, I can commit the new quirks upstream right away
[14:22] <apw> ack
[14:23] <pitti> (I guess you want to get the removal from the kernel upstream as well)
[14:23] <apw> they never made it upstream in the kernel
[14:23] <pitti> oh, so much the better
[14:24] <pitti> wrt. reducing delta, I mean
[14:24] <seb128> cjwatson, the enchant version uploaded should fix the ubiquity crash, I cleaned some bugs there too
[14:24] <seb128> cjwatson, let me know if you still get one of those after tomorrow's iso update
[14:24] <apw> pitti, its a much much better game all round ...
[14:24] <seb128> cjwatson, I'm pretty sure that was it but in case there is still some other issue
[14:33] <cjwatson> seb128: great, thanks a lot
[14:35] <seb128> cjwatson, np
[14:39] <jdstrand> cjwatson: hi! I noticed when you adjusted libvirt to build against parted 2.1, it ftbfs on all architectures. are you looking at this?
[14:39] <cjwatson> jdstrand: yes
[14:39] <cjwatson> I need to make a change in Debian experimental and merge it across
[14:39] <jdstrand> ok, excellent
[14:40] <jdstrand> cjwatson: thanks :)
[14:40] <jdstrand> kirkland: fyi ^
[14:40] <cjwatson> likewise pyparted
[14:40] <cjwatson> (change in Debian> in parted, I mean)
[14:40] <kirkland> jdstrand: thanks
[14:40] <jdstrand> cjwatson: re change in Debian> in parted-- gotcha (that is what I figured)
[14:42] <cjwatson> I think it only affects packages that build against parted *and make use of libparted.la*8
[14:42] <cjwatson> s/8$//
[14:42] <mpt> mvo, tremolux: https://bugs.launchpad.net/ubuntu/+source/software-center/+bug/426999
[14:46] <apw> pitti, this dell quirk is for the volume keys, in the kernle they renamed it simply volume as it was used a lot, one of the missing ones also wants the same three keys ... would it be reasonable to rename that to like basic-volume as well?
[14:47] <pitti> apw: "renamed it" -> what is "it" in particular?
[14:47] <pitti> apw: certainly not the linux/input.h constants?
[14:48] <ebroder> Any core-devs around that could sponsor bug #497606? It's already got an ack from ubuntu-sru
[14:48] <apw> pitti, you have a quirk in udev called dell-studio-1557 which quirks a0, ae and b0.  in the kernel they renamed that list to a generic name 'volume' or similar as it is a common set of keys to be bust ... one of the new quirks is for the same three keys
[14:49] <apw> pitti, so i either need to make a new file with the same three keys, or share it, in sharing a generic name may be appropriate ... just wondering
[14:50] <apw> which you though was more approprate here
[14:54] <pitti> apw: oh, you can address sets of keys by name? I didn't know that
[14:54] <apw> pitti, no ... i am just talking about the files in udev
[14:54] <apw> there are perhaps 5 machiens which have the same three binary numbered keys, all for mute/volume up/voume down with the same fault
[14:54] <apw> (according to the kernel)
[14:55] <apw> i am adding a second one which needs the same file as the dell
[14:55] <pitti> apw: ah, ok; I'm fine with that file being renamed to dell-volume
[14:55] <apw> you already added.  and it seems silly to not share the file
[14:55] <apw> its actually not just dell
[14:55] <pitti> and referenced by multiple udev matches (or generalizing the existing one)
[14:55] <pitti> apw: but the particular scan codes are probably dell specific?
[14:55] <apw> i was thinking generic-volume-mute or common-v-m
[14:56] <pitti> apw: in general, if the map files are the same, I either change the file name to include another model number or, if there are too many, just drop the model and make it a generic file name
[14:56] <apw> i assume they are bios specific or something as the same codes on the dell affect amilo as well
[14:56] <apw> hrmm
[14:57] <apw> i'll pull in the amilo for now and it can evolve over time
[14:58] <mpt> mvo, tremolux: https://bugs.launchpad.net/ubuntu/+source/software-center/+bug/524379
[14:59] <ArneGoetje> cjwatson: I will take a look
[15:00] <cjwatson> ArneGoetje: thanks
[15:01] <tremolux> mpt, mvo: https://bugs.edge.launchpad.net/ubuntu/+source/software-center/+bug/528043
[15:01] <tremolux> mpt, mvo: https://bugs.edge.launchpad.net/ubuntu/+source/software-center/+bug/528057
[15:03] <apw> Keybuk, is this the right stacking branch being picked here:
[15:03] <apw> Using default stacking branch /~scott/udev/master at lp-64605456:///~apw/udev
[15:04] <apw> when pushing a new udev branch ?
[15:04] <Keybuk> apw: sodomy non sapiens
[15:05] <Keybuk> that branch is where I import the GIT HEAD into
[15:05]  * apw suspects that is a new
[15:05] <Keybuk> lp:ubuntu/udev is based off that
[15:05] <apw> no
[15:05] <jdstrand> apw: fyi, I installed that kernel with the backported drm fro .33 and will be testing it extensively
[15:05] <apw> ... ahh, well its pushing one hell of a heap of stuff as a result... i guess i'll blame LP
[15:05] <Keybuk> sorry lp:~ubuntu-core-dev/udev/ubuntu
[15:05] <Keybuk> yeah
[15:05] <apw> 8MB so far and counting, for two 2 line changes :(
[15:06] <apw> jdstrand, sounds good ...
[15:08] <Keybuk> apw: it's a kinda pointless message really
[15:08] <apw> i thought it was meant to chose a base which it could steal the packs from ... seems not
[15:08] <apw> 16MB ... and couting
[15:08] <cjwatson> it chooses a base, it's just not necessarily the closest one
[15:09] <cjwatson> indeed it's sometimes possible for there to be no common history at all :( I think it just uses the "development focus"
[15:09] <apw> seems that it chose that today
[15:10] <cjwatson> for branches in the distribution namespace rather than the product namespace, it'll use lp:ubuntu/<package>, I believe
[15:11] <Keybuk> cjwatson: that still has the whole chicken/egg problem
[15:12] <Keybuk> though that's weird
[15:12] <Keybuk> lp:ubuntu/udev looks like lp:~ubuntu-core-dev/udev/ubuntu
[15:12] <Keybuk> I've never pushed it there :
[15:12] <Keybuk> :p
[15:14] <jdstrand> apw: well, that was quick. compiz crashed (see report), but differently. Only thing in dmesg related to the crash is:
[15:14] <jdstrand> [ 738.880732] [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation
[15:15] <jdstrand> apw: do you need more info? an apport-collect or is this enough?
[15:16]  * apw has no idea.  the more infor the merrier
[15:23] <apw> pitti, as requested i have filed a bug for each quirk, they are assigned to you, i've linked a branch with possible patches for them both
[15:23] <pitti> apw: cheers!
[15:59] <lucas> james_w: hi, is there a way to make your life better for the next round of ruby syncs? or should I continue with 1 bug per sync? (yes, there's another round coming :( )
[15:59] <james_w> lucas: you don't have to file a bug per-sync for transitions
[15:59] <james_w> lucas: you can provide instructions directly if they won't require in-depth checking
[16:00] <james_w> (one bug with a list of packages is actually the worst way to provide it, so please no-one do that :-)
[16:00] <lucas> what do you mean by instructions, then?
[16:00] <james_w> one line per source package
[16:01] <james_w> -S <suite> [-f] <source package name>
[16:01] <james_w> where suite is testing/unstable/experimental
[16:01] <james_w> and -f is to overwrite Ubuntu changes
[16:01] <lucas> ok, thanks
[16:01] <james_w> and source package name is... well you can probably figure that one out
[16:01] <lucas> I think so
[16:01] <james_w> hand that list to an archive admin and they can fire them all through for you
[16:02] <james_w> please only use it for transitions though, it doesn't scale if everyone does this for every sync :-)
[16:02] <lucas> sure
[16:03] <Riddell> mvo: rgreening is testing upgrade but getting " The package 'update-manager-kde' is marked for removal but it is in the removal blacklist" errors, we don't use update-manager-kde in lucid, where's this blacklist?
[16:09] <hyperair> any ubuntu-release people around?
[16:13] <mvo> Riddell: should it go away? I can fix that, its currently shying away from removing anything that starts with update-manager
[16:14] <Riddell> mvo: yes it gets replaced by kubuntu-notification-helper and kpackagekit distro notification in lucid
[16:15] <mvo> Riddell: ok
[16:16] <superm1> mvo, re bug 529740, i'm a bit confused.  what's the most appropriate section for the themes metapackage to prevent this problem?
[16:16] <Riddell> hyperair: what do you need a release person for?
[16:16] <mvo> Riddell: commited to bzr, should I remove update-manager-kde from the u-m source too?
[16:16] <hyperair> Riddell: i'd like to discuss about banshee, banshee-community-extensions and taglib-sharp.
[16:17] <mvo> superm1: well, the way we use metapackage is that anything directly under metapackage will not get marked as auto-installed. this has the nice effect that removing ubuntu-desktop does not remove half your system. now for the themese that is probably not what we want, so I would suggest to put it into a different section
[16:17] <rgreening> ty Riddell, mvo
[16:18] <superm1> mvo, ah i see. Ok.
[16:18] <Riddell> mvo: where is it in u-m source?
[16:18] <Riddell> hyperair: doesn't sound like my area I'm afraid
[16:18] <hyperair> Riddell: oh well.
[16:19] <hyperair> Riddell: who handles the GNOME freeze exception?
[16:19] <mvo> Riddell: thre is debian/control update-manager-kde
[16:19] <mvo> Riddell: if that should go away, just let me know and I remove it
[16:20] <Riddell> mvo: oh yes.  I'm pretty sure we still need those, they get called by packagekit to do the tests
[16:21] <Riddell> hyperair: #ubuntu-desktop probably best for Gnome packages issues
[16:21] <hyperair> thanks
[16:21] <mvo> Riddell: eh, if those are still needed, then u-m should also keep it in the the removal blacklist, no?
[16:22] <Riddell> mvo: it's update-notifier-kde we want to go, update-manager-kde keep
[16:23] <Riddell> mvo: hum wait, this is confusing
[16:23] <mvo> Riddell: I'm confused too
[16:28] <Riddell> mvo: I need to look into this properly and get back to you
[16:28] <Riddell> not today I'm afraid
[16:35] <mvo> Riddell: sure, just let me know
[17:09] <ArneGoetje> cjwatson: I will check with LiDaobing tomorrow if we really need pinyin-database as a Depends or if it should rather be a Build-Depends
[17:10] <cjwatson> cool.  if it's a build-depends it will still need to live in main, though.
[17:14] <ArneGoetje> cjwatson: it is definetely needed to build ibus-pinyin-db-open-phrase... since pinyin-database is really just a sql database file, which gets packed into a tarball, what is to check there for the MIR?
[17:15] <cjwatson> you're allowed to write an MIR bug that indicates that it's trivial.  the thing is that you cannot expect archive admins to do that check for all of the dozens of packages currently awaiting promotion to main - somebody needs to actively request it and keep on top of it
[17:15] <cjwatson> https://wiki.ubuntu.com/MainInclusionProcess
[17:15] <ArneGoetje> cjwatson: okay
[17:30] <ArneGoetje> cjwatson: done. Bug #530178
[17:31] <mpt> tremolux, I've triaged both bug 528043 and bug 528057
[17:31] <cjwatson> ArneGoetje: thanks
[17:32] <tremolux> mpt: thanks!  looking...
[17:35] <cyphermox> is there a specific reason why ifupdown is still at version 0.6.8
[17:35] <cyphermox> ah, I should rephrase that
[17:38] <cyphermox> is there a specific reason why ifupdown is still at version 0.6.8 (admittedly, -0ubuntu29), while 0.6.9 is now available? would there be a benefit or an issue with merging that to match what's currently in debian testing (since last September)?
[17:39] <tremolux> mpt: so, the issue for bug 528043 is that we are currently filtering the "Provided by Ubuntu" list to show applications only, rather than all 30K+ available packages
[17:39] <mpt> tremolux, so I see
[17:41] <tremolux> mpt: originally, I had them all in there, but that long list was pretty painfully unusable and, iirc, mvo added the filter for apps only
[17:43] <mpt> mvo, is it easy to produce a list of applications that have .desktop files using the categories "2DGraphics", "VectorGraphics", "RasterGraphics", "3DGraphics", "Scanning", "OCR", "Photography", "Viewer"? (For bonus points, is there an easy way to advise someone other than you on how to generate that list, so it doesn't take up your time?:-)
[17:43] <mpt> mvo, because whether they're currently being used influences whether we should expose them in the 2.0 categorization (that I'm finishing right now)
[17:45] <mpt> tremolux, my "Deleted Messages" folder has 121634 messages in it and scrolls fine. :-) Any idea why that 32000 is painfully unusable?
[17:46] <mpt> tremolux, is it just because of the resizing of the selected row?
[17:46] <tremolux> mpt: I think it's due to the fixed-height bug
[17:47] <tremolux> mpt: p.s.  you should clear out your "Deleted Messages" folder  ;)
[17:47] <mpt> Other people call it "Archive"
[17:47] <tremolux> mpt: haha
[17:48] <mpt> tremolux, so maybe someone (mvo? bratsche?) could give bug 524567 some love first
[17:49] <mpt> tremolux, but it's pretty fundamental to the mental model here that the parent item (e.g. "Get Software") == the union of the child items.
[17:49] <tremolux> mpt: agreed
[17:51] <mpt> tremolux, and this is something we'll need to solve anyway because I'm about to nuke (specificationally-speaking) the subcategories of "System Packages"
[17:51] <tremolux> mpt: ah
[17:52] <tremolux> mpt: yeah, we need to solve this anyway, it causes lots of problems
[17:53] <tremolux> mpt: we should let mvo weigh in, he's spent a fair amount of time on this
[18:01] <mpt> mvo, in the absence of debtags, what's the best way to tell which packages are fonts?
[18:02] <mpt> Package name starts with "ttf-" or "otf-"?
[18:02] <mpt> ArneGoetje, ^^
[18:02] <didrocks> cjwatson: when you have some time, if you can review lp:~didrocks/ubiquity/copy_wallpaper_cache, thanks :)
[18:14] <mvo> mpt: re categories> I can write you a tool for that tomorrow (need to leave in a bit) - could you mail me the exact requirements please?
[18:15] <mvo> mpt: re speed> what are you using? evo? thunderbird?
[18:16] <mvo> mpt: re speed 2> we have some code in the fastapp branch, but its a lot of code in order to work around the gtktreeview performance problems
[18:16] <mpt> mvo, thunderbird, so, not the same implementation :-)
[18:16] <mvo> mpt: I spend a bit of time on gtk thing, we need to solve it for final one way or the other, but its not trivial (either via fastapp workaround or gtk patching)
[18:17] <mpt> mvo, thanks, I'll mail you
[18:17] <mvo> mpt: my preference is to fix it upstream, but that requires some effort (ond, two days, unless bratsche does it, then ~4h ;)
[18:18] <mvo> s/ond/one/
[18:18] <mvo> so yeah, its on the list, but its painful
[18:18] <mvo> mpt: mail> thanks, I will reply in the morning first thing
[18:18] <mpt> mvo, UI freeze doesn't affect that bug unless we're really uncertain we'll be able to fix it at all, I guess
[18:19] <mvo> right
[18:28] <jdstrand> ccheney: hey, do you have a minute to discuss webkit in #ubuntu-meeting right now?
[18:28] <jdstrand> ccheney: we have a few questions
[18:29] <jdstrand> ccheney: if not, we can schedule for another time
[18:35] <ccheney> jdstrand: ok
[18:39] <kirkland> pitti: i have another eucalyptus (*-7.6) uploaded to karmic-proposed ... could you accept at your convenience?
[18:44] <LaserJock> hmm quilt 3.0 source packages don't work in Karmic PPAs?
[18:44] <soreau> In the output of 'dpkg -l' ii means installed. What does rc mean?
[18:44] <elmo> soreau: there's a legend at the top of the dpkg -l output
[18:44] <elmo> LaserJock: apparently dpkg in karmic doesn't work 100% with them
[18:45] <LaserJock> elmo: darn, that does make backports a pain
[18:45] <geser> LaserJock: v3 source packages are only accepted for lucid and lucid PPAs
[18:46] <soreau> elmo: This is all I see http://pastebin.com/pn7kU3y8
[18:47] <LaserJock> geser: you know of any doc on how to "un-v3" a source package?
[18:47] <soreau> Not seeing a legend, and the man page doesn't reveal anything interesting
[18:48] <geser> LaserJock: no (I haven't worked much with v3 packages). but if you don't use any fancy features from v3 it might be enough to remove debian/source/format (that's what I've heard)
[18:48] <elmo> soreau: r == Desired == Remove
[18:49] <elmo> soreau c == Status == Cfg-files
[18:49] <LaserJock> geser: that's the only thing mentioned in the changelog for it so maybe that'd be enough
[18:49] <elmo> soreau: it is a legend, just quite a dense one
[18:50] <soreau> elmo: I would hardly call that a valid legend
[18:51] <soreau> I do not see how one could reasonably assume that another could deduce what 'rc' means from that
[18:51] <elmo> soreau: err, ok, dude, whatever.  I was just trying to help you
[18:52] <elmo> clearly, my bad
[18:52] <soreau> elmo: I still want to know what rc means though :P
[18:52] <cjwatson> it means that the package has been removed but configuration files remain
[18:53] <soreau> Ahh
[18:53] <soreau> Thanks cjwatson
[19:00] <soreau> elmo: Thanks for your help too man
[19:41] <zul> slangasek: ping have you had a chance to look at the php ffe?
[20:05] <pitti> slangasek, Keybuk: is it correct that upstart jobs don't do anything like sourcing /etc/environment, /etc/default/locale, etc.?
[20:15] <pitti> ah, apparently it is, looking at gdm.conf
[20:17] <slangasek> zul: granted now, sorry for the delay
[20:18] <slangasek> pitti: upstart jobs *can* do this, but Keybuk doesn't like it when you do (he says sourcing files is too slow :)
[20:18] <zul> slangasek: thanks
[20:24] <pitti> slangasek: we can also soure /etc/default/locale in /etc/gdm/failsafeXServer, so that's fine
[20:24] <pitti> slangasek: I just wanted to know why translations were broken
[20:24] <pitti> slangasek: thanks
[20:28] <siretart> I'd like to contact the technical board, but would prefer to use a non archived mailing list. is there a better adress than technical-board@l.u.c?
[20:29] <maco2> superm1: have you had a look at the price for the Dell Mini 10n when you click "Shop For Ubuntu" on dell.com/ubuntu ?
[20:30] <maco2> (it's $100,278)
[20:31] <jdong> maco2: it's the *designer* edition :)
[20:31] <ScottK> maco2: Nice.
[20:31] <maco2> jdong: oh and here i was thinking it was a typo!
[20:32] <jdong> maco2: no no, it's a symbol of social elitism to be able to afford that one!
[20:32] <LaserJock> I thought maybe it was the "donate to Hati relief" model
[20:32] <jdong> forget that M5 I was saving up for...
[20:32] <tkamppeter> pitti, hi
[20:54] <superm1> maco2, haha, looks like quite a typo.  i'll forward that to the website folks.  at least when you click configure it comes up right
[20:55] <maco2> superm1: thanks
[21:08] <jcole> is the java viewer enabled in remote desktop (vino)
[21:09] <jcole> im searching all over gconf and cant figure out how to enable http access
[21:11] <kees> NCommander: do you have access to a running mips system?  I'm trying to debug a build failure in Debian, but all the mips porters are down.
[21:11] <NCommander> kees: mips or mipsel?
[21:11] <NCommander> I can probably get the former if you can tolerate 166Mhz/32 MiB :-)
[21:11] <kees> NCommander: either, mipsel preferred
[21:11] <kees> I don't mind :)
[21:11] <NCommander> kees: mipsel is easy. 800Mhz, 512MiB :-)
[21:12] <NCommander> kees: I need to reinstall that box though, and there may be instabilities; what package?
[21:12] <jcole> we use hp virtual rooms (rooms.hp.com) for windows and mac users right now, but it would be nicer to use ubuntu's built in to use remote desktop
[21:12] <kees> NCommander: I'm trying to figure out why "readelf -r" fails.  https://buildd.debian.org/fetch.cgi?pkg=hardening-wrapper;ver=1.24;arch=mipsel;stamp=1267403604  "There are no relocations in this file."
[21:12] <jcole> bleh
[21:13] <NCommander> kees: I'll jot reinstalling that box on my TODO list
[21:14] <kees> NCommander: okay, cool.  don't burn a lot of time on it.  )
[21:14] <kees> :)
[21:35] <DnaX> pitti: https://bugs.launchpad.net/ubuntu/+source/udisks/+bug/526524
[21:36] <DnaX> pitti: https://edge.launchpad.net/~dnax88/+archive/ppa/+sourcepub/982085/+listing-archive-extra
[21:39] <kirkland> nixternal: howdy, around?
[21:39] <kirkland> nixternal: can you reproduce https://bugs.edge.launchpad.net/ubuntu/+source/qemu-kvm/+bug/500218 on the latest Lucid kvm?
[21:42] <nixternal> kirkland: it is now fixed
[21:42] <nixternal> ie. I can't reproduce that now...I thought I closed it out a few weeks back
[21:43] <kirkland> nixternal: \o/
[21:43] <nixternal> and what fixed it, I have no clue...I do not remember updating anything that broke it or fixed it :)
[21:43] <kirkland> nixternal: cool, would you close it?
[21:43] <kirkland> nixternal: ;-)
[21:43] <nixternal> roger that
[21:43] <kirkland> nixternal: rock on with your bad self
[21:43] <nixternal> haha, quit stealing my lines :)
[21:44] <nixternal> done
[21:45] <blueyed> bug 530295 - am I missing something?
[21:46] <blueyed> (except the debug symbols ;)
[21:49] <Caesar> lucas: yt?
[21:51] <lucas> Caesar: yt?
[21:52] <Caesar> lucas: yeah
[21:52] <Caesar> How are you?
[21:52] <Caesar> lucas: I'm trying to help out Nigel with https://bugs.launchpad.net/ubuntu/+source/ruby1.8/+bug/520715 because he's busy
[21:53] <Caesar> Basically what he was trying to say was that he's not seeing that timeout code work as intended
[21:53] <Caesar> The thread is not getting killed, aiui
[21:54] <lucas> Caesar: a test case could be great, because I can't reproduce it
[21:54] <Caesar> lucas: that would be coment #13
[21:54] <Caesar> comment even
[21:54] <Caesar> https://bugs.launchpad.net/ubuntu/+source/ruby1.8/+bug/520715/comments/13
[21:55] <lucas> Caesar: yes, but as I wrote, the timeout class is a pure-ruby class. so it should be very easy to reduce the testcase further
[21:56] <lucas> to something not involving the Timeout module/class
[21:56] <Caesar> Have you tried to reproduce it on Ubuntu or only Debian?
[21:58] <lucas> Debian, and an ubuntu chroot. but I admit I've not tried very hard in the chroot.
[21:58] <Caesar> ok
[22:01] <cjwatson> siretart: you'll have to mail the members individually
[22:05] <lucas> Caesar: gah. I can see it now.
[22:06] <lucas> which is good. now I can blame Ubuntu :->
[22:13] <Caesar> lucas: :-)
[22:14] <lucas> Caesar: it's clearly not reproducible on Debian. Switch to Debian? :-)
[22:14] <Caesar> lucas: heh
[22:15] <TheMuso> 8/c
[22:15] <Caesar> So I have this sneaking suspicion it might be a glibc issue
[22:15] <lucas> me too
[22:15] <Caesar> I saw something else (can't remember what) that was crashing in libpthread
[22:16] <Caesar> lucas: so are you going to update the bug with what you've seen/found/not found?
[22:16] <lucas> Caesar: no, I first want to try with experimental's libc
[22:16] <Caesar> ok
[22:16] <Caesar> It might be a 2.11 thing
[22:18] <lucas> ok; crashes with libc 2.11.0 from debian experimental
[22:19] <Caesar> \o/
[22:26] <Caesar> slangasek: why does Lucid have a newer glibc than is in Debian's testing?
[22:27] <kees> NCommander: no worries about the mips system; I've got qemu working locally now.
[22:28] <persia> Caesar: There are a few sets of packages that are typically newer in Ubuntu.  These include X, GNOME, KDE, gcc, glibc, python, etc.
[22:30] <Caesar> persia: I know, there was just a general air of conservatism about Lucid since it was an LTS
[22:30] <bryceh> Caesar, not really
[22:30] <Caesar> bryceh: orly, so why is it syncing from testing and not unstable then?
[22:31] <lucas> persia: that's not true for X, gcc and python
[22:31] <bryceh> Caesar, the S in LTS stands for 'support' not 'stable' - the idea is to have versions of things that can be supported for a long period
[22:31] <Caesar> heh
[22:31] <bryceh> sometimes newer bits are going to be more suitable to support for a longer period
[22:31] <Caesar> I am so going to put that on a t-shirt
[22:31] <slangasek> Caesar: syncing generally applies to all those packages that aren't actively attended by anyone in Ubuntu; packages that have maintainers in Ubuntu are certainly more likely to be out of sync.  I don't know specifically why eglibc is out of sync
[22:32] <Caesar> slangasek: FYI, it sounds like bug #520715 is a glibc bug
[22:32] <slangasek> ah, well then
[22:32] <Caesar> Just so you know
[22:32] <Caesar> And that's impacting on Puppet
[22:32] <Caesar> yadda yadda yadda
[22:33] <persia> There's lots of bugs :)
[22:33] <slangasek> Caesar: reassign it to the eglibc package, subscribe doko to it?
[22:33] <lucas> I'm not 100% sure it's a glibc bug.
[22:33] <Caesar> lucas: you want to update it with your most recent findings first?
[22:33] <slangasek> lucas: try to reproduce in Debian pulling eglibc from experimental?
[22:33] <Caesar> slangasek: he did
[22:34] <Caesar> and he succeeded
[22:34] <slangasek> ah
[22:34] <lucas> ruby1.8 is known to sometimes make assumptions about pthread. it was a problem on hppa before the NPTL switch.
[22:34] <Caesar> Hence my "it sounds like a glibc bug"
[22:36] <lucas> anyway, we need someone with glibc knowledge to look at this, so it's probably better to reassign
[22:36] <Caesar> Okay
[22:36] <Caesar> I will do that then
[22:36] <lucas> (I've subscribed directly)
[22:37] <Caesar> Thanks lucas, slangasek
[22:38] <Caesar> I'll try to remember what else I saw failing in libphtread
[23:28] <Keybuk> slangasek: no, Keybuk doesn't like it because there should be one place to configure jobs (the /etc/init conf file - I'm quite happy with the env FOO=bar stuff at the top)
[23:28] <slangasek> well, ok
[23:29] <slangasek> in the case of /etc/default/locale, this would be contrary to the intent of that file
[23:31] <cjwatson> if somebody moves the canonical location of system locale configuration again, I may go postal