[00:38] <cjwatson> pitti: one of your changes to media-player-info looks wrong
[00:38] <cjwatson> +ATTRS{idVendor}=="22b8" , ATTRS{idProduct}=="41d9|41db" , ENV{ID_MEDIA_PLAYER}="motorola-droid" ENV{UDISKS_PRESENTATION_ICON_NAME}="phone-motorola-droid"
[00:38] <cjwatson> pitti: missing comma-separation there?
[00:39] <cjwatson> pitti: actually, uh, there seems to be lots of this.  Is the udev documentation wrong about what it accepts?
[00:56] <Keybuk_> huzzah!
[01:30] <smoser> cjwatson, that rocks. thanks. i have never seen that syntax for case
[01:55] <psusi> ev, just subscribed you to bug #644011 since I believe it was caused by your upload the other day
[04:10] <YokoZar> I can't figure out which package this bug should be against: https://bugs.launchpad.net/ubuntu/+source/gnome-screensaver/+bug/632827
[04:16] <micahg> YokoZar: could xscreensaver be installed or is that too far-fetched
[04:17] <YokoZar> micahg: if it is it was pulled in by default somehow
[04:17] <YokoZar> micahg: and it's not installed
[04:17] <micahg> ah, your bug :)
[04:38] <smoser> if I upload bug 644074 (ec2-api-tools package in multiverse) does it stand a chance at getting approved ?
[04:45] <persia> lifeless, SpamapS : You might want to catch mjj re: Java library versioning; I believe there's a plan to have a soname-like facility in Debian in the future.
[04:50] <lifeless> persia: \o/
[04:51] <persia> Might be a while, like Wheezy+1 or so, but if there's interest in doing that, probably better to work with folks already looking at it for a few months, rather than a parallel solution.
[07:40] <Mixmax> cjwatson: Good morning! Do you wish to be apart of the massive growth of Open Source software and ill have to ask you to keep an open mind.
[07:42] <Hobbsee> Mixmax: if you wish to troll, please go elsewhere
[07:43] <Hobbsee> where elsewhere does not include any other ubuntu channels, incidently
[07:50] <lifeless> Hobbsee: welcome back to peak condition
[07:51] <Hobbsee> lifeless: cheers
[07:51] <lifeless> Hobbsee: did you get your good news?
[07:51] <lifeless> whatever it was?
[07:52] <Hobbsee> i don't remember which particular bit it was :)
[07:53] <lifeless> @facebook
[07:53] <Hobbsee> oh
[07:53] <Hobbsee> mostly
[07:53] <Hobbsee> parts of it, anyway :)
[07:53] <lifeless> \o/
[07:59] <Mixmax> ... /msg ananke Hows your frying going cock smoker ?
[07:59] <micahg> Hobbsee: ^^
[07:59] <Mixmax> Hobbit.. act and be one
[07:59] <Hobbsee> !staff
[08:00] <micahg> Hobbsee: you're no longer IRC admin?
[08:00] <Hobbsee> micahg: i was never a staffer
[08:00] <micahg> Hobbsee: oh, my mistake :)
[08:00] <Hobbsee> micahg: no problem
[08:01] <Mixmax> micahg: If you had liked linux or open source at all yould have booted ananke.
[08:02] <Mixmax> micahg: And not let them turn it into The dreaded Dalnet!
[08:02] <micahg> Hobbsee: thanks
[08:03] <vish> odd, did i miss something?  why was he/she picking on cj-watson  though?
[08:03] <micahg> vish: trolling...
[08:03] <Hobbsee> goodness only knows
[08:03] <wgrant> There was a great battle last week.
[08:10] <Hobbsee> i'll never understand why people think they're going to get what they want by telling people to go and die, or other similar things
[08:45] <slomo> hi, can someone sync this from debian/experimental? https://bugs.launchpad.net/ubuntu/+source/totem-plugin-arte/+bug/639760
[09:00] <pitti> cjwatson: no, that looks wrong; I'll check this, thanks!
[09:00] <pitti> Good morning
[09:08] <pitti> cjwatson: right, seems this already happened in previous versions as well; I didn't change the generator script in 9
[09:09] <pitti> looks like all the rules with an icon name miss it
[09:52] <cjwatson> slomo: totem-plugin-arte is blocked on the rollout of a Launchpad fix.  I'll sync it after that
[09:56] <cjwatson> slomo: (bug 635591)
[09:56] <cjwatson> ah, here, that's Fix Released now
[09:56]  * cjwatson will look
[10:02] <wgrant> Watch out -- it may not be on cocoplum yet.
[10:02] <wgrant> But worth a try.
[10:03] <cjwatson> slomo: I think I misremembered what this was blocked on, so at any rate done
[10:04] <cjwatson> wgrant: it is, I checked bzr log there first :)
[10:04] <wgrant> cjwatson: Ah, good.
[10:23] <apparle> hi guys I want to access the touchpad. how to do it?
[10:37] <slomo> cjohnston: thanks
[10:37] <slomo> cjwatson: ^---
[10:38] <pitti> cjwatson: m-p-i fixed upstream (now with automatic syntax check), and uploaded version 10
[10:38] <pitti> cjwatson: thanks a lot for spotting
[11:06] <doko> Riddell: kdesdk failed to build. could you address bug #641356 with the next upload too?
[11:12] <Riddell> doko: mm, ok
[11:21] <tkamppeter> pitti, hi
[11:23] <cjwatson> tkamppeter: the changelog in your ghostscript upload doesn't match the control file
[11:23] <cjwatson> +  * debian/control: Updated versioned dependency of ghostscript on gsfonts,
[11:23] <cjwatson> +    we need at least gsfonts 1:8.11+urwcyr1.0.7~pre44-4.2 now due to the
[11:23] <cjwatson> +    dropping of defoma.
[11:23] <cjwatson> gsfonts (>= 1:8.11+urwcyr1.0.7~pre44-4.1)
[11:23] <cjwatson> but:
[11:23] <cjwatson> tkamppeter: is the control file correct (in which case that's fine) or is the changelog correct (in which case please reupload with a fixed control file)/
[11:23] <cjwatson> ?
[11:28] <doko> ttx: are you involved with likewise-open? there are some patches/fixes pending (assigned to Gerald Carter). But for now I'd like to just do a no change upload to get it built on powerpc.
[11:29] <doko> zul: ^^^
[11:35] <persia> doko, Are you sure that will work?  It didn't build for me on ppc yesterday, and I've been digging through the configuration hoping the Mac/PPC stuff would migrate to Linux/PPC.
[11:35] <doko> persia: currently building on davis,now for about 30min
[11:37] <persia> doko, Well, if it works, go ahead :)
[11:37] <tkamppeter> cjwatson, the correct version number is 1:8.11+urwcyr1.0.7~pre44-4.1. I will re-upload.
[11:41] <persia> doko, Just FYI, my build took 57 minutes to fail.
[11:43] <apachelogger> Keybuk: I have a Qt upstart library to the dbus interface ^^
[11:43] <apachelogger> (well, almost)
[11:46] <maxb> Does anyone know what's responsible for adding localhost6 to /etc/hosts on a maverick update?
[11:47] <Keybuk> apachelogger: doesn't Qt make one from the xml automatically?
[11:48] <apachelogger> Keybuk: yes, but the dynamic nesting requires some poking
[11:48] <apachelogger> Keybuk: comes to about 700 sloc including a simple example app and build system and xml
[11:59] <pitti> cjwatson, ev, all others I forgot: I recently installed a current Maverick snapshot, and I just wanted to say that the new installer simply looks and feels awesome. Kudos!
[11:59] <ev> yay
[11:59] <ev> thanks pitti
[12:00] <ev> that balances nicely with Keybuk's "it ate my shiny new computer"
[12:00] <Keybuk> no, the Lucid installer ate my shiny new computer
[12:00] <Keybuk> the Maverick installer mostly worked
[12:01] <Keybuk> though I did note that it complained that I didn't have a working Internet connection
[12:01] <cjwatson> my unproven suspicion is that grub_options is being initialised too early in lucid, before partitioning
[12:01] <Keybuk> while bcmwl-kernel-source was sitting on the CD and it could have done something about that itself
[12:01] <Keybuk> oh, and mvo - how the buggery bugger is apt-cd supposed to work?
[12:01] <cjwatson> and that if it had actually shown the device it was supposed to show, we could have avoided going down a hideously wrong path involving grub-efi
[12:02] <cjwatson> (which in part was because Keybuk asked me for help during sofa time :P)
[12:02] <ev> Keybuk: it does do something about it
[12:02] <Keybuk> ev: it didn't :p
[12:02] <ev> Keybuk: if you click the "give me nonfree happiness" and hit next, it solves that problem for you
[12:03] <Keybuk> I didn't have that button that I remember
[12:03] <ev> cjwatson: I'm really confused as to how putting something in the MBR could so massively break GPT for OSX
[12:03] <ev> given that it's just there for backwards compatibility
[12:04] <cjwatson> it wasn't putting something in the MBR
[12:04] <cjwatson> we were playing with grub-efi because I forgot how macbooks are supposed to work
[12:04] <cjwatson> and it looks like the EFI System Partition got trashed in some arcane way
[12:04] <ev> ahh
[12:04] <cjwatson> also something odd with the partition table which I didn't really have a chance to debug because Keybuk wiped and reinstalled :)
[12:09] <ttx> doko: likewise-open is now mostly maintained upstream and sponsored by the desktop team
[12:09] <doko> ttx: ok, thanks
[12:09] <ttx> doko: though I can help if need be, obviously
[12:10] <doko> ttx: no, looks like it needs porting for powerpc. the autoconf/automake failure I did see in the build log just did hide that
[12:10] <doko> persia: ^^^
[12:11] <persia> Yep.  There's some upstream config to make it work for OS X/ppc so I'm fairly sure that it can be ported easily.  I believe it to be just a matter of defining the architecture correctly, but haven't unwound the complex configuration yet.
[12:14] <doko> persia: look at NCommander's arm patches as a guide ...
[12:14] <persia> I don't think it's that bad, but yeah, I've looked at those.
[12:15] <mvo> Keybuk: apt-cdrom > that should just work, it talks to udev nowdays and looks for cdroms/dvds. what was/is the issue with it
[12:15] <mvo> ?
[12:15] <Keybuk> it seemed to find the CD ok
[12:15] <Keybuk> but when I tried apt-get install, it said file not found
[12:16] <Keybuk> (and the path it gave was certainly on the CD)
[12:16] <mvo> Keybuk: wehh, that is bad (obviously). did it output anything more, or just that? what do I have to do to reproduce, was that a fresh install?
[12:18] <Keybuk> yeah just a fresh install, CD still in the drive
[12:18] <Keybuk> was installing bcmwl-kernel-source
[12:18] <Keybuk> I'm pretty sure I can still reproduce it
[12:21] <mvo> Keybuk: it would be nice if you could give me the output of "apt-get install bcmwl-kernel-source -o debug::aptcdrom=true
[12:21] <Keybuk> sure thing
[12:21] <Keybuk> will grab that for you in a bit
[12:21] <mvo> Keybuk: and -o Debug::Acquire::cdrom=true as well please
[12:22] <Keybuk> *nods*
[12:22] <popey> Keybuk: you have a mbp?
[12:24] <Keybuk> popey: aye
[12:24] <ttx> doko: right, I'm pretty sure upstream answer was that "it's not supported"'
[12:24] <ttx> let me dig a reference for that
[12:24] <pitti> cjwatson: I just did some udev bug fixes, and prepared a new pacakge with an upstream merge; tested locally, works fine
[12:24] <popey> maverick installer scared me so i pulled the plug because it started doing stuff to the disk before I had an opportunity to tell it where to put grub :S
[12:24] <pitti> cjwatson: I'd like to upload http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu/maverick/udev/ubuntu/revision/2619, do you consider it okay, too?
[12:26] <Keybuk> popey: it asks that in the partitioning phase
[12:26]  * ogra notices that all his ubuntu problems vanished when he started to use that tegra2 based armel netbook from toshiba
[12:26] <pitti> cjwatson: there are two important bug fixes, a new keymap, some documentation updates, a new automatic test, and a small new feature in scsi_id (exports a new property); I think the feature is harmless for us, but I'd still like to get a second pair on it
[12:26] <popey> Keybuk: hmm it might do now, it didnt when I tried, so i did 10.04.1 -> 10.10 instead
[12:27] <ttx> doko: https://bugs.launchpad.net/ubuntu/+source/likewise-open5/+bug/345332
[12:27] <popey> Keybuk: keyboard layout wrong for you?
[12:27] <popey> Keybuk: bug 630203
[12:27] <cjwatson> pitti: looks fine
[12:28] <doko> ttx: well, meanwhile, ARM is supported ... NCommander, did the patches land upstream?
[12:28] <pitti> cjwatson: ok, thanks; uploading
[12:29] <persia> ttx, There's PPC support upstream: that bug is just kinda amusing.
[12:29] <Keybuk> popey: haven't explored fully
[12:29] <Keybuk> I know the touchpad is difficult
[12:29] <Keybuk> to right click a menu and choose an option in it is kinda impossible
[12:29] <popey> yeah
[12:30] <popey> I resorted to using a mouse ;(
[12:31] <ogra> doko, bug 517300 says it was forwarded ... not sure it was ever applied
[12:32] <Keybuk> popey: they keyboard seems mostly right, what's wrong for you?
[12:32]  * cjwatson punts popey's bug off to the right package
[12:32] <cjwatson> /usr/share/X11/xkb/symbols/gb is the relevant file
[12:34]  * popey reboots to find out
[12:34] <popey> thanks cjwatson
[12:38] <popey> Keybuk: pressing the "' & ~" key next to Z gives me "< & >" respectively
[12:39] <Keybuk> oh
[12:39] <Keybuk> I think I expected the ~ key to be next to 1
[12:39] <Keybuk> and have been using it there just fine ;-)
[12:40] <popey> well, yes, thats a nice place to put it, but wrong according to mr jobs
[12:44] <ttx> persia: eh, I suspect they added it later, then, because that's the answer I got from Jerry Carter at that time.
[12:44] <persia> ttx, Oh.  I thought it was earlier.  As far as I've been able to tell, the PPC support is only for old Mac OS X.
[12:44] <persia> But yeah, I don't expect upsteam to support ppc/linux today :)
[13:12] <ogra> mvo, lol !
[13:12] <ogra> mvo, you could just have told me to drop the 4 from the channel name :)
[13:18] <tkamppeter> cjwatson, the ghostscript with corrected debian/changelog is uploaded and in the queue now.
[13:18] <mvo> ogra: well, its not the only fix needed :)
[13:18] <mvo> ogra: and honestly its a bit silly from s-c to mandate that ;)
[13:18] <ogra> indeed
[13:19] <ogra> but would be an easy workaround on my side
[13:19] <mvo> ogra: there is another problem in the code left that I just fixed
[13:19] <mvo> ogra: so its a good and worthwhile report
[13:19] <ogra> k :)
[13:19] <ogra> thanks for the quick fix
[13:19] <ogra> i'll add testing results to the bug
[13:20]  * ogra goes to find lunch
[13:20] <mvo> ogra: I think the currently .eula display is broken too, I check that out now, if you could move that to plain text that would make it easier
[13:20] <mvo> ogra: after lunch :)
[13:20] <ogra> mvo, no prob, will do
[13:20] <ogra> its not a real eula anyway, no ?
[13:20] <ogra> there wont be a yes/no question i guess
[13:21] <ogra> (or accept/cancel or how you wanna call it)
[13:21] <mvo> ogra: yeah, I think we should just name it "info" instead or ".description"
[13:21] <mvo> ogra: nowdays with s-c there is no need for yes/no anymore, that is legacy from gnome-app-install
[13:21] <ogra> yup
[13:21] <ogra> well, there is
[13:21] <ogra> for TI at least
[13:22] <ogra> some packages ship third party stuff that requires eula accepting
[13:22] <ogra> which TI has no control over
[13:22] <mvo> ogra: aha, ok.
[13:22] <mvo> ogra: so we keep it as eula and write "if you enable this source you accept the eula"?
[13:23] <ogra> how does s-c handle debconf questions with eula like java stuff for example ?
[13:23] <ogra> does anything pop up on a per package basis ?
[13:23] <mvo> that should work just fine
[13:23] <persia> Isn't that just the normal debconf frontend?
[13:23] <ogra> or is it just ignored
[13:23] <mvo> the gnome frontend will be used during install
[13:23] <ogra> ah, perfect
[13:23] <ogra> current TI packages steal preinst from java i belive
[13:23] <persia> mvo, Always GNOME, or whichever is appropriate?
[13:24] <ogra> so that should just work ... but i'll clearify if we cant just leave the s-c eula and drop debconf fiddling
[13:24] <persia> That wouldn't be safe anyway, in case people use other means to enable a channel.
[13:25] <mvo> persia: gnome iirc, not sure what is up with the qt one these days
[13:25] <ogra> anyway, lunch
[13:27] <LBo> Hi
[13:28] <cjwatson> tkamppeter: thanks
[13:28] <LBo> I'm not sure if I'm in the right channel but I have a question about the python bindings for libindicate
[13:28] <LBo> Is it possible to start the server in one process and add messages to that server in another process?
[13:28] <LBo> With the python binding
[13:39] <Keybuk> my office has gotten so untidy, I'm starting to think that it would be better to just get a new office
[13:39] <cjwatson> sounds familiar
[13:39] <ogra_cmpc> Keybuk, come over to the arm team, our devices are smaller :)
[13:40] <soren> Quotes page!
[13:40] <persia> Not necessarily: I have x86 machines that are smaller than some of my arm machines
[13:40]  * soren misses the Quotes page
[13:40] <ogra_cmpc> soren, btw, i bought a new blinker :)
[13:40] <ogra_cmpc> it had a car attached *g*
[13:41] <Keybuk> ogra_cmpc: it's not devices, it's mostly notes
[13:41] <ogra_cmpc> next europe uds you dont have to drive scared
[13:41] <soren> Heheh :) Did you keep the car it came with or was it just a vessel for your new blinker?
[13:41] <Keybuk> I appear to now be using laptops as bookmarks in notebooks
[13:42] <ogra_cmpc> soren, didnt fit, so i kept the car too :) http://people.canonical.com/~ogra/car/0180175676001.jpg
[13:42] <soren> ogra_cmpc: Nice :)
[13:45] <zyga> where is this magic repo with all the -dbg packages?
[13:45]  * zyga needs to hunt some crashes
[13:47] <zyga> pitti, could you please point me to the debug symbol repository?
[13:48] <persia> ddebs.ubuntu.com ?
[13:48] <ogra_cmpc> zyga, the debigging wikipage should have it
[13:48] <persia> Indeed
[13:48] <ogra_cmpc> *debugging
[13:48] <ogra_cmpc> i thik there is also a subdir needed
[13:48] <ogra_cmpc> not only ddebs.ubuntu.com
[13:49] <persia> Well, sure, but that's enough to analyse archive structure :p
[13:49]  * zyga could not find any information about this apart from pitti's email from 2007
[13:49] <persia> !stacktrace
[13:49] <persia> !debug
[13:50] <persia> https://wiki.ubuntu.com/DebuggingProgramCrash
[13:51] <zyga> persia, thanks!
[13:51] <persia> !crash
[13:52] <persia> bah.  Something shuold point at the right URL :(  I suppose it's not hard to find from the landing page, but...
[13:52] <zyga> persia, I found a bug in dbus menu and I need symbols to report a proper bug
[13:54] <persia> zyga, You know about the retracers, right?  That if you're using Ubuntu packages, and you crash, apport will upload the coredump, and the retracers will do the symbol insertion for you?
[13:54] <zyga> persia, this bug has several duplicates but for each report the retracer failed
[13:54] <persia> Anyway, for future note, #ubuntu-bugs is great resource for information about debugging, filing good bugs, etc.
[13:55] <zyga> persia, thanks :-)
[13:57] <tseliot> pitti: do you know why I can't find linux-restricted-modules-envy-2.6.24 in Hardy?
[14:09] <alourie> question: who would be the person to talk to about uds.ubuntu.com?
[14:21] <pitti> zyga: right, what persia said (sorry, was out for lunch)
[14:21] <zyga> pitti, thanks, I got it now
[14:22] <pitti> tseliot: it's only in hardy-updates indeed
[14:22] <pitti> linux-restricted-modules-envy-2.6.24 | 2.6.24.503-503.31 | hardy-updates/multiverse | source
[14:22] <pitti> tseliot: I don't remember any more, did we introduce that post-release, or was that an abi bump or so?
[14:23] <tseliot> pitti: that doesn't depend on the ABI as it uses DKMS. Maybe we introduced it post-release
[14:24] <tseliot> it was some time ago...
[14:24] <tseliot> pitti: I'm asking as I need to update it now because of LP: #642518
[14:24] <tseliot> bug #642518
[14:25] <pitti> tseliot: is linux-restricted-modules-envy-2.6.24 the dkms version?
[14:25] <tseliot> pitti: yep
[14:26]  * tseliot has to update any fglrx package in hardy, jaunty, karmic and lucid :/
[14:27] <pitti> ugh, good luck
[14:28] <tseliot> thanks, I'll need it ;)
[14:29] <tseliot> smb: BTW I'm working on a patch for Hardy which we'll have to apply to both linux-restricted-modules-envy-2.6.24 and linux-restricted-modules-2.6.24 (which the kernel team maintains)
[14:29] <tseliot> apw: ^
[14:29] <smb> tseliot, Ok got that ready already
[14:30] <tseliot> smb: ah, even better. Will you share the patch?
[14:30] <smb> tseliot, sure, I'll send you a mail
[14:30] <cjwatson> you know that your problem has become complicated when you find yourself stracing automake
[14:31] <tseliot> smb: thanks
[14:31] <smb> tseliot, Had to modify it slightly as lrm does not make use of make.sh
[14:32] <tseliot> smb: ah, I'll have to check lrm-envy as I don't remember whether it uses make.sh or not
[14:33] <smb> tseliot, mail is away. Maybe it works for envy the same
[14:33] <smb> Should actually not matter that way whether you come from make.sh or not
[14:33] <tseliot> smb: I hope it does, as I don't really remember how lrm-envy works
[14:34] <tseliot> yes, as long as you get that flag from somewhere
[14:34] <smb> Understandable, its so long ago. Had to dig around in lrm as well
[14:34]  * tseliot nods
[14:40] <tseliot> smb: BTW have you built lrm with your patch
[14:40] <tseliot> locally, that is
[14:40] <smb> tseliot, yes
[14:40] <tseliot> ok
[14:41] <tseliot> ah, fix committed in Hardy
[14:41] <smb> tseliot, test build failed with the change to make.sh. Thats how I noticed it is not used there
[14:41] <smb> tseliot, Yes and uploaded to proposed now
[14:41] <tseliot> smb: great
[14:42] <smb> pitti, Btw, could you accept it?
[14:42] <smb> pitti, l-r-m for hardy, that is. Its the fix for the fglrx compile failure after the last security upadte
[14:42] <tseliot> smb: I guess we should request an SRU in the bug report anyway
[14:43] <smb> true
[14:43] <smb> tseliot, who? :)
[14:43] <pitti> smb: looking; takes a bit longer since it was just uploaded (no debdiff yet)
[14:43] <smb> pitti, Ok, np. It was really just done
[14:44] <smb> pitti, Seems one of us ( tseliot  or me ) needs to add SRU info to the bug
[14:44] <pitti> seems fine? tasks look alright
[14:44] <tseliot> smb: I was planning on doing it as soon as all of my sources are ready. But if you want to do it first, please go ahead
[14:45] <smb> tseliot, Ok, I'll update the bug and subscribe the sru team
[14:45] <pitti> smb: hold on, I'm currently wiggling the bug
[14:45] <pitti> u-sru gets autosubscribed
[14:45]  * smb holds
[14:45] <tseliot> smb: perfect, thanks
[14:46] <pitti> it shoudl be clear, but of course we'll waive the 7 day period for this
[14:46] <pitti> done
[14:48] <smb> pitti, great thanks. Yeah it sort of is fixup. Though l-r-m in hardy is probably slightly less critical. It is not recompiled locally. So it would have broken next time we would try to upload it.
[14:50] <smb> pitti, otoh the security relevant part would still be vulnerable if we do not recompile it...
[14:50] <kees> assuming fglrx uses it unsafely, that is
[14:52] <smb> kees, correct as fglrx in lrm was compiled before the securty update it still would use the old implementation
[14:52] <smb> (as that was an inline)
[14:52]  * kees nods
[14:53] <smb> pitti, I assume yes, but done also meant you are done wiggling the bug?
[14:53] <pitti> smb: right
[14:54] <smb> ok, just wanted to be sure not to step on some body parts. ;)
[14:57] <pitti> cjwatson, mdz, kees, Keybuk: TB meeting reminder (3 mins)
[14:57] <pitti> sabdfl seems to be off today?
[14:57] <kees> pitti: yup, there's another meeting in there atm
[15:31] <kees> doko: so, how do I turn on all the CompilerFlags defaults for llvm?
[15:32] <doko> kees: -O99? no, sorry, don't see what you want ...
[15:34] <kees> doko: I mean -fstack-protector, -D_FORTIFY_SOURCE etc
[15:35] <doko> kees: in the JIT, or in clang?
[15:35]  * kees does not know llvm at all.
[15:35] <kees> isn't it a C compiler?
[15:36] <doko> you can use it as a C compiler too
[15:36] <doko> so llvm-gcc-4.2 should be easy
[15:36] <doko> clang you'll have to look at
[15:36] <kees> ah-ha, but the things we use it for are the JIT, not the C compiler? if so, I'll ignore this some more
[15:36] <doko> the JIT, have fun ...
[15:37] <kees> heh
[15:37] <doko> kees: but then, why don't you start modifying hotspot in openjdk first? ;P
[15:38] <doko> ohh, and llvm-gcc-4.5 should already be done
[15:38] <doko> if you did gcc-4.5
[15:39] <kees> I'm not touching JITs yet :)
[15:54] <maxb> It's quite late in the cycle, and there is still no sun-java6 in the maverick partner repository. Is anyone visual on getting that uploaded in time?
[15:56] <ogra_ac> there is a maverick-partner already ?
[15:58] <maxb> Doesn't a partner repository spring into existence at the creation of a new distroseries?
[15:59] <ogra_ac> yes, like -security, but nobody uploads to them before release usually
[15:59] <ogra_ac> not sure if partnaer is different in that regard, but i wouldnt expect so
[16:00] <ogra_ac> since you need a stable release to compile the partner packages against
[16:01] <ogra_ac> i wouldnt expect partners to be keen to rebuild for every changed dep during a dev cycle
[16:01] <tseliot> pitti: can you approve the following source packages in -proposed, please? linux-restricted-modules-envy-2.6.24 (in hardy), fglrx-installer (in jaunty, karmic, lucid)
[16:02] <ogra_ac> mvo, is there any change in update-notifiers behavior in maverick ?
[16:02] <maxb> Hmm. Well, sun-java6 is a bit of an oddity, as it's actually synced from Debian non-free
[16:02] <mvo> ogra_ac: no, why?
[16:02] <ogra_ac> i havent seen it auto-popup since a while
[16:02] <ogra_ac> even there are updates pending and i ran apt-get update
[16:03] <ogra_ac> GrueMaster said he doesnt see it on hos x86 netbook either
[16:03] <ogra_ac> *his
[16:04] <mvo> ogra_ac: its magic (too much of it) - you can run "update-notifier --debug-update " to see why its not comming up
[16:05] <ogra_ac> will do
[16:21] <ogra_ac> mvo, so it looks like it reports the right amounts of packages etc but u-m never pops up
[16:21] <mvo> ogra_ac: so the logic is that if you upgraded manually in between (apt-get, synaptic etc) it will reset the 7 day counter
[16:31] <ScottK> ogra_ac: Remember it was decided that not telling you about updates is a good thing.
[16:32] <ScottK> TheMuso: Ping (re your espeak upload in the queue)
[16:32] <ogra_ac> ScottK yeah, but it used to pop up if i manually ran apt-get update
[16:32] <ogra_ac> in lucid at least
[16:32] <ogra_ac> but if it waits seven days .... well ... shrug
[16:33] <pitti> tseliot: meeting-o-mania, will do ASAP
[16:33] <pitti> tseliot: no -envy in https://edge.launchpad.net/ubuntu/hardy/+queue?queue_state=1 ?
[16:33] <tseliot> pitti: np ;)
[16:33] <tseliot> pitti: that's in NEW
[16:33] <tseliot> unfortunately
[16:34] <pitti> ??
[16:34] <tseliot> pitti: [ubuntu/hardy-proposed] linux-restricted-modules-envy-2.6.24 2.6.24.503-503.32 (New)
[16:35] <tseliot> this is what the email that I received says
[16:36] <tseliot> pitti: I guess it's perceived as an ABI bump (as in lrm) but there's no ABI here
[16:36] <tseliot> as I use DKMS
[16:37] <smb> I though all kernel modules also NEW before finally getting out...
[16:38] <smb> I was surprised once but then thought I just may have forgotten that feature. Though it seemed strange as the abi had not changed... Maybe a new "feature"
[16:39] <cjwatson> if you upload any package name, binary or source, which is not currently in the archive, then it will hit NEW
[16:39] <cjwatson> this one is a little odd
[16:40] <cjwatson> I suspect that uploads to -proposed don't magically inherit overrides from -updates
[16:40] <cjwatson> because linux-restricted-modules-envy-2.6.24 is only in hardy-updates, not in hardy
[16:40] <tseliot> ah
[16:59] <tkamppeter> pitti, it is about bug 632094 and bug 618017. I have a possible fix. The self-extraction Python script for the PPD archives throughs Tracebacks when simply killing the process, like entering "/usr/lib/cups/driver/openprinting-ppds list | less" end then pressing "q" without scrolling down before. I have a simple fix for that, should I upload it for Maverick?
[17:01] <pitti> tseliot: hm, did yuo happen to upload fglrx-installer/karmic twice?
[17:02] <pitti> tseliot: I just accepted it, but now it's in the queue qgain
[17:02] <pitti> tseliot: ah, no, you have to reupload
[17:02] <pitti> FAILED: fglrx-installer (The source fglrx-installer - 2:8.660-0ubuntu5 is already accepted in ubuntu/lucid and you cannot upload the same version within the same distribution
[17:03] <pitti> tseliot: ^
[17:03] <tseliot> pitti: I don't think so and I received only 1 email about it
[17:03] <pitti> tseliot: I'll reject it; please let me know if you have a new upload; use ubuntu4.1?
[17:03] <tseliot> pitti: oh, I see, I'll do it again in a second
[17:04] <tseliot> pitti: is it only lucid or shall I do the same for karmic?
[17:04] <pitti> tseliot: no, it's only karmic
[17:04] <pitti> tseliot: jaunty and lucid went fine
[17:04] <pitti> sorry, I already fired the "plz test" mail for karmic
[17:05] <tseliot> pitti: I misread that message. Ok, I'll reupload karmic's source
[17:06] <tseliot> pitti: done (it's 4.1 this time)
[17:11] <tseliot> pitti: ok, it's waiting for approval now
[17:11] <pitti> tseliot: accepted
[17:11] <pitti> tseliot: thanks a lot!
[17:11] <tseliot> pitti: thanks for approving all of those packages ;)
[17:12] <pitti> np
[17:14] <tkamppeter> pitti, if you are on approving packages now, can you approve my ghostscript (the newer one, I have fixed a copy'n'paste error in changelog)?
[17:14] <pitti> will have a look later
[17:35] <mathiaz> ttx: what's your take on bug 641001?
[17:36] <mathiaz> ttx: should it be included before release or maverick-updates is ok as a 0 day sRU?
[18:13] <ScottK> mathiaz: My advice is that for things you would SRU, as long as they don't impact the kernel, would be to go ahead (speaking for myself, don't take that as release team approval)
[18:15] <pitti> +1
[18:16] <pitti> at least until the RC
[18:26] <tkamppeter> pitti, can you have a look at bug 618017? It is a rather trivial patch to eliminate annoying Apport pop-ups caused by Python Tracebacks. Should we take it into Maverick?
[18:27] <pitti> simple crash fixes always sound fine
[18:27] <pitti> tkamppeter: this is not an FFE, btw
[18:27] <pitti> it's not a feature at all
[18:27] <tkamppeter> pitti, How is it called then?
[18:27] <pitti> a bug fix :)
[18:28] <pitti> there's no particular procedure for those, just upload and wait for a release team member to review the upload/bug
[18:28] <tkamppeter> FFE removed. pitti, should I prepare and upload the packages?
[18:28] <pitti> tkamppeter: please do
[18:28] <pitti> thanks for fixing!
[19:00] <ttx> mathiaz: I'd say before release
[19:00] <mathiaz> ttx: I've uploaded the package to maverick
[19:00] <mathiaz> ttx: we'll see how it goes :)
[19:00] <mathiaz> ttx: puppet is on the -server isos
[19:00] <ttx> mathiaz: I'll track it
[19:00] <mathiaz> ttx: that's why I wasn't sure if it could be uploaded
[19:01] <ttx> oh, it always can.
[19:12] <ScottK> TheMuso: unping.
[19:34]  * nigelb hugs lucidfox :)
[19:34]  * lucidfox hugs back
[19:34] <lucidfox> That was a bit random, nigelb :)
[19:35] <nigelb> lucidfox: More like a bit delayed :)
[19:35] <nigelb> Thanks for posting the interview :)
[19:35] <lucidfox> Ah!
[19:36] <lucidfox> nigelb> I thought it was about my conversion to the evil Kult of the blue K
[19:37] <nigelb> lucidfox: wait, where is that? scrollback?
[19:38] <lucidfox> nigelb> Yes, and #kubuntu-devel
[19:39]  * nigelb will look
[22:12] <Keybuk> clearly the touchpad support needs some improvement :-/
[22:15] <fagan> Keybuk: well this is the first relase
[22:15] <fagan> *release
[22:15] <Keybuk> first release of?
[22:15] <fagan> the multitouch stuff
[22:16] <Keybuk> I'm not using the multitouch stuff
[22:16] <fagan> damn I really should read stuff right
[22:16] <fagan> i read touchpad as multitouch
[22:16] <fagan> :P
[22:18] <Keybuk> having a few difficulties right-clicking and middle-clicking with the MBP touchpad
[22:19] <fagan> Keybuk: isnt the MBP touchpad supposed to be getting better now
[22:19] <Keybuk> yeah, it can right-click by clicking with two fingers
[22:19] <Keybuk> but you can't, for example, right-click and then move the pointer
[22:19] <Keybuk> which is kinda necessary to use context menus
[22:20] <Keybuk> the other main problem seems to be that if you change fingers at all, it stops whatever you're doing
[22:20] <Keybuk> so if you click and drag an icon, and add another finger because you ran out of touchpad, it drops the icon there and then
[22:20] <fagan> thats not good
[22:26] <Keybuk> but hey, just about everything else works
[22:27] <Keybuk> even the keyboard backlight :p
[22:27] <fagan> have you tried utouch with it yet
[22:27] <fagan> ?
[22:28]  * fagan got scrolling on all 4 fingers with his crappy old laptop touchpad 
[22:30] <Keybuk> fagan: no, I probably should
[22:30] <Keybuk> two-finger scrolling actually works on this with the bcm5974 driver
[22:31] <fagan> Im not even going to bother with the pinch and the other stuff id say
[22:31] <fagan> but the two three and four fingers work easy on my old computer
[22:31] <fagan> which I found very strange
[22:53] <SpamapS> lifeless: you do realize your "how do we package multiple versions of the same lib" question is causing my head to explode, right? ;)
[22:56] <ion> Hasn’t that been done for ages? E.g. libcurl3, libcurl4
[22:56] <ion> Gtk 1.2, 2.0
[22:58] <fagan> yeah ion is right
[22:58] <fagan> there always was a lot of them
[22:58] <fagan> so developers who dont port their app to the newer version can stay in the repo
[22:59] <fagan> and in cases like python where we havent moved to 3 yet but we still have it in the repo so people can use it
[23:03] <SpamapS> ion: compile time/link time checks are easy
[23:04] <SpamapS> Try building an app on top of say, ruby on rails 2.x right now..
[23:04] <SpamapS> then ubuntu ships rails 3.0
[23:04] <SpamapS> and your app implodes
[23:05] <SpamapS> Or maybe even just a minor release version where the developers inadvertently broke the API in a python module..
[23:05] <SpamapS> Yes you should fix your app to work with the new API version.. but there's no link time check thats failing because you didn't.
[23:05] <SpamapS> Its just some random runtime fatal error.
[23:06] <SpamapS> Unless we find a way to get 100% code coverage unit tests to write themselves, its monumentally harder to test for API compatibility in scripting languages.
[23:07] <lifeless> SpamapS: its the same answer as for c libraries
[23:07] <lifeless> SpamapS: forget about perfection, just use the same rules that gems, eggs and jars themselves use.
[23:07] <lifeless> SpamapS: solved problem
[23:08] <SpamapS> lifeless: what rules do eggs use?
[23:08] <SpamapS> I honestly don't know. ;)
[23:09] <SpamapS> and that just solves the "existence on the system" problem right? you still have to munge your load path to get the ones you want. Don't you?
[23:09] <lifeless> setuptools knows how to do it
[23:09] <lifeless> .pth files
[23:09] <lifeless> bbiab
[23:09] <SpamapS> .pth appends
[23:11] <SpamapS> I know that ruby has solved this quite well with rvm http://rvm.beginrescueend.com/
[23:12] <ion> Yeah, a decent deployment system basically takes a snapshot of all the dependencies and pushes that along with an app release to production, assuming you’ve tested the combination first.
[23:13] <SpamapS> rubygems actually has it doable in code
[23:13] <SpamapS> you can say    gem 'libFoo', '> 3.0'
[23:23] <lifeless> SpamapS: 'Require'
[23:23] <ScottK> Which works great until libFoo does something incompatible in 3.1 that got released yesterday.
[23:24] <lifeless> from pkg_resources import require; require("foo==3.0.0")
[23:24] <lifeless> ScottK: the newer-versions-break-stuff isn't limited to ABI changes in C libraries though
[23:25] <lifeless> simple behaviour things can do it, so thats not unique to python
[23:25] <lifeless> and the fix is the same: upload again with a capped version range
[23:30] <SpamapS> lifeless: so analogous to the way rubygems is doing it.
[23:33] <lifeless> SpamapS: yes
[23:35] <SpamapS> lifeless: given that, it would actually be better to embrace rubygems/pypi/cpan than try to fold them into .deb wouldn't it?
[23:35] <lifeless> SpamapS: that is why I said 'upstream' in my mail :)
[23:36] <lifeless> SpamapS: but I think the deb wrapping has a lot of value:
[23:36] <lifeless>  - we've tested combinations
[23:36] <lifeless>  - no worries about MITM attacks and can use the apt toolchain to get what you need mirrored in advance etc
[23:37] <SpamapS> lifeless: and licensing, and other things too...
[23:37] <mathiaz> SpamapS: IMO we should embrace upstream tools
[23:38] <SpamapS> mathiaz: agreed 100%
[23:38] <mathiaz> SpamapS: and make sure they don't break apt/dpkg.
[23:38] <mathiaz> SpamapS: IMO it's unreasonable to try to package everything in the world
[23:38] <SpamapS> even a bad idea
[23:39] <SpamapS> we're talking python, but I'd like to consider java for a moment
[23:40] <SpamapS> mathiaz: so for Hadoop/cassandra, they need lots of libs from maven/ivy/etc...
[23:40] <mathiaz> SpamapS: right
[23:40] <SpamapS> mathiaz: but we'd like to make sure they are licensed correctly, working, etc.
[23:40] <SpamapS> seems like the upstream tools aren't going to help us do that.
[23:40] <mathiaz> SpamapS: and the versin of the libs are different for every one of them
[23:41] <mathiaz> SpamapS: I think one of the first step is to decide whether we'd allow to have multiple version of the same library in the archive
[23:42] <lifeless> I think we should embrace upstream tools - yes. But that can mean many things.
[23:42] <lifeless> For me, I think we want to write thunks for them so that:
[23:42] <lifeless>  - they can request dependencies (even at runtime) from the package manager.
[23:42] <SpamapS> mathiaz: Yes, we should allow multiple versions. No we should not allow unlimited versions. ;)
[23:43] <lifeless>  - we find a way such that we can represent enough of the magical complexity that they have, to work well.
[23:43] <mathiaz> SpamapS: right - IIUC in the java world that would actually be the case
[23:43] <SpamapS> lifeless: for scripting languages, its all runtime. ;)
[23:43] <lifeless> I'm thinking the dbus service that installs packages, sort of thing.
[23:43] <mathiaz> SpamapS: one version of a library per application
[23:44] <lifeless> mathiaz: that would be too restrictive for some java stuff.
[23:44] <lifeless> (sadly)
[23:44] <SpamapS> lifeless: how do you authorize a runtime program for installing things though? that seems rather haphazard at first glance.
[23:44] <mathiaz> lifeless: some application could have 2.0.1 and 2.1.2 of the same jar?
[23:44] <lifeless> mathiaz: yes
[23:45] <lifeless> SpamapS: theres an existing service for it
[23:45] <lifeless> SpamapS: on the buildds we could just have it say 'true'
[23:45] <lifeless> SpamapS: packagekit
[23:45] <mathiaz> SpamapS: I'm not sure I get your use case?
[23:46] <mathiaz> SpamapS: dependencies can be sorted at package build time?
[23:46] <lifeless> mathiaz: OSGI
[23:46] <mathiaz> SpamapS: or when an application is installed (via gem, maven, etc..)
[23:46] <lifeless> mathiaz: you can't actually sensibly ask maven to predict all the deps in advance
[23:46] <lifeless> mathiaz: because its got a complex minilanguage; better to make the callbacks /work/.
[23:46] <mathiaz> lifeless: agreed
[23:47] <lifeless> and if something is needed that isn't packaged, error, and then we package it etc.
[23:47]  * mathiaz nods
[23:47] <mathiaz> IMO we should provide a maven repo available from the buildd networks
[23:47] <mathiaz> and populate the maven repo on a per need basis
[23:47] <SpamapS> well with maven thats at least doable at build time
[23:48] <SpamapS> I feel though that the same solutions for maven/java will not work for scripting languages
[23:48] <mathiaz> well - populating the maven repo == packaging them correctly in apt
[23:48] <lifeless> mathiaz: thats roughly what I'm saying
[23:48] <SpamapS> tell the buildd to install on runtime need. Then run the unit tests. Without code coverage, we miss deps.
[23:48] <lifeless> mathiaz: except inject a deb-backed maven repo implementation
[23:49] <mathiaz> lifeless: right - and having a pseudo maven service that answers if the version of the dep is already packaged
[23:49] <lifeless> mathiaz: so there isn't a 'regular' maven repo at all.
[23:49]  * mathiaz nods
[23:49] <lifeless> just a maven-repo that talks to apt; and apt can handle N versions of a library to handle things like (e.g.) hudson
[23:49] <lifeless> or atlassian stuff, etc
[23:49] <lifeless> etc
[23:49] <lifeless> et
[23:49] <lifeless> c
[23:49] <SpamapS> lifeless: so rather than using the local mode that maven-debian-helper uses, you'd have a maven backend that helps resolve things?
[23:50] <lifeless> SpamapS: right, maven-debian-helper is broken by design
[23:50] <mathiaz> SpamapS: the backend could also help to create the build dependency
[23:50] <mathiaz> SpamapS: what does maven-debian-helper actually do?
[23:51] <SpamapS> well in this case.. really all we're talking about is building our own limited maven repository.. doesn't need to be special at all... we just have to apply our packaging policies to the bits in the maven repository
[23:51] <SpamapS> and the same would work for pypi/gems/cpan/pear/etc.
[23:51] <SpamapS> and be a lot easier than trying to .deb them all
[23:51] <mathiaz> SpamapS: well - the output would always to be driven by .deb
[23:51] <mathiaz> IIUC the problem is in building the dependencies - right?
[23:52] <SpamapS> mathiaz: maven-debian-helper puts a java library in a local repository with a special version "debian" and then tries to muck with the spec file of other things to not require a specific version, but rather to require the version "debian"
[23:52] <mathiaz> if the dependencies are all packaged, the correct depends can be generated?
[23:52] <lifeless> SpamapS: I wasn't proposing a maven repo; rather a maven 'repo implementation'
[23:52] <mathiaz> lifeless: that maven pseudo-repo would be used by buildd?
[23:52] <SpamapS> mathiaz: No, I'm saying it would be far easier to simply approve/disapprove syncs into a maven repository than to try and make .debs for everything.
[23:52] <mathiaz> lifeless: or ubuntu developers to figure out what needs to be packaged?
[23:53] <SpamapS> I mean.. big picture thinking here..
[23:53] <SpamapS> we already do this for *debian* -> *ubuntu* .. why not *maven* -> *ubuntu-maven* ?
[23:53] <lifeless> mathiaz: uh, 'an adapter from the maven object api to apt'. Is what I'm proposing.
[23:53] <SpamapS> the goal is to be able to repeat builds, sustain support, etc. right?
[23:53] <mathiaz> SpamapS: yeah - the problem then is about ubuntu licensing policies
[23:53] <lifeless> SpamapS: licence metadata perhaps?
[23:54] <mathiaz> SpamapS: yeah - and maven repo is a binary repo IIUC
[23:54] <SpamapS> I'd bet money on maven repositories being built in a way to be extensible.
[23:54] <lifeless> SpamapS: I'd be happiest with a (source jar)->deb machine
[23:54] <mathiaz> SpamapS: sources for every version are not necessarly available
[23:54] <SpamapS> True, maven isn't a source repo, which kills that idea. ;)
[23:54] <lifeless> SpamapS: I'll take your money; jars are extensible but at that point why not just reflect it straight int oapt.
[23:54] <lifeless> SpamapS: maven is both binary and source.
[23:55] <lifeless> foo-1.2-source.jar and foo-1.2.jar
[23:55] <mathiaz> lifeless: are *all* sources available for each binary in the maven repo?
[23:56] <SpamapS> Those sources are often very tricky to build again into the same binary
[23:56] <mathiaz> lifeless: I thought binary jars could be uploaded to maven without their source
[23:56] <SpamapS> http://mvnrepository.com/artifact/org.apache.hadoop/avro/1.3.3
[23:56] <SpamapS> no source
[23:58] <ScottK> lifeless: Of course not.  I guess my point is that providing a versioning capability is one thing, but developers still have to be willing to keep API/ABI compatibility or increment the version.  IME there's only a limited amount of discipline for that in the Python world and ~none in the Ruby/RoR world.