[01:33] <psusi> so I'm a little confused about pkg-config... this program depends on lua... as I understand it, the package should use pkg-config to discover the proper include path where it can find the headers for lua, which varies depending on the version installed... bug if you don't know or care what version is installed, how do you use pkg-config?  since it seems to require the full 'lua5.1' name rather than just 'lua'?
[01:35] <RAOF> Does /usr/lib/pkgconfig/lua.pc exist, or is it lua5.1.pc?
[01:35] <psusi> it's lua5.1.pc
[01:35] <psusi> shouldn't the package create a diversion for the unversioned lua.pc?
[01:37] <RAOF> That kinda depends.
[01:38] <RAOF> Really that's an upstream decision.
[01:38] <psusi> how are you supposed to get SOME version of lua if you don't know or care what version is installed?
[01:38] <RAOF> You can't; upstream obviously wants you to ask for lua5.1
[01:39] <RAOF> psusi: Oh, also, about your radeon question a while ago: yes, radeon loads firmware blobs - they're all in /lib/firmware/radeon
[01:39] <psusi> hrm... I thought it was us who changed it to lua5.1 so we could install multiple versions at once?
[01:39] <RAOF> If that's us, then we're wrong, and bugs should be filed.
[01:39] <psusi> ahh, yes... I ended up finding the amd docs for the r600 gpu and started reading them... fascinating stuff
[01:41] <psusi> am I correct in assuming that the reason they are in binary form ( well hex file form anyhow ) is because there isn't a ( common ) assembler for the gpu?  but it looks like based on this documentation I should be able to understand what the microcode means, effectively disassembling it by hand... but where does the code come from?  amd/ati?  or did someone else develop the code?
[01:42] <psusi> there was only a single commit when I checked the git log for the file and it didn't seem to say
[01:42] <RAOF> I presume it comes from AMD; you might be able to understand it based on the docs, or it might be driving a separate processor.  I dunno :)
[01:44] <psusi> I guess what I'm getting at is, does amd provide the same microcode to the open source mesa driver that the proprietary one uses, and the only difference is the kernel code that passes the commands down to the firmware, or is the firmware also developed openly?
[01:44] <RAOF> I think it's the former, but I'm not sure.
[01:46] <psusi> goofy
[01:47] <RAOF> Firmware isn't generally very interesting :)
[01:47] <psusi> of course it is ;)
[01:47] <psusi> all the driver does is forward commands from the higher layers to the firmware... the firmware is where it all actually happens... that's where the important stuff is
[01:56] <RAOF> Given how small the firmware is compared to the rest of the stack, I beg to differ :)
[01:58] <RAOF> (The firmware is ~2KiB, fglrx contains more code than the whole kernel)
[02:56] <psusi> RAOF, how is that?  the driver just has to communicate with the card... the firmware running on the card is what actually implements all of the opengl calls
[03:52] <pting> i'm trying to use prevu to generate a backport of maverick's puppet 2.6 to lucid, but prevu doesn't seem to accept my DIST, it keep defaulting to karmic
[03:53] <pting> soren, if i wanted to backport something from maverick to lucid, am i suppose to use the following commands: DIST=lucid sudo -E prevu-init && DIST=lucid prevu mypackage ?
[06:54] <MTecknology> I'm about to add a script to a package. The package has a BSD license so I figure I may as well make the script has the same license. The issue is that I have no idea wha the top of that file should look like..
[06:55] <MTecknology> Any tips?
[06:59] <micahg> MTecknology: what type of header do the other files have?
[07:03] <MTecknology> micahg: there's a LISENCE file with http://dpaste.com/281813/ and the other files seem to just have a comment block with  * Copyright (C) Igor Sysoev
[07:08] <micahg> MTecknology: sorry, I'm still a little fuzzy on licenses
[07:09] <MTecknology> micahg: I'm completely fuzzy :P - I can pick the license I want, but that's about it
[07:10] <MTecknology> oh... I think I figured it out
[08:18] <dholbach> good morning!
[08:41] <hrw> hi amitarora
[08:41] <hrw> morning
[08:41] <amitarora> hrw: Hello
[08:42] <amitarora> hrw: Whom should I contact for sponsoring the package for the new tool that we have developed in Power Management work group of Linaro ?
[08:47] <hrw> amitarora: powerdebug?
[08:54] <amitarora> hrw: yes .. powerdebug
[08:55] <amitarora> hrw: have a call in few mins .. will have to disconnect and connect again in sometime ..
[08:55] <hrw> dholbach: can you help amitarora when he will be back?
[08:56] <micahg> hrw: a new package needs 2 MOTU acks before uploading (sponsor can be one)
[08:57] <hrw> micahg: or one coredev?
[08:57] <micahg> hrw: no
[08:57] <hrw> thx
[08:57] <micahg> hrw: AFAIK at least :)
[08:59] <amitarora> hrw: am back ..
[08:59] <micahg> amitarora: https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages#Going%20through%20MOTU
[09:01] <amitarora> micahg: ok, will go through.. thanks!
[09:02] <micahg> amitarora: if you don't get 2 reviews by the weekend, I"ll be happy to look at it
[09:02] <amitarora> micahg: ok, thanks
[13:40] <pwuertz> hi, I'm having trouble including an udev rule in my package. by default, the rule is given a priority of 40 after upgrading to 10.10
[13:41] <pwuertz> if one wants to change the permissions of a device using an udev rule.. the default rule should be sufficient
[13:42] <pwuertz> but the 50-udev-default.rules reset my permission changes
[13:46] <pwuertz> using the standard debhelper scripts I named my rules file "packagename.udev" and the scripts install it using priority 40.. like "40-packagename.rules"
[13:46] <pwuertz> how can I change thatß
[15:40] <ari-tczew> ttx: so, gwt is to (fake)sync?
[15:41] <ttx> ari-tczew: yes, the orig tarballs are not the same (same size, so probably just some timestamp differences)
[15:42] <ari-tczew> ttx: I'll prepare a branch to fakesync. could you sponsor it?
[15:42] <ari-tczew> (when it will be done)
[15:42] <ttx> ari-tczew: sure, subscribe me
[15:42] <ari-tczew> thanks
[16:05] <highvoltage> tumbleweed: seen http://lwn.net/Articles/417946/ yet? :p
[16:41] <cdbs> For everyone's info, this is bilalakhtar's new nick
[16:42] <Pici> well, hes going to get a lot of accidental hilights...
[17:13] <ScottK> Plenty of disdain too.
[17:14] <jpds> ScottK: Ha.
[17:48] <geser> does somebody know what this "OpenStack" is from which I get merge emails?
[17:52] <micahg> geser: http://openstack.com/?
[17:52] <geser> ScottK: when is a good time to ask lucas_ for an archive rebuild to see how many packages FTBFS since the --as-needed linker default change?
[17:52] <ScottK> geser: You should talk to soren about openstack emails.
[17:52] <ScottK> geser: I'd say anytime is good.
[17:53] <lucas_> ScottK: geser: I'll add one to my TODO list
[17:53] <geser> lucas_: thanks
[17:53] <lucas_> we've got a new cluster to test anyway ;)
[17:53] <ScottK> lucas_: Thanks.
[17:53] <ScottK> Excellent.
[17:53] <ScottK> We're also interested in python2.7 related failures too.
[17:54]  * micahg is interested in xulrunner related breakage :)
[20:08] <soren> ScottK, geser: You're getting merge e-mails?
[20:09] <soren> ScottK, geser: Can you pastebin one of them so I know what we're talking about?
[20:16] <soren> ScottK, geser: Oh, about this for instance? https://code.launchpad.net/~openstack-ubuntu-packagers/ubuntu/natty/nova/ubuntu-apport-hook/+merge/42364 ?
[20:18] <soren> I'd be happy to spare you from getting the e-mails. I'm just not sure how. We have a team for doing openstack packaging. Openstack is in universe, so I added motu to the team (which we've long ago decided is the right thing to do for these things since everyone in ~motu can upload it anyway, so they might as well have access to the bzr branch).
[20:19] <ebroder> soren: I think there's a, like, ubuntu-dev-without-spam group or something to that effect that you could add, although ~ubuntu-dev is obviously more inclusive than ~motu
[20:19] <soren> For major changes, people may want to go through a merge proposal to get stuff reviewed.
[20:19] <soren> ebroder: Exactly.
[20:19] <soren> Oh, hang on.
[20:19] <soren> I think I know what to do.
[20:19] <ebroder> You could make a ~motu-without-spam list :)
[20:20] <soren> ebroder: I'm not sure how that would work. The ubuntu-dev-without-spam team just has a team e-mail address set, AFAIK.
[20:20] <soren> ebroder: So does ~motu.
[20:20] <ebroder> Ah, I didn't realize that was the trick. No idea, then
[20:21] <soren> I /think/ it is.
[20:21]  * soren checks that too
[20:23] <soren> ScottK, geser: I have no particular reservations removing ~motu from the team again. I just don't want to give the impression of being exclusive, because that's really not the intent.
[20:23] <micahg> ah, so there's a MOTU bugs ML
[20:25] <soren> Yes.
[20:25] <soren> https://launchpad.net/~ubuntu-dev-without-bugmail
[20:25] <soren> Is the without-spam one.
[20:25] <soren> It has a /dev/null sort of e-mail address set.
[20:26] <soren> But since the motu team also has an e-mail set and you guys /still/ see these e-mails, that clearly doesn't do the trick.
[20:26] <micahg> soren: maybe those people are subscribed to the ML?
[20:26] <soren> micahg: I glanced at the archive, didn't see the e-mails. I'll try looking harder.
[20:27] <soren> Nope, nothing.
[20:27] <soren> I can just remove ~motu and add to the description that anyone in ~motu is free to join the team?
[20:27] <geser> soren: yes, that merge request (or similar ones) for example (don't have the exact mail anymore as I deleted them already)
[20:27] <soren> geser: Ok.
[20:28] <soren> How does my proposal (right above your comment) sound?
[20:28] <soren> I'll let you catch up..
[20:28] <geser> soren: I don't know how exactly LP mail work, but wouldn't setting a contact email for the openstack-ubuntu-packagers team work too?
[20:29] <soren> geser: I doubt it.
[20:29] <soren> geser: Since it doesn't do the trick for ~motu.
[20:29] <soren> geser: Also, it's silly to have to maintain a separate mailing list for this.
[20:32] <geser> soren: hmm. if you don't get too many complains about those mail you can leave the motu team as member, it's not that much emails that's a too big annoyance for me (yet)
[20:32] <geser> just curious: does somebody from motu commit to those branches too?
[20:33] <soren> geser: At the moment, it's just myself, zul, and Daviey.
[20:39] <ajmitch_> soren: oddly, I don't seem to have received mail about the merge requests
[20:39]  * ajmitch_ is only indirectly in ~motu at the moment
[20:39] <highvoltage> you should be ashamed
[20:39] <ajmitch_> highvoltage: why?
[20:39] <highvoltage> just kidding :)
[20:40] <soren> ajmitch_: orly? That's odd.
[20:40] <ajmitch_> quite
[20:43] <bcurtiswx> is there a way to find out where `menu_proxy_module_load' would come from ?
[20:55]  * micahg hasn't gotten the e-mails either
[21:57] <ari-tczew> could someone taker a look on bug 683838 ? there is a not sure delta related to python.
[22:15] <ari-tczew> !sru | apachelogger
[23:51] <glennricster1> I recently upload a dolphin-emu package to REVU.  Are there any MOTU's interested in reviewing it?
[23:51] <glennricster1> The REVU link is http://revu.ubuntuwire.com/p/dolphin-emu
[23:52] <micahg> glennricster1: I'll be happy to look at it over the weekend
[23:55] <glennricster1> micahg:  Thanks.  Let me know what needs to be done.